A lot of ambiguity exists around how to properly manage vulnerabilities. The vulnerability management program will encompass multiple teams, tools and processes with the common goal to secure and maintain security of the environment. A proper vulnerability management will allow for the management and measurement through metrics, which mature programs regularly produce.
Before performing vulnerability scans things a few things must be considered.
What should be scanned, or how should different segments be treated? Is one zone PCI and the other is HITRUST but the dev network is out of scope.
Once the scope is identified we need to
Discover Assets
Keep a valid asset inventory is not a fun or cool thing to do but it is important and often over looked.
Another often-overlooked aspect of an update to date asset inventory is the utilizing outside sources of alerts. For example if I know I have a ton of Apache Web Servers I can set alerts from multiple sources to notify me or the team of any new vulnerabilities specifically against the criteria I define.
Once assets are discovered we will need to confirm custodian/ownership or who is patching them?
After assets are known and owners are identified we need to assign criticality rating based on business function.
The asset, asset owner, /custodian, and the criticality rating of each asset should be included in the inventory along with the location, name, serial number, important software, OS or versions and other relevant information.
Now the fun stuff…
Identifying Vulnerabilities (Detection Phase)
A vulnerability scan is a combination of an automated or manual tools, techniques, and/or methods that are run against external and internal network devices and servers, designed to expose potential vulnerabilities in networks that could be exploited by malicious individuals. Once these weaknesses are identified, the entity should focus on remediating deficiencies discovered, and repeats the scan to verify the vulnerabilities have been corrected.
A vulnerability scan should be performed against the internal network and the external footprint of an organization. The frequency of the scans can vary depending upon compliance regulations but a suggested practice would be to scan quarterly and after any major changes to your environment.
PCI requires quarterly scans from an approved vendor for organizations external environments. Internal scans are defined for annual along with penetration tests.
HITRUST does require vulnerability scanning quarterly as well.
Evaluation of Vulnerabilities (Prioritizing of Risk)
On a typical vulnerability scan findings will range from critical, high, medium and low
These ratings are based on the Common Vulnerability and Exposures, which is commonly referred to as a CVE.
A CVE score is used for prioritizing the security of vulnerabilities. The CVE glossary is a project dedicated to tracking and documenting vulnerabilities for software and hardware. Since 1999, MITRE Corporation has maintained the CVE system, which is funded by the National Cyber Security Division of the US Department of Homeland Security.
When a security researcher discovers a new vulnerability it will be evaluated and identified according to the Root CVE Numbering Authority. Once independent researchers can confirm the vulnerability it will be entered into the NIST National Vulnerability Database (NVD).
The Common Vulnerability Scoring System CVSS is utilized to identify a final score for vulnerability.
3 parts of the CVSS score.
The Base score, temporal score and environmental score.
Knowing the criticality ratings of each system will help judge associated risk of the system based on the vulnerability rating considering as well the the system rating. The CVSS score includes an environmental score that would help determine a vulnerabilities risk specifically against your organization. The temporal score is based on the timing of available patching or fixes for vulnerabilities.
A high vulnerability on a system that is not external exposed and requires network access before it can be exploited will be rated lower than a high vulnerability found on an externally exposed web server. This is a simple example but situations will be similar and using a defined methodology will help.
Remediation (Fixing the detected Issues)
Remediation efforts should be tracked, managed and reviewed. Ideally a central ticketing system will be utilized which can track remediation efforts to provide meaningful metrics to the overall vulnerability management program. Metrics from the remediation effort can include, mean time to detection, mean time to remediation, average window of exposure, % of systems without critical or high vulnerabilities.
- Rinse, Repeat and Document
- Set a defined frequency for:
- Scanning
- Patching
- Reviewing Scans
- Reviewing Remediation efforts
A vulnerability management program should consist of a team of individuals including IT, Security and a management level IT or Security person. The idea is to include IT that most likely will perform remediation and have it managed and overseen by security. IT or Security management should be included to prove buy-in and to help with any approvals required.
A vulnerability management program provides an organization the data needed to properly manage and measure their IT infrastructure.
A mature vulnerability program will encompass not only vulnerability scanning but inventory management, a remediation process for discovered vulnerabilities, penetration testing, and risk management. A mature program will have the ability to coordinate the results of previous scans to create meaningful metrics that an organization can use to review the processes for improvements and additional risk reduction.