How to Be a Better Patcher

Use this single recommendation to help you better reduce risk while patching.

It is tough to do patching 100% perfectly. Most people and organizations do not do it nearly 100% perfectly. This is evidenced by the fact that unpatched software is involved in somewhere around 20% to 40% of all hacking attacks (depending on the source of the statistic) and it has been the number one or number two most common reason for successful, malicious hacking attacks for the entirety of computers since they were invented (social engineering is the number one cause of all malicious hacking).

As an example, this KnowBe4 white paper (https://info.knowbe4.com/wp-root-causes-ransomware) on the root causes of ransomware shows, unpatched software is responsible for an average of 23% of all ransomware attacks. This source (https://www.tripwire.com/state-of-security/vulnerability-management/unpatched-vulnerabilities-breaches/) says unpatched software is involved in 27% of all attacks. It is the rare National Institutes of Standards and Technology (NIST) or Cybersecurity Infrastructure Security Agency (CISA) threat warning that does not list unpatched software as a top root cause of the described attack. Unpatched software is a huge risk to most organizations.

All penetration testers know how easy it is to compromise most environments because of a few missing patches. You scan the environment to locate different network accessible software, identify the type of software and version (called fingerprinting), look for older, unpatched implementations, locate the appropriate vulnerability exploit code, exploit the unpatched software, and then you’re in. It is easy-peasy.

All defenders know they need to patch to prevent hacking attacks. But patching is hard. For one thing, there are a lot of potential vulnerabilities to patch. Last year, as an example, there were at least 18,103 new vulnerabilities publicly announced as needing patches (https://cyber-reports.com/2021/02/21/highest-number-of-vulnerabilities-disclosure-reported-in-2020/). That is nearly 50 new patches a day that need applying (if you have the involved software/firmware) and that is on top of every patch ever listed over the years. As a defender, all it takes is one missed patch to let the hackers in.

Second, it is really hard to be 100% perfect at patching even if you really care and try. It’s hard for any single person to do on just the devices they own, must less do it over every device in a larger managed environment. Just accurately trying to inventory and identify everything that needs patching can be impossible. And, often, when you go to apply a patch across a bunch of computers and devices, the patches often do not apply correctly to a small percentage of computers for one reason or another.

In my personal experience, I often got 1% to 3% patch failure rates on any patch I applied. Identifying the computers with patch problems, fixing them, and getting the patches applied so I could say I had 100% patch compliance for a particular patch always took longer than applying the other 97% to 99%. And even when you try to consistently patch 100%, somehow unpatched software sneaks in unnoticed or something you thought was patched simply is not. One hundred percent patching across all computers and software (and firmware) is really a difficult challenge. It is why unpatched software is a top root cause of malicious hacking. Hackers know 100% perfect patching is very hard to impossible for defenders to accomplish consistently, especially over time. Tick-tock. Tick-tock.

Secret To Good Patching

Here is a top hint to good patching: Focus harder on what is most likely to be exploited. The stuff most likely to be exploited is only 2% to 4% of the bigger patching population. You will be far better off, risk wise, if you patch 100% of the software most likely to be exploited than trying (and failing) to patch everything.

Note: I first wrote about this in my book, A Data-Driven Computer Defense (https://www.amazon.com/Data-Driven-Computer-Defense-Way-Improve/dp/1092500847/) in 2018, and years before that in many articles and white papers.

If you can patch 100% of everything all the time then by all means, do that. That will give you the best risk reduction possible. But even if you try to do that, if you focus first and best on patching the things most likely to be exploited, you’ll be far better off risk wise than a defender who isn’t. Go for broke, try to patch 100% of everything, but make sure you patch the most likely to be exploited stuff first and best.

Patch Your Most Likely To Be Exploited Software

Turns out that only 2% to 4% of software vulnerabilities are ever exploited by anyone! Researchers have known for years that attackers have only attacked a small fraction of known vulnerabilities. So, instead of worrying equally about over 18,000 vulnerabilities a year, what you need to worry about THE MOST is 724 vulnerabilities, at most. And it is really a much smaller subset than even that.

Kenna Security and the Cyentia Institute (https://website.kennasecurity.com/wp-content/uploads/2020/09/Kenna_Prioritization_to_Prediction_Vol1.pdf) had the data to show that less than 2% of vulnerabilities were actively exploited in the wild. This research paper (https://resources.sei.cmu.edu/asset_files/WhitePaper/2020_019_001_644727.pdf) revealed that only 4.1% of vulnerabilities had public exploit code. In the latter paper, I cannot tell if the 4.1% figure refers to just the existence of public exploit code or if it is the existence of exploit code publicly exploited against a real-world target (i.e., “in-the-wild”). Per Kenna Security, far more vulnerabilities have exploit code publicly published than is actually used in the wild. Although Kenna Security does say the existence of publicly known exploit code, alone, increases by 700% that the involved exploit will be used in the wild. Regardless, in a given time period, you really only need to worry about, at most, 4% of all publicly announced vulnerabilities. And even then, really only the ones that are in your managed environment, which is no doubt, a far smaller percentage than the 4%.

But how do you identify the most likely to be exploited software?

First, look to see if the vulnerability has public exploit code published. If so, it becomes fairly high risk. The highest risk and the ones that matter the most, are vulnerabilities actually being exploited in the wild. If a vulnerability is not being exploited in the wild, then it really is not something you need to patch ASAP!!

So, how can you tell what is being actively exploited in the wild?

Well, it used to be that you had to really keep your eyes out. You would have to read every vendor and news article related to software (and firmware) in your environment and read to see if an exploit was being used in the wild or not. That is basically the way it worked until the last few years. Now, after everyone has started to understand the importance of patching the right vulnerabilities 100% of the time, there are easier methods.

Most sophisticated vendors and analysts have started to publish in readily accessible public vulnerability databases whether public exploit code exists and whether the exploit code is actively being used in real-world attacks. The most popular, free, public exploit list standard is known as the Common Vulnerability Exploits (CVE) database(https://cve.mitre.org/). You can look up any exploit or search by vendor and find out if the exploit is being exploited in the wild or even if public exploit code exists.

In particular, you want to find out an exploit’s Common Vulnerability Scoring System (https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator) or CVSS rating. A CVSS criticality rating takes into account over two dozen important factors, including whether the exploit can be accomplished only locally or can be done remotely over the network, privileges required to execute, and ease of use (called complexity). It also includes whether public exploit code exists and is being used in the wild. Any exploit with a CVSS rating above 8.0 is pretty high risk and should probably be patched fairly quickly.

Note: CISA now says that all high-risk exploits being used in the wild should be patched within 2 weeks.

A vulnerability can end up with a high risk CVSS rating even without there being exploit code in the wild.

But we all should pay particular attention to whether there is exploit code in the wild. It means a lot in overall risk. If there is not public exploit code or if the exploit is not being used in the wild against real world targets, then no matter what its CVSS criticality rating is (due to all the other factors), the less I care. In the CVSS rating, this factor is called Exploit Code Maturity (E) under Temporal Score Metrics. It has four possible values of increasing risk criticality:

·????????Unproven that exploit exists (E:U)

·????????Proof of concept code (E:P)

·????????Functional exploit exists (E:F)

·????????High (E:H)

Most vulnerabilities do not have any exploit code. You do not to worry, as much, until someone publicly publishes proof of concept code. An Exploit Code Maturity value of Functional exploit exists or High means you must do everything to patch it right away.

Of course, a vulnerability can be announced without there being any publicly known exploit code to take advantage of it at the time of the original announcement, but then a public exploit shows up later. Per the best stats I can find, of the vulnerabilities that end up WITH PUBLICLY KNOWN EXPLOIT code (which is only 2% to 4% of all known vulnerabilities), most public exploit code is published within two days of the public vulnerability announcement (per the previous referenced research paper, https://resources.sei.cmu.edu/asset_files/WhitePaper/2020_019_001_644727.pdf). That is median average. The mean average was 91 days. Still, it means most public exploit code is announced fairly quickly around the same time as the original public vulnerability announcement.

What can you do to monitor when a vulnerability becomes publicly exploited regardless of when the vulnerability was first announced? Well, you can subscribe to one the many commercial services that help with that, including Kenna Security (https://www.kennasecurity.com/) and Risk-Based Security (https://www.riskbasedsecurity.com/). They, and other commercial companies like them, provide excellent services well worth the money. They get an inventory of your software and firmware and compare it every day to a known list of publicly exploited threats. They will basically tell you, “Here’s what you need to worry about.”

Alternately, if you do not have the budget for a commercial service, you can follow CISA’s new Known Exploited Vulnerabilities Catalog (https://www.cisa.gov/known-exploited-vulnerabilities-catalog). Just released two weeks ago, it is the U.S. government’s list of known actively exploited vulnerabilities used against U.S. assets. I wrote about it here two weeks ago: https://www.dhirubhai.net/pulse/cisa-says-fix-right-stuff-now-roger-grimes. If you have software with an unpatched vulnerability shown on the list, patch it immediately! You can also subscribe and get frequent emails about new exploits: https://public.govdelivery.com/accounts/USDHSCISA/subscriber/new.

To recap, one of the best patching strategies is to make sure you have every publicly exploited vulnerability 100% patched. Nothing matters, in patch management strategy, as much as this one objective. Everything else should be secondary. Patch all critical patches, but especially the vulnerabilities being actively exploited in the wild against real world targets.

I’m not telling you to not patch everything. You need to try your best to patch all missing critical patches. But it’s really hard to do that 100% perfectly all the time. So, what I am telling you to do is to concentrate on actively exploited critical patches a little extra. No, make that a lot extra. If you get 100% of actively exploited vulnerabilities patched 100% perfectly all the time, consistently, over time, you’ll likely not get exploited because of patching issues. There’s a chance you might be hit by a zero-day or be the victim of some newly exploited vulnerability (known but never exploited before), but your odds of those two things happening are far, far, less than being exploited by something that is known and being actively exploited in the wild already.

Example Test Case

Intel recently announced two “high risk” vulnerabilities (https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00562.html) impacting Intel CPUs. Both have CVSS scores of 8.2, which means you should patch it. But do you need to patch it NOW!!...ahead of other necessary vulnerabilities actively being exploited in wild already if you have any in your environment? Probably not…at least not yet. As far as I can tell, it is not yet being exploited in the wild.

Here is my research:

·????????Intel's announcements (https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00562.html) do not say it is being exploited in the wild

·????????CVE and CVSS databases (https://www.first.org/cvss/calculator/3.1#CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H) do not state it is being exploited in the wild

·????????It is not listed by NIST/CISA in the Known Exploited Vulnerabilities Catalog (https://www.cisa.gov/known-exploited-vulnerabilities-catalog)

·????????None of the news stories (like https://securityonline.info/intel-rolls-out-bios-updates-to-fix-local-privilege-escalation-cve-2021-0157-vulnerabilities/) about the Intel vulnerability announcements say it is being exploited in the wild.

To be clear, none of the information I found actually stated whether the vulnerabilities were or were not being exploited in the wild. The current CVE CVSS scores for the vulnerabilities do not even cover any Temporal Score components, including the Exploit Code Maturity. But that is actually a great sign. Because any exploit being exploited in the wild is the top of criticality. If it was being exploited in the wild, the vendor, news stories, and CVSS rating would probably say so. Although not ultra-comforting, the absence of people and organizations not talking about public exploit code or active exploits in the wild is a great sign…and good enough for me to rely on until I hear otherwise.

On top of that, both exploits can only be exploited locally, require high privileges to accomplish in the first place, and are only elevation of privilege exploits. These factors make it highly likely that these exploits will not get released in the wild in the future. I could be wrong. But my best guess is that this exploit will not go viral.

Again, I could be wrong. Some hacker somewhere could publish an exploit code after reverse engineering the patch or someone could “worm it” and just embarrass me. But decades of past exploit experience tells me that I am probably safe in saying the it won't be exploited in the wild. And what experience tells me is that until an exploit ends up being exploited in the wild, at least once, there is no need to start overly worrying. There is no need to forsake other higher risk, currently being exploited in the wild vulnerabilities, to get these two applied. It doesn’t mean you shouldn’t apply them, just that if you’ve got some unpatched vulnerabilities that are being abused publicly, you should concentrate on them ahead of vulnerabilities that aren’t currently being abused in the wild.

As a related footnote, in 2017, Meltdown and Spectre (https://meltdownattack.com/) CPU vulnerabilities were announced. IMHO, they were probably the biggest and possibly most impactful vulnerabilities ever announced in the history of computers. It was a collection of bugs that impacted most modern-day CPUs (and not just one CPU manufacturer). If you did not patch the vulnerabilities, almost no other defense would work. Vulnerable, exploited computers would likely not only not stop the attacks, but not even show any evidence in their security logs that they had been successfully exploited. Demonstration code was shown (although not publicly released) in the original public announcement.?As far as vulnerabilities go, these were possibly as damaging as they come. There was not a patch management vendor that did not rate them with the highest criticality a vulnerability could get. Except for the fact that the exploit code was not publicly released and it was not being exploited in the wild. Those are big Ifs.

Because of the news stories and panicked senior management, most of the world rushed to apply the vendor patches. And for those who did early on, it caused big problems. Turns out the involved vendors ended up making some buggy patches (there was a lot of finger-pointing), and the patches caused a large percentage of machines to either lock up, reboot or significantly slowed performance. It took the involved vendors months to work out all of the patching bugs. And even now, over three years later, there has not been a publicly announced exploit in the wild (AFAIK). And if there is not even a single exploit in the wild, it really is not the highest risk no matter what your patching report says.?

In a sentence, concentrate the most and best on patching things actively being exploited in the wild.

It does not mean you should neglect other high-risk patches. You need to patch everything. But if you are trying to reduce vulnerability risk the most, perfectly patching 100% of the things being actively exploited in the wild means more than everything else you could patch. For most of us, this means we should strive to patch 100% of critical patches within 2 weeks (if not sooner). All of them. But spend extra time making sure that you have 100% patching compliance of the stuff being actively exploited in the wild. Recognize that actively exploited vulnerabilities are a special beast and deserve more time and attention. Do that one task well and you’re likely never to get exploited because of an unpatched vulnerability.