May 23 2016

What to do When You Can’t Patch a Vulnerability

The Verizon DBIR has a lot to say about vulnerabilities. One of the more interesting topics is the large number of 2015 vulnerability exploits that were more than a year old. In a footnote the DBIR authors comment that “Those newly exploited CVEs, however, are mostly – and consistently – older than one year.” The data show that more than 90% of exploited vulnerabilities in 2015 were more than one-year-old and nearly 20% were published more than 10 years ago.



This data is consistent from year-to-year. In 2014, more than 95% of exploited CVEs were more than a year old. As you would expect, most of the remediated CVEs in 2015 were recent. It appears that over 70% of all closed CVEs in 2015 were no more than two years old and over 95% of all closed CVEs were within five years of their original publication.



You would expect that most of the CVEs closed in any year would be recent as older vulnerabilities would have received patches published in previous years. And, when you get past about five years, you are much more likely to encounter software versions that are no longer supported. New patches are not arriving for that end-of-life software you are still running. “This gets at a core and often ignored vulnerability management constraint – sometimes you can’t fix a vulnerability – be it because of a business process, a lack of a patch, or incompatibilities,” conclude the DBIR authors.

SAP Vulnerabilities Expose the Scope of the Problem

The king of the enterprise resource planning (ERP) market, SAP, provides good example of this situation. On May 11th, US-CERT published an alert confirming that 36 organizations were affected by a vulnerability first identified by researchers at Onapsis earlier in the year. This may not seem like widespread impact, but consider that these likely represent 36 of the world’s largest companies facing severe consequences. The alert states, “Exploitation of the Invoker Servlet vulnerability gives unauthenticated remote attackers full access to affected SAP platforms, providing complete control of the business information and processes on these systems, as well as potential access to other systems.”

A Dark Reading interview with Onapsis director of research Ezequiel Gutesman concludes, “the average enterprise takes 18 months to patch these systems.” Why so long? The hosts of the Defensive Security podcast, Jerry Bell and Andrew Kalat, offer a simple explanation. Every instance of SAP is customized during implementation. Patches from SAP, no matter how expertly crafted, risk breaking those customizations that SAP didn’t include in their core product. Now  consider that companies often rely on SAP to run back-office financials, fulfillment, and procurement. Those customizations could impact a company’s ability to run payroll, ship product, or order supplies for production. An extended downtime of the system could bring business operations to a halt. When you consider this situation, you can see why some companies are slow or reluctant to implement every patch immediately. It’s complicated.

This is a recurring theme on the Defensive Security podcast. Compromises of unpatched vulnerabilities are often known risks that information security teams cannot or are not allowed to patch for a variety of business reasons. Risk must often be addressed through means other than patching in these instances. The SAP example highlights that this isn’t just a concern for legacy software, PLCs and SCADA systems that have always-on operational requirements. Even your newest software can pose substantial challenges around vulnerability management.

Detection Capabilities Are Critical

This is yet another reason why robust breach detection capabilities are so critical. There is a lot of discussion about the importance of detection and response due to increased attacker skills in social engineering and penetrating well protected and fully patched endpoints. We understand that it is hard to prepare for unknown risks from skilled hackers. However, detection and response capabilities are equally important because we also have many known risks like un-remediated vulnerabilities that we must vigilantly monitor for compromise.

The added complication is that we know SIEM and endpoint protection solutions consistently miss attacks. This allows attackers to dwell for several months inside the network before discovery. We know that leads to lateral movement, data exfiltration and heightened risk leading to financial, operational and reputational impacts to the business.

Identifying Patterns of Compromise

That is precisely why enterprises are turning to information security analytics solutions. Tools like IKANOW help narrow the time between compromise and detection by curating threat intelligence to match IOCs to assets with higher predictability and also identify unusual patterns of behavior. Existing security tools too often miss these compromises because they cannot process enough network and application data and filter through the noise to notice the tiny footprints left by attackers. Nor are they designed to integrate with the wide variety of threat intelligence content and use it for rapid analysis.

IKANOW has the required scalability, speed and an open architecture that enables rapid detection where other systems fail. It also enables enterprises to identify clusters of assets and identify growing risk across the group. Even if a single asset may not appear to be under attack, small changes across a number of assets as a group can indicate malicious activity. IKANOW’s risk scorecards expose these incidents when other systems view them as benign. In practice, this might mean clustering un-patchable assets and the systems they interact with as a group instead of looking at each individually.

The un-patchable vulnerability is a fact of everyday life for many information security teams. Segmenting networks and end-of-life plans are solid strategies to employ over time to limit the risk of damage. Tools like information security analytics can also make these situations far easier to manage with an acceptable risk profile.

Share Post
Chris Morgan

Cofounder and Chief Technology Officer. Chris Morgan is responsible for technology innovation and delivering high-quality security analytics solutions to clients. He has more than 15 years of experience in research and development, software engineering, software development and product management. Morgan studied management at the Wharton School of Business of the University of Pennsylvania and economics and computer science at Virginia Polytechnic and State University.