Microsoft’s Patch Tuesday update on January 14, 2020 reported a significant vulnerability specific to Microsoft’s CryptoAPI services.
According to Microsoft, the impact of the Windows CryptoAPI Spoofing Vulnerability (CVE-2020-0601) means, “An attacker could exploit the vulnerability by using a spoofed code-signing certificate to sign a malicious executable, making it appear the file was from a trusted, legitimate source. The user would have no way of knowing the file was malicious, because the digital signature would appear to be from a trusted provider. A successful exploit could also allow the attacker to conduct man-in-the-middle attacks and decrypt confidential information on user connections to the affected software.”
Brian Krebs shared information on this critical security vulnerability, stating all Windows devices are likely affected. While this is a necessary and critical patch, what adds weight to the seriousness of this risk is that it was pre-deployed to critical infrastructure prior to its public release.
This standard operating procedure to automatically patch all systems with the latest risk reduction bundle from Microsoft is never straightforward, leaving industrial companies to fend for themselves and find ways to manually patch or design and implement a host of compensating controls in the interim. This diverts their key engineering and operations staff away from fundamental operational tasks and projects.
3 steps for the OT deployment of Microsoft Windows CryptoAPI patching into OT environments:
Detect and monitor anomalies in your OT assets
While you build out a practical (read: methodical but likely time consuming) patching plan, first keep an eye on what is happening while locking things down. You don’t need an entire passive anomaly detection tool set (if you have one then that is good – but if its coverage doesn’t extend to all Windows assets you might want something more inclusive), but you do need to monitor for possible tell-tale signs.
This is where file integrity monitoring comes into play. By monitoring your Windows assets for unwanted software being placed on those systems outside of your normal patching you can gain instant alerts as to any specific systems being targeted or compromised while you start to roll out patches.
Patch software with a safe and automated OT tool
Patching is difficult, but there are OT safe, automated tools allowing for triage, prioritization, automation and OT oversight as needed to safely patch and automate as much as possible.
To patch effectively:
- Enumerate your inventory to ascertain priority by criticality of asset and ease of patching
- Pre-deploy patch files to target assets while you test sample system types in your lab or on redundant systems
- Use automated tool set to schedule patches – include requirement for a human to be at the console to accept deployment if necessary
- Execute staged patch deployment by territory, asset criticality, type or unit as planned
- Track and report centrally across the asset fleet during tasks
This step is a necessary and hopefully at this point, you have begun rolling out more robust patching tools to help your organization keep apace of risk.
Mitigate risk when software patching is not an option
Every patch cannot be applied to every OT system. Once you have patched as much as you can, you should provide compensating controls to at-risk systems. The fastest way to do this would be to deploy Hash-Based Whitelisting with a solution such as Carbon Black’s Bit9.
Find a partner with extensive experience in the deployment and tuning of a best-in-class security whitelisting solution. Integrate its initial deployment and ongoing status tracking in your cybersecurity program to make it easy and affordable to deploy.
While software patching isn’t easy, there are steps to improve the process. Following these steps to deploy compensating controls, you will provide the most comprehensive coverage possible for your OT environment. Read more about additional ways to protect against remote vulnerabilities.