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:
- 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.
- 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.
- 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.
- 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:
- 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.
- 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.
- 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:
- 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.
- 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.
- 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 edit the custom filter or select a different filter.
|
