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

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:  

  
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: 
For 
  additional commands, e-mail: