February 7, 2012 | Written by: Turgut Aslan
Share this post:
One often contracted and therefore most important IT security process is about global security patch management. Because the cloud computing offering is about automation, standardization, and optimization, how does it match to the customer needs of notification, change management, agreed service level agreements (SLAs) for system and application availability, and commercial account risk management? This blog entry takes a step-by-step walkthrough approach to analyze process requirements against the cloud implementation. Identified potential gaps and issues are to be addressed in policy updates and in an effective risk management.
The security patch management process
Security patch management is a crucial task to be performed in all enterprises. This is needed because of the fact that no shipped software is free of errors and vulnerabilities, which can and in fact are being exploited daily. Because both development cycles of software become rather shorter than longer, often generating more vulnerabilities, and the number of potential hackers of software worldwide is growing, it makes a lot of sense to create a robust security patch management process and a related implementation procedure to mitigate the risk of vulnerabilities being exploited.
A security patch management process should address at minimum the following items:
- Security vulnerability detection and evaluation by the vendor
- Subscription mechanism to vendor security patch notifications
- Severity assessment of the security patch by the receiving enterprise using that software
- Applicability assessment of the security patch on target systems
- Opening of tracking records in case of patch applicability
- Customer notification of applicable security patches, if contracted
- Change management
- Successful security patch application verification
- Issue and risk management in case of unexpected troubles or conflicting actions
- Closure of tracking records with all auditable artefacts
The potential for automation
Some of the steps in the outlined process above are well suited for automation in cloud and traditional IT environment implementations, where others require human interaction:
The discovery and evaluation of security vulnerabilities and their re-evaluation, including the severity assessments, are currently tasks for human beings. Software testing may identify many shortcomings, errors, and vulnerabilities. Nevertheless there will be remaining, undiscovered vulnerabilities also. Even after years, software errors are often detected and fixed by vendors.
The automation part starts with notifications. When a vulnerability is detected, a severity assessment of it is done, a security patch or an interim solution is provided and this information is entered into a system; then, sending out automated email notifications to predefined accounts is straightforward.
Another area of automation is the security patch applicability part. If there is an up-to-date software inventory of a company with all software versions, releases, and maintenance levels in production, automatic matching of incoming security vulnerability information can be performed against the software inventory.
The creation of tracking records and their assignment to the predefined resolver groups, in case of matching, is another step that can be automated. If some pre-agreed change windows are available, the part with change record creation, change approval, and change implementation can be automated also. Finally, automated verification of the successful implementation of security patches is possible in addition to audit-proof documentation of this.
A second area where automation will fail is the risk and issue management part. Human interaction is needed when unexpected errors occur. This is also valid when other conflicting actions are taken in an IT environment such as software upgrades or physical changes. Critical systems and applications in production with strict SLAs to be delivered will often need special consideration – that is, they will not be part of the automated security patch management solution.
Installing security patches on desktop or laptop computers and on servers is something that can be automated today already to a very large extent, if certain preconditions such as granting automated security patch download and risk acceptances for automated execution of downloads, and allowing automated reboots are given. This potential for full security patch management automation can and is being used in clouds, decreasing human interaction and therefore maintenance costs significantly.