Industry Observations

OWASP – The Superhero of AppSec

The security industry needs unbiased sources of information who share best practices with an active membership body who advocates for open standards. In the AppSec world, one of the best is the Open Web Application Security Project (or OWASP).

Standards and best practices have to evolve over time. Earlier this year, the OWASP community issued a request for comments (RFC) on updates that added a risk category for unmitigated issues, which implies a very true fact that many vulnerabilities stay open for a long time. As a security industry, web applications are the least attended to in priority in terms of funding, attention, and program support. (Back in April I was interviewed on my thoughts on the 2017 proposed OWASP updates to the 10 Most Critical Application Security Risks.)

That version of the RFC didn’t pass as written, but a very similar version was finalized November 18:

OWASP

Summary of New Items:

A4 – XML External Entities: Attackers can exploit vulnerable XML processors if they can upload XML or include hostile content in an XML document, exploiting vulnerable code, dependencies or integrations. These flaws can be used to extract data, execute a remote request from the server, scan internal systems, perform a denial of service attack as well as execute other attacks. This is more easily tested for via source code scanning (SAST) or manual business logic tests.

A8 – Insecure Deserialization: Exploitation of deserialization is somewhat difficult, as off-the-shelf exploits rarely work without changes or tweaks to the underlying exploit code. However, the impact of deserialization flaws can be dire, leading to remote code execution attacks. This, also, is most easily detected via SAST technology.

A10 – Insufficient Logging & Monitoring: This isn’t, technically, a vulnerability in code or business logic which is being exploited, which is why this entry has been somewhat controversial. As I noted in the 2017 draft, this entry isn’t inherently a vulnerability, however, it still counts as a website risk due to a lack of monitoring or timely response to events – and a limitation of the logging available for cyber investigators to determine what precisely happened during a web application-based incident. Websites need logging turned on, but at the same time need to avoid printing log results to the console or a plain text file within the application which can, in turn, be accessed and erased or tampered with.

We’re exploring multiple ways of determining the various mitigation methods to offset this risk, including projects such as scanning API calls which handle logging or integration with other security devices for mitigation, monitoring, and logging. This is a very exciting opportunity to educate our own customers on what they’re doing right, could improve, or need to work on in terms of averting risk. Because A10 isn’t a vulnerability covered by an obvious scan rule pack, we have a great opportunity to find multiple approaches to identifying this risk for our customers and helping them with remediation, mitigation, or in the case of WAF, RASP, and NGFW technologies, virtual patching.

Security controls and ecosystem inter-weaving is the best way to secure the whole software development lifecycle. And you know the best thing about open standards in security projects like the Top 10 list?

You can be a superhero and start your own. OWASP provides a forum here.