Re: [was] Interesting papers about vulnerability classification and a possible proposal to move forward

Mark,

 

Thanks for those links. I'm attaching a paper from Gonzalo Alvarez (http://www.iec.csic.es/~gonzalo/) 
posted to webappsec a few months ago. I believe he's applied Blaze's "Thesaurus" 
approach to the WAS problem. For those that haven't read the papers, allow 
me to summarize the approach.

 

BLAZE SUMMARY: Vulnerabilities are overlapping, vague, at different levels 
of abstraction, and sometimes only partially understood. So any strict 
categorization scheme is doomed to fail.  Blaze proposes that 
a "thesaurus" of characteristics can solve this problem.  Essentially, 
each vulnerability is tagged with the appropriate characteristics from the 
thesaurus. This makes it easy for security folks to search for existing and 
related vulnerabilities.

 

So, our first step is to select the initial set of characteristics that we 
will tag vulnerabilities with (i.e. build the thesaurus). I've tried to do 
this systematically, so that we have a way of telling whether a proposed 
characteristic is "good" or not.  I'm also hoping to spur more 
discussion about what the list ought to contain. As Blaze puts it -- "a 
vulnerability is a characterization of a vulnerable state" -- meaning that a 
vulnerability simply IS the list of characteristics that uniquely identifies 
it.

 

So I've set out a few different types of characteristics below. This 
is a top-down effort to try to be complete about the characteristics that 
are important:

  1 - basic characteristics of the vulnerability

  2 - security characteristics of the vulnerability

  3 - characteristics related to finding the vulnerability

  4 - characteristics related to exploiting the vulnerability

  5 - characteristics related to remedying the vulnerability

 

1 - Basic characteristics -- obvious, concrete characteristics are the best 
for unique identification and searching purposes. Some examples (nowhere 
near a complete list) I think would be useful to have documented for each 
vulnerability are:

    - The name, version of the targeted 
application

    - Platform info(servers, 
versions)
    - HTTP info(method, headers, cookies, domain, 
response code)

    - Parameter info (form name, field name, URL, 
querystring)

    - Code (language, method name, line number, error 
message)

    - Other common identifiers (filenames)

 

2 - Security characteristics -- these will "map" vulnerabilities 
into a security space. Not as important for unique identification, but very 
useful for risk analysis and understanding. By the way, I think using 
characteristics is a cleaner way to handle the idea of 'groups':

    - Security area (confidentiality, integrity, 
availability, accountability, privacy)

    - Vulnerability category (Top Ten, Mark's list below, 
others -- this is where the thesaurus idea is best for aliases)

    - Related security mechanisms (authentication, 
authorization, encryption, filtering, logging, etc...)
    - 
Likelihood of exploit (tools, difficulty)

    - Consequence (defacement, disclosure, corruption, 
denial of service)

 

3 - Characteristics related to how to FIND the vulnerability --  these 
are a step away from characteristics of the vulnerability, but I think could be 
included in this model without too much difficulty. Note that these won't help 
much at all with unique identification, but target the user who wants to know if 
they're susceptible.

    - Finding in running application (proxy mitm, scanning, 
tools to use)

    - Finding in code (search strings, patterns to look for, 
tools to use)

 

4 - Characteristics related to how to EXPLOIT the vulnerability -- as 
discussed on the list, I don't think we should try to put specific exploit 
recipes in XML -- it's too hard. This is for a brief text description of how to 
exploit.  Specific exploits are best represented in NASL, or libwhisker 
perl, or something.

    - Specific tools to use

    - Methodology or process

 

5 - Characteristics related to how to REMEDY the vulnerability -- I think 
these will be extremely useful if you want to find out if you've got a 
vulnerability, and if you do, to determine how to fix it. 

    - Approaches (fix code, block requests, filter, apply 
patch, start over)

    - Forensics (how to search logs, other evidence of 
exploit)

 

I don't think there's a need to get EVERY possible characteristic 
identified up front. I'd much rather have a smaller list of characteristics that 
we're pretty sure of.  Also, I know there's some pressure to get something 
out the door, but I think we all really need to get behind this approach if it's 
going to succeed.

 

I'm looking forward to your thoughts.

 

--

Jeff 

 

  
----- Original Message ----- 

  
From: 
  Mark Curphey 
  

  
To:  

  
Sent: Friday, August 08, 2003 10:57 
  PM

  
Subject: [was] Interesting papers about 
  vulnerability classification and a possible proposal to move forward

  

As I am still trying to get my head around this classification 
  problem we
are working through and I started searching the web for 
  abstracts about
other projects for experience of how others have dealt with 
  it. There are
some wise thoughts from Matt Bishop in the following two 
  papers

http://downloads.securityfocus.com/library/1996-nissc-vn.pdf

http://seclab.cs.ucdavis.edu/secsem2/09-01-99-Matt/matt.ppt

I 
  am leaning (tonight) to thinking the approach suggested in both 
  of
essentially decomposing vulnerabilities into characteristics and 
  organizing
them into a thesaurus that can be used for classifiying issues 
  seems to
resonate with what we are trying to do and would work the best. 
  Essentially
we would group vulnerabilities with "like" characteristics. 
  The
characteristics could be used to create classification 
  schemes.

Essentially this is not a million miles from the original 
  OWASP ASAC.

Characteristics 
  Maybe;

Techniques
            
  Modify Existing 
  Requests
            
  New Requests

Attack 
  Surface
            
  System 
  Boundary
            
  Component 
  Boundary
            
  Source 
  Code

Target
            
  Application 
  Component
            
  Infrastructure 
  Component
            
  User

Consequences
            
  Denial of 
  Service
            
  Elevated 
  Privileges
            
  Transfer of 
  Trust
            
  Spoofed 
  Identity
            
  Revelation of Additional 
  Data
            
  Security Requirements Fail

The groups maybe ;

Logic 
  Conditions

Boundary 
  Validation

            
  Canonicalization

            
  Modified Existing 
  Requests

                        
  SQL Injection

LDAP Injection

OS Command Injection

Script 
  Injection

            
  HTML 
  Injection

                        
  XSS to call 
  JS

            
  JavaScript

                        
  XSS

            
  ASP 
  Scripts

            
  PHP Scripts

Addition to Existing Requests

Directory 
  TRaversal

New Requests

Infrastructure 
  Configuration 
  Management

            
  Insecure Default 
  Configurations

            
  Security 
  Patches

            
  Exposed Administration Interfaces

User 
  Privacy

Session 
  Management

            
  Session 
  Timeout

            
  Session Hi-Jacking

Access 
  Control

Authentication

Authorization

Data 
  Protection

            
  Cryptography

            
  Transport Security

Buffer 
  Overflows

            
  Heap 
  Overflow

            
  Stack 
  Overflow

            
  Format String

Race Conditions

What do people 
  think of this idea 
  ?

---------------------------------------------------------------------
To 
  unsubscribe, e-mail: 
For 
  additional commands, e-mail: 

taxonomy.cs.02.pdf