[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: 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]