Common Weakness Enumeration

A Community-Developed List of Software Weakness Types

CWE/SANS Top 25 Most Dangerous Software Errors
Home > Community > Research > Managing Node Restructuring in CWE  

Managing Node Restructuring in CWE
Managing Node Restructuring in CWE

Depending on the CWE community's resolution to the discussion points being proposed, some significant node changes may be necessary in CWE. Both Systemic and Major modifications could require a restructuring of entire branches within a tree.

For example, an inclusion-related modification might recommend that certain low-level details be omitted by all views except by a single, specialized view. An abstraction-related modification might recommend that a single higher-level node could be preserved while its children are "rolled up" into this node, and/or hidden from most views.

Key Principles
Key Principles

It is essential that node restructuring should preserve the amount of information that is already in CWE. But where that information lives, and how it is represented, is not yet clear.

The CWE Project Leads currently believe that while CWE has the word "weakness" in its name, there are many other concepts that are closely connected with "weaknesses," and some of these concepts may be important for addressing the needs of some CWE stakeholders. For example, CWE Draft 6 has many "category" and "navigation" nodes that make CWE more usable to various communities, even though they are not focused on weaknesses per se. Other concepts and terms are used by many communities even though they are not describing weaknesses per se, such as "Cross-Site Scripting." For these reasons, the CWE Project Leads believe that CWE might need to include these other concepts, perhaps as different types of nodes.

The CWE Project Leads currently believe that Views, while not yet precisely defined, might be a useful mechanism for managing node restructuring and keeping CWE easily usable for everyone.

Possible Methods for Node Restructuring

Since any restructuring is likely to involve noticeable changes in CWE schema, it is important for the CWE community to provide feedback on possible methods for restructuring.

Some ideas are below.

Abstraction-Related Restructuring
Abstraction-Related Restructuring

Suppose there are 4 nodes. P is a parent, and A, B, and C are children. P deals with a specific weakness, and A/B/C happen to describe minor variants.

Suppose the CWE Research Community agrees that there is little need to distinguish A, B, and C from their parent P.

Some options might be:

  1. Keep P as a parent node. Create a new type of node - say, "sub-type" - which has exactly the same schema as regular nodes. Label nodes A, B, and C as having this "sub-type," and add annotations that only cause these nodes to show up in relevant views. These nodes would be full-fledged nodes within CWE, with their own unique numeric identifiers, except they are labeled as "sub-type" nodes.
    Discussion: the same node might be a "sub-type" in one view and "regular" in another view. The total number of identifiers in CWE could increase substantially as low-level variants are identified. However, these large totals might not be present in most views; in addition, community discussions will produce guidance that might keep this potential explosion under control. Note: MITRE has not yet determined how to implement and manage views, which might introduce additional complications (or solutions) besides those mentioned here.
  2. Keep P as a parent node, and extend the CWE schema to support "variants" that are attached to the parent node. A, B, and C could be converted into these variants. They would no longer be individual nodes within CWE; they would only have identities as associated with P. A separate notation such as "P.1" could be used to identify variants by some separate number. CWE users who want additional granularity could reference these "variants."
    Discussion: some "variants" might have the same extensive information as full-fledged nodes, so it might not make sense to treat them as separate entities, schema-wise. Based on past CVE experience, "P.1" style notation was not widely adopted. Also, the use of numbers like "12.4" could lead to people mis-interpreting which number is the base CWE identifier. Finally, these notations could be difficult to maintain, especially if variants need to be restructured themselves.
  3. Keep P as a parent node, add the contents of A, B, and C to detailed descriptions, context notes, and/or examples within P (i.e. existing fields). Then, delete A, B, and C entirely; their original content is still preserved within P.
    Discussion: this reduces the utility of CWE for stakeholders who want low-level distinctions that would have been provided by using A, B, and C. If the information is not well structured, then it would be difficult to retrieve it.
  4. The community is encouraged to suggest other options.

NOTE: any true "deprecation" of a node from CWE would not remove the node from the list entirely; at least, there would be a brief explanation for the deprecation, along with a pointer to any relevant nodes that are still active.

Inclusion-Related Restructuring
Inclusion-Related Restructuring

Suppose the CWE Research Community defines certain criteria that limit which concepts can be defined within CWE. Suppose that a node N does not meet these criteria.

Some options might be:

  1. N's content could be preserved in its entirety, but N would only be made available through "comprehensive" views, so that it is rarely encountered and, hopefully, rarely used. Special flags might be useful for consumers to omit such nodes.
  2. N could be "deprecated", which would remove most of its content and omit it from most views. Use of this node would be actively discouraged.
  3. The community is encouraged to suggest other options.
Perspective-Related Restructuring
Perspective-Related Restructuring

Suppose a node is described and organized in a way that reflects a certain perspective that is not supported in CWE. For example, the community might decide that nodes that focus only on attacks should be more closely associated with CAPEC, not necessarily treated as separate entities within CWE. Alternately, some nodes might be useful for navigation even though they have no fundamental relationship with weaknesses, such as the Motivation/Intent subtree (CWE-504).

Note: this discussion is NOT about minor modifications related to perspective, such as changing a node's name to more closely reflect the underlying weakness being identified.

Some options might be:

  1. If a node has a useful role within some views, e.g. to support navigation or grouping, then it could be preserved. The node could be labeled in a way that indicates that it is not associated with any "supported" perspectives within CWE.
    Example: Man-in-the-middle (CWE-300), being related to an attack, could be highlighted as an attack-only node. Pointers to the CAPEC ID (94) and references to associated weaknesses could be provided. However, CWE might not attempt to capture every possible attack with individual CWE nodes.

  2. If the node is identifying a concept that the community agrees is out-of-scope, and it does not serve a useful navigational or organizational role, then it could be deprecated. If the concept is deemed important to the community, then the CWE schema could be modified to provide relevant tags or elements.
    Discussion: there are few nodes in CWE that might be related to this option, although the CWE team has had difficulty in applying the Motivation/Intent subtree (CWE-504) to other areas of CWE, due largely to perspective differences.

  3. The community is encouraged to suggest other options.

Document version: 0.1    Date: September 13, 2007

This is a draft document. It is intended to support maintenance of CWE, and to educate and solicit feedback from a specific technical audience. This document does not reflect any official position of the MITRE Corporation or its sponsors. Copyright © 2007, The MITRE Corporation. All rights reserved. Permission is granted to redistribute this document if this paragraph is not removed. This document is subject to change without notice.

More information is available — Please select a different filter.
Page Last Updated: January 17, 2017