RE: [was] Notes on WAS Face to Face

["Peter Michalek" <peter@fortifysoftware.com>]

Yuval,

Thanks for the reminder. Everyone else, rest assured that we your comments
will be taken into account and you'll see them reflected in the schema
definition as it evolves.

Mark, was there a plan where to take article type definition from?


Peter


-----Original Message-----
From: Yuval Ben-Itzhak [mailto:yuvalben@netvision.net.il] 
Sent: Thursday, April 01, 2004 9:18 AM
To: Peter Michalek
Subject: RE: [was] Notes on WAS Face to Face


Peter,

The type "article" was not define in the schema.
<xsd:element name="article" type="article"/>

Yuval.

-----Original Message-----
From: Peter Michalek [mailto:peter@fortifysoftware.com]
Sent: Thursday, April 01, 2004 3:47 PM
To: 'Jeff Williams'; 'Mark Curphey'; 'David Raphael'
Cc: was@lists.oasis-open.org
Subject: RE: [was] Notes on WAS Face to Face


Jeff, thanks for detail annotation notes, I incorporated them into the
document and as you suggested, deleted this:
<xsd:enumeration value="Injection.OS"/>
FIXME: THIS IS A DUPLICATE of Injection.OSCommand and should be deleted.

I also added
BufferOverflow "super-category" that was missing.
I didn't some minor changes in your wording of some, e.g. IntegerOverflow

Modified .xsd and diff to the previous version are attached.

Peter


-----Original Message-----
From: Jeff Williams [mailto:jeff.williams@aspectsecurity.com]
Sent: Wednesday, March 31, 2004 8:49 PM
To: Peter Michalek; 'Mark Curphey'; 'David Raphael'
Cc: was@lists.oasis-open.org
Subject: Re: [was] Notes on WAS Face to Face

Here are some updated definitions.  I'm not sure the syntax for
annotations -- is it right to just have one big block for the whole list?
Or should there be a separate annotation for each item in the list?

-------------

<xsd:enumeration value="AccessControl"/>
Used for problems that allow users to access assets or functions they are
not authorized for. Frequently, there is no access control mechanism where
there should be. A proper access control mechanism should enforce the
principles of a reference monitor: non-bypassable, tamperproof, and
analyzable.

<xsd:enumeration value="ConfigurationManagement"/>
Used to describe problems in the configuration of an application or
application environment.

<xsd:enumeration value="ConfigurationManagement.Administration"/>
Used for problems in the application's mechanisms that enable remote
administration, such as user management, credential management, database
management, and other configuration options.

<xsd:enumeration value="ConfigurationManagement.Application"/>
Used to describe problems in the application's configuration, such as
misconfigured security mechanisms, default programs, unused code, and
unnecessarily enabled features.

<xsd:enumeration value="ConfigurationManagement.Infrastructure"/>
Used for problems with the configuration of the application's
infrastructure, such as the web and application servers, filters, and
external security mechanisms.

<xsd:enumeration value="IntegerOverflow"/>
Used for problems resulting from attempts to put a large number into a
variable too small to hold it. This can occur when parsing problems occur or
mathematical functions are misused. These errors are particularly dangerous
when the overflowed variable is used to allocate memory.

<xsd:enumeration value="DataProtection"/>
Used for issues related to inappropriate disclosure of data.

<xsd:enumeration value="DataProtection.Storage"/>
Used for problems storing data securely, including storage of credentials,
keys, and other sensitive information. Mistakes related to cryptographic
mechanisms are examples, including poor sources of randomness, bad choice of
algorithm, and poor implementation.

<xsd:enumeration value="DataProtection.Transport"/>
Used for problems related to secure transfer of information. Frequently,
this will refer to problems with SSL or TLS configuration, but could include
other protocols with security features.

<xsd:enumeration value="InputValidation"/>
Used for issues related to failure to validate untrusted input before it is
relied on by an application.

<xsd:enumeration value="InputValidation.User"/>
Used for input validation problems where the input comes from a human user,
such as HTTP request parameters, command line input, or input events from an
application's GUI.

<xsd:enumeration value="InputValidation.Network"/>
Used for input validation problems where the input comes from a network
protocol, such as HTTP headers, sequence numbers, or other protocol fields.

