Vulnerability and Patch Management are major and essential tasks of the Information- and IT-Security. A good vulnerability and patch management process helps you to identify, evaluate, prioritize and reduce the technical security risks of your company or organization. Even if you are not planning to implement security frameworks like ISO 27001 or NIST Cybersecurity Framework (CSF) you should consider to implement a basic vulnerability management process or technical measures and controls to be prepared for critical cybersecurity attacks or threats. Not only to harden your IT Infrastructure but also to increase your organizations resilience. This article helps you to understand the basic concepts, process and best practices for a modern vulnerability management.
1. What is Vulnerability Management in IT-Security
In the first step Vulnerability Management describes a process to identify, evaluate, classify, prioritize and document a vulnerability (mostly for software). And in the second step how to mitigate, remediate or – in the worst case – accept the risk.
Vulnerabilities are normally identified or discovered by the product vendor, security researchers, penetration testers, hackers and so on.
If officially reported, each detected vulnerability is assigned a so called CVE-ID (Common Vulnerabilities and Exposures – ID). The CVE-IDs are assigned and registered by CVE Numbering Authority (CNA). The primary CNA is “The MITRE Corporation” but also companies or organizations can assign their CVE-ID for their own products. Additionally, third parties such as CERTs (Computer Emergency Response Teams) or CSIRTs (Computer/Cyber Security Incident Response Teams) could assign CVE numbers that are not covered by CNAs above.
All CVE numbers are saved with further information in a publicly available database. The most common databases or catalogues are:
- The MITRE – CVE Database (https://cve.mitre.org)
- NIST – National Vulnerability Database (NVD) (https://nvd.nist.gov)
- CVE Details (https://www.cvedetails.com)
From the IT-Security view the next step is to identify the organization’s information assets. This could be hardware assets (such as computers, servers, network components or any electronic devices) and/or software assets (such as operating systems, software and applications). The aim is to compare the version status of these assets with those from the vulnerability databases to find weaknesses, vulnerabilities and risks in the IT infrastructure.
After a vulnerability is found, it must be classified and remediated. The remediation is normally done by deploying patches or updates. Therefore you often find the combination of Vulnerability Management policies, processes or procedures together with Patch Management.
2. Who is responsible for Vulnerability Management in my company or organization?
There are 3 major players who could be involved in a vulnerability management process:
2.1. Information Security department or Chief Information Security Officer (CISO)
In larger organizations the Information Security department or CISO is responsible to define:
– a strategy in designing and implementing a Vulnerability Management Process and Patch Management Process
– a set of rules or policies
– roles and responsibilities (who does what)
– the risk management and classification
– controls and measures (technical and/or organizational)
– reporting to upper management
The main goal is to describe the risks coming from external (third party software) as well as internal (own software) vulnerabilities.
2.2. IT-Security or Security Operations Center (SOC)
IT-Security or in larger corporations a SOC is responsible to implement technical measures and tools to check all information systems against vulnerabilities. This is normally done with the help of tools (see below) and vulnerability scanners. If vulnerabilities are found the next step is to remediate the vulnerability by whether patching the system or implementing technical measures to reduce the likelihood of an attack (e.g., Firewalls, configuration changes, etc.)
Another possibility is to do or order penetration tests that does not even check for weaknesses but also if a vulnerability or system is exploitable.
Because the elimination of vulnerabilities is also a major part of the process, vulnerability management is often combined with patch management procedures. Therefore IT-Security or the SOC is also responsible to prove the absence of a vulernability after a solution is deployed.
IT-Security or SOC reports any weaknesses and implemented measures to the CISO. The CISO assesses the risk of the vulnerability and reports it to the upper management, which decides on any further actions.
2.3. Software Development Department
If the organization develops or sells its own software, their responsibility is to integrate security and vulnerability checks in their software development lifecycle process. For larger corporations it could also be possible to register their own CVE Numbering Authority (CNA) to assign their own CVEs. If weaknesses are found, it is also responsible to develop and deliver patches for customers.
This topic is normally outside of the scope of a traditional vulnerability management process, as it should be described in a separate security development policy or process.
2.4. IT Operations
The IT Operations or infrastructure teams are responsible to remediate the vulnerability by deploying patches, updates or any other measures (e.g. configuration changes, installing firewalls, shutting down or replacing systems).
3. What are Vulnerability Management requirements for ISO 27001 or NIST CSF
If you are planning to implement a security management framework such as ISO 27001 or NIST Cybersecurity Framework (CSF) there are a lot of requirements and prerequisites for the realization of a vulnerability management process.
3.1. ISO 27001
The necessary measures are described in the ISO 27001 Annex A in section A.12 where operational security controls are defined.
The main requirements are:
– Describe and prove how you manage and deal with technical vulnerabilities
– and also how you reduce the likelihood for vulnerabilities by restricting software installations
This is normally described in a documented policy, process or procedure.
Patch Management is not mentionied explicitly in one of the controls but should be considered as part of the vulnerability management process.
3.2. NIST CSF
In the NIST CSF, vulnerability management is mainly part of the risk management process and described in several controls within the whole framework. These are described in following functions and subcategories:
The NIST CSF does not only requires you to identify and asses the risk of vulnerabilities like ISO 27001, but also to have tools like vulnerability scanners in place.
As for ISO 27001, Patch Management is not mentioned under one of the controls but should also be considered as part of the Vulnerability Management Procedure.
4. What are typical steps in a Vulnerability Management Process
There are several steps needed to identify or detect, analyze and remediate a vulnerability. The next sections show how to continiously respond to found vulnerabilities and they should be part of a continious vulnerability response process.
4.1. Identify and Detect
The first step in the process is to identify and detect vulnerabilities in your infrastructure or environment. This could be done via automated scans with tools, with the help of penetration tests, security audits or by manually assessing or reviewing CVE databases. vendor information or other resources.
It is good practice to define a scope of assets that should be included in your vulnerability management, like:
– networks and IP ranges that should be scanned (or not scanned)
– URL’s that should be included in web application vulnerability scans
– scope or when penetration tests should be performed
– maybe also if static application security testing (SAST) or source code analysis should be included
After identifying a vulnerability, it should be documented in a common repository or risk map. This enables further analysis and reporting.
You could use the repository from your vulnerability scanner, your incident management tool or just Excel for example. The objective is to be able to assign the vulnerability to corresponding teams (e.g. Server Operating Systems, Network, Application Owners) for further investigations or treatments.
In the analysis phase the first step is to check whether there is any susceptibility and to assess the risk of the detected vulnerability in order to determine the criticality and hence the urgency of the required remediation.
4.3.1. Remediation Analysis
The next step is to find the most appropriate remediation solution. This could be:
– Deploying patches or updates
– Configuration changes
– Correcting insecure code
– Implementing other security measures
– Replace or shutdown the corresponding system or application
If no remediation solution is available, it is also possible to accept the risk based on criticality. But it is best practice, even if no solution is available, to not change the before assessed criticality level.
4.3.2. Decision Board (optional)
For critical vulnerabilities or when the remediation of a vulnerability has a high impact for the business of the organization a board of stakeholders may meet to review the risk, criticality, remediation solution or discuss any other problems.
Any exceptions or deviations should be documented and handled according to the risk associated. These may result from:
– Delay in remediation due to operational constraints
– Inability to remediate a vulnerability due to lack of solution
4.4. Remediation Management Process
After detecting, aggregating and analyzing the risk of a vulnerability the next step is to define a process to remediate the vulnerability by going through different VM Remediation Management steps. This includes the preparation, implementation and monitoring or tracking of the selected remediation solution.
4.4.1 Remediation preparation
Before deploying a remediation solution, it is vital to prepare the necessary activities including:
– Remediation Plan: define a detailed plan, procedure, checklist for remediation
– Packaging: collect patches, updates, software, scripts or tools and prepare your deployment solution
– Testing: test the functionality of a software patch or configuration in a lab, test or staging environment
– Change Management / Request for Change: Prepare a change request
– Rollback procedures: have a fail/fall back procedure in place to recover to a state before implementing the remediation solution
4.4.2 Implementing the remediation solution
The implementation is the actual deployment of the remediation solution to the vulnerable assets. This could be solutions already mentioned above, like deplyoing a patch or doing configuration changes, etc. All steps, activities and changes should be documented.
4.4.3 Remediation Monitoring
This step includes verifying that the solution deployment was successful for the target assets and if the deployment had any impact for the IT infrastructure or on the business processes. It also takes action in case a deployment fails and a rollback to the last stable state is necessary.
4.5. Remediation tracking and control
If the deployment has been performed, the success of the remediation solution is tracked and controlled. This could be done by:
– Manually run a vulnerability scan against the target
– Wait for the next scheduled vulnerability scan
– Manually assess the absence of the vulnerability (via penetration test, tools or scripts)
Once the assessment and remediation are finished it should be considered to prepare a report depending on the criticality of the vulnerability.
The report should not only document the analysis and remediation process but also:
– Lessons learned
– Potential for continuous improvement
– Limitations in the vulnerability detection
– Process inefficiencies
The report could also include possible Key Performance Indicators such as:
– Risk indicators
– Detection capabilities
– Operational indicators: patched systems, failed patches, patching progress
– Process efficiency
Also, your risk map or risk register should be updated in this step.
5. Vulnerability lifecycle and tracking process
When a vulnerability in the IT infrastructure or any information asset has been detected, it is necessary to track the remediation process.
The tracking of a vulnerability is done through a number of steps during the treatment process.
The vulnerability is detected and recorded and it is checked whether the vulnerability is applicable to the infrastructure (meaningfulness check). It is not yet assigned to a vulnerability owner.
A vulnerability can be detected or reported by any person inside or outside of the organization by an “vulnerability identifier” (person).
But usually this is done by specialists who are running vulnerability scans. penetration tests or checks. The “vulnerability coordinator” identifies and then assigns the vulnerability to a “vulnerability owner”.
When the “vulnerability owner” has been identified and notified the owner starts analyzing the vulnerability.
The owner of the vulnerability evaluates the risk and impact, finds affected assets, possible solutions for remediation and stakeholders or responsible persons to deploy the remediation solution. Depending on the impact of the chosen solution for the asset or business process it should be approved by the management.
The solution is deployed to the vulnerable instance by the solution deployer. The solution could be:
-deploying a patch/update
-doing a configuration change
-implement other measures
The deployer confirms the implementation and checks if the deployment had any impact on the systems or business processes.
All stakeholders check if the actual remediation of the vulnerability was successful. It is to be decided if a detailed report should be made or if it is necessary to held a lesson learned meeting.
All steps during the whole process should be tracked and documented in a common repository. This is normally done in the IT Service Management Tool. The tracking of the actual identification, classification and risk analysis could also be done in specialist tools itself, like vulnerability scanner or Security Information Event Management Software (SIEM).
6. Interfaces with other processes
A good vulnerability and patch management process relies heavily on other IT business processes. And mainly on these:
6.1. Asset and Configuration Management
Nearly all IT processes depend on a solid Asset Management and not the other way round. A lot of organizations try to conceal their lack of Asset Management with the help of vulnerability scanners. The assumption is that the scanners will detect all IT assets anyway and give all information about operating system, installed applications and versions. This is kind of true but opens a lot of problems in the end run, because:
– you need to know what assets are critical and want to define what assets to scan and how (e.g. authenticated or leave out some networks)
– you cannot define the risk or impact of a vulnerability, when you don’t know the criticality of the asset (in terms of confidentiality, integrity and availability)
– you cannot assess the criticality without having a list of assets
– You are not able to manually determine whether a vulnerability applies to your organization
Often the remediation of a vulnerability will also require a change of the configuration of the asset. That leads to a Change Management Process.
6.2. Change Management
When configuration changes or the installation of patches are needed this is mostly done according to a Change Management Process. Prior to the change of an asset a change request is needed to proceed with the deployment of the remediation solution.
6.3. Patch Management
Although Patch Management is also part of a Vulnerability Management Process, a separate Patch Management Policy should be in place. Often critical vulnerabilities are patched ad-hoc. But if an update can be installed during a pre-defined maintenance window or patch day these time frames should be defined in a written policy or procedure.
6.4. Software Development Lifecycle
In certain cases, the remediation solution will require the modification of source code and the release of the updated application to production or the provision of a patch for the customers.
There might be more processes involved. For example, if it is determined that the vulnerability has already been exploited, incident management processes, etc., could also be affected.