Difference between revisions of "CPWE"

From OWASP
Jump to: navigation, search
m (Common Program Weakness Enumeration)
m
 
(41 intermediate revisions by one user not shown)
Line 1: Line 1:
 
= Introduction =
 
= Introduction =
This OWASP cheat sheet for CISO is intended for an executive audience and for application security program assessors. It contains a list / taxonomy of application security program weaknesses that is intended to be built out over time, similar to MITRE's CWE for software weaknesses. This list of program not software weaknesses is called the Common Program Weakness Enumeration (CPWE) and spans topics having to do with (1)institutionalization of an application security program and also (2)systems development touch points. One example use case is an organization having a SAMM or BSIMM assessment done, with the findings are mapped to CPWE, in a similar fashion as one can generally configure software vulnerability assessment tools to map findings to CWE or Top Ten, so that one can compare apples to apples regardless of if SAMM or e.g. BSIMM or what have you are used. Long-term goals potentially include creating an OWASP CISO Top Ten project using the CPWE as inputs (i.e. that draws from the list), as a sort of brass ring for an OWASP CISO "guide".
+
This OWASP initiative is intended for an executive audience and for application security program assessors. It contains a list of application security program weaknesses called the Common Program Weakness Enumeration (CPWE) that is intended to be built out over time, similar to MITRE's Common Weakness Enumeration (CWE) for software weaknesses. The CPWE spans topics having to do with both institutionalization of an application security program, and also systems development touch points. A CPWE use case is an organization having a SAMM (or a BSIMM, or a less formal assessment) done, and the findings are mapped to CPWE-ID. Mappings in this example would be done in a similar fashion as one can for example generally configure software vulnerability assessment tools to map software weakness findings to CWE (or e.g. OWASP Top Ten), so that one can compare apples to apples regardless of program assessment methodology.  
  
= Common Program Weakness Enumeration =
+
'''Example: '''Below is a notional example of reporting findings from some SwA program assessment using CPWE:
The comprehensive CPWE dictionary view is below.
+
  
== CPWE-xx: Insufficient Program Resources ==
+
  '''Severe (3 Findings)'''
'''Description'''
+
      CPWE-3: Failure to Address Verification Findings For Application X  ''<-- This is an instance of a finding of type CPWE-3''
* The software development organization or organizational unit has started an application security program, but the resources allocated to support the program (people, tools, or a combination thereof) are not sufficient, the initiative is either not funded or under-funded.
+
      CPWE-3: Failure to Address Verification Findings For Application Y  ''<-- This is another instance of a finding of type CPWE-3''
 +
      CPWE-12: Insufficient Program Resources For Project Z  ''<-- This is an instance of a finding of type CPWE-12''
 +
  '''High (xx Findings)'''
 +
      ...
 +
  '''Moderate (xx Findings)'''
 +
  '''Low (xx Findings)'''
  
'''Modes of Introduction'''
+
Long-term goals for leveraging the CPWE potentially include creating an OWASP CISO Top Ten project using the CPWE as inputs (i.e. that draws from the list), similar to how the CWE/SANS Top 25 list is constructed using the CWE.
  
* This weakness typically occurs in situations where there is no executive-level application security evangelist.
+
= Contributor Instructions =
 +
First, thank you for considering contributing. Generally, I think for CPWE outlines we need at least the five sections as in the example ([[CPWE-ID: 12|Insufficient Program Resources - (12)]]). I think we should make sure to cover not just BSIMM and SAMM, but NIST SP 800-64 (and actually make sure the SP is well-represented). I think CWPE text needs to be CWE-like (i.e. brief but consistent in presentation and level of detail), but also slightly bent towards an executive audience. I think CWPE consequences need to grouped into those two top-level buckets for sure, for clear alignment in that regard to CF Disclosure Guidance: Topic No. 2.  
  
'''Common Consequences'''
+
Next steps if you are interested would be to send a note to boberski_michael [at] bah.com for an assignment for further discussion on an item.
  
* ''Prior to a Cyber Incident -'' Delayed program adoption
+
= Common Program Weakness Enumeration =
* ''During and After a Cyber Incident -'' Unknown business risk; impaired incident response
+
The comprehensive CPWE dictionary view is below.
  
== CPWE-xx: ... ==
+
[[CPWE-ID: 12|Insufficient Program Resources - (12)]]<br>
 
