The Verizon 2015 Data Breach Investigations Report has always had a conversational, quirky style to share some pretty technical information about the security breach data it analyzes. So if you’re wondering what Prince has to do with vulnerability management, just know that when you read the full report, you’ll understand – a lot of song titles are used to help give the detailed analysis a little fun. Bear with me then, as I extend the analogies and share some important vulnerability trends seen in this year’s report, and I have a little fun myself relating it to the lyrics of one of Prince’s big hits… Just know that “I was dreaming when I wrote this, so forgive me if it goes astray…” Also, I want to thank Kenna Security (formally known as Risk I/O), one of our Technology Alliance Partners, for working with Verizon to deliver vulnerability management data and valuable insights for the 2015 DBIR.
PRINCE AND THE OLD VULNERABILITY GENERATION
“Apparently, hackers really do still party like it’s 1999” (DBIR, pg. 15)
The DBIR folks took a look at the age of vulnerabilities exploited over the past year and found that CVEs dating back to the year 1999 were still being exploited by hackers in 2014. This is consistent with the original DBIR released back in 2008 where the authors concluded that nearly all exploited vulnerabilities could have been patched months, if not years earlier.
Source: 2015 Verizon DBIR, Risk I/O The 2014 findings support a key piece of advice from the inaugural DBIR: patch management should focus on “coverage and consistency” to prevent compromise, not scrambling to focus the latest branded vulnerability with a cool logo. Vulnerability management programs need coverage for these older CVEs since they are still being exploited today.
IF YOU DIDN’T COME TO PATCH, DON’T BOTHER KNOCKIN’ ON MY DOOR
“99.9% of the exploited vulnerabilities were compromised more than a year after the CVE was published.” (DBIR, pg. 15)
As the report suggests, your vulnerability management program should include coverage for older CVEs. Just because a CVE is old doesn’t mean it’s ignored by hackers. In fact, the opposite is often true. Numerous studies by SANS, the FBI and others have shown that a large proportion of system and network compromises have begun with successful attacks against very old vulnerabilities. Older, well-known vulnerabilities are the low-hanging fruit that are most widely targeted by automated malware tools. Vulnerability scoring that takes into account the age of the vulnerability can help prioritize patching and remediation efforts by increasing the score over time to reflect this progressive risk
C-V-E TWO THOUSAND ZERO ZERO PARTY OVER
“Ten CVEs account for almost 97% of the exploits observed in 2014” (DBIR, pg. 16)
Source: 2015 Verizon DBIR, Risk I/O According to Verizon, ten CVEs accounted for nearly 97% of the attacks in the 2014 report:
10. Vulnerabilities in a large number of SNMP implementations allow remote attackers to cause a denial of service or gain privileges (CVE-2002-0012)
9. Vulnerabilities in the SNMPv1 request handling of a large number of SNMP implementations allow remote attackers to cause a denial of service or gain privileges (CVE-2002-0013)
8. An SNMP community name is the default (e.g. public), null, or missing (CVE-1999-0517)
7. Memory leak in Terminal servers in Windows NT and Windows 2000 allows remote attackers to cause a denial of service (CVE-2001-0540)
6. SSL v3 protocol vulnerability, aka the vulnerability formerly known as "POODLE" (CVE-2014-3566)
5. The Remote Desktop Protocol (RDP) service in Microsoft Windows Server 2008 R2 and R2 SP1 and Windows 7 Gold and SP1 allows remote attackers to cause a denial of service (CVE-2012-0152)
4. Directory traversal vulnerability in ftpd in QPC QVT/Net 4.0 and AVT/Term 5.0 allows a remote attacker to traverse directories on the web server (CVE-2001-0680)
3. Directory traversal vulnerability in Pablo FTP server 1.0 build 9 and earlier allows remote authenticated users to list arbitrary directories (CVE-2002-1054)
2. Cross-site scripting (XSS) vulnerability in PHP Arena paFileDB 1.1.3 and 2.1.1 allows remote attackers to inject arbitrary web script or HTML (CVE-2002-1931)
1. Microsoft Windows XP and Windows 2000 does not notify the administrator when the log reaches its maximum size (CVE-2002-1932)
So, if you eliminate these CVEs in your environment you’re home free, right? Not so fast. The report points out that in addition to the top 10, there are 7 million other vulnerabilities that were exploited. Fixing 10 CVEs might be doable, but up to 7 million? Even if you were able to pause time to prevent new changes and vulnerabilities from entering your network, you’d never get anywhere near that number before it’s “party over, oops, out of time” due to resource constraints. You need to know what’s most important and what needs to be fixed first. Again, this is where vulnerability scoring can help by prioritizing the thousands or millions of vulnerabilities that need attention. Automated prioritization can take into consideration the likelihood of an attack on your organization based on the availability of automated exploit kits, as well as the potential impact on your business from a successful exploit.
I GOT A SANDWORM IN MY POCKET AND BABY HE'S READY TO ROAR
“Heartbleed, POODLE, Schannel, and Sandworm were all observed being exploited within a month of CVE publication date.” (DBIR, pg. 17)
The report did some analysis to uncover patterns that could be indicative of likeliness of exploitation by grouping CVEs and their scores into three buckets: 1. all vulnerabilities, 2. vulnerabilities exploited during 2014, and 3. vulnerabilities that were exploited within weeks after disclosure.
Source: 2015 Verizon DBIR, Risk I/O Looking at what gets exploited within a month of disclosure, most vulnerabilities scored a CVSS base score of nine or ten. This underlines the value of vulnerability prioritization such as CVSS to focus remediation resources on the best bang for the buck. In addition to CVSS scoring, the DBIR points out one other subjective attribute of “critical” vulnerabilities—branding. If a vulnerability gets a real name (not just a CVE identifier) and a cool logo it’s more likely to be exploited.
BUT LIFE IS JUST A PARTY AND PARTIES WEREN'T MEANT TO LAST
The vulnerability section of the DBIR closes out with the suggestion that remediation shouldn’t focus on which vulnerabilities to patch or not patch, but which vulnerability should be patched more quickly or outside normal patch cycles. I agree, and again suggest prioritization along with business context as the solution. By focusing remediation efforts on the highest risk hosts and the highest scoring vulnerabilities, you can achieve the greatest possible risk reduction with available resources. If you want to take a deeper dive on the technical side of vulnerability prioritization, check out our whitepaper on risk-based scoring.
