I recently covered a few sections from the Verizon Data Breach Investigations Report (take a look if you haven’t already).  I also mentioned another one of my favorites, the WhiteHat Security Website Security Statistics Report.  This report gives an insightful overview of a constantly evolving and frequently targeted attack vector, web applications.  Ignoring my strong bias (I may or may not specialize in web application security), it’s one of the most informative, interesting reports you can read this year.  The report can be found here.

The authors make some notable points just in the introduction.  Web application breaches are so common in this day and age that only the largest breaches gain attention from the media. Think about the breaches you read about in 2014.  Home Depot, JP Morgan Chase, and Sony probably come to mind.  The full list is impressive (and a little scary).  Here’s a few other breaches that occurred during 2014:

I have to be honest, I had a hard time picking just a handful of examples.  I found a very detailed list at the Identity Theft Resource Center here that details each breach for each category, as well as the number of records lost (if known).  Let’s dive into the fun stuff.

Vulnerability Likelihood

These numbers weren’t entirely shocking to me.  Coming in at #1 is insufficient transport layer protection, affecting 70% of all applications.  With all the recent SSL/TLS zero-days, it’s not shocking.  From 0% in 2010 to 70% likelihood in 2014, it’s become the vulnerability to look out for.  From my experience, the problem stems from the difficult process of upgrading everything on the back-end to be compatible with TLS 1.2.  It’s important for management and executives to understand the risks of leaving a vulnerability like this open.  Heartbleed is being blamed for one of the largest data breaches in the medical industry.  In April of 2014, Community Health Systems Inc. was breached, exposing personal data of 4.5 million patients.  The PCI-DSS standards make it perfectly clear that TLS 1.2 is absolutely necessary, as well as disabling any weak encryption ciphers to ensure that your sensitive data is being transported as securely as possible.

Coming in second is information leakage at 56%.  These numbers haven’t change much from the 58% in 2012.  Honestly, this is the bane of my existence.  The moment I find one stack trace, I know the rest of them are going to come crawling out of the walls like cockroaches.  Please, developers of the world, e.printStackTrace() is not the answer to every error or application failure.

And finally third, your favorite and mine, cross site scripting.  There’s good news though, there has been a significant decline in the number of applications affected by cross site scripting.  In 2014, the likelihood of an application being vulnerable to cross site scripting is 47%, compared to 53% in 2012.  All those meetings and walk-throughs are finally paying off!

There are some variations throughout different industries.  The table below shows the likelihood of each vulnerability in each industry:

Compared to all the industries, the information sector is doing pretty well for itself with two of the lowest likelihoods.  I wouldn’t call it secure with a 65% likelihood of having insufficient transport layer protection, but that’s a significant improvement over the 76% in the financial/insurance sector.

Surveys on Surveys on Surveys

WhiteHat provides an analysis based on survey responses from 118 security professionals.  The data gathered from this gives a clear view of how application security programs affect various organizations.  A couple of things to note before diving into a couple of sections:

• Information and Finance/Insurance have the highest number of responses
• There is not enough data from the other industries to draw meaningful conclusions

Who is held accountable if there is a data breach?

Pretty interesting.  When the board of directors is held accountable, open vulnerabilities are at their lowest and remediation rates are at their highest.  Although, when the security team is held accountable, there average number of open vulnerabilities is highest.

What is your organization’s driver for resolving vulnerabilities?

Yeah, that seems about right to me.  A 0% remediation rate when corporate policy is the driver for remediation.  I’ve been on conference calls about some vulnerabilities, and the moment I mention it’s corporate policy I’m pretty sure they mute their phones to laugh.  That all changes when I send them the excerpt from the PCI-DSS standards.  Remediation driven by compliance yields the highest remediation rate at 86%.  Another number to note, when customer demand is the driver for resolving vulnerabilities, the average time open sky rockets to 559 days (holy $#!+).

How often does the QA team perform basic adversarial test?

How frequently does your organization perform ad hoc code reviews?

I’d love to dive in even further, but there’s just so much information condensed into this report.  If you work with application security, I highly recommend taking a look through and applying some of the data and statistics to your team.  I was able to find some interesting points to talk about with my team.

Thanks for reading!