Some asking about CWE.

[Tadashi Yamagishi]

Dear CWE group,

I am Tadashi Yamagishi
 in Information-technology Promotion Agency, Japan (IPA).
We(IPA) have Vulnerability Countermeasure
 Information Database (JVN iPedia) for Japanese IT user.
http://jvndb.jvn.jp/index_en.html

JVN iPedia adapted CVSS(Common Vulnerability Scoring System) last year.
The next step, I think that JVN iPedia need CWE.
I am studying CWE draft 9 now.
I have three questions about CWE.

Question1:About Hierarchy diagram.
I made CWE-635(Weaknesses Used by NVD) a hierarchy diagram
 referring to cwe_classification_tree.pdf.
The hierarchy diagram is appended.
cwe_classification_tree.pdf shows the following.
 CWE-20 is a child of CWE-19.
 CWE-22 is a child of CWE-21.
 CWE-134 is a child of CWE-133.
However, CWE-1000(Natural Hierarchy) shows another parents.
I am confused. Are two or more parents permitted in CWE ?
I think that cwe_classification_tree.pdf and CWE-1000
 are comprehensible when it is the same.

Question2:About the classification of Dos( Denial of Service ).
DoS is not classified in CWE.
How do you classify it when the cause of the DoS is not understood
 in the vulnerability report?

Question3:About XSS vulnerabilities.
There are lots of XSS vulnerabilities
 by the UTF-7 encoded string problems in Japan.
for example:
  CVE - CVE-2008-1468
  http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1468
  JVNDB-2008-000018 - JVN iPedia
  http://jvndb.jvn.jp/contents/en/2008/JVNDB-2008-000018.html

  CVE - CVE-2008-2168
  http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-2168

  CVE - CVE-2008-0005
  http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-0005

I want to classify the detail of XSS.
Can I choose a CWE-ID more detail than CWE-79
 about XSS(UTF-7 encoded string problems)?

I look forward to your reply.

Sincerely yours,
Tadashi Yamagishi
IT Security Center (ISEC)
Information-technology Promotion Agency, Japan (IPA)
E-mail: t-yamagi@...

[Steven M. Christey-2]

On Mon, 25 Aug 2008, Tadashi Yamagishi wrote:

> Question1:About Hierarchy diagram.
> I made CWE-635(Weaknesses Used by NVD) a hierarchy diagram
>  referring to cwe_classification_tree.pdf.
> The hierarchy diagram is appended.
> cwe_classification_tree.pdf shows the following.
>  CWE-20 is a child of CWE-19.
>  CWE-22 is a child of CWE-21.
>  CWE-134 is a child of CWE-133.
> However, CWE-1000(Natural Hierarchy) shows another parents.
> I am confused. Are two or more parents permitted in CWE ?

Yes.  This is for two reasons:

  (1) there are multiple ways of looking at the same weakness, so we want
      to support these different ways.  So, different views can express
      different relationships.

  (2) Some weaknesses can be fairly complex, so they can be classified in
      different ways, even within the same view.  Ideally, it would be
      good to have a view in which every weakness can have only one
      parent.  This is very difficult to achieve in practice; we think
      that the concept of chains and composites helps to explain why
      this classification is so difficult.  We are making significant
      progress within the "natural hierarchy" (view 1000), but we
      will not have this finished by the release of CWE 1.0.

> Question2:About the classification of Dos( Denial of Service ).
> DoS is not classified in CWE.

DoS is not classified because it's a "consequence" of some weakness - just
like "loss of integrity" is a consequence.  In CWE 1.0, we will have
multiple ways of trying to determine which weaknesses can lead to a DoS:

   - a new OWASP Top Ten 2004 view has category A9, Denial of Service.

   - as a result of schema changes in 1.0, our Consequence element has
     been improved so that you will be able to search CWE for
     Consequence_Scope = Availability.


> How do you classify it when the cause of the DoS is not understood
>  in the vulnerability report?

This is a very difficult question, and I'm not sure how to handle it.  In
the case of databases of public vulnerabilities (like NVD), the databases
often don't have solid information about the underlying weaknesses that
led to the vulnerability.  Sometimes, the only vulnerability information
is something like "Product X can crash from a malformed packet" - you
might see this in a software vendor advisory, for example.

