Threat actors can move pretty fast. There are untold numbers of adversaries operating in the shadows looking for the next vulnerability they can exploit. Sometimes they find a vulnerability that hasn’t been identified by white-hat researchers or the vendors—resulting in a zero-day exploit—but most often they watch for public disclosures and updates from vendors to identify changes that have occurred in code. At this point a race begins—the race to see if they can create a functioning exploit before organizations across the globe can plug the vulnerabilities.

There are several recent examples that show how quickly threat actors can move:

  • BlueKeep (CVE-2019-0708): The vulnerability that received so much hype for being the next potential WannaCry was resolved on May 14, 2019. Because of its notoriety, we got a chance to see exploit development in action as multiple independent research teams achieved working exploits in just 14 days (May 28, 2019 multiple proof-of-concept (POC) videos showed full exploit of the vulnerability). It took a while before threat actors started using the exploits, but it has seen a lot of active usage in crypto-mining.
  • ZeroLogon (CVE-2020-1472): The vulnerability in NetLogon was resolved in an update on August 11, 2020. The resolution required some changes to how NetLogon works, so Microsoft rolled out the update by fixing the vulnerability but putting the change in audit mode to begin. Microsoft advised it would be turning on enforcement as part of the February 2021 Patch Tuesday release, but organizations were able to turn enforcement on sooner if they were ready by changing a registry setting. By September 15, 2020, news broke regarding POCs, and by September 18, the Department of Homeland Security released Emergency Directive 20-04 advising government agencies to deploy and enable enforcement for the update by the following Monday, September 21, 2020. Turns out their urgency was well placed as the first exploits in the wild were detected before the end of September.
  • .Net\SharePoint RCE Flaw (CVE-2020-1147): Initially resolved in the July Patch Tuesday release on July 14. By July 21, POC exploit code was circulating. This update has been re-released as part of the October Patch Tuesday release.

In all three cases—from release to exploit-code availability—the range is around 14 to 28 days. This happens to match the findings in the 2016 Verizon Data Breach Investigations Report indicating that 50% of exploits will occur withing two to four weeks of release from the vendor. Findings from “Zero Days, Thousands of Nights”, a report released through RAND Corporation, found the median time to exploit a vulnerability to be 22 days. Based on this evidence, it’s recommended to target an SLA on vulnerability remediation of 14 days or less, which brings us to the next set of challenges.

Why Is a 14-day SLA Hard to Achieve?

Vulnerability and Patch Management solutions have been on the market for more than a decade and are fairly mature solutions. Technology to identify, stage, execute, and report quickly on the state of vulnerabilities is a small challenge.

The bigger challenges include the fact that the vulnerability-remediation process spans multiple teams and technology stacks. The process is fraught with manual steps, testing and operational impacts, and some base communication challenges that cause delays. I can name many companies off the top of my head that have achieved 14-day or shorter SLAs on vulnerability remediation. Several of them are large enterprises in manufacturing, retail, and more. What have they done to achieve this since they’re using the same technology as some companies that are still on 30-day cycles?

The four greatest challenges in vulnerability remediation:

  1. Bridging the gap between security and operations: Let’s be honest. It’s not often that security and operations truly “get along”. Security speaks the language of Risk and CVE, while operations speaks Operational and Patch. Resolving a CVE has operational impact because the patch broke something. There’s a lot of pain for the operations team. When day-to-day operations restrict how quickly the security issues can be resolved and an incident occurs, there’s a lot of pain for the security team.
  2. Risk-based prioritization is critical to resolve the right vulnerabilities first: There are many cases where vendor severity and CVSS score don’t reflect what’s most urgent. There are many examples of a zero day being resolved, yet the vendor severity is only rated as “Important” and the CVSS score is 7.0 or even less. Additional metrics and metadata are needed to ensure the highest risk items are plugged. For example, what is actively being exploited?
  3. Understanding reliability of updates: Back to the vulnerability remediation SLA and time to patch. One of the largest barriers to moving quickly is the inability to test effectively. Admins have two choices: 1) try to scale their testing to ensure they don’t have an operational impact, or 2) let time factor into their testing process and things will work themselves out if you wait long enough. The thing is, threat actors love it when you wait. Did I mention that the same RAND report also found the average shelf life of an exploit to be seven years? Apparently, some issues went unresolved for a really long time, allowing plenty of low-hanging fruit for threat actors.
  4. Patch compliance: There’s a lot of variety in compliance reports, but most track against the time your maintenance window opens, not when the update was first made available. Microsoft, Adobe, and Oracle may release most security updates on a consistent and predictable date, but Google, Apple, Mozilla, and many more companies do not. Tracking compliance on a vulnerability needs a refocusing down to a more granular level to account for the continuous delivery nature of today’s software.

If patch reliability, risk-based prioritization, and patch compliance are challenges that prevent you from achieving a 14-day SLA on vulnerability remediation, you may be in need of an enhanced experience beyond your current patching solution. Ivanti® Neurons for Patch Intelligence was designed with these challenges in mind. Check it out today.