Discussion point: CONSPEC - Context-specific Issues

[Sean Barnum]

Well, while I don't necessarily agree from a knowledge architecture perspective, we can definitely agree on the beer and the difficulty of discussing this kind of issue in depth through email. Verbal discussion of this kind of detailed issue can be much more effective.
Anytime you want to call a CWE brew forum, I will be there. :-)


sean

-----Original Message-----
From: Jarzombek, Joe [mailto:Joe.Jarzombek@...]
Sent: Wednesday, November 14, 2007 12:44 PM
To: Sean Barnum; Jarzombek, Joe; ldw
Cc: cwe-research-list@...
Subject: RE: some challenges for CWE -- "discernible" characteristics in descriptions

More generality in the unique CWE ID with a description that still
includes a "discernible" characteristic could still provide that
requisite granularity in the decomposition/details within the CWE ID.

For instance, if we specified the "discernible" characteristics for
patterns associated with integer coercion and path traversal, then each
characteristic could provide the basis for a unique CWE ID.  Of course,
the level of granularity for each meaningfully "discernible"
characteristic might be the basis for determining meaningful "views"
that need to be reflected in the details.

This is just thinking 'out loud' -- the subject would be better
discussed in an open (but small) group -- perhaps with a beer in hand.

v/r,

Joe

Joe Jarzombek, PMP
Director for Software Assurance
National Cyber Security Division
Office of Assistant Secretary
   for Cyber Security & Communications
Department of Homeland Security

e-mail:  Joe.Jarzombek@...
Cell Phone:  [phone]
Business Phone:  [phone]
Fax:  [phone]
http://www.us-cert.gov/swa/  "Build Security In"
https://buildsecurityin.us-cert.gov


-----Original Message-----
From: Sean Barnum [mailto:sbarnum@...]
Sent: Wednesday, November 14, 2007 12:19 PM
To: Jarzombek, Joe; ldw
Cc: cwe-research-list@...
Subject: RE: Patr Traversal and some challenges for CWE

Joe, I am not sure I understand what you are trying to say.
Are you arguing for more granularity or more generality?

sean

-----Original Message-----
From: Jarzombek, Joe [mailto:Joe.Jarzombek@...]
Sent: Wednesday, November 14, 2007 12:04 PM
To: Sean Barnum; ldw
Cc: cwe-research-list@...
Subject: RE: Patr Traversal and some challenges for CWE

These nuances should cause us to more effectively address naming
conventions with decomposition details that could offer the requisite
granularity as part of the description/examples of each CWE ID.

As such, I would rather see a smaller number of more generalized entries
for CWE descriptions.  How many unique CWE IDs are truly useful for
integer coercion and path traversal?  What would be wrong with the
desired granularity being in the details that could be structured to
enable unique "sub-IDs" within the CWE ID?

It would seem that keeping the granularity contained within details,
such that the descriptions reflected in further decomposition could me
more useful to a broader stakeholder community.

v/r,

Joe

Joe Jarzombek, PMP
Director for Software Assurance
National Cyber Security Division
Office of Assistant Secretary
   for Cyber Security & Communications
Department of Homeland Security


-----Original Message-----
From: owner-cwe-research-list@...
[mailto:owner-cwe-research-list@...] On Behalf Of Sean
Barnum
Sent: Wednesday, November 14, 2007 11:18 AM
To: ldw; cwe-research-list@...
Subject: RE: Patr Traversal and some challenges for CWE

One example of why this granularity is important is for people assessing
tools and developing tools.

For people assessing tools, it is a matter of precision. If several
variations of a weakness are generalized up into the description of a
higher level weakness, then there is no way to assert, measure or track
which of the variations the tool finds and how well. It becomes a binary
condition and the assessor would need to decide if a 'yes' on whether
that weakness was covered was determined by the fact that all variations
were covered or that even a single one in the list was covered. There
would be no in-between.

For people developing tools, it is a matter of configuration management.
Let's assume that at Time0, a given abstraction node lists 5 variations
in its description and a tool vendor has ensured they cover all of those
variations and thus can claim coverage of the CWE. If at Time1, 5 new
variations are determined to be appropriate and the description field is
simply modified to yield a list of 10, it becomes a more difficult thing
for the tool vendor and all users of the CWE to manage the configuration
issue than if each variation was a sub-node. Higher granularity of nodes
does not fully solve the configuration problem but makes it a lot
easier.

By keeping the granularity in the CWE but using views to only display
the desired granularity to each user, we serve the needs of the users
who need the higher granularity without putting undue clutter on those
who wish a more minimal set.
As I stated before, I don't believe we have any responsibility to make
sure that all possible variations are covered (the slippery slope) but
only the common (as in CWE) ones that people report they look for (tool
vendors and tool users).

Sean

________________________________________
From: owner-cwe-research-list@...
[owner-cwe-research-list@...] On Behalf Of ldw
[larry.wagoner@...]
Sent: Wednesday, November 14, 2007 9:50 AM
To: cwe-research-list@...
Subject: RE: Patr Traversal and some challenges for CWE

I would rather see a smaller number of more generalized entries.  The
path
traversal
is a good example of why additional entries should not be.  Absolute
path
traversal
and relative path traversal should be the limit to the granularity.
Details
can be part
of the description/examples of each.  If we did the same with integer
coercion as
has been done with path traversal , where would the entries end?

I'm not arguing against the granularity, but rather keeping the
granularity
contained
within the descriptions.  I agree with Sean that the granularity could
be
useful.
But I do not see a reason for a huge number of entries that will
ultimately
come
down to a splitting of hairs in many instances.


Sean Barnum wrote:
>
> Sure. I will argue for inclusion rather than exclusion.
> This does not mean that I would argue for a "complete" exposition or
> capture of all combinatorics, but fully believe than more granularity
and
> precision is better where it is applicable and makes sense.
> If specific variations/cases have been identified through practical
> experience by researchers, security analysts, tool vendors, and
others,
> then it makes sense to capture all of these as CWEs with appropriate
> abstraction relationships defined. To not keep this granularity where
it
> has already been identified is throwing away potentially useful
knowledge.
> I would argue that in many of these cases (but not necessarily all),
this
> more granular information is useful for tool vendors (or those
assessing
> tools) and for security analysts performing both automated and manual
> analysis of software. The potential solutions to things like path
> traversal can vary and while there are some solutions that should
solve
> the problem for most if not all variations, there are numerous
solutions
> that will only catch some of the variations and not others. Removing
this
> differential by abstracting them all up into one higher level node is
> doing the community a disservice.
>
> The solution to the problem is using views. With appropriate views, if
you
> don't want to see that level of granularity, you don't have to. If you
do,
> then you can. The full set of underlying information should be left
> unmolested unless absolutely necessary. The number of CWE IDs should
not
> be a concern. It is the utility and accessability of the information
for a

