You wanna cry? Been staring at a ransomware screen? The Attributer hopes not, but we all know it happened to a lot of people. So, what can we learn from this global incident and what should we do about protecting ourselves in the future? Three years ago The Attributer wrote an article named ‘Patched’. We shall re-examine some of the principles mentioned then in the light of recent experiences with malicious software attack vectors.
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? In the case of Wanna-Cry, it is clear that many systems at risk had not been patched, so why not?
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. If you want to know why the vendors can’t supply bug-free software, it’s because highly complex systems exhibit what are known as ‘emergent properties’. These are unexpected and usually unwanted system behaviours that are the result of intense complexity. It is beyond human capability (at least for the time being) to predict all these behaviours and so we must live with the real world fact that software bugs exist and that malicious code can exploit them.
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? Whoops! Emergent properties showing up again. Hmmm – now we see that there are potential uncertainties here that may have been overlooked. Well that’s risk for you – uncertainty of outcomes.
This means that patch management is not just a simple exercise in applying the patches. It requires a careful risk management approach. 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, and this can take a long time to roll out the patch. Another issue is – which systems should be patched first and what is the priority order?
The patch management process should begin with creating a state of ‘patch-readiness’, meaning having the process in place and tested for it’s own suitability. Some of the key steps to be incorporated into the process should include:
1. Make the patch management process an integral sub-process of business continuity management.
2. Ensure that patch management will enable business and not hinder it.
3. Assess the business criticality of IT systems so that priority in patching can be decided based on critical need.
4. 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.
5. Test each patch on a test platform to assess its effects on overall system performance. Assess the risks of patch failure.
6. 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.
7. The regression plan should also be tested thoroughly to ensure that it would work if needed.
8. 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 to identify problems.
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.