In early September, we published a piece about the OWASP top 10. At that time, the most prominent vulnerabilities on the list had not yet changed. Soon after we posted the article, OWASP updated the list with three new categories. Four have name and scope changes. It also includes some notable reordering.
After several years without change, the latest list represents a major step forward for the top 10.
What’s Different in the OWASP Top 10 in 2021?
Andrew van der Stock, executive director of the OWASP Foundation, spoke with us to provide insight into the new list. He discussed the importance of the changes for the security industry and the enterprise.
Van der Stock explained that the rationale behind the new outlook began in 2017. That year, the foundation conducted an open two-day session at the Open Security Summit. Since then, they’ve been working with the public to develop a better way of constructing the top 10. They decided to be more data-driven and survey-quality-driven using more industry feedback.
“We got over 700 different CWEs (common weakness enumerations) in the data set covering around 515,000 apps, and we categorized them into various buckets,” he said. “Some of the buckets were overly broad, and we had to work on them to bring them back into some sort of focus.”
He explained that a vulnerability like sensitive data exposure stems from many root causes. However, the focus is often on the symptom. So OWASP decided to normalize the category names as the root cause rather than talking about the symptoms.
New Category: Insecure Design and the Need to Shift Left
As you scan the new top 10, you’ll notice a brand new category in the number four position: insecure design. This focuses on risks related to design flaws. Van der Stock is a former app designer himself. As such, he says this category isn’t a catch-all for anything that doesn’t make sense anywhere else. The bucket, he said, represents any control that is missing, ineffective or by-passable in code.
“If you have a piece of business logic that is poorly implemented and doesn’t think about all the different abuse cases, it’s going to have a design flaw that could be bypassed,” he said. “I got rid of a lot of CWEs from this bucket to be very particular about what the category truly means. We got a lot of data from a lot of different sources that were best described as insecure design.”
According to van der Stock, the category reached number four because companies were reporting it “like wildfire”. Some tool vendors criticized the category. It was too difficult to discover an absence of control, they said. However, those with an end-to-end security development life cycle that takes secure design into account can minimize vulnerabilities.
When you test code for security early in the process, you’re shifting left. But today, secure code is about more than just shifting left. Along with testing earlier, van der Stock advised that your secure development life cycle should include some elements of security, knowledge and access to security professionals and security champions within the development community themselves.
OWASP Vulnerabilities #9: Logging Failures
As breaches continue to skyrocket, just knowing you’ve been breached is part of the incident response and remediation process. But if no one logs the incident, how would you even be aware of the breach?
It used to take two years between when a breach happened and when the victim found out. Today, most organizations can determine a breach within a couple of days. They can take action because of the attention placed on the importance of logging.
“I was really pleased that the community put [the vulnerability] back in; it was the most requested item,” he said.
The most critical takeaway about logging failures is that you need to properly audit the logs.
“Our field often thinks of themselves as auditors,” he said. “But unless you have an accounting degree majoring in auditing, you should never ever call yourself an auditor, because they’ve got specific skills. It’s like me trying to do someone’s taxes.”
Auditing should be an interview-based process. You ask people about the controls in place and look for the evidence by interview. Auditors are looking for both the existence of these logs and how you take action based on the data. This has been a standard staple of auditing for hundreds of years.
“The number of breaches that are out of control cost companies hundreds of millions of dollars,” he said. “You don’t fix that without looking at logs.”
According to OWASP’s category description, “failures can directly impact visibility, incident alerting and forensics.”
OWASP Vulnerabilities #10: Server-Side Request Forgery
As for #10 on the list, Server Side Request Forgery (SSRF), van der Stock noted that it was the second most popular request from the community and a worthy inclusion. At a very high level, SSRF is about what you could do with a specially crafted URL that can carry out malicious requests.
“If you get the response you’re looking for, you can basically make internal requests on behalf of the server to an internal resource,” he said.
In a Black Hat 2017 presentation, Orange Tsai explained that the root cause of the problem lies in the inconsistency of URL parsers and URL requesters.
Takeaways for the CIO or CSO
Organizations that adopt a proactive approach in the top 10 vulnerabilities will almost always boast a more robust security posture. Those that practice good cyber hygiene — like fostering a security-forward culture, patching and updating frequently and using only trusted software — on top of being proactive can get even further ahead in the quest for minimizing security risk.
But if there’s one crucial takeaway here, it’s that the OWASP top 10 is the bare minimum to avoid negligence.
“It doesn’t really matter what order it is; just do it,” van der Stock said. “I know that’s a tall order, but it’s only 10 things. And if you take it from the point of view of 10 positive things, rather than hundreds of negative things, it’s a really good place to start. But, it’s not the endpoint.”