Blog HackRTU

‹ Regresar

cwe, enumerating industrial weaknesses 

 

CNA

 

The CWE, or Common Weakness Enumeration, is a list of common weaknesses in both software and hardware that could lead to vulnerabilities. The various lists that can be consulted on the official CWE website are developed by the community. The main objective of these CWE lists is to provide a common language for describing, mapping, and classifying the origin of certain vulnerabilities.

Historically, the CWE list was developed in 2005 as part of the SAMATE (Software Assurance Metrics and Tool Evaluation) project under the participation of MITRE with the NIST (National Institute of Standards and Technology) and sponsored by the U.S National Vulnerability Database (NVD). As a result of this project, the document  “Preliminary List Of Vulnerability Examples for Researchers” (PLOVER) was created, which would establish the foundations for what we now know as CWE.

UNDERSTANDING CWE LISTS

CWE lists use a hierarchical structure based on different levels of abstraction ranging from the most general to the most specific, for both software and hardware. These levels of abstraction are very important for using the specific list selected when linking/mapping a CVE vulnerability to a specific CWE-ID. The different levels of abstraction are:

• View: A subset of CWE entries that provide a way to examine CWE content. The main view structures are Slices (flat lists) and Graphs (containing relationships between entries). As an example of this hierarchy, we propose the specific list created for industrial control systems, CWE VIEW: Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS.

• Pillar: The most abstract level for assigning weaknesses within a list (View). It represents a broad theme for all class/base/variant weaknesses related to it. A pillar is different from a category, as a pillar is technically still a type of weakness that describes an error, while a category represents a common characteristic used to group related terms. An example of a pillar within the list developed on weaknesses in ICS is CWE-710: Improper Adherence to Coding Standards

• Category: CWE entry containing a set of other entries that share a common characteristic. An example of this hierarchy is the ICS Communications category, which contains entries related to the main category at the hierarchy level, all of which deal with industrial communications.

• Class: A weakness described in very abstract terms, usually independent of any specific language or technology. More specific than a pillar weakness, but more general than a base weakness. Class-level weaknesses typically describe problems in terms of one or two of the following dimensions: behaviour, property, and resource. An example of a class in the CWE list on ICS could be: CWE-1384: Improper Handling of Physical or Environmental Conditions.

• Base: One of the most used levels, as it is the best for mapping real vulnerabilities. It allows weaknesses to be described in sufficient detail so that they can be used as the ‘root cause’ in the CVE/CWE association. (CWE recommends using Base whenever possible to map CVEs). An example of this base level at the industrial level is CWE-1338: Improper Protections Against Hardware Overheating, which is included in the list developed for ICS.

• Variant: Weakness related to a specific type of product/technology/language in a Base. This level is usually ideal for defining static or dynamic tests in applications (SAST/DAST). An example of this level is the following weakness CWE-121: Stack-based Buffer Overflow in the list of 1358 developed for ICS.

• Composite: A composite element consisting of two or more distinct weaknesses, in which all weaknesses must be present at the same time for a potential vulnerability to arise. Eliminating any of the weaknesses eliminates or drastically reduces the risk. An example of this level is the following weakness CWE-384: Session Fixation, which appears in list 1358 developed for ICS.

In addition to these levels, it is important to note that the CWE is not just a flat list; the entries are connected to each other. Common types of relationships within the CWE are:

• ParentOf/ChildOf: Hierarchical relationships between abstractions, used to model different levels of generality. For example, a Class or Base can have several children. A child has exactly one parent. Let's look at a specific example:

  • CWE-119 (Improper Restriction of Operations within the Bounds of a Memory Buffer) would be ParentOf of CWE-120 (Classic Buffer Overflow) and CWE-125 (Out-of-bounds Read). This is because, in control systems, an out-of-bounds read (CWE-125) detected at the firmware level in a PLC can cause memory corruption or loss of control of the physical process.

  • When classifying a 0-day vulnerability as a researcher, it is always recommended to use the most specific CWE, starting from the parent to its children.

• HasMember/MemberOf: These relationships refer more to thematic grouping than to hierarchy itself, making it easier to filter CWEs according to their context.
  • As a specific example of this relationship, CWE-1368 (View: ICS Dependencies & Architecture) has the following members, i.e. HasMember CWE-15 (External Control of System or Configuration Setting) and CWE-287 (Improper Authentication). If we were to talk about CWE-1368 upwards, for example, CWE-1368 MemberOf CWE-1360 (ICS Dependencies (& Architecture)). If a SCADA does not validate inputs from an HMI and lacks mechanisms to filter requests through legitimate and authenticated users, it can be manipulated, and an attacker could send unauthorised commands.

