In my earlier article, I discussed how the OWASP Top 10 carries many of the same issues forward over the 18 years it has been in existence, which is a symptom of a more significant problem. While we at Security Innovation are great supporters of OWASP and the Top 10 list, clearly having a list hasn’t been enough. If we were solving old vulnerabilities and replacing them on the list, the idea of focusing on the top 10 would have been borne out, but this has not been the case.
The problem is that looking at web application security from a top ten most significant issues perspective to provide a place to focus on has been limiting. It has given some organizations a bare minimum to work towards and has not created the necessary change in building applications securely. The real solution is to bring security on par with performance and stability as critical requirements.
I suggested a world in which there might be a ticket that looks like this:
P1 – Must be in MVP
User Story: As a Hacker, I want to steal the organization’s sensitive data to make money on the dark web.
Result: Action is prevented.
Acceptance Criteria:
- All checked in code peer-reviewed by certified security engineer, level 2 or above
- All checked in code meets parameters established in the Threat Model
- The application passes all QA xAST scans with no severity 1 vulnerabilities
- Application passes unannounced, unlimited penetration test with no severity 1 vulnerabilities
I also suggested other tickets around threats such as ransomware or hijacking systems resources for bitcoin mining. Of course, as soon as I wrote the above ticket, I could picture the sprint planning session looking at this ticket and adding:
Story Points: One million
This does look like a lot of work, but if we break down the acceptance criteria, we can see that this can save time or at least not be onerous in both the long and short run. First, ensuring that code is peer-reviewed is good practice regardless and can find costly bugs of all types. Having engineers trained to recognize security flaws in code only makes them better engineers, and a few well-trained security champions can cover many check-ins. Even more basic training for those writing the code will prevent most of the problems in the first place.
Enter Threat Modeling
Looking at the ticket itself, you can see it implementing an aspect of a threat model. We have determined we have sensitive information that needs protection and will address the threat of data theft. The threat model will go into more detail about how. For example, it might require that all sensitive data is stored encrypted, so this second bullet will ensure any use of data doesn’t leave it around unencrypted, among other security requirements dictated by the threat model.
Next up - Pentesting
The next two bullets are around testing, automated and manual. xAST (SAST, DAST, and IAST) scans require time and money to acquire the scanner and learn how to use it properly, but once up and running, such testing can become an integral, automated part of the DevOps process. Pentesting is the manual testing for security, which can be internal, or even better, carried out by an independent organization with a specialty in the skills required – or a combination of both. If pentesting internally, this is another opportunity for developing specialized skills that a security champion would relish.
So, broken down, this isn’t bad at all and could even make the process more efficient. Preventing bugs (shifting security left) will prove less costly and time-consuming than finding them later, during the project, and after. Enhancing testing for security (shifting security right) will ensure finding more issues before they end up in deployed applications. The OWASP Top 10 can serve as a helpful reference for P1 issue categories (among others determined by the threat model).
OWASP Top 10's role
As we can see, the OWASP Top 10, despite the lack of changes over 18 years, is still a valuable tool as part of an overall approach to building web applications more securely – training, peer review, security testing, threat modeling, etc. Using it as a guide and as part of the prioritization process can help focus the SecDevOps approach.
Using the OWASP Top 10 as a list of the only software security risk to address in a haphazard way to avoid going deeper will doom the industry to continue to repeat the same costly security mistakes.
About Fred Pinkett, Senior Director Product Management
Fred Pinkett is the Senior Director of Product Management for Security Innovation. Prior to this role, he was at Absorb, Security Innovation's learning management system partner. In his second stint with the company, he is the first product manager for Security Innovation's computer-based training. Fred has deep experience in security and cloud storage, including time at RSA, Nasuni, Core Security, and several other startups. He holds an MBA from Boston College and a BS in Computer Science from MIT. Working at both Security Innovation and Absorb, Fred clearly can't stay away from the intersection between application security and learning. Connect with him on LinkedIn.
