FW: Natural Hierarchy email

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

FW: Natural Hierarchy email

Harris, Conor O.
Hi All,

In earlier CWE drafts, the CWE hierarchy was mostly based on weakness
abstractions - that is parent / child relationships were focused on the
abstraction of the core weakness being addressed by each. But
weaknesses in some areas of the hierarchy were grouped together based
on a common attribute such as language, resource or consequence, the
relevance of which can change based on the context of the weakness
occurrence or the perspective of the viewer. As a result, weaknesses
were sometimes children of categories that had little to do with the
underlying problem, but provided a convenient way in which to view
issues from certain perspectives.  While these perspective and context
based views into CWE are very useful for some, a view based solely on
weaknesses and their abstractions is also needed.

In an effort to provide this additional perspective into CWE, the CWE
team began adding additional relationships to some entries in the
release of draft 9. These relationships are based on the fundamental
weakness behind each entry and how it relates to other weaknesses in
terms of abstraction and small variations on similar issues. We are
attempting to identify relationships that are as independent of
specific language, technology, programming idiom, and resource as
possible.

The slight shift in focus between drafts 7 and 8 led to several new
schema constructs being added for draft 9, one of which being the Class
/ Base / Variant attribute added to the weaknesses structure - a
derivation of the draft 8 Grouping attribute - in order to facilitate
the abstraction-based relationships. The CWE team has expanded on this
for the release of version 1.0, and can be demonstrated in part by the
top level of the natural hierarchy, view-1000, and a small subset of
their children shown below.


 * Range Errors
   o Unbounded Transfer ('Classic Buffer Overflow')
   o Incorrect Offset into a File
 * Equivalence [Draft Concept for 1.0]
   o Insufficient Comparison
   o Failure to Resolve Case Sensitivity
   o Encoding Error
 * Incorrect Calculation
   o Off-by-one Error
   o Divide by Zero
 * Failure to Fulfill API Contract (aka 'API Abuse')
   o Failure to Follow Specification
   o Failure to Provide Specified Functionality
 * Coding Rule Violation
   o Violation of Secure Design Principles
   o Use of Inherently Dangerous Function
   o Use of Potentially Dangerous Function
 * Security Features (Protection Mechanism Failure) [Merging is new for
1.0]
   o Incomplete Blacklist
   o Weak Encryption
   o Insufficient Authentication
 * Use of Insufficiently Random Values
   o Insufficient Entropy
   o Small Space of Random Values
 * Interaction Error
   o Compiler Removal of Code to Clear Buffers
   o Interpretation Conflict
   o Reliance on Data Memory Layout
   o Behavioral Change in New Version or Environment
 * Insufficient Control of  Resource Through its Lifetime
   o Improper Resource Shutdown or Release
   o Incorrect or Incomplete Initialization
   o External Influence of Sphere Definition
   o Incorrect Resource Transfer Between Spheres
   o Operation on Resource in Wrong Phase of Lifetime
 * Insufficient Control Flow Management
   o Insufficient Synchronization
   o Always-Incorrect Control Flow Implementation
   o Incorrect Behavior Order
   o Deployment of Wrong Handler
 * Failure to Handle Exceptional Conditions
   o Missing Error Handling Mechanism
   o Unexpected Status Code or Return Value
 * Failure to Maintain Cohesion in Structured Messages or Data [New
Concept for 1.0]
   o Failure to Sanitize Special Elements
   o Deletion of Data Structure Sentinel
   o Improper Null Termination


It is important to emphasize that CWE will still be navigable by common
attributes, such as language, consequence and platform after the
release of CWE version 1.0 through various "views". Prior relationships
were preserved in the development of the natural hierarchy and can
still be viewed from the individual CWE Definition pages or through an
alternate view where the relationships carry more meaning. For example,
CWE will be supporting a Programming Concepts view as well as a 7
Pernicious Kingdoms view starting with version 1.0.

The 7 Pernicious Kingdom view will be based on the original 7PK paper
and is focused primarily on usefulness to developers and grouping
weaknesses by categories. The Programming Concepts view will be an
expansion of sorts from the 7PK view which will incorporate the
additional content that has been added to CWE. These views will
accommodate navigation similar to previous drafts of CWE using
categories such as pointer issues, mobile code issues, error handling,
data handling, cleansing, comparison and canonicalization, time and
state, temporary file issues, and channel and path errors. Different
views allow for the organization of the content in the manner that
makes the most sense for the intended audience of each view.