<xsd:enumeration value="InputValidation.File"/>
Used for input validation problems where the input comes from a file, such
as a properties file, batch data file, flat-file databases, or other file
based data.

<xsd:enumeration value="Concurrency"/>
Used for errors in multithreaded environments that allow data to be shared
or corrupted. Examples include variables that are shared between threads and
cause time-of-check-time-of-use (TOCTOU) problems, broken singleton
patterns, and poor cache design.

<xsd:enumeration value="AppDOS"/>
Used for flaws that would allow an attacker to completely or partially
prevent users from using an application properly.

<xsd:enumeration value="AppDOS.Flood"/>
Used for application denial of service problems that involve saturating some
limited resource shared by all users of the application, such as disk space,
CPU, network bandwidth, database connections, or memory.

<xsd:enumeration value="AppDOS.Lockout"/>
Used for application denial of service problems that involve using up some
resource that is allocated to a user of the application, such as failed
logon attempts, minutes, messages, or transactions.

<xsd:enumeration value="BufferOverflow.Heap"/>
Used for flaws that allow an attacker to overflow memory that is dynamically
allocated by the application.

<xsd:enumeration value="BufferOverflow.Stack"/>
Used for flaws that allow an attacker to write data into the stack, causing
the program to crash or transfer control.

<xsd:enumeration value="BufferOverflow.Format"/>
Used for flaws that allow an attacker to use format strings to overwrite
locations in memory, allowing data to be changed, program control to be
altered, or the program to crash.

<xsd:enumeration value="Injection"/>
Used for problems that allow an attacker to bury commands into data and have
them interpreted by some system that the data reaches.

<xsd:enumeration value="Injection.OS"/>
FIXME: THIS IS A DUPLICATE of Injection.OSCommand and should be deleted.

<xsd:enumeration value="Injection.SQL"/>
Used for flaws that allow an attacker to inject special characters and
commands into a SQL database and modify the intended query. The attack might
attempt to change the meaning of the query, or might attempt to chain
additional commands.

<xsd:enumeration value="Injection.HTML"/>
Used for flaws that allow an attacker to inject HTML into an application and
modify the appearance of HTML generated by that application. For example, an
attacker might inject an unwanted IMG tag into a guest book, and offend
other users.

<xsd:enumeration value="Injection.OSCommand"/>
Used for flaws that allow an attacker to inject special characters and
commands into the operating system command shell and modify the intended
command. The attack might attempt to modify how a program is invoked, or
might attempt to chain additional commands.

<xsd:enumeration value="Injection.LDAP"/>
Used for flaws that allow an attacker to inject special characters and
search terms into an LDAP server and modify the intended query.

<xsd:enumeration value="Injection.XSS"/>
Used for flaws that allow an attacker to send malicious scripts through a
web application and have them execute on victims' browsers. Stored XSS
attacks involve storing the script in the web application for users to find.
Reflected XSS attacks are bounced off a web application in real time and
require a user to be tricked into sending the request containing the attack.

<xsd:enumeration value="ErrorHandling"/>
Used for problems in handling errors, including printing stack traces to the
screen, fail open security mechanisms, allowing errors to affect the
operation of the entire application, and revealing too much information
about a failure.

<xsd:enumeration value="Monitoring"/>
Used for issues related to monitoring the security posture of a web
application.

<xsd:enumeration value="Monitoring.Logging"/>
Used for issues concerning the proper logging of events, including what
should be logged, how it should be logged, how logs should be reviewed, and
other issues related to accountability.

<xsd:enumeration value="Monitoring.Detection"/>
Used for issues related to the detection of attacks on an application, how
attacks should be handled, what information should be gathered, and who
should be notified.

<xsd:enumeration value="Cryptography"/>
Used for problems related to encryption, decryption, signing, and
verification.

<xsd:enumeration value="Cryptography.Algorithm"/>
Used for cryptographic algorithm selection, implementation, and analysis
problems.

<xsd:enumeration value="Cryptography.KeyManagement"/>
Used for issues with certificate storage, tokens, revocation, certificates,
key stores, issuing keys, and other key issues ;-)

