Re: [was] WAS Classification Thoughts

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 
  

  
To:  

  
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:  
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: 
For 
  additional commands, e-mail: