CISSP Implement and Support Patch and Vulnerability Management in this having security manager must ensure that the software, networks, and equipment of the organization are protected against attacks and that known vulnerabilities are patched. While the security manager will rarely be responsible for the operation of the patch management program, it may be the responsibility of the security manager to design and implement it—perhaps based on some of the tools available to manage patching and updates. This must be linked to the asset management process and the configuration management database to ensure that all assets are identified and will be included in any patches that are released.
When a vulnerability assessment or audit has detected an unpatched system, this reveals a fault in the patch management process. While it is important to install the missing patches, the most important matter is to determine why the system was not patched.
Something went wrong—all patches should have been applied to each system, and a missing patch indicates a problem in the underlying process. Thorough investigation of the incident may be able to identify the root cause of the problem, and steps should be taken to ensure that this does not happen again.
A patch management program requires oversight to ensure that patches are applied in a timely manner. The security manager should determine the key performance indicator (KPI) for patch management that specifies how quickly a patch will/must be applied to a system from the day that the patch is available until it is deployed. To do this, there needs to be a process for identifying which patches are available from various vendors and then testing the patches to ensure that they will work within the organization’s environment.
There is a double-sided risk here. Some patches do not work and, even worse, may disable systems or other business functions. Therefore, some organizations delay the implementation of a patch for a short time until they know whether the patch has caused problems for other organizations that have already deployed it. Even this may not work, however, since the networks and architecture of other organizations may be substantially different from the target environment. Even worse, a delay in deploying the patch may leave the organization vulnerable to an attack that is designed to exploit the vulnerability that was addressed by the patch. In this situation, the organization may be subject to liability for the delay.
When a vendor releases a patch, it provides a source of information for bad actors. The criminal community may reverse engineer the patch to discover the vulnerability that it was meant to address. This allows them to write an exploit to take advantage of that patch that can be used against organizations or individuals who are late in deploying the patch.
Regulations and contractual requirements also influence the scheduling of patches.
Some contractual agreements (such as PCI-DSS) may require security patches to be deployed within a set time frame. Insurance policies and vendor warranties may also be void if patches are not applied in a timely manner. The security manager must investigate what regulations or contractual requirements are in place to ensure that the patch management process meets the required time frames.
Once new patches have been identified, the patch management process must involve testing, approving, and scheduling the rollout of the patches. Ideally, it is best to test a patch on an isolated test network first, before scheduling a rollout to the entire organization. The test environment should have sufficient representative samples of all operational systems and devices in the production environment to best estimate the patch’s efficacy and impact. Testing should review the potential impact on interoperating systems, as well as standalone/individual units. Patching may affect proprietary systems in ways the vendor/issuer did not anticipate. It is also crucial to perform a backup of the environment before applying a patch to have the capability to roll back to the last known good configuration in case the patch has substantial detrimental effects.
Scheduling the rollout of the patch may also be a challenge because many systems must operate 24 hours per day, and any outage could be expensive and can impact business operations. The patch management process must work together with management to schedule a patch at a convenient time or to roll out patches to different business units in sequence to reduce the risk of total outage.
Vulnerability management is addressed primarily in Chapter 6, “Security Assessment and Testing.” However, from an IT Operations perspective, the security manager has to work with the IT department to perform and resolve any issues found during a vulnerability assessment according to the prioritization and severity of the vulnerabilities found.
The vulnerability management process must also mandate resolution for all vulnerabilities detected (even if the resolution is just documenting a “risk accepted” decision); it is surprising how many organizations will perform a second or third vulnerability assessment before they have even fixed the items found in the previous test. Vulnerabilities do not fix themselves, and performing a vulnerability assessment without being committed to fixing what is found just creates an illusion of security management without actually making a difference.
