CWE Reuse vs Deprecation

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

CWE Reuse vs Deprecation

Andrew Buttner
Administrator
CWE Community,

We have been discussing the topics of reuse and deprecation internally and would like to better understand your points of view.

** QUESTION FOR THE COMMUNITY **

In a case like what is outlined below, where the change to the meaning of a CWE is subtle and it is likely that the modified CWE is close enough to the original CWE, should we reuse the existing CWE ID?  Or should we deprecate the original CWE and create a new one?

** BACKGROUND **

A CWE can be deprecated for a number of reasons. Maybe there are duplicate entries in the list, or maybe there was an error and an entry should never have been created. When a CWE is deprecated, a statement is added to the entry to explain why it was deprecated, and if possible a redirect is provided to the CWE to use instead.

There is a grey area when we decide to slightly alter an existing CWE. Let's say we want to clarify the name / description of an existing CWE, but in doing so we would change meaning a bit. If we just modify the existing CWE, then an existing mapping would still point to a "valid" CWE and would have no idea that a change was made. Of course many users might agree with the change and they wouldn't need to change their product. The other option would be to deprecate the existing CWE and create a new one for the clarified issue.  An existing mapping would now see the deprecation and know that something has changed. However this means that everyone would now need to change mappings, including those that agree with the modifications that were made.

As a concrete example ...

We are discussing combining the following two CWEs:

CWE-242 : Use of Inherently Dangerous Function
CWE-676 : Use of Potentially Dangerous Function

The difference between these two is subtle and often misunderstood. The first is about functions that are ALWAYS bad (e.g., gets()) while the second is about functions that are SOMETIMES bad (e.g., strcpy()). We are questioning if this level of distinction is necessary within CWE. We are thinking of combining these into a single entry for "Use of Dangerous Function".

We have two options:

1) Deprecate CWE-242 and expand the scope of CWE-676. Many users of CWE-676 probably already think of the weakness in these new terms anyway.  However, some users may be using CWE-676 to represent the specific current meaning and mapped to it accordingly. The new meaning is different and might not align with their use, but they would not see the change since CWE-676 is still "valid".

2) Deprecate both CWE-242 and CWE-676 and create a new CWE that covers "Use of Dangerous Functions".  This avoids the issue of an existing mapping pointing to a real CWE that doesn't mean what it did originally did. However, everyone would now be forced to update their mappings.

We are very interested in your thoughts, especially as they related to the question asked at the top of this email.

Thanks
Drew

---------

Andrew Buttner
The MITRE Corporation
[hidden email]
781-271-3515

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
|  
Report Content as Inappropriate

Re: CWE Reuse vs Deprecation

Kevin Hale
I am not a product vendor, so maybe my perspective is different.  I am part of a small, centralized security team, and I use CWEs as educational materials for the large number of development teams that I serve.  I believe that Option #2 has the benefit of maintaining the original intent of the deprecated CWEs (and their links) while still providing the sought-after clarity in the replacement CWE.  As long as the replacement CWE is added as a reference to the deprecated CWE's "Relationships", I would prefer Option #2.  I would suggest adding a new "Nature" that indicates that the relationship is one of a new CWE replacing the deprecated one, and I would suggest having it at the top of the "Relationships" list, if possible.  


-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Buttner, Drew
Sent: Wednesday, April 5, 2017 2:53 PM
To: cwe-research-list CWE Research Discussion <[hidden email]>
Subject: CWE Reuse vs Deprecation

CWE Community,

We have been discussing the topics of reuse and deprecation internally and would like to better understand your points of view.

** QUESTION FOR THE COMMUNITY **

In a case like what is outlined below, where the change to the meaning of a CWE is subtle and it is likely that the modified CWE is close enough to the original CWE, should we reuse the existing CWE ID?  Or should we deprecate the original CWE and create a new one?

** BACKGROUND **

A CWE can be deprecated for a number of reasons. Maybe there are duplicate entries in the list, or maybe there was an error and an entry should never have been created. When a CWE is deprecated, a statement is added to the entry to explain why it was deprecated, and if possible a redirect is provided to the CWE to use instead.

There is a grey area when we decide to slightly alter an existing CWE. Let's say we want to clarify the name / description of an existing CWE, but in doing so we would change meaning a bit. If we just modify the existing CWE, then an existing mapping would still point to a "valid" CWE and would have no idea that a change was made. Of course many users might agree with the change and they wouldn't need to change their product. The other option would be to deprecate the existing CWE and create a new one for the clarified issue.  An existing mapping would now see the deprecation and know that something has changed. However this means that everyone would now need to change mappings, including those that agree with the modifications that were made.

As a concrete example ...

We are discussing combining the following two CWEs:

CWE-242 : Use of Inherently Dangerous Function
CWE-676 : Use of Potentially Dangerous Function

The difference between these two is subtle and often misunderstood. The first is about functions that are ALWAYS bad (e.g., gets()) while the second is about functions that are SOMETIMES bad (e.g., strcpy()). We are questioning if this level of distinction is necessary within CWE. We are thinking of combining these into a single entry for "Use of Dangerous Function".

We have two options:

