What’s New in OWASP: APIs and Mitigation

There are a lot of articles on, and attention being paid to, cybersecurity. This is largely driven by record-breaking breach costs and numbers, combined with new proposed legislation both in the U.S. and abroad. OWASP has maintained the same Top 10 Application Vulnerabilities since 2013. As I was reading the proposed OWASP Top 10 for 2017 and preparing to submit my input, I thought I’d provide a brief recap of the changes here, and share the two large changes that stood out for me.

The proposed OWASP 2017 changes contain a merge of two previous categories, two new categories, and one dropped category. Here’s a quick summary of the two changes that caught my attention and what they mean to most companies.

The first big change is OWASP is now stating that companies need to have some sort of WAF or RASP technology to detect, respond, and patch. I believe this is going to be controversial as it’s addressing the topic of mitigation for a vulnerability and not, itself, a vulnerability. The OWASP list has historically been focused on vulnerabilities and how to fix or protect against those threats. With this change, OWASP is now saying that since the lag between a vulnerability being discovered and remediated is so extensive for most organizations, a 3rd party service or tool is needed.

From their notes:

2017-A7: Insufficient Attack Protection: “Based on the data call, we see that the majority of applications and APIs lack basic capabilities to detect, prevent, and respond to both manual and automated attacks. Application and API owners also need to be able to deploy patches quickly to protect against attacks.”

The next important change regards the protection of APIs. APIs have become the standard building block for applications; APIs make it easy for other systems to quickly integrate into an application, but that also opens some big holes for vulnerabilities. OWASP is recognizing the changing landscape of app development and stating that APIs must also get the same attention and vulnerability assessments rigor as web or mobile applications.

2017-A10: Under-protected APIs: Modern applications and APIs often involve rich client applications, such as JavaScript in the browser and mobile apps, that connect to an API of some kind (SOAP/XML, REST/JSON, RPC, GWT, etc.). These APIs are often unprotected and contain numerous vulnerabilities. We include it here to help organizations focus on this major emerging exposure.

At WhiteHat, we have noticed that APIs are becoming more prevalent, and securing them is often ignored or, at best, an afterthought. This recognition of APIs as a distinct application ingredient in need of securing is a great change. It really speaks to the changing dynamic of how we develop applications and build them for modern consumption.

These changes are welcome and show me that OWASP is looking at current vulnerability statistics as well as future trends. However, we cannot wait another four years to evolve our approach and identify new threats. The development landscape changes by the day, and new threats are detected and identified in an instant.

WhiteHat has long believed in solid technology partnerships in both WAF and RASP technologies. I think we all need to be honest about the length of time it takes to remediate a vulnerability in many organizations, and help customers understand where they may need to invest based on their WSI scores as part of a risk assessment exercise.

The security industry needs to get in the development mindset and become much more Agile to changing threats. This definitely includes discussing vulnerabilities in APIs. If this also needs to include mitigation as an alternative to pure-play remediation, I’m for it.