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.