Reducing Your Breach Risk

DZone 's Guide to

Reducing Your Breach Risk

Web app vulnerabilities aren't anything to shy away from. They are affecting every industry—including yours. The data is here to show it.

· Web Dev Zone ·
Free Resource

Every year, the fine folks at Verizon Enterprise, along with a slew of the world's major networking/telecom companies, financial institutions, cybersecurity technology firms, a number of government agencies, and computer emergency response teams, share data about web application security policy, as well as incidents and breaches they have investigated that year. The end result is the annual Verizon Data Breach Investigations Report (VBDIR).

In this blog post, I will highlight a few of the key findings and suggest a few things you can do today to significantly reduce the risk of enterprise application security breaches impacting your business.

Web app vulnerabilities aren't anything to shy away from. They are affecting every industry—including yours. The data is here to show it.

Before we dive into the numbers, though, it's important to note that a breach and an incident are not the same as far as the VBDIR is concerned:

  • An incident is defined as "a security event that compromises the integrity, confidentiality, or availability of an information asset"
  • A breach, on the other hand, is "a confirmed disclosure (not just potential) of data to an unauthorized party"

The subtle difference here is important. If your valuable data (customer details, PII, PCI, etc.) ends up on a Pastebin somewhere (or sold on the dark web); you've suffered a breach. If you were simply a victim of a DDoS attack, you experienced an incident (there was no disclosure of data).

Why is this important? DDoSs are annoying, and they cost your business money. They are relatively trivial for the bad guys to pull off, but also pretty easy to defend against. Breaches require more work by the attackers but are much more lucrative; these types of network security attacks are much harder to defend against.

Incidents are annoying, but breaches can be devastating. Here are some facts from the report, which covers calendar year 2015:

  • There were 3,141 confirmed breaches and more than 100,000 incidents.
  • Financial gain is still the top motive. Espionage is a distant second, and everything else is tiny in comparison.
    • 89% of breaches had a financial or espionage motive.
    • 95% of confirmed web app breaches were financially motivated.
  • External threat actors still account for more than 80% of breaches; internal attackers were a distant second (less than 20%).

That means 2015 saw more than 3,000 confirmed data breaches perpetrated by external threat actors with financial motives.

How do these breaches happen? The number one cause, at 40% of all breaches, was attacks on web application technologies.


Web app attacks are also an equal-opportunity threat affecting almost every industry.


What are the bad guys using to penetrate secure web applications? Most successful attacks were achieved through one or more of the following tactics:

  • Stolen credentials
  • Web Shells/backdoors
  • Malware
  • SQL injection
  • RFI
  • Brute force

Most organizations, when they're addressing web application security best practices, are focused on penetration testing, blocking the OWASP Top Ten, and configuring Web Application Firewalls (WAFs)—the hurdle you need to clear for compliance. But hackers are prepared to jump much higher, so these strategies alone are not effective in preventing web app breaches:

  • Today's websites and their associated apps live in a complex, dynamic environment with little standardization—and little app security expertise.
  • People use the same credentials for low- and high-security online accounts.
  • When hackers breach a database, like Ashley Madison, they can be pretty sure some of those user credentials will give them access to far more valuable data than dating preferences.
  • Phishing and other social engineering techniques still work—because people are still the weakest link in any security chain.
  • All these stolen credentials are available for sale at for a few dollars a piece on the dark web.
  • Writing apps is easy—writing apps securely is hard
  • Just because you haven't been hacked yet doesn't mean you're secure—it just means you've been lucky (or really unlucky, and you just don’t know it yet). It doesn't mean you can lighten up on the security effort.

Credential stuffing is a big deal these days. The bad guys don't need to waste time trying to work out how to break into a system when there are 866M known username or email and password combinations out in the wild. Want to log into the corporate site of a big Wall Street firm? Just look for that domain in the email addresses in that giant list. In an ironic twist, PwnedList, a company that maintained a leaked credentials list, was itself hacked earlier this month.

That's not to say that SQLi, RFI, and other OWASP Top Ten threats are not important—they are, but attackers will always jump the lowest fence first.

What’s particularly worrying about unsecured web applications being the major attack vector is that they were also the top attack vector in the previous year's report, too. It's further evidence that traditional web application protection measures aren't working.


So what do the report's authors recommend to prevent web applications security vulnerabilities taking the No. 1 slot for the third year?

  1. Start by assuming the bad guys already have your users' and employees' credentials and look for solutions that can mitigate web application security breaches "after the fact."
  2. Do a web application vulnerability assessment ( SQLi, XSS, RCE, RFI/LFI, etc). It's not a silver bullet, as we've already seen, but it is at least a foundation, and newer technologies like RASP can automatically reduce the effort required to do this.
  3. Fix your own security bugs, and patch/upgrade to the safest versions of the libraries and frameworks that make up your web application security assessment.

By following these steps, you're already starting to make life harder for the bad guys. But they're smart, and they will keep trying. Which is why we built IMMUNIO—because web applications are inherently insecure. It is far more difficult to build web applications securely, which is precisely why we built a solution that can drastically reduce the risk factors outlined above (stolen credentials, input validation type issues, and dealing with web application vulnerability in your out-of-date code).

What are you doing to secure your web applications, the No. 1 source of security and data breaches?

And when will it be too late to find a solution?

risk, security flaw

Published at DZone with permission of Zaid Al Hamami . See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}