Patching: Not a Silver Bullet

The best way to keep out an adversary out of your network is to build a fortress: create a network with no vulnerabilities in the underlying software and hardware and employ people who are not susceptible to social engineering, ever.

As we all know, this is fantasy for any CIO or CISO. In reality, software and hardware contain vulnerabilities—many known and many not. In most cases, software vendors generate software patches to fix vulnerabilities quickly, which means implementing a robust software patch management program is critical for an organization.


However, patching is not a silver bullet for two main reasons: 1) Not all systems are created equal. Patches cannot automatically be installed on every system immediately upon a vendor’s patch release and 2) Software vulnerabilities may be unknown to the vendor, but known and/or available to a malicious threat actor. Many government and commercial organizations establish and run Change Control Boards (CCBs) for critical IT systems. These boards are made up of key stakeholders from across an organization and customer base. In many cases, patches require CCB approval before an organization is allowed to apply a given patch on its system; the review, approval, and apply cycle can take months or even years. In some cases, vendors are no longer releasing patches when vulnerabilities are identified, even though these operating systems are still widely used. Two examples of this are Windows XP and Adobe Acrobat Reader Versions 9.x. In the world of Service Level Agreements (SLAs), rebooting a critical system to apply a patch can cost the organization vast amounts of money. To apply the tens or hundreds of patches released each year by various software vendors could cripple a companies’ bottom line or jeopardize a military mission. Vendors release fixes so frequently today that patching even disrupts the work of non-critical systems. Even just while writing this blog, I received a reboot request to install a patch. To that end, threat actors can leverage spear phishing to target users who have not rebooted their workstation/laptop to install the latest patches, which then enables them to move laterally in a target’s network. A strong patch management program is an outstanding initiative, but CIOs and CISOs must not be lulled into thinking that patches are a silver bullet that will cure all of their security woes.

A patch is just one tool in the overall arsenal against cyber-crime. Let’s look at the first and most common scenario above, where a software patch is released. A threat actor can learn what vulnerability the patch is designed to fix, and then create an exploit to target that vulnerability. At this point, a threat actor is racing to use the exploit before potential targets can patch every relevant system within their extended enterprise. FireEye’s Threat Intelligence team routinely sees rapid weaponization of vulnerabilities upon public disclosure whether by a third party, vendor announcement or a vendor patch notification. FireEye recently published a blog on APT3 and APT18, where a malicious actor weaponized the public disclosure of a vulnerability and vendor patch.

One misconception here is that, when leveraging a patching solution, a patch is quickly applied to all corporately owned assets (even those off the network) and immediately provides full protection. This is not the case because not every vulnerable system can be patched instantaneously. Mission- and business-critical systems pose the greatest risk to an organization if they are impacted. Since these systems are uniquely customized to a business or mission and are not typically patched right out of the box, they require extra testing and adequate time for patch installation. Each time a patch is needed, the business/mission is impacted – which means CIOs and CISOs must constantly assess the tradeoff between the need for a patch and the likelihood that an adversary will exploit the vulnerability, possibly resulting in an impact to company operations, a very expensive Incident Response engagement, and a highly embarrassing public disclosure.

In today’s world, a threat actor is more likely than ever to exploit that vulnerability but the impact of patching critical systems is still deemed more risky in many cases. Figure 1 shows the tradeoff.

This situation demands that CIOs and CISOs implement additional protections against the exploitation of all vulnerabilities, both unpatched and unknown (zero-day) for the exploitation of unknown vulnerabilities and the exploitation of those systems for which there are unapplied security patches. This type of protection can be called Vulnerability Shielding. Vulnerability Shielding is a security mechanism that protects, or shields, a vulnerability from being exploited and can help CIOs and CISOs mitigate this risk exposure, which is much larger than most know. A Detonation Chamber, as defined by NIST, is an ideal capability for providing vulnerability shielding. One of the best and most proven capabilities on the market today is the FireEye Multi-Vector Virtual eXecution (MVX) engine. MVX has allowed FireEye to detect more zero-day exploits in the wild than all other security vendors combined. In short, it picks up where patching alone leaves off, detecting and preventing advanced attacks.

Rather than relying on a single silver bullet, CIOs and CISOs must ensure the practical limitations of patching are incorporated into their overall security strategy, with appropriate technologies to shield vulnerabilities on systems that can’t be patched or where the patch doesn’t exist. Also, organizations should apply proper network- and domain-level segmentation in their networks to isolate critical systems from non-critical systems and prevent enterprise-level impacts due to a breach of one user’s system. By simultaneously keeping their networks safer and their enterprises operational, those in charge of technology can feel better about their fortress’ defense and business’ success.

Patching is needed and recommended; however, in the age of advanced attacks with zero-day researchers picking apart software (and patches), the most reliable strategy requires adding detonation chambers. Detonation chambers allow for a thorough analysis of objects entering an environment to determine if they are malicious or contain exploit code targeting a known vulnerability or an unknown/zero-day vulnerability. In addition, some virtual machines monitor and detect complex, multi-flow attacks across many vectors such as web, email, file or even mobile to spot malicious behavior. Advanced threat actors can routinely bypass capabilities that don't offer these advanced capabilities embedded into virtual machines analysis. At the end of the day, a security architecture that incorporates effective detonation chamber technology is an important insurance policy against the exploitation of unpatched systems and zero-day vulnerabilities.