1.0 confusion

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

1.0 confusion

Chris Eng
Posting this to the list for further discussion.
 

-----Original Message-----
From: Steven M. Christey [mailto:[hidden email]]
Sent: Friday, September 12, 2008 11:52 AM
To: Chris Eng
Cc: Steven M. Christey; Robert A. Martin
Subject: Re: 1.0 confusion


Chris,

Would you mind posting this question to the research list?  Others will
probably run into similar questions.

> 1) Why does each Relationship node have a View_ID and a
> Relationship_Target?

A Relationship only exists within the context of a particular view.
This
technically begin in Draft 9 but wasn't necessarily that noticeable
until
1.0.

>  If I am trying to figure out who is the most applicable parent for a
> given node, how do I prioritize if there are multiple ChildOf
> Relationships?

1) You pick a view, X, through which you plan to navigate, then you pick
ChildOf in that view.

2) If there are multiple ChildOf in view X (i.e. where
Relationship_View_ID=X), then you pick the relationship with
ordinal=primary for that view.  There's only one primary allowed per
(relationship:view) tuple in each node.  If there's multiple
ordinals=primary, then each one is in a separate view.

The primary navigational views in CWE 1.0 are View 1000 (Research
Concepts) and view 699 (Development Concepts; the main CWE organization
before 1.0).  In general, deferring to view 1000 instead of 699 is more
likely to get you closely-related entries - however, that's based on
view-1000's perspective of the world.

Note that we only have relationships in a single direction in the XML.
We plan on publishing XML with bidirectional relationships, which should
minimize programming effort in some cases.

[Note to Bob and self: we should probably have a way of more cleanly
capturing only primary relationships for people who don't want to do
multi-parent navigation].

> 2) I am trying to figure out how to take the OWASP views and generate
a
> list of all the CWE nodes that belong to it, which we will then use
for
> our reporting.  I thought I could start with all the nodes that are
> listed explicitly as part of CWE 723, for example, and then add all
the
> descendants of those nodes. But when I do that, I end up missing some
> nodes, such as CWE 73 which should be part of OWASP A2-2004.

A very interesting problem that I don't have a fully-automated answer
for.

In general, you could use something we informally call "view-hopping,"
although there can be limitations.

Let's say you're following view 711, the 2004 OWASP Top Ten.  Once you
run
out of "711" child relationships to follow, you could then "hop" over to
view-1000 (natural hierarchy) relationships.

So navigating under view-711 from cwe-723, you'll reach a child CWE-330
(randomness).  This has no cildren under view-711, but if you "hop" to
relationships under view 1000, CWE-329 Not Using a Random IV with CBC
Mode
and many other variants starts to show up.

View-hopping probably makes the most sense under view-1000, since it is
focused on closely related weaknesses instead of arbitrary categories.

But there are limitations here, and the example you used, CWE-73, is one
of them.  You won't find it under view A2 (as you saw), and it's not a
descendant under view-1000 either, because the Research Concept view
doesn't treat CWE-73 as an instance of input validation.  However, you
do
reach CWE-20 through the 699 Development Concepts view.

  711 --> 722 (A1 - Unvalidated Input) [VIEW 711]

  722 has child 20 (Insufficient Input Validation)  [VIEW 711]

  20 has many children under VIEW 1000... but not 73

  20 also has children under VIEW 699... including 73

But since view 1000 and view 699 are organized so differently, I can see
how you'd wind up in trouble if you just navigated both of them
automatically.

If you're going the opposite direction, maybe you could try something
like:

  73

    view 1000: ChildOf CWE-610 (which is ChildOf 664, no OWASP cat's
               in the path)

    view 699: ChildOf CWE-20 [under 699]
              CWE-20 ChildOf CWE-722 [under 711]
              CWE-722 is A1-2004

So 73 is part of A1-2004.

I don't think there's a fully automated solution here, but if you
navigate
up view-1000 relationships *and* view-699 relationships, you're likely
to
find what you want.

> 3) You have CWE 79 (XSS) listed under OWASP A1-2004.  But XSS is
really
> an Output Validation problem, not Input Validation, plus it has its
own
> OWASP category dedicated to it, OWASP A4-2004.

This is because when I created 711, I made a literal mapping from what
the
OWASP document said to what CWEs were available.  I agree that XSS is
more
related to output than input (we say "sanitization" instead of
"validation" because things like encoding/escaping don't feel like
"validation").  However, the OWASP 2004 document specifically lists XSS
under its A1 category.

The ordinal=primary for XSS, though, is for the A4 XSS relationship.

Hope this all makes sense.

- Steve