OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

was message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: WAS Classification


Andrew et all,

I too like where this is heading but slower than I thought ;-)

A couple of comments before maybe we could start putting this down and creating some examples to see if they work out and refining things from there. We need to agree this week so we stay on schedule.

1. You describe vulnerabilities only. I am a firm beleiver that we should be able to describe positive security conditions as well as negative ones. Today scanning tehcnology focused on finding holes but as the industry matures I think and hope it will move to a compliance model.
2. You have outlined some "exploitability" and "impacts". These are in the next deliverable which the risk ranking model but good to see where it will fit in.

Now onto the taxonomy discussion. I am just not clear in my head how this would work. I think what I was proposing was that we would create attributes at the object level (ie allow objects to have a well defined interface) that would allow people to create taxonmies based on how they slice and dice the interface. The data is the same ie whats the difference between parameter manipulation id=me, id=you and input validation. If we create carefully chosen attribues for each vulnerability (ie allow a vulnerability to be tagged with descriptive attributes) we allow the end users to create many taxonomies that are more meaningful to themselves. An example maybe that at a high level a user would want to list all issues that could be exploited by users to escalate priviledges, or all vulnerabilities that we attack the user and not the system. Create a taxonomy of issues that are specific to intenationalisation issues.

The way I read what you describe in 3 is an instance of a vulnerability being realized under conditions ie an attack is a vulnerability condition which I think is what I was saying.

Would it be helpful if I start a glossary that we all agree on tonight ? 




Mark, Jeff and all --

I was on vacation last week, and so I'm thankful we didn't have a TC 
call. I like the direction this conversation is taking, and would like 
to consolidate and riff on it a bit.

Here goes:

VECTOR                 VULNERABILITY                    TARGET
====== 1            *  =============   1             *  ======
Name  --realized by--> Name         -----directed at--> Name
Class   instance of    ShortDescription \  *            Vendor
                        LongDescription   -------        Component
                        ExploitabilityRating    |        Version
                        ExploitabilityDesc      |
                        ImpactRating            |
                        ImpactDescription       |
                        Remediation             |
                        RelatedVulnerabilities  |
                        RelatedLibraryCalls     |     *
                        RelatedTools            --when-> CONDITION
                        DiscoveryMethod                  =========
                         |                               PrivilegeContext
                         |1            *
                         --exploited by--> ATTACK
                                           ======
                                           VulnXML goes here...

This is a cheap-and-cheerful ASCII art version of an object class 
diagram. If this comes across the wire mangled, I can do a quickie JPEG 
of it.

ABSTRACT: the Vector (an angle of attack made possible by the violation 
of a best practice or security requirement) enables a Vulnerability to 
be found. That Vulnerability can be directed at (exploited against) a 
Target under certain Conditions, using one or more specific Attack methods.

1. The VECTOR is essentially analagous to what we have been calling a 
"dictionary" (Jeff) or "taxonomy" (Mark). This is a primordial tree of 
web application security threats. Stealing half of (and expanding on) 
Mark's definition of vulnerability, a vector is "a [class of] flaw 
within a [type of] software system that can cause it to work contrary to 
its documented design." Vectors are specific to a type of software; for 
instance, thick client attack vectors are different for those associated 
with web applications.

Cardinality rules: a vector may be realized by one or more 
vulnerabilites; a vulnerability must realize one and only one vector.

Discussion:
I agree with Mark that the taxonomy classes should not be too granular 
because we want to be able to help vendors easily classify the 
vulnerabilities. I further agree that there may be more that one 
taxonomy -- but we should only create one for "web applications" -- 
i.e., not for thick clients or e-mail virii... at least not yet. 
Unsurprisingly, I happen to like the 8 high-level vectors I previously 
discussed with this group:
  Administrative interfaces
  Authentication and access control
  Configuration management
  Cryptographic algorithms
  Information gathering
  Input validation
  Parameter manipulation
  Sensitive data handling
  Session management

I have also heard vectors referred to as "threats" (diff from Mark's 
definition). I don't have a preference myself...

2. The VULNERABILITY is a method of exploit that could "cause the system 
to violate its intended security policy". The key word is COULD, because 
the vulnerability might not be successful if certain conditions are not 
met. The vulnerability includes a short (one-line) and long (extended) 
description of what it is, the method used to discover the vulnerability 
(scanner, manual inspection, etc.), and links to related vulnerabilities 
and tools. The vulnerability also includes ratings and descriptions for:
   a. The relative EXPLOITABILITY of the vulnerability (h/m/l), based on
      the availabilty of scripts, skill of attacker, etc. I'd prefer
      we use this over "likelihood", since likelihood implies a
      percentage chance and that's pretty much proxied by exploitability
      anyway.
   b. The relative IMPACT of the vulnerability if successfully exploited
      (h/m/l), based on what the exploit would enable an attacker to
      do. Getting root would be "high impact"

3. Not all vulnerabilities are created equally. To be successful, they 
must fulfil certain CONDITIONS -- does the attacker require local 
machine access? Do they need to be inside a protected perimeter, or is 
it remotely exploitable? (Question: is this something ADVL can help us 
with?) Cardinality rules: a vulnerability must fulfil at least one or 
more conditions; a condition may be fulfilled by one or more 
vulnerabilities.

