Four years after the last edition of the Open Web Application Security Project (OWASP) Top 10 was published, the team has released its new draft for community feedback and discussion.
The list, currently in Beta form here, adds three new categories for security teams to concentrate on, and consolidates some of the existing categories to make it easier to manage. So what can we learn from the new list, asks Paul Baird, Chief Technical Security Officer UK, Qualys and what does it mean in context?
What is new in this guidance?
What is important to stress is that this update to the OWASP Top 10 uses the largest application security data set available, based on information from more than 500,000 applications. Rather than being solely based on opinions and suggestions from the great and the good of the security sector, it is based on hard data.
This means the findings have real merit for CISOs and their teams, and the work done here is incredibly important to the industry as a whole.
There is a clear shift to focus on making web applications as secure as they can be before going live. Some of the categories have been expanded this year, which is likely to allow for more CWEs. They have also implemented Exploitability and Impact data for the first time, which adds further weight and validity to the list.
See also: A new critical pre-auth RCE bug in VMware vCenter Server rings alarm bells
The three new categories added to the OWASP Top 10 are Insecure Design, Software and Data Integrity Failures, and Server-Side Request Forgery (SSRF).
The first two represent improvements to the software development process and supply chain areas. For example, Insecure Design covers how developers and security teams can improve the process for building software or creating code and making these developments secure before production through more use of threat modelling, secure design patterns, and better use of reference architectures. Software and Data Integrity Failures represents how developers can make assumptions around security as they implement software updates, work with critical data in their development processes, and use CI/CD pipelines without verifying their integrity.
In practice, these two additions to the Top 10 encourage security teams to get involved in how their organisations build, test, distribute and deploy code. Rather than being gatekeepers to production, or looking at applications once they have rolled out, security should ensure that best practices are adopted and followed throughout the software supply chain.
The other new addition, SSRF, hijacks a web application to send HTTP requests to a third party site controlled by the attacker, leading to unauthorised access to data or transactions. SSRF is a big potential issue for web application security that the industry has to take seriously as a whole.
How can this help enterprises?
Alongside providing a valuable tool for IT security teams to prioritise potential threats, the OWASP Top 10 has another purpose. It can help teams to discuss the processes and challenges that exist around security and software. For instance, DevOps as an approach and term is now more than a decade old. Rather than being a new and untried approach, it is business as usual for many companies that were formed during those ten years.
According to the Linux Foundation Open Source Jobs Report for 2021, 88 percent of IT professionals use DevOps practices in their work today. Yet despite all this, there is still a political ‘Them’ and ‘Us’ divide between development and security teams. All too often, these teams don’t work well with each other. Those walls need to be taken down so that both teams come together to support the business they work for. To help this process, CIOs and CISOs can set goals and measure metrics that put the emphasis on security into the development process.
Making this happen is based on getting better insight into the whole process for building software and running infrastructure. There are multiple initiatives taking place that - when combined - can help all organisations improve security and bridge those gaps too. For example, the US Government’s approach on Software Bill of Materials for federal government projects will force all suppliers to update their customers on any changes taking place in their applications. This move will help take-up of this approach by some of the world’s largest customers for software, which should make this more popular with other public organisations and private enterprises. Internal development teams can support SBOMs for the applications and services they build, providing their teams with more insight into what is in place and what has to be updated.
Similarly, IT security teams maintain asset registries across internal IT, cloud services, containers and other devices that can then be shared with the software development teams for them to know what is in place at any time and how secure it is, from the most ephemeral container to the longest-lived legacy application. By helping teams align on software design improvements and focus on integrity across the whole development process, security should improve overall.
What next?
The new OWASP Top 10 should be applauded. It has captured the most relevant issues that plague IT Security and software teams. However, it’s only a starting point and is by no means the be all and end all of application development security. It was never designed as a checklist for organisations to tick off and assume they are secure, but some might be foolish enough to do exactly that. The list can be used as a methodology with guidance on the direction you need to travel to be more secure but should be combined with web application scanning tools that deliver a more accurate picture that relates to an organisation's own network.
Given the pace of change we’re seeing within the industry and from bad actors themselves, we need to keep up with them, or ideally be one step ahead. We should not wait another four years to update these categories and criteria, but look at them more frequently. This will require support from the whole security industry to collaborate and support this process. Just as we expect developers and security professionals to pull together for the good of their individual companies, so the security industry as a whole has more to do to support these kinds of initiatives being embedded in customers and service providers.
