[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
|
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
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]