With any new technology topic, terminology, semantics, and the use of terms within the context of the technology topic can be confusing, misused, and misrepresented. Risk itself encompasses the following three major areas: risks, threats, and vulnerabilities.
Risk is the probability or likelihood of the occurrence or realization of a threat. There are three basic elements of risk from an IT infrastructure perspective:
An IT asset or data asset is an item or collection of items that has a quantitative or qualitative value to an organization. Examples of IT assets that organizations may put a dollar value or criticality value on include the following:
A threat is any agent, condition, or circumstance that could potentially cause harm, loss, damage, or compromise to an IT asset or data asset. From an IT infrastructure perspective, threats may be categorized as circumstances that can affect the confidentiality, integrity, or availability of the IT asset or data asset in terms of destruction, disclosure, modification, corruption of data, or denial of service. Examples of threats in an IT infrastructure environment include the following:
A vulnerability is a weakness in the system design, a weakness in the implementation of an operational procedure, or a weakness in how the software or code was developed (for example, bugs, back doors, vulnerabilities in code, and so on). Vulnerabilities may be eliminated or reduced by the correct implementation of safeguards and security countermeasures.
Vulnerabilities and weaknesses are common with software mainly because there isn't any software or code in existence that doesn't have bugs, weaknesses, or vulnerabilities. Many vulnerabilities are derived from the various kinds of software that is commonplace within the IT infrastructure. This type of software includes the following:
Why do software vendors and application software companies have Software Licensing Agreements (SLAs) that protect them from their own software vulnerabilities? Why do software companies have stringent Limited Warranty, Disclaimer of Warranties, Exclusion of Incidental, Consequential, and Certain Other Damages, and Limitations of Liability clauses in all their software products' SLAs?
The answer to these questions can be summarized quite simply: software vendors know they can't create and sell perfect code because of the human element. Software bugs and vulnerabilities are commonplace. Simply put, software vendors cannot guarantee that their software is bug-proof and free of vulnerabilities, so they must protect themselves from potential liability and damages that may be the result of a software vulnerability that is exploited by a hacker or unauthorized user.
Herein lies the fundamental problemsoftware has vulnerabilities, hackers and perpetrators know there are vulnerabilities, and organizations attempt to put the proper software patches and updates in place to combat this fundamental problem before being attacked. The key word here is before being attacked. Many organizations lack sufficient funds for securing their IT infrastructure by mandating a vulnerability window of 0 days or 0 hours, thus eliminating any software vulnerability potential threats. Achieving a vulnerability window of 0 days or 0 hours is virtually impossible given that software vendors cannot provide software patches fast enough to the general public after a vulnerability is exposed. In addition, the time required to deploy and install the software patch on production servers and workstations exposes an organization's IT infrastructure to potential threats from that vulnerability.
This gap in time is reality in IT infrastructures, especially because a majority of IT assets and devices have some kind of software loaded in them. Remember, vulnerabilities in software extend to firmware, operating systems, configuration files, and applications, and must be combated with a software maintenance, update, and patch maintenance plan. This encompasses the entire software, operating, and application software environment exposing potential vulnerabilities in any device that houses and runs this vulnerable software. In large organizations, combating the software vulnerability issue requires an enterprise, automated software patch-management solution.
The Computer Emergency Response Team (CERT) is an organization sponsored by Carnegie-Mellon University's Software Engineering Institute. Until 2003, CERT was the organizational body that was responsible for collecting, tracking, and monitoring vulnerability and incident reporting statistics. CERT can be found at www.cert.org. CERT publishes statistics for the following:
As of 2004, CERT no longer publishes the number of incidents reported. Instead, CERT is working with others in the community to develop and report on more meaningful metrics for incident reporting, such as the 2004 E-Crime Watch Survey. Figure 3.1 shows the dramatic increase in known and documented vulnerabilities and the number of incidents that have occurred and have been recorded by www.cert.org during the past few years. Note that as the number of vulnerabilities increases, the number of incidents has also increased, but this value is misleading because the number of incidents that go unreported is unknown.
Figure 3.1. Rise in vulnerabilities and incidents.
Many of the security incidents indicated in 2003 on the www.cert.org website were the direct result of software vulnerabilities that were exploited by an attacker. These security incidents can be attributed to the "vulnerability window, which is the amount of time that lapses between when a known vulnerability is identified and documented to when an organization implements the vulnerability fix or deploys the appropriate software patch.
Because of this vulnerability window issue, SQL Slammer, which was a known vulnerability posted by Microsoft in July, 2002, affected nearly 90% of the world's SQL databases on Super Bowl Sunday, January 2003, six months after the vulnerability was exposed.
The stages of vulnerability in software are as follows:
In Figure 3.2, the stages in vulnerabilities in software are defined. This gap in time between when a known vulnerability is identified and communicated to when that known vulnerability is mitigated through a software patch is referred to as the vulnerability window.
Figure 3.2. The vulnerability window.
From a vulnerability perspective, an IT asset or IT infrastructure is most vulnerable during the vulnerability window exposure time. This exposure time is referred to as vulnerability time:
Vulnerable Time (Vt) = Vt(open) - Vt(closed)
Most organizations, when they first conduct a vulnerability assessment on their IT infrastructure, servers, workstations, and systems, are shocked to realize that they are vulnerable because of software vulnerabilities inherent in the code. Upon realizing this, the ultimate goal for an organization is to prioritize those IT assets and IT infrastructure components to assess which IT assets should have their vulnerability time reduced. Reducing the vulnerability time will assist organizations in minimizing the potential risk and threats caused by software vulnerabilities. Many organizations create internal policies that state the maximum vulnerability time exposure for their mission critical IT assets and systems.
Organizations are now realizing that having an IT security architecture and framework consisting of policies, standards, procedures, and guidelines for their production IT systems, software, and applications is critical. Many organizations are apt to create a policy that defines the maximum acceptable vulnerability window for its mission-critical and production IT systems. This policy then drives the priorities for how funds are to be invested for risk mitigation via an enterprise patch-management solution.
When defining a policy for software vulnerability management, identifying and prioritizing mission-critical IT assets to prioritize the confidentiality, availability, and integrity of information assets is paramount.
Software vulnerabilities are documented and tracked by the U.S. Computer Emergency Readiness Team (US-CERT) in a public-accessible list called the Common Vulnerabilities and Exposures (CVEs) list. In 1999, the MITRE organization was contracted by the U.S. Computer Emergency Readiness Team to track, monitor, and update the CVE list. Today, the CVE list has grown to more than 7,000 unique documented vulnerability items, and approximately 100 new candidate names are added to the CVE list each month, based on newly discovered vulnerabilities. The CVE list can be found at http://www.cve.mitre.org/.
The CVE is merely a list or dictionary of publicly known information security vulnerabilities and exposures and is international in scope and free for public use. Each vulnerability or exposure included on the CVE list has one common, standardized CVE name. The CVE list is a community effort that encourages the support of hardware and software vendors. The CVE list is free and can be downloaded or accessed online at the previously mentioned website.
Use of the CVE list along with identifying IT and data assets are necessary first steps in conducting an internal risk assessment of an organization. The risk and vulnerability assessor should first identify all known IT assets and build an IT asset inventory using a spreadsheet or similar tool. Then, for each IT asset, the assessor should list the firmware, the operating system software, the application software, and the software patches and their version numbers currently loaded in that IT asset. Using the CVE list, a quick global search on known software vulnerabilities to the organization's IT asset list can be conducted, especially if the software version and software patch numbers from the software vendor can be obtained. This quick examination of known software vulnerabilities will help an organization uncover known software vulnerabilities. This information can be used to assess whether the value of the IT asset or the data asset requires remediation.
Prior to conducting an internal risk assessment, it is important to understand the new laws, mandates, and regulations that are driving organizations to create and implement information systems security plans and conduct vulnerability assessments. These new laws, mandates, and regulations are impacting IT infrastructures and their assets and are driving the need for conducting a thorough risk and vulnerability assessment on an IT infrastructure and its assets.
Introduction to Assessing Network Vulnerabilities
Foundations and Principles of Security
Why Risk Assessment
Scoping the Project
Understanding the Attacker
Performing the Assessment
Tools Used for Assessments and Evaluations
Preparing the Final Report
Appendix A. Security Assessment Resources
Appendix B. Security Assessment Forms
Appendix C. Security Assessment Sample Report
Appendix D. Dealing with Consultants and Outside Vendors
Appendix E. SIRT Team Report Format Template