With so many software patches being released, can the panel offer any advice on how to manage what has become another burden in my already large workload?
Suppliers should be made responsible for patches
Roger Marshall, Elite
This is a growing problem and it is reasonable to ask why this should happen, considering the age and apparent maturity of the software industry.
Do suppliers want to put us off using their products because of the high cost of ownership? Are they in such a competitive race to bring out new features that they can't be tested properly before release? Or are we such a pathetically gullible set of consumers that we do not even examine a supplier's record before buying?
All these factors play a part, and all serve to diminish the reputation of IT in organisations. The only slight mitigation for suppliers is that they have genuinely been taken by surprise by the growing number and range of security threats that need to be considered when designing products.
As users, we should ensure that suppliers tell us honestly whether patches are obligatory or advisory and what risks are being taken by not applying them.
We should insist that suppliers maintain support for older, unpatched versions of their products if, having assessed the risks, we choose to continue using them. It should be as easy as possible to apply patches by designing "patchibility" into products.
Just imagine if this were the car industry. The manufacturer tells you there is a fault in your new car, supplies you with the replacement part, but tells you to fit it yourself rather than making an appointment with a dealer who will do it for free. Why as consumers of software do we accept such nonsense?
Is security compromised by not patching?
David Hughes, Deloitte and Touche
One area of IT management particularly susceptible to patch frenzy is security. Keeping hardware devices, operating systems and off-the-shelf applications current and secure is an enormous task for security managers and overworked system administrators, yet it is essential if key information assets are to remain secure.
Considerations to give to patches include:
- Do you need the patch? Risk management is paramount in the decision to patch or not to. How hostile is the threat? Is the fix for a local or remote security vulnerability? Do you have adequate physical security to rebuff an internal threat? How trusted is the environment in which the vulnerable system resides?
- Rather than apply a patch, would it be better to wait until you deploy the next service pack? Can you mitigate the risk another way, for example, by turning off a service, changing firewall rules or increasing intrusion detection activities?
- If you decide you need to patch, can several patches be tested together to reduce the project and testing burden? The only downside is that if something arises during testing, it may take more time to work out which patch is at fault. Ideally, a mirrored test environment, budget permitting, can highlight any issues new software patches may bring to the production environment.
- Centralised ownership, effective co-ordination and current documentation are vital to ensure the build and patch level complies with the company's security policy, which should be uniform across an organisation, including the disaster recovery environment.
The general rule is: patch in haste and repent at leisure. If you can spare the time to monitor the communities relevant to your environment, you will be better able to make an informed decision. Anything to increase your chances of following best practice for your network solution is generally a safe bet.
The only solution is to use older, reliable software
Robin Laidlaw, president, CW500 Club
There are many pressures on suppliers to get their products to market quickly - sometimes too quickly.
Software that may have previously been subject to extensive de-bugging and stress testing, often with an extended pilot, entails timescales which either the client, in their wish to gain a competitive edge, or the supplier, to get it to market as quickly as possible, find unacceptable.
Products come out too fast and patches result. Add to this the sophistication of the hacker and the problem is exacerbated.
Realistically, you have to plan and budget; an ignored patch requirement leaves you with a problem. Try to get your users to understand and share awareness that in today's rapidly changing environment, this is a way of life. It seems the only way to reduce (and even then not totally eliminate) patching is to use proven software where most of the problems have been ironed out. But can your business afford to lag behind in the market as a result?
Consider any impact on support agreements
Neil Roden, NCC Group
The apparent increase in software patches is mainly because of improved security measures and the continued evolution of applications. Any implemented approach to an upgrade or patch schedule must establish the benefit of maintaining the changes.
A key consideration is the impact of not adding a patch. For a developed application, this could immediately invalidate a software support agreement. For a finance application, critical legislation or taxation considerations may be omitted.
General "bug fixes" may cause significant operational problems or produce long-term issues, either of which may not be immediately apparent. In all cases, the rule must be to review the benefits delivered by the patch against the impact of not upgrading.
Where the time constraints on an operation from implementing a patch are unduly heavy, thin client environments or other application server strategies should be considered. Patches and upgrades can then be performed in a controlled manner at a single point, but cost-benefit considerations should always apply.
Computer Weekly has put together a panel of experts. You can draw on their specialist knowledge to solve a problem. E-mail your questions (or your own solutions to this or the next question) to firstname.lastname@example.org
NCC Group www.nccglobal.co.uk
Deloitte &Touche www.deloitte.co.uk
Cranfield School of Management www.cranfield.ac.uk/som
Computer Weekly 500 Club www.cw500.co.uk
Henley Management College www.henleymc.ac.uk
British Computer Society www.bcs.org.uk/elite
The Infrastructure Forum www.tif.co.uk
Dominic Barrow www.dominicbarrow.com
We have outsourced IT to three or four best-of-breed providers and have spent a lot of time defining who is responsible for what. How can I further entice these companies to work together?