1) Deprecate CWE-242 and expand the scope of CWE-676. Many users of CWE-676 probably already think of the weakness in these new terms anyway.  However, some users may be using CWE-676 to represent the specific current meaning and mapped to it accordingly. The new meaning is different and might not align with their use, but they would not see the change since CWE-676 is still "valid".

2) Deprecate both CWE-242 and CWE-676 and create a new CWE that covers "Use of Dangerous Functions".  This avoids the issue of an existing mapping pointing to a real CWE that doesn't mean what it did originally did. However, everyone would now be forced to update their mappings.

We are very interested in your thoughts, especially as they related to the question asked at the top of this email.

Thanks
Drew

---------

Andrew Buttner
The MITRE Corporation
[hidden email]
781-271-3515

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

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
|  
Report Content as Inappropriate

Re: CWE Reuse vs Deprecation

G. Ann Campbell
In reply to this post by Andrew Buttner
Hi Drew,

First, I think it's worth pointing out that you listed 2, not 3 options. I assume that's because you didn't see the third option, rolling CWE-676 into CWE-242, as viable because while all inherently dangerous functions are also potentially dangerous, the reverse is not true.

So we're not talking here about changes that would water down existing CWEs. Or at least, that's how I read it.


That said, I think the action you take should be determined by whether the change narrows or expands the current definition. In your example, the change would expand CWE-676, so I think it could be an in-place change because afterward CWE-676 would still cover everything it did before (so no violation of the "contract"), and more. If on the the the other hand you were proposing a change that would exclude things CWE-676 currently covers, I think that would requite a deprecation and a new number.


Ann




---
G. Ann CAMPBELL | SonarSource
Product Manager

On Wed, Apr 5, 2017 at 3:52 PM, Buttner, Drew <[hidden email]> wrote:
CWE Community,

We have been discussing the topics of reuse and deprecation internally and would like to better understand your points of view.

** QUESTION FOR THE COMMUNITY **

In a case like what is outlined below, where the change to the meaning of a CWE is subtle and it is likely that the modified CWE is close enough to the original CWE, should we reuse the existing CWE ID?  Or should we deprecate the original CWE and create a new one?

** BACKGROUND **

A CWE can be deprecated for a number of reasons. Maybe there are duplicate entries in the list, or maybe there was an error and an entry should never have been created. When a CWE is deprecated, a statement is added to the entry to explain why it was deprecated, and if possible a redirect is provided to the CWE to use instead.

There is a grey area when we decide to slightly alter an existing CWE. Let's say we want to clarify the name / description of an existing CWE, but in doing so we would change meaning a bit. If we just modify the existing CWE, then an existing mapping would still point to a "valid" CWE and would have no idea that a change was made. Of course many users might agree with the change and they wouldn't need to change their product. The other option would be to deprecate the existing CWE and create a new one for the clarified issue.  An existing mapping would now see the deprecation and know that something has changed. However this means that everyone would now need to change mappings, including those that agree with the modifications that were made.

As a concrete example ...

We are discussing combining the following two CWEs:

CWE-242 : Use of Inherently Dangerous Function
CWE-676 : Use of Potentially Dangerous Function

The difference between these two is subtle and often misunderstood. The first is about functions that are ALWAYS bad (e.g., gets()) while the second is about functions that are SOMETIMES bad (e.g., strcpy()). We are questioning if this level of distinction is necessary within CWE. We are thinking of combining these into a single entry for "Use of Dangerous Function".

We have two options:

1) Deprecate CWE-242 and expand the scope of CWE-676. Many users of CWE-676 probably already think of the weakness in these new terms anyway.  However, some users may be using CWE-676 to represent the specific current meaning and mapped to it accordingly. The new meaning is different and might not align with their use, but they would not see the change since CWE-676 is still "valid".

2) Deprecate both CWE-242 and CWE-676 and create a new CWE that covers "Use of Dangerous Functions".  This avoids the issue of an existing mapping pointing to a real CWE that doesn't mean what it did originally did. However, everyone would now be forced to update their mappings.

We are very interested in your thoughts, especially as they related to the question asked at the top of this email.

Thanks
Drew

---------

Andrew Buttner
The MITRE Corporation
[hidden email]
<a href="tel:781-271-3515" value="+17812713515">781-271-3515

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

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
|  
Report Content as Inappropriate

Re: CWE Reuse vs Deprecation

Jim Duncan
In reply to this post by Andrew Buttner
Drew, all,

I apologize for top-posting, but I cannot reply in-line cleanly.

Reusing a CWE label would be a mistake. We have a custom field in our internal defect tracking system for CWE. Thousands of problem reports spanning many years now contain a CWE label corresponding to the most likely weakness at the crux of each issue. These are indexed by the CWE numeric identifier (although both the number and the short description are shown when the problem report is displayed). We (the Juniper SDL team and the SIRT) use the associated CWE in a wide variety of ways, including the production of an annual "Top Ten Software Weaknesses" report.

If you change the meaning of a single CWE label, you invalidate years of work. You also render moot the validation or reproduction of any of those historical analyses, and for zero gain. Please use the next available integer.