The natural hierarchy as described above is the result of a
reorganization of the draft 8 hierarchy. We focused more on
abstractions of the core issues behind each weakness to try to unify
the perspective throughout the natural hierarchy. This entails moving
away from relationships based on weakness context, environment, or
technologies. In draft 8 of CWE, for example, CWE-5 Misconfiguration:
Data Transmission without Encryption is a child of CWE-4 J2EE
Environment Issues. While this is a useful relationship, especially for
a J2EE developer, CWE-4 is a technology specific grouping of CWE-5 and
there may or may not be any relationship between CWE-5 and its siblings
other than a common technology. In version 1.0 of CWE, an additional
"ChildOf" relationship was added to CWE-5 relating it to CWE-319
Plaintext Transmission of Sensitive Data because CWE-5 is a technology
specific variant of the more abstract weakness, CWE-319. It is
important to note that CWE-5 is still a "ChildOf" CWE-4. This
relationship is maintained in a different "View", another schema
construct added for draft 9.

To further illustrate these changes, CWE-444 HTTP Request Smuggling was
a child of CWE-442 Web Problems in draft 8. Once again, this
relationship might be a useful way for a web developer to come across
relevant problems, but it doesn't tell us very much about the more
abstract issue behind CWE-444 nor does it give us any indication as to
how CWE-444 is related to its siblings aside from web technologies. For
draft 9, a relationship was added to CWE-444 making it a "ChildOf"
CWE-436 Interpretation Conflict, which is more aligned with the
fundamental problem behind CWE-444.

A hierarchy focused on abstraction can allow for more intuitive and
consistent navigation of the CWE tree from top to bottom. This approach
may be more useful to researchers, educators and coverage mapping for
code analysis tool vendors. Organizing the weaknesses hierarchically by
abstraction helps the CWE team identify gaps and inconsistencies in CWE
and it also helps tool vendors identify gaps in their mappings. For
example, duplicates CWE-132 Miscalculated Null Termination and CWE-170
Improper Null Termination used to be in disjoint segments of the
hierarchy. When reorganized by core weakness, they fell in the same
location; thus identifying the content of each entry as duplicates was
much more obvious. Furthermore, applying "Chains" and "Composites" to
an abstraction-based hierarchy can be useful for identifying higher
level trends in weakness occurrences, potential mitigation strategies
and their impact, and is another useful mechanism for finding gaps in
CWE coverage. In addition, these concepts have helped us to understand
why classification has been such a difficult challenge in the past.

Another benefit of collocating similar core weaknesses is the ease of
applying a consistent vocabulary across CWE. Weaknesses that had no
relationships before are brought together and allow the CWE team to see
inconspicuous relationships and trends. For example, CWE-696 Incorrect
Behavior Order was created as a weakness class for several entries
where the fundamental problem was performing operations in the
incorrect sequence. The first level of children of CWE-696 under the
natural hierarchy now read:

* CWE-179 Incorrect Behavior Order: Early Validation
* CWE-408 Incorrect Behavior Order: Early Amplification
* CWE-551 Incorrect Behavior Order: Authorization Before Parsing
and Canonicalization

As a result, when we peer into other views of CWE and come across these
weaknesses, we can immediately identify what the core issue is.

The natural hierarchy view is simply one view meant to unify the
weaknesses within CWE in a way that can be understood by a broad
audience based on underlying factors of each weakness rather than the
context in which the weakness occurs or how the weakness can be
mitigated. By ignoring such variables as environment, consequence,
mitigation, attacks, and relationship impact, we have been able to find
the factors that make each weakness unique and canonical. Likewise, we
have been able to identify gaps and create a more mature CWE model,
have identified areas for further research, and laid the groundwork for
a more solid understanding of the complexity of weaknesses and their
impact. With such a foundation we can then start adding in the
previously discounted variables to create a more complex and thorough
understanding of issues caused by the existence of these weaknesses.

Any thoughts, suggestions or concerns are welcome, either to this
thread or [hidden email].

-Conor Harris