+
Organizational Culture Problems - (xx)<br>
"Insufficient Program Resources - (##)"..... if you only put someone on this half time you'll continue limping along trying to start a secure software development program........
+
Missing Policy - (xx)<br>
 
+
Missing Standards - (xx)<br>
"Lack of Verification Capability  - (##)"........ if you have for instance only a couple people to get some elements of the program going but not enough to have an enforcement/verification capability..........
+
Missing Solution Stack Guidance - (xx)<br>
 
+
Missing Secure Coding Standards - (xx)<br>
Etc,
+
Missing Common Security Control Libraries - (xx)<br>
.. initial, then e.g. (make a pass through sp)
+
Inadequate Developer Training - (xx)<br>
.....some top-level generic using sp, 5 generic, e.g. missing or inadequate implementation phase activities
+
Use of Insufficient Verification Technique - (xx)<br>
... risky or dangerous vendor service
+
Failure to Address Verification Findings - (3)<br>
.. risky or dangerous application or service integration ((split all these 'ors' into separate ones))
+
Failure to Protect Source Code from Theft - (xx)<br>
.. missing policy
+
Failure to Protect Sensitive Application Data from Theft - (xx)<br>
.. missing standards
+
Failure to Track Security Bugs - (xx)<br>
.. missing systems development activity
+
Failure to Address Implicit Contractual Requirements - (xx)<br>
.. missing systems development gate
+
Failure to Address Explicit Contractual Requirements - (xx)<br>
.. failure to track compliance activities
+
Risky Internal Integration - (xx)<br>
.. failure to track security bugs
+
Risky Vendor Integration - (xx)<br>
.. failure to protect source code from theft
+
Broken or Risky Platform - (xx)<br>
... missing or inadequate developer training
+
Broken or Risky Service - (xx)<br>
.. no reusable common security control libraries
+
Weaknesses that Affect SDLC Initiation Phase - (xx)<br>
.. no secure coding standards
+
Weaknesses that Affect SDLC Development/Acquisition Phase - (xx)<br>
.. no minimum lifecycle activities
+
Weaknesses that Affect SDLC Implementation/Assessment Phase - (xx)<br>
.. failure to address implicit contractual or regulatory requirements
+
Weaknesses that Affect SDLC Maintenance Phase - (xx)<br>
.. failure to address explicit contractual or regulatory requirements
+
Weaknesses that Affect SDLC Disposal Phase - (xx)<br>
.. inappropriate or inadequate secure development lifecycle activity
+
Supply Chain Issues - (xx)<br>
.. portfolio posture blindness
+
Service-Oriented Architecture Issues - (xx)<br>
.. application posture blindness
+
Reusable Security Module Issues - (xx)<br>
.. potentially material event (add ref to draft guidance)
+
Cross-Organizational Solution Issues - (xx)<br>
 
+
Migration Issues - (xx)<br>
 
+
Data Center or Development Facility Issues - (xx)<br>
 
+
Virtualization Issues - (xx)<br>
== CPWE-xx: ... ==
+
Regulatory Cybersecurity Risk Disclosure Obligation Issues - (xx)<br>
 +
Regulatory Cyber Incident Disclosure Obligation Issues - (xx)<br>
 +
Weaknesses in In-House Applications - (xx)<br>
 +
Weaknesses in In-House Mobile Applications - (xx)<br>
 +
Weaknesses in In-House App Store - (xx)<br>
 +
Weaknesses in Vendor Applications - (xx)<br>
 +
Weaknesses in Vendor Mobile Applications - (xx)<br>
 +
Weaknesses in Vendor App Store - (xx)<br>
 +
Weaknesses in In-House Verification Services - (xx)<br>
 +
Weaknesses in Vendor Verification Services - (xx)<br>
 +
... - (xx)<br>
  
 
= Authors and Primary Editors  =
 
= Authors and Primary Editors  =
  
 
Mike Boberski - boberski_michael [at] bah.com
 
Mike Boberski - boberski_michael [at] bah.com
 
= Other Cheatsheets =
 
{{Cheatsheet_Navigation}}
 
 
[[Category:Cheatsheets]]
 

Latest revision as of 14:22, 26 September 2012

Contents

Introduction