Regarding the second issue, I find it a powerful tool to distinguish between inherently- and potentially-dangerous functions, and I have made significant use of the contrast in formal reports as well as casual discussions and educational opportunities. Merging the two entries weakens the CWE, and -- in my opinion -- represents a race to the bottom, again for negligible benefit.

We need _more_ such distinctions and improved informational content to help others understand the fine differences. We do not need to "dumb down" the content in order to make it more accessible. This would reduce the value of CWE in order to admit an audience that won't understand it anyhow.

My two cents' worth. If you disagree, please educate me. I don't claim to have all the answers.

Thanks for all the work you and the team continue to do to maintain and improve CWE. I think it's enormously valuable.

        Jim


> On Wed 2017-04-05, at 15:52, Buttner, Drew <[hidden email]> wrote:
>
> CWE Community,
>
> We have been discussing the topics of reuse and deprecation internally and would like to better understand your points of view.
>
> ** QUESTION FOR THE COMMUNITY **
>
> In a case like what is outlined below, where the change to the meaning of a CWE is subtle and it is likely that the modified CWE is close enough to the original CWE, should we reuse the existing CWE ID?  Or should we deprecate the original CWE and create a new one?
>
> ** BACKGROUND **
>
> A CWE can be deprecated for a number of reasons. Maybe there are duplicate entries in the list, or maybe there was an error and an entry should never have been created. When a CWE is deprecated, a statement is added to the entry to explain why it was deprecated, and if possible a redirect is provided to the CWE to use instead.
>
> There is a grey area when we decide to slightly alter an existing CWE. Let's say we want to clarify the name / description of an existing CWE, but in doing so we would change meaning a bit. If we just modify the existing CWE, then an existing mapping would still point to a "valid" CWE and would have no idea that a change was made. Of course many users might agree with the change and they wouldn't need to change their product. The other option would be to deprecate the existing CWE and create a new one for the clarified issue.  An existing mapping would now see the deprecation and know that something has changed. However this means that everyone would now need to change mappings, including those that agree with the modifications that were made.
>
> As a concrete example ...
>
> We are discussing combining the following two CWEs:
>
> CWE-242 : Use of Inherently Dangerous Function
> CWE-676 : Use of Potentially Dangerous Function
>
> The difference between these two is subtle and often misunderstood. The first is about functions that are ALWAYS bad (e.g., gets()) while the second is about functions that are SOMETIMES bad (e.g., strcpy()). We are questioning if this level of distinction is necessary within CWE. We are thinking of combining these into a single entry for "Use of Dangerous Function".
>
> We have two options:
>
> 1) Deprecate CWE-242 and expand the scope of CWE-676. Many users of CWE-676 probably already think of the weakness in these new terms anyway.  However, some users may be using CWE-676 to represent the specific current meaning and mapped to it accordingly. The new meaning is different and might not align with their use, but they would not see the change since CWE-676 is still "valid".
>
> 2) Deprecate both CWE-242 and CWE-676 and create a new CWE that covers "Use of Dangerous Functions".  This avoids the issue of an existing mapping pointing to a real CWE that doesn't mean what it did originally did. However, everyone would now be forced to update their mappings.
>
> We are very interested in your thoughts, especially as they related to the question asked at the top of this email.
>
> Thanks
> Drew
>
> ---------
>
> Andrew Buttner
> The MITRE Corporation
> [hidden email]
> 781-271-3515
>
> 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].

--
James N. Duncan, CISSP
Security Engineer, Juniper Secure Development Lifecycle (SDL) Program
E-mail: [hidden email]    Mobile: +1 919 608 0748
PGP key fingerprint: E09E EA55 DA28 1399 75EB D6A2 7092 9A9C 6DC3 1821

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
|  
Report Content as Inappropriate

Re: CWE Reuse vs Deprecation

Robin Gandhi
In reply to this post by Andrew Buttner
** QUESTION FOR THE COMMUNITY **
   
    In a case like what is outlined below, where the change to the meaning of a CWE is subtle and it is likely that the modified CWE is close enough to the original CWE, should we reuse the existing CWE ID?  Or should we deprecate the original CWE and create a new one?

Suggestion:
My vote is for reusing the existing CWE-ID, because one of the design goals of the CWE is to become part of the vocabulary when discussing software weaknesses. The permanence of a CWE will allow people and security software to refer to weaknesses more consistently. Evolution and refinement of the meaning of a CWE does reflect that it is a living community resource rather than something set in stone. For existing mappings, there should be a periodic review (ideally with every CWE release) if the mappings are still accurate for the entries that are updated. There needs to be some assumption of basic CWE mapping lifecycle management. It cannot be a one and done deal.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: CWE Reuse vs Deprecation

Celia Rexselin Aloysius
In reply to this post by Andrew Buttner
Hi,

For the given example,

CWE-242 : Use of Inherently Dangerous Function
CWE-676 : Use of Potentially Dangerous Function

I would rather say that we keep both. As consumers of CWE, we need to prioritize weaknesses while identifying and escalating them to business. In this case, CWE-242 is definitely a high issue and CWE-676 is not. By clubbing both together, we would be diluting the risk factor associated with both issues and would have to rely on an external consultant or App Security resource to manually determine whether the issue is high or not.

Regards,
Celia,
Application Security Consultant,
Infosys



