Patch and Vulnerability Management
NIST 800-40 “Creating a Patch and Vulnerability Management Program” describes the functions and processes that a patch and vulnerability management program should cover in order to maintain effective security.
Importance of patch management
As operating systems, applications and utility tools continue to manifest exploitable flaws, rapid application of security patches becomes critical to security. Attackers can reverse engineer patches and develop exploits that penetrate the vulnerability made public when the patch is released. Most organizations do not perform the patching task well enough to minimize the timeframe of vulnerability. They often do not have adequate inventory records and miss patching some systems. They often do not have formalized procedures for testing and deploying patches promptly.
Description of the patch and vulnerability group (PVG)
The composition and structure of the PVG will vary with the system being defended, the mission and information involved and the structure of the organization, but there are elements likely to be common and which should be considered. Team members may come from both the operations and the information security areas and should represent skills for system administration, firewall configuration and management, intrusion detection, vulnerability scanning, patch management, and change control.
Functions of the PVG
- Inventory – creating and maintaining an accurate inventory of information system components is an essential pre-requisite to performing good patch and vulnerability management. Use existing IT inventory if possible and prioritize your target list by system, FIPS impact level, network location, high priority resources and whether or not they are supported by the central organization.
See security controls PM-5 and CM-8. - Monitoring
- Monitoring security advisories, vulnerabilities and threats
See security control SI-5 - Monitoring your network and systems for vulnerabilities and evidence of incidents
See security controls CA-7, SI-4, AU-6, RA-5
- Monitoring security advisories, vulnerabilities and threats
- Prioritize remediation actions according to the significance (threat/vulnerability matchup), the extent of the threat and the risk involved with taking the remediation action.
See security controls CM-4 and RA-3 - Create a DB of remediations to ensure integrity and availability and to maintain a history.
- Testing the remediation before applying it is wise if possible
- Authentication check
- AV/malware scan
- Application in a lab environment
- Check for dependencies and ripple effects
- Monitor the experience of others in the community
- Make a balanced decision on the risk of taking the action versus the risk of not taking the action
See security controls SI-3/7, SA-11, CM-4 - Remediation usually takes the following three forms:
- Patching
- Configuration changes
- Removal of software or hardware
See security control SI-2 - Verifying – this is often performed by vulnerability scanning, but can also involve examining patch logs, files and configuration settings, and doing penetration testing.
See security controls RA-5, AU-6, CA-2/7 - Training – there may be training or some other form of knowledge distribution required after the vulnerability is closed
See security control AT-3
NIST stresses the use of automated tools to accomplish many of these functions.
Metrics
Performance measurement of the progress made in the patching program should be considered in order to ensure security requirements are being met. This should include some of the following types of metrics:
- Susceptibility to attack – number of services running, number of vulnerabilities identified, number of patches required.
- Patching response time – this can be divided up into sub-categories such as; identification time, testing time, application of the patch time and possibly others.
- Cost – this too can be broken down into many sub-categories. It may be particularly effective to attempt to measure the cost saved by applying patches in terms of the cost of potential impact to business functions and loss if they had not been applied.
SEE ALSO:
NIST SP 800-40 ver2 “Creating a Patch and Vulnerability Management Program”