What is a security weakness?

While threat and vulnerability have rather clear definitions in cybersecurity, this is not the case for a weakness. Commonly used glossaries, such as RFC 4949 and the NIST glossary do not define the term weakness. On the other hand, it is very often used as part of the vulnerability definition. A vulnerability is a weakness that can be exploited by an attacker. Thus, a weakness is an error, typically in the software code, that might lead to a vulnerability. This happens when it can be exploited.

Software weaknesses are often discussed and defined in the context of the Common Weaknesses Enumeration (CWE). This is a “community-developed list of common software security weaknesses”. In CWE, each distinct weakness is assigned a CWE identifier. The Mitre corporation, a not-for-profit company, maintains the CWE list. CWE Version 3.2, released in January 2019, contains 806 weaknesses. Entries in the list often have quite extensive descriptions with examples. It is a good starting point for understanding and avoiding software errors.

CWE examples

Since there is no clear definition of the term, we look at a few examples. This will give a better feeling for it. CWE includes both very well known and common errors, but also some more exotic potential problems. These issues can increase the probability of having security vulnerabilities.

• CWE-79: improper neutralization of input during web page generation (‘cross-site scripting’). Cross-site scripting, or XSS, is one of the most common web application vulnerabilities. The NIST NVD database contains 1,964 XSS vulnerabilities that were published in 2018.
• CWE-120: buffer copy without checking size of input (‘classic buffer overflow’). This is the classic buffer overflow attack and is the cause of very many vulnerabilities. It can sometimes lead to arbitrary code execution. The NIST NVD database contains 1,756 vulnerabilities related to this CWE published during 2018 alone.
• CWE-646: reliance on file name or extension of externally-supplied file. A server should not assume that the file extension actually matches the content of the file. Processing files that are misclassified could lead to unwanted behaviour.
• CWE-1120: excessive code complexity. Code that is difficult to understand or maintain is more likely to be vulnerable. Errors are more difficult to find and fix when code is not clear and clean.

This last example, CWE-1120, clearly shows the difference between a weakness and a vulnerability. Very complex code is obviously not by itself exploitable in a cyber attack. However, this weakness can lead to errors than can be exploited by an attacker.

CWE abstraction levels

Entries in CWE are given with different levels of abstraction. Some are very generic, while others are more specific. There are three different abstraction levels. These are class, base, and variant. Classes are described in a very abstract way, independent of programming language and technology. Weaknesses in the base level are slightly more specific. They are often enough specific to include methods for detection and prevention. The variants are the most specific and are described with a low level of detail.

For the buffer overflow vulnerabilities, examples of these levels would be:

• Class: CWE-119: improper restriction of operations within the bounds of a memory buffer.
• Base: CWE-120: buffer copy without checking size of input.
• Variant: CWE-121: stack-based buffer overflow.

For cross-site scripting, a similar abstraction can be seen as follows:

• Class: CWE-74: improper neutralization of special elements in output used by a downstream component (‘injection’).
• Base: CWE-79: improper neutralization of input during web page generation (‘cross-site scripting’).
• Variant: CWE-80: improper neutralization of script-related HTML tags in a web page (basic XSS).

Mitre provides visualizations showing how the different weaknesses relate to each other. There are a few different visualizations depending on how you want to view the relations. These are given as views.

CWE categories and views

In addition to concrete weaknesses, CWE also uses the notion of categories and views. A category is an entry that contains a CWE list of other entries, where all share a common characteristic. Categories can be nested. The Code category include the Source Code category, which in turn contains e.g., Data Processing Errors. This category in turn contains e.g., CWE-119 mentioned above.

A view is a subset of CWE entries that are grouped together. One view is e.g., CWE-1026 Weaknesses in OWASP Top Ten (2017). This view includes all weaknesses that are related to the different items in OWASP Top 10. In turn, each of the ten items is a category consisting of weaknesses. Two other views that are interesting are CWE-701: Weaknesses Introduced During Design and CWE-702: Weaknesses Introduced During Implementation.

In summary, the CWE list can be used as a baseline for identifying, preventing and mitigating errors. Through this common language, organizations can describe and communicate problems in a well-defined way.