-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Buttner, Drew
Sent: Thursday, April 6, 2017 1:23 AM
To: cwe-research-list CWE Research Discussion <[hidden email]>
Subject: CWE Reuse vs Deprecation

CWE Community,

We have been discussing the topics of reuse and deprecation internally and would like to better understand your points of view.

** QUESTION FOR THE COMMUNITY **

In a case like what is outlined below, where the change to the meaning of a CWE is subtle and it is likely that the modified CWE is close enough to the original CWE, should we reuse the existing CWE ID?  Or should we deprecate the original CWE and create a new one?

** BACKGROUND **

A CWE can be deprecated for a number of reasons. Maybe there are duplicate entries in the list, or maybe there was an error and an entry should never have been created. When a CWE is deprecated, a statement is added to the entry to explain why it was deprecated, and if possible a redirect is provided to the CWE to use instead.

There is a grey area when we decide to slightly alter an existing CWE. Let's say we want to clarify the name / description of an existing CWE, but in doing so we would change meaning a bit. If we just modify the existing CWE, then an existing mapping would still point to a "valid" CWE and would have no idea that a change was made. Of course many users might agree with the change and they wouldn't need to change their product. The other option would be to deprecate the existing CWE and create a new one for the clarified issue.  An existing mapping would now see the deprecation and know that something has changed. However this means that everyone would now need to change mappings, including those that agree with the modifications that were made.

As a concrete example ...

We are discussing combining the following two CWEs:

CWE-242 : Use of Inherently Dangerous Function
CWE-676 : Use of Potentially Dangerous Function

The difference between these two is subtle and often misunderstood. The first is about functions that are ALWAYS bad (e.g., gets()) while the second is about functions that are SOMETIMES bad (e.g., strcpy()). We are questioning if this level of distinction is necessary within CWE. We are thinking of combining these into a single entry for "Use of Dangerous Function".

We have two options:

1) Deprecate CWE-242 and expand the scope of CWE-676. Many users of CWE-676 probably already think of the weakness in these new terms anyway.  However, some users may be using CWE-676 to represent the specific current meaning and mapped to it accordingly. The new meaning is different and might not align with their use, but they would not see the change since CWE-676 is still "valid".

2) Deprecate both CWE-242 and CWE-676 and create a new CWE that covers "Use of Dangerous Functions".  This avoids the issue of an existing mapping pointing to a real CWE that doesn't mean what it did originally did. However, everyone would now be forced to update their mappings.

We are very interested in your thoughts, especially as they related to the question asked at the top of this email.

Thanks
Drew

---------

Andrew Buttner
The MITRE Corporation
[hidden email]
781-271-3515

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

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
|  
Report Content as Inappropriate

RE: CWE Reuse vs Deprecation

Andrew Buttner
Administrator
In reply to this post by Andrew Buttner
The feedback so far has been really helpful. Thank you!  Please keep it coming. If you have opinions and don't mind sharing, please do.

Thanks
Drew


> -----Original Message-----
> From: [hidden email] [mailto:owner-cwe-research-
> [hidden email]] On Behalf Of Buttner, Drew
> Sent: Wednesday, April 5, 2017 3:53 PM
> To: cwe-research-list CWE Research Discussion <cwe-research-
> [hidden email]>
> Subject: CWE Reuse vs Deprecation
>
> CWE Community,
>
> We have been discussing the topics of reuse and deprecation internally and
> would like to better understand your points of view.
>
> ** QUESTION FOR THE COMMUNITY **
>
> In a case like what is outlined below, where the change to the meaning of a
> CWE is subtle and it is likely that the modified CWE is close enough to the
> original CWE, should we reuse the existing CWE ID?  Or should we deprecate
> the original CWE and create a new one?
>
> ** BACKGROUND **
>
> A CWE can be deprecated for a number of reasons. Maybe there are
> duplicate entries in the list, or maybe there was an error and an entry should
> never have been created. When a CWE is deprecated, a statement is added
> to the entry to explain why it was deprecated, and if possible a redirect is
> provided to the CWE to use instead.
>
> There is a grey area when we decide to slightly alter an existing CWE. Let's
> say we want to clarify the name / description of an existing CWE, but in doing
> so we would change meaning a bit. If we just modify the existing CWE, then
> an existing mapping would still point to a "valid" CWE and would have no idea
> that a change was made. Of course many users might agree with the change
> and they wouldn't need to change their product. The other option would be
> to deprecate the existing CWE and create a new one for the clarified issue.
> An existing mapping would now see the deprecation and know that
> something has changed. However this means that everyone would now
> need to change mappings, including those that agree with the modifications
> that were made.
>
> As a concrete example ...
>
> We are discussing combining the following two CWEs:
>
> CWE-242 : Use of Inherently Dangerous Function
> CWE-676 : Use of Potentially Dangerous Function
>
> The difference between these two is subtle and often misunderstood. The
> first is about functions that are ALWAYS bad (e.g., gets()) while the second is
> about functions that are SOMETIMES bad (e.g., strcpy()). We are questioning
> if this level of distinction is necessary within CWE. We are thinking of
> combining these into a single entry for "Use of Dangerous Function".
>
> We have two options:
>
> 1) Deprecate CWE-242 and expand the scope of CWE-676. Many users of
> CWE-676 probably already think of the weakness in these new terms
> anyway.  However, some users may be using CWE-676 to represent the
> specific current meaning and mapped to it accordingly. The new meaning is
> different and might not align with their use, but they would not see the
> change since CWE-676 is still "valid".
>
> 2) Deprecate both CWE-242 and CWE-676 and create a new CWE that covers
> "Use of Dangerous Functions".  This avoids the issue of an existing mapping
> pointing to a real CWE that doesn't mean what it did originally did. However,
> everyone would now be forced to update their mappings.
>
> We are very interested in your thoughts, especially as they related to the
> question asked at the top of this email.
>
> Thanks
> Drew
>
> ---------
>
> Andrew Buttner
> The MITRE Corporation
> [hidden email]
> 781-271-3515
>
> 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].

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
|  
Report Content as Inappropriate

