OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

was message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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 -----
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.

 

 

 

 

 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]