Difference between revisions of "CPWE"

From OWASP
Jump to: navigation, search
m (Common Program Weakness Enumeration)
m (Common Program Weakness Enumeration)
Line 13: Line 13:
 
Inadequate Developer Training - (xx)<br>
 
Inadequate Developer Training - (xx)<br>
 
Use of Insufficient Verification Technique - (xx)<br>
 
Use of Insufficient Verification Technique - (xx)<br>
 +
Failure to Address Verification Findings - (xx)<br>
 
Failure to Protect Source Code from Theft - (xx)<br>
 
Failure to Protect Source Code from Theft - (xx)<br>
 
Failure to Protect Sensitive Application Data from Theft - (xx)<br>
 
Failure to Protect Sensitive Application Data from Theft - (xx)<br>

Revision as of 15:17, 30 August 2012

Contents

Introduction

This OWASP cheat sheet for Chief Information Security Officers (CISO) is intended for an executive audience and for application security program assessors. It contains a list of application security program weaknesses that is intended to be built out over time, similar to MITRE's Common Weakness Enumeration (CWE) for software weaknesses. This list of program weaknesses is called the Common Program Weakness Enumeration (CPWE). The CPWE spans topics having to do with both institutionalization of an application security program, and also systems development touch points. An example of a CPWE use case is an organization having a SAMM or BSIMM assessment done, and the findings are mapped to CPWE-ID. Mappings are 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. I.e., regardless if for example SAMM or BSIMM was used. 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), as a sort of brass ring for an OWASP CISO "guide".

Common Program Weakness Enumeration

The comprehensive CPWE dictionary view is below.

Insufficient Program Resources - (12)
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 - (xx)
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)
Regulatory Cybersecurity Risk Disclosure Obligation Issues - (xx)
Regulatory Cyber Incident Disclosure Obligation Issues - (xx)
... - (xx)

Authors and Primary Editors

Mike Boberski - boberski_michael [at] bah.com

Other Cheatsheets

OWASP Cheat Sheets Project Homepage

Developer Cheat Sheets (Builder)

Assessment Cheat Sheets (Breaker)

Mobile Cheat Sheets

OpSec Cheat Sheets (Defender)

Draft Cheat Sheets