Managing Node Restructuring in CWE

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

Managing Node Restructuring in CWE

Steven M. Christey-2

This document is also on the web site, but it's being posted here to kick
off the discussions.

We might not be covering all the possible options.  In addition, you might
have some strong opinions about which option is best for your needs, or
which option wouldn't work for you at all.  Feel free to post to this list
with any feedack.

- Steve

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

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 ==========

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 ==========

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

3) The community is encouraged to suggest other options.

=========== 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.