In the previous issue of this article we looked at the SABSA Business Attribute ‘Risk Managed’, taking the very highest level ‘helicopter view’. In this issue we shall examine a detailed technical example – looking from the bottom up, rather than from the top down.
Software patching is a standard security measure for maintaining the integrity of IT systems, and hence the business functionality that they perform and the business goals and success factors that they support. It is a conventional ‘control strategy’. We should keep our systems patching up to date. Simple! Or is it?
The primary concern of patching is that there are vulnerabilities in complex software systems that become known as exploits for hacking and malware attacks. Software vendors issue patches and system managers apply the patches. However, there are many more aspects of patch management that bring more complex, unintended, incidental threats and vulnerabilities and therefore put the business at risk.
The standard approach is based up on the assumption that the patches will work perfectly. This is known from experience not to be the case. A patch is a software modification to fix an original flaw in a program, and so it is just another piece of code to be deployed and ‘inserted’ into the software. It will often delete previous code and previous parameter settings, over-writing them with new stuff. In a complex operating system environment such a change will often touch many parts of the system, parts that are shared with other applications that have a dependency on OS functionality. How will these other applications be affected? Hmmm – now we see that there are potential uncertainties here that may have been overlooked.
This means that patch management is not just a simple exercise in applying the patches. It needs an end-to-end process that takes account of the other incidental risks. Typically there will be hundreds, even tens of thousands of platforms to be patched. The patch management process should begin with creating a state of ‘patch-readiness’, meaning having the process itself in place and tested for it’s own suitability. Some of the key steps to be incorporated into the process should include:
- Make the patch management process an integral sub-process of business continuity management. Ensure that patch management will enable business and not hinder it.
- Assess the business criticality of IT systems so that priority in patching can be decided based on critical need.
- Ensure good vulnerability intelligence from CERT bulletins and the like, so that zero-day attacks can be identified and likely consequences assessed. This is an essential aspect of patch prioritisation – which ones should be applied first and what sequence of patches is the best. Some at least will be recursive patches – patches on patches.
- Test each patch on a test platform to assess its effects on overall system performance. Assess the risks of patch failure.
- Always develop a regression plan before applying any patch in a live production environment. This may require having a disk image of the unpatched state, because many patches are irreversible once applied.
- The regression plan should also be tested thoroughly to ensure that it would work if needed.
- Roll out the patches in a systematic way according to the priorities identified and monitor the impacts on live production systems in case the patch testing has failed.
- Give careful thought to the patching of BYOD environments. This means considering the very architecture used to enable BYOD. We shall address this topic in more detail in the next article in this series, to be called ‘BYOD Enabled’, so watch this space.
The SABSA approach requires us to consider all aspects of risk from a business perspective, not just applying controls in a blind, uninformed fashion. Far too often the application of security controls is done without this type of holistic consideration.