[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]