How to use CWEs

The advent of cloud security has led many professionals into the often overwhelming world of application security. If you’re like me, you were familiar with cloud infrastructure, which inevitably led to learning kubernetes and devops, and then application security. On the one hand, this has created an amazing breath of life into a field previously ruled by enterprises. Before cloud security, only companies with giant risks to their applications could afford meaningful investments into application security. On the other hand, this has led to a lot of confusion about the value of CWEs and CVEs in general.

Now, many companies like Backslash have made application security more approachable for security professionals in general by making what used to be very complex tooling easy to deploy and maintain. However, many of us have learned the hard way that proper tool implementation was only half of the battle. After you implement your shiny new tool, you have to deal with the plethora of alerts that come out the other side.

In this article, we’ll discuss Common Weakness Enumeration (CWEs) - something that I spent too long not knowing anything about. We’ll evaluate what makes them different (and supplementary) from Common Vulnerabilities and Exposures (CVEs), as well as why they’re helpful in real world prioritization for practitioners.

CVEs vs. CWEs, is it all just noise?

The world of infrastructure security is ruled by CVEs, something that SCA and container scanning tools brought to application security. If you’re like me, your first exposure to application security was unfortunately through CVEs. I say “unfortunately” because the value of CVEs is in their cataloging of different potential weaknesses, not in the individual likelihood of one getting exploited in your system.

There’s been a lot of talk about the value of CVEs and their scoring recently, and this article doesn’t plan to address all of that; however, there is a core issue with the generalities of CVEs. Most of the time, your direct systems are not actually susceptible to CVE exploitation. The findings are usually false positives because these are published exploits under very specific circumstances. Conversely, CWEs are helpful in that they give you the details of the nature of the vulnerability itself.

For example, here’s a vulnerability with AppArmor I was analyzing recently. At a high level, CVE-2016-1585 is an exploit where a specific mount rule can allow more permissions to an application than you meant to allow. On the one hand, if you use this mount rule, this vulnerability could be catastrophic, on the other hand, it’s not a mount rule you’ll see regularly. This vulnerability is illustrative of the normal issues with CVEs - you have wildly different scorings, prioritizations, and details about how it would be exploited, because ultimately it links back to a couple of sentences on a bug forum. More foundationally, much application security practitioner time is spent researching obscure edge cases. Anything that can help you pinpoint the cause of a vulnerability faster leads to the most time saved.

This is where CWE’s come in - notice that this CVE has a CWE of CWE-254, “7PK - Security Features.” The 7PK tells you that it’s related to “Seven Pernicious Kingdoms” - meaning that it’s not tied to a specific known exploit type, but rather to a general configuration issue with the software. In other words, the weakness here relates to exploiting the general security configuration of the software. 

Returning back to CVE-2016-1585 then, you can save time by knowing that the vulnerability is related to exploiting internal configuration features of AppArmor. This is information that you may not be immediately aware of from the CVE description or bug description; furthermore, it’s information that helps you understand compensating controls like restricting access to your Linux configs.It empowers you to make prioritization decisions between general configuration exploits, and more obviously dangerous things like SQL injection or hard coded credentials.

This context is the fastest way to determine the actual risk of the vulnerability on a specific system. Now that I have a general understanding - I don’t need to be an expert on AppArmor or Linux mounting details in order to prioritize this finding. If we allow a lot of custom configurations, or have broad access to our linux systems, this should be a high priority. But if our linux system configurations are pretty locked down, this finding probably isn’t a big deal. At the very least, I understand that I’m checking AppArmor configs for vulnerabilities, and not other permissions issues.

Why CWEs Matter for AppSec

At first, I thought CWEs wouldn’t matter compared to CVEs for effective remediation of findings because they don’t attach scores or apply to specific exploits. Instead, I’ve found them to be the most overlooked aspect of finding prioritization across tools. While we’ve been focused on reachability analysis, simple CWEs often provide more value.

The easiest example to make is SQL injection, where a single finding is a show stopper basically regardless of context. Same with findings like path traversal or OS command injection - these findings demand immediate action because they allow attackers complete takeovers of critical systems.

I was recently interviewing a highly seasoned pentester about his findings and was relieved when he said that doing a buffer overflow is highly specialized and difficult. I was relieved because I always thought to myself, “who on earth is nerdy enough that they’re exploiting this via a web application?” The answer was that it is indeed a rarer exploit to attempt. Beyond this popular but unlikely CWE (for most SaaS apps), there are numerous CWEs that are low impact. For example, CWE-200: Information Exposure, and CWE-215: Information Exposure Through Debug Information. These findings can be important to correct, but in most scanner contexts this reveals basic information like if the hosting server is nginx or apache.

I’ve loved Backslash’s CWE database because it allowed me to confirm my suspicions. Should I be more concerned about Information Exposure? I can easily see that most of these findings are in Java frameworks and are usually medium severity findings.

Instead of just saying “I feel like these are never a big deal,” I can back it up with some empirical findings to confirm.

In sum, CWEs offer a valuable informational layer on top of CVEs. They help security professionals think like attackers and categorize findings quickly to understand how their own systems may be vulnerable. Backslash’s CWE database helps fill the missing gap between individual CVEs and the larger CWE picture.