What to make of the new 2021 OWASP Top 10 vulnerability rankings? The industry comments
This year's Open Web Application Security Project list is out, with novel categories and a new number one
The new OWASP Top 10 list, published this month, has a new chief villain. Move over Injection vulnerabilities, the biggest and baddest category in town is now Broken Access Control.
Injection vulnerabilities topped the OWASP (Open Web Application Security Project) list for many years, partly because of the broad range of techniques and flaws the term covers, ranging from SQL injections to OS command injection attacks, but this category now finds itself in third place, behind Broken Access Control and Cryptographic Failures.
Broken Access Control vulnerabilities are often introduced as applications and environments evolve. They include failures in permissions systems that allow vertical and horizontal privilege escalation. Meanwhile, Cryptographic Failures cover hard-coded or weak passwords, broken or risky cryptographic algorithms and insufficient entropy when creating keys.
There are three new categories in the 2021 OWASP Top 10 too.
At number 4 we have Insecure Design, referring to software that cannot be fixed by a perfect implementation since the underlying code is insecure.
Software and Data Integrity Failures are at number 8, encompassing false assumptions made about automated processes and CI/CD pipelines.
Meanwhile at number 10 we see Server-Side Request forgery (SSRF), a class of vulnerability which allows an attacker to induce a server-side application to make HTTP requests to an arbitrary domain.
Other categories have been consolidated and merged in the new Top 10.
The OWASP Top 10 list is intended to raise awareness of common vulnerabilities among developers. We asked a number of industry players how useful they believe it is to developers and security professionals, and what they think about this year's rankings.
Computing: What do you make of this year's changes, and how important are they?
Etienne Hodder, senior information security consultant for eSentire: The most important changes would be the introduction of three new categories: Insecure Design, Software and Data Integrity Failures and Server -Side Request Forgery. With a focus on emerging threats against web applications, the first two of these new categories further emphasize the need to protect the integrity of apps across the entire software development life cycle (SDLC) - the infamous 2020 SolarWinds breach being a clear example of software integrity failure.
The new additions to the Top 10 are the most interesting ones to look at - Iain Chidgey, Sumo Logic
Iain Chidgey, vice president EMEA, Sumo Logic: The new additions to the Top 10 are the most interesting ones to look at, as they show where developers and security teams face the most pressure and have to upskill. For example, the category of Insecure Design covers how applications are architected and built. Microservices-based applications are more popular with developers when it comes to design and development, and they are now responsible for generating revenue for business.
Fred Wilmot, CISO JumpCloud: The critical changes in the Top 10 list, include a better focus on today's CI/CD pipelines and deployment approaches incorporating cloud architecture, and addresses the well-known complexity of ‘well architected' does not mean ‘well implemented'. Among the challenges of building well architected solutions are critical libraries for logging, design ideation on authentication methodologies, and data integrity are critical to the entirety of a service model.
Paul Baird, chief technical security officer UK, Qualys: There are some important changes to the Top 10 categories in this report, such as a clear shift to focus on making web applications as secure as they can be before going live. Exploitability and impact data has also been implemented for the first time, which adds further weight and validity to the list.
How important are these kinds of changes, and how will they help security and development teams?
Wilmot: These changes are critical when we think about addressing the entire software development lifecycle with modern tooling. In some cases, we look at sanitisation, input validation, CSRF, SSRF, XSS as lightweight fixes, but truly getting into things like cryptographic failures, logging/monitoring, misconfigurations, and vulnerable components- they are across the design of a cloud service, rather than just the implementation of a web server. This also closely aligns with how we think about operational risk and where security fits into product development as a capability. Not all risk has a CVE or CWE attached to it, which makes the fix more complex, and muddies the water for clear execution to remedy.
Security teams should incorporate recurring detection for the OWASP categories in production - Etienne Hodder, eSentire
Hodder: Security teams should incorporate recurring detection for the OWASP categories in production, such as adopting a dynamic application security testing (DAST) tool with recurring scheduled scans and providing visibility of the results to the development team. Development team leaders should also ensure enough time is allocated to provide adequate training and allow all contributors to perform thorough testing throughout the design phase.
Chidgey: Rankings like these help security teams get support internally. It helps them get the time and budget from their department to look at these issues seriously, and it helps them get support from their peers as part of their workflows and processes.
The schedule for these updates isn't in line with the significant pace of change we're seeing, Paul Baird, Qualys
Baird: The report uses the largest application security data set available with data from more than 500,000 applications, so the findings have merit and are incredibly important to the industry. However, the schedule for these updates isn't in line with the significant pace of change we're seeing in the industry today. Bad actors are invigorating their tactics constantly, and we as an industry need to keep up.
Is there a danger that lists like these could encourage teams to look at security as a box-ticking exercise, rather than thinking strategically?
Wilmott: I think the opposite. When we look at developing an idea, we have design principles we can measure through OWASP, earlier in the process through tooling and discussion, that surfaces or validates security teams' concerns based on industry practice.
Hodder: With the OWASP 2021 update being more heavily data-driven than its previous iteration, teams should find that the category structure and descriptions now more closely match their current understanding of application vulnerabilities across their organisation, hopefully encouraging engagement beyond previous box-ticking exercises.
Chidgey: Security teams know that these frameworks are not the be-all-and-end-all of security. Where they help is to support the business case around investment or around making changes to how security processes work. I think the biggest change is how much emphasis there is on getting security right across the development process. While we have seen breaches linked to faults in the software supply chain get big headlines, many security and developer teams want more guidance on how to check the integrity of their supply chains around things like continuous integration / continuous deployment.
Baird: The OWASP Top 10 list should never be seen as an exhaustive checklist. It was designed to function as a methodology with guidance on the direction you need to take to be more secure. Ultimately, it should be combined with web application scanning tools that deliver a more accurate picture that relates to an organisation's own network.
What does this year's Top 10 show about the future for app development and security teams working together in practice?
Baird: It highlights the need for them to do exactly that - work together in practice. There is a clear shift this year on making applications secure before release which reiterates how important the relationship is between the two teams. Yet, there still seems to be a political divide between the two. The teams need to come together to support the business that they both work for.
Hodder: Corporate leadership should strive for more collaboration between app dev and security teams and re-evaluate their current SDLC to incorporate the security team. There may even be new opportunities for career shifts between both teams, providing organisations with stronger, security-minded application dev teams.
It helps establish a common bridge between product/engineering and security teams aside from JIRA tickets - Fred Wilmot, JumpCloud
Wilmott: It helps establish a common bridge between product/engineering and security teams aside from JIRA tickets.
Chidgey: The Top 10 provides a great guide for where to prioritise around DevOps and security, but this is just a starting point when it comes to understanding what is going on in terms of data.