IT Support

Implementation of Patches & Service Packs

Why is Patch management so important?
Installation followed by neglect was once a fairly common practice when it came to patch management policies - once deployed, many systems were infrequently, or even never, updated. Obviously, this approach is no longer an option. The rise of widespread worms and malicious code targeting known vulnerabilities on unpatched systems, and the resultant downtime and expense they bring, is probably the biggest reason so many organisations are focusing on patch management. Along with these threats, increasing concern around governance and regulatory compliance (e.g. HIPAA, Sarbanes-Oxley) has pushed companies to gain better control and oversight of their information assets. Add to that increasingly interconnected partners and customers and the rise of broadband connections and remote workers, and you have the perfect storm that has thrust patch management to the forefront of many organisations' list of security priorities.

What is the main objective of a Patch management policy?
It's obvious that patch management is a critical issue. What is also clear is the main objective of a patch management programme - to create a consistently configured environment that is secure against known vulnerabilities in operating system and application software. Unfortunately, as with many technology-based problems, good, practical solutions are not as apparent. Managing updates for all the applications and operating system versions used in a small company is fairly complicated, and the situation only becomes more complex when you take into account additional platforms, availability requirements, and remote offices and workers.

Where we come in...
A key component of patch management is the intake and vetting of information regarding both security issues and patch release - you must know which security issues and software updates are relevant to your environment. An organisation needs a point person or team that is responsible for keeping up to date on newly released patches and security issues that affect the systems and applications deployed in its environment - and Signal Networks is that team. We can also take the lead in alerting administrators and users of security issues or updates to the applications and systems they support and use. A comprehensive and accurate asset management system can help determine whether all existing systems are accounted for when researching and processing information on patches and updates.

Patch Prioritisation and Scheduling
Several scheduling guidelines and plans should exist in a comprehensive patch management program. First, a patch cycle must exist that guides the normal application of patches and updates to systems. This cycle does not specifically target security or other critical updates. Instead, this patch cycle is meant to facilitate the application of standard patch releases and updates. This cycle can be time or event based; for example, the schedule can mandate that system updates occur quarterly, or a cycle may be driven by the release of service packs or maintenance releases. In either instance, modifications and customizations can and should be made based on availability requirements, system criticality, and available resources.

The second scheduling plan deals more with critical security and functionality patches and updates. This plan helps an organisation deal with the prioritisation and scheduling of updates that, by their nature, must be deployed in a more immediate fashion. A number of factors are routinely considered when determining patch priority and scheduling urgency. Vendor-reported criticality (e.g. high, medium, low) is a key input for calculating a patch's significance and priority, as is the existence of a known exploit or other malicious code that uses the vulnerability being patched as an attack vector. Other factors that should be taken into account when scheduling and prioritising patches are system criticality (e.g. the relative importance of the applications and data the system supports to the overall business) and system exposure (e.g. DMZ systems vs. internal file servers vs. client workstations).

Change Management
Change management is vital to every stage of the patch management process. As with all system modifications, patches and updates must be performed and tracked through the change management system. It is highly unlikely that an enterprise-scale patch management program can be successful without proper integration with the change management system and organisation.

Like any environmental changes, patch application plans submitted through change management must have associated contingency and backout plans. What are the recovery plans if something goes wrong during or as a result of the application of a patch or update? Also, information on risk mitigation should be included in the change management solution. For example, how are desktop patches going to be phased and scheduled to prevent mass outages and support desk overload? Monitoring and acceptance plans should also be included in the change management process. How will updates be certified as successful? There should be specific milestones and acceptance criteria to guide the verification of the patches' success and to allow for the closure of the update in the change management system (e.g. no reported issues within a week of patch application).

Patch Installation and Deployment
The deployment phase of the patch management process tends to be where administrators and engineers have the most experience. Installation and deployment is where the actual work of applying patches and updates to production systems occurs. And, while this stage is the most visible to the organisation as a whole, the effort expended throughout the entire patch management process is what dictates the overall success of a given deployment and the patch management program in total.

The most important technical factor affecting patch deployment is likely to be the choice of tools used. One key distinction between patch tools is a common system development issue - to buy or to build? Historically, many organisations have created custom solutions using scripting languages combined with available platform tools to distribute and apply patches. As the industry has matured and the need for comprehensive and automated updates has increased, many tools have become available to help manage the patch application process. These tools are often classified as being either agent-based or agentless systems, depending on whether they rely on software being installed on the target systems that are to be patched. Additionally, many existing system management tools have the capability to perform software and system updates. The correct choice of patch management tools for any organisation depends on a number of issues, including: the number of platforms supported, the number of systems to be patched, existing expertise and personnel involved, and the availability of existing system management tools.

Audit and Assessment
Regular audit and assessment helps gauge the success and extent of patch management efforts. In this phase of the patch management program, you are essentially trying to answer two questions:

The audit and assessment component will help answer these questions, but there are dependencies. Two critical success factors are accurate and effective asset and host management. Often, these related goals of asset and host management are addressed by a single product, such as with Tivoli, Unicenter, or SMS. The major requirement for any asset management system is the ability to accurately track deployed hardware and software throughout the enterprise, including remote users and office locations. Ideally, host management software will allow the administrator to generate reports (e.g. all clients without a given hot fix, all versions of particular applications) that will be used to drive the effort toward consistent installation of patches and updates across the organisation.

System discovery and auditing are also components of the audit and assessment process. While asset and host management systems can help you administer and report on known systems, there are likely a number of systems that have been either unknowingly or intentionally excluded from inventory databases and management infrastructures. System discovery tools can help uncover these systems and assist in bringing them under the umbrella of formal system management and patch compliance. Organsations typically use either their own discovery and assessment mechanisms or one of the various managed vulnerability assessment tools. Regardless of the tools used, the goal is to discover unknown systems within your environment and assess their compliance with organisation update and configuration guidelines.

Consistency and Compliance
While the audit and assessment element of your patch management program will help identify systems that are out of compliance with your organisational guidelines, additional work is required to reduce non-compliance. Your audit and assessment efforts can be considered 'after the fact' evaluation of compliance, since the systems being evaluated will typically be already deployed into production. To supplement post-implementation assessment, controls should be in place to ensure that newly deployed and rebuilt systems are up to spec with regard to patch levels.

System build tools and guidelines are the primary enforcement means of ensuring compliance with patch requirements at installation time. As new patches are approved and deployed, build images and scripts should be updated so that all newly built systems are appropriately patched, and associated build documentation should be updated to reflect these changes. In addition to updates to build tools and documentation, operational procedures must exist to facilitate ongoing compliance of newly built systems. If an engineering team typically builds servers (e.g. with the base operating system and applications) and a separate operations team then assumes management of the system, a process must exist to funnel operational changes back to the build and engineering stage of the system lifecycle. These modifications are most ideally and suitably handled via an enterprise-wide change management system. Any new patches and updates that are approved and installed by operations should also be integrated by the engineering team into new builds, with the change management system providing both an appropriate audit trail and suitable procedural guidelines for this implementation.

Back to IT Support