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] Milestone check and suggestion

Hash: SHA1

I am neutral about which of Mark's Options (1 or 2) makes sense. The one 
thing I am NOT neutral on, though, is this:


Please, let's get past the abstract -- and into the concrete. We won't 
be able to drive out all of the modeling issues unless we start 
implementing ideas people have.

Jeff, I like much of what you suggest. Proposed revisions should be 
reflected in the schema, IMHO.


PS. XML schema can be daunting at first. I would strongly encourage that 
folks use the <xsd:documentation> element for inline comments. This 
makes the schema self-documenting. For example:

<xsd:simpleType name="ProfileGroupType">
     <xsd:documentation>Each vulnerability can be classified by a
        Profile Group. This denotes a high-level category
        for the vulnerability and answers the question, "what type
        of issue is this?"
   <xsd:restriction base="xsd:string">
     <xsd:enumeration value="access control"/>
     <xsd:enumeration value="application configuration management"/>

(This comment isn't in the XSD, but you get the idea...)

Mark Curphey wrote:
> After reading Jeff's mail below;
> I think what maybe happening here is that we delved into the world of 
> XML to help us create the classification scheme and it maybe confusing 
> some things. For a level set, this is where I think we are;
> 1. We want to create some common langauge and high level groupings from 
> which to describe issues at a high "human readable non-technical 
> manner". This was the classification scheme.
> 2. After some debate we decided as a group that strict classification 
> was futile but a thesaurus approach of terms grouped by similar 
> characteristics was valuable with standard textual language to support 
> it. Remember this is solely for the purpose of someone being able to 
> reference SQL injection as SQL Injection and not describe Database 
> sabotage as a brand new attack.
> 3. In order to help with our high level characteristic Andy created a 
> schema.
>  From what I can read from the message below I think this is all valid 
> conversation if we were discussing Part Three of our proposal but is 
> beyond scope for this Part One "classification" piece which should 
> really be *very* simple. Remember this is just to support the XML format 
> with some terminlogy that will help people in grouping, sorting and 
> searching for vulnerabilities that will ultimately be created with the 
> WAS format.
> Scenario -  a security researcher finds a new issue with an application 
> and wants to create a signature to test for the issue in his environment 
> and other peoples. He first goes to the WAS Thesaurus and from the 
> textual descriptions immediatly say that this is a SQL injection issue 
> and points to the reference description of SQL injection. He has 
> immediatly found common concise accurate language and does not need 
> to dream up the term "Database HTTP Introspection" which would confuse 
> everyone;-) This is the thing we are creating in this phase. He then 
> goes to the risk ranking model and is able to deduce that based on the 
> the model that this is a high risk vulnerability (not to pre-empt that 
> work). This is the peice we were going to create next. He then describes 
> the specific technical details of the vulnerability he discovered which 
> will likely include a combination of all the stuff you mention below.
> I think your Section 2 aligns with this section of work which is where I 
> think the dis-connect is. The rest is scope for the main body of work we 
> are doing (the real guts of WAS) but not this peice.
> I know there are a number of people on this list who have mailed me to 
> explain that thier silence is not a fucntion of their lack of interest 
> but that they are really interested in the XML Schema (ie the guts only).
> So based on that I have a proposal of two ways we can work moving 
> forward more effectively. If more people want Option 1we can revise the 
> schedule / agenda and do this and get cracking ASAP.
> Option 1
> I will personally run with completing the thesaurus and risk ranking 
> models over the next few weeks. This will allow the bulk of the group to 
> start work on the XML schema and get under the hood. We (I) can revise 
> the thesaurus work if needed as the XML portion of the project shapes out.
> If we do this I would suggest we invite Rogan Dawes to spend some time 
> on this Thursdays meeting walking through the existing VulnXML as a 
> starting point.
> Option 2
> All plough on for the next 6 weeks with the thesaurus and risk ranking 
> model as planned before tackling the XML.
> I am assuming most people want to get to the WAS format ASAP so I will 
> setup a vote for this to be completed before COB Tuesday.
> Seem sensible ?
>     ----- Original Message ----- 
>     *From:* Jeff Williams @ Aspect
>     <mailto:jeff.williams@aspectsecurity.com>
>     *To:* was@lists.oasis-open.org <mailto:was@lists.oasis-open.org>
>     *Sent:* Saturday, August 30, 2003 8:45 AM
>     *Subject:* 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 <mailto:mark@curphey.com>
>         *To:* was@lists.oasis-open.org <mailto: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
>         <mailto:was-unsubscribe@lists.oasis-open.org>
>         For additional commands, e-mail: was-help@lists.oasis-open.org
>         <mailto:was-help@lists.oasis-open.org>

- -- 
Andrew Jaquith
Program Director
@stake, Inc.
196 Broadway
Cambridge, MA 02139

Direct:  617.768.2711
Mobile:  617.501.3278
Fax:     617.621.1478
Email:   ajaquith@atstake.com
PGP key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x898CF546
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]