<xsd:enumeration value="Authentication"/>
Used for problems related to determining the identity of individuals and
authenticating that identity.

<xsd:enumeration value="Authentication.User"/>
Used for issues related to identification and authentication of people who
are intended to use an application. Problems with usernames, passwords,
tokens, smartcards, biometrics, and other credentials are examples.

<xsd:enumeration value="Authentication.UserManagement"/>
Used for problems related to managing a set of users, especially the
security relevant information such as roles, privileges, authorizations,
groups, social security numbers, credit card numbers, and other sensitive
information. Also problems with creating new users, registration, granting
rights, and terminating access.

<xsd:enumeration value="Authentication.Entity"/>
Used for problems with authenticating automated systems, such as web
services, databases, directories, and others. Examples include secure
credential storage, securing transport, changing credentials, and
terminating access.

<xsd:enumeration value="Authentication.SessionManagement"/>
Used for problems with issuing, using, protecting, changing, and terminating
session identifiers of all kinds. Session identifiers stand in the place of
authentication credentials yet are freqently not protected as carefully.


--Jeff

----- Original Message -----
From: Peter Michalek
To: 'Mark Curphey' ; 'David Raphael'
Cc: was@lists.oasis-open.org
Sent: Wednesday, March 31, 2004 8:56 PM
Subject: RE: [was] Notes on WAS Face to Face


Mark,

Attached is a (phase I) modification of the schema that we created at the
face to face meeting and also diffs with this baseline:

http://www.oasis-open.org/apps/org/workgroup/was/download.php/6134/oasis-was
-version4.xsd

This modification contains mainly new annotations for vulnTypes, also
including the wording/explanation of why it's a collection (see previous
email from Jeff Williams).

Please see:
1) See: Line 38 - definition of Ids - how to we make them globally unique.
2) Line 308 - vulnList, vulnTypes - first attempt at documenting them, I
think it needs more work, ideally with references to papers to make sure
everyone understands the background behind each type.

I didn't address any of the issues raised in other emails for now.

I also think the suggestion to put this under version control is a good one,
and will make it easier to evolve the schema into the final form.
David, if you decide to do it, you can check this in.


Peter




-----Original Message-----
From: Mark Curphey [mailto:mark.curphey@foundstone.com]
Sent: Monday, March 29, 2004 10:44 AM
To: Peter Michalek
Cc: was@lists.oasis-open.org
Subject: RE: [was] Notes on WAS Face to Face

Peter,

Feel free to clean up what you need to. Some of the older vuln info is
still there and the original info of Attack Types etc from the older
risk ranking model. I think we should take that out.

Also what do you think about a structure of

WAS Core.xsd that calls
WAS Detect
WAS Protect

This allows for an easier development (less merge conflicts) but would
also allow us to increment sub-elements moving forward without having to
update the entire schema.

Mark

As a note Symantec will be joining WAS in an active role this week!



-----Original Message-----
From: Peter Michalek [mailto:peter@fortifysoftware.com]
Sent: Monday, March 29, 2004 11:49 AM
To: Mark Curphey
Subject: RE: [was] Notes on WAS Face to Face

Hi Mark,

This is a good summary of vulnTypes that is useful, how we need to clean
up and publishing as schema so that it has a more professional look. If
you would be OK with that, we could go ahead with my proposal from
Saturday and clean up and relatively finalize the stuff we came up with
last week. You probably want to do it at your own pace and coordinate
with other things, which is fine. Just let me know when you are ready.

Peter


-----Original Message-----
From: Mark Curphey [mailto:mark.curphey@foundstone.com]
Sent: Sunday, March 28, 2004 6:10 PM
To: was@lists.oasis-open.org
Subject: [was] Notes on WAS Face to Face

As you will know from the notifications I have uploaded the meeting
minutes from last weeks face to face and the updated working schema.

It was a great meeting and we are making real progress. I am fairly
confident we can publish the drafts of meta-data and profile as well the
supporting documents before the end of April.

The supporting documents will be;

OASIS WAS Thesaurus (using VulnTypes) - this is the classification
scheme OASIS WAS Vision Document OASIS WAS Core Schema Documented