> variety of use cases that counts. Size and scope can be effectively
> managed with views.
>
> That is my 1 cent for now (I don't currently have time to throw two
> pennies in the ring).
>
> Sean Barnum
> Cigital, Inc.
>
> -----Original Message-----
> From: owner-cwe-research-list@...
> [mailto:owner-cwe-research-list@...] On Behalf Of Steven

M.
> Christey
> Sent: Monday, October 22, 2007 4:36 PM
> To: Jarzombek, Joe
> Cc: CWE-RESEARCH-LIST@...; Pascal Meunier
> Subject: RE: Patr Traversal and some challenges for CWE
>
> On Thu, 18 Oct 2007, Jarzombek, Joe wrote:
>
>> I, too, like the idea of avoiding a large number of CWE IDs that vary
on
>> a single, simple detail that could be easily abstracted and stored.
>
> Are there others on this list who either agree or disagree?  For those
who
> advocate a greater level of detail with more CWE IDs, what is the
use-case
> that makes this important for you?
>
>> Let's discuss the desired solution/selected implementation at our
>> upcoming Software Assurance Working Group session on Technology,
Tools
>> and Product Evaluation, 4 Dec in Arlington, VA.  Since CWE provides
the
>> foundation for our SwA Ecosystem, we would also provide a short
>> out-brief during the plenary session on 5 Dec.
>
> We will ensure that we capture the different proposals and relevant
> use-cases, and we will summarize the results of that meeting to this
list.
>
> My hope is that, with CWE's hierarchical layout and some
well-constructed
> views, we can come up with a representation that addresses everybody's
> needs.  An 'ecosystem view' might only go to a certain depth of the
tree,
> hiding some nodes that are too low-level for that particular view.
>
> For us to ensure that CWE can meet the diverse needs of the community,
we
> need to be sure that everybody on this list speaks up, publicly or
> privately, pro or con, even if it's a "me too" statement :)  I'm glad
for
> the responses we're getting, but even more would be better.
>
> Thanks all,
> Steve
>
>

--
View this message in context:
http://www.nabble.com/Discussion-point%3A-CONSPEC---Context-specific-Iss
ues-tf4470811.html#a13473503
Sent from the CWE Research List mailing list archive at Nabble.com.

[Pascal Meunier-3]

Ugh.  I think if we can't discuss it clearly in written form, the
verbalization will be awful.  The only advantage is that with beer, you
won't suffer from realizing how awful it is.

Can someone translate for me what Joe wrote?

Thanks,
Pascal

Sean Barnum wrote:

> Well, while I don't necessarily agree from a knowledge architecture perspective, we can definitely agree on the beer and the difficulty of discussing this kind of issue in depth through email. Verbal discussion of this kind of detailed issue can be much more effective.
> Anytime you want to call a CWE brew forum, I will be there. :-)
>
>
> sean
>
> -----Original Message-----
> From: Jarzombek, Joe [mailto:Joe.Jarzombek@...]
> Sent: Wednesday, November 14, 2007 12:44 PM
> To: Sean Barnum; Jarzombek, Joe; ldw
> Cc: cwe-research-list@...
> Subject: RE: some challenges for CWE -- "discernible" characteristics in descriptions
>
> More generality in the unique CWE ID with a description that still
> includes a "discernible" characteristic could still provide that
> requisite granularity in the decomposition/details within the CWE ID.
>
> For instance, if we specified the "discernible" characteristics for
> patterns associated with integer coercion and path traversal, then each
> characteristic could provide the basis for a unique CWE ID.  Of course,
> the level of granularity for each meaningfully "discernible"
> characteristic might be the basis for determining meaningful "views"
> that need to be reflected in the details.
>
> This is just thinking 'out loud' -- the subject would be better
> discussed in an open (but small) group -- perhaps with a beer in hand.
>
> v/r,
>
> Joe
>
> Joe Jarzombek, PMP
> Director for Software Assurance
> National Cyber Security Division
> Office of Assistant Secretary
>    for Cyber Security & Communications
> Department of Homeland Security
>
> e-mail:  Joe.Jarzombek@...
> Cell Phone:  [phone]
> Business Phone:  [phone]
> Fax:  [phone]
> http://www.us-cert.gov/swa/  "Build Security In"
> https://buildsecurityin.us-cert.gov
>
>
> -----Original Message-----
> From: Sean Barnum [mailto:sbarnum@...]
> Sent: Wednesday, November 14, 2007 12:19 PM
> To: Jarzombek, Joe; ldw
> Cc: cwe-research-list@...
> Subject: RE: Patr Traversal and some challenges for CWE
>
> Joe, I am not sure I understand what you are trying to say.
> Are you arguing for more granularity or more generality?
>
> sean
>
> -----Original Message-----
> From: Jarzombek, Joe [mailto:Joe.Jarzombek@...]
> Sent: Wednesday, November 14, 2007 12:04 PM
> To: Sean Barnum; ldw
> Cc: cwe-research-list@...
> Subject: RE: Patr Traversal and some challenges for CWE
>
> These nuances should cause us to more effectively address naming
> conventions with decomposition details that could offer the requisite
> granularity as part of the description/examples of each CWE ID.
>
> As such, I would rather see a smaller number of more generalized entries
> for CWE descriptions.  How many unique CWE IDs are truly useful for
> integer coercion and path traversal?  What would be wrong with the
> desired granularity being in the details that could be structured to
> enable unique "sub-IDs" within the CWE ID?
>
> It would seem that keeping the granularity contained within details,
> such that the descriptions reflected in further decomposition could me
> more useful to a broader stakeholder community.
>
> v/r,
>
> Joe
>
> Joe Jarzombek, PMP
> Director for Software Assurance
> National Cyber Security Division
> Office of Assistant Secretary
>    for Cyber Security & Communications
> Department of Homeland Security
>
>
> -----Original Message-----
> From: owner-cwe-research-list@...
> [mailto:owner-cwe-research-list@...] On Behalf Of Sean
> Barnum
> Sent: Wednesday, November 14, 2007 11:18 AM
> To: ldw; cwe-research-list@...
> Subject: RE: Patr Traversal and some challenges for CWE
>
> One example of why this granularity is important is for people assessing
> tools and developing tools.
>
> For people assessing tools, it is a matter of precision. If several
> variations of a weakness are generalized up into the description of a
> higher level weakness, then there is no way to assert, measure or track
> which of the variations the tool finds and how well. It becomes a binary
> condition and the assessor would need to decide if a 'yes' on whether
> that weakness was covered was determined by the fact that all variations
> were covered or that even a single one in the list was covered. There
> would be no in-between.
>
> For people developing tools, it is a matter of configuration management.
> Let's assume that at Time0, a given abstraction node lists 5 variations
> in its description and a tool vendor has ensured they cover all of those
> variations and thus can claim coverage of the CWE. If at Time1, 5 new
> variations are determined to be appropriate and the description field is
> simply modified to yield a list of 10, it becomes a more difficult thing
> for the tool vendor and all users of the CWE to manage the configuration
> issue than if each variation was a sub-node. Higher granularity of nodes
> does not fully solve the configuration problem but makes it a lot
> easier.
>
> By keeping the granularity in the CWE but using views to only display
> the desired granularity to each user, we serve the needs of the users
> who need the higher granularity without putting undue clutter on those
> who wish a more minimal set.
> As I stated before, I don't believe we have any responsibility to make
> sure that all possible variations are covered (the slippery slope) but
> only the common (as in CWE) ones that people report they look for (tool
> vendors and tool users).
>
> Sean
>
> ________________________________________
> From: owner-cwe-research-list@...
> [owner-cwe-research-list@...] On Behalf Of ldw
> [larry.wagoner@...]
> Sent: Wednesday, November 14, 2007 9:50 AM
> To: cwe-research-list@...
> Subject: RE: Patr Traversal and some challenges for CWE
>
> I would rather see a smaller number of more generalized entries.  The
> path
> traversal
> is a good example of why additional entries should not be.  Absolute
> path
> traversal
> and relative path traversal should be the limit to the granularity.
> Details
> can be part
> of the description/examples of each.  If we did the same with integer
> coercion as
> has been done with path traversal , where would the entries end?
>
> I'm not arguing against the granularity, but rather keeping the
> granularity
> contained
> within the descriptions.  I agree with Sean that the granularity could
> be
> useful.
> But I do not see a reason for a huge number of entries that will
> ultimately
> come
> down to a splitting of hairs in many instances.
>
>
> Sean Barnum wrote:
>> Sure. I will argue for inclusion rather than exclusion.
>> This does not mean that I would argue for a "complete" exposition or
>> capture of all combinatorics, but fully believe than more granularity
> and
>> precision is better where it is applicable and makes sense.
>> If specific variations/cases have been identified through practical
>> experience by researchers, security analysts, tool vendors, and
> others,
>> then it makes sense to capture all of these as CWEs with appropriate
>> abstraction relationships defined. To not keep this granularity where
> it
>> has already been identified is throwing away potentially useful
> knowledge.
>> I would argue that in many of these cases (but not necessarily all),
> this
>> more granular information is useful for tool vendors (or those
> assessing
>> tools) and for security analysts performing both automated and manual
>> analysis of software. The potential solutions to things like path
>> traversal can vary and while there are some solutions that should
> solve
>> the problem for most if not all variations, there are numerous
> solutions
>> that will only catch some of the variations and not others. Removing
> this
>> differential by abstracting them all up into one higher level node is
>> doing the community a disservice.
>>
>> The solution to the problem is using views. With appropriate views, if
> you
>> don't want to see that level of granularity, you don't have to. If you
> do,
>> then you can. The full set of underlying information should be left
>> unmolested unless absolutely necessary. The number of CWE IDs should
> not
>> be a concern. It is the utility and accessability of the information
> for a
>> variety of use cases that counts. Size and scope can be effectively
>> managed with views.
>>
>> That is my 1 cent for now (I don't currently have time to throw two
>> pennies in the ring).
>>
>> Sean Barnum
>> Cigital, Inc.
>>
>> -----Original Message-----
>> From: owner-cwe-research-list@...
>> [mailto:owner-cwe-research-list@...] On Behalf Of Steven
> M.
>> Christey
>> Sent: Monday, October 22, 2007 4:36 PM
>> To: Jarzombek, Joe
>> Cc: CWE-RESEARCH-LIST@...; Pascal Meunier
>> Subject: RE: Patr Traversal and some challenges for CWE
>>
>> On Thu, 18 Oct 2007, Jarzombek, Joe wrote:
>>
>>> I, too, like the idea of avoiding a large number of CWE IDs that vary
> on
>>> a single, simple detail that could be easily abstracted and stored.
>> Are there others on this list who either agree or disagree?  For those
> who
>> advocate a greater level of detail with more CWE IDs, what is the
> use-case
>> that makes this important for you?
>>
>>> Let's discuss the desired solution/selected implementation at our
>>> upcoming Software Assurance Working Group session on Technology,
> Tools
>>> and Product Evaluation, 4 Dec in Arlington, VA.  Since CWE provides
> the
>>> foundation for our SwA Ecosystem, we would also provide a short
>>> out-brief during the plenary session on 5 Dec.
>> We will ensure that we capture the different proposals and relevant
>> use-cases, and we will summarize the results of that meeting to this
> list.
>> My hope is that, with CWE's hierarchical layout and some
> well-constructed
>> views, we can come up with a representation that addresses everybody's
>> needs.  An 'ecosystem view' might only go to a certain depth of the
> tree,
>> hiding some nodes that are too low-level for that particular view.
>>
>> For us to ensure that CWE can meet the diverse needs of the community,
> we
>> need to be sure that everybody on this list speaks up, publicly or
>> privately, pro or con, even if it's a "me too" statement :)  I'm glad
> for
>> the responses we're getting, but even more would be better.
>>
>> Thanks all,
>> Steve
>>
>>
>
> --
> View this message in context:
> http://www.nabble.com/Discussion-point%3A-CONSPEC---Context-specific-Iss
> ues-tf4470811.html#a13473503
> Sent from the CWE Research List mailing list archive at Nabble.com.

[Steven M. Christey-2]

All,

It would be great to hear from some of the tool vendors here.


Sean Barnum wrote:

> One example of why this granularity is important is for people assessing
> tools and developing tools.
>
> For people assessing tools, it is a matter of precision. If several
> variations of a weakness are generalized up into the description of a
> higher level weakness, then there is no way to assert, measure or track
> which of the variations the tool finds and how well.

I think this is still feasible if the node is structured in a way that
allows someone to formally enumerate the possibilities, such as what
Pascal proposed here:

http://www.nabble.com/Discussion-point%3A-CONSPEC---Context-specific-Issues-tf4470811.html

It doesn't have to be exactly what Pascal proposed, but something that's
well-structured so that it can be handled automatically (i.e. not hidden
in freetext descriptions or context notes).

When a more precise evaluation is needed, the node is 'expanded' to cover
these other possibilities.

I do see your point about mapping precision, but I don't see how a
Pascal-style alternate proposal would fail to allow such precision.

> For people developing tools, it is a matter of configuration management.

It would be really nice for the tool developers to speak up here :)

Finally - as mentioned periodically, but perhaps not clearly enough, we
(MITRE) are starting to think that views can help take care of this.
This requires a more comprehensive effort to figure out the proper
representation; the draft 7 views are fairly primitive, but the idea is to
get people thinking in this direction.  Sean's comments on views are a
reflection of this emerging thought process.  This has some implications
for the schema, however, and we haven't pursued this aggressively at this
point.

There is another consideration, of course - the amount of labor required
to maintain CWE at a lower level of granularity.  This might be a place
where the community can more actively contribute content (which we hope to
make feasible at some point).

- Steve

[Chris Telfer]

I'd like to weigh in here.

There are usually a huge number of different ways for a programmer to
produce the same type of weakness.  We already acknowledge this in some
part through the notion of "complexities" that color a flaw (ala
SAMATE).  I believe that different ways to express the same weakness
(e.g. '/' vs '\\' as a path separator) are simply "complexities" for a
weakness that don't apply generally across all weakness types.

As an example of the danger, imagine the scenario:  You have tool A that
can cover a particular weakness, for example path traversal with '/', in
a myriad of contexts programming contexts.  However, tool A doesn't find
'\\' traversal problems.  Another tool, B, has covers all path traversal
issues but only covers them in the narrowest interpretation of each of
the weakness complexities and thus doesn't find nearly the breadth of
issues that will actually arise in code.  Breaking the CWEs down to
fine-grained weaknesses would give tool B an artificially high and
dubious evaluation rating.  Due to this, tool vendors will have more
incentive to build tools like B rather than A.

The CWE weaknesses, no matter how fine-grained, are still general
expressions for something that can occur in numerous ways.  Categorizing
  sub-variations of a weakness as different CWEs in order to help
evaluate coverage is probably a poor approach.  It seems to me that
measuring a tool's coverage of the same flaw in different programming
contexts is just as important (if not more so) as measuring a tool's
weakness variation coverage.  Using different, little, type-specific
variations to measure breadth can thus create a false illusion of
comprehensiveness.

Incidentally, I think that the ideal CWE compliance metric would grade
CWE compliance according to how _well_ a tool finds a flaw and not just
_whether_ it does or doesn't in some situations that we have test cases
for.  In this scenario we could then craft the scheme to evaluate not
only breadth of coverage in the context of general complexity types but
also in the context of weakness-specific variations.

In conclusion, I favor rolling up weakness variations into the same CWE.
  Evaluating coverage of a CWE should be separated from the definition
of "what defines this weakness" and will require much more thought.

Christopher Telfer, Ph.D.
Principal Security Engineer
Concurrent Technologies Corporation
Email: telferc@...
Phone: [phone]

** By the way, we still are no where near having good metrics or
benchmarks for weakness coverage of different complexities.  More and
different test cases won't do it.  In fact I'd argue that this probably
can't be done by benchmarks at all.  At CTC we've been attacking this
for the past 2 years and it is a LOT harder than just generating
different variations to test a tool.  Also, in general, we've found that
coverage benchmarks can easily favor tools with weaker analysis rather
than stronger analysis because such tools do not weed out false-positives.

Sean Barnum wrote:

> One example of why this granularity is important is for people assessing tools and developing tools.
>
> For people assessing tools, it is a matter of precision. If several variations of a weakness are generalized up into the description of a higher level weakness, then there is no way to assert, measure or track which of the variations the tool finds and how well. It becomes a binary condition and the assessor would need to decide if a 'yes' on whether that weakness was covered was determined by the fact that all variations were covered or that even a single one in the list was covered. There would be no in-between.
>
> For people developing tools, it is a matter of configuration management. Let's assume that at Time0, a given abstraction node lists 5 variations in its description and a tool vendor has ensured they cover all of those variations and thus can claim coverage of the CWE. If at Time1, 5 new variations are determined to be appropriate and the description field is simply modified to yield a list of 10, it becomes a more difficult thing for the tool vendor and all users of the CWE to manage the configuration issue than if each variation was a sub-node. Higher granularity of nodes does not fully solve the configuration problem but makes it a lot easier.
>
> By keeping the granularity in the CWE but using views to only display the desired granularity to each user, we serve the needs of the users who need the higher granularity without putting undue clutter on those who wish a more minimal set.
> As I stated before, I don't believe we have any responsibility to make sure that all possible variations are covered (the slippery slope) but only the common (as in CWE) ones that people report they look for (tool vendors and tool users).
>
> Sean
>
> ________________________________________
> From: owner-cwe-research-list@... [owner-cwe-research-list@...] On Behalf Of ldw [larry.wagoner@...]
> Sent: Wednesday, November 14, 2007 9:50 AM
> To: cwe-research-list@...
> Subject: RE: Patr Traversal and some challenges for CWE
>
> I would rather see a smaller number of more generalized entries.  The path
> traversal
> is a good example of why additional entries should not be.  Absolute path
> traversal
> and relative path traversal should be the limit to the granularity.  Details
> can be part
> of the description/examples of each.  If we did the same with integer
> coercion as
> has been done with path traversal , where would the entries end?
>
> I'm not arguing against the granularity, but rather keeping the granularity
> contained
> within the descriptions.  I agree with Sean that the granularity could be
> useful.
> But I do not see a reason for a huge number of entries that will ultimately
> come
> down to a splitting of hairs in many instances.
>
>
> Sean Barnum wrote:
>> Sure. I will argue for inclusion rather than exclusion.
>> This does not mean that I would argue for a "complete" exposition or
>> capture of all combinatorics, but fully believe than more granularity and
>> precision is better where it is applicable and makes sense.
>> If specific variations/cases have been identified through practical
>> experience by researchers, security analysts, tool vendors, and others,
>> then it makes sense to capture all of these as CWEs with appropriate
>> abstraction relationships defined. To not keep this granularity where it
>> has already been identified is throwing away potentially useful knowledge.
>> I would argue that in many of these cases (but not necessarily all), this
>> more granular information is useful for tool vendors (or those assessing
>> tools) and for security analysts performing both automated and manual
>> analysis of software. The potential solutions to things like path
>> traversal can vary and while there are some solutions that should solve
>> the problem for most if not all variations, there are numerous solutions
>> that will only catch some of the variations and not others. Removing this
>> differential by abstracting them all up into one higher level node is
>> doing the community a disservice.
>>
>> The solution to the problem is using views. With appropriate views, if you
>> don't want to see that level of granularity, you don't have to. If you do,
>> then you can. The full set of underlying information should be left
>> unmolested unless absolutely necessary. The number of CWE IDs should not
>> be a concern. It is the utility and accessability of the information for a
>> variety of use cases that counts. Size and scope can be effectively
>> managed with views.
>>
>> That is my 1 cent for now (I don't currently have time to throw two
>> pennies in the ring).
>>
>> Sean Barnum
>> Cigital, Inc.
>>
>> -----Original Message-----
>> From: owner-cwe-research-list@...
>> [mailto:owner-cwe-research-list@...] On Behalf Of Steven M.
>> Christey
>> Sent: Monday, October 22, 2007 4:36 PM
>> To: Jarzombek, Joe
>> Cc: CWE-RESEARCH-LIST@...; Pascal Meunier
>> Subject: RE: Patr Traversal and some challenges for CWE
>>
>> On Thu, 18 Oct 2007, Jarzombek, Joe wrote:
>>
>>> I, too, like the idea of avoiding a large number of CWE IDs that vary on
>>> a single, simple detail that could be easily abstracted and stored.
>> Are there others on this list who either agree or disagree?  For those who
>> advocate a greater level of detail with more CWE IDs, what is the use-case
>> that makes this important for you?
>>
>>> Let's discuss the desired solution/selected implementation at our
>>> upcoming Software Assurance Working Group session on Technology, Tools
>>> and Product Evaluation, 4 Dec in Arlington, VA.  Since CWE provides the
>>> foundation for our SwA Ecosystem, we would also provide a short
>>> out-brief during the plenary session on 5 Dec.
>> We will ensure that we capture the different proposals and relevant
>> use-cases, and we will summarize the results of that meeting to this list.
>>
>> My hope is that, with CWE's hierarchical layout and some well-constructed
>> views, we can come up with a representation that addresses everybody's
>> needs.  An 'ecosystem view' might only go to a certain depth of the tree,
>> hiding some nodes that are too low-level for that particular view.
>>
>> For us to ensure that CWE can meet the diverse needs of the community, we
>> need to be sure that everybody on this list speaks up, publicly or
>> privately, pro or con, even if it's a "me too" statement :)  I'm glad for
>> the responses we're getting, but even more would be better.
>>
>> Thanks all,
>> Steve
>>
>>
>
> --
> View this message in context: http://www.nabble.com/Discussion-point%3A-CONSPEC---Context-specific-Issues-tf4470811.html#a13473503
> Sent from the CWE Research List mailing list archive at Nabble.com.

------------------------------------------------------------
This message and any files transmitted within are intended
solely for the addressee or its representative and may
contain company sensitive information.  If you are not the
intended recipient, notify the sender immediately and delete
this message.  Publication, reproduction, forwarding, or
content disclosure is prohibited without the consent of the
original sender and may be unlawful.

Concurrent Technologies Corporation and its Affiliates.
www.ctc.com  1-800-282-4392
------------------------------------------------------------

[Jacob West]

I agree with the high-level idea in this thread that precision can both
be beneficial and detrimental. I think in most cases the granularity of
CWE nodes should be broader than it is currently, but that in no way
necessitates losing the additional information. A scheme designed around
top-level nodes that are broad (e.g. path traversal, integer coercion)
would make the taxonomy more accessible in a lot of ways. Then, the idea
of having an arbitrary number of sub/pseudo classifications for each of
those nodes stored more or less as meta data would make the additional
precision some people desire and some circumstances demand. In some ways
this differentiation between nodes and meta info isn't too meaningful,
but the significance is that encourages people who don't need the added
precision to base decisions on the broader categorization, which makes
errors of classification less likely (e.g. person A maps V1 to category
Foo and person B maps V1 to category Bar).

Cheers,

Jacob

-----Original Message-----
From: owner-cwe-research-list@...
[mailto:owner-cwe-research-list@...] On Behalf Of Steven M.
Christey
Sent: Wednesday, November 14, 2007 10:58 AM
To: Sean Barnum
Cc: ldw; cwe-research-list@...
Subject: RE: Patr Traversal and some challenges for CWE

All,

It would be great to hear from some of the tool vendors here.


Sean Barnum wrote:

> One example of why this granularity is important is for people
assessing
> tools and developing tools.
>
> For people assessing tools, it is a matter of precision. If several
> variations of a weakness are generalized up into the description of a
> higher level weakness, then there is no way to assert, measure or
track
> which of the variations the tool finds and how well.

I think this is still feasible if the node is structured in a way that
allows someone to formally enumerate the possibilities, such as what
Pascal proposed here:

http://www.nabble.com/Discussion-point%3A-CONSPEC---Context-specific-Iss
ues-tf4470811.html

It doesn't have to be exactly what Pascal proposed, but something that's
well-structured so that it can be handled automatically (i.e. not hidden
in freetext descriptions or context notes).

When a more precise evaluation is needed, the node is 'expanded' to
cover
these other possibilities.

I do see your point about mapping precision, but I don't see how a
Pascal-style alternate proposal would fail to allow such precision.

> For people developing tools, it is a matter of configuration
management.

It would be really nice for the tool developers to speak up here :)

Finally - as mentioned periodically, but perhaps not clearly enough, we
(MITRE) are starting to think that views can help take care of this.
This requires a more comprehensive effort to figure out the proper
representation; the draft 7 views are fairly primitive, but the idea is
to
get people thinking in this direction.  Sean's comments on views are a
reflection of this emerging thought process.  This has some implications
for the schema, however, and we haven't pursued this aggressively at
this
point.

