Security verification and validation are important steps in the security patch management lifecycle. These processes...
help determine the effectiveness of a patch by exposing vulnerabilities that could affect the security of an organization's assets. Security verification and validation are just as important as security patch testing and deployment; however, verification and review are mainly driven by the procedure rather than the patch.
Verify patch implementation
Due to the intricacies of software installation, a separation exists between the deployment and verification procedures. During deployment, success or failure is judged based on feedback from the security patch management tool or service. The verification process, therefore, involves checking related files, binary versions and registry settings to confirm the patch has taken effect. Patch verification must use methods that check for specific characteristics of the patch. The verification process is primarily handled by the tool. If the tool is not capable of doing so, the process must be done manually. A vulnerability scanner can be used to check that vulnerabilities mitigated by the patch are no longer present or exploitable.
The patch management tool used to deploy the security patch needs to have the ability to monitor patched systems after deployment. It should also verify that the security patch was properly installed and identify any post-deployment issues by running smoke tests. If the tool is unable to do so, the organization needs to create a manual method or subprocedure to complete the task. The tool should also keep track of the systems that have been patched.
Review patch status
The change control procedure -- be it a tool, ticket or form -- should be updated as each step is completed. A report should also be generated to record the status of each patch. These reports can be generated by the patch management tool or from the change management system within the organization. The reports are used in the review phase and should be distributed to the appropriate staff, including the patch management team and IT personnel.
As part of the report, the patch management team should receive the following information:
- number of systems successfully patched;
- number of systems that failed patching or were unsuccessfully patched;
- summary indicating why the failures occurred and the follow-up steps;
- summary of reboot request reporting;
- number of systems that were omitted from the process, which is typically provided within the accompanying exception report;
- summary indicating why these systems were omitted from the process and any temporary workarounds implemented; and
- summary of reporting effectiveness.
KPIs should be developed for the patch management procedure. KPIs enable an organization to measure the success of the patch management initiatives and its effectiveness and efficiency. KPIs for patch management include the following:
Those responsible for patch management should regularly analyze the reports and use the information and the KPIs to assess the effectiveness of their remediation and response processes to answer the following questions:
- How effective is the process?
- If there is a high rate of failure, what are the contributing factors?
- Where can improvements to the patch management procedure be made?
This information establishes the baseline performance of the patch management procedure, which can then be used to expose the accuracy and effectiveness of the patch against attacks. Completing this last phase of the procedure ensures an organization's patch management initiative is proactive.