[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [no subject]
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.=20 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.=20 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).=20 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 ----- =20 From: Jeff Williams @ Aspect=20 To: was@lists.oasis-open.org=20 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.=20 - Approaches (fix code, block requests, filter, apply patch, start = over) - Forensics (how to search logs, other evidence of exploit) Thoughts? -- Jeff=20 ----- Original Message -----=20 From: Mark Curphey=20 To: was@lists.oasis-open.org=20 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=20 previously, plus or minus one or two minor tweaks I've made. I've enclosed the schema (src/schema) and a sample Java app=20 (SerializerTester) that creates a Vulnerability object, serializes = it to=20 XML, and deserializes it back into an object graph. If you are = wondering=20 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=20 that automates the build process. =20 -------------------------------------------------------------------------= --- = --------------------------------------------------------------------- To unsubscribe, e-mail: was-unsubscribe@lists.oasis-open.org For additional commands, e-mail: was-help@lists.oasis-open.org ------=_NextPart_000_01C9_01C36EDF.C29A4B80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META http-equiv=3DContent-Type content=3D"text/html; = charset=3Diso-8859-1"> <META content=3D"MSHTML 6.00.2800.1226" name=3DGENERATOR> <STYLE></STYLE> </HEAD> <BODY bgColor=3D#ffffff> <DIV>After reading Jeff's mail below;</DIV> <DIV> </DIV> <DIV>I think what maybe happening here is that we delved into the world = of XML=20 to help us create the classification scheme and it maybe confusing some = things.=20 For a level set, this is where I think we are;</DIV> <DIV> </DIV> <DIV>1. We want to create some common langauge and high level groupings = from=20 which to describe issues at a high "human readable non-technical = manner". This=20 was the classification scheme.</DIV> <DIV>2. After some debate we decided as a group that strict = classification was=20 futile but a thesaurus approach of terms grouped by similar = characteristics was=20 valuable with standard textual language to support it. Remember this is = solely=20 for the purpose of someone being able to reference SQL injection as SQL=20 Injection and not describe Database sabotage as a brand new = attack.</DIV> <DIV>3. In order to help with our high level characteristic Andy created = a=20 schema.</DIV> <DIV> </DIV> <DIV>From what I can read from the message below I think this is all = valid=20 conversation if we were discussing Part Three of our proposal but is = beyond=20 scope for this Part One "classification" piece which should really be = *very*=20 simple. Remember this is just to support the XML format with some = terminlogy=20 that will help people in grouping, sorting and searching for = vulnerabilities=20 that will ultimately be created with the WAS format. </DIV> <DIV> </DIV> <DIV>Scenario - a security researcher finds a new issue with an=20 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=20 textual descriptions immediatly say that this is a SQL = injection issue and=20 points to the reference description of SQL injection. He has=20 immediatly found common concise accurate language and does not need=20 to dream up the term "Database HTTP Introspection" which would = confuse=20 everyone;-) This is the thing we are creating in this phase. He then = goes to the=20 risk ranking model and is able to deduce that based on the the model = that this=20 is a high risk vulnerability (not to pre-empt that work). This is the = peice we=20 were going to create next. He then describes the specific technical = details of=20 the vulnerability he discovered which will = likely include a=20 combination of all the stuff you mention below. </DIV> <DIV> </DIV> <DIV>I think your Section 2 aligns with this section of work which is = where I=20 think the dis-connect is. The rest is scope for the main body of work we = are=20 doing (the real guts of WAS) but not this peice. </DIV> <DIV> </DIV> <DIV>I know there are a number of people on this list who have mailed me = to=20 explain that thier silence is not a fucntion of their lack of interest = but that=20 they are really interested in the XML Schema (ie the guts only). </DIV> <DIV> </DIV> <DIV>So based on that I have a proposal of two ways we can work moving = forward=20 more effectively. If more people want Option 1we can revise = the=20 schedule / agenda and do this and get cracking ASAP.</DIV> <DIV> </DIV> <DIV>Option 1</DIV> <DIV>I will personally run with completing the thesaurus and risk = ranking=20 models over the next few weeks. This will allow the bulk of the group to = start=20 work on the XML schema and get under the hood. We (I) can revise = the=20 thesaurus work if needed as the XML portion of the project shapes = out.</DIV> <DIV> </DIV> <DIV>If we do this I would suggest we invite Rogan Dawes to spend some = time on=20 this Thursdays meeting walking through the existing VulnXML as a = starting=20 point.</DIV> <DIV> </DIV> <DIV>Option 2</DIV> <DIV>All plough on for the next 6 weeks with the thesaurus and risk = ranking=20 model as planned before tackling the XML.</DIV> <DIV> </DIV> <DIV>I am assuming most people want to get to the WAS format ASAP = so I will=20 setup a vote for this to be completed before COB Tuesday.</DIV> <DIV><BR>Seem sensible ?</DIV> <BLOCKQUOTE dir=3Dltr=20 style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; = BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px"> <DIV style=3D"FONT: 10pt arial">----- Original Message ----- = </DIV> <DIV=20 style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: = black"><B>From:</B>=20 <A title=3Djeff.williams@aspectsecurity.com=20 href=3D"mailto:jeff.williams@aspectsecurity.com">Jeff Williams @ = Aspect</A>=20 </DIV> <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A = title=3Dwas@lists.oasis-open.org=20 href=3D"mailto:was@lists.oasis-open.org">was@lists.oasis-open.org</A> = </DIV> <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Saturday, August 30, 2003 = 8:45=20 AM</DIV> <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> Re: [was] WAS Schema = first draft=20 forwarded from Andrew Jaquith</DIV> <DIV><BR></DIV> <DIV>I've reviewed the schema very closely, and I'm not convinced this = is=20 heading the right direction. Under the proposed schema, a = vulnerability=20 has 5 types of information:</DIV> <DIV> </DIV> <DIV><FONT color=3D#0000ff>Vulnerability</FONT></DIV> <DIV><FONT color=3D#0000ff> - Attack Characteristics = (group=20 and subgroup -- e.g. access control and authorization)</FONT></DIV> <DIV><FONT color=3D#0000ff> - Attack Surfaces = (system=20 boundary, component boundary, source code)</FONT></DIV> <DIV><FONT color=3D#0000ff> - Target (application = component,=20 infrastructure component, end user)</FONT></DIV> <DIV><FONT color=3D#0000ff> - Conditions (privilege, = port)</FONT></DIV> <DIV><FONT color=3D#0000ff> - Consequences (denial = of service,=20 privilege elevation, transfer of trust, identity impersonation, data=20 disclosure, security requirements violation)</FONT></DIV> <DIV> <DIV> </DIV> <DIV>Many of these terms are not clear to me, nor am I convinced that = every=20 vulnerability will have information in all of these categories. = I also=20 believe that many types of useful information have no place in = the=20 proposed schema.</DIV> <DIV> </DIV> <DIV>I think our goal should be to create a language for communicating = about=20 web application vulnerabilities that is rich enough to express all the = information we have about vulnerabilities, yet simple and clear enough = for=20 anyone to understand. In my last message, I proposed a schema = that would=20 look something like this:</DIV> <DIV> </DIV> <DIV><FONT color=3D#0000ff>Vulnerability</FONT></DIV> <DIV><FONT color=3D#0000ff> - Basic=20 Characteristics</FONT></DIV> <DIV><FONT color=3D#0000ff> - Security=20 Characteristics</FONT></DIV> <DIV><FONT color=3D#0000ff> - Testing=20 Characteristics</FONT></DIV> <DIV><FONT color=3D#0000ff> - Exploit=20 Characteristics</FONT></DIV> <DIV><FONT color=3D#0000ff> - Remediation=20 Characteristics</FONT></DIV> <DIV> </DIV> <DIV>Each of those types of characteristics was detailed as = follows:</DIV> <DIV> </DIV> <DIV> <DIV>1 - Basic characteristics -- obvious, concrete characteristics = are the=20 best for unique identification and searching purposes. Some = examples=20 (nowhere near a complete list) I think would be useful to have = documented for=20 each vulnerability are:</DIV> <DIV> <DIV> - The name, version of the targeted=20 application</DIV> <DIV> - Platform info(servers,=20 versions)</DIV> - HTTP info(method, headers, = cookies,=20 domain, response code)</DIV> <DIV> - Parameter info (form name, field name, URL,=20 querystring)</DIV> <DIV> - Code (language, method name, line number, = error=20 message)</DIV> <DIV> - Other common identifiers (filenames)</DIV> <DIV> </DIV> <DIV>2 - Security characteristics -- these will "map"=20 vulnerabilities into a security space. Not as important for unique=20 identification, but very useful for risk analysis and understanding. = By the=20 way, I think using characteristics is a cleaner way to handle the idea = of=20 'groups':</DIV> <DIV> - Security area (confidentiality, integrity,=20 availability, accountability, privacy)</DIV> <DIV> - Vulnerability category (Top Ten, Mark's list = below,=20 others -- this is where the thesaurus idea is best for aliases)</DIV> <DIV> <DIV> - Related security mechanisms (authentication, = authorization, encryption, filtering, logging, = etc...)</DIV> =20 - Likelihood of exploit (tools, difficulty)</DIV> <DIV> - Consequence (defacement, disclosure, = corruption,=20 denial of service)</DIV> <DIV> <DIV> </DIV> <DIV>3 - Characteristics related to how to TEST for the vulnerability = -- =20 these are a step away from characteristics of the vulnerability, but I = think=20 could be included in this model without too much difficulty. Note that = these=20 won't help much at all with unique identification, but will help the = user who=20 wants to know if they're susceptible.</DIV> <DIV> - Finding in running application (proxy mitm,=20 scanning, tools to use)</DIV> <DIV> - Finding in code (search strings, patterns to = look=20 for, tools to use)</DIV> <DIV> </DIV> <DIV>4 - Characteristics related to how to EXPLOIT the vulnerability = -- as=20 discussed on the list, I don't think we should try to put specific = exploit=20 recipes in XML -- it's too hard. This is for a brief text description = of how=20 to exploit. Specific exploits are best represented in NASL, or=20 libwhisker perl, or something.</DIV> <DIV> - Specific tools to use</DIV> <DIV> - Methodology or process</DIV> <DIV> <DIV> </DIV> <DIV>5 - Characteristics related to how to REMEDY the vulnerability -- = I think=20 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. </DIV> <DIV> - Approaches (fix code, block requests, = filter, apply=20 patch, start over)</DIV> <DIV> - Forensics (how to search logs, other = evidence of=20 exploit)</DIV> <DIV> </DIV></DIV></DIV></DIV> <DIV>Thoughts?</DIV> <DIV> </DIV> <DIV>--=20 <STYLE type=3Dtext/css> <!-- body { FONT-Size: 10pt; FONT-Family: 'Arial'; FONT-Weight: normal; } .small { FONT-Size: 9pt; FONT-Family: 'Arial'; FONT-Weight: normal; } --> =09 </STYLE> Jeff </DIV> <DIV> </DIV></DIV> <BLOCKQUOTE=20 style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; = BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px"> <DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV> <DIV=20 style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: = black"><B>From:</B>=20 <A title=3Dmark@curphey.com href=3D"mailto:mark@curphey.com">Mark = Curphey</A>=20 </DIV> <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A = title=3Dwas@lists.oasis-open.org=20 = href=3D"mailto:was@lists.oasis-open.org">was@lists.oasis-open.org</A> = </DIV> <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Tuesday, August 26, = 2003 3:57=20 PM</DIV> <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> [was] WAS Schema = first draft=20 forwarded from Andrew Jaquith</DIV> <DIV><BR></DIV>All,<BR><BR>Attached below is an email and the first = draft at=20 the schema from Andrew Jaquith to deal with the classification / = thesaurus.=20 There is also a Java skunk works app using it. Andy is on the road = this week=20 and so unable to attend this weeks meeting. I am also unable to = attend this=20 weeks meeting so I am proposing we don't meet this week, have an = additional=20 meeting next week but still plough on over the email list. I know = most=20 people were waiting on this schema to get their teeth into things so = I hope=20 things will really get going now. Hint, hint ;-)<BR><BR>I am pretty=20 conscious of time given that in order to maintain schedule we really = need to=20 produce the textual document within a few weeks. So we need to get = into this=20 and close out on the characteristics and groupings this week. I will = then=20 take the lead on creating the documentation version of the thesaurus = that we=20 will release and we can move onto the risk ranking and then the guts = of the=20 WAS format.<BR><BR>Andy you are a = star!<BR><BR>Mark<BR><BR><Andrew=20 Jaquith><BR><BR>Mark,<BR><BR>Here is the first cut at an XML = schema for=20 WAS. The schema is pretty <BR>straightforward, and is taken directly = from=20 the Word doc you sent <BR>previously, plus or minus one or two minor = tweaks=20 I've made.<BR><BR>I've enclosed the schema (src/schema) and a sample = Java=20 app <BR>(SerializerTester) that creates a Vulnerability object, = serializes=20 it to <BR>XML, and deserializes it back into an object graph. If you = are=20 wondering <BR>why the file is so huge, it's because I enclosed all = of the=20 Java and <BR>Javadocs.<BR><BR>If you want to run the Java app you = will need=20 a recent JDK (1.4.2 is <BR>what I used) and the Java Web Services = Developer=20 Pack 1.2.<BR><BR>Everything pretty much flows from the schema, so we = can=20 modify it at <BR>will & then re-generate the Java. I've enclosed = an Ant=20 build.xml file <BR>that automates the build = process.<BR><BR> <BR> <P> <HR> = <P></P>------------------------------------------------------------------= ---<BR>To=20 unsubscribe, e-mail: <A=20 = href=3D"mailto:was-unsubscribe@lists.oasis-open.org">was-unsubscribe@list= s.oasis-open.org</A><BR>For=20 additional commands, e-mail: <A=20 = href=3D"mailto:was-help@lists.oasis-open.org">was-help@lists.oasis-open.o= rg</A></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML> ------=_NextPart_000_01C9_01C36EDF.C29A4B80--
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]