Vulnerability Management
Vulnerability management refers to the process of discovering, confirming, classifying, prioritizing, assigning, remediating, and tracking vulnerabilities. Do not confuse vulnerability management with vulnerability scanning, the latter being part of the vulnerability management process, with emphasis on the discovery phase. It is also important to understand that risk management deals with all associated risks, whereas vulnerability management targets technology.
Vulnerabilities can be perceived as weaknesses in people, process, and technology. Vulnerability management in the context of SOC focuses on known technical weaknesses introduced in software and firmware. It is worth highlighting that the existence of a technical vulnerability could be the result of weaknesses in people and process such as the lack of a proper software quality assurance process.
Organizations with a mature security program integrate the closely linked vulnerability management and risk management practices. Sometimes this can be accomplished using tools that can automate this integration. Figure 2-9 shows the initial steps you would typically undertake to identify the scope and prepare your vulnerability management program. We will look deeper into preparing the SOC in Chapter 10.
)
Figure 2-9 Preparing a Vulnerability Management Program
The most critical element of vulnerability management is being faster at protecting the vulnerable asset before the weakness is exploited. This is accomplished by continuously applying a series of steps to identify, assess, and remediate the risk associated with the vulnerability. A good reference model that can be followed as a guideline for handling risk is the SANS Vulnerability Management Model shown in Figure 2-10. The details of each step are covered in Chapter 7.
)
Figure 2-10 SANS Vulnerability Management Model
One of the most common methods to identify when a system is vulnerable is by monitoring for vulnerability announcements in products found within your organization. Let’s look more into how this information is released.
Vulnerability Announcements
Vulnerabilities in open and closed source code are announced on a daily basis. Identifiers are associated with vulnerability announcements so that they can be globally referenced, ensuring interoperability. One commonly used standard to reference vulnerabilities is the Common Vulnerabilities and Exposures (CVE), which is a dictionary of publicly known information security vulnerabilities and exposures. CVE’s common identifiers make it easier to share data across separate network security databases and tools. If a report from one of your security tools incorporates CVE identifiers, the administrator can quickly and accurately access and fix information in one or more separate CVE-compatible databases to remediate the problem. Each CVE identifier contains the following:
- CVE identifier (CVE-ID) number in the form of CVE prefix + Year + Arbitrary Digits
- Brief description of the security vulnerability or exposure
- Other related material
The list of products that use CVE for referencing vulnerabilities is maintained by MITRE.8
The CVE identifier does not provide vulnerability context such as exploitability complexity and potential impact on confidentiality, integrity, and availability. These are provided by the Vulnerability Scoring System (CVSS), maintained by NIST. According to NIST, CVSS defines a vulnerability as a bug, flaw, weakness, or exposure of an application, system device, or service that could lead to a failure of confidentiality, integrity, or availability.
The CVSS enables users to understand a standardized set of characteristics about vulnerabilities. These characteristics are conveyed in the form of a vector composed of three separate metric groups: base, environmental, and temporal. The base metric group is composed of six metrics: Access Vector (AV), Access Complexity (AC), Authentication (Au), Confidentiality (C), Integrity (I), and Availability (A). The base score, ranging from 0 to 10, derives from an equation specified within the CVSS. AV, AC, and Au are often referred to as exploit metrics, and C, I, and A are referred to as impact metrics. Figure 2-11 shows the base metrics used in CVSS (source: NIST CVSS Implementation Guidance). The vector template syntax for the base score is AV:[L,A,N]/AC:[H,M,L]/Au:[M,S,N]/C:[N,P,C]/I:[N,P,C]/A:[N,P,C].
)
Figure 2-11 CVSS Base Metrics (Source: NIST CVSS Implementation Guidance)
CVSS is a quantitative model that ensures a repeatable accurate measurement while enabling users to see the underlying vulnerability characteristics that were used to generate the scores. Thus, CVSS is well suited as a standard measurement system for industries, organizations, and governments that need accurate and consistent vulnerability impact scores. Example 2-11 shows the information included in the vulnerability announcement labeled CVE-2014-4111 including the CVSS score of (AV:N/AC:M/Au:N/C:C/I:C/A:C).
Example 2-11 Vulnerability Announcement CVE-2014-4111
Original release date: 09/09/2014 Last revised: 09/10/2014 Source: US-CERT/NIST Overview Microsoft Internet Explorer 6 through 11 allows remote attackers to execute arbitrary code or cause a denial of service (memory corruption) via a crafted web site, aka "Internet Explorer Memory Corruption Vulnerability." Impact CVSS Severity (version 2.0): CVSS v2 Base Score: 9.3 (HIGH) (AV:N/AC:M/Au:N/C:C/I:C/A:C) Impact Subscore: 10.0 Exploitability Subscore: 8.6 CVSS Version 2 Metrics: Access Vector: Network exploitable; Victim must voluntarily interact with attack mechanism Access Complexity: Medium Authentication: Not required to exploit Impact Type: Allows unauthorized disclosure of information; Allows unauthorized modification; Allows disruption of service External Source: MS Name: MS14-052 Type: Advisory; Patch Information Hyperlink: http://technet.microsoft.com/security/bulletin/MS14-052