At the Zero Day Initiative (ZDI), we see patches in a way few do. We get the initial report from a researcher, we verify the issue internally, we notify the vendor, and finally we publish some details once a patch is released. Those patches represent the best method for preventing cyber attacks. Recently, an issue patched by Microsoft in March 2017 was used by malware, known as Wanna, Wannacry, or Wcry, to infect systems globally with ransomware.
How could something fixed for more than 60 days wreak so much havoc around the globe? Why can’t people simply patch? Sometimes patching isn’t as easy as it sounds – especially for enterprises.
Step 1: Prepare for the patch
To establish a complete patching strategy, organizations need to identify the assets they own. This task is usually more difficult than it sounds. Enterprises have the choice of using a mixture of Open Source Software (OSS) or commercial tools to identify and catalog all the systems and devices on their network. Even if the software they use is free, implementing the solution has costs. Once an enterprise determines what needs to be protected, they must then create and document a process to update these devices. This includes updates for not just workstations and servers, but networking devices such as routers and switches. Decisions need to be made.
Will an automated system be used or will an administrator need to physically touch a machine? Since security patches often need a system reboot, or another type of workflow disruption, at what time will the patches be applied? Documenting the patching strategy ensures uniformity and consistency of patching throughout the enterprise.
Step 2: Find the patch
Now all you need to do is find some patches. Having a robust strategy is somewhat pointless if those in charge are not subscribed to the appropriate email lists, RSS feeds, Twitter accounts, and other methods used by vendors to announce the release of a new patch. Some vendors communicate more robustly than others. Once you find the patch, you must determine how to install it. Small enterprises may consider doing this manually. However, any enterprise with more than a handful of machines should invest in automated tools. Similar to tools intended to identify assets, there are many choices of varying costs. Still, the costs of an automated system far outweigh the costs of manual installation.
Step 3: Test the patch
There is just one final step an enterprise should consider before deploying any patch: testing. Repairing and restoring systems affected by a faulty patch is both disruptive and costly. To prevent this, there are various forms of testing. If resources exist, the minimum amount of testing should involve applying the patch to a similar system in a non-production environment to make sure business functions continue after the patch is installed.
Step 4: Patch!
Once you identify your assets, document your processes, find your relevant patches, institute automated patch deployment, and test the patch – congratulations! You may now install that patch!
Beyond the complexity of patching in the enterprise, there’s also a psychological barrier with patching that many people need to overcome. Simply put, people are afraid of security patches for several reasons.
- Security patches intended to close holes end up breaking other software, or even leaving the entire system unusable
- Alternatively, there are times when the patch does not address the root problem
- Some vendors have chosen to include additional software or features not wanted by users – like changing the default browser with an unrelated instant messenger patch
- Perhaps the worst-case scenario, there have been security patches that ended up introducing additional security vulnerabilities
While the industry as a whole has improved over the years, problems – including historic fears – remain.
The vulnerability used in Wcry was listed in a dump of tools purportedly used by the NSA alongside something called EwokFrenzy. We knew EwokFrenzy in the ZDI program as ZDI-07-011 – when it came through 10 years prior. Does that imply the exploit was still effective 10 years after the vendor released a patch? That does seem likely. It’s also the latest data point in more than two decades of imploring regularly patches and strong backup policies.
It isn’t easy. It isn’t simple. It often isn’t cheap. But the potential cost (both financially and to the organization’s reputation) of leaving vulnerabilities unpatched far outweighs the cost of patching. Recovery after attacks is harder, more complex, and more expensive – it’s time we admit patches matter.