4. ATTACK. This would contain detailed information on how an attack 
could be implemented. I would imagine that the VulnXML grammar would be 
the ideal way to express the description of the attack. Cardinality 
rules: a vulnerability may be exploited by one or more attacks; an 
attack must exploit one and only one vector.

An instance document for a vulnerability might look like this:

<vulnerability name="Microsoft SQL Server Named Pipes Exploit">
   <short-description>One sentence</shortDescription>
   <long-description>A paragraph</long-description>
   <discovery-method>Manual inspection</discovery-method>

   <!-- @refid='WAS-A-1' denotes Web App Sec threat taxonomy,
        category A, subcategory 1, which is "Buffer Overflow" -->
   <vector-class refid="WAS-A-1"/>

   <target name="Microsoft SQL Server">
     <vendor>Microsoft</vendor>
     <version>2000</version>
     <subversion>SP2</version>
     <component>Authentication subsystem</component>
   </target>

   <attack>
     ...VulnXML goes here?
   </attack>

   <exploitability rating="High">Lotsa kidz have scripts</exploitability>
   <impact rating="High">This is a total machine compromise</impact>

   <references>
     ...tools & CVE refs etc. go here...
   </references>

   <!-- This next bit is rather sketchy -->
   <condition>
     <name>ATTACK_LOCATION</name>
     <value>LOCAL</value>
   <condition>
     <name>PORT_NEEDED</name>
     <value>LPC</value>
   </condition>
   <condition>
     <name>ACCOUNT_NEEDED</name>
     <value>NORMAL_USER</value>
   </condition>

</vulnerability>

The vector taxonomy that the vulnerability instance document refers to 
could be pretty simple:

<vector-trees>
   <vector-tree name="Web Application Security" id="WAS">
     <vector-class name="Input Validation" id="WAS-A">
       <vector-class name="Buffer Overflow" id="WAS-A-1"/>
       ...
     </vector-class>
     ...
   </vector-tree>
</vector-trees>

On second thought, I'm not sure if "threat" isn't a better choice than 
"vector class". Hmm...

Feedback?

-- 
Andrew Jaquith
Program Director
@stake, Inc.
196 Broadway
Cambridge, MA 02139
USA

Direct:  617.768.2711
Mobile:  617.501.3278
Fax:     617.621.1478
Email:   ajaquith@atstake.com
PGP key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x898CF546


Jeff Williams @ Aspect wrote:
> Mark,
>  
> 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:
>  
> Vulnerability
>     Short Name
>     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
>     Remediation Description
>     Related Vulnerabilities
>     Related Library Calls
>     Related Tools
>     ... and much of the stuff from VulnXML
>  
> -- Jeff
>  
> 
>     ----- Original Message -----
>     *From:* Mark Curphey <mailto:mark@curphey.com>
>     *To:* was@lists.oasis-open.org <mailto:was@lists.oasis-open.org>
>     *Sent:* Friday, August 01, 2003 12:58 PM
>     *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 ideas....
> 
>     ----- Original Message -----
>     From: RCarlton@eteam.com <mailto:RCarlton@eteam.com>
>     To: Mark Curphey
>     Sent: Thursday, July 31, 2003 1:15 PM
>     Subject: Re: [was] Classification Thoughts
> 
> 
>     Hey Mark,
>      
>     I responded to your stream of consciousness with some thoughts of my
>     own below.
> 
>     R.A. Carlton
>     Vice President  - Strategic Technologies
>     Chairman EMIF - Sub Committee
>     949.433.4127 mobile
>     949.646.8853 land line
> 
> 
>     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.
>     Before opening or using any attachments, please scan them for
>     viruses and defects. We do
>     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 attachments.
> 
> 
> 
>     -----"Mark Curphey" wrote: -----
> 
>     To:
>     From: "Mark Curphey"
>     Date: 07/31/2003 08:37AM
>     Subject: [was] Classification Thoughts
> 
> 
>     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
>     classification scheme.
> 
>     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 pieces.
> 
>     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".
> 
>     In 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 policy.
> 
>      http://www.oisafety.org/process.html#_Toc42474363
> 
>      Threat is the probability of an instance of a vulnerability being
>     realized.
> 
>     Impact - is the consequence to the end system and / or its users.
> 
>     ...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 systems.
> 
>     ...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" break.
> 
>     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.
> 
>     How many 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
>     heierachies.
> 
>     I entirely agree with this thinking.
> 
>     Let me 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
> 
>     Needs payload
> 
>     Passes System Boundaries
> 
>     Can Escalate privileges
> 
>     Passes Trust
> 
>     ..as examples
> 
>     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 filtering.
> 
>     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.
> 
>     Any 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 the
>     room? :>)
> 
>     Rick
> 
>     ---------------------------------------------------------------------
>     To unsubscribe, e-mail: was-unsubscribe@lists.oasis-open.org
>     <mailto:was-unsubscribe@lists.oasis-open.org>
>     For additional commands, e-mail: was-help@lists.oasis-open.org
>     <mailto:was-help@lists.oasis-open.org>




---------------------------------------------------------------------
To unsubscribe, e-mail: was-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: was-help@lists.oasis-open.org



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]