Re: CWE Reuse vs Deprecation

Kurt Seifried
In reply to this post by Andrew Buttner


On Wed, Apr 5, 2017 at 1:52 PM, Buttner, Drew <[hidden email]> wrote:
CWE Community,

We have been discussing the topics of reuse and deprecation internally and would like to better understand your points of view.

** QUESTION FOR THE COMMUNITY **

In a case like what is outlined below, where the change to the meaning of a CWE is subtle and it is likely that the modified CWE is close enough to the original CWE, should we reuse the existing CWE ID?  Or should we deprecate the original CWE and create a new one?

** BACKGROUND **

A CWE can be deprecated for a number of reasons. Maybe there are duplicate entries in the list, or maybe there was an error and an entry should never have been created. When a CWE is deprecated, a statement is added to the entry to explain why it was deprecated, and if possible a redirect is provided to the CWE to use instead.

There is a grey area when we decide to slightly alter an existing CWE. Let's say we want to clarify the name / description of an existing CWE, but in doing so we would change meaning a bit. If we just modify the existing CWE, then an existing mapping would still point to a "valid" CWE and would have no idea that a change was made. Of course many users might agree with the change and they wouldn't need to change their product. The other option would be to deprecate the existing CWE and create a new one for the clarified issue.  An existing mapping would now see the deprecation and know that something has changed. However this means that everyone would now need to change mappings, including those that agree with the modifications that were made.

As a concrete example ...

We are discussing combining the following two CWEs:

CWE-242 : Use of Inherently Dangerous Function
CWE-676 : Use of Potentially Dangerous Function

I actually think this is an important distinction, e.g. some functions are just not safe anymore. For example various SSL/TLS related clients that do NOT check certificate hostnames, at all. Quite often these are fixed by adding the capability to check the hostname, but you have to explicitly call this. This is a perfect example of a piece of software with a CWE making an improvement (moving from completely broken, to broken by default, but can be used safely), and it is a huge difference. 
 

The difference between these two is subtle and often misunderstood. The first is about functions that are ALWAYS bad (e.g., gets()) while the second is about functions that are SOMETIMES bad (e.g., strcpy()). We are questioning if this level of distinction is necessary within CWE. We are thinking of combining these into a single entry for "Use of Dangerous Function".

But most functions are potentially dangerous/can be abused in some stupid/creative way that results in a vuln.
 

We have two options:

1) Deprecate CWE-242 and expand the scope of CWE-676. Many users of CWE-676 probably already think of the weakness in these new terms anyway.  However, some users may be using CWE-676 to represent the specific current meaning and mapped to it accordingly. The new meaning is different and might not align with their use, but they would not see the change since CWE-676 is still "valid".

2) Deprecate both CWE-242 and CWE-676 and create a new CWE that covers "Use of Dangerous Functions".  This avoids the issue of an existing mapping pointing to a real CWE that doesn't mean what it did originally did. However, everyone would now be forced to update their mappings.

We are very interested in your thoughts, especially as they related to the question asked at the top of this email.

In this case I would say keep them as is but maybe expand the scope of documentation/examples to make it more concrete. 
 

Thanks
Drew

---------

Andrew Buttner
The MITRE Corporation
[hidden email]
<a href="tel:781-271-3515" value="+17812713515">781-271-3515

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



--
Kurt Seifried
[hidden email]
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
|  
Report Content as Inappropriate

Re: CWE Reuse vs Deprecation

Scott Christiansen
In reply to this post by Andrew Buttner

It seems as though there are a few parallel themes going on in the below message, and I'll try and provide feedback to each.

 

The first questions seems more like a conversation on "how granular should CWE be?"

 

The second is concerning your example.  From a security professional point of view, I wouldn't change it at all.  If CWE-242 highlights "always bad" then I can write a grep to check my code and always show a developer that these are bad and that they should never be used.  The time to fix here is also small because anytime they show up, a limited amount of dev time needs to be spent to fix them.  That "always bad" is a significantly different risk level than the "sometimes bad" called out by CWE-676 that someone would have to evaluate context on.  These are going to require a bit more time to boil down the context thus costing additional dev time.  From an SDL point of view, if I have a min bar security gate that needs to be passed before a dev can ship and they need to ship immediately, I would require them to fix all CWE-242 issues and require a follow-up on CWE-676 after deployment.

 

