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