Continuous Vulnerability Assessment and Remediation
Continuously acquire, assess, and take action on new information in order to identify vulnerabilities, remediate, and minimize the window of opportunity for attackers.
Why Is This Control Critical?
Cyber defenders must operate in a constant stream of new information: software updates, patches, security advisories, threat bulletins, etc. Understanding and managing vulnerabilities has become a continuous activity, requiring significant time, attention, and resources.
Attackers have access to the same information, and can take advantage of gaps between the appearance of new knowledge and remediation. For example, when new vulnerabilities are reported by researchers, a race starts among all parties, including: attackers (to "weaponize", deploy an attack, exploit); vendors (to develop, deploy patches or signatures and updates), and defenders (to assess risk, regression-test patches, install).
Organizations that do not scan for vulnerabilities and proactively address discovered flaws face a significant likelihood of having their computer systems compromised. Defenders face particular challenges in scaling remediation across an entire enterprise, and prioritizing actions with conflicting priorities, and sometimes-uncertain side effects.
How to Implement This Control
|CSC 4-1||Run automated vulnerability scanning tools against all systems on the network on a weekly or more frequent basis and deliver prioritized lists of the most critical vulnerabilities to each responsible system administrator along with risk scores that compare the effectiveness of system administrators and departments in reducing risk. Use a SCAP-validated vulnerability scanner that looks for both code-based vulnerabilities (such as those described by Common Vulnerabilities and Exposures entries) and configuration-based vulnerabilities (as enumerated by the Common Configuration Enumeration Project).||Quick win (Supports the "First Five")|
|CSC 4-2||Correlate event logs with information from vulnerability scans to fulfill two goals. First, personnel should verify that the activity of the regular vulnerability scanning tools themselves is logged. Second, personnel should be able to correlate attack detection events with earlier vulnerability scanning results to determine whether the given exploit was used against a target known to be vulnerable.||Quick win|
|CSC 4-3||Perform vulnerability scanning in authenticated mode either with agents running locally on each end system to analyze the security configuration or with remote scanners that are given administrative rights on the system being tested. Use a dedicated account for authenticated vulnerability scans, which should not be used for any other administrative activities and should be tied to specific machines at specific IP addresses. Ensure that only authorized employees have access to the vulnerability management user interface and that roles are applied to each user.||Quick win|
|CSC 4-4||Subscribe to vulnerability intelligence services in order to stay aware of emerging exposures, and use the information gained from this subscription to update the organization's vulnerability scanning activities on at least a monthly basis. Alternatively, ensure that the vulnerability scanning tools you use are regularly updated with all relevant important security vulnerabilities.||Quick win|
|CSC 4-5||Deploy automated patch management tools and software update tools for operating system and software/applications on all systems for which such tools are available and safe. Patches should be applied to all systems, even systems that are properly air gapped.||Visibility/Attribution|
|CSC 4-6||Carefully monitor logs associated with any scanning activity and associated administrator accounts to ensure that all scanning activity and associated access via the privileged account is limited to the timeframes of legitimate scans.||Visibility/Attribution|
|CSC 4-7||Compare the results from back-to-back vulnerability scans to verify that vulnerabilities were addressed either by patching, implementing a compensating control, or documenting and accepting a reasonable business risk. Such acceptance of business risks for existing vulnerabilities should be periodically reviewed to determine if newer compensating controls or subsequent patches can address vulnerabilities that were previously accepted, or if conditions have changed, increasing the risk.||Configuration/Hygiene|
|CSC 4-8||Measure the delay in patching new vulnerabilities and ensure that the delay is equal to or less than the benchmarks set forth by the organization. Alternative countermeasures should be considered if patches are not available.||Configuration/Hygiene|
|CSC 4-9||Evaluate critical patches in a test environment before pushing them into production on enterprise systems. If such patches break critical business applications on test machines, the organization must devise other mitigating controls that block exploitation on systems where the patch cannot be deployed because of its impact on business functionality.||Configuration/Hygiene|
|CSC 4-10||Establish a process to risk-rate vulnerabilities based on the exploitability and potential impact of the vulnerability, and segmented by appropriate groups of assets (example, DMZ servers, internal network servers, desktops, laptops). Apply patches for the riskiest vulnerabilities first. A phased rollout can be used to minimize the impact to the organization. Establish expected patching timelines based on the risk rating level.||Configuration/Hygiene|
CSC 4 Procedures and Tools
A large number of vulnerability scanning tools are available to evaluate the security configuration of systems. Some enterprises have also found commercial services using remotely managed scanning appliances to be effective. To help standardize the definitions of discovered vulnerabilities in multiple departments of an organization or even across organizations, it is preferable to use vulnerability scanning tools that measure security flaws and map them to vulnerabilities and issues categorized using one or more of the following industry-recognized vulnerability, configuration, and platform classification schemes and languages: CVE, CCE, OVAL, CPE, CVSS, and/or XCCDF.
Advanced vulnerability scanning tools can be configured with user credentials to log in to scanned systems and perform more comprehensive scans than can be achieved without login credentials. The frequency of scanning activities, however, should increase as the diversity of an organization's systems increases to account for the varying patch cycles of each vendor.
In addition to the scanning tools that check for vulnerabilities and misconfigurations across the network, various free and commercial tools can evaluate security settings and configurations of local machines on which they are installed. Such tools can provide fine-grained insight into unauthorized changes in configuration or the inadvertent introduction of security weaknesses by administrators.
Effective organizations link their vulnerability scanners with problem-ticketing systems that automatically monitor and report progress on fixing problems, and that make unmitigated critical vulnerabilities visible to higher levels of management to ensure the problems are solved.
The most effective vulnerability scanning tools compare the results of the current scan with previous scans to determine how the vulnerabilities in the environment have changed over time. Security personnel use these features to conduct vulnerability trending from month to month.
As vulnerabilities related to unpatched systems are discovered by scanning tools, security personnel should determine and document the amount of time that elapses between the public release of a patch for the system and the occurrence of the vulnerability scan. If this time window exceeds the organization's benchmarks for deployment of the given patch's criticality level, security personnel should note the delay and determine if a deviation was formally documented for the system and its patch. If not, the security team should work with management to improve the patching process.
Additionally, some automated patching tools may not detect or install certain patches due to an error by the vendor or administrator. Because of this, all patch checks should reconcile system patches with a list of patches each vendor has announced on its website.
CSC 4 Effectiveness Metrics
In order to test the effectiveness of the automated implementation of this control, organizations should measure the following:
1. How long does it take vulnerability scanning systems, if they detect unauthorized devices on the network, to generate an alert (time in minutes)?
2. How long after a scan successfully completes does it take to generate an alert indicating that it completed (time in minutes)?
3. If a scan does not complete, how long does it take to generate an alert that the scan failed to run (time in minutes)?
4. How long does it take automated patch management tools to alert or send e-mail to administrative personnel regarding the successful installation of new patches (time in minutes)?
For all of the above, consider that system priority, service level commitments, system role, and other factors may drive varying objectives for scan frequency and alert time frames on different systems. Ensure that the rationale for these classifications is clear, consistent, documented, and consistently applied. Verify that target detection and notification results are aligned with service level commitments and policies for each class of system.
CSC 4 Automation Metrics
In order to automate the collection of relevant data from these systems, organizations should gather the following information with automated technical sensors:
1. What is the percentage of the organization's business systems that have not recently been scanned by the organization's approved, SCAP compliant, vulnerability management system (by business unit)?
2. What is the average SCAP vulnerability score of each of the organization's business systems (by business unit)?
3. What is the total SCAP vulnerability score of each of the organization's business systems (by business unit)?
4. How long does it take, on average, to completely deploy operating system software updates to a business system (by business unit)?
5. How long does it take, on average, to completely deploy application software updates to a business system (by business unit)?
CSC 4 Effectiveness Test
To evaluate the implementation of Control 4 on a periodic basis, the evaluation team must verify that scanning tools have successfully completed their weekly or daily scans for the previous 30 cycles of scanning by reviewing archived alerts and reports to ensure that the scan was completed. If a scan could not be completed in that timeframe, the evaluation team must verify that an alert or e-mail was generated indicating that the scan did not finish.
CSC 4 System Entity Relationship Diagram
Organizations will find that by diagramming the entities necessary to fully meet the goals defined in this control, it will be easier to identify how to implement them, test the controls, and identify where potential failures in the system might occur.
A control system is a device or set of devices to manage, command, direct, or regulate the behavior of other devices or systems. In this case, the vulnerability scanners, management system, patch management systems, and configuration baselines all work together to address an organization's vulnerability management and remediation strategy. The following list of the steps in the above diagram shows how the entities work together to meet the business goal defined in this control. The list also delineates each of the process steps in order to help identify potential failure points in the overall control.
Step 1: Vulnerability intelligence service provides inputs to vulnerability scanner
Step 2: Vulnerability scanners scan production systems
Step 3: Vulnerability scanners report detected vulnerabilities to a vulnerability management system (VMS)
Step 4: The VMS compares production systems to configuration baselines
Step 5: The VMS sends information to log management correlation system
Step 6: The VMS produces reports for management
Step 7: A patch management system applies software updates to production systems.
Critical Security Controls - Version 5
- 1: Inventory of Authorized and Unauthorized Devices
- 2: Inventory of Authorized and Unauthorized Software
- 3: Secure Configurations for Hardware and Software on Mobile Devices, Laptops, Workstations, and Servers
- 4: Continuous Vulnerability Assessment and Remediation
- 5: Malware Defenses
- 6: Application Software Security
- 7: Wireless Access Control
- 8: Data Recovery Capability
- 9: Security Skills Assessment and Appropriate Training to Fill Gaps
- 10: Secure Configurations for Network Devices such as Firewalls, Routers, and Switches
- 11: Limitation and Control of Network Ports, Protocols, and Services
- 12: Controlled Use of Administrative Privileges
- 13: Boundary Defense
- 14: Maintenance, Monitoring, and Analysis of Audit Logs
- 15: Controlled Access Based on the Need to Know
- 16: Account Monitoring and Control
- 17: Data Protection
- 18: Incident Response and Management
- 19: Secure Network Engineering
- 20: Penetration Tests and Red Team Exercises
This work is licensed under a Creative Commons Attribution-NoDerivs 3.0 Unported License.
To further clarify the Creative Commons license related to the 20 Critical Controls content, (i) All persons are authorized to use the content as a framework in their organization or to sell professional services related to the content (e.g. a consulting engagement to implement the 20 Critical Controls), and (ii) sale of the contents as a framework model is not authorized. Users of the 20 Critical Controls framework are also required to refer to http://www.sans.org/critical-security-controls/ when referring to the 20 Critical Controls in order to ensure that users are employing the most up to date guidance.