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: Re: [was] Interesting papers about vulnerability classification and a possible proposal to move forward

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 -----
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



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;

            Modify Existing Requests
            New Requests

Attack Surface
            System Boundary
            Component Boundary
            Source Code

            Application Component
            Infrastructure Component

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

The groups maybe ;

Logic Conditions

Boundary Validation


            Modified Existing Requests

                        SQL Injection

LDAP Injection

OS Command Injection

Script Injection

            HTML Injection

                        XSS to call JS



            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



Data Protection


            Transport Security

Buffer Overflows

            Heap Overflow

            Stack Overflow

            Format String

Race Conditions

What do people think of this idea ?

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]