{"id":13030,"date":"2019-03-26T16:51:52","date_gmt":"2019-03-26T12:51:52","guid":{"rendered":"https:\/\/me-en.kaspersky.com\/blog\/patching-strategy-rsa2019\/13030\/"},"modified":"2019-11-15T15:22:24","modified_gmt":"2019-11-15T11:22:24","slug":"patching-strategy-rsa2019","status":"publish","type":"post","link":"https:\/\/me-en.kaspersky.com\/blog\/patching-strategy-rsa2019\/13030\/","title":{"rendered":"RSAC 2019: Seeking the perfect patching strategy"},"content":{"rendered":"

\u201cExcuse me, sir, do you have a moment to talk about security updates?\u201d<\/p>\n

\u201cNope, too busy installing patches.\u201d<\/p>\n

Seriously, though, it\u2019s worth pausing to think about how effectively (or not) you are managing patches.<\/p>\n

In a perfect world, you would install all patches for all software in use at your company as soon as they rolled out. But in real life, things are a little more complicated, and there\u2019s never enough time for all patches\u00a0\u2014 so you have to prioritize. But how best to do it?<\/p>\n

At the RSA Conference 2019, Jay Jacobs of the Cyenta Institute and Michael Roytman of Kenna Security<\/a> presented a study entitled \u201cThe Etiology<\/a> of Vulnerability Exploitation.\u201d The well-argued report addressed what vulnerabilities are worthy of increased attention and how to dramatically improve patch installation and security update strategy.<\/p>\n

The basic premise is that not all vulnerabilities are exploited in practice. Assuming that\u2019s true, a great many updates can safely be pushed back, giving priority to vulnerabilities that really can (and most likely will) be used in an attack. But how does one distinguish \u201cdangerous\u201d vulnerabilities from the \u201cmostly harmless\u201d variety?<\/p>\n

Armed with descriptions from the CVE (Common Vulnerabilities and Exposures)\u00a0database and publicly available exploit databases, as well as data from vulnerability scanners and IPS\/IDS systems (a total of 7.3 billion attack records and 2.8 billion vulnerabilities in 13 million systems), the researchers built a model that handles the task pretty well. To put that into perspective requires a small bit of analysis of the vulnerability landscape.<\/p>\n\n

How many CVEs exist in the wild?<\/h2>\n

Any information security expert will tell you that the number of known vulnerabilities is huge. But not many (if any) know the precise figure. At present, about 108,000 CVEs have been published.<\/p>\n

Bear in mind also that in the past couple of years, the rate of monthly publications has risen: If during the years 2005\u20132017 about 300\u2013500 CVEs were published every month, at the end of 2017 the average monthly value shot past 1,000 and has stayed that high ever since. Think about it: That\u2019s dozens of new bugs every day!<\/p>\n

\"CVE<\/a><\/p>\n

The existence of an exploit generally becomes known either shortly before or immediately after the relevant CVE is published. There are exceptions, but in most cases the window is plus or minus two weeks around the date of CVE publication. So CVEs demand a quick response.<\/p>\n

\"In<\/a><\/p>\n

It goes without saying that update install rates lag somewhat behind. On the average, a month after detection only a quarter of vulnerabilities are patched. It takes 100 days to eliminate half, and a quarter remain unpatched a year later.<\/p>\n

\"On<\/a><\/p>\n

More than two-thirds of unpatched vulnerabilities exist in products from just three vendors. No marks for guessing which vendors and which products:<\/p>\n

\"More<\/a><\/p>\n

\"Products<\/a><\/p>\n

Meanwhile, 77% of CVEs have no published exploit. Also of interest is that not all published vulnerabilities are encountered in real world environments\u00a0\u2014 only 37,000 of the 108,000 CVEs in existence. And only 5,000 CVEs simultaneously exist in the wild and are exploitable. It is these vulnerabilities that should em> be prioritized\u00a0\u2014 they just need to be correctly identified.<\/p>\n

\"Of<\/a><\/p>\n

Existing patching strategies<\/h2>\n

The researchers measured the relevance of the patching strategies against two metrics: The share of \u201cdangerous\u201d vulnerabilities in the total number of patched ones (efficiency), and conversely, the share of patched vulnerabilities in the total number of \u201cdangerous\u201d ones (coverage).<\/p>\n

\"The<\/a>

If this picture looks familiar, that\u2019s probably because it\u2019s nothing new<\/a><\/p><\/div>\n

One of the generally accepted patching strategies is based on the Common Vulnerability Scoring System (CVSS), whereby priority is assigned to CVSS scores above a particular value. Calculating the efficiency and coverage for CVSS 10 gives 23% and 7%, respectively. Interestingly, the very same result (at least by these metrics) can be achieved by randomly installing patches.<\/p>\n

\"The<\/a><\/p>\n

The most common approach\u00a0\u2014 patch everything with a \u201chigh\u201d CVSS score (7 or above)\u00a0\u2014 produces markedly better results. This approach is not bad on the whole, but it\u2019s time-consuming because it means having to prioritize the installation of a large number of patches.<\/p>\n

\"Comparing<\/a><\/p>\n

An alternative strategy would be to prioritize patching by vendor. After all, developers have different ratios of the number of actual exploits to the total number of CVEs, so it would be logical to prioritize those whose products contain vulnerabilities that are more likely to be exploited in practice.<\/p>\n

\"Vulnerabilities<\/a><\/p>\n

However, based on efficiency and coverage, this strategy turns out to be worse than random patching \u2014 it\u2019s about half as effective.<\/p>\n

\"Vendor-based<\/a><\/p>\n

So in the long run, this approach is even less relevant than one based on CVSS.<\/p>\n

Probability computation model for vulnerability exploitation<\/h2>\n

This brings us back to the model built by the researchers. Comparing data from the CVE descriptions, publicly available exploit databases, and IPS\/IDS systems, the team was able to identify a set of signs influencing the probability of a vulnerability being exploited in practice.<\/p>\n

For example, on the one hand, signs such as a CVE reference from Microsoft, or the presence of an exploit in Metasploit, drastically increase the likelihood of exploitation of the vulnerability in question.<\/p>\n

\"The<\/a><\/p>\n

Some signs, on the other hand, reduce the probability of exploitation \u2014 such as a vulnerability being in the Safari browser, an exploit that was published in the ExploitDB database (which is not very convenient for practical purposes), the presence of the terms \u201cauthenticated\u201d or \u201cdouble free memory\u201d in the CVE descriptions, and others. Combining these factors, researchers could compute the probability of any particular vulnerability being exploited.<\/p>\n

\"Some<\/a><\/p>\n

To verify the accuracy of the model, the researchers compared their predictions with data from real attacks. Here\u2019s what they found:<\/p>\n