The final part of this series explains how to complete the verification and review steps of the security patch management procedure. These last two phases are just as important as security patch testing and deployment; however, verification and review are mainly driven by the procedure instead of the patch.
Verify patch implementation
The intricacies of software installation compel the separation of the deployment and verification procedures. During deployment, success or failure is judged based on feedback from the security patch management tool. The verification process involves checking the related files, binary versions and registry settings to confirm the patch has taken effect. Patch verification must use methods that check for the specific characteristics of the patch. The verification process is primarily conducted by the tool, unless the tool is not capable of doing so, then it must be done manually.
The patch management tool used to deploy the security patch needs to have the ability to monitor the patched systems after deployment. It should also verify that the security patch was properly installed. If the tool is unable to do so, the organization needs to create a manual method or sub-procedure to complete the task. The tool should also keep track of which systems have and have not been patched. If a system file or application has changed and causes the system to become vulnerable again, the tool should flag the system and the patch should be re-applied.
Review patch status
The change control procedure -- be it a tool, ticket or form -- should be updated as each step is completed. Also, a report should be generated to record the status of each patch. These reports can be Web-based and derived from the patch management tool, or from the change management system in use within the organization. The reports are used in the review phase and should be distributed to the appropriate staff, such as the patch management team, IT personnel, etc.
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
- 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
- Reporting effectiveness
Key Performance Indicators (KPIs) should be developed for the patch management procedure. KPIs enable the organization to measure the success of the patch management initiatives and gauge the results. KPIs for patch management include:
|
Metric
|
Description
|
Rationale
|
|
Number of patches that failed the quality assurance testing
|
Number of patches that failed the quality assurance testing in the test environment
|
Indicates possible poor planning or possible problems with the development procedure
|
|
Number of patches that resulted in an incident ticket being generated
|
Failed implementation of a patch that impacted user operation
|
Indicates possible poor planning or a problem with testing and quality assurance procedures
|
|
Number of successful patch implementation versus the number of unsuccessful patch implementations
|
Provides an indication of how many new patches, on average, were implemented successfully
|
Indicates possible poor planning or a problem with testing and quality assurance procedures
|
The patch management team or those responsible for patch management, should regularly analyze the reports and use the information from them and the KPIs 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 is then used to update the patch management procedure on a regular basis to ensure its accuracy, effectiveness and ability to protect the organization's assets. Completing this last phase of the procedure ensures the organization's patch management initiative is a proactive one.
Step by Step: Best practices for security patch management
Introduction
How to prepare for security patch testing
Security patch testing and deployment phase
Security patch validation and verification
ABOUT THE AUTHOR:
|
Felicia Nicastro, CISSP, CHSP, ISSMP is a Principal Consultant with International Network Services (INS), with over seven years in the information security field. Felicia's areas of expertise include security policies and procedures, security assessments and security architecture planning, design, implementation and operation. Felicia has also authored a book on patch management, titled Curing the Patch Management Headache, which was released in February 2005.
|
|
