Jacob Kaplan-Moss

2016 DBIR Highlights

I wrote this post in 2016, more than 6 years ago. It may be very out of date, partially or totally incorrect. I may even no longer agree with this, or might approach things differently if I wrote this post today. I rarely edit posts after writing them, but if I have there'll be a note at the bottom about what I changed and why. If something in this post is actively harmful or dangerous please get in touch and I'll fix it.

The 2016 edition of Verizon’s Data Breach Investigations Report is out, and as usual it’s compelling reading. The DBIR is one of the only sources of hard data about information security, which makes it a must-read for anyone trying to run a security program in a data-driven manner.

What follows are the bits that I found especially interesting, and a bit of my own commentary.

Internal threats are rare

[T]he Actors in breaches are predominantly external. While this goes against InfoSec folklore, the story the data consistently tells is that, when it comes to data disclosure, the attacker is not coming from inside the house. And let’s face it, no matter how big your house may be there are more folks outside it than there are inside it. [7]

Internal threats are the scariest, because they know the most about us, and can do the most damage. But the data shows that they make up a fairly small minority of attackers (less than 20%), so we should be cautious about the level of investment we make against internal actors.

On vulnerabilities and patching

Standard patch timelines are reasonable-ish, but could be more data-driven


Figure 10 is a box plot, which plots the time between publication and the first observed successful exploit by vendors. We can see that Adobe vulnerabilities are exploited quickly, while Mozilla vulnerabilities take much longer to exploit after disclosure. Half of all exploitations happen between 10 and 100 days after the vulnerability is published, with the median around 30 days. This provides us with some general guidelines on which software vulnerabilities to prioritize along with some guidance on time-to- patch targets. [14]

Typically, companies have established patch timelines; 30/60/90 for high/med/low is fairly common. This data suggests that

  1. those timelines are probably about right in general (though more aggressive would always be better), but
  2. we probably should be including the vendor in our risk analysis, and seeking to patch vulns from specific vendors according to more aggressive timelines.

We’re keeping up on new vulns, but old vulns are a huge problem

Basically, we confirmed across multiple datasets that we are treading water—we aren’t sinking in new vulnerabilities, but we’re also not swimming to the land of instantaneous remediation and vuln-free assets. However, all that patching is for naught if we’re not patching the right things. If we’re going to tread, let’s tread wisely. [15]

The good news is that we’re not getting worse over time, but…


Figure 12 arranges CVEs according to publication year and gives a count of CVEs for each year. While 2015 was no chump when it came to successfully exploited CVEs, the tally of really old CVEs which still get exploited in 2015 suggests that the oldies are still goodies. [15]

The bad news is that if we’re just barely keeping up with new vulnerabilities, it means we’re not catching up on old ones. The length of that long tail is truly terrifying – there are exploits happening today for issues discovered nearly two decades ago.

Phishing is tremendously effective

In this year’s dataset, 30% of phishing messages were opened by the target across all campaigns. […] About 12% went on to click the malicious attachment or link and thus enabled the attack to succeed. […]. The median time for the first user of a phishing campaign to open the malicious email is 1 minute, 40 seconds. The median time to the first click on the attachment was 3 minutes, 45 seconds. [18]

Phishing is tremendously effective. This 12% success rate means that an attacker only needs to send about 35 phishing emails to have a 99% chance of being successful. Fuck.

Web AppSec efforts should be focused on financial data

The DBIR finds that “95% of confirmed web app breaches were financially motivated” [28]. This is pretty great data for AppSec practitioners; it means we can risk model our web apps with a high degree of certainty. We should focus our AppSec efforts on those apps where a compromise would have financial reward, and view all other web apps as much lower risk.

Security controls in haiku form are the best thing ever

People lose things all the time—this is not new or particularly newsworthy. It is, however, a real-world pain in the neck for organizations that are at best replacing Scooter’s laptop, or at worse scrambling around to figure out if there was PII on the device and whether encryption had been implemented. […] So, to sum this pattern up in haiku form:

Employees lose things

Bad guys also steal your stuff

Full disk encryption

I love everything about this.