Staying Strong Despite Vulnerabilities
No system is 100% foolproof – all systems have weaknesses: humans get sick, cars break down and elevators get stuck. Sometimes these weaknesses can be fixed quickly; other times, a fix might take considerable time or may not be feasible.
No software is 100% foolproof . All software applications have bugs or vulnerabilities that might be exploited by malicious actors looking to infiltrate networks, steal sensitive information and/or cause damage. According to Check Point Software´s Security Report, 87% of organizations have experienced an attempted exploit of an already-known, existing vulnerability.
Recently, we published a blog post about two vulnerabilities in Microsoft Windows that enable attackers to gain elevated privileges, move laterally in the network and access sensitive resources. Many ransomware attacks exploit a vulnerability in SMB protocol dubbed EternalBlue to propagate through the network.
Most cyber attacks such as EternalBlue involve vulnerabilities for which a patch is available but not applied. The question is, if a patch exists, why wasn’t it applied?
If Only It Were that Simple…
A patch is basically an updated version of the software – and like any software update, it may not be trivial. A software update can require restarting the affected system, and in some cases, it may potentially cause a fault that brings the system down. That’s why organizations typically have a “patching window” for sensitive systems, and often test patches in the lab first before applying them in production. Some systems are too sensitive or critical to be taken offline and cannot be updated, or at least not immediately. Once again, we’re encountering that familiar tension between Security and Business Continuity!
Mitigating Vulnerability Risk Is Not Easy Either
Last week F5 reported a critical vulnerability in its BIG-IP WAF. According to the article “An authenticated attacker with access to the Configuration utility can execute arbitrary system commands, create or delete files, and/or disable services. This vulnerability may result in complete system compromise.”
While a fix for this vulnerability is available, F5 acknowledges that users may not be able to apply it and suggest organizations “restrict access to the Configuration utility to only trusted networks or devices” in order to mitigate the threat temporarily. Assuming we know whom to trust (which is also not always trivial), that restriction could be quite harsh on the business (in this case, IT).
Buy Time with Deception
Once a system is identified as vulnerable, DeceptionGrid can be used to quickly deploy an emulated copy of that system to deceive attackers, distract them from their original target, and provide an early and accurate detection to the SOC. Implementing Deception in such a manner can buy the organization more time, allowing it to sustain the vulnerability while reducing the risk.
The emulated traps can be created using one of the dozens of predefined templates, or use the vulnerable system as a template through DeceptionGrid BYOT (Build Your Own Trap).
For example, for the Microsoft Windows vulnerabilities mentioned earlier – this post describes in detail how you can buy time by deploying a decoy vulnerable Windows trap. Attackers attempting to exploit one of these vulnerabilities on a trap will receive authentic responses and be deceived into thinking the exploit succeeded. At the same time, the attackers’ interaction with the trap will be recorded and an alert triggered in TSOC (TrapX Security Operations Console), enabling IT to take rapid action to protect the network.
Keep Traps Even After Patching
As a single DeceptionGrid emulation server can host hundreds of traps, and traps can be set up within minutes, a trap created to mirror a vulnerable system can remain active even after this system has been patched – that way the SOC will be alerted on attackers lurking in the network.
For more information about how TrapX Deception works, visit the DeceptionGrid page.