Imagine that you are the IT Director of a large retail bank with an active and highly visible Internet banking service. Driving into the office, half-listening to the radio news, you hear your bank’s name being announced. Immediately followed by the words "hacker," "massive system failure" and "identity theft."

Whilst reeling from this, you recall an email from last week concerning a patch that needed to be applied to your web servers. Two thoughts pass through your mind: "Surely those patches went in OK," followed swiftly by "Should I bother driving to the office?"

According to Gartner, patches are defined as "a software fix made or distributed in a quick and expedient way – typically, via a separate piece of software that users can download and run to modify an application already installed on their computers." 

Do not, however, let the words "fix...in a quick and expedient way..." lead you to think that patches are insignificant.  They are the first line of defense against many types of exposure – primarily security loopholes – in vendor-supplied applications and operating software. 

Neither does it imply that patches can be distributed with a cheery whistle and the press of a button on a management console.  The IT estate of most organizations today is a complex and delicate mix of components and dependencies.  Unfortunately, many IT organizations are ill prepared to keep pace.  It seems that many organizations still manage patches in a rudimentary and inconsistent way.  In order to arrive at the desired outcome – the successful and timely deployment of the right patches on the right computers – an organization must know in detail the current state of its IT infrastructure and the processes it must follow in order to make the change.

What's there? What state is it in?

IT organizations that desire to implement effective patch management need an accurate and immediate assessment of their IT infrastructure.  Typical questions include:
· Do we have a list of all servers running an operating system below a certain revision level?
· Is there an increase in incidents reported to the service desk about specific symptoms or outages?
· Does my hardware or software configuration match exposures identified by my technology vendors?

For most organizations, these questions are only the tip of the iceberg.  There are many more because change is a constant for IT; yet, how can any human being keep up with the dynamic pace of change?

IT professionals must maintain a database that is detailed and updated enough to provide accurate and up-to-the-minute reports on the current state of the IT infrastructure, and they rely on a high degree of automation to ensure data integrity.

Discovery tools provide that level of automation. These tools detect and collect a wide range of detailed information about the network and computing resources in an organization's IT infrastructure.  Loaded into the appropriate repository, that information can support a wide range of service management activities of which patch management is a critical subset.

Very few organizations maintain an IT estate consisting of only one type of hardware. An effective discovery tool must be agnostic – able to collect data across a wide range of different platforms.

How can I ensure that rollout will be successful?

Implementing the right processes is another critical component for effective patch management practice. Although the automated discovery of the IT estate and distribution of patches are essential, an organization that relies solely on tools to do the job is in a state of dangerous denial.  To work most effectively, the tools must be an integral part of a mature service management solution.

A number of activities must be carefully managed.  As with discovery, appropriate automation brings significant benefits. Some examples are:
· Risk and cost assessment for both the business and the IT estate.
· Priorities activities based upon those assessments.
· Collect, validate and maintain configuration data.
· Identify the parts of the infrastructure that are at risk. Isolate them.
· Obtain the patches from a trusted source.
· Identify and repair or roll-back any damage.
· Physical deployment of patches.
· Testing and sign-off of the changes.

Patch management cannot be treated as an exercise in isolation. It is important to identify and integrate with a number of other activities to ensure that the customer or user receives the right quality and consistency of IT services. Some might be:
· Integration with configuration management / IT asset management -- It is highly desirable to feed data from an existing configuration repository, and important to ensure that it is maintained during a patch deployment. Failure to do so will lead to fragmented and badly managed knowledge of the IT infrastructure.
· Correlation with the service desk -- Identifying and responding appropriately to reported incidents can significantly reduce the scope and impact of any exposure.
· Release management -- A best practice discipline (part of the ITIL library) which deals with the bigger picture of managing the deployment of software across the estate. Any patch management activities should feed back into the DSL (Definitive Software Library – the subset of ITIL configuration data that applies to software assets).
· Work order / change activity -- Deploying software patches to an organization's operational infrastructure constitutes a significant change activity. It is very important to ensure that it adheres to the defined standards for Changes or Emergency Changes. Additionally, there may be specific instances where deploying a patch cannot be fully automated. Any manual activity needs to be coordinated properly.
· Service level agreement (SLA) impact -- Inadequate patch management can have a serious impact on the levels of IT service promised to business users. This issue is particularly significant for outsourcers and service providers, where such failures can lead to significant penalties.
· Potential software licensing implications – for example, it may be necessary to have a current maintenance agreement with a software vendor in order to apply patches legally.

This approach will permit a more proactive and consistent approach to patch management.

Conclusion

The adoption of comprehensive discovery tools and mature best practice processes significantly improves the effectiveness of an organization's patch management efforts, which in turn improves its service management capabilities. To be successful, the technology and processes adopted should bear a number of objectives in mind. They should be as automated as possible. They need to be agnostic – that is, they should work equally well on all of the hardware and software platforms in that organization's operational environment. In a dynamic and constantly evolving IT environment, they must be adaptive. And finally they must be able to provide the highest level of analytical data, both for technicians and management, to ensure that patches can be deployed quickly and accurately with minimal impact to the business.

David D'Agostino is product marketing manager EMEA, Peregrine Systems