Since the "DoS" phrase alone doesn't talk about any specific weakness, CWE
is not currently capable of modeling it.

This is an example of a challenge: how should you map to CWE when you're
dealing with issues that aren't exactly weaknesses?  We hope to be able to
develop methods of handling these kinds of issues.  In fact, one of the
upcoming white papers will cover some of the common difficulties that
people will face when mapping to CWE.  In addition, sometime after the
release of CWE 1.0, we will try to improve the current NVD classifications
so that they are more suitable for handling incomplete vulnerability
information.  Hopefully we will be able to address this issue somehow.


- Steve

[Tadashi Yamagishi]

Dear Mr. Steven M. Christey,

I am very appreciate all your help.
I am looking forward to the CWE Version 1.0 release.

We(IPA) think that we will adopt CWE.
We would like to participate in the following CWE community initiative.
http://cwe.mitre.org/community/index.html

Could you add our organization to the CWE community initiative ?
Information-technology Promotion Agency, Japan (IPA)
http://www.ipa.go.jp/index-e.html

Thank you again for your explanation about questions.

Sincerely yours,
Tadashi Yamagishi
IT Security Center (ISEC)
Information-technology Promotion Agency, Japan (IPA)
E-mail: t-yamagi@...

Steven M. Christey wrote:

> On Mon, 25 Aug 2008, Tadashi Yamagishi wrote:
>
>> Question1:About Hierarchy diagram.
>> I made CWE-635(Weaknesses Used by NVD) a hierarchy diagram
>>  referring to cwe_classification_tree.pdf.
>> The hierarchy diagram is appended.
>> cwe_classification_tree.pdf shows the following.
>>  CWE-20 is a child of CWE-19.
>>  CWE-22 is a child of CWE-21.
>>  CWE-134 is a child of CWE-133.
>> However, CWE-1000(Natural Hierarchy) shows another parents.
>> I am confused. Are two or more parents permitted in CWE ?
>
> Yes.  This is for two reasons:
>
>   (1) there are multiple ways of looking at the same weakness, so we want
>       to support these different ways.  So, different views can express
>       different relationships.
>
>   (2) Some weaknesses can be fairly complex, so they can be classified in
>       different ways, even within the same view.  Ideally, it would be
>       good to have a view in which every weakness can have only one
>       parent.  This is very difficult to achieve in practice; we think
>       that the concept of chains and composites helps to explain why
>       this classification is so difficult.  We are making significant
>       progress within the "natural hierarchy" (view 1000), but we
>       will not have this finished by the release of CWE 1.0.
>
>> Question2:About the classification of Dos( Denial of Service ).
>> DoS is not classified in CWE.
>
> DoS is not classified because it's a "consequence" of some weakness - just
> like "loss of integrity" is a consequence.  In CWE 1.0, we will have
> multiple ways of trying to determine which weaknesses can lead to a DoS:
>
>    - a new OWASP Top Ten 2004 view has category A9, Denial of Service.
>
>    - as a result of schema changes in 1.0, our Consequence element has
>      been improved so that you will be able to search CWE for
>      Consequence_Scope = Availability.
>
>
>> How do you classify it when the cause of the DoS is not understood
>>  in the vulnerability report?
>
> This is a very difficult question, and I'm not sure how to handle it.  In
> the case of databases of public vulnerabilities (like NVD), the databases
> often don't have solid information about the underlying weaknesses that
> led to the vulnerability.  Sometimes, the only vulnerability information
> is something like "Product X can crash from a malformed packet" - you
> might see this in a software vendor advisory, for example.
>
> Since the "DoS" phrase alone doesn't talk about any specific weakness, CWE
> is not currently capable of modeling it.
>
> This is an example of a challenge: how should you map to CWE when you're
> dealing with issues that aren't exactly weaknesses?  We hope to be able to
> develop methods of handling these kinds of issues.  In fact, one of the
> upcoming white papers will cover some of the common difficulties that
> people will face when mapping to CWE.  In addition, sometime after the
> release of CWE 1.0, we will try to improve the current NVD classifications
> so that they are more suitable for handling incomplete vulnerability
> information.  Hopefully we will be able to address this issue somehow.
>
>
> - Steve
>