Re: [was] WAS Schema first draft forwarded from Andrew Jaquith

["Jeff Williams @ Aspect" <jeff.williams@aspectsecurity.com>]

I've reviewed the schema very closely, and I'm not convinced this is heading the right direction. Under the proposed schema, a vulnerability has 5 types of information:

 

Vulnerability

    - Attack Characteristics (group and subgroup -- e.g. access control and authorization)

    - Attack Surfaces (system boundary, component boundary, source code)

    - Target (application component, infrastructure component, end user)

    - Conditions (privilege, port)

    - Consequences (denial of service, privilege elevation, transfer of trust, identity impersonation, data disclosure, security requirements violation)

 

Many of these terms are not clear to me, nor am I convinced that every vulnerability will have information in all of these categories.  I also believe that many types of useful information have no place in the proposed schema.

 

I think our goal should be to create a language for communicating about web application vulnerabilities that is rich enough to express all the information we have about vulnerabilities, yet simple and clear enough for anyone to understand. In my last message, I proposed a schema that would look something like this:

 

Vulnerability

    - Basic Characteristics

    - Security Characteristics

    - Testing Characteristics

    - Exploit Characteristics

    - Remediation Characteristics

 

Each of those types of characteristics was detailed as follows:

 

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 TEST for 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 will help 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)

 

Thoughts?

 

-- Jeff

 

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

From: Mark Curphey

To: was@lists.oasis-open.org

Sent: Tuesday, August 26, 2003 3:57 PM

Subject: [was] WAS Schema first draft forwarded from Andrew Jaquith

All,

Attached below is an email and the first draft at the schema from Andrew Jaquith to deal with the classification / thesaurus. There is also a Java skunk works app using it. Andy is on the road this week and so unable to attend this weeks meeting. I am also unable to attend this weeks meeting so I am proposing we don't meet this week, have an additional meeting next week but still plough on over the email list. I know most people were waiting on this schema to get their teeth into things so I hope things will really get going now. Hint, hint ;-)

I am pretty conscious of time given that in order to maintain schedule we really need to produce the textual document within a few weeks. So we need to get into this and close out on the characteristics and groupings this week. I will then take the lead on creating the documentation version of the thesaurus that we will release and we can move onto the risk ranking and then the guts of the WAS format.

Andy you are a star!

Mark

<Andrew Jaquith>

Mark,

Here is the first cut at an XML schema for WAS. The schema is pretty
straightforward, and is taken directly from the Word doc you sent
previously, plus or minus one or two minor tweaks I've made.

I've enclosed the schema (src/schema) and a sample Java app
(SerializerTester) that creates a Vulnerability object, serializes it to
XML, and deserializes it back into an object graph. If you are wondering
why the file is so huge, it's because I enclosed all of the Java and
Javadocs.

If you want to run the Java app you will need a recent JDK (1.4.2 is
what I used) and the Java Web Services Developer Pack 1.2.

Everything pretty much flows from the schema, so we can modify it at
will & then re-generate the Java. I've enclosed an Ant build.xml file
that automates the build process.

 

---

---------------------------------------------------------------------
To unsubscribe, e-mail: was-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: was-help@lists.oasis-open.org