Lionel Mourer has more than 10 years experience in strategic and operational consulting on security for large organizations. He joined Bull in 2004 to set up and develop the IT security consulting and audit unit. Over and above his mission to develop the offer and manage the team, Lionel is involved in a large number of pre-sales activities and also contributes to consulting assignments and complex projects.
“Bug, did you say bug?!…”
Before going any further, let’s make it very clear what we’re talking about. This is not about software or system upgrades… nor versioning, or releases featuring new functionality, even though there is some similarity with patch management in the way these updates are treated. Before looking at other issues, I would like to examine security weaknesses themselves and their associated corrective actions. There are effectively four key types of security risk, as described in Table 1 below. In the context of patch management, we are mainly interested in bugs. Our aim is to counter an area of weakness using a suitable ‘patch’ as supplied by software publishers and IT makers.
Table 1 – Types of security risk
|Type of breaches
||How often does it need to be checked?
||Inexpert configuration of a particular item
||Badly positioned ACLs
|Administrative and human errors
||Nobody is perfect…
||Password written on paper
||Linked to the application, operating system or network protocol being used
||For example, for IP: non-authenticated IP address, possible fragmentation of bundles etc.
||As per evolution of network protocols, etc.
||Breaches identified in a particular component resulting from a development error
||Cf. Internet sites and specialized distribution lists
||As per evolution of operating systems and applications
The number of bugs is currently growing exponentially. To grasp this fully, you only have to look at Figure 1 below, which shows the increase in security breaches reported during the course of the last 11 years, covering the whole spectrum of OS and application software. And the trend is not showing any signs of diminishing; 1,600 security breaches have already been recorded during the first quarter of 2006!
It’s interesting to note that many discovered breaches involved not only the proprietary world, but also the ‘Open Source’ world. However, most of the attacks on record today are still aimed at the Microsoft range of operating systems.
Figure 1 – Growth in the number of security breaches discovered since 1995
Another important indicator in the appearance of bugs is speed. There are two angles from which to approach this factor:
• The speed with which ‘exploits’ (the name given to pieces of malicious code created by hackers designed to take advantage of a security breach in order to run) become available has decreased dramatically in the last few years (cf. Figure 2 below);
• The speed of propagation, in other words the time it takes for an ‘exploit’ to do the rounds, (i.e. visit the ‘full circle of the world’s servers’) has also increased radically (see Figure 3 below).
Figure 2 – Propagation times for a series of worms between 2001 and 2003
Figure 3 – Timescale for an ‘exploit’ to be ‘made available’
Finally, the nature of attacks that exploit security breaches that are uncovered has also changed:
• Historically, the ‘exploit’ often aimed at disrupting a (simple or distributed) service
• Today, increasing ‘professionalism’ and financial incentives go hand in hand with a trend for more sophisticated ‘Trojan horse’ type code, destined for key-logging, backdoor or other types of stealth operations.
So, having explored these different aspects of the theory, we now need to position patch management more precisely. To do this, let’s look at the three phases involved in the process:
• The lead-time before patches are put in place
• During deployment
• Following installation of corrective patches.
Finally, we will look at some additional considerations that are important in their own way, and finish this review with a conclusion.
Sometimes the fall-out from putting a patch in place can work both ways: patches themselves are not always problem-free and, in seeking to put them into production too quickly, the cure can turn out to be worse than the original problem!
In the first place, it is important that the installed IT base is as homogeneous as possible. Indeed, the more homogeneous the park is, the simpler it will be to distribute patches. In addition, some kind of pre-production or test environment will also be in place, for non-regression testing before applying patches in a live production environment.
Next, procedures have to be written, implemented and maintained to enable:
• Security watch, to discover what breaches have recently come to light, whether they are applicable to your organization, etc. This enables decisions to be taken on the basis of appropriate and verified information
• The need to qualify the information for the specific IS involved: this enables the actual level of risk to be assessed, and gets round the need to depend on the publisher’s own evaluations
• Identification of suitable patches depending on specific needs of the business
• Estimation and analysis of risks and impacts in the case where patches are not applied.
Then, of course, comes the moment when the patches you want to deploy have to be tested. Effectively, to work out whether or not it is actually necessary to install a particular patch, several factors should be borne in mind:
• The impact on the operating system or application software concerned (loss of functionality, need to reboot, etc);
• The wider impact on business processes.
Only tests that are carried out on a platform closely matching the actual production environment will identify any likely side effects of installing the patch. Once these ‘non-regressive’ tests have been completed, the decision whether or not to deploy a patch can be taken.
Finally, for complete peace of mind, the decision-making procedures must be cross-checked, while respecting each member of staff’s areas of responsibility.
Putting patches in place
Actual deployment of patches is often achieved using a patch management tool. There are many such tools on the market, and we are not going to try and compare them here. The choice of tool must be made depending on the platforms used (OS, application software…), but also depending on how they are used (fixed workstations, mobile computing...) and the way the business is organized (whether or not it is highly centralized).
Nevertheless, deployment is actually controlled by the host organization to a greater or lesser extent, depending on the method of distribution being used:
• Deployment controlled via remote distribution tools that send out upstream pre-configured software bundles
• Deployment partly controlled by the company, with target platforms coming to look for the appropriate software bundles independently and at different times
• Deployment that is not controlled to any great extent by the company, since it is the user who independently seeks patches, on software publishers’ websites for example.
Finally, during deployment, it is essential to ensure the good progress of the deployment, any rejects or failures, side effects and so on.
The procedures that needed to be implemented after patches have been applied include:
• Monitoring of patch updates, to keep track of any developments to the patch itself.
• Updating the inventory of the installed IT base, for the application of subsequent patches.
Finally, it is important that the results obtained are communicated, so it’s clear when a job has been well done! This can be communicated via management control panels to a wide range of groups including:
• IT management, for monitoring and assessing the scale of the installed computer base
• Information systems security management, to enable on-going assessment of security levels and risk analysis updates
• General management, to enable them to gauge alignment with rules and/or regulations.
A few additional thoughts
When implementing patch management plans, organizations need to ask themselves a number of other questions, to ensure that their information systems, and the staff working in and around them, are fully protected.
With the increasing importance of mobility in companies, new challenges are appearing in relation to updating (this applies equally to anti-virus software, for example). How, for example, should you go about updating a portable PC used by someone who is working away from his usual site for several weeks, and who is connected to the company network via the Internet? And how are PDAs and other smartphones handled? These points will have to be catered for within the company’s information system.
Some systems cannot be taken into account: for example, ‘turnkey’ type: platforms dedicated to controlling manufacturing processes, platforms dedicated to specific business applications, applications or modules re-used by other applications in OEM products, ‘black boxes’ appliances, etc. In these cases, the publisher, manufacturer or even the systems integrator is directly responsible. But how much confidence do you have in them?
ISVs generally publish regular security patches (for example, once a month). However, sometimes they are happy to wait before issuing them. So what’s going to happen in the following situations?
• A patch fails to fix a security breach, but instead only intercepts calls seeking to exploit a weakness (in this instance the weakness remains completely unaffected)?
• An ‘unauthorised’ or ‘unofficial’ patch corrects the problem a risk that has been discovered independently, before the publisher can send out the official patch?
• A zero-day attack: an ‘exploit’ appears on the scene at exactly the same time as weakness is announced?
• A patch is only published several months after the discovery of a security risk?
And ultimately, the rather tricky problem remains, of how to manage responsibilities:
• Over and above the technical aspects, who is responsible for applying patches? And who is held responsible for an attack if patches are not applied?
• In the case of outsourcing, which party is responsible for implementing patches: the customer or the outsourcing provider?
Good practice procedures (for example ITIL, COBIT or ISO 27000) can help in the allocation of these responsibilities. But on the whole, it is just important that it is done, whether internally through business procedures or via contracts (in the case of outsourcing).
Figure 4 below shows that patch management is an area where numerous organizations still have to make a lot of progress.
Figure 4 – Time elapsing between distribution of a patch and its application
What’s more, instead of patching after the event, isn’t it so much better to install a system properly from the start and banish default installations (OS and software applications optimization)? Finally, rather than preserving old operating systems or software applications isn’t it better, surely, to move on to newer versions?
Nevertheless, while it is easy to say, “we must patch,” the implementation of a comprehensive and coherent update for security patches remains a real project in itself, and one that must be managed as such.
To find out more
View the presentations recently given at the CUBE (Bull European User Group) Patch Management seminar on June 8 in France (French version)
- Patch Management challenges: managing patches, alternatives and better practices
Lionel Mourer, Director IS Security Consulting and Audit unit, Bull
- Patch Management in a Linux world: view of the whole and perspectives
Pierre Fumery, Head of the Linux Competence Center, Bull
- Patch Management in the Bull Support range
Linux Competence Center, Bull
- Industrial management of security patches for PC installed bases: some possible strategies.
Louis-Marie Fouchard, Director of Services, Bull Evidian
- Learning from experience and best practices in patch management
Eric Grospeiller, Head of Security, ANPE (French National Employment Agency).
Should you like to find out more about how Bull could advise you and support you in handling patch management for all your working environments and information systems? Contact us >>