A Quick Look at the New OWASP Top 10 for 2021

Back in September of 2021 we wrote that the OWASP working group had a draft of latest Top 10 Web Application Security Risks, their first update since the 2017 revision.  The working group finalized their list and published a final version a month later in October of 2021.  With the list out for a few months now, let’s take a quick look at what’s changed with the new OWASP Top 10.

The Top 10 list for 2021 starts out with three new categories, four of the previous categories have been updated with naming and scoping changes, and there is some consolidation in a few categories, along with a shift in the ordering of the risks.  A display of the movement and changes in the OWASP Top 10 list is shown in the diagram below.

Here’s the recap of the changes from OWASP site:

• A01:2021-Broken Access Control moves up from the fifth position; 94% of applications were tested for some form of broken access control. The 34 Common Weakness Enumerations (CWEs) mapped to Broken Access Control had more occurrences in applications than any other category.
• A02:2021-Cryptographic Failures shifts up one position to #2, previously known as Sensitive Data Exposure, which was broad symptom rather than a root cause. The renewed focus here is on failures related to cryptography which often leads to sensitive data exposure or system compromise.
• A03:2021-Injection slides down to the third position. 94% of the applications were tested for some form of injection, and the 33 CWEs mapped into this category have the second most occurrences in applications. Cross-site Scripting is now part of this category in this edition.
• A04:2021-Insecure Design is a new category for 2021, with a focus on risks related to design flaws. If we genuinely want to “move left” as an industry, it calls for more use of threat modeling, secure design patterns and principles, and reference architectures.
• A05:2021-Security Misconfiguration moves up from #6 in the previous edition; 90% of applications were tested for some form of misconfiguration. With more shifts into highly configurable software, it’s not surprising to see this category move up. The former category for XML External Entities (XXE) is now part of this category.
• A06:2021-Vulnerable and Outdated Components was previously titled Using Components with Known Vulnerabilities and is #2 in the Top 10 community survey, but also had enough data to make the Top 10 via data analysis. This category moves up from #9 in 2017 and is a known issue that we struggle to test and assess risk. It is the only category not to have any Common Vulnerability and Exposures (CVEs) mapped to the included CWEs, so a default exploit and impact weights of 5.0 are factored into their scores.
• A07:2021-Identification and Authentication Failures was previously Broken Authentication and is sliding down from the second position, and now includes CWEs that are more related to identification failures. This category is still an integral part of the Top 10, but the increased availability of standardized frameworks seems to be helping.
• A08:2021-Software and Data Integrity Failures is a new category for 2021, focusing on making assumptions related to software updates, critical data, and CI/CD pipelines without verifying integrity. One of the highest weighted impacts from Common Vulnerability and Exposures/Common Vulnerability Scoring System (CVE/CVSS) data mapped to the 10 CWEs in this category. Insecure Deserialization from 2017 is now a part of this larger category.
• A09:2021-Security Logging and Monitoring Failures was previously Insufficient Logging & Monitoring and is added from the industry survey (#3), moving up from #10 previously. This category is expanded to include more types of failures, is challenging to test for, and isn’t well represented in the CVE/CVSS data. However, failures in this category can directly impact visibility, incident alerting, and forensics.
• A10:2021-Server-Side Request Forgery is added from the Top 10 community survey (#1). The data shows a relatively low incidence rate with above average testing coverage, along with above-average ratings for Exploit and Impact potential. This category represents the scenario where the security community members are telling us this is important, even though it’s not illustrated in the data at this time.

The changes to the OWASP Top 10 for 2021 were finalized and released back in October 2021.  With the latest list of web application security risks, you may be wondering how you can improve your protection against these top threats to your application security.

Take a Page from NIST to Improve Application Security and Implement OWASP Top 10 Protection

Even the National Institute of Standards and Technologies (NIST), has recently recognized the need for runtime application security   NIST’s SP800-53 that was just released on September 23, 2020, includes a requirement for runtime application security also known as runtime application self-protection (RASP).  The latest revision of NIST SP800-53 includes the requirement of RASP (Runtime Application Self-Protection) and IAST (Interactive Application Security Testing). It’s a first in recognizing these two advancements in application security by now requiring them as part of the security framework.

In addition, there are a number of simple measures an organization can take to improve their web application security stance.  First starts at the very beginning of application development, and that’s making sure developers take security into consideration when developing and coding applications.  Second, is making sure that software and operating systems are kept up to date, with the latest updates and patches to ensure known vulnerabilities that have patches are not exploited.

In addition to these two fundamental starts to application security, there’s still a need to ensure security for web applications running in production, especially against threats either missed or not typically secured by network or system level security.  The OWASP Top 10 Web Application Security Risks are a great example of risks that aren’t typically protected with network or system level security.

A RASP solution sits on same server as the application, and provides continuous security for the application during runtime. By running on same server as the application, RASP solutions provide continuous security for the application during runtime.  For example, as mentioned earlier, a RASP solution has complete visibility into the application, so a RASP solution can analyze an application’s execution to validate the execution of the code, and can understand the context of the application’s interactions.

IAST is the other new recommendation for application security coming from the NIST revised draft, and if you haven’t heard of IAST, there’s a good definition available from Optiv

“IAST is an emerging application security testing approach which combines elements of both of its more established siblings in SAST (Static Application Security Testing) and DAST (Dynamic Application Security Testing).  IAST instruments the application binary which can enable both DAST-like confirmation of exploit success and SAST-like coverage of the application code. In some cases, IAST allows security testing as part of general application testing process which provides significant benefits to DevOps approaches. IAST holds the potential to drive tests with fewer false positives/negatives and higher speed than SAST and DAST.”

With these two new requirements (RASP and IAST) for application security being added to the NIST framework, it’s really time to rethink how your organization is doing application security.

Here at K2 Cyber Security, we’d like to help out with your RASP and IAST requirements.  K2 offers an ideal runtime protection security solution that detects true zero-day attacks, while at the same time generates the least false positives and alerts.  Rather than rely on technologies like signatures, heuristics, fuzzy logic, machine learning or AI, we use a deterministic approach to detect true zero-day attacks, without being limited to detecting attacks based on prior attack knowledge.  Deterministic security uses application execution validation, and verifies the API calls are functioning the way the code intended.  There is no use of any prior knowledge about an attack or the underlying vulnerability, which gives our approach the true ability to detect new zero-day attacks. Our technology has 8 patents granted/pending, and has no false alerts.

We’ve also recently published a video, The Need for Deterministic Security.  The video explains why the technologies used in today’s security tools, including web application firewalls (WAFs) fail to prevent zero day attacks and how deterministic security fills the need for detecting zero day attacks.  The video covers why technologies like artificial intelligence, machine learning, heuristics, fuzzy logic, pattern and signature matching fail to detect true zero day attacks, giving very specific examples of attacks where these technologies work, and where  they fail to detect an attack.

The video also explains why deterministic security works against true zero day attacks and how K2 uses deterministic security.  Watch the video now.

Change how you protect your applications, include RASP and check out K2’s application workload security.

Find out more about K2 today by requesting a demo, or get your free trial.