The third issue is around your main point of either create a new CWE or collapse/modify an existing one.  If two CWE entries are similar I do believe you should keep one and simply reword it.  However, in this example I think these two are very contextually different.  All of the file system path traversal CWEs would be a better example in which they could and should all be rolled into one single CWE.

 

Scott Christiansen

Sr Security Program Manager

Trustworthy Computing Security Engineering

Microsoft

 

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
|  
Report Content as Inappropriate

Re: CWE Reuse vs Deprecation

Kent Landfield
In reply to this post by Jim Duncan
+1 here.  I agree with all that’s said in Jim’s response
-----
Kent Landfield
817-637-8026
[hidden email]

On 4/5/17, 6:10 PM, "[hidden email] on behalf of Jim Duncan" <[hidden email] on behalf of [hidden email]> wrote:

    Drew, all,
   
    I apologize for top-posting, but I cannot reply in-line cleanly.
   
    Reusing a CWE label would be a mistake. We have a custom field in our internal defect tracking system for CWE. Thousands of problem reports spanning many years now contain a CWE label corresponding to the most likely weakness at the crux of each issue. These are indexed by the CWE numeric identifier (although both the number and the short description are shown when the problem report is displayed). We (the Juniper SDL team and the SIRT) use the associated CWE in a wide variety of ways, including the production of an annual "Top Ten Software Weaknesses" report.
   
    If you change the meaning of a single CWE label, you invalidate years of work. You also render moot the validation or reproduction of any of those historical analyses, and for zero gain. Please use the next available integer.
   
    Regarding the second issue, I find it a powerful tool to distinguish between inherently- and potentially-dangerous functions, and I have made significant use of the contrast in formal reports as well as casual discussions and educational opportunities. Merging the two entries weakens the CWE, and -- in my opinion -- represents a race to the bottom, again for negligible benefit.
   
    We need _more_ such distinctions and improved informational content to help others understand the fine differences. We do not need to "dumb down" the content in order to make it more accessible. This would reduce the value of CWE in order to admit an audience that won't understand it anyhow.
   
    My two cents' worth. If you disagree, please educate me. I don't claim to have all the answers.
   
    Thanks for all the work you and the team continue to do to maintain and improve CWE. I think it's enormously valuable.
   
    Jim
   
   
    > On Wed 2017-04-05, at 15:52, Buttner, Drew <[hidden email]> wrote:
    >
    > CWE Community,
    >
    > We have been discussing the topics of reuse and deprecation internally and would like to better understand your points of view.
    >
    > ** QUESTION FOR THE COMMUNITY **
    >
    > In a case like what is outlined below, where the change to the meaning of a CWE is subtle and it is likely that the modified CWE is close enough to the original CWE, should we reuse the existing CWE ID?  Or should we deprecate the original CWE and create a new one?
    >
    > ** BACKGROUND **
    >
    > A CWE can be deprecated for a number of reasons. Maybe there are duplicate entries in the list, or maybe there was an error and an entry should never have been created. When a CWE is deprecated, a statement is added to the entry to explain why it was deprecated, and if possible a redirect is provided to the CWE to use instead.
    >
    > There is a grey area when we decide to slightly alter an existing CWE. Let's say we want to clarify the name / description of an existing CWE, but in doing so we would change meaning a bit. If we just modify the existing CWE, then an existing mapping would still point to a "valid" CWE and would have no idea that a change was made. Of course many users might agree with the change and they wouldn't need to change their product. The other option would be to deprecate the existing CWE and create a new one for the clarified issue.  An existing mapping would now see the deprecation and know that something has changed. However this means that everyone would now need to change mappings, including those that agree with the modifications that were made.
    >
    > As a concrete example ...
    >
    > We are discussing combining the following two CWEs:
    >
    > CWE-242 : Use of Inherently Dangerous Function
    > CWE-676 : Use of Potentially Dangerous Function
    >
    > The difference between these two is subtle and often misunderstood. The first is about functions that are ALWAYS bad (e.g., gets()) while the second is about functions that are SOMETIMES bad (e.g., strcpy()). We are questioning if this level of distinction is necessary within CWE. We are thinking of combining these into a single entry for "Use of Dangerous Function".
    >
    > We have two options:
    >
    > 1) Deprecate CWE-242 and expand the scope of CWE-676. Many users of CWE-676 probably already think of the weakness in these new terms anyway.  However, some users may be using CWE-676 to represent the specific current meaning and mapped to it accordingly. The new meaning is different and might not align with their use, but they would not see the change since CWE-676 is still "valid".
    >
    > 2) Deprecate both CWE-242 and CWE-676 and create a new CWE that covers "Use of Dangerous Functions".  This avoids the issue of an existing mapping pointing to a real CWE that doesn't mean what it did originally did. However, everyone would now be forced to update their mappings.
    >
    > We are very interested in your thoughts, especially as they related to the question asked at the top of this email.
    >
    > Thanks
    > Drew
    >
    > ---------
    >
    > Andrew Buttner
    > The MITRE Corporation
    > [hidden email]
    > 781-271-3515
    >
    > 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].
   
    --
    James N. Duncan, CISSP
    Security Engineer, Juniper Secure Development Lifecycle (SDL) Program
    E-mail: [hidden email]    Mobile: +1 919 608 0748
    PGP key fingerprint: E09E EA55 DA28 1399 75EB D6A2 7092 9A9C 6DC3 1821
   
    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