There is another consideration, of course - the amount of labor required
to maintain CWE at a lower level of granularity.  This might be a place
where the community can more actively contribute content (which we hope
to
make feasible at some point).

- Steve

[Steven M. Christey-2]

On Wed, 14 Nov 2007, Chris Telfer wrote:

> There are usually a huge number of different ways for a programmer to
> produce the same type of weakness.  We already acknowledge this in some
> part through the notion of "complexities" that color a flaw (ala
> SAMATE).  I believe that different ways to express the same weakness
> (e.g. '/' vs '\\' as a path separator) are simply "complexities" for a
> weakness that don't apply generally across all weakness types.

Lately, Bob Martin and I have begun exploring certain concepts of "chains"
of weaknesses, as well as "composites" of properties whose combination
forms a weakness.

An increasingly-reported "chain" would be an integer overflow that causes
insufficient allocation of memory, which then leads to a buffer overflow.
A second chain involging integer overflow would lead to an infinite loop,
and could be independent of memory allocation altogether (we see examples
of this in CVE).

The "weakness that is better known by the attack term 'Symbolic Link
Following'" can be thought of as a composite in which one needs
predictability (of filenames), a race condition, path equivalence (where
two paths ultimately point to the same file object), and a shared
directory to exist all at once, in order to be present.  Removing any one
of these elements would prevent the issue or, at worst, significantly
reduce its scope.

Many of the CWE path traversal variants are probably reflections of
different chains and/or composites.  This gets closer to understanding the
variety of ways for programmers to cause the same problem.

Note: Bob and I are only in the early stages of developing these concepts.

> As an example of the danger, imagine the scenario:  You have tool A that
> can cover a particular weakness, for example path traversal with '/', in
> a myriad of contexts programming contexts.  However, tool A doesn't find
> '\\' traversal problems.  Another tool, B, has covers all path traversal
> issues but only covers them in the narrowest interpretation of each of
> the weakness complexities and thus doesn't find nearly the breadth of
> issues that will actually arise in code.  Breaking the CWEs down to
> fine-grained weaknesses would give tool B an artificially high and
> dubious evaluation rating.  Due to this, tool vendors will have more
> incentive to build tools like B rather than A.

I've been thinking lately that one way to handle this might be to define
one or more "tool evaluation" views that have a fairly fixed level of
abstraction and omit all nodes that are higher or lower levels.  If chosen
well, these views could provide more consistent evaluation ratings, at the
expense of precision.  This is just an early thought, however.

> Incidentally, I think that the ideal CWE compliance metric would grade
> CWE compliance according to how _well_ a tool finds a flaw and not just
> _whether_ it does or doesn't in some situations that we have test cases
> for.

I suspect the SAMATE project hopes to get to this point.

>   Evaluating coverage of a CWE should be separated from the definition
> of "what defines this weakness" and will require much more thought.

This is an intriguing proposal that might address a few separate problems
at once - or, at worst, put them in separate buckets.

- Steve

[ldw]

 
I think your chains have to be made at a consistent lower level.  For
instance, a buffer overflow is not a fundamental weakness, but a
combination of several weaknesses that together allow a system to be
comprimised.  This is an idea that has been around for quite a while
(see Matt Bishop's paper "Vulnerability Analysis"
(http://nob.cs.ucdavis.edu/bishop/papers/1999-raid/similar ) and has
been talked about lately in the Intro. to Vulnerability Theory paper.
That is, a buffer overflow, integer coercion, path traversal, etc. are
instantiations of a combination of weaknesses or primitive flaws.
Frequently if one of the underlying flaws are removed, then the weakness
(as currently in CWE) is no longer a vulnerability.  For example, if
some of the components of the buffer overflow weakness are eliminated
such as if one does not have unvalidated input, a language that doesn't
do bounds checking, and a system that allows return addresses to be
modified, then a buffer overflow cannot occur.  Therefore, the "real"
leaf nodes in CWE should be "allows unvalidated input" "language that
does not do array bounds checking" "return addresses can be modified"
(no doubt better names could be created).  Buffer overflow would be a
parent to these three nodes.  And tying this to the view strategy that
CWE wants to move to, then under a Java or Pascal view, the leaf node
"language that does not do array bounds checking" would not appear in
that view, but "allows unvalidated input" would.  Path traversal would
also be a parent of "allows unvalidated input."  Integer coercion would
be very interesting to reduce to its fundamental components -- such as
"allows data casting," "allows unsigned data," etc.

Those fundamental entries and the links to them would solve several
problems:
1. Would allow tools to make claims about the real weaknesses.
Languages or even hardware platforms could also make claims ("Wow, look
at how much of the CWE tree disappears when you use Acme")
2. Would make generation of views easier -- any node that is a parent to
"allows unsigned data" could be eliminated a Java view
3. Would reduce (likely not eliminate, unfortunately) the problem of one
tool calling it one weakness and another tool calling it another
weakness and both being argubly right -- this would put things at a more
fundamental level where things are, at the least, a little more
definitive
4. Would address the real problem at the lowest level possible
5. Would likely expose other weaknesses

Larry



<quote author="Steven M. Christey-2">
On Wed, 14 Nov 2007, Chris Telfer wrote:

> There are usually a huge number of different ways for a programmer to
> produce the same type of weakness.  We already acknowledge this in
some
> part through the notion of "complexities" that color a flaw (ala
> SAMATE).  I believe that different ways to express the same weakness
> (e.g. '/' vs '\\' as a path separator) are simply "complexities" for a
> weakness that don't apply generally across all weakness types.

Lately, Bob Martin and I have begun exploring certain concepts of
"chains"
of weaknesses, as well as "composites" of properties whose combination
forms a weakness.

An increasingly-reported "chain" would be an integer overflow that
causes
insufficient allocation of memory, which then leads to a buffer
overflow.
A second chain involging integer overflow would lead to an infinite
loop,
and could be independent of memory allocation altogether (we see
examples
of this in CVE).

The "weakness that is better known by the attack term 'Symbolic Link
Following'" can be thought of as a composite in which one needs
predictability (of filenames), a race condition, path equivalence (where
two paths ultimately point to the same file object), and a shared
directory to exist all at once, in order to be present.  Removing any
one
of these elements would prevent the issue or, at worst, significantly
reduce its scope.

Many of the CWE path traversal variants are probably reflections of
different chains and/or composites.  This gets closer to understanding
the
variety of ways for programmers to cause the same problem.

Note: Bob and I are only in the early stages of developing these
concepts.

- Steve

</quote>

[Matt Bishop-3]

Folks,

Minor correction to Larry's URL. The paper "Vulnerability Analysis" is  
available at the URL

http://nob.cs.ucdavis.edu/bishop/papers/1999-raid

and you can get PDF, PS, or (gasp!) HTML. The PDF is best :-)

We now return you to the current discussion ....

Matt

On Nov 15, 2007, at 6:48:55AM PST, Wagoner, Larry D. wrote:

>
> I think your chains have to be made at a consistent lower level.  For
> instance, a buffer overflow is not a fundamental weakness, but a
> combination of several weaknesses that together allow a system to be
> comprimised.  This is an idea that has been around for quite a while
> (see Matt Bishop's paper "Vulnerability Analysis"
> (http://nob.cs.ucdavis.edu/bishop/papers/1999-raid/similar ) and has
> been talked about lately in the Intro. to Vulnerability Theory paper.
> That is, a buffer overflow, integer coercion, path traversal, etc. are
> instantiations of a combination of weaknesses or primitive flaws.
> Frequently if one of the underlying flaws are removed, then the  
> weakness
> (as currently in CWE) is no longer a vulnerability.  For example, if
> some of the components of the buffer overflow weakness are eliminated
> such as if one does not have unvalidated input, a language that  
> doesn't
> do bounds checking, and a system that allows return addresses to be
> modified, then a buffer overflow cannot occur.  Therefore, the "real"
> leaf nodes in CWE should be "allows unvalidated input" "language that
> does not do array bounds checking" "return addresses can be modified"
> (no doubt better names could be created).  Buffer overflow would be a
> parent to these three nodes.  And tying this to the view strategy that
> CWE wants to move to, then under a Java or Pascal view, the leaf node
> "language that does not do array bounds checking" would not appear in
> that view, but "allows unvalidated input" would.  Path traversal would
> also be a parent of "allows unvalidated input."  Integer coercion  
> would
> be very interesting to reduce to its fundamental components -- such as
> "allows data casting," "allows unsigned data," etc.
>
> Those fundamental entries and the links to them would solve several
> problems:
> 1. Would allow tools to make claims about the real weaknesses.
> Languages or even hardware platforms could also make claims ("Wow,  
> look
> at how much of the CWE tree disappears when you use Acme")
> 2. Would make generation of views easier -- any node that is a  
> parent to
> "allows unsigned data" could be eliminated a Java view
> 3. Would reduce (likely not eliminate, unfortunately) the problem of  
> one
> tool calling it one weakness and another tool calling it another
> weakness and both being argubly right -- this would put things at a  
> more
> fundamental level where things are, at the least, a little more
> definitive
> 4. Would address the real problem at the lowest level possible
> 5. Would likely expose other weaknesses
>
> Larry
>
>
>
> <quote author="Steven M. Christey-2">
> On Wed, 14 Nov 2007, Chris Telfer wrote:
>
>> There are usually a huge number of different ways for a programmer to
>> produce the same type of weakness.  We already acknowledge this in
> some
>> part through the notion of "complexities" that color a flaw (ala
>> SAMATE).  I believe that different ways to express the same weakness
>> (e.g. '/' vs '\\' as a path separator) are simply "complexities"  
>> for a
>> weakness that don't apply generally across all weakness types.
>
> Lately, Bob Martin and I have begun exploring certain concepts of
> "chains"
> of weaknesses, as well as "composites" of properties whose combination
> forms a weakness.
>
> An increasingly-reported "chain" would be an integer overflow that
> causes
> insufficient allocation of memory, which then leads to a buffer
> overflow.
> A second chain involging integer overflow would lead to an infinite
> loop,
> and could be independent of memory allocation altogether (we see
> examples
> of this in CVE).
>
> The "weakness that is better known by the attack term 'Symbolic Link
> Following'" can be thought of as a composite in which one needs
> predictability (of filenames), a race condition, path equivalence  
> (where
> two paths ultimately point to the same file object), and a shared
> directory to exist all at once, in order to be present.  Removing any
> one
> of these elements would prevent the issue or, at worst, significantly
> reduce its scope.
>
> Many of the CWE path traversal variants are probably reflections of
> different chains and/or composites.  This gets closer to understanding
> the
> variety of ways for programmers to cause the same problem.
>
> Note: Bob and I are only in the early stages of developing these
> concepts.
>
> - Steve
>
> </quote>

[Dave McKinney]

On Thu, Nov 15, 2007 at 09:48:55AM -0500, Wagoner, Larry D. wrote:

>  
> I think your chains have to be made at a consistent lower level.  For
> instance, a buffer overflow is not a fundamental weakness, but a
> combination of several weaknesses that together allow a system to be
> comprimised.  This is an idea that has been around for quite a while
> (see Matt Bishop's paper "Vulnerability Analysis"
> (http://nob.cs.ucdavis.edu/bishop/papers/1999-raid/similar ) and has
> been talked about lately in the Intro. to Vulnerability Theory paper.
> That is, a buffer overflow, integer coercion, path traversal, etc. are
> instantiations of a combination of weaknesses or primitive flaws.
> Frequently if one of the underlying flaws are removed, then the weakness
> (as currently in CWE) is no longer a vulnerability.  For example, if
> some of the components of the buffer overflow weakness are eliminated
> such as if one does not have unvalidated input, a language that doesn't
> do bounds checking, and a system that allows return addresses to be
> modified, then a buffer overflow cannot occur.  Therefore, the "real"
> leaf nodes in CWE should be "allows unvalidated input" "language that
> does not do array bounds checking" "return addresses can be modified"
> (no doubt better names could be created).  Buffer overflow would be a
> parent to these three nodes.  And tying this to the view strategy that
> CWE wants to move to, then under a Java or Pascal view, the leaf node
> "language that does not do array bounds checking" would not appear in
> that view, but "allows unvalidated input" would.  Path traversal would
> also be a parent of "allows unvalidated input."  Integer coercion would
> be very interesting to reduce to its fundamental components -- such as
> "allows data casting," "allows unsigned data," etc.

While I think there is a real need for a more academically rigorous approach
to creating a vulnerability taxonomy, I think the current level of
abstraction used by the CWE is adequate for the audience and its
intended users. For example, describing something as a cross-site
scripting vulnerability or a sub-set of XSS is probably the right
level for tool vendors, security researchers, software vendors,
non-technical managers, the media, etc.

We can understand and agree that a vulnerability can be broken down
further into primitives that must exist in tandem for
the vulnerability to occur. However, my fear is that this may
needlessly complicate the description and classification of simple vulnerabilities.

I am also concerned of the possibility of arriving at a system where many
of the classifications are not actually security weaknesses in and of
themselves, which may make many of the entries irrelevant for
practically classifying vulnerabilities. Like for example, you have a
vulnerability that occurs because of one legit security weakness
combined with nine other environmental or programming
language-specific entries which are not weaknesses in and of
themselves. I am also concerned about overlap with other SCAP related
standards if the CWE is addressing a lot of configuration or
environmental factors that cause a vulnerability to exist in one
installation where it wouldn't exist in another.

My understanding of what Steve was suggesting in terms of combining
vulnerabilities is that there will be some cases where the system will
need to be robust enough to describe vulnerabilities that exist only
where certain weaknesses are combined in tandem.  There are also some
conditions that are best described in terms of interactions, like an
integer handling issue that lets the attacker influence a memory copy operation
further down the execution chain in a way that the developer did not
intend. It may be useful to describe this in terms of multiple
weaknesses working in tandem.

--
Dave McKinney
Symantec

keyID: E461AE4E
key fingerprint = F1FC 9073 09FA F0C7 500D  D7EB E985 FAF3 E461 AE4E

[Chris Wysopal-2]

 

Wagoner, Larry wrote:

>Therefore, the "real" leaf nodes in CWE should be "allows unvalidated
input"
>"language that does not do array bounds checking" "return addresses can
be modified"


You can get even more precise than this.  "Allows unvalidated input"
could be "allows unvalidated input by input size" or many other flavors
of input validation that all protect against different weaknesses in the
code.  The "return address can be modified" is really just one of many
ways a buffer overflow can be exploited at a higher severity than just
overwriting data. "function pointers can be modified" or "heap
structures can be modified" are other ways. I like this level of
precision because it helps language and platform designers understand
precisely what the mechanisms of insecure software are.

In a subsequent post Dave McKinney made an argument against lower levels
of classification because it would go lower level than needed by the
people who need to understand and manage fixing vulnerable code. This
seems to me a split akin to atoms and sub-atomic particles.  One has
chemical properties and can exist as a molecule or be combined with
other atoms to make bigger molecules.  Chemists work at this level.
Physicists try to understand the way the universe works at a lower level
and work with things that really don't exist in the "real world".  We
just need to figure out where the split is.  Something like chemists
(sofware developers)use CWE and physcists (language and platform
designers) use X.

-Chris



-----Original Message-----
From: owner-cwe-research-list@...
[mailto:owner-cwe-research-list@...] On Behalf Of Wagoner,
Larry D.
Sent: Thursday, November 15, 2007 9:49 AM
To: cwe-research-list@...
Cc: Matt Bishop; Jarzombek, Joe
Subject: RE: Patr Traversal and some challenges for CWE

 
I think your chains have to be made at a consistent lower level.  For
instance, a buffer overflow is not a fundamental weakness, but a
combination of several weaknesses that together allow a system to be
comprimised.  This is an idea that has been around for quite a while
(see Matt Bishop's paper "Vulnerability Analysis"
(http://nob.cs.ucdavis.edu/bishop/papers/1999-raid/similar ) and has
been talked about lately in the Intro. to Vulnerability Theory paper.
That is, a buffer overflow, integer coercion, path traversal, etc. are
instantiations of a combination of weaknesses or primitive flaws.
Frequently if one of the underlying flaws are removed, then the weakness
(as currently in CWE) is no longer a vulnerability.  For example, if
some of the components of the buffer overflow weakness are eliminated
such as if one does not have unvalidated input, a language that doesn't
do bounds checking, and a system that allows return addresses to be
modified, then a buffer overflow cannot occur.  Therefore, the "real"
leaf nodes in CWE should be "allows unvalidated input" "language that
does not do array bounds checking" "return addresses can be modified"
(no doubt better names could be created).  Buffer overflow would be a
parent to these three nodes.  And tying this to the view strategy that
CWE wants to move to, then under a Java or Pascal view, the leaf node
"language that does not do array bounds checking" would not appear in
that view, but "allows unvalidated input" would.  Path traversal would
also be a parent of "allows unvalidated input."  Integer coercion would
be very interesting to reduce to its fundamental components -- such as
"allows data casting," "allows unsigned data," etc.

Those fundamental entries and the links to them would solve several
problems:
1. Would allow tools to make claims about the real weaknesses.
Languages or even hardware platforms could also make claims ("Wow, look
at how much of the CWE tree disappears when you use Acme") 2. Would make
generation of views easier -- any node that is a parent to "allows
unsigned data" could be eliminated a Java view 3. Would reduce (likely
not eliminate, unfortunately) the problem of one tool calling it one
weakness and another tool calling it another weakness and both being
argubly right -- this would put things at a more fundamental level where
things are, at the least, a little more definitive 4. Would address the
real problem at the lowest level possible 5. Would likely expose other
weaknesses

Larry



<quote author="Steven M. Christey-2">
On Wed, 14 Nov 2007, Chris Telfer wrote:

> There are usually a huge number of different ways for a programmer to
> produce the same type of weakness.  We already acknowledge this in
some
> part through the notion of "complexities" that color a flaw (ala
> SAMATE).  I believe that different ways to express the same weakness
> (e.g. '/' vs '\\' as a path separator) are simply "complexities" for a

> weakness that don't apply generally across all weakness types.

Lately, Bob Martin and I have begun exploring certain concepts of
"chains"
of weaknesses, as well as "composites" of properties whose combination
forms a weakness.

An increasingly-reported "chain" would be an integer overflow that
causes insufficient allocation of memory, which then leads to a buffer
overflow.
A second chain involging integer overflow would lead to an infinite
loop, and could be independent of memory allocation altogether (we see
examples of this in CVE).

The "weakness that is better known by the attack term 'Symbolic Link
Following'" can be thought of as a composite in which one needs
predictability (of filenames), a race condition, path equivalence (where
two paths ultimately point to the same file object), and a shared
directory to exist all at once, in order to be present.  Removing any
one of these elements would prevent the issue or, at worst,
significantly reduce its scope.

Many of the CWE path traversal variants are probably reflections of
different chains and/or composites.  This gets closer to understanding
the variety of ways for programmers to cause the same problem.

Note: Bob and I are only in the early stages of developing these
concepts.

- Steve

</quote>