RE: [was] Alternative to vulnTypes definition

I have just uploaded a working document for the VulnTypes and Vuln Ranking model. There is still some work to do but I would REALLY like to release this draft before the end of the month as we committed to.

If we assume that we are to go with model 3 as put forward by Peter, are there any other comments / concerns about the VulnTypes ?

I have created a placeholder for some examples in the back of the doc.

From: Jeff Williams [mailto:jeff.williams@aspectsecurity.com]
Sent: Sunday, April 25, 2004 9:12 PM
To: Mark Curphey; Peter; was@lists.oasis-open.org
Subject: Re: [was] Alternative to vulnTypes definition

I like 3 too. I think we should include some guidance in the document for when and how to create a new subtype.

--Jeff

----- Original Message -----

From: Mark Curphey

To: Peter ; was@lists.oasis-open.org

Sent: Sunday, April 25, 2004 8:41 PM

Subject: RE: [was] Alternative to vulnTypes definition

I like 3. I like the idea of 2 but in your example of cookie poisoning, that’s either an issue of InputValidation or AccessControl. In this case it actually forces people to describe the issue correctly rather than have to create a new term. No Database Sabotage please ;-) Save it for the 007 films ;-)

From: Peter [mailto:peter@fortifysoftware.com]
Sent: Tuesday, April 20, 2004 2:45 PM
To: was@lists.oasis-open.org
Subject: [was] Alternative to vulnTypes definition

Summary: This is a follow-up on a vulnTypes discussion at the last teleconference.

The alternative 2) below offers a good compromise among possible approaches while allowing an organization to extend the types currently defined.

---------

In the current WAS core schema proposal as of April 18, 2004, vulnTypes are strongly typed as enums, offering 54 values in 13 categories. Here is the summary:

Major vulnType categories (13 entries):

AccessControl

ConfigurationManagement

IntegerOverflow

DataProtection

InputValidation

Concurrency

AppDOS

BufferOverflow

Injection

ErrorHandling

Monitoring

Cryptography

Authentication

Complete list of vulnTypes (54 entries)

AccessControl

ConfigurationManagement

ConfigurationManagement.Administration

ConfigurationManagement.Application

ConfigurationManagement.Infrastructure

IntegerOverflow

DataProtection

DataProtection.Storage

DataProtection.Transport

InputValidation

InputValidation.User

InputValidation.Network

InputValidation.File

Concurrency

AppDOS

AppDOS.Flood

AppDOS.Lockout

BufferOverflow

BufferOverflow.Heap

BufferOverflow.Stack

BufferOverflow.Format

Injection

Injection.SQL

Injection.HTML

Injection.OSCommand

Injection.LDAP

Injection.XSS

ErrorHandling

Monitoring

Monitoring.Logging

Monitoring.Detection

Cryptography

Cryptography.Algorithm

Cryptography.KeyManagement

Authentication

Authentication.User

Authentication.UserManagement

Authentication.Entity

Authentication.SessionManagement

The primary reason behind originally offering a discrete list of enums was for the consumer of the vuln documents to be able to rely on a constant set of values and that all types can be recognized and processed properly.

Here are some alternatives to this approach with cons and pros, 1) being the original proposal.

1) Only strongly typed vulnTypes

Pros: Consumer knows all values and can process properly

Cons: Can't be extended to support company-specific vuln type extensions

Note: namespace can be extended in future versions of the schema

Example:

a) A new vulnerability type such as "InformationLeakage" can't be used

b) A new vulnerability type such as "Authentication.SessionManagement.CookiePoisoning" can't be used

2) vulnTypes include those proposed, plus extension of any form

Pros: Ultimate flexibility for producer of xml vuln documents

Cons: Consumer program who doesn't know the particular extensions may not be

able to handle them properly (perhaps will categorize them as unknown)

Examples:

Both a) and b) above are supported.

3) vulnTypes include those proposed, plus extension of the form {supportedBase}.extension

Pros: depends on your perspective: Compromise between flexibility and some level of type restrictions

Pros: Consumer program who doesn't know the particular extensions may not be

able to handle them properly (perhaps will categorize them as unknown)

Example:

a) A new vulnerability type such as "InformationLeakage" can't be used

b) A new vulnerability type such as "Authentication.SessionManagement.CookiePoisoning" or "Authentication.MycompanyAuthentication" may be used

Notes:

- 1), 2), 3) would work better if a more complete coverage of base types is provided, such as

a new type "InformationLeakage"

- The first pro in 3) is somewhat subjective - depends on your perspective.

was message