|  
Report Content as Inappropriate

Re: CWE Reuse vs Deprecation

Ken Prole-2
In reply to this post by Andrew Buttner
In general, I would agree to keeping an existing CWE even if it was modified slightly. CWE is a bit subjective already, so changing the meaning *slightly* I don't think is such a big deal. The real question is how drastic of a change it really is?

Your specific example is interesting however. I wonder if there's two other options (1) keep it as is or (2) add a parent element.

An argument can be made that being able to differentiate CWE-242 and CWE-676 is important. From a triage perspective, I would want to address the CWE-242 issues before CWE-676, since CWE-242 issues are ALWAYS bad, and CWE-676 are SOMETIMES bad. And I generally prefer having the ability to have more specificity when selecting a CWE. Although in this case, I'm not sure how important the distinction is. Can't gets() and strcpy both be used in a safe and unsafe manor depending on surrounding code and what the attacker has access to? It seems like there are arguments for having the distinction however, and if so then I think it's better to have a CWE for both.

What's interesting is these two CWEs fall in different parts of the CWE hierarchy with no relationship. CWE-242 is under "API Abuse" and CWE-676 is under "Code Quality". If you merge CWE-242 with CWE-676 does it then mean you are saying this is a Code Quality issue and not API Abuse? I think an argument can be made that both should be under "Code Quality". Is using gets() abusing the API? It's being used how it was designed to, no? CWE-242 also has a "CanPrecede" relationship with CWE-120 Buffer Overflow, that you would be removing if you deprecate CWE-242.

Another thought is to keep both under "API Abuse" or "Code Quality" and have a new parent CWE called "Use of Dangerous Functions". People can pick that CWE or be more specific and choose a child CWE. By having those two CWEs be close in CWE hierarchy maybe people would use it more appropriately.

I can see any these four options being viable. My vote would be to keep them as is for many of the reasons expressed by others, and it doesn't sound like there's great benefit to changing things.

- Ken

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Buttner, Drew
Sent: Wednesday, April 5, 2017 3:53 PM
To: cwe-research-list CWE Research Discussion <[hidden email]>
Subject: CWE Reuse vs Deprecation

CWE Community,

We have been discussing the topics of reuse and deprecation internally and would like to better understand your points of view.

** QUESTION FOR THE COMMUNITY **

In a case like what is outlined below, where the change to the meaning of a CWE is subtle and it is likely that the modified CWE is close enough to the original CWE, should we reuse the existing CWE ID?  Or should we deprecate the original CWE and create a new one?

** BACKGROUND **

A CWE can be deprecated for a number of reasons. Maybe there are duplicate entries in the list, or maybe there was an error and an entry should never have been created. When a CWE is deprecated, a statement is added to the entry to explain why it was deprecated, and if possible a redirect is provided to the CWE to use instead.

There is a grey area when we decide to slightly alter an existing CWE. Let's say we want to clarify the name / description of an existing CWE, but in doing so we would change meaning a bit. If we just modify the existing CWE, then an existing mapping would still point to a "valid" CWE and would have no idea that a change was made. Of course many users might agree with the change and they wouldn't need to change their product. The other option would be to deprecate the existing CWE and create a new one for the clarified issue.  An existing mapping would now see the deprecation and know that something has changed. However this means that everyone would now need to change mappings, including those that agree with the modifications that were made.

As a concrete example ...

We are discussing combining the following two CWEs:

CWE-242 : Use of Inherently Dangerous Function
CWE-676 : Use of Potentially Dangerous Function

The difference between these two is subtle and often misunderstood. The first is about functions that are ALWAYS bad (e.g., gets()) while the second is about functions that are SOMETIMES bad (e.g., strcpy()). We are questioning if this level of distinction is necessary within CWE. We are thinking of combining these into a single entry for "Use of Dangerous Function".

We have two options:

1) Deprecate CWE-242 and expand the scope of CWE-676. Many users of CWE-676 probably already think of the weakness in these new terms anyway.  However, some users may be using CWE-676 to represent the specific current meaning and mapped to it accordingly. The new meaning is different and might not align with their use, but they would not see the change since CWE-676 is still "valid".

2) Deprecate both CWE-242 and CWE-676 and create a new CWE that covers "Use of Dangerous Functions".  This avoids the issue of an existing mapping pointing to a real CWE that doesn't mean what it did originally did. However, everyone would now be forced to update their mappings.

We are very interested in your thoughts, especially as they related to the question asked at the top of this email.

Thanks
Drew

---------

Andrew Buttner
The MITRE Corporation
[hidden email]
781-271-3515

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

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
|  
Report Content as Inappropriate

Re: CWE Reuse vs Deprecation

Amy Gale
In reply to this post by Celia Rexselin Aloysius

To me, it seems most logical to make CWE-676 a parent of CWE-242 . As Ann Campbell said, all inherently dangerous functions are also potentially dangerous; as many people said, there is value in maintaining the distinction. An explicit parent-child relationship should also help resolve at least some user misunderstandings.

