Colin Domoney, Senior Product Innovation Manager, Veracode, discusses why software developers must shift security into the development process.

The key findings of the Verizon 2016 Data Breach Investigation Report have, as ever, sparked debate between media outlets, vendors, and security experts alike.

However, the debate this year concerned the report’s list of top 10 vulnerabilities claimed by Verizon to be the cause of 85% of successful exploits, with many security professionals questioning just how reliable this list truly is. Highlighting that eight of the vulnerabilities are over 10 years old, the absence of common SQL and XSS flaws, which wreak havoc on the Adobe Flash Player, is causing concern.

The root of the problem seems to be Verizon’s research methodology for vulnerabilities and breaches. And the method accuracy aside, we must also question the logic behind creating such a list in the first place. Indeed, Verizon announces in the very same report that the 15% of successful exploits, which don’t originate from the ‘top 10 vulnerabilities’, still constitutes a significant number of breaches.

So as we continue to debate the top vulnerabilities responsible for the breaches, we risk veering away from the real issue. We should instead be focusing on how to better protect the applications that run our businesses and lives differently.

Ending reactive security

Over recent years, there has been a shift towards detect and response based security strategies, but these have not proven too effective in protecting data. Attackers are infiltrating networks and acquiring data quicker than ever, often faster than attacks can be detected. As such, malicious activity is often identified too late, if at all.

Verizon believes that “the detection deficit is getting worse”, with more than 67% of exfiltration occurring shortly after the breach. The report also revealed that in 2015, 84% of exploits took days or less, with fewer than 25% of these detected in the same period.

Detecting an attack after it has happened serves little benefit to organisations. It is more logical to strengthen the applications; the natural entry points. Especially as applications are inherently vulnerable and provide access to the IT infrastructure.

The rise of the application

Applications are entering the market at an exponential rate. The 2014 State of CIO report shows that the average US$500 million company has over 3000 applications, which constitutes 3000 points of entry. This was two years ago, and the average number of applications will only continue to increase as organisations increasingly depend on them to innovate, differentiate themselves in the market, and boost employee productivity.

This hasn’t gone unnoticed by hackers who are increasingly aware that applications constitute a low-resistance route to our private data. And yet, too frequently enterprise applications aren’t built with the necessary security measures to prevent these threats.

A new approach to application security

The Verizon DBIR results highlight that a new approach to security, one that takes into consideration our software-orientated environments, is necessary. For as the digital revolution continues the problem of insecure applications will only worsen. One solution is to co-ordinate security teams and development and to incorporate secure coding practices into DevOps procedures.

Introducing security in the development process, rather than simply securing the production phase alone, will help reduce organisations’ exposure to a range of vulnerabilities, and lower dependency on ‘top 10’ lists.

One of the greatest aspects of working in the security industry is that everybody works together to achieve a common aim – safer environments. We must, therefore, work to create an open, honest dialogue so security professionals can discover vulnerabilities and remediate them as quickly as possible.

No matter what mistakes Verizon’s researchers may have made with their methodology when reporting on the top vulnerabilities, I have no doubt that the next edition will address this. But, as security professionals, we should all be looking beyond retrospective analysis, as a means to suggest what attackers will do next.

The reality is that if we can prevent the vulnerability getting into the software in the first place, we can avoid the futile discussion as to which coding weakness attackers prefer. They always choose what they know will work. We also know that preventing bad code or vulnerable components appearing in software if the most effective play, by a wide margin. So relying on detection alone, especially when the breach may be in the rear-view mirror is always going to be a disappointing strategy.

Edited from press release by Cecilia Rehn.