I remember watching a film, years ago, in which the two protagonists go hunting. They are both carrying shotguns and the dialogue goes something like this:
“Is your gun loaded?”
“Nope.”
“Break it.” [the other guy does as he’s told, breaking the shotgun open to show there are no shells loaded]
“Good. Now you’re sure.”
I don’t know if the recently-departed CEO of Equifax, Richard Smith ever saw this film. But when he blamed a single individual for the largest data breach in American history because they allegedly failed to apply a patch, he certainly forgot the cardinal rule of gun safety – and cyber safety.
Be sure.
Applying a patch without being sure is like carrying a gun you think isn’t loaded. Sure, you checked it a while back. But someone could have had access to it, and played around with it. You don’t know until you break that gun open and look. Now you’re sure.
As with gun safety, cyber safety isn’t rocket science. There are three key steps to being sure.
Step 1. Know where you are today
Managing security patches starts, of course, by knowing exactly what patches you DO have installed and on what systems. You should start here with a risk analysis and ensure that your systems mitigate all potential risks. Let’s enumerate some of the obvious ones
You don’t have an accurate picture of your estate, because:
- Not all endpoints are communicating data in a timely manner to your inventory management system.
- Some endpoints are ‘off the grid’ – you aren’t monitoring them and you’re not even sure about how many there are. (This may have happened at Equifax, allegedly.)
- The data you’re receiving from endpoints isn’t accurate or is subject to misinterpretation. For example, collecting version information at file level gives you quite a different picture to collecting information at the level of installed software. In fact, quite a lot of software may have NO install information but the files exist and are run on endpoints, nonetheless.
- There is unreliability in your collection infrastructure, with devices randomly dropping off the network or reappearing. In addition, mobile devices come and go unpredictably as their owners reconnect to corporate infrastructure after being on leave or away from the office on a business trip.
You don’t have the capability to monitor certain patches because:
- They don’t leave a footprint on the installation data you collect (e.g change in installed version)
- They don’t leave a footprint on the file inventory you collect – perhaps they involve a registry tweak or a configuration file change that you aren’t monitoring. Or they involve open ports (or port configuration) on endpoints that you can’t monitor reliably for some reason. Or perhaps database changes you can’t easily monitor.
- They involve complex products with lots of subsystems and you aren’t collecting the level of detail required to be sure that each subsystem is patched
Step 2. Verify your position with regard to any vulnerability
You need to be sure that, for any security vulnerability, you can reliably answer these three simple questions, ideally in real time.
- Am I vulnerable to this issue?
- Which endpoints are vulnerable?
- Given the endpoints that run this subsystem, but which are supposedly not vulnerable, if I run a ‘proof of concept’ attack using the vulnerability, do these endpoints correctly reject the attack?
Step 3. Close the loop
Once you’re confident that you can reliably answer these questions you need to close the loop with patches or other affirmative actions (e.g uninstalling software completely or disabling subsystems).
In this case the processes involved can’t rely on people getting it right. They have to be automated so that, having applied patches, you should be able to repeat the previous two steps above in real time and get answers. This closes the loop. Now you’re sure.
In the case of Equifax it looks as though this ‘closed loop’ process simply didn’t exist. As a consequence, it could only hope it was secure, and could not verify it.
Hence, even if someone failed to apply a patch, the root cause of the problem wasn’t human error. Automated, closed loop systems compensate for human error by detecting the failure.
The root cause of the problem was not having these systems in place. If you don’t have this level of control, you may be secure. Or you may not. Simply put, you aren’t secure until you’re sure.
| About the Author | |
 |
Andrew Mayo has been involved in IT, both in software and hardware roles, for enough years to have worked through the tail-end of the punched card and paper tape era, and the subsequent invention of the PC. Currently he’s working on the evolution of 1E’s Tachyon solution, looking in depth at both attack and defense strategies and the evolution of the threat landscape. Previously Team Lead for the AppClarity project, he’s worked previously in various verticals including healthcare, finance and ERP. When he’s not wrangling with databases, he enjoys playing piano and hiking, especially when the destination is one of England’s picturesque pubs. |
