Re: [was] Alternative to vulnTypes definition

["Jeff Williams" <jeff.williams@aspectsecurity.com>]

I'm glad you raised this issue.  In using these types, we've already been
forced to extend it quite a bit to cover many problems that we identify in
the code.  I think of this as a namespace for tagging potential
vulnerabilities, and there are quite a lot of things I'd like to tag them
with.  I don't like the idea of infinite extensibility as it will no doubt
cause issues in the future. We created an Other type and added things like
Other.MaliciousCode and a bunch more.  We also had to add things like
AppDos.Client for client side problems.

I think the standard should strongly encourage the use of existing basetypes
and allow extension only if absolutely necessary.  I suggest that
extensions, if useful, should be captured and rolled back into the
standard -- kind of the way javax stuff gets rolled into the java namespace
eventually.

--Jeff

----- Original Message ----- 
From: Peter
To: was@lists.oasis-open.org
Sent: Tuesday, April 20, 2004 2:45 PM
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.