You could then interpose a new "use of dangerous function" above CWE-676, but that doesn't seem immediately necessary.

For the more general question, my opinion is that IDs shouldn't be reused if any bug could fall into the symmetric difference of the old definition and the new definition. Otherwise, existing classification bases are invalidated - Jim Duncan has given a concrete example.

Amy Gale
Senior Technical Writer
GrammaTech, Inc.

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
|  
Report Content as Inappropriate

Re: CWE Reuse vs Deprecation

Joe Jarzombek

From a Synopsys perspective (coordinated with our R&D team), we would prefer to keep the separate CWEs 242 and 676.  The "always bad" for CWE-242 is a different risk level than the "sometimes bad" for CWE-676.  There is value in the distinctions, even from a CWSS technical impact.  Context is important in prioritizing remediation efforts.   

 

We would not want to reuse or repurpose a CWE-ID.  If the community is in favor of combining or deprecating similar CWEs, then we would vote in favor of creating a new CWE-ID that covers the related weaknesses (and not reusing or redefining one of those from which the combined/deprecated CWE was derived). 

 

Even though such a change of a combined/deprecated CWE would require an update to our mappings, we have designed our taxonomy system to accommodate these kinds of changes.  We usually have several issue types mapping to a single CWE, so if it becomes necessary to rearrange the mapping (taxonomy) in any way, the fine-level detail is always available for those who want that level of description. 

 

The difference only matters if (a) we report issues in both CWEs 242 & 676 and (b) a user cares about the distinction even after the potential revision to the CWE taxonomy.  If both of those conditions are true, then there is concern that the merge could potentially discard information that our mapping previously encoded and that our hypothetical user wants to know -- that is, our user could no longer tell if an issue in the combined CWE (CWE 676 in this example) corresponds to the old interpretation (just CWE 676) or the new one (old CWE 676 or old CWE 242).  If you create a new CWE, we could map issues from both (676, 242) to it and leave the old mappings in place.  We don't see it as a critical use case, but all things equal, we'd rather not throw away information.  

 

Regards,

 

   -Joe -

 

Joe Jarzombek, CSSLP 

Global Manager, Software Supply Chain Solutions

Email: [hidden email]  |  Mobile: 703 627-4644

Synopsys Software Integrity Group  |  www.synopsys.com/software  cid:image002.jpg@01D23376.09F8BF20  cid:image003.jpg@01D23376.09F8BF20  cid:image004.jpg@01D23376.09F8BF20

See my QAI Global Institute webinar on “Cybersecurity Technical Risk Indicators: A Measure of Technical Debt” at https://vimeo.com/206456054 | Download Presentation Slides  

Synopsys Named a Leader in AppSec Testing in Gartner’s 2017 Magic Quadrant – see https://software.synopsys.com/2017-gartner-magic-quadrant.html

 

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Amy Gale
Sent: Friday, April 07, 2017 9:52 AM
To: cwe-research-list CWE Research Discussion <[hidden email]>
Subject: Re: CWE Reuse vs Deprecation

 

To me, it seems most logical to make CWE-676 a parent of CWE-242 . As Ann Campbell said, all inherently dangerous functions are also potentially dangerous; as many people said, there is value in maintaining the distinction. An explicit parent-child relationship should also help resolve at least some user misunderstandings.

You could then interpose a new "use of dangerous function" above CWE-676, but that doesn't seem immediately necessary.

For the more general question, my opinion is that IDs shouldn't be reused if any bug could fall into the symmetric difference of the old definition and the new definition. Otherwise, existing classification bases are invalidated - Jim Duncan has given a concrete example.

Amy Gale
Senior Technical Writer
GrammaTech, Inc.

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

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
|  
Report Content as Inappropriate

Re: CWE Reuse vs Deprecation

Wheeler, David A
In reply to this post by Andrew Buttner
Buttner, Drew:
> ** QUESTION FOR THE COMMUNITY **
>
> In a case like what is outlined below, where the change to the meaning of a
> CWE is subtle and it is likely that the modified CWE is close enough to the
> original CWE, should we reuse the existing CWE ID?  Or should we deprecate
> the original CWE and create a new one?

I think this varies case-by-case.  But let's look at the specific example:

> CWE-242 : Use of Inherently Dangerous Function
> CWE-676 : Use of Potentially Dangerous Function
>
> The difference between these two is subtle and often misunderstood. The
> first is about functions that are ALWAYS bad (e.g., gets()) while the second is
> about functions that are SOMETIMES bad (e.g., strcpy()). We are questioning
> if this level of distinction is necessary within CWE.

Yes, it *is* necessary, because what you *do* about it differs:
* If a function is inherently dangerous, you can immediately flag all uses as being more likely to be important, and analysis of it probably needs to be prioritized.
* In contrast, a "potentially" dangerous function demands much more analysis.

I think what's needed is clarifying text, not elimination.

In general, in any (re)organization of the CWE, a critical question should be, "will what I do change based on this difference?"  If something will tend to be prioritized higher (at least for analysis), or if different measures/countermeasures will be invoked, then a different CWE makes sense.

--- David A. Wheeler

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].
Loading...