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