I agree with the approach you've laid out. Attempting to define bright and
clear lines would result in endless arguments. So documenting the metadata
associated with each vulnerability is a constructive way forward.
To make sure I understand, we'll still have to decide on the list of
vulnerabilities that we're going to document (the words in the dictionary),
right? I suspect that we'll end up with a list that essentially contains
most of the vulnerability categories that people frequently use in
discussion. I suggest that we have everyone in the group contribute a list
of the items they'd like to see defined by WAS.
I'd like to see the same format work for both "dictionary" entries and
specific instances of that vulnerability. Is it within the charter to
define both the general types of vulnerabilities and provide a format for
documenting specific flaws in specific apps? If so, the format should also
include details about the target application, how the flaw was found, where it
is located in the code, what attack causes it, etc...
Independent of the dictionary, we'll also have to define the attributes
themselves, right? I think you're using the word
'attributes' to mean the distinguishing features of the vulnerability,
yes? In addition to those attributes, I'd like to see the following things
documented for each item:
One Line Description
Conditions Resulting in this Vulnerability
Exploit Description -- how the exploit works, perhaps a
single URL, perhaps many steps
Likelihood of Exploit
Impact of Exploit
Location of Flaws -- in the code
Related Library Calls
... and much of the stuff from VulnXML
----- Original Message -----
Sent: Friday, August 01, 2003 12:58
Subject: [was] WAS Classification
Thoughts from Rick Carlton
As there has been little debate I am going to move to suggest
we adopt the scheme I proposed and start creating content. Lets close out on
Tuesday of next week and then move forward unless anyone has any other
----- Original Message -----
To: Mark Curphey
Sent: Thursday, July 31, 2003 1:15 PM
Subject: Re: [was] Classification
I responded to your stream of
consciousness with some thoughts of my own below.
President - Strategic Technologies
Chairman EMIF - Sub
PRIVILEGED - PRIVATE AND CONFIDENTIAL
This email and
any files transmitted with it are intended solely for the use of the
addressee(s) and may contain information which is confidential or privileged.
If you receive this email
and you are not the addressee (or responsible
for delivery of the email to the addressee),
please disregard the contents
of the email, delete the email and notify the author immediately.
opening or using any attachments, please scan them for viruses and defects. We
not accept any liability for loss or damage, which may arise from your
receipt of this e-mail. Our liability is limited to re-supplying any affected
-----"Mark Curphey" wrote: -----
From: "Mark Curphey"
Date: 07/31/2003 08:37AM
At the last meeting we all struggled to get
to grips with what a classification scheme actually is, the difference between
a classification scheme and a taxonomy; and with mental challenges around how
it would all fold up into a higher level message.
I thought I would
spend a few minutes and put down my thoughts and see if we can all agree on a
way to move forward.
I don't claim these to be the answers just my
thoughts in bits.
After the meeting I spent some time in dictionaries
and tried to understand if there is a difference between a dictionary and a
taxonomy and go back to basic of what we are trying to do with the
I view these two nouns as clearly different. At
the highest level a dictonary could be classified as a "taxonomy," I guess,
but only to the extent that it orders a larger collection of taxonomys. Sort
of like a candy box that contains a hundred individually wrapped
As you recall the aim of this part of the project was to create
a set of common descriptions for problems so we could avoid the issue of one
vendor called the same attack "Database Sabotage", another calling it "SQL
Injection" and another calling it "Direction Database Injection".
that respect the need for ordering of list elements was not a requirement but
I see (and agree) that an ordering system or at least the ability to order the
list would be very beneficial, especially for tools or researchers who are
looking for vulnerabilities that may be realized under specific conditions.
Problem here is that threats and their axes are purely subjective and
to large degree based on the specific operating and configuration
vulnerabilities of a particular system or network, or the turgid and active
intellect of the hacker community. Since, the permutations of how poorly
operators can potentially screw up perfectly good baseline systems appear
inifinite, I'd be careful trying to "order" elements in too granular a fashion
lest we find ourselves in situation where we think we've thought of everything
- and haven't. Maybe better to do a gross list of high level categories with
lots of wiggle room for ad hoc specifics, i.e. "Denial of Service etc.," under
which all the flavors could fall as necessary.
It helps me
to define a few terms and maybe we could all agree on a few terms as well
Vulnerability - a security vulnerability is a flaw within a
software system that can cause it to work contrary to its documented design
and could be exploited to cause the system to violate its intended security
is the probability of an instance of a vulnerability being
Impact - is the consequence to the end system and / or its
...and the wider interconnected community? "When a butterfly
flaps its wings in Africa it rains in New York?" Given the rapid emergence of
system to system integration it is entirely possible that a failure in Node 1
on one continent, could ultimately result in a spontaneous failure in Node 21
on another - for no apparent reason.
Attack - is an instance of a
vulnerability (or several vulnerabilities) being realized on a system or
...or not. Are all things "security" about attack? What about
configuration error, a poorly conformed user registry, or a public-switch
router table error? Columbia was lost because physical damage accruing to a
1.5 pound block of foam striking the leading edge of the wing was simply
underestimated. Seems to me that the most prudent approach to general
security is to define "bags" rather than a "boxes." "Bags" stretch "boxes"
This stays in line with the widely accepted basic risk model
that risk is a function of the number of vulnerabilities, the number of
threats and the business impact to the system and allows us to place
theoretical financial constraints on the basic model.
vulnerabilities can you fit on the head of a pin? That's always been my issue
with theoretical models, they're effective in a vacuum, but rarely appliciable
to the real world.
So if you buy this, you could extrapolate and
say any classification scheme would want to cater for the threat and also the
impact and ultimately attacks that leverage these components. Think the risk
ranking model may help here.
So, "YOU can lead a horse to water but
sometimes YOU have to shoot him in the head?" Again, it seems to me that one
will either have to subjectively apply general criteria or be forced to become
VERY granular. I don't see a middle-ground yet.
This leads me to
thinking that we should NOT get wrapped up in a well defined hierarchy, but
create an extensible scheme with attributes that would allow consumers to sort
and search for vulnerabilities based on defined criteria and create their own
I entirely agree with this thinking.
illustrate an example.
Cross Site Scripting
When looking for
cross site scripting issues, I would be more interested in knowing that the
impact is a transfer of trust, must be used in conjunction with a payload and
that it can occur at any data boundary to the system that processes structured
markup languages. This would lead me to start looking at XML data feeds,
process privileges of parsing components etc and ultimately may start me
thinking about how to build attacks specific to a system.
So what I am
advocating we do is to create the atomic components that can not be broken
down any more, document them and define a set of attributes such as
Passes System Boundaries
This is essentially
what we did at OWASP although we never built a hierarchical instances because
we never defined the criteria above.
An example of one hierarchy that
someone may wish to build from this may be to say, show me all attacks that
could escalate system privileges, or show me all attacks on the system and all
attacks on the user. Show me all attacks that leverage poor input
So I guess the question is what does everyone else think
about this ?
If its worth pursuing then I would suggest we define the
attributes and the atomic components next and see how things look.
thoughts ? Better ideas ?
I love working with engineers that take the
concept of logical modeling literally. This is good baseline thinking in my
view. Now, ya think you'll be able to herd all your cats into one corner of
unsubscribe, e-mail: email@example.com
additional commands, e-mail: firstname.lastname@example.org