This OWASP initiative is intended for an executive audience and for application security program assessors. It contains a list of application security program weaknesses called the Common Program Weakness Enumeration (CPWE) that is intended to be built out over time, similar to MITRE's Common Weakness Enumeration (CWE) for software weaknesses. The CPWE spans topics having to do with both institutionalization of an application security program, and also systems development touch points. A CPWE use case is an organization having a SAMM (or a BSIMM, or a less formal assessment) done, and the findings are mapped to CPWE-ID. Mappings in this example would be done in a similar fashion as one can for example generally configure software vulnerability assessment tools to map software weakness findings to CWE (or e.g. OWASP Top Ten), so that one can compare apples to apples regardless of program assessment methodology.

Example: Below is a notional example of reporting findings from some SwA program assessment using CPWE:

 Severe (3 Findings)
     CPWE-3: Failure to Address Verification Findings For Application X  <-- This is an instance of a finding of type CPWE-3
     CPWE-3: Failure to Address Verification Findings For Application Y  <-- This is another instance of a finding of type CPWE-3
     CPWE-12: Insufficient Program Resources For Project Z  <-- This is an instance of a finding of type CPWE-12
 High (xx Findings)
     ...
 Moderate (xx Findings)
 Low (xx Findings)

Long-term goals for leveraging the CPWE potentially include creating an OWASP CISO Top Ten project using the CPWE as inputs (i.e. that draws from the list), similar to how the CWE/SANS Top 25 list is constructed using the CWE.

Contributor Instructions

First, thank you for considering contributing. Generally, I think for CPWE outlines we need at least the five sections as in the example (Insufficient Program Resources - (12)). I think we should make sure to cover not just BSIMM and SAMM, but NIST SP 800-64 (and actually make sure the SP is well-represented). I think CWPE text needs to be CWE-like (i.e. brief but consistent in presentation and level of detail), but also slightly bent towards an executive audience. I think CWPE consequences need to grouped into those two top-level buckets for sure, for clear alignment in that regard to CF Disclosure Guidance: Topic No. 2.

Next steps if you are interested would be to send a note to boberski_michael [at] bah.com for an assignment for further discussion on an item.

Common Program Weakness Enumeration

The comprehensive CPWE dictionary view is below.

Insufficient Program Resources - (12)
Organizational Culture Problems - (xx)
Missing Policy - (xx)
Missing Standards - (xx)
Missing Solution Stack Guidance - (xx)
Missing Secure Coding Standards - (xx)
Missing Common Security Control Libraries - (xx)
Inadequate Developer Training - (xx)
Use of Insufficient Verification Technique - (xx)
Failure to Address Verification Findings - (3)
Failure to Protect Source Code from Theft - (xx)
Failure to Protect Sensitive Application Data from Theft - (xx)
Failure to Track Security Bugs - (xx)
Failure to Address Implicit Contractual Requirements - (xx)
Failure to Address Explicit Contractual Requirements - (xx)
Risky Internal Integration - (xx)
Risky Vendor Integration - (xx)
Broken or Risky Platform - (xx)
Broken or Risky Service - (xx)
Weaknesses that Affect SDLC Initiation Phase - (xx)
Weaknesses that Affect SDLC Development/Acquisition Phase - (xx)
Weaknesses that Affect SDLC Implementation/Assessment Phase - (xx)
Weaknesses that Affect SDLC Maintenance Phase - (xx)
Weaknesses that Affect SDLC Disposal Phase - (xx)
Supply Chain Issues - (xx)
Service-Oriented Architecture Issues - (xx)
Reusable Security Module Issues - (xx)
Cross-Organizational Solution Issues - (xx)
Migration Issues - (xx)
Data Center or Development Facility Issues - (xx)
Virtualization Issues - (xx)
Regulatory Cybersecurity Risk Disclosure Obligation Issues - (xx)
Regulatory Cyber Incident Disclosure Obligation Issues - (xx)
Weaknesses in In-House Applications - (xx)
Weaknesses in In-House Mobile Applications - (xx)
Weaknesses in In-House App Store - (xx)
Weaknesses in Vendor Applications - (xx)
Weaknesses in Vendor Mobile Applications - (xx)
Weaknesses in Vendor App Store - (xx)
Weaknesses in In-House Verification Services - (xx)
Weaknesses in Vendor Verification Services - (xx)
... - (xx)

Authors and Primary Editors

Mike Boberski - boberski_michael [at] bah.com