• Related (PeerOf):Lateral relationships between CWEs with the same abstraction but with a different focus. In other words, CWEs are conceptually linked but not at the hierarchical level. This classification is particularly useful for understanding chains of weaknesses that can be combined in complex attacks.
  • For example, CWE-295 (Improper Certificate Validation) is related to CWE-322 (Key Exchange without Entity Authentication). Let's look at an example in IIoT gateways, i.e. those related to the industrial world of things. A CWE-295 flaw may be related to CWE-322 because both affect the verification of the issuer's trustworthiness, and in a MITM attack, these weaknesses can be combined to impersonate a legitimate server.
  • Let's look at the relationship in the table within the CWE ‘Research Concepts’ list (View-1000). For an independent analysis of the above, please refer to the following link from which the example was taken: https://cwe.mitre.org/data/definitions/295.html.

These connections can be found in the Nature column, which indicates the nature of the relationship between a source CWE and a destination CWE. It is important to note that it is always read in the direction Source à Destination, since, as we saw in the ParentOf/ChildOf example, the same pair of CWEs could appear with different addresses and ‘Nature’ depending on the point of view.

Now that we have a basic understanding of how CWE lists work, here are some practical recommendations for using them:

• If you are going to classify a CVE, carefully review the level of abstraction, prioritising CWEs at the Base level. If you are analysing an application, it is better to use Variants.
• Draw chains of relationships to select the most specific CWE that allows for a more refined classification.
• Use specific Views such as those at the ICS level (CWE-1358 - Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) or IEC 62443 (CWE-1424 - Weaknesses Addressed by ISA/IEC 62443 Requirements) when performing a specific task. In our case, for industrial cybersecurity, it works like a charm.
• Use tools that the community has published to improve your searches and understanding of CWE, such as cwe-tool.
• Don't be afraid to make mistakes. Who hasn't used the wrong CWE at some point? :P.

 

HISTORY OF THE CWE

Following the preliminary list developed (PLOVER), in 2006 the community released a beta version of the CWE list in response to a catalogue of ‘root causes’ where vulnerabilities originate. With approximately 300 entries of potential weaknesses, the first beta version aimed to define a common terminology for software-related weaknesses.

On 9 September 2008, version 1.0 of the CWE was officially released, marking the initial path to the version we know today, with all the details refined over the years.

Subsequently, version CWE 2.0 was published in mid-2011, including a greater number of weaknesses and relationships between them.

Version CWE 3.2 was released publicly in 2019 and did not add industrial cybersecurity elements, but it did allow the CWE lists to be refined with discredits of old CWEs classified as ‘deprecated.’

Version CWE 4.7 was the beginning of the inclusion of industrial cybersecurity into the CWE lists with CWE-1358 - Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS, which we have already used in several examples throughout the article. Subsequently, other versions such as 4.9 would revise the categories created within the list and enhance the list focused on industrial control systems.

In 2024, version CWE 4.14 was published, introducing another new view, CWE-1424 - Weaknesses Addressed by ISA/IEC 62443 Requirements, in this case related to the IEC 62443 family of standards, focusing on some weaknesses in the IEC 62443-3-3 standard or the IEC 62443-3-2 standard. It is understood that the focus was placed on these standards due to weaknesses at the architecture and design level (IEC 62443-3-3) and potential problems at the operation or maintenance level that may arise in a risk analysis (IEC 62443-3-2).

Finally, the most recent version of the CWE lists is CWE 4.17, which continues the work of refining and expanding both existing lists and others that may be proposed.

 

SPECIFIC EXAMPLE OF CWE LISTS

In this case, as we have already mentioned in other publications discussing CVE, CVSS, and CPE, we will analyse the CVE-2025-41362 vulnerability to determine its CWE classification.

Given that CWE is a field that is used directly in advisories, we will discuss how a researcher can use the classification to assign the most consistent weakness based on the reported vulnerability.

The CVE-2025-41362 vulnerability has been assigned CWE-94 Improper Control of Generation of Code ('Code Injection'). This is because the vulnerability is directly a code injection and therefore not very complex to classify. It can also be seen that this CWE is not strictly related to the industrial world, as the vulnerability was found in a web technology that the device possessed, but would we have an equivalent at the industrial level?

Let's look at the possibilities by applying logic. Searching for code injection or code in general within the list Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS, we detected three results, two of which we have already ruled out because one refers to downloading code from a device without integrity and the other to activating debug mode in the code. We will stick with the following weakness CWE-470: Use of Externally-Controlled Input to Select Classes or Code ('Unsafe Reflection'). Now that we have the weakness, let's look at the relationships it may have and detect that it is a member (MemberOf) of the OWASP Top Ten 2021 Category A03:2021 - Injection category, and, as is logical, CWE-94 is included here, so, in terms of relationships, if the specific list for ICS had been used, which did not exist at the time, the weakness could be classified as CWE-470.

At HackRTU, we believe that the use of specific lists within CWE is essential for accurately managing weaknesses that can lead to potential vulnerabilities. Furthermore, based on new regulations and directives such as NIS2 and CRA, the use of CWE lists can greatly facilitate the management of cybersecurity issues for organisations at both the industrial and corporate levels.

 

 

HACKRTU TEAM