Most malware, ransomware and hands-on keyboard attacks use known or zero-day vulnerabilities to get a foothold in an organisation. Some recent examples of how successful these attacks are include the PrintNightmare (Print spooler remote code execution), the Microsoft Exchange-Remote Code execution and the Log4J vulnerabilities.
These devastating vulnerabilities had cyber security teams in a frenzy to “patch before the dreaded breach”, as many exploit attempts were identified before official vendor patches were released. The problem here was that according to breach investigation reports, older (well-known) vulnerabilities were an even bigger target in the previous year.
Which then asks the question: if the security community knows about these vulnerabilities and official patches have been available for a while, why does patching still pose such a considerable risk? What are the challenges facing traditional patching?
Patching cycles
Official vendor patches are typically available days after an exploit is made public, but then only does a company start patch testing, and only once testing is completed do they initiate the change control process. Bear in mind that the more critical the system, the longer the patching cycle, and vendor patches make changes to the operating system and the registry, so extensive testing is required.
Some systems get patched weeks or even months after the exploit is known. This equates to weeks and months of being vulnerable and at risk of being breached.
Legacy operating systems
Most manufacturing, retail and financial services organisations are still using a small percentage of older operating systems in their operations, including custom-built applications or control systems. The big challenge is that vendors no longer create and release patches for those systems. Hackers need one good entry point, not 100, making legacy systems a prime target.
Adverse effects of the official patch
How often have we seen patches that "break" something? During testing, something stops working, or a dependency system is adversely affected. This usually means further testing, or at a minimum, a delay in deploying the official patch. Rolling back a patch is almost as big a challenge as the change control process itself.
Zero-day exploits
In June 2021, the Microsoft Print Spooler vulnerability was made public, and Microsoft released a patch on 8 June 2021. The vendor released patch was ineffective, and they released a few more patches in June to try and combat this. Then on 1 July 2021, a new print spooler remote code execution vulnerability, considered a zero-day, was published – so new but not new.
After various attempts to successfully patch the vulnerability, on 10 August 2021, Microsoft released a patch that worked. Yes, an extreme case, but it took more than 60 days for the vulnerability to be successfully addressed, which means 60 days before organisations could start testing the patch and initiate change control for the risk.
Virtual patching to the rescue
The best virtual patches are intrusion protection type rules aimed at catching the source code used in exploiting the vulnerability. When done right, this happens upstream or at the network layer to ensure the offending code is not allowed on the target machine. So, no matter how many malware variants exploit the same vulnerability, a well written virtual patch will prevent them from being executed.
The success of virtual patching related to the challenges mentioned above include:
Patching cycles
A vendor using virtual patches will release a virtual patch an average of 81 days before the official vendor patch is released. These patches make no changes to the operating system or the registry of the target machine, so the testing phase is dramatically reduced.
Deploying the virtual patch is done via a tick in a box; rolling back the patch is as simple as unticking the box. Teams can deploy a virtual patch in “Detect Mode” only to ensure no dependent systems are affected and operations aren’t impacted. They can also be deployed temporarily to ensure systems are protected. At the same time, a vendor patch is created, or testing is done on operational systems, reducing the risk window from months or weeks to a day.
Legacy operating systems
Virtual patches protect legacy operating systems that the vendor no longer supports, and as above, deployment and rollback is still just a tick in a box.
Adverse effects of official patches
Since the virtual patch does not change any part of the operating system or the registry, the chances of “breaking” anything is almost zero. As it doesn’t require a reboot of the target system, the risk is further reduced, as is the reliance on expensive person-hours during change control windows. In the unlikely event of the virtual patch affecting operations, it can be deployed in “Detect Mode” or rolled back by unticking the box.
Zero-day
Leaders in virtual patching participate in vendor-based zero-day initiatives and often find and publicise zero-day vulnerabilities. In these instances, the virtual patch is made available while the threat is made public; for example, Trend Micro’s Tipping Point team releases a virtual patch on average 81 days before the official vendor patch is released.
When more known vulnerabilities are addressed more quickly, there is a positive spin-off for business, namely a smaller attack surface, resulting in fewer incidents to investigate and better use of cyber security resources. With virtual patching, a company reduces time to detect, respond and remediate, reducing risk exposure.
For proof of concept or more information, e-mail Info@blueturtle.co.za.
Share