Planned Changes to the CWE Development View (CWE-699)

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Planned Changes to the CWE Development View (CWE-699)

Christey, Steven M.
All,

In the coming months, the CWE team is planning to reorganize certain
portions of the Development Concepts view (CWE-699), which is used to
organize weaknesses around concepts that are frequently encountered in
software development.

The graph structure of this view can be seen at
https://cwe.mitre.org/data/graphs/699.html; other presentations are
available in the tabs on the upper right, just under the view's name.

Our primary goal is to simplify navigation across the hierarchy for
users, while reducing noise.

We would like your input on the following suggested changes.  Please
respond by Thursday, December 8; we plan to implement some of these
changes in the next CWE version, which we hope to release later in
December.

We plan to:

- remove several high-level entries that introduce inaccuracies and
  make the view unnecessarily deep and/or inaccurate, e.g. the
  "Location" / "Code" / "Source Code" categories and similar
  sub-categories.  These might also lead to deprecation of such
  entries (but, if we do so, we would want to ensure that any
  necessary information from those entries is properly represented,
  e.g. within particular schema elements such as "time of
  introduction.")

  We probably have to make special accomodations to preserve CWE-16
  ("Configuration"), which is a category used by NIST's NVD (and
  probably others) to map configuration-related issues.  While we
  discourage CWE users from mapping to categories, we recognize that
  sometimes there is no suitable CWE weakness available (see
  https://cwe.mitre.org/documents/cwe_usage/mapping_navigation.html
  for more.)

- remove "child views" from the CWE-699 development hierarchy, such as
  CWE-629 (2007 OWASP Top Ten).  We believe that such "child views"
  create unnecessary complexity and "noise" for users who are
  traversing the CWE-699 hierarchy.  Note that we do not necessarily
  plan to remove or deprecate these "child views" from CWE itself; we
  only plan to disassociate them from the Development view.

- identify and resolve duplicate or near-duplicate entries.  While we
  have actively sought and eliminated duplicates in the past, we have
  concentrated primarily on weakness-oriented entries.  But within the
  Development view, sometimes there is a category-oriented CWE entry
  that also has a separate, equivalent weakness-oriented entry.  For
  example, CWE-264 (Permissions, Privileges, and Access Control) - a
  category - is arguably equivalent to CWE-284 (Improper Access
  Control), a weakness class.

- align the abstraction of children so that it is more consistent.
  This is especially problematic with the Development view.  For
  example, CWE-20 (improper input validation) is at the Class level,
  but its immediate children include variants, bases, and other
  classes.  The "Injection" class (CWE-74) is at the same level as
  improper address validation in an IOCTL (CWE-781), which is a
  variant.  We believe that such inconsistencies may cause unnecessary
  confusion and noise.

We are looking forward to any feedback that you may have.


Thank you,
Steve and Drew

To unsubscribe, send an email message to [hidden email] with SIGNOFF CWE-RESEARCH-LIST in the BODY of the message. If you have difficulties, write to [hidden email].
Reply | Threaded
Open this post in threaded view
|

RE: Planned Changes to the CWE Development View (CWE-699)

Christey, Steven M.
Kurt,

While CWE's focus is on the technical issues, categories typically serve as mechanisms to organize views using concepts that are familiar to a view’s intended audience; this can make it easier for the user to navigate the associated tree for purposes of finding the right CWE to map to, or to explore a certain area.  The research view (CWE-1000) explicitly avoids categories in an effort to characterize its entries in terms of behaviors/resources/etc (see “Taxonomic and Related Properties” in https://cwe.mitre.org/documents/views/view-comparison.html), and as mentioned in the original email, users are discouraged from mapping to categories.  However, the development view uses categories liberally in order to give developers multiple paths to navigate to the relevant weaknesses.

For "operational" things, such as your example of "no automated tests," these might be more appropriately described as external human practices that can make it easier to introduce weaknesses into software.  While we had considered extending CWE to cover such topics a couple years ago, our current (and likely future) focus will be on the technical weaknesses themselves, as artifacts within code, design documents, etc.  I think the kind of practices you're talking about are already somewhat covered by efforts such as the Building Security In Maturity Model (BSIMM), OpenSAMM, etc.

- Steve



From: Kurt Seifried [mailto:[hidden email]]
Sent: Saturday, December 10, 2016 11:29 AM
To: Christey, Steven M. <[hidden email]>
Cc: cwe-research-list CWE Research Discussion <[hidden email]>
Subject: Re: Planned Changes to the CWE Development View (CWE-699)

I've actually never seen CWE-699 before this, I had always assumed CWE covered specific technical issues like buffer overflow, xss, csrf, etc. What is the scope of coverage of CWE of these more process/operational side things? E.g. could we have a CWE for "no automated tests" or similar?

On Thu, Dec 1, 2016 at 5:52 PM, Steven M. Christey <mailto:[hidden email]> wrote:
All,

In the coming months, the CWE team is planning to reorganize certain
portions of the Development Concepts view (CWE-699), which is used to
organize weaknesses around concepts that are frequently encountered in
software development.

The graph structure of this view can be seen at
https://cwe.mitre.org/data/graphs/699.html; other presentations are
available in the tabs on the upper right, just under the view's name.

Our primary goal is to simplify navigation across the hierarchy for
users, while reducing noise.

We would like your input on the following suggested changes.  Please
respond by Thursday, December 8; we plan to implement some of these
changes in the next CWE version, which we hope to release later in
December.

We plan to:

- remove several high-level entries that introduce inaccuracies and
  make the view unnecessarily deep and/or inaccurate, e.g. the
  "Location" / "Code" / "Source Code" categories and similar
  sub-categories.  These might also lead to deprecation of such
  entries (but, if we do so, we would want to ensure that any
  necessary information from those entries is properly represented,
  e.g. within particular schema elements such as "time of
  introduction.")

  We probably have to make special accomodations to preserve CWE-16
  ("Configuration"), which is a category used by NIST's NVD (and
  probably others) to map configuration-related issues.  While we
  discourage CWE users from mapping to categories, we recognize that
  sometimes there is no suitable CWE weakness available (see
  https://cwe.mitre.org/documents/cwe_usage/mapping_navigation.html
  for more.)

- remove "child views" from the CWE-699 development hierarchy, such as
  CWE-629 (2007 OWASP Top Ten).  We believe that such "child views"
  create unnecessary complexity and "noise" for users who are
  traversing the CWE-699 hierarchy.  Note that we do not necessarily
  plan to remove or deprecate these "child views" from CWE itself; we
  only plan to disassociate them from the Development view.

- identify and resolve duplicate or near-duplicate entries.  While we
  have actively sought and eliminated duplicates in the past, we have
  concentrated primarily on weakness-oriented entries.  But within the
  Development view, sometimes there is a category-oriented CWE entry
  that also has a separate, equivalent weakness-oriented entry.  For
  example, CWE-264 (Permissions, Privileges, and Access Control) - a
  category - is arguably equivalent to CWE-284 (Improper Access
  Control), a weakness class.

- align the abstraction of children so that it is more consistent.
  This is especially problematic with the Development view.  For
  example, CWE-20 (improper input validation) is at the Class level,
  but its immediate children include variants, bases, and other
  classes.  The "Injection" class (CWE-74) is at the same level as
  improper address validation in an IOCTL (CWE-781), which is a
  variant.  We believe that such inconsistencies may cause unnecessary
  confusion and noise.

We are looking forward to any feedback that you may have.


Thank you,
Steve and Drew

To unsubscribe, send an email message to mailto:[hidden email] with SIGNOFF CWE-RESEARCH-LIST in the BODY of the message. If you have difficulties, write to mailto:[hidden email].




--

--
Kurt Seifried -- Red Hat -- Product Security -- Cloud
PGP A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
Red Hat Product Security contact: mailto:[hidden email]