UC Berkeley security policy mandates compliance with Minimum Security Standard for Electronic Information for devices handling covered data. The recommendations below are provided as optional guidance for continuous vulnerability assessment and remediation.
Resource Custodians must continuously assess and remediate vulnerabilities on all covered devices.
Attackers can discover and compromise covered data on devices that are not secured against vulnerabilities.
A vulnerability is a weakness in a covered device that can be exploited by an attacker to gain unauthorized access to covered data. An effective vulnerability assessment and remediation program must be able to prevent the exploitation of vulnerabilities by detecting and remediating vulnerabilities in covered devices in a timely fashion. Proactively managing vulnerabilities on covered devices will reduce or eliminate the potential for exploitation and save on the resources otherwise needed to respond to incidents after an exploitation has occurred. Information Security and Policy (ISP) provides a centrally managed campus service that campus units can use to comply with this requirement.
Information Security and Policy (ISP) provides a centralized, non-authenticated vulnerability scanning program that can help campus units comply with MSSEI vulnerability assessment and remediation requirements. By registering as directed in the MSSEI Annual Registration requirement, covered devices are automatically enrolled in the ISP vulnerability scanning program, which meets the MSSEI continuous assessment requirement. Note that resource proprietors and resource custodians must remediate identified vulnerabilities in a timely fashion as defined below.
To ensure vulnerability scans operate as required by MSSEI, campus unit must enable access by ISP vulnerability scanners to campus unit’s covered devices as described below:
- Enable all relevant firewalls to pass all IP traffic from ISP scanners. In the event a system can be disrupted by scanning, scanning exceptions can be made to alleviate the potential problem.
- "Scanning exception" means Resource Custodians block the minimum necessary to avoid the problem, and notify ISP of the block and the reason for the block. The notification is required so participation in the campus program can be adequately assessed.
- "Minimum necessary" means blocking the least amount of traffic possible to avoid the problem. For example, blocking a specific TCP port rather than all TCP traffic, or blocking a specific IP protocol rather than all IP traffic.
More details about the ISP vulnerability scanning program can be found in the scanning service page, under the section “Sensitive data host scanning”.
Alternative Vulnerability Assessment and Remediation
In the cases where campus service can not be used to address the requirement, resource proprietor and resource custodian should consider the following recommendations to implement an effective continuous vulnerability assessment and remediation program:
- Establish information resources that will be used to identify relevant vulnerabilities. These information resources should be monitored to keep up-to-date awareness on emerging threats and latest software updates. Common vulnerability resources include:
- Vendor specific vulnerability databases and mailing lists (e.g. Microsoft, Oracle feeds)
- Prioritize the order in which the organization addresses remediating vulnerabilities. Vulnerabilities from vendors and public source typically provide risk ratings that may need to be adjusted for campus computing environments. When establishing remediation priority, consider mitigating controls in place that affect how easily the vulnerability can be exploited, e.g., the priority of a vulnerability can be lowered if access to a protected subnet is required for exploitation.
- Non-authenticated vulnerability scans should be performed on covered devices at least once a week (5 business days). See additional discussion below on non-authenticated scan vs. authenticated scan.
- Remediate high-risk vulnerabilities (prioritized according recommendation #2 above) in a timely fashion, where “timely” is defined in the table below:
Remediation Steps High Risk Vuln Response Time (business days) Medium Risk Vuln Response Time (business days) Confirm vulnerability is not false positive 1 5 Develop remediation plan to fix vulnerability 5 10 Remediate vulnerability by executing steps in remediation plan 10 30
If remediation steps may be delayed due to institutional needs, resource proprietor and/or resource custodian should document decision to delay remediation along with details that address each of the following elements:
- Threat Level - Does the organization or systems requiring remediation face numerous and/or significant threats? For example, public Web servers and internet accessible covered devices may face high threat levels. In general, timely remediation is critical for these systems. In contrast, for a covered device that is inaccessible from the Internet or other campus networks, remediation may be delayed for institutional needs because such a device usually faces a lower threat level.
- Risk of compromise - What is the likelihood that a compromise will occur? If the vulnerability is easy to exploit, then remediation should be applied in a timely fashion as defined above.
- Impact of compromise - What are the consequences of compromise? If the system is critical or contains sensitive data, then the remediation should be performed immediately. This holds true even for noncritical systems if a successful exploitation would lead to an attacker gaining full control of the system.
- Create a database of remediations that need to be applied to covered devices. The remediation database should be used to track remediation progress and provide historical reference in follow-up incidents post-remediation.
- Verify remediation through targeted vulnerability re-scanning that focuses on specific software versions and vulnerabilities.
- Measure the effectiveness of patch and vulnerability management program and apply corrective actions as necessary. The vulnerability metrics should at minimum include the following (on an annual basis):
- Total Vulnerabilities
- Total Vulnerabilities per 1000 devices
- Uncorrected Vulnerabilities
- Uncorrected Vulnerabilities per 1000 devices
The metrics above are also collected and reported by ISP vulnerability scanning process. Click here for detail definitions of metrics.
Campus units should define roles and responsibilities associated with vulnerability detection and remediation. Security roles defined in Security Contact application should be used to assign responsibilities for detecting and remediating against identified vulnerabilities.
Non-Authenticated vs. Authenticated Scans
Continuous Vulnerability Assessment requirement refers to non-authenticated scanning technique that is one of the most common vulnerability discovery techniques. Without using credentials to the scanned system, a non-authenticated vulnerability scan can gather basic information about the system which may include:
- Operating system name and version
- Network ports open
- Services listening on the ports, if these details are available without authentication using techniques such as banner-grabbing
- Data “leaked” by the listening services, such as the listing of open file shares and insecure configurations that allow access using default/known credentials
The scanning tool obtains these information by sending probing queries over the network to scanned devices. The scanning tool may be able to use these details from non-authenticated scans to identify some vulnerabilities, such as missing security patches and configuration weaknesses. As non-authenticated scans are less intrusive to the scanned devices and easier to setup, it should run more frequently than authenticated scans to detect risks associated with future vulnerabilities.
Authenticated scans require valid login credential to scanned devices, which is used by scanner tool to authenticate and obtain detailed information about operating system and installed applications, including configuration issues and missing security patches. As the result, authenticated scans findings are more comprehensive and have fewer false positives than non-authenticated scans. For specific guidance on authenticated scan, please refer to authenticated scan guidelines.
Note that while most vulnerability scans are non-intrusive, meaning discovered vulnerabilities are not actually exploited to cause instability in scanned devices, resource proprietors and custodians should test scan configuration to confirm before running scans on production systems.
- Nessus campus network scanning,
- ISP Vulnerability Metrics Reporting,
- NIST Guidelines: Creating a Patch and Vulnerability Management Program,