[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [was] Milestone check and suggestion
-----BEGIN PGP SIGNED MESSAGE-----
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:
We need to STOP WRITING E-MAILS and START WRITING SCHEMA.
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.
Andy
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:annotation>
<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:documentation>
<xsd:annotation>
<xsd:restriction base="xsd:string">
<xsd:enumeration value="access control"/>
<xsd:enumeration value="application configuration management"/>
...
</xsd:restriction>
</xsd:simpleType>
(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
USA
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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQE/VKfWiZurRomM9UYRAlY4AJ4o0RV16SDHGBRobdVF654Fz0NmWACgpt8U
Cd3HDXjwrhfBTrWvTDLe2IE=
=efNF
-----END PGP SIGNATURE-----
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]