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 ;
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:]
Sent: Tuesday, April 20, 2004 2:45
PM
To:
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.