For those who don't read the minutes or look at the schema, I think some
of the important schema is below. This will allow for rich metrics and
measurement programs to be created by using the categories.


<xsd:simpleType name="vulnList">
<xsd:restriction base="xsd:string">
<xsd:enumeration value="AccessControl" />
<xsd:enumeration value="ConfigurationManagement"
/>
<xsd:enumeration
value="ConfigurationManagement.Administration" />
<xsd:enumeration
value="ConfigurationManagement.Application" />
<xsd:enumeration
value="ConfigurationManagement.Infrastructure" />
<xsd:enumeration value="IntegerOverflow" />
<xsd:enumeration value="DataProtection" />
<xsd:enumeration value="DataProtection.Storage"
/>
<xsd:enumeration
value="DataProtection.Transport" />
<xsd:enumeration value="InputValidation" />
<xsd:enumeration value="InputValidation.User" />
<xsd:enumeration value="InputValidation.Network"
/>
<xsd:enumeration value="InputValidation.File" />
<xsd:enumeration value="Concurrency" />
<xsd:enumeration value="AppDOS" />
<xsd:enumeration value="AppDOS.Flood" />
<xsd:enumeration value="AppDOS.Lockout" />
<xsd:enumeration value="BufferOverflow.Heap" />
<xsd:enumeration value="BufferOverflow.Stack" />
<xsd:enumeration value="BufferOverflow.Format"
/>
<xsd:enumeration value="Injection" />
<xsd:enumeration value="Injection.OS" />
<xsd:enumeration value="Injection.SQL" />
<xsd:enumeration value="Injection.HTML" />
<xsd:enumeration value="Injection.OSCommand" />
<xsd:enumeration value="Injection.LDAP" />
<xsd:enumeration value="Injection.XSS" />
<xsd:enumeration value="ErrorHandling" />
<xsd:enumeration value="Monitoring" />
<xsd:enumeration value="Monitoring.Logging" />
<xsd:enumeration value="Monitoring.Detection" />
<xsd:enumeration value="Cryptography" />
<xsd:enumeration value="Cryptography.Algorithm"
/>
<xsd:enumeration
value="Cryptography.KeyManagement" />
<xsd:enumeration value="Authentication" />
<xsd:enumeration value="Authentication.User" />
<xsd:enumeration
value="Authentication.UserManagement" />
<xsd:enumeration value="Authentication.Entity"
/>
<xsd:enumeration
value="Authentication.SessionManagement" />
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="appType">
<xsd:restriction base="xsd:string">
<xsd:enumeration value="client-server" />
<xsd:enumeration value="web service" />
<xsd:enumeration value="standalone" />
<xsd:enumeration value="p2p" />
<xsd:enumeration value="web application" />
<xsd:enumeration value="server" />
<xsd:enumeration value="client" />
<xsd:enumeration value="mainframe" />
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="rootCauseType">
<xsd:restriction base="xsd:string">
<xsd:enumeration value="software defect" />
<xsd:enumeration value="config" />
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="RelatedProcesses">
<xsd:restriction base="xsd:string">
<xsd:enumeration value="RequirementsAnalysis" />
<xsd:enumeration value="DesignAnalysis" />
<xsd:enumeration value="code" />
<xsd:enumeration value="SecurityTesting" />
<xsd:enumeration value="Deployment" />
</xsd:restriction>
</xsd:simpleType>
</xsd:schema>

Mark Curphey
Consulting Director
Foundstone, Inc.
Strategic Security

949.297.5600 x2070 Tel
781.738.0857 Cell
949.297.5575 Fax

http://www.foundstone.com

This email may contain confidential and privileged information for the
sole use of the intended recipient. Any review or distribution by others
is strictly prohibited. If you are not the intended recipient, please
contact the sender and delete all copies of this message. Thank you.

To unsubscribe from this mailing list (and be removed from the roster of
the OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/was/members/leave_workgroup
.php
.




To unsubscribe from this mailing list (and be removed from the roster of the
OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/was/members/leave_workgroup.php
.


To unsubscribe from this mailing list (and be removed from the roster of the
OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/was/members/leave_workgroup.php
.