Many organizations struggle with identifying and patching all vulnerabilities. Legacy systems that cannot be patched without impacting operations, a lack of tools that can identify all vulnerabilities, automated deployment of third-party patches, and meeting remediation timelines associated with patching requirements are just some of the reasons your organization may struggle with comprehensive technical vulnerability management.
Remember, deploying the recommended Microsoft patches is not the same as deploying all required patches. Third-party, non-Microsoft, software also needs to be patched regularly.
Your organization also needs to have the capability to accommodate firmware upgrades to maintain protection for infrastructure devices against new, emerging threats. If you do not comprehensively address all aspects of technical vulnerability management, your information systems and infrastructure devices are very likely to be impacted either by performance degradation, system compromise, or both.
The Technical Vulnerability Management Plan
A vulnerability management plan or procedure should be developed and implemented. This plan should describe how vulnerability scanning, remediation scheduling, and patching are performed within your organization. Your plan should address the following:
- Measures of effectiveness
- Tools available/required
- Training requirements
- Sources of vulnerability information
- Roles and responsibilities
Sources of Vulnerability Information
Timely information about technical vulnerabilities should be obtained from trusted sources. Once received, your organization’s exposure to vulnerabilities should be evaluated, and appropriate actions should be taken to address the associated risks to prevent the exploitation of technical vulnerabilities. Sources of vulnerability information may include:
- Vendors and manufacturers
- Mailing lists
- Department of Homeland Security (DHS) US-CERT
- Industry-specific Information Sharing and Analysis Centers (ISACs)
- Product user groups
- FBI’s InfraGard
Your asset inventory should be leveraged to determine what information assets, including firmware and software, may be impacted by zero-day vulnerabilities. Specific information to support vulnerability management should include the software vendor, version number, and current state of deployment (e.g., what software is installed on what systems). The personnel in your organization responsible for the software should also be defined.
Technical Vulnerability Scans
Technical vulnerability scans of all information systems, including all infrastructure devices, should be performed on a regular schedule (e.g., at least monthly). Scans should also be performed when new vulnerabilities that may have a potentially immediate impact (e.g., “zero-day” vulnerabilities) are identified or reported. This does not mean all systems need to be scanned at the same time.
Scanning all assets at the same time could hurt the performance of your networks. Even though scanning is generally performed during non-business hours, it can consume notable network bandwidth as well as the system resources of the devices being scanned. Different types of information systems and infrastructure devices can be separated into multiple scanning groups. This enables scanning to take place during different approved windows throughout the month.
The overall goal is to scan each asset at least once every month. Note: More frequent scans may be appropriate for critical systems and infrastructure devices.
Technical vulnerability scanning tools should include the capability to update the list of vulnerabilities for which they can readily. Scanning techniques should be used that facilitate interoperability amongst tools and automate parts of the vulnerability management process by using standards for:
- Enumerating platforms, software flaws, and improper configurations
- Formatting checklists and testing procedures
- Measuring the impact of vulnerabilities
Vulnerability scan reports and control assessment results should be analyzed once available. Vulnerabilities should be remediated by the timelines defined by your organization that are based on the criticality of the vulnerability and its impact on the organization.
Pro Tip:
Implementing a 30, 60, 90, and 180-day remediation schedule that is based on criticality is a good starting point for addressing identified vulnerabilities.
- Critical vulnerabilities: patched within zero to 30 days
- High vulnerabilities: patched within 60 days
- Medium vulnerabilities: patched within 90 days
- Low vulnerabilities: patched within 180 days
The sooner vulnerabilities are patched, the better off your organization will be. Highly regulated, certified, and larger organizations may have shorter remediation requirements. Just keep in mind that the timelines documented in your vulnerability management procedure are what you will be held accountable for achieving.
The information obtained from the vulnerability scanning process and control assessments should be communicated to appropriate internal stakeholders. This includes sharing results with appropriate cross-functional personnel. This sharing of information is intended to help eliminate the same vulnerabilities from impacting similar information systems within your organization.
Privileged access accounts for information systems should be used to support credentialed vulnerability scanning. This results in more thorough scanning, along with more comprehensive results. The results from back-to-back or recurring vulnerability scans should be regularly compared to verify that vulnerabilities have been successfully remediated promptly.
Patches should be tested and evaluated before they are installed to ensure that they are effective at removing the vulnerability they are intended to address while not resulting in side effects that cannot be tolerated. Patches installed in the production environment should also be installed in the business continuity or recovery environment to keep these environments updated. You do not want your production environment to be fully patched and leave an open vulnerability in your recovery environment that could potentially be used to impact your production (or other) environment.
Vulnerability scanning and appropriate remediation should be completed before deploying new information systems or devices. A best practice is to keep a “golden image” of systems or standard configurations that can be deployed on new systems or devices that are being placed into the production environment. These images and standard configurations must be refreshed after each applicable vulnerability patch deployment. It takes time to research vulnerabilities, test, and deploy appropriate patches.
If base images and standard configurations are not updated with newly deployed patches previously addressed, vulnerabilities are likely to be re-introduced into your environment when a new system or device is deployed. When this happens, your vulnerability counts will increase for no reason other than the mismanagement of images and standard configurations. This happens to organizations much more often than it should, and it can be demoralizing to the personnel who work to keep your environment patched with appropriate updates.
