https://wiki.owasp.org/api.php?action=feedcontributions&user=Deleted+user&feedformat=atomOWASP - User contributions [en]2024-03-29T01:11:03ZUser contributionsMediaWiki 1.27.2https://wiki.owasp.org/index.php?title=Template:Cheatsheet_Navigation&diff=141017Template:Cheatsheet Navigation2012-12-10T23:54:25Z<p>Deleted user: </p>
<hr />
<div>'''OWASP Cheat Sheets Project Homepage'''<br />
* [[Cheat Sheets]]<br />
<br />
'''Developer Cheat Sheets (Builder)'''<br />
* [[Authentication Cheat Sheet]]<br />
* [[Choosing and Using Security Questions Cheat Sheet]]<br />
* [[Clickjacking Defense Cheat Sheet]]<br />
* [[Cross-Site Request Forgery (CSRF) Prevention Cheat Sheet]]<br />
* [[Cryptographic Storage Cheat Sheet]]<br />
* [[DOM based XSS Prevention Cheat Sheet]]<br />
* [[Forgot Password Cheat Sheet]]<br />
* [[HTML5 Security Cheat Sheet]]<br />
* [[Input Validation Cheat Sheet]]<br />
* [[JAAS Cheat Sheet]]<br />
* [[Logging Cheat Sheet]]<br />
* [[OWASP Top Ten Cheat Sheet]]<br />
* [[Query Parameterization Cheat Sheet]]<br />
* [[REST Security Cheat Sheet]]<br />
* [[Session Management Cheat Sheet]]<br />
* [[SQL Injection Prevention Cheat Sheet]]<br />
* [[Transport Layer Protection Cheat Sheet]]<br />
* [[Web Service Security Cheat Sheet]]<br />
* [[XSS (Cross Site Scripting) Prevention Cheat Sheet]]<br />
* [[User Privacy Protection Cheat Sheet]]<br />
<br />
'''Assessment Cheat Sheets (Breaker)'''<br />
* [[Attack Surface Analysis Cheat Sheet]]<br />
* [[XSS Filter Evasion Cheat Sheet]]<br />
<br />
'''Mobile Cheat Sheets'''<br />
* [[IOS Developer Cheat Sheet]]<br />
* [[Mobile Jailbreaking Cheat Sheet]]<br />
<br />
'''Draft Cheat Sheets'''<br />
* [[Access Control Cheat Sheet]]<br />
* [[Application Security Architecture Cheat Sheet]]<br />
* [[Password Storage Cheat Sheet]]<br />
* [[PHP Security Cheat Sheet]]<br />
* [[.NET Security Cheat Sheet]]<br />
* [[Secure Coding Cheat Sheet]]<br />
* [[Secure SDLC Cheat Sheet]]<br />
* [[Threat Modeling Cheat Sheet]]<br />
* [[Virtual Patching Cheat Sheet]]<br />
* [[Web Application Security Testing Cheat Sheet]]<br />
* [[Grails Secure Code Review Cheat Sheet]]</div>Deleted userhttps://wiki.owasp.org/index.php?title=Grails_Secure_Code_Review_Cheat_Sheet&diff=141016Grails Secure Code Review Cheat Sheet2012-12-10T23:52:54Z<p>Deleted user: Initial annotated outline</p>
<hr />
<div>= Introduction =<br />
This article is focused on providing clear, simple, actionable guidance for getting started reviewing the source code of applications written using the Grails web application framework for potential security flaws, whether architectural or implementation-related. Reviewing Grails application source code can be tricky, for example it is very easy even for an experienced code reviewer to unintentionally skip past (i.e. not review) parts of a Grails application because of certain features of the language and the framework. This is in short because of Groovy programming language-specific and Grails framework-specific language considerations that are explored in this article. This article can be used as a checklist for reviewing Grails application source code for both architectural and implementation-related potential security flaws. Guidance provided can be used to support manual analysis, automated analysis, or combinations thereof, depending on the resources that you might have available.<br />
<br />
== Groovy Language Basics ==<br />
TODO<br />
===“.groovy” Files===<br />
TODO<br />
===“.gsp” Files===<br />
TODO<br />
== Grails Framework Basics ==<br />
Wikipedia describes the Grails framework as... TODO<br />
===Grails Programming Languages===<br />
TODO<br />
===Grails Application Directory Structure===<br />
TODO<br />
== Why Can’t I Just Scan The Byte Code Compiled From The Generated Java Classes? ==<br />
Well, you can. But, even assuming that you can (1)build the code or get the compiled bytecode, and (2)have access to a decent automated static analysis tool, you’re going to find yourself with very noisy results that can’t easily be acted upon by developers. Since, the developers will need findings for generated code translated into findings mapped back to the original Groovy code in order to make fixes that are appropriate to their Grails and Groovy language solution stack (i.e. using a Java language fix or a Java language library such as OWASP’s ESAPI may not be appropriate or actionable for technical or non-technical reasons). Further, you’re going to find that Groovy language-specific considerations, along with Grails library and framework-specific considerations are not being analyzed.<br />
... TODO... Code Narc not enough...<br />
= Getting Started Reviewing Groovy Language Source Code Files =<br />
TODO<br />
== Reviewing Groovy Language Files (.groovy and .gsp) ==<br />
TODO<br />
===Groovy Language Considerations===<br />
TODO<br />
===Groovy Library and Framework Considerations===<br />
TODO<br />
== Reviewing Grails Framework Groovy Language Files ==<br />
TODO<br />
===Grails Model Considerations===<br />
TODO<br />
===Grails View Considerations===<br />
TODO<br />
===Grails Controller Considerations===<br />
TODO<br />
===Grails Service Considerations===<br />
TODO<br />
== Reviewing Java In Groovy Language Files (.groovy and .gsp) ==<br />
TODO<br />
= Getting Started Reviewing Java Language Source Code Included in Grails Applications =<br />
TODO<br />
== Reviewing Java In Java Language Files (.java and .jsp) ==<br />
... Review like any other Java app... TODO... <br />
== Reviewing Other Java Language File Types ==<br />
... Review like any other Java app... TODO... <br />
= Getting Started Reviewing Other Types of Source Code And Functionality Included in Grails Applications =<br />
TODO<br />
== Reviewing Other Types Included For Use by the Grails Framework ==<br />
TODO<br />
== Reviewing Other Types Included For Use by Java Language Source Code ==<br />
TODO<br />
= Code Review Tool Configuration Summary =<br />
TODO<br />
= References and Further Reading =<br />
...Groovy pages... Grails security pages....etc...TODO<br />
= Authors and Primary Editors =<br />
Mike Boberski - boberski_michael[at]bah.com<br />
= Other Cheat Sheets =<br />
{{Cheatsheet_Navigation}}<br />
[[Category:Cheatsheets]]</div>Deleted userhttps://wiki.owasp.org/index.php?title=CPWE&diff=136655CPWE2012-09-26T19:22:12Z<p>Deleted user: </p>
<hr />
<div>= Introduction =<br />
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. <br />
<br />
'''Example: '''Below is a notional example of reporting findings from some SwA program assessment using CPWE:<br />
<br />
'''Severe (3 Findings)'''<br />
CPWE-3: Failure to Address Verification Findings For Application X ''<-- This is an instance of a finding of type CPWE-3''<br />
CPWE-3: Failure to Address Verification Findings For Application Y ''<-- This is another instance of a finding of type CPWE-3''<br />
CPWE-12: Insufficient Program Resources For Project Z ''<-- This is an instance of a finding of type CPWE-12''<br />
'''High (xx Findings)'''<br />
...<br />
'''Moderate (xx Findings)'''<br />
'''Low (xx Findings)'''<br />
<br />
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.<br />
<br />
= Contributor Instructions =<br />
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. <br />
<br />
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.<br />
<br />
= Common Program Weakness Enumeration =<br />
The comprehensive CPWE dictionary view is below.<br />
<br />
[[CPWE-ID: 12|Insufficient Program Resources - (12)]]<br><br />
Organizational Culture Problems - (xx)<br><br />
Missing Policy - (xx)<br><br />
Missing Standards - (xx)<br><br />
Missing Solution Stack Guidance - (xx)<br><br />
Missing Secure Coding Standards - (xx)<br><br />
Missing Common Security Control Libraries - (xx)<br><br />
Inadequate Developer Training - (xx)<br><br />
Use of Insufficient Verification Technique - (xx)<br><br />
Failure to Address Verification Findings - (3)<br><br />
Failure to Protect Source Code from Theft - (xx)<br><br />
Failure to Protect Sensitive Application Data from Theft - (xx)<br><br />
Failure to Track Security Bugs - (xx)<br><br />
Failure to Address Implicit Contractual Requirements - (xx)<br><br />
Failure to Address Explicit Contractual Requirements - (xx)<br><br />
Risky Internal Integration - (xx)<br><br />
Risky Vendor Integration - (xx)<br><br />
Broken or Risky Platform - (xx)<br><br />
Broken or Risky Service - (xx)<br><br />
Weaknesses that Affect SDLC Initiation Phase - (xx)<br><br />
Weaknesses that Affect SDLC Development/Acquisition Phase - (xx)<br><br />
Weaknesses that Affect SDLC Implementation/Assessment Phase - (xx)<br><br />
Weaknesses that Affect SDLC Maintenance Phase - (xx)<br><br />
Weaknesses that Affect SDLC Disposal Phase - (xx)<br><br />
Supply Chain Issues - (xx)<br><br />
Service-Oriented Architecture Issues - (xx)<br><br />
Reusable Security Module Issues - (xx)<br><br />
Cross-Organizational Solution Issues - (xx)<br><br />
Migration Issues - (xx)<br><br />
Data Center or Development Facility Issues - (xx)<br><br />
Virtualization Issues - (xx)<br><br />
Regulatory Cybersecurity Risk Disclosure Obligation Issues - (xx)<br><br />
Regulatory Cyber Incident Disclosure Obligation Issues - (xx)<br><br />
Weaknesses in In-House Applications - (xx)<br><br />
Weaknesses in In-House Mobile Applications - (xx)<br><br />
Weaknesses in In-House App Store - (xx)<br><br />
Weaknesses in Vendor Applications - (xx)<br><br />
Weaknesses in Vendor Mobile Applications - (xx)<br><br />
Weaknesses in Vendor App Store - (xx)<br><br />
Weaknesses in In-House Verification Services - (xx)<br><br />
Weaknesses in Vendor Verification Services - (xx)<br><br />
... - (xx)<br><br />
<br />
= Authors and Primary Editors =<br />
<br />
Mike Boberski - boberski_michael [at] bah.com</div>Deleted userhttps://wiki.owasp.org/index.php?title=Template:Cheatsheet_Navigation&diff=136354Template:Cheatsheet Navigation2012-09-24T17:00:53Z<p>Deleted user: </p>
<hr />
<div>'''OWASP Cheat Sheets Project Homepage'''<br />
* [[Cheat Sheets]]<br />
<br />
'''Developer Cheat Sheets (Builder)'''<br />
* [[Authentication Cheat Sheet]]<br />
* [[Choosing and Using Security Questions Cheat Sheet]]<br />
* [[Cross-Site Request Forgery (CSRF) Prevention Cheat Sheet]]<br />
* [[Cryptographic Storage Cheat Sheet]]<br />
* [[DOM based XSS Prevention Cheat Sheet]]<br />
* [[Forgot Password Cheat Sheet]]<br />
* [[HTML5 Security Cheat Sheet]]<br />
* [[Input Validation Cheat Sheet]]<br />
* [[JAAS Cheat Sheet]]<br />
* [[Logging Cheat Sheet]]<br />
* [[OWASP Top Ten Cheat Sheet]]<br />
* [[Query Parameterization Cheat Sheet]]<br />
* [[Session Management Cheat Sheet]]<br />
* [[SQL Injection Prevention Cheat Sheet]]<br />
* [[Transport Layer Protection Cheat Sheet]]<br />
* [[Web Service Security Cheat Sheet]]<br />
* [[XSS (Cross Site Scripting) Prevention Cheat Sheet]]<br />
<br />
'''Assessment Cheat Sheets (Breaker)'''<br />
* [[Attack Surface Analysis Cheat Sheet]]<br />
* [[XSS Filter Evasion Cheat Sheet]]<br />
<br />
'''Mobile Cheat Sheets'''<br />
* [[IOS Developer Cheat Sheet]]<br />
* [[Mobile Jailbreaking Cheat Sheet]]<br />
<br />
'''Draft Cheat Sheets'''<br />
* [[Access Control Cheat Sheet]]<br />
* [[Application Security Architecture Cheat Sheet]]<br />
* [[Clickjacking Cheat Sheet]]<br />
* [[Password Storage Cheat Sheet]]<br />
* [[PHP Security Cheat Sheet]]<br />
* [[REST Security Cheat Sheet]]<br />
* [[Secure Coding Cheat Sheet]]<br />
* [[Secure SDLC Cheat Sheet]]<br />
* [[Threat Modeling Cheat Sheet]]<br />
* [[Virtual Patching Cheat Sheet]]<br />
* [[Web Application Security Testing Cheat Sheet]]</div>Deleted userhttps://wiki.owasp.org/index.php?title=CPWE-ID:_12&diff=135846CPWE-ID: 122012-09-13T23:57:48Z<p>Deleted user: /* Other CPWE */</p>
<hr />
<div>== Insufficient Program Resources ==<br />
'''Description'''<br />
* 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.<br />
<br />
'''Common Causes'''<br />
<br />
* This weakness typically occurs in situations where there is no executive-level application security evangelist.<br />
<br />
'''Common Consequences'''<br />
<br />
* ''Prior to a Cyber Incident -'' Delayed program adoption<br />
* ''During and After a Cyber Incident -'' Unknown business risk; impaired incident response<br />
<br />
'''Severity'''<br />
<br />
* ''Critical -'' This must be addressed immediately.<br />
<br />
'''References'''<br />
<br />
* TODO<br />
<br />
== Other CPWE ==<br />
[[CPWE|Common Program Weakness Enumeration (CPWE)]]</div>Deleted userhttps://wiki.owasp.org/index.php?title=CPWE-ID:_12&diff=135845CPWE-ID: 122012-09-13T23:57:24Z<p>Deleted user: /* Other CPWE */</p>
<hr />
<div>== Insufficient Program Resources ==<br />
'''Description'''<br />
* 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.<br />
<br />
'''Common Causes'''<br />
<br />
* This weakness typically occurs in situations where there is no executive-level application security evangelist.<br />
<br />
'''Common Consequences'''<br />
<br />
* ''Prior to a Cyber Incident -'' Delayed program adoption<br />
* ''During and After a Cyber Incident -'' Unknown business risk; impaired incident response<br />
<br />
'''Severity'''<br />
<br />
* ''Critical -'' This must be addressed immediately.<br />
<br />
'''References'''<br />
<br />
* TODO<br />
<br />
== Other CPWE ==<br />
[[CPWE]]</div>Deleted userhttps://wiki.owasp.org/index.php?title=CPWE&diff=135796CPWE2012-09-13T18:30:59Z<p>Deleted user: /* Contributor Instructions */</p>
<hr />
<div>= Introduction =<br />
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. <br />
<br />
'''Example: '''Below is a notional example of reporting findings from some SwA program assessment using CPWE:<br />
<br />
'''Severe (3 Findings)'''<br />
CPWE-3: Failure to Address Verification Findings For Application X ''<-- This is an instance of a finding of type CPWE-3''<br />
CPWE-3: Failure to Address Verification Findings For Application Y ''<-- This is another instance of a finding of type CPWE-3''<br />
CPWE-12: Insufficient Program Resources For Project Z ''<-- This is an instance of a finding of type CPWE-12''<br />
'''High (xx Findings)'''<br />
...<br />
'''Moderate (xx Findings)'''<br />
'''Low (xx Findings)'''<br />
<br />
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.<br />
<br />
= Contributor Instructions =<br />
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. <br />
<br />
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.<br />
<br />
= Common Program Weakness Enumeration =<br />
The comprehensive CPWE dictionary view is below.<br />
<br />
[[CPWE-ID: 12|Insufficient Program Resources - (12)]]<br><br />
Organizational Culture Problems - (xx)<br><br />
Missing Policy - (xx)<br><br />
Missing Standards - (xx)<br><br />
Missing Solution Stack Guidance - (xx)<br><br />
Missing Secure Coding Standards - (xx)<br><br />
Missing Common Security Control Libraries - (xx)<br><br />
Inadequate Developer Training - (xx)<br><br />
Use of Insufficient Verification Technique - (xx)<br><br />
Failure to Address Verification Findings - (3)<br><br />
Failure to Protect Source Code from Theft - (xx)<br><br />
Failure to Protect Sensitive Application Data from Theft - (xx)<br><br />
Failure to Track Security Bugs - (xx)<br><br />
Failure to Address Implicit Contractual Requirements - (xx)<br><br />
Failure to Address Explicit Contractual Requirements - (xx)<br><br />
Risky Internal Integration - (xx)<br><br />
Risky Vendor Integration - (xx)<br><br />
Broken or Risky Platform - (xx)<br><br />
Broken or Risky Service - (xx)<br><br />
Weaknesses that Affect SDLC Initiation Phase - (xx)<br><br />
Weaknesses that Affect SDLC Development/Acquisition Phase - (xx)<br><br />
Weaknesses that Affect SDLC Implementation/Assessment Phase - (xx)<br><br />
Weaknesses that Affect SDLC Maintenance Phase - (xx)<br><br />
Weaknesses that Affect SDLC Disposal Phase - (xx)<br><br />
Supply Chain Issues - (xx)<br><br />
Service-Oriented Architecture Issues - (xx)<br><br />
Reusable Security Module Issues - (xx)<br><br />
Cross-Organizational Solution Issues - (xx)<br><br />
Migration Issues - (xx)<br><br />
Data Center or Development Facility Issues - (xx)<br><br />
Virtualization Issues - (xx)<br><br />
Regulatory Cybersecurity Risk Disclosure Obligation Issues - (xx)<br><br />
Regulatory Cyber Incident Disclosure Obligation Issues - (xx)<br><br />
Weaknesses in In-House Applications - (xx)<br><br />
Weaknesses in In-House Mobile Applications - (xx)<br><br />
Weaknesses in In-House App Store - (xx)<br><br />
Weaknesses in Vendor Applications - (xx)<br><br />
Weaknesses in Vendor Mobile Applications - (xx)<br><br />
Weaknesses in Vendor App Store - (xx)<br><br />
Weaknesses in In-House Verification Services - (xx)<br><br />
Weaknesses in Vendor Verification Services - (xx)<br><br />
... - (xx)<br><br />
<br />
= Authors and Primary Editors =<br />
<br />
Mike Boberski - boberski_michael [at] bah.com<br />
<br />
= Other Cheatsheets =<br />
{{Cheatsheet_Navigation}}<br />
<br />
[[Category:Cheatsheets]]</div>Deleted userhttps://wiki.owasp.org/index.php?title=CPWE&diff=135795CPWE2012-09-13T18:18:52Z<p>Deleted user: /* Introduction */</p>
<hr />
<div>= Introduction =<br />
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. <br />
<br />
'''Example: '''Below is a notional example of reporting findings from some SwA program assessment using CPWE:<br />
<br />
'''Severe (3 Findings)'''<br />
CPWE-3: Failure to Address Verification Findings For Application X ''<-- This is an instance of a finding of type CPWE-3''<br />
CPWE-3: Failure to Address Verification Findings For Application Y ''<-- This is another instance of a finding of type CPWE-3''<br />
CPWE-12: Insufficient Program Resources For Project Z ''<-- This is an instance of a finding of type CPWE-12''<br />
'''High (xx Findings)'''<br />
...<br />
'''Moderate (xx Findings)'''<br />
'''Low (xx Findings)'''<br />
<br />
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.<br />
<br />
= Contributor Instructions =<br />
First, thank you for considering contributing. <br />
<br />
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. <br />
<br />
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.<br />
<br />
= Common Program Weakness Enumeration =<br />
The comprehensive CPWE dictionary view is below.<br />
<br />
[[CPWE-ID: 12|Insufficient Program Resources - (12)]]<br><br />
Organizational Culture Problems - (xx)<br><br />
Missing Policy - (xx)<br><br />
Missing Standards - (xx)<br><br />
Missing Solution Stack Guidance - (xx)<br><br />
Missing Secure Coding Standards - (xx)<br><br />
Missing Common Security Control Libraries - (xx)<br><br />
Inadequate Developer Training - (xx)<br><br />
Use of Insufficient Verification Technique - (xx)<br><br />
Failure to Address Verification Findings - (3)<br><br />
Failure to Protect Source Code from Theft - (xx)<br><br />
Failure to Protect Sensitive Application Data from Theft - (xx)<br><br />
Failure to Track Security Bugs - (xx)<br><br />
Failure to Address Implicit Contractual Requirements - (xx)<br><br />
Failure to Address Explicit Contractual Requirements - (xx)<br><br />
Risky Internal Integration - (xx)<br><br />
Risky Vendor Integration - (xx)<br><br />
Broken or Risky Platform - (xx)<br><br />
Broken or Risky Service - (xx)<br><br />
Weaknesses that Affect SDLC Initiation Phase - (xx)<br><br />
Weaknesses that Affect SDLC Development/Acquisition Phase - (xx)<br><br />
Weaknesses that Affect SDLC Implementation/Assessment Phase - (xx)<br><br />
Weaknesses that Affect SDLC Maintenance Phase - (xx)<br><br />
Weaknesses that Affect SDLC Disposal Phase - (xx)<br><br />
Supply Chain Issues - (xx)<br><br />
Service-Oriented Architecture Issues - (xx)<br><br />
Reusable Security Module Issues - (xx)<br><br />
Cross-Organizational Solution Issues - (xx)<br><br />
Migration Issues - (xx)<br><br />
Data Center or Development Facility Issues - (xx)<br><br />
Virtualization Issues - (xx)<br><br />
Regulatory Cybersecurity Risk Disclosure Obligation Issues - (xx)<br><br />
Regulatory Cyber Incident Disclosure Obligation Issues - (xx)<br><br />
Weaknesses in In-House Applications - (xx)<br><br />
Weaknesses in In-House Mobile Applications - (xx)<br><br />
Weaknesses in In-House App Store - (xx)<br><br />
Weaknesses in Vendor Applications - (xx)<br><br />
Weaknesses in Vendor Mobile Applications - (xx)<br><br />
Weaknesses in Vendor App Store - (xx)<br><br />
Weaknesses in In-House Verification Services - (xx)<br><br />
Weaknesses in Vendor Verification Services - (xx)<br><br />
... - (xx)<br><br />
<br />
= Authors and Primary Editors =<br />
<br />
Mike Boberski - boberski_michael [at] bah.com<br />
<br />
= Other Cheatsheets =<br />
{{Cheatsheet_Navigation}}<br />
<br />
[[Category:Cheatsheets]]</div>Deleted userhttps://wiki.owasp.org/index.php?title=CPWE&diff=135794CPWE2012-09-13T18:15:46Z<p>Deleted user: /* Introduction */</p>
<hr />
<div>= Introduction =<br />
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. <br />
<br />
'''Example: '''Below is a notional example of reporting findings from some SwA program assessment using CPWE:<br />
<br />
'''Severe (3 Findings)'''<br />
CPWE-3: Failure to Address Verification Findings For Application X ''<-- This is an instance of a finding of type CPWE-3''<br />
CPWE-3: Failure to Address Verification Findings For Application Y ''<-- This is another instance of a finding of type CPWE-3''<br />
CPWE-12: Insufficient Program Resources For SwA Program For Project Z ''<-- This is an instance of a finding of type CPWE-12''<br />
'''High (xx Findings)'''<br />
...<br />
'''Moderate (xx Findings)'''<br />
'''Low (xx Findings)'''<br />
<br />
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.<br />
<br />
= Contributor Instructions =<br />
First, thank you for considering contributing. <br />
<br />
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. <br />
<br />
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.<br />
<br />
= Common Program Weakness Enumeration =<br />
The comprehensive CPWE dictionary view is below.<br />
<br />
[[CPWE-ID: 12|Insufficient Program Resources - (12)]]<br><br />
Organizational Culture Problems - (xx)<br><br />
Missing Policy - (xx)<br><br />
Missing Standards - (xx)<br><br />
Missing Solution Stack Guidance - (xx)<br><br />
Missing Secure Coding Standards - (xx)<br><br />
Missing Common Security Control Libraries - (xx)<br><br />
Inadequate Developer Training - (xx)<br><br />
Use of Insufficient Verification Technique - (xx)<br><br />
Failure to Address Verification Findings - (3)<br><br />
Failure to Protect Source Code from Theft - (xx)<br><br />
Failure to Protect Sensitive Application Data from Theft - (xx)<br><br />
Failure to Track Security Bugs - (xx)<br><br />
Failure to Address Implicit Contractual Requirements - (xx)<br><br />
Failure to Address Explicit Contractual Requirements - (xx)<br><br />
Risky Internal Integration - (xx)<br><br />
Risky Vendor Integration - (xx)<br><br />
Broken or Risky Platform - (xx)<br><br />
Broken or Risky Service - (xx)<br><br />
Weaknesses that Affect SDLC Initiation Phase - (xx)<br><br />
Weaknesses that Affect SDLC Development/Acquisition Phase - (xx)<br><br />
Weaknesses that Affect SDLC Implementation/Assessment Phase - (xx)<br><br />
Weaknesses that Affect SDLC Maintenance Phase - (xx)<br><br />
Weaknesses that Affect SDLC Disposal Phase - (xx)<br><br />
Supply Chain Issues - (xx)<br><br />
Service-Oriented Architecture Issues - (xx)<br><br />
Reusable Security Module Issues - (xx)<br><br />
Cross-Organizational Solution Issues - (xx)<br><br />
Migration Issues - (xx)<br><br />
Data Center or Development Facility Issues - (xx)<br><br />
Virtualization Issues - (xx)<br><br />
Regulatory Cybersecurity Risk Disclosure Obligation Issues - (xx)<br><br />
Regulatory Cyber Incident Disclosure Obligation Issues - (xx)<br><br />
Weaknesses in In-House Applications - (xx)<br><br />
Weaknesses in In-House Mobile Applications - (xx)<br><br />
Weaknesses in In-House App Store - (xx)<br><br />
Weaknesses in Vendor Applications - (xx)<br><br />
Weaknesses in Vendor Mobile Applications - (xx)<br><br />
Weaknesses in Vendor App Store - (xx)<br><br />
Weaknesses in In-House Verification Services - (xx)<br><br />
Weaknesses in Vendor Verification Services - (xx)<br><br />
... - (xx)<br><br />
<br />
= Authors and Primary Editors =<br />
<br />
Mike Boberski - boberski_michael [at] bah.com<br />
<br />
= Other Cheatsheets =<br />
{{Cheatsheet_Navigation}}<br />
<br />
[[Category:Cheatsheets]]</div>Deleted userhttps://wiki.owasp.org/index.php?title=CPWE&diff=135793CPWE2012-09-13T18:12:59Z<p>Deleted user: /* Introduction */</p>
<hr />
<div>= Introduction =<br />
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. <br />
<br />
'''Example: '''Below is a notional example of reporting findings from some SwA program assessment using CPWE:<br />
<br />
'''Severe (3 Findings)'''<br />
CPWE-3: Failure to Address Verification Findings For Application X ''<-- This is an instance of a finding of type CPWE-3''<br />
CPWE-3: Failure to Address Verification Findings For Application Y ''<-- This is another instance of a finding of type CPWE-3''<br />
CPWE-12: Insufficient Program Resources For SwA Program For Project Z ''<-- This is an instance of a finding of type CPWE-12''<br />
'''High (xx Findings)'''<br />
...<br />
'''Moderate (xx Findings)'''<br />
'''Low (xx Findings)'''<br />
<br />
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), perhaps also turning this into its own separate project if interest/activity warrants.<br />
<br />
= Contributor Instructions =<br />
First, thank you for considering contributing. <br />
<br />
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. <br />
<br />
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.<br />
<br />
= Common Program Weakness Enumeration =<br />
The comprehensive CPWE dictionary view is below.<br />
<br />
[[CPWE-ID: 12|Insufficient Program Resources - (12)]]<br><br />
Organizational Culture Problems - (xx)<br><br />
Missing Policy - (xx)<br><br />
Missing Standards - (xx)<br><br />
Missing Solution Stack Guidance - (xx)<br><br />
Missing Secure Coding Standards - (xx)<br><br />
Missing Common Security Control Libraries - (xx)<br><br />
Inadequate Developer Training - (xx)<br><br />
Use of Insufficient Verification Technique - (xx)<br><br />
Failure to Address Verification Findings - (3)<br><br />
Failure to Protect Source Code from Theft - (xx)<br><br />
Failure to Protect Sensitive Application Data from Theft - (xx)<br><br />
Failure to Track Security Bugs - (xx)<br><br />
Failure to Address Implicit Contractual Requirements - (xx)<br><br />
Failure to Address Explicit Contractual Requirements - (xx)<br><br />
Risky Internal Integration - (xx)<br><br />
Risky Vendor Integration - (xx)<br><br />
Broken or Risky Platform - (xx)<br><br />
Broken or Risky Service - (xx)<br><br />
Weaknesses that Affect SDLC Initiation Phase - (xx)<br><br />
Weaknesses that Affect SDLC Development/Acquisition Phase - (xx)<br><br />
Weaknesses that Affect SDLC Implementation/Assessment Phase - (xx)<br><br />
Weaknesses that Affect SDLC Maintenance Phase - (xx)<br><br />
Weaknesses that Affect SDLC Disposal Phase - (xx)<br><br />
Supply Chain Issues - (xx)<br><br />
Service-Oriented Architecture Issues - (xx)<br><br />
Reusable Security Module Issues - (xx)<br><br />
Cross-Organizational Solution Issues - (xx)<br><br />
Migration Issues - (xx)<br><br />
Data Center or Development Facility Issues - (xx)<br><br />
Virtualization Issues - (xx)<br><br />
Regulatory Cybersecurity Risk Disclosure Obligation Issues - (xx)<br><br />
Regulatory Cyber Incident Disclosure Obligation Issues - (xx)<br><br />
Weaknesses in In-House Applications - (xx)<br><br />
Weaknesses in In-House Mobile Applications - (xx)<br><br />
Weaknesses in In-House App Store - (xx)<br><br />
Weaknesses in Vendor Applications - (xx)<br><br />
Weaknesses in Vendor Mobile Applications - (xx)<br><br />
Weaknesses in Vendor App Store - (xx)<br><br />
Weaknesses in In-House Verification Services - (xx)<br><br />
Weaknesses in Vendor Verification Services - (xx)<br><br />
... - (xx)<br><br />
<br />
= Authors and Primary Editors =<br />
<br />
Mike Boberski - boberski_michael [at] bah.com<br />
<br />
= Other Cheatsheets =<br />
{{Cheatsheet_Navigation}}<br />
<br />
[[Category:Cheatsheets]]</div>Deleted userhttps://wiki.owasp.org/index.php?title=CPWE&diff=135792CPWE2012-09-13T18:01:41Z<p>Deleted user: /* Common Program Weakness Enumeration */</p>
<hr />
<div>= Introduction =<br />
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. <br />
<br />
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 a BSIMM, or a less formal assessment) done, and the findings are mapped to CPWE-ID. <br />
<br />
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. In this example, regardless if SAMM or BSIMM or a less formal assessment was done. <br />
<br />
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), perhaps also turning this into its own separate project if interest/activity warrants.<br />
<br />
= Contributor Instructions =<br />
First, thank you for considering contributing. <br />
<br />
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. <br />
<br />
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.<br />
<br />
= Common Program Weakness Enumeration =<br />
The comprehensive CPWE dictionary view is below.<br />
<br />
[[CPWE-ID: 12|Insufficient Program Resources - (12)]]<br><br />
Organizational Culture Problems - (xx)<br><br />
Missing Policy - (xx)<br><br />
Missing Standards - (xx)<br><br />
Missing Solution Stack Guidance - (xx)<br><br />
Missing Secure Coding Standards - (xx)<br><br />
Missing Common Security Control Libraries - (xx)<br><br />
Inadequate Developer Training - (xx)<br><br />
Use of Insufficient Verification Technique - (xx)<br><br />
Failure to Address Verification Findings - (3)<br><br />
Failure to Protect Source Code from Theft - (xx)<br><br />
Failure to Protect Sensitive Application Data from Theft - (xx)<br><br />
Failure to Track Security Bugs - (xx)<br><br />
Failure to Address Implicit Contractual Requirements - (xx)<br><br />
Failure to Address Explicit Contractual Requirements - (xx)<br><br />
Risky Internal Integration - (xx)<br><br />
Risky Vendor Integration - (xx)<br><br />
Broken or Risky Platform - (xx)<br><br />
Broken or Risky Service - (xx)<br><br />
Weaknesses that Affect SDLC Initiation Phase - (xx)<br><br />
Weaknesses that Affect SDLC Development/Acquisition Phase - (xx)<br><br />
Weaknesses that Affect SDLC Implementation/Assessment Phase - (xx)<br><br />
Weaknesses that Affect SDLC Maintenance Phase - (xx)<br><br />
Weaknesses that Affect SDLC Disposal Phase - (xx)<br><br />
Supply Chain Issues - (xx)<br><br />
Service-Oriented Architecture Issues - (xx)<br><br />
Reusable Security Module Issues - (xx)<br><br />
Cross-Organizational Solution Issues - (xx)<br><br />
Migration Issues - (xx)<br><br />
Data Center or Development Facility Issues - (xx)<br><br />
Virtualization Issues - (xx)<br><br />
Regulatory Cybersecurity Risk Disclosure Obligation Issues - (xx)<br><br />
Regulatory Cyber Incident Disclosure Obligation Issues - (xx)<br><br />
Weaknesses in In-House Applications - (xx)<br><br />
Weaknesses in In-House Mobile Applications - (xx)<br><br />
Weaknesses in In-House App Store - (xx)<br><br />
Weaknesses in Vendor Applications - (xx)<br><br />
Weaknesses in Vendor Mobile Applications - (xx)<br><br />
Weaknesses in Vendor App Store - (xx)<br><br />
Weaknesses in In-House Verification Services - (xx)<br><br />
Weaknesses in Vendor Verification Services - (xx)<br><br />
... - (xx)<br><br />
<br />
= Authors and Primary Editors =<br />
<br />
Mike Boberski - boberski_michael [at] bah.com<br />
<br />
= Other Cheatsheets =<br />
{{Cheatsheet_Navigation}}<br />
<br />
[[Category:Cheatsheets]]</div>Deleted userhttps://wiki.owasp.org/index.php?title=CPWE&diff=135788CPWE2012-09-13T17:52:01Z<p>Deleted user: /* Introduction */</p>
<hr />
<div>= Introduction =<br />
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. <br />
<br />
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 a BSIMM, or a less formal assessment) done, and the findings are mapped to CPWE-ID. <br />
<br />
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. In this example, regardless if SAMM or BSIMM or a less formal assessment was done. <br />
<br />
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), perhaps also turning this into its own separate project if interest/activity warrants.<br />
<br />
= Contributor Instructions =<br />
First, thank you for considering contributing. <br />
<br />
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. <br />
<br />
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.<br />
<br />
= Common Program Weakness Enumeration =<br />
The comprehensive CPWE dictionary view is below.<br />
<br />
[[CPWE-ID: 12|Insufficient Program Resources - (12)]]<br><br />
Organizational Culture Problems - (xx)<br><br />
Missing Policy - (xx)<br><br />
Missing Standards - (xx)<br><br />
Missing Solution Stack Guidance - (xx)<br><br />
Missing Secure Coding Standards - (xx)<br><br />
Missing Common Security Control Libraries - (xx)<br><br />
Inadequate Developer Training - (xx)<br><br />
Use of Insufficient Verification Technique - (xx)<br><br />
Failure to Address Verification Findings - (xx)<br><br />
Failure to Protect Source Code from Theft - (xx)<br><br />
Failure to Protect Sensitive Application Data from Theft - (xx)<br><br />
Failure to Track Security Bugs - (xx)<br><br />
Failure to Address Implicit Contractual Requirements - (xx)<br><br />
Failure to Address Explicit Contractual Requirements - (xx)<br><br />
Risky Internal Integration - (xx)<br><br />
Risky Vendor Integration - (xx)<br><br />
Broken or Risky Platform - (xx)<br><br />
Broken or Risky Service - (xx)<br><br />
Weaknesses that Affect SDLC Initiation Phase - (xx)<br><br />
Weaknesses that Affect SDLC Development/Acquisition Phase - (xx)<br><br />
Weaknesses that Affect SDLC Implementation/Assessment Phase - (xx)<br><br />
Weaknesses that Affect SDLC Maintenance Phase - (xx)<br><br />
Weaknesses that Affect SDLC Disposal Phase - (xx)<br><br />
Supply Chain Issues - (xx)<br><br />
Service-Oriented Architecture Issues - (xx)<br><br />
Reusable Security Module Issues - (xx)<br><br />
Cross-Organizational Solution Issues - (xx)<br><br />
Migration Issues - (xx)<br><br />
Data Center or Development Facility Issues - (xx)<br><br />
Virtualization Issues - (xx)<br><br />
Regulatory Cybersecurity Risk Disclosure Obligation Issues - (xx)<br><br />
Regulatory Cyber Incident Disclosure Obligation Issues - (xx)<br><br />
Weaknesses in In-House Applications - (xx)<br><br />
Weaknesses in In-House Mobile Applications - (xx)<br><br />
Weaknesses in In-House App Store - (xx)<br><br />
Weaknesses in Vendor Applications - (xx)<br><br />
Weaknesses in Vendor Mobile Applications - (xx)<br><br />
Weaknesses in Vendor App Store - (xx)<br><br />
Weaknesses in In-House Verification Services - (xx)<br><br />
Weaknesses in Vendor Verification Services - (xx)<br><br />
... - (xx)<br><br />
<br />
= Authors and Primary Editors =<br />
<br />
Mike Boberski - boberski_michael [at] bah.com<br />
<br />
= Other Cheatsheets =<br />
{{Cheatsheet_Navigation}}<br />
<br />
[[Category:Cheatsheets]]</div>Deleted userhttps://wiki.owasp.org/index.php?title=CPWE&diff=135755CPWE2012-09-13T17:31:04Z<p>Deleted user: </p>
<hr />
<div>= Introduction =<br />
This OWASP initiative for [http://en.wikipedia.org/wiki/Chief_information_security_officer 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 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. <br />
<br />
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 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. In this example, regardless if SAMM or BSIMM or a less formal assessment was done. <br />
<br />
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), perhaps also turning this into its own separate project if interest/activity warrants.<br />
<br />
= Contributor Instructions =<br />
First, thank you for considering contributing. <br />
<br />
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. <br />
<br />
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.<br />
<br />
= Common Program Weakness Enumeration =<br />
The comprehensive CPWE dictionary view is below.<br />
<br />
[[CPWE-ID: 12|Insufficient Program Resources - (12)]]<br><br />
Organizational Culture Problems - (xx)<br><br />
Missing Policy - (xx)<br><br />
Missing Standards - (xx)<br><br />
Missing Solution Stack Guidance - (xx)<br><br />
Missing Secure Coding Standards - (xx)<br><br />
Missing Common Security Control Libraries - (xx)<br><br />
Inadequate Developer Training - (xx)<br><br />
Use of Insufficient Verification Technique - (xx)<br><br />
Failure to Address Verification Findings - (xx)<br><br />
Failure to Protect Source Code from Theft - (xx)<br><br />
Failure to Protect Sensitive Application Data from Theft - (xx)<br><br />
Failure to Track Security Bugs - (xx)<br><br />
Failure to Address Implicit Contractual Requirements - (xx)<br><br />
Failure to Address Explicit Contractual Requirements - (xx)<br><br />
Risky Internal Integration - (xx)<br><br />
Risky Vendor Integration - (xx)<br><br />
Broken or Risky Platform - (xx)<br><br />
Broken or Risky Service - (xx)<br><br />
Weaknesses that Affect SDLC Initiation Phase - (xx)<br><br />
Weaknesses that Affect SDLC Development/Acquisition Phase - (xx)<br><br />
Weaknesses that Affect SDLC Implementation/Assessment Phase - (xx)<br><br />
Weaknesses that Affect SDLC Maintenance Phase - (xx)<br><br />
Weaknesses that Affect SDLC Disposal Phase - (xx)<br><br />
Supply Chain Issues - (xx)<br><br />
Service-Oriented Architecture Issues - (xx)<br><br />
Reusable Security Module Issues - (xx)<br><br />
Cross-Organizational Solution Issues - (xx)<br><br />
Migration Issues - (xx)<br><br />
Data Center or Development Facility Issues - (xx)<br><br />
Virtualization Issues - (xx)<br><br />
Regulatory Cybersecurity Risk Disclosure Obligation Issues - (xx)<br><br />
Regulatory Cyber Incident Disclosure Obligation Issues - (xx)<br><br />
Weaknesses in In-House Applications - (xx)<br><br />
Weaknesses in In-House Mobile Applications - (xx)<br><br />
Weaknesses in In-House App Store - (xx)<br><br />
Weaknesses in Vendor Applications - (xx)<br><br />
Weaknesses in Vendor Mobile Applications - (xx)<br><br />
Weaknesses in Vendor App Store - (xx)<br><br />
Weaknesses in In-House Verification Services - (xx)<br><br />
Weaknesses in Vendor Verification Services - (xx)<br><br />
... - (xx)<br><br />
<br />
= Authors and Primary Editors =<br />
<br />
Mike Boberski - boberski_michael [at] bah.com<br />
<br />
= Other Cheatsheets =<br />
{{Cheatsheet_Navigation}}<br />
<br />
[[Category:Cheatsheets]]</div>Deleted userhttps://wiki.owasp.org/index.php?title=Template:Cheatsheet_Navigation&diff=135754Template:Cheatsheet Navigation2012-09-13T17:30:15Z<p>Deleted user: </p>
<hr />
<div>'''OWASP Cheat Sheets Project Homepage'''<br />
* [[Cheat Sheets]]<br />
<br />
'''Developer Cheat Sheets (Builder)'''<br />
* [[Authentication Cheat Sheet]]<br />
* [[Cross-Site Request Forgery (CSRF) Prevention Cheat Sheet]]<br />
* [[Cryptographic Storage Cheat Sheet]]<br />
* [[DOM based XSS Prevention Cheat Sheet]]<br />
* [[Forgot Password Cheat Sheet]]<br />
* [[HTML5 Security Cheat Sheet]]<br />
* [[Input Validation Cheat Sheet]]<br />
* [[JAAS Cheat Sheet]]<br />
* [[Logging Cheat Sheet]]<br />
* [[OWASP Top Ten Cheat Sheet]]<br />
* [[Query Parameterization Cheat Sheet]]<br />
* [[Session Management Cheat Sheet]]<br />
* [[SQL Injection Prevention Cheat Sheet]]<br />
* [[Transport Layer Protection Cheat Sheet]]<br />
* [[Web Service Security Cheat Sheet]]<br />
* [[XSS (Cross Site Scripting) Prevention Cheat Sheet]]<br />
<br />
'''Assessment Cheat Sheets (Breaker)'''<br />
* [[Attack Surface Analysis Cheat Sheet]]<br />
<br />
'''Mobile Cheat Sheets'''<br />
* [[IOS Developer Cheat Sheet]]<br />
* [[Mobile Jailbreaking Cheat Sheet]]<br />
<br />
'''Draft Cheat Sheets'''<br />
* [[XSS Filter Evasion Cheat Sheet]]<br />
* [[Abridged XSS Prevention Cheat Sheet]]<br />
* [[Access Control Cheat Sheet]]<br />
* [[Application Security Architecture Cheat Sheet]]<br />
* [[Clickjacking Cheat Sheet]]<br />
* [[Password Storage Cheat Sheet]]<br />
* [[PHP Security Cheat Sheet]]<br />
* [[REST Security Cheat Sheet]]<br />
* [[Secure Coding Cheat Sheet]]<br />
* [[Secure SDLC Cheat Sheet]]<br />
* [[Threat Modeling Cheat Sheet]]<br />
* [[Virtual Patching Cheat Sheet]]<br />
* [[Web Application Security Testing Cheat Sheet]]<br />
<br />
'''Related Resources'''<br />
* [[CPWE | Common Program Weakness Enumeration (CPWE)]]</div>Deleted userhttps://wiki.owasp.org/index.php?title=CPWE&diff=135752CPWE2012-09-13T17:29:18Z<p>Deleted user: moved CISO Cheat Sheet to CPWE</p>
<hr />
<div>= Introduction =<br />
This OWASP cheat sheet for [http://en.wikipedia.org/wiki/Chief_information_security_officer 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 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. So, it is not a traditional cheat sheet per se.<br />
<br />
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 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. In this example, regardless if SAMM or BSIMM or a less formal assessment was done. <br />
<br />
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), perhaps also turning this into its own separate project if interest/activity warrants.<br />
<br />
= Contributor Instructions =<br />
First, thank you for considering contributing. <br />
<br />
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. <br />
<br />
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.<br />
<br />
= Common Program Weakness Enumeration =<br />
The comprehensive CPWE dictionary view is below.<br />
<br />
[[CPWE-ID: 12|Insufficient Program Resources - (12)]]<br><br />
Organizational Culture Problems - (xx)<br><br />
Missing Policy - (xx)<br><br />
Missing Standards - (xx)<br><br />
Missing Solution Stack Guidance - (xx)<br><br />
Missing Secure Coding Standards - (xx)<br><br />
Missing Common Security Control Libraries - (xx)<br><br />
Inadequate Developer Training - (xx)<br><br />
Use of Insufficient Verification Technique - (xx)<br><br />
Failure to Address Verification Findings - (xx)<br><br />
Failure to Protect Source Code from Theft - (xx)<br><br />
Failure to Protect Sensitive Application Data from Theft - (xx)<br><br />
Failure to Track Security Bugs - (xx)<br><br />
Failure to Address Implicit Contractual Requirements - (xx)<br><br />
Failure to Address Explicit Contractual Requirements - (xx)<br><br />
Risky Internal Integration - (xx)<br><br />
Risky Vendor Integration - (xx)<br><br />
Broken or Risky Platform - (xx)<br><br />
Broken or Risky Service - (xx)<br><br />
Weaknesses that Affect SDLC Initiation Phase - (xx)<br><br />
Weaknesses that Affect SDLC Development/Acquisition Phase - (xx)<br><br />
Weaknesses that Affect SDLC Implementation/Assessment Phase - (xx)<br><br />
Weaknesses that Affect SDLC Maintenance Phase - (xx)<br><br />
Weaknesses that Affect SDLC Disposal Phase - (xx)<br><br />
Supply Chain Issues - (xx)<br><br />
Service-Oriented Architecture Issues - (xx)<br><br />
Reusable Security Module Issues - (xx)<br><br />
Cross-Organizational Solution Issues - (xx)<br><br />
Migration Issues - (xx)<br><br />
Data Center or Development Facility Issues - (xx)<br><br />
Virtualization Issues - (xx)<br><br />
Regulatory Cybersecurity Risk Disclosure Obligation Issues - (xx)<br><br />
Regulatory Cyber Incident Disclosure Obligation Issues - (xx)<br><br />
Weaknesses in In-House Applications - (xx)<br><br />
Weaknesses in In-House Mobile Applications - (xx)<br><br />
Weaknesses in In-House App Store - (xx)<br><br />
Weaknesses in Vendor Applications - (xx)<br><br />
Weaknesses in Vendor Mobile Applications - (xx)<br><br />
Weaknesses in Vendor App Store - (xx)<br><br />
Weaknesses in In-House Verification Services - (xx)<br><br />
Weaknesses in Vendor Verification Services - (xx)<br><br />
... - (xx)<br><br />
<br />
= Authors and Primary Editors =<br />
<br />
Mike Boberski - boberski_michael [at] bah.com<br />
<br />
= Other Cheatsheets =<br />
{{Cheatsheet_Navigation}}<br />
<br />
[[Category:Cheatsheets]]</div>Deleted userhttps://wiki.owasp.org/index.php?title=CISO_Cheat_Sheet&diff=135753CISO Cheat Sheet2012-09-13T17:29:18Z<p>Deleted user: moved CISO Cheat Sheet to CPWE</p>
<hr />
<div>#REDIRECT [[CPWE]]</div>Deleted userhttps://wiki.owasp.org/index.php?title=CPWE&diff=135502CPWE2012-09-09T03:13:39Z<p>Deleted user: /* Introduction */</p>
<hr />
<div>= Introduction =<br />
This OWASP cheat sheet for [http://en.wikipedia.org/wiki/Chief_information_security_officer 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 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. So, it is not a traditional cheat sheet per se.<br />
<br />
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 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. In this example, regardless if SAMM or BSIMM or a less formal assessment was done. <br />
<br />
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), perhaps also turning this into its own separate project if interest/activity warrants.<br />
<br />
= Contributor Instructions =<br />
First, thank you for considering contributing. <br />
<br />
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. <br />
<br />
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.<br />
<br />
= Common Program Weakness Enumeration =<br />
The comprehensive CPWE dictionary view is below.<br />
<br />
[[CPWE-ID: 12|Insufficient Program Resources - (12)]]<br><br />
Organizational Culture Problems - (xx)<br><br />
Missing Policy - (xx)<br><br />
Missing Standards - (xx)<br><br />
Missing Solution Stack Guidance - (xx)<br><br />
Missing Secure Coding Standards - (xx)<br><br />
Missing Common Security Control Libraries - (xx)<br><br />
Inadequate Developer Training - (xx)<br><br />
Use of Insufficient Verification Technique - (xx)<br><br />
Failure to Address Verification Findings - (xx)<br><br />
Failure to Protect Source Code from Theft - (xx)<br><br />
Failure to Protect Sensitive Application Data from Theft - (xx)<br><br />
Failure to Track Security Bugs - (xx)<br><br />
Failure to Address Implicit Contractual Requirements - (xx)<br><br />
Failure to Address Explicit Contractual Requirements - (xx)<br><br />
Risky Internal Integration - (xx)<br><br />
Risky Vendor Integration - (xx)<br><br />
Broken or Risky Platform - (xx)<br><br />
Broken or Risky Service - (xx)<br><br />
Weaknesses that Affect SDLC Initiation Phase - (xx)<br><br />
Weaknesses that Affect SDLC Development/Acquisition Phase - (xx)<br><br />
Weaknesses that Affect SDLC Implementation/Assessment Phase - (xx)<br><br />
Weaknesses that Affect SDLC Maintenance Phase - (xx)<br><br />
Weaknesses that Affect SDLC Disposal Phase - (xx)<br><br />
Supply Chain Issues - (xx)<br><br />
Service-Oriented Architecture Issues - (xx)<br><br />
Reusable Security Module Issues - (xx)<br><br />
Cross-Organizational Solution Issues - (xx)<br><br />
Migration Issues - (xx)<br><br />
Data Center or Development Facility Issues - (xx)<br><br />
Virtualization Issues - (xx)<br><br />
Regulatory Cybersecurity Risk Disclosure Obligation Issues - (xx)<br><br />
Regulatory Cyber Incident Disclosure Obligation Issues - (xx)<br><br />
Weaknesses in In-House Applications - (xx)<br><br />
Weaknesses in In-House Mobile Applications - (xx)<br><br />
Weaknesses in In-House App Store - (xx)<br><br />
Weaknesses in Vendor Applications - (xx)<br><br />
Weaknesses in Vendor Mobile Applications - (xx)<br><br />
Weaknesses in Vendor App Store - (xx)<br><br />
Weaknesses in In-House Verification Services - (xx)<br><br />
Weaknesses in Vendor Verification Services - (xx)<br><br />
... - (xx)<br><br />
<br />
= Authors and Primary Editors =<br />
<br />
Mike Boberski - boberski_michael [at] bah.com<br />
<br />
= Other Cheatsheets =<br />
{{Cheatsheet_Navigation}}<br />
<br />
[[Category:Cheatsheets]]</div>Deleted userhttps://wiki.owasp.org/index.php?title=CPWE&diff=135498CPWE2012-09-08T19:53:27Z<p>Deleted user: </p>
<hr />
<div>= Introduction =<br />
This OWASP cheat sheet for [http://en.wikipedia.org/wiki/Chief_information_security_officer 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 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. So, it is not a traditional cheat sheet per se.<br />
<br />
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 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. <br />
<br />
In this example, regardless if SAMM or BSIMM or a less formal assessment was done. 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), perhaps also turning this into its own separate project if interest/activity warrants.<br />
<br />
= Contributor Instructions =<br />
First, thank you for considering contributing. <br />
<br />
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. <br />
<br />
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.<br />
<br />
= Common Program Weakness Enumeration =<br />
The comprehensive CPWE dictionary view is below.<br />
<br />
[[CPWE-ID: 12|Insufficient Program Resources - (12)]]<br><br />
Organizational Culture Problems - (xx)<br><br />
Missing Policy - (xx)<br><br />
Missing Standards - (xx)<br><br />
Missing Solution Stack Guidance - (xx)<br><br />
Missing Secure Coding Standards - (xx)<br><br />
Missing Common Security Control Libraries - (xx)<br><br />
Inadequate Developer Training - (xx)<br><br />
Use of Insufficient Verification Technique - (xx)<br><br />
Failure to Address Verification Findings - (xx)<br><br />
Failure to Protect Source Code from Theft - (xx)<br><br />
Failure to Protect Sensitive Application Data from Theft - (xx)<br><br />
Failure to Track Security Bugs - (xx)<br><br />
Failure to Address Implicit Contractual Requirements - (xx)<br><br />
Failure to Address Explicit Contractual Requirements - (xx)<br><br />
Risky Internal Integration - (xx)<br><br />
Risky Vendor Integration - (xx)<br><br />
Broken or Risky Platform - (xx)<br><br />
Broken or Risky Service - (xx)<br><br />
Weaknesses that Affect SDLC Initiation Phase - (xx)<br><br />
Weaknesses that Affect SDLC Development/Acquisition Phase - (xx)<br><br />
Weaknesses that Affect SDLC Implementation/Assessment Phase - (xx)<br><br />
Weaknesses that Affect SDLC Maintenance Phase - (xx)<br><br />
Weaknesses that Affect SDLC Disposal Phase - (xx)<br><br />
Supply Chain Issues - (xx)<br><br />
Service-Oriented Architecture Issues - (xx)<br><br />
Reusable Security Module Issues - (xx)<br><br />
Cross-Organizational Solution Issues - (xx)<br><br />
Migration Issues - (xx)<br><br />
Data Center or Development Facility Issues - (xx)<br><br />
Virtualization Issues - (xx)<br><br />
Regulatory Cybersecurity Risk Disclosure Obligation Issues - (xx)<br><br />
Regulatory Cyber Incident Disclosure Obligation Issues - (xx)<br><br />
Weaknesses in In-House Applications - (xx)<br><br />
Weaknesses in In-House Mobile Applications - (xx)<br><br />
Weaknesses in In-House App Store - (xx)<br><br />
Weaknesses in Vendor Applications - (xx)<br><br />
Weaknesses in Vendor Mobile Applications - (xx)<br><br />
Weaknesses in Vendor App Store - (xx)<br><br />
Weaknesses in In-House Verification Services - (xx)<br><br />
Weaknesses in Vendor Verification Services - (xx)<br><br />
... - (xx)<br><br />
<br />
= Authors and Primary Editors =<br />
<br />
Mike Boberski - boberski_michael [at] bah.com<br />
<br />
= Other Cheatsheets =<br />
{{Cheatsheet_Navigation}}<br />
<br />
[[Category:Cheatsheets]]</div>Deleted userhttps://wiki.owasp.org/index.php?title=CPWE&diff=135181CPWE2012-09-01T01:49:55Z<p>Deleted user: /* Introduction */</p>
<hr />
<div>= Introduction =<br />
This OWASP cheat sheet for [http://en.wikipedia.org/wiki/Chief_information_security_officer 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 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. In this example, regardless if SAMM or BSIMM or a less formal assessment was done. 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), perhaps also turning this into its own separate project if interest/activity warrants.<br />
<br />
= Common Program Weakness Enumeration =<br />
The comprehensive CPWE dictionary view is below.<br />
<br />
[[CPWE-ID: 12|Insufficient Program Resources - (12)]]<br><br />
Organizational Culture Problems - (xx)<br><br />
Missing Policy - (xx)<br><br />
Missing Standards - (xx)<br><br />
Missing Solution Stack Guidance - (xx)<br><br />
Missing Secure Coding Standards - (xx)<br><br />
Missing Common Security Control Libraries - (xx)<br><br />
Inadequate Developer Training - (xx)<br><br />
Use of Insufficient Verification Technique - (xx)<br><br />
Failure to Address Verification Findings - (xx)<br><br />
Failure to Protect Source Code from Theft - (xx)<br><br />
Failure to Protect Sensitive Application Data from Theft - (xx)<br><br />
Failure to Track Security Bugs - (xx)<br><br />
Failure to Address Implicit Contractual Requirements - (xx)<br><br />
Failure to Address Explicit Contractual Requirements - (xx)<br><br />
Risky Internal Integration - (xx)<br><br />
Risky Vendor Integration - (xx)<br><br />
Broken or Risky Platform - (xx)<br><br />
Broken or Risky Service - (xx)<br><br />
Weaknesses that Affect SDLC Initiation Phase - (xx)<br><br />
Weaknesses that Affect SDLC Development/Acquisition Phase - (xx)<br><br />
Weaknesses that Affect SDLC Implementation/Assessment Phase - (xx)<br><br />
Weaknesses that Affect SDLC Maintenance Phase - (xx)<br><br />
Weaknesses that Affect SDLC Disposal Phase - (xx)<br><br />
Supply Chain Issues - (xx)<br><br />
Service-Oriented Architecture Issues - (xx)<br><br />
Reusable Security Module Issues - (xx)<br><br />
Cross-Organizational Solution Issues - (xx)<br><br />
Migration Issues - (xx)<br><br />
Data Center or Development Facility Issues - (xx)<br><br />
Virtualization Issues - (xx)<br><br />
Regulatory Cybersecurity Risk Disclosure Obligation Issues - (xx)<br><br />
Regulatory Cyber Incident Disclosure Obligation Issues - (xx)<br><br />
Weaknesses in In-House Applications - (xx)<br><br />
Weaknesses in In-House Mobile Applications - (xx)<br><br />
Weaknesses in In-House App Store - (xx)<br><br />
Weaknesses in Vendor Applications - (xx)<br><br />
Weaknesses in Vendor Mobile Applications - (xx)<br><br />
Weaknesses in Vendor App Store - (xx)<br><br />
Weaknesses in In-House Verification Services - (xx)<br><br />
Weaknesses in Vendor Verification Services - (xx)<br><br />
... - (xx)<br><br />
<br />
= Authors and Primary Editors =<br />
<br />
Mike Boberski - boberski_michael [at] bah.com<br />
<br />
= Other Cheatsheets =<br />
{{Cheatsheet_Navigation}}<br />
<br />
[[Category:Cheatsheets]]</div>Deleted userhttps://wiki.owasp.org/index.php?title=CPWE&diff=135153CPWE2012-08-30T23:51:35Z<p>Deleted user: /* Introduction */</p>
<hr />
<div>= Introduction =<br />
This OWASP cheat sheet for [http://en.wikipedia.org/wiki/Chief_information_security_officer 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 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. In this example, regardless if SAMM or BSIMM or a less formal assessment was done. 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".<br />
<br />
= Common Program Weakness Enumeration =<br />
The comprehensive CPWE dictionary view is below.<br />
<br />
[[CPWE-ID: 12|Insufficient Program Resources - (12)]]<br><br />
Organizational Culture Problems - (xx)<br><br />
Missing Policy - (xx)<br><br />
Missing Standards - (xx)<br><br />
Missing Solution Stack Guidance - (xx)<br><br />
Missing Secure Coding Standards - (xx)<br><br />
Missing Common Security Control Libraries - (xx)<br><br />
Inadequate Developer Training - (xx)<br><br />
Use of Insufficient Verification Technique - (xx)<br><br />
Failure to Address Verification Findings - (xx)<br><br />
Failure to Protect Source Code from Theft - (xx)<br><br />
Failure to Protect Sensitive Application Data from Theft - (xx)<br><br />
Failure to Track Security Bugs - (xx)<br><br />
Failure to Address Implicit Contractual Requirements - (xx)<br><br />
Failure to Address Explicit Contractual Requirements - (xx)<br><br />
Risky Internal Integration - (xx)<br><br />
Risky Vendor Integration - (xx)<br><br />
Broken or Risky Platform - (xx)<br><br />
Broken or Risky Service - (xx)<br><br />
Weaknesses that Affect SDLC Initiation Phase - (xx)<br><br />
Weaknesses that Affect SDLC Development/Acquisition Phase - (xx)<br><br />
Weaknesses that Affect SDLC Implementation/Assessment Phase - (xx)<br><br />
Weaknesses that Affect SDLC Maintenance Phase - (xx)<br><br />
Weaknesses that Affect SDLC Disposal Phase - (xx)<br><br />
Supply Chain Issues - (xx)<br><br />
Service-Oriented Architecture Issues - (xx)<br><br />
Reusable Security Module Issues - (xx)<br><br />
Cross-Organizational Solution Issues - (xx)<br><br />
Migration Issues - (xx)<br><br />
Data Center or Development Facility Issues - (xx)<br><br />
Virtualization Issues - (xx)<br><br />
Regulatory Cybersecurity Risk Disclosure Obligation Issues - (xx)<br><br />
Regulatory Cyber Incident Disclosure Obligation Issues - (xx)<br><br />
Weaknesses in In-House Applications - (xx)<br><br />
Weaknesses in In-House Mobile Applications - (xx)<br><br />
Weaknesses in In-House App Store - (xx)<br><br />
Weaknesses in Vendor Applications - (xx)<br><br />
Weaknesses in Vendor Mobile Applications - (xx)<br><br />
Weaknesses in Vendor App Store - (xx)<br><br />
Weaknesses in In-House Verification Services - (xx)<br><br />
Weaknesses in Vendor Verification Services - (xx)<br><br />
... - (xx)<br><br />
<br />
= Authors and Primary Editors =<br />
<br />
Mike Boberski - boberski_michael [at] bah.com<br />
<br />
= Other Cheatsheets =<br />
{{Cheatsheet_Navigation}}<br />
<br />
[[Category:Cheatsheets]]</div>Deleted userhttps://wiki.owasp.org/index.php?title=CPWE&diff=135144CPWE2012-08-30T20:53:41Z<p>Deleted user: /* Introduction */</p>
<hr />
<div>= Introduction =<br />
This OWASP cheat sheet for [http://en.wikipedia.org/wiki/Chief_information_security_officer 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 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. In this example, regardless if 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".<br />
<br />
= Common Program Weakness Enumeration =<br />
The comprehensive CPWE dictionary view is below.<br />
<br />
[[CPWE-ID: 12|Insufficient Program Resources - (12)]]<br><br />
Organizational Culture Problems - (xx)<br><br />
Missing Policy - (xx)<br><br />
Missing Standards - (xx)<br><br />
Missing Solution Stack Guidance - (xx)<br><br />
Missing Secure Coding Standards - (xx)<br><br />
Missing Common Security Control Libraries - (xx)<br><br />
Inadequate Developer Training - (xx)<br><br />
Use of Insufficient Verification Technique - (xx)<br><br />
Failure to Address Verification Findings - (xx)<br><br />
Failure to Protect Source Code from Theft - (xx)<br><br />
Failure to Protect Sensitive Application Data from Theft - (xx)<br><br />
Failure to Track Security Bugs - (xx)<br><br />
Failure to Address Implicit Contractual Requirements - (xx)<br><br />
Failure to Address Explicit Contractual Requirements - (xx)<br><br />
Risky Internal Integration - (xx)<br><br />
Risky Vendor Integration - (xx)<br><br />
Broken or Risky Platform - (xx)<br><br />
Broken or Risky Service - (xx)<br><br />
Weaknesses that Affect SDLC Initiation Phase - (xx)<br><br />
Weaknesses that Affect SDLC Development/Acquisition Phase - (xx)<br><br />
Weaknesses that Affect SDLC Implementation/Assessment Phase - (xx)<br><br />
Weaknesses that Affect SDLC Maintenance Phase - (xx)<br><br />
Weaknesses that Affect SDLC Disposal Phase - (xx)<br><br />
Supply Chain Issues - (xx)<br><br />
Service-Oriented Architecture Issues - (xx)<br><br />
Reusable Security Module Issues - (xx)<br><br />
Cross-Organizational Solution Issues - (xx)<br><br />
Migration Issues - (xx)<br><br />
Data Center or Development Facility Issues - (xx)<br><br />
Virtualization Issues - (xx)<br><br />
Regulatory Cybersecurity Risk Disclosure Obligation Issues - (xx)<br><br />
Regulatory Cyber Incident Disclosure Obligation Issues - (xx)<br><br />
Weaknesses in In-House Applications - (xx)<br><br />
Weaknesses in In-House Mobile Applications - (xx)<br><br />
Weaknesses in In-House App Store - (xx)<br><br />
Weaknesses in Vendor Applications - (xx)<br><br />
Weaknesses in Vendor Mobile Applications - (xx)<br><br />
Weaknesses in Vendor App Store - (xx)<br><br />
Weaknesses in In-House Verification Services - (xx)<br><br />
Weaknesses in Vendor Verification Services - (xx)<br><br />
... - (xx)<br><br />
<br />
= Authors and Primary Editors =<br />
<br />
Mike Boberski - boberski_michael [at] bah.com<br />
<br />
= Other Cheatsheets =<br />
{{Cheatsheet_Navigation}}<br />
<br />
[[Category:Cheatsheets]]</div>Deleted userhttps://wiki.owasp.org/index.php?title=CPWE-ID:_12&diff=135142CPWE-ID: 122012-08-30T20:46:23Z<p>Deleted user: /* Insufficient Program Resources */</p>
<hr />
<div>== Insufficient Program Resources ==<br />
'''Description'''<br />
* 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.<br />
<br />
'''Common Causes'''<br />
<br />
* This weakness typically occurs in situations where there is no executive-level application security evangelist.<br />
<br />
'''Common Consequences'''<br />
<br />
* ''Prior to a Cyber Incident -'' Delayed program adoption<br />
* ''During and After a Cyber Incident -'' Unknown business risk; impaired incident response<br />
<br />
'''Severity'''<br />
<br />
* ''Critical -'' This must be addressed immediately.<br />
<br />
'''References'''<br />
<br />
* TODO<br />
<br />
== Other CPWE ==<br />
[[CISO Cheat Sheet]]</div>Deleted userhttps://wiki.owasp.org/index.php?title=CPWE&diff=135141CPWE2012-08-30T20:45:39Z<p>Deleted user: /* Common Program Weakness Enumeration */</p>
<hr />
<div>= Introduction =<br />
This OWASP cheat sheet for [http://en.wikipedia.org/wiki/Chief_information_security_officer 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. In this example, regardless if 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".<br />
<br />
= Common Program Weakness Enumeration =<br />
The comprehensive CPWE dictionary view is below.<br />
<br />
[[CPWE-ID: 12|Insufficient Program Resources - (12)]]<br><br />
Organizational Culture Problems - (xx)<br><br />
Missing Policy - (xx)<br><br />
Missing Standards - (xx)<br><br />
Missing Solution Stack Guidance - (xx)<br><br />
Missing Secure Coding Standards - (xx)<br><br />
Missing Common Security Control Libraries - (xx)<br><br />
Inadequate Developer Training - (xx)<br><br />
Use of Insufficient Verification Technique - (xx)<br><br />
Failure to Address Verification Findings - (xx)<br><br />
Failure to Protect Source Code from Theft - (xx)<br><br />
Failure to Protect Sensitive Application Data from Theft - (xx)<br><br />
Failure to Track Security Bugs - (xx)<br><br />
Failure to Address Implicit Contractual Requirements - (xx)<br><br />
Failure to Address Explicit Contractual Requirements - (xx)<br><br />
Risky Internal Integration - (xx)<br><br />
Risky Vendor Integration - (xx)<br><br />
Broken or Risky Platform - (xx)<br><br />
Broken or Risky Service - (xx)<br><br />
Weaknesses that Affect SDLC Initiation Phase - (xx)<br><br />
Weaknesses that Affect SDLC Development/Acquisition Phase - (xx)<br><br />
Weaknesses that Affect SDLC Implementation/Assessment Phase - (xx)<br><br />
Weaknesses that Affect SDLC Maintenance Phase - (xx)<br><br />
Weaknesses that Affect SDLC Disposal Phase - (xx)<br><br />
Supply Chain Issues - (xx)<br><br />
Service-Oriented Architecture Issues - (xx)<br><br />
Reusable Security Module Issues - (xx)<br><br />
Cross-Organizational Solution Issues - (xx)<br><br />
Migration Issues - (xx)<br><br />
Data Center or Development Facility Issues - (xx)<br><br />
Virtualization Issues - (xx)<br><br />
Regulatory Cybersecurity Risk Disclosure Obligation Issues - (xx)<br><br />
Regulatory Cyber Incident Disclosure Obligation Issues - (xx)<br><br />
Weaknesses in In-House Applications - (xx)<br><br />
Weaknesses in In-House Mobile Applications - (xx)<br><br />
Weaknesses in In-House App Store - (xx)<br><br />
Weaknesses in Vendor Applications - (xx)<br><br />
Weaknesses in Vendor Mobile Applications - (xx)<br><br />
Weaknesses in Vendor App Store - (xx)<br><br />
Weaknesses in In-House Verification Services - (xx)<br><br />
Weaknesses in Vendor Verification Services - (xx)<br><br />
... - (xx)<br><br />
<br />
= Authors and Primary Editors =<br />
<br />
Mike Boberski - boberski_michael [at] bah.com<br />
<br />
= Other Cheatsheets =<br />
{{Cheatsheet_Navigation}}<br />
<br />
[[Category:Cheatsheets]]</div>Deleted userhttps://wiki.owasp.org/index.php?title=CPWE&diff=135140CPWE2012-08-30T20:36:07Z<p>Deleted user: /* Introduction */</p>
<hr />
<div>= Introduction =<br />
This OWASP cheat sheet for [http://en.wikipedia.org/wiki/Chief_information_security_officer 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. In this example, regardless if 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".<br />
<br />
= Common Program Weakness Enumeration =<br />
The comprehensive CPWE dictionary view is below.<br />
<br />
[[CPWE-ID: 12|Insufficient Program Resources - (12)]]<br><br />
Organizational Culture Problems - (xx)<br><br />
Missing Policy - (xx)<br><br />
Missing Standards - (xx)<br><br />
Missing Solution Stack Guidance - (xx)<br><br />
Missing Secure Coding Standards - (xx)<br><br />
Missing Common Security Control Libraries - (xx)<br><br />
Inadequate Developer Training - (xx)<br><br />
Use of Insufficient Verification Technique - (xx)<br><br />
Failure to Address Verification Findings - (xx)<br><br />
Failure to Protect Source Code from Theft - (xx)<br><br />
Failure to Protect Sensitive Application Data from Theft - (xx)<br><br />
Failure to Track Security Bugs - (xx)<br><br />
Failure to Address Implicit Contractual Requirements - (xx)<br><br />
Failure to Address Explicit Contractual Requirements - (xx)<br><br />
Risky Internal Integration - (xx)<br><br />
Risky Vendor Integration - (xx)<br><br />
Broken or Risky Platform - (xx)<br><br />
Broken or Risky Service - (xx)<br><br />
Weaknesses that Affect SDLC Initiation Phase - (xx)<br><br />
Weaknesses that Affect SDLC Development/Acquisition Phase - (xx)<br><br />
Weaknesses that Affect SDLC Implementation/Assessment Phase - (xx)<br><br />
Weaknesses that Affect SDLC Maintenance Phase - (xx)<br><br />
Weaknesses that Affect SDLC Disposal Phase - (xx)<br><br />
Regulatory Cybersecurity Risk Disclosure Obligation Issues - (xx)<br><br />
Regulatory Cyber Incident Disclosure Obligation Issues - (xx)<br><br />
Weaknesses in In-House Applications - (xx)<br><br />
Weaknesses in In-House Mobile Applications - (xx)<br><br />
Weaknesses in In-House App Store - (xx)<br><br />
Weaknesses in Vendor Applications - (xx)<br><br />
Weaknesses in Vendor Mobile Applications - (xx)<br><br />
Weaknesses in Vendor App Store - (xx)<br><br />
Weaknesses in In-House Verification Services - (xx)<br><br />
Weaknesses in Vendor Verification Services - (xx)<br><br />
... - (xx)<br><br />
<br />
= Authors and Primary Editors =<br />
<br />
Mike Boberski - boberski_michael [at] bah.com<br />
<br />
= Other Cheatsheets =<br />
{{Cheatsheet_Navigation}}<br />
<br />
[[Category:Cheatsheets]]</div>Deleted userhttps://wiki.owasp.org/index.php?title=CPWE&diff=135139CPWE2012-08-30T20:33:53Z<p>Deleted user: /* Common Program Weakness Enumeration */</p>
<hr />
<div>= Introduction =<br />
This OWASP cheat sheet for [http://en.wikipedia.org/wiki/Chief_information_security_officer 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".<br />
<br />
= Common Program Weakness Enumeration =<br />
The comprehensive CPWE dictionary view is below.<br />
<br />
[[CPWE-ID: 12|Insufficient Program Resources - (12)]]<br><br />
Organizational Culture Problems - (xx)<br><br />
Missing Policy - (xx)<br><br />
Missing Standards - (xx)<br><br />
Missing Solution Stack Guidance - (xx)<br><br />
Missing Secure Coding Standards - (xx)<br><br />
Missing Common Security Control Libraries - (xx)<br><br />
Inadequate Developer Training - (xx)<br><br />
Use of Insufficient Verification Technique - (xx)<br><br />
Failure to Address Verification Findings - (xx)<br><br />
Failure to Protect Source Code from Theft - (xx)<br><br />
Failure to Protect Sensitive Application Data from Theft - (xx)<br><br />
Failure to Track Security Bugs - (xx)<br><br />
Failure to Address Implicit Contractual Requirements - (xx)<br><br />
Failure to Address Explicit Contractual Requirements - (xx)<br><br />
Risky Internal Integration - (xx)<br><br />
Risky Vendor Integration - (xx)<br><br />
Broken or Risky Platform - (xx)<br><br />
Broken or Risky Service - (xx)<br><br />
Weaknesses that Affect SDLC Initiation Phase - (xx)<br><br />
Weaknesses that Affect SDLC Development/Acquisition Phase - (xx)<br><br />
Weaknesses that Affect SDLC Implementation/Assessment Phase - (xx)<br><br />
Weaknesses that Affect SDLC Maintenance Phase - (xx)<br><br />
Weaknesses that Affect SDLC Disposal Phase - (xx)<br><br />
Regulatory Cybersecurity Risk Disclosure Obligation Issues - (xx)<br><br />
Regulatory Cyber Incident Disclosure Obligation Issues - (xx)<br><br />
Weaknesses in In-House Applications - (xx)<br><br />
Weaknesses in In-House Mobile Applications - (xx)<br><br />
Weaknesses in In-House App Store - (xx)<br><br />
Weaknesses in Vendor Applications - (xx)<br><br />
Weaknesses in Vendor Mobile Applications - (xx)<br><br />
Weaknesses in Vendor App Store - (xx)<br><br />
Weaknesses in In-House Verification Services - (xx)<br><br />
Weaknesses in Vendor Verification Services - (xx)<br><br />
... - (xx)<br><br />
<br />
= Authors and Primary Editors =<br />
<br />
Mike Boberski - boberski_michael [at] bah.com<br />
<br />
= Other Cheatsheets =<br />
{{Cheatsheet_Navigation}}<br />
<br />
[[Category:Cheatsheets]]</div>Deleted userhttps://wiki.owasp.org/index.php?title=CPWE-ID:_12&diff=135138CPWE-ID: 122012-08-30T20:26:40Z<p>Deleted user: /* Insufficient Program Resources */</p>
<hr />
<div>== Insufficient Program Resources ==<br />
'''Description'''<br />
* 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.<br />
<br />
'''Common Causes'''<br />
<br />
* This weakness typically occurs in situations where there is no executive-level application security evangelist.<br />
<br />
'''Common Consequences'''<br />
<br />
* ''Prior to a Cyber Incident -'' Delayed program adoption<br />
* ''During and After a Cyber Incident -'' Unknown business risk; impaired incident response<br />
<br />
'''Severity'''<br />
<br />
* ''Critical -'' This must be addressed immediately.<br />
<br />
== Other CPWE ==<br />
[[CISO Cheat Sheet]]</div>Deleted userhttps://wiki.owasp.org/index.php?title=CPWE&diff=135137CPWE2012-08-30T20:24:32Z<p>Deleted user: /* Common Program Weakness Enumeration */</p>
<hr />
<div>= Introduction =<br />
This OWASP cheat sheet for [http://en.wikipedia.org/wiki/Chief_information_security_officer 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".<br />
<br />
= Common Program Weakness Enumeration =<br />
The comprehensive CPWE dictionary view is below.<br />
<br />
[[CPWE-ID: 12|Insufficient Program Resources - (12)]]<br><br />
Missing Policy - (xx)<br><br />
Missing Standards - (xx)<br><br />
Missing Solution Stack Guidance - (xx)<br><br />
Missing Secure Coding Standards - (xx)<br><br />
Missing Common Security Control Libraries - (xx)<br><br />
Inadequate Developer Training - (xx)<br><br />
Use of Insufficient Verification Technique - (xx)<br><br />
Failure to Address Verification Findings - (xx)<br><br />
Failure to Protect Source Code from Theft - (xx)<br><br />
Failure to Protect Sensitive Application Data from Theft - (xx)<br><br />
Failure to Track Security Bugs - (xx)<br><br />
Failure to Address Implicit Contractual Requirements - (xx)<br><br />
Failure to Address Explicit Contractual Requirements - (xx)<br><br />
Risky Internal Integration - (xx)<br><br />
Risky Vendor Integration - (xx)<br><br />
Broken or Risky Platform - (xx)<br><br />
Broken or Risky Service - (xx)<br><br />
Weaknesses that Affect SDLC Initiation Phase - (xx)<br><br />
Weaknesses that Affect SDLC Development/Acquisition Phase - (xx)<br><br />
Weaknesses that Affect SDLC Implementation/Assessment Phase - (xx)<br><br />
Weaknesses that Affect SDLC Maintenance Phase - (xx)<br><br />
Weaknesses that Affect SDLC Disposal Phase - (xx)<br><br />
Regulatory Cybersecurity Risk Disclosure Obligation Issues - (xx)<br><br />
Regulatory Cyber Incident Disclosure Obligation Issues - (xx)<br><br />
Weaknesses in In-House Applications - (xx)<br><br />
Weaknesses in In-House Mobile Applications - (xx)<br><br />
Weaknesses in In-House App Store - (xx)<br><br />
Weaknesses in Vendor Applications - (xx)<br><br />
Weaknesses in Vendor Mobile Applications - (xx)<br><br />
Weaknesses in Vendor App Store - (xx)<br><br />
Weaknesses in In-House Verification Services - (xx)<br><br />
Weaknesses in Vendor Verification Services - (xx)<br><br />
... - (xx)<br><br />
<br />
= Authors and Primary Editors =<br />
<br />
Mike Boberski - boberski_michael [at] bah.com<br />
<br />
= Other Cheatsheets =<br />
{{Cheatsheet_Navigation}}<br />
<br />
[[Category:Cheatsheets]]</div>Deleted userhttps://wiki.owasp.org/index.php?title=CPWE&diff=135135CPWE2012-08-30T20:17:19Z<p>Deleted user: /* Common Program Weakness Enumeration */</p>
<hr />
<div>= Introduction =<br />
This OWASP cheat sheet for [http://en.wikipedia.org/wiki/Chief_information_security_officer 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".<br />
<br />
= Common Program Weakness Enumeration =<br />
The comprehensive CPWE dictionary view is below.<br />
<br />
[[CPWE-ID: 12|Insufficient Program Resources - (12)]]<br><br />
Missing Policy - (xx)<br><br />
Missing Standards - (xx)<br><br />
Missing Solution Stack Guidance - (xx)<br><br />
Missing Secure Coding Standards - (xx)<br><br />
Missing Common Security Control Libraries - (xx)<br><br />
Inadequate Developer Training - (xx)<br><br />
Use of Insufficient Verification Technique - (xx)<br><br />
Failure to Address Verification Findings - (xx)<br><br />
Failure to Protect Source Code from Theft - (xx)<br><br />
Failure to Protect Sensitive Application Data from Theft - (xx)<br><br />
Failure to Track Security Bugs - (xx)<br><br />
Failure to Address Implicit Contractual Requirements - (xx)<br><br />
Failure to Address Explicit Contractual Requirements - (xx)<br><br />
Risky Internal Integration - (xx)<br><br />
Risky Vendor Integration - (xx)<br><br />
Broken or Risky Platform - (xx)<br><br />
Broken or Risky Service - (xx)<br><br />
Weaknesses that Affect SDLC Initiation Phase - (xx)<br><br />
Weaknesses that Affect SDLC Development/Acquisition Phase - (xx)<br><br />
Weaknesses that Affect SDLC Implementation/Assessment Phase - (xx)<br><br />
Weaknesses that Affect SDLC Maintenance Phase - (xx)<br><br />
Weaknesses that Affect SDLC Disposal Phase - (xx)<br><br />
Regulatory Cybersecurity Risk Disclosure Obligation Issues - (xx)<br><br />
Regulatory Cyber Incident Disclosure Obligation Issues - (xx)<br><br />
... - (xx)<br><br />
<br />
= Authors and Primary Editors =<br />
<br />
Mike Boberski - boberski_michael [at] bah.com<br />
<br />
= Other Cheatsheets =<br />
{{Cheatsheet_Navigation}}<br />
<br />
[[Category:Cheatsheets]]</div>Deleted userhttps://wiki.owasp.org/index.php?title=CPWE&diff=135134CPWE2012-08-30T20:12:58Z<p>Deleted user: /* Common Program Weakness Enumeration */</p>
<hr />
<div>= Introduction =<br />
This OWASP cheat sheet for [http://en.wikipedia.org/wiki/Chief_information_security_officer 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".<br />
<br />
= Common Program Weakness Enumeration =<br />
The comprehensive CPWE dictionary view is below.<br />
<br />
[[CPWE-ID: 12|Insufficient Program Resources - (12)]]<br><br />
Missing Policy - (xx)<br><br />
Missing Standards - (xx)<br><br />
Missing Solution Stack Guidance - (xx)<br><br />
Missing Secure Coding Standards - (xx)<br><br />
Missing Common Security Control Libraries - (xx)<br><br />
Inadequate Developer Training - (xx)<br><br />
Use of Insufficient Verification Technique - (xx)<br><br />
Failure to Protect Source Code from Theft - (xx)<br><br />
Failure to Protect Sensitive Application Data from Theft - (xx)<br><br />
Failure to Track Security Bugs - (xx)<br><br />
Failure to Address Implicit Contractual Requirements - (xx)<br><br />
Failure to Address Explicit Contractual Requirements - (xx)<br><br />
Risky Internal Integration - (xx)<br><br />
Risky Vendor Integration - (xx)<br><br />
Broken or Risky Platform - (xx)<br><br />
Broken or Risky Service - (xx)<br><br />
Weaknesses that Affect SDLC Initiation Phase - (xx)<br><br />
Weaknesses that Affect SDLC Development/Acquisition Phase - (xx)<br><br />
Weaknesses that Affect SDLC Implementation/Assessment Phase - (xx)<br><br />
Weaknesses that Affect SDLC Maintenance Phase - (xx)<br><br />
Weaknesses that Affect SDLC Disposal Phase - (xx)<br><br />
Regulatory Cybersecurity Risk Disclosure Obligation Issues - (xx)<br><br />
Regulatory Cyber Incident Disclosure Obligation Issues - (xx)<br><br />
... - (xx)<br><br />
<br />
= Authors and Primary Editors =<br />
<br />
Mike Boberski - boberski_michael [at] bah.com<br />
<br />
= Other Cheatsheets =<br />
{{Cheatsheet_Navigation}}<br />
<br />
[[Category:Cheatsheets]]</div>Deleted userhttps://wiki.owasp.org/index.php?title=CPWE&diff=135133CPWE2012-08-30T20:10:34Z<p>Deleted user: /* Common Program Weakness Enumeration */</p>
<hr />
<div>= Introduction =<br />
This OWASP cheat sheet for [http://en.wikipedia.org/wiki/Chief_information_security_officer 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".<br />
<br />
= Common Program Weakness Enumeration =<br />
The comprehensive CPWE dictionary view is below.<br />
<br />
[[CPWE-ID: 12|Insufficient Program Resources - (12)]]<br><br />
Missing Policy - (xx)<br><br />
Missing Standards - (xx)<br><br />
Missing Solution Stack Guidance - (xx)<br><br />
Missing Secure Coding Standards - (xx)<br><br />
Missing Common Security Control Libraries - (xx)<br><br />
Inadequate Developer Training - (xx)<br><br />
Failure to Protect Source Code from Theft - (xx)<br><br />
Failure to Protect Sensitive Application Data from Theft - (xx)<br><br />
Failure to Track Security Bugs - (xx)<br><br />
Failure to Address Implicit Contractual Requirements - (xx)<br><br />
Failure to Address Explicit Contractual Requirements - (xx)<br><br />
Risky Internal Integration - (xx)<br><br />
Risky Vendor Integration - (xx)<br><br />
Broken or Risky Platform - (xx)<br><br />
Broken or Risky Service - (xx)<br><br />
Weaknesses that Affect SDLC Initiation Phase - (xx)<br><br />
Weaknesses that Affect SDLC Development/Acquisition Phase - (xx)<br><br />
Weaknesses that Affect SDLC Implementation/Assessment Phase - (xx)<br><br />
Weaknesses that Affect SDLC Maintenance Phase - (xx)<br><br />
Weaknesses that Affect SDLC Disposal Phase - (xx)<br><br />
Regulatory Cybersecurity Risk Disclosure Obligation Issues - (xx)<br><br />
Regulatory Cyber Incident Disclosure Obligation Issues - (xx)<br><br />
... - (xx)<br><br />
<br />
= Authors and Primary Editors =<br />
<br />
Mike Boberski - boberski_michael [at] bah.com<br />
<br />
= Other Cheatsheets =<br />
{{Cheatsheet_Navigation}}<br />
<br />
[[Category:Cheatsheets]]</div>Deleted userhttps://wiki.owasp.org/index.php?title=CPWE&diff=135131CPWE2012-08-30T20:07:21Z<p>Deleted user: /* Common Program Weakness Enumeration */</p>
<hr />
<div>= Introduction =<br />
This OWASP cheat sheet for [http://en.wikipedia.org/wiki/Chief_information_security_officer 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".<br />
<br />
= Common Program Weakness Enumeration =<br />
The comprehensive CPWE dictionary view is below.<br />
<br />
[[CPWE-ID: 12|Insufficient Program Resources - (12)]]<br><br />
Missing Policy - (xx)<br><br />
Missing Standards - (xx)<br><br />
Missing Solution Stack Guidance - (xx)<br><br />
Missing Secure Coding Standards - (xx)<br><br />
Missing Common Security Control Libraries - (xx)<br><br />
Inadequate Developer Training - (xx)<br><br />
Failure to Protect Source Code from Theft - (xx)<br><br />
Failure to Protect Sensitive Application Data from Theft - (xx)<br><br />
Failure to Track Security Bugs - (xx)<br><br />
Failure to Address Implicit Contractual Requirements - (xx)<br><br />
Failure to Address Explicit Contractual Requirements - (xx)<br><br />
Risky Internal Integration - (xx)<br><br />
Risky Vendor Integration - (xx)<br><br />
Broken or Risky Platform - (xx)<br><br />
Broken or Risky Service - (xx)<br><br />
Weaknesses that Affect SDLC Initiation Phase - (xx)<br><br />
Weaknesses that Affect SDLC Development/Acquisition Phase - (xx)<br><br />
Weaknesses that Affect SDLC Implementation/Assessment Phase - (xx)<br><br />
Weaknesses that Affect SDLC Maintenance Phase - (xx)<br><br />
Weaknesses that Affect SDLC Disposal Phase - (xx)<br><br />
Potentially Impacts Regulatory Cybersecurity Risk Disclosure Obligations - (xx)<br><br />
Potentially Impacts Regulatory Cyber Incident Disclosure Obligations - (xx)<br><br />
... - (xx)<br><br />
<br />
= Authors and Primary Editors =<br />
<br />
Mike Boberski - boberski_michael [at] bah.com<br />
<br />
= Other Cheatsheets =<br />
{{Cheatsheet_Navigation}}<br />
<br />
[[Category:Cheatsheets]]</div>Deleted userhttps://wiki.owasp.org/index.php?title=CPWE&diff=135130CPWE2012-08-30T20:04:52Z<p>Deleted user: /* Common Program Weakness Enumeration */</p>
<hr />
<div>= Introduction =<br />
This OWASP cheat sheet for [http://en.wikipedia.org/wiki/Chief_information_security_officer 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".<br />
<br />
= Common Program Weakness Enumeration =<br />
The comprehensive CPWE dictionary view is below.<br />
<br />
[[CPWE-ID: 12|Insufficient Program Resources - (12)]]<br><br />
Missing Policy - (xx)<br><br />
Missing Standards - (xx)<br><br />
Missing Solution Stack Guidance - (xx)<br><br />
Missing Secure Coding Standards - (xx)<br><br />
Missing Common Security Control Libraries - (xx)<br><br />
Inadequate Developer Training - (xx)<br><br />
Failure to Protect Source Code from Theft - (xx)<br><br />
Failure to Protect Sensitive Application Data from Theft - (xx)<br><br />
Failure to Track Security Bugs - (xx)<br><br />
Failure to Address Implicit Contractual - (xx)<br><br />
Failure to Address Explicit Contractual Requirements - (xx)<br><br />
Risky Internal Integration - (xx)<br><br />
Risky Vendor Integration - (xx)<br><br />
Broken or Risky Platform - (xx)<br><br />
Broken or Risky Service - (xx)<br><br />
Weaknesses that Affect SDLC Initiation Phase - (xx)<br><br />
Weaknesses that Affect SDLC Development/Acquisition Phase - (xx)<br><br />
Weaknesses that Affect SDLC Implementation/Assessment Phase - (xx)<br><br />
Weaknesses that Affect SDLC Maintenance Phase - (xx)<br><br />
Weaknesses that Affect SDLC Disposal Phase - (xx)<br><br />
Potentially Impacts Regulatory Cybersecurity Risk Disclosure Obligations - (xx)<br><br />
Potentially Impacts Regulatory Cyber Incident Disclosure Obligations - (xx)<br><br />
... - (xx)<br><br />
<br />
= Authors and Primary Editors =<br />
<br />
Mike Boberski - boberski_michael [at] bah.com<br />
<br />
= Other Cheatsheets =<br />
{{Cheatsheet_Navigation}}<br />
<br />
[[Category:Cheatsheets]]</div>Deleted userhttps://wiki.owasp.org/index.php?title=CPWE&diff=135129CPWE2012-08-30T20:03:33Z<p>Deleted user: /* Common Program Weakness Enumeration */</p>
<hr />
<div>= Introduction =<br />
This OWASP cheat sheet for [http://en.wikipedia.org/wiki/Chief_information_security_officer 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".<br />
<br />
= Common Program Weakness Enumeration =<br />
The comprehensive CPWE dictionary view is below.<br />
<br />
[[CPWE-ID: 12|Insufficient Program Resources - (12)]]<br><br />
Missing Policy - (xx)<br><br />
Missing Standards - (xx)<br><br />
Missing Solution Stack Guidance - (xx)<br><br />
Missing Secure Coding Standards - (xx)<br><br />
Missing Common Security Control Libraries - (xx)<br><br />
Inadequate Developer Training - (xx)<br><br />
Failure to Protect Source Code From Theft - (xx)<br><br />
Failure to Track Security Bugs - (xx)<br><br />
Failure to Address Implicit Contractual - (xx)<br><br />
Failure to Address Explicit Contractual Requirements - (xx)<br><br />
Risky Internal Integration - (xx)<br><br />
Risky Vendor Integration - (xx)<br><br />
Broken or Risky Platform - (xx)<br><br />
Broken or Risky Service - (xx)<br><br />
Weaknesses that Affect SDLC Initiation Phase - (xx)<br><br />
Weaknesses that Affect SDLC Development/Acquisition Phase - (xx)<br><br />
Weaknesses that Affect SDLC Implementation/Assessment Phase - (xx)<br><br />
Weaknesses that Affect SDLC Maintenance Phase - (xx)<br><br />
Weaknesses that Affect SDLC Disposal Phase - (xx)<br><br />
Potentially Impacts Regulatory Cybersecurity Risk Disclosure Obligations - (xx)<br><br />
Potentially Impacts Regulatory Cyber Incident Disclosure Obligations - (xx)<br><br />
... - (xx)<br><br />
<br />
= Authors and Primary Editors =<br />
<br />
Mike Boberski - boberski_michael [at] bah.com<br />
<br />
= Other Cheatsheets =<br />
{{Cheatsheet_Navigation}}<br />
<br />
[[Category:Cheatsheets]]</div>Deleted userhttps://wiki.owasp.org/index.php?title=CPWE&diff=135128CPWE2012-08-30T20:03:02Z<p>Deleted user: /* Common Program Weakness Enumeration */</p>
<hr />
<div>= Introduction =<br />
This OWASP cheat sheet for [http://en.wikipedia.org/wiki/Chief_information_security_officer 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".<br />
<br />
= Common Program Weakness Enumeration =<br />
The comprehensive CPWE dictionary view is below.<br />
<br />
[[CPWE-ID: 12|Insufficient Program Resources - (12)]]<br><br />
Missing Policy - (xx)<br><br />
Missing Standards - (xx)<br><br />
Missing Solution Stack Guidance - (xx)<br><br />
Missing Secure Coding Standards - (xx)<br><br />
Missing Common Security Control Libraries - (xx)<br><br />
Inadequate Developer Training - (xx)<br><br />
Failure to Protect Source Code From Theft - (xx)<br><br />
Failure to Track Security Bugs - (xx)<br><br />
Failure to Address Implicit Contractual - (xx)<br><br />
Failure to Address Explicit Contractual Requirements - (xx)<br><br />
Risky Internal Integration - (xx)<br><br />
Risky Vendor Integration - (xx)<br><br />
Broken or Risky Platform - (xx)<br><br />
Broken or Risky Service - (xx)<br><br />
Weaknesses that Affect SDLC Initiation Phase - (xx)<br><br />
Weaknesses that Affect SDLC Development/Acquisition Phase - (xx)<br><br />
Weaknesses that Affect SDLC Implementation/Assessment Phase - (xx)<br><br />
Weaknesses that Affect SDLC Maintenance Phase - (xx)<br><br />
Weaknesses that Affect SDLC Disposal Phase - (xx)<br><br />
Potentially Impacts Regulatory Cybersecurity Risk Disclosure Obligations - (xx)<br><br />
Potentially Impacts Regulatory Cyber Incident Disclosure Obligations - (xx)<br><br />
zxxxxxxxxxx - (xx)<br><br />
xxxxxxxxxxx - (xx)<br><br />
xxxxxxxxxxx - (xx)<br><br />
<br />
= Authors and Primary Editors =<br />
<br />
Mike Boberski - boberski_michael [at] bah.com<br />
<br />
= Other Cheatsheets =<br />
{{Cheatsheet_Navigation}}<br />
<br />
[[Category:Cheatsheets]]</div>Deleted userhttps://wiki.owasp.org/index.php?title=CPWE&diff=135127CPWE2012-08-30T20:02:30Z<p>Deleted user: /* Common Program Weakness Enumeration */</p>
<hr />
<div>= Introduction =<br />
This OWASP cheat sheet for [http://en.wikipedia.org/wiki/Chief_information_security_officer 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".<br />
<br />
= Common Program Weakness Enumeration =<br />
The comprehensive CPWE dictionary view is below.<br />
<br />
[[CPWE-ID: 12|Insufficient Program Resources - (12)]]<br><br />
Missing Policy - (xx)<br><br />
Missing Standards - (xx)<br><br />
Missing Solution Stack Guidance - (xx)<br><br />
Missing Secure Coding Standards - (xx)<br><br />
Missing Common Security Control Libraries - (xx)<br><br />
Inadequate Developer Training - (xx)<br><br />
Failure to Protect Source Code From Theft - (xx)<br><br />
Failure to Track Security Bugs - (xx)<br><br />
Failure to Address Implicit Contractual or Regulatory Requirements - (xx)<br><br />
Failure to Address Explicit Contractual or Regulatory Requirements - (xx)<br><br />
Risky Internal Integration - (xx)<br><br />
Risky Vendor Integration - (xx)<br><br />
Broken or Risky Platform - (xx)<br><br />
Broken or Risky Service - (xx)<br><br />
Weaknesses that Affect SDLC Initiation Phase - (xx)<br><br />
Weaknesses that Affect SDLC Development/Acquisition Phase - (xx)<br><br />
Weaknesses that Affect SDLC Implementation/Assessment Phase - (xx)<br><br />
Weaknesses that Affect SDLC Maintenance Phase - (xx)<br><br />
Weaknesses that Affect SDLC Disposal Phase - (xx)<br><br />
Potentially Impacts Regulatory Cybersecurity Risk Disclosure Obligations - (xx)<br><br />
Potentially Impacts Regulatory Cyber Incident Disclosure Obligations - (xx)<br><br />
zxxxxxxxxxx - (xx)<br><br />
xxxxxxxxxxx - (xx)<br><br />
xxxxxxxxxxx - (xx)<br><br />
<br />
= Authors and Primary Editors =<br />
<br />
Mike Boberski - boberski_michael [at] bah.com<br />
<br />
= Other Cheatsheets =<br />
{{Cheatsheet_Navigation}}<br />
<br />
[[Category:Cheatsheets]]</div>Deleted userhttps://wiki.owasp.org/index.php?title=CPWE&diff=135126CPWE2012-08-30T19:45:53Z<p>Deleted user: /* Introduction */</p>
<hr />
<div>= Introduction =<br />
This OWASP cheat sheet for [http://en.wikipedia.org/wiki/Chief_information_security_officer 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".<br />
<br />
= Common Program Weakness Enumeration =<br />
The comprehensive CPWE dictionary view is below.<br />
<br />
[[CPWE-ID: 12|Insufficient Program Resources - (12)]]<br><br />
xxxxxxxxxxx - (xx)<br><br />
xxxxxxxxxxx - (xx)<br><br />
xxxxxxxxxxx - (xx)<br><br />
xxxxxxxxxxx - (xx)<br><br />
<br />
<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........<br />
<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..........<br />
<br />
Etc,<br />
.. initial, then e.g. (make a pass through sp)<br />
.....some top-level generic using sp, 5 generic, e.g. missing or inadequate implementation phase activities<br />
... risky or dangerous vendor service<br />
.. risky or dangerous application or service integration ((split all these 'ors' into separate ones))<br />
.. missing policy<br />
.. missing standards<br />
.. missing systems development activity<br />
.. missing systems development gate<br />
.. failure to track compliance activities<br />
.. failure to track security bugs<br />
.. failure to protect source code from theft<br />
... missing or inadequate developer training<br />
.. no reusable common security control libraries<br />
.. no secure coding standards<br />
.. no minimum lifecycle activities<br />
.. failure to address implicit contractual or regulatory requirements<br />
.. failure to address explicit contractual or regulatory requirements<br />
.. inappropriate or inadequate secure development lifecycle activity <br />
.. portfolio posture blindness<br />
.. application posture blindness <br />
.. potentially material event (add ref to draft guidance)<br />
<br />
= Authors and Primary Editors =<br />
<br />
Mike Boberski - boberski_michael [at] bah.com<br />
<br />
= Other Cheatsheets =<br />
{{Cheatsheet_Navigation}}<br />
<br />
[[Category:Cheatsheets]]</div>Deleted userhttps://wiki.owasp.org/index.php?title=CPWE&diff=135125CPWE2012-08-30T19:36:49Z<p>Deleted user: /* Introduction */</p>
<hr />
<div>= Introduction =<br />
This OWASP cheat sheet for [http://en.wikipedia.org/wiki/Chief_information_security_officer 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 (1)institutionalization of an application security program and also (2)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".<br />
<br />
= Common Program Weakness Enumeration =<br />
The comprehensive CPWE dictionary view is below.<br />
<br />
[[CPWE-ID: 12|Insufficient Program Resources - (12)]]<br><br />
xxxxxxxxxxx - (xx)<br><br />
xxxxxxxxxxx - (xx)<br><br />
xxxxxxxxxxx - (xx)<br><br />
xxxxxxxxxxx - (xx)<br><br />
<br />
<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........<br />
<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..........<br />
<br />
Etc,<br />
.. initial, then e.g. (make a pass through sp)<br />
.....some top-level generic using sp, 5 generic, e.g. missing or inadequate implementation phase activities<br />
... risky or dangerous vendor service<br />
.. risky or dangerous application or service integration ((split all these 'ors' into separate ones))<br />
.. missing policy<br />
.. missing standards<br />
.. missing systems development activity<br />
.. missing systems development gate<br />
.. failure to track compliance activities<br />
.. failure to track security bugs<br />
.. failure to protect source code from theft<br />
... missing or inadequate developer training<br />
.. no reusable common security control libraries<br />
.. no secure coding standards<br />
.. no minimum lifecycle activities<br />
.. failure to address implicit contractual or regulatory requirements<br />
.. failure to address explicit contractual or regulatory requirements<br />
.. inappropriate or inadequate secure development lifecycle activity <br />
.. portfolio posture blindness<br />
.. application posture blindness <br />
.. potentially material event (add ref to draft guidance)<br />
<br />
= Authors and Primary Editors =<br />
<br />
Mike Boberski - boberski_michael [at] bah.com<br />
<br />
= Other Cheatsheets =<br />
{{Cheatsheet_Navigation}}<br />
<br />
[[Category:Cheatsheets]]</div>Deleted userhttps://wiki.owasp.org/index.php?title=CPWE&diff=135124CPWE2012-08-30T19:36:24Z<p>Deleted user: /* Common Program Weakness Enumeration */</p>
<hr />
<div>= Introduction =<br />
This OWASP cheat sheet for [http://en.wikipedia.org/wiki/Chief_information_security_officer 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 (1)institutionalization of an application security program and also (2)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".<br />
<br><br><br />
<br />
= Common Program Weakness Enumeration =<br />
The comprehensive CPWE dictionary view is below.<br />
<br />
[[CPWE-ID: 12|Insufficient Program Resources - (12)]]<br><br />
xxxxxxxxxxx - (xx)<br><br />
xxxxxxxxxxx - (xx)<br><br />
xxxxxxxxxxx - (xx)<br><br />
xxxxxxxxxxx - (xx)<br><br />
<br />
<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........<br />
<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..........<br />
<br />
Etc,<br />
.. initial, then e.g. (make a pass through sp)<br />
.....some top-level generic using sp, 5 generic, e.g. missing or inadequate implementation phase activities<br />
... risky or dangerous vendor service<br />
.. risky or dangerous application or service integration ((split all these 'ors' into separate ones))<br />
.. missing policy<br />
.. missing standards<br />
.. missing systems development activity<br />
.. missing systems development gate<br />
.. failure to track compliance activities<br />
.. failure to track security bugs<br />
.. failure to protect source code from theft<br />
... missing or inadequate developer training<br />
.. no reusable common security control libraries<br />
.. no secure coding standards<br />
.. no minimum lifecycle activities<br />
.. failure to address implicit contractual or regulatory requirements<br />
.. failure to address explicit contractual or regulatory requirements<br />
.. inappropriate or inadequate secure development lifecycle activity <br />
.. portfolio posture blindness<br />
.. application posture blindness <br />
.. potentially material event (add ref to draft guidance)<br />
<br />
= Authors and Primary Editors =<br />
<br />
Mike Boberski - boberski_michael [at] bah.com<br />
<br />
= Other Cheatsheets =<br />
{{Cheatsheet_Navigation}}<br />
<br />
[[Category:Cheatsheets]]</div>Deleted userhttps://wiki.owasp.org/index.php?title=CPWE&diff=135123CPWE2012-08-30T19:34:45Z<p>Deleted user: /* CPWE-12: Insufficient Program Resources */</p>
<hr />
<div>= Introduction =<br />
This OWASP cheat sheet for [http://en.wikipedia.org/wiki/Chief_information_security_officer 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 (1)institutionalization of an application security program and also (2)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".<br />
<br><br><br />
<br />
= Common Program Weakness Enumeration =<br />
The comprehensive CPWE dictionary view is below.<br />
<br><br />
<br />
<br />
[[CPWE-ID: 12|Insufficient Program Resources - (12)]]<br />
<br />
== CPWE-xx: ... ==<br />
<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........<br />
<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..........<br />
<br />
Etc,<br />
.. initial, then e.g. (make a pass through sp)<br />
.....some top-level generic using sp, 5 generic, e.g. missing or inadequate implementation phase activities<br />
... risky or dangerous vendor service<br />
.. risky or dangerous application or service integration ((split all these 'ors' into separate ones))<br />
.. missing policy<br />
.. missing standards<br />
.. missing systems development activity<br />
.. missing systems development gate<br />
.. failure to track compliance activities<br />
.. failure to track security bugs<br />
.. failure to protect source code from theft<br />
... missing or inadequate developer training<br />
.. no reusable common security control libraries<br />
.. no secure coding standards<br />
.. no minimum lifecycle activities<br />
.. failure to address implicit contractual or regulatory requirements<br />
.. failure to address explicit contractual or regulatory requirements<br />
.. inappropriate or inadequate secure development lifecycle activity <br />
.. portfolio posture blindness<br />
.. application posture blindness <br />
.. potentially material event (add ref to draft guidance)<br />
<br />
<br />
<br />
== CPWE-xx: ... ==<br />
<br />
= Authors and Primary Editors =<br />
<br />
Mike Boberski - boberski_michael [at] bah.com<br />
<br />
= Other Cheatsheets =<br />
{{Cheatsheet_Navigation}}<br />
<br />
[[Category:Cheatsheets]]</div>Deleted userhttps://wiki.owasp.org/index.php?title=CPWE-ID:_12&diff=135122CPWE-ID: 122012-08-30T19:33:01Z<p>Deleted user: Created page with "== Insufficient Program Resources == '''Description''' * The software development organization or organizational unit has started an application security program, but the reso..."</p>
<hr />
<div>== Insufficient Program Resources ==<br />
'''Description'''<br />
* 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.<br />
<br />
'''Common Causes'''<br />
<br />
* This weakness typically occurs in situations where there is no executive-level application security evangelist.<br />
<br />
'''Common Consequences'''<br />
<br />
* ''Prior to a Cyber Incident -'' Delayed program adoption<br />
* ''During and After a Cyber Incident -'' Unknown business risk; impaired incident response<br />
<br />
== Other CPWE ==<br />
[[CISO Cheat Sheet]]</div>Deleted userhttps://wiki.owasp.org/index.php?title=CPWE&diff=135121CPWE2012-08-30T19:28:13Z<p>Deleted user: /* CPWE-xx: Insufficient Program Resources */</p>
<hr />
<div>= Introduction =<br />
This OWASP cheat sheet for [http://en.wikipedia.org/wiki/Chief_information_security_officer 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 (1)institutionalization of an application security program and also (2)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".<br />
<br><br><br />
<br />
= Common Program Weakness Enumeration =<br />
The comprehensive CPWE dictionary view is below.<br />
<br><br />
<br />
<br />
== CPWE-12: Insufficient Program Resources ==<br />
'''Description'''<br />
* 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.<br />
<br />
'''Common Causes'''<br />
<br />
* This weakness typically occurs in situations where there is no executive-level application security evangelist.<br />
<br />
'''Common Consequences'''<br />
<br />
* ''Prior to a Cyber Incident -'' Delayed program adoption<br />
* ''During and After a Cyber Incident -'' Unknown business risk; impaired incident response<br />
<br><br />
<br />
== CPWE-xx: ... ==<br />
<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........<br />
<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..........<br />
<br />
Etc,<br />
.. initial, then e.g. (make a pass through sp)<br />
.....some top-level generic using sp, 5 generic, e.g. missing or inadequate implementation phase activities<br />
... risky or dangerous vendor service<br />
.. risky or dangerous application or service integration ((split all these 'ors' into separate ones))<br />
.. missing policy<br />
.. missing standards<br />
.. missing systems development activity<br />
.. missing systems development gate<br />
.. failure to track compliance activities<br />
.. failure to track security bugs<br />
.. failure to protect source code from theft<br />
... missing or inadequate developer training<br />
.. no reusable common security control libraries<br />
.. no secure coding standards<br />
.. no minimum lifecycle activities<br />
.. failure to address implicit contractual or regulatory requirements<br />
.. failure to address explicit contractual or regulatory requirements<br />
.. inappropriate or inadequate secure development lifecycle activity <br />
.. portfolio posture blindness<br />
.. application posture blindness <br />
.. potentially material event (add ref to draft guidance)<br />
<br />
<br />
<br />
== CPWE-xx: ... ==<br />
<br />
= Authors and Primary Editors =<br />
<br />
Mike Boberski - boberski_michael [at] bah.com<br />
<br />
= Other Cheatsheets =<br />
{{Cheatsheet_Navigation}}<br />
<br />
[[Category:Cheatsheets]]</div>Deleted userhttps://wiki.owasp.org/index.php?title=CPWE&diff=135120CPWE2012-08-30T19:24:31Z<p>Deleted user: /* Introduction */</p>
<hr />
<div>= Introduction =<br />
This OWASP cheat sheet for [http://en.wikipedia.org/wiki/Chief_information_security_officer 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 (1)institutionalization of an application security program and also (2)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".<br />
<br><br><br />
<br />
= Common Program Weakness Enumeration =<br />
The comprehensive CPWE dictionary view is below.<br />
<br><br />
<br />
<br />
== CPWE-xx: Insufficient Program Resources ==<br />
'''Description'''<br />
* 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.<br />
<br />
'''Common Causes'''<br />
<br />
* This weakness typically occurs in situations where there is no executive-level application security evangelist.<br />
<br />
'''Common Consequences'''<br />
<br />
* ''Prior to a Cyber Incident -'' Delayed program adoption<br />
* ''During and After a Cyber Incident -'' Unknown business risk; impaired incident response<br />
<br><br />
<br />
== CPWE-xx: ... ==<br />
<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........<br />
<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..........<br />
<br />
Etc,<br />
.. initial, then e.g. (make a pass through sp)<br />
.....some top-level generic using sp, 5 generic, e.g. missing or inadequate implementation phase activities<br />
... risky or dangerous vendor service<br />
.. risky or dangerous application or service integration ((split all these 'ors' into separate ones))<br />
.. missing policy<br />
.. missing standards<br />
.. missing systems development activity<br />
.. missing systems development gate<br />
.. failure to track compliance activities<br />
.. failure to track security bugs<br />
.. failure to protect source code from theft<br />
... missing or inadequate developer training<br />
.. no reusable common security control libraries<br />
.. no secure coding standards<br />
.. no minimum lifecycle activities<br />
.. failure to address implicit contractual or regulatory requirements<br />
.. failure to address explicit contractual or regulatory requirements<br />
.. inappropriate or inadequate secure development lifecycle activity <br />
.. portfolio posture blindness<br />
.. application posture blindness <br />
.. potentially material event (add ref to draft guidance)<br />
<br />
<br />
<br />
== CPWE-xx: ... ==<br />
<br />
= Authors and Primary Editors =<br />
<br />
Mike Boberski - boberski_michael [at] bah.com<br />
<br />
= Other Cheatsheets =<br />
{{Cheatsheet_Navigation}}<br />
<br />
[[Category:Cheatsheets]]</div>Deleted userhttps://wiki.owasp.org/index.php?title=CPWE&diff=135119CPWE2012-08-30T19:17:47Z<p>Deleted user: /* CPWE-xx: Insufficient Program Resources */</p>
<hr />
<div>= Introduction =<br />
This OWASP cheat sheet for 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 (1)institutionalization of an application security program and also (2)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".<br />
<br><br><br />
<br />
= Common Program Weakness Enumeration =<br />
The comprehensive CPWE dictionary view is below.<br />
<br><br />
<br />
<br />
== CPWE-xx: Insufficient Program Resources ==<br />
'''Description'''<br />
* 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.<br />
<br />
'''Common Causes'''<br />
<br />
* This weakness typically occurs in situations where there is no executive-level application security evangelist.<br />
<br />
'''Common Consequences'''<br />
<br />
* ''Prior to a Cyber Incident -'' Delayed program adoption<br />
* ''During and After a Cyber Incident -'' Unknown business risk; impaired incident response<br />
<br><br />
<br />
== CPWE-xx: ... ==<br />
<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........<br />
<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..........<br />
<br />
Etc,<br />
.. initial, then e.g. (make a pass through sp)<br />
.....some top-level generic using sp, 5 generic, e.g. missing or inadequate implementation phase activities<br />
... risky or dangerous vendor service<br />
.. risky or dangerous application or service integration ((split all these 'ors' into separate ones))<br />
.. missing policy<br />
.. missing standards<br />
.. missing systems development activity<br />
.. missing systems development gate<br />
.. failure to track compliance activities<br />
.. failure to track security bugs<br />
.. failure to protect source code from theft<br />
... missing or inadequate developer training<br />
.. no reusable common security control libraries<br />
.. no secure coding standards<br />
.. no minimum lifecycle activities<br />
.. failure to address implicit contractual or regulatory requirements<br />
.. failure to address explicit contractual or regulatory requirements<br />
.. inappropriate or inadequate secure development lifecycle activity <br />
.. portfolio posture blindness<br />
.. application posture blindness <br />
.. potentially material event (add ref to draft guidance)<br />
<br />
<br />
<br />
== CPWE-xx: ... ==<br />
<br />
= Authors and Primary Editors =<br />
<br />
Mike Boberski - boberski_michael [at] bah.com<br />
<br />
= Other Cheatsheets =<br />
{{Cheatsheet_Navigation}}<br />
<br />
[[Category:Cheatsheets]]</div>Deleted userhttps://wiki.owasp.org/index.php?title=CPWE&diff=135118CPWE2012-08-30T19:16:30Z<p>Deleted user: </p>
<hr />
<div>= Introduction =<br />
This OWASP cheat sheet for 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 (1)institutionalization of an application security program and also (2)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".<br />
<br><br><br />
<br />
= Common Program Weakness Enumeration =<br />
The comprehensive CPWE dictionary view is below.<br />
<br><br />
<br />
<br />
== CPWE-xx: Insufficient Program Resources ==<br />
'''Description'''<br />
* 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.<br />
<br />
'''Modes of Introduction'''<br />
<br />
* This weakness typically occurs in situations where there is no executive-level application security evangelist.<br />
<br />
'''Common Consequences'''<br />
<br />
* ''Prior to a Cyber Incident -'' Delayed program adoption<br />
* ''During and After a Cyber Incident -'' Unknown business risk; impaired incident response<br />
<br><br />
<br />
== CPWE-xx: ... ==<br />
<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........<br />
<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..........<br />
<br />
Etc,<br />
.. initial, then e.g. (make a pass through sp)<br />
.....some top-level generic using sp, 5 generic, e.g. missing or inadequate implementation phase activities<br />
... risky or dangerous vendor service<br />
.. risky or dangerous application or service integration ((split all these 'ors' into separate ones))<br />
.. missing policy<br />
.. missing standards<br />
.. missing systems development activity<br />
.. missing systems development gate<br />
.. failure to track compliance activities<br />
.. failure to track security bugs<br />
.. failure to protect source code from theft<br />
... missing or inadequate developer training<br />
.. no reusable common security control libraries<br />
.. no secure coding standards<br />
.. no minimum lifecycle activities<br />
.. failure to address implicit contractual or regulatory requirements<br />
.. failure to address explicit contractual or regulatory requirements<br />
.. inappropriate or inadequate secure development lifecycle activity <br />
.. portfolio posture blindness<br />
.. application posture blindness <br />
.. potentially material event (add ref to draft guidance)<br />
<br />
<br />
<br />
== CPWE-xx: ... ==<br />
<br />
= Authors and Primary Editors =<br />
<br />
Mike Boberski - boberski_michael [at] bah.com<br />
<br />
= Other Cheatsheets =<br />
{{Cheatsheet_Navigation}}<br />
<br />
[[Category:Cheatsheets]]</div>Deleted userhttps://wiki.owasp.org/index.php?title=CPWE&diff=135117CPWE2012-08-30T19:15:53Z<p>Deleted user: /* Introduction */</p>
<hr />
<div><br><br />
= Introduction =<br />
This OWASP cheat sheet for 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 (1)institutionalization of an application security program and also (2)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".<br />
<br><br><br />
<br />
= Common Program Weakness Enumeration =<br />
The comprehensive CPWE dictionary view is below.<br />
<br><br />
<br />
<br />
== CPWE-xx: Insufficient Program Resources ==<br />
'''Description'''<br />
* 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.<br />
<br />
'''Modes of Introduction'''<br />
<br />
* This weakness typically occurs in situations where there is no executive-level application security evangelist.<br />
<br />
'''Common Consequences'''<br />
<br />
* ''Prior to a Cyber Incident -'' Delayed program adoption<br />
* ''During and After a Cyber Incident -'' Unknown business risk; impaired incident response<br />
<br><br />
<br />
== CPWE-xx: ... ==<br />
<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........<br />
<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..........<br />
<br />
Etc,<br />
.. initial, then e.g. (make a pass through sp)<br />
.....some top-level generic using sp, 5 generic, e.g. missing or inadequate implementation phase activities<br />
... risky or dangerous vendor service<br />
.. risky or dangerous application or service integration ((split all these 'ors' into separate ones))<br />
.. missing policy<br />
.. missing standards<br />
.. missing systems development activity<br />
.. missing systems development gate<br />
.. failure to track compliance activities<br />
.. failure to track security bugs<br />
.. failure to protect source code from theft<br />
... missing or inadequate developer training<br />
.. no reusable common security control libraries<br />
.. no secure coding standards<br />
.. no minimum lifecycle activities<br />
.. failure to address implicit contractual or regulatory requirements<br />
.. failure to address explicit contractual or regulatory requirements<br />
.. inappropriate or inadequate secure development lifecycle activity <br />
.. portfolio posture blindness<br />
.. application posture blindness <br />
.. potentially material event (add ref to draft guidance)<br />
<br />
<br />
<br />
== CPWE-xx: ... ==<br />
<br />
= Authors and Primary Editors =<br />
<br />
Mike Boberski - boberski_michael [at] bah.com<br />
<br />
= Other Cheatsheets =<br />
{{Cheatsheet_Navigation}}<br />
<br />
[[Category:Cheatsheets]]</div>Deleted userhttps://wiki.owasp.org/index.php?title=CPWE&diff=135116CPWE2012-08-30T19:15:36Z<p>Deleted user: /* Introduction */</p>
<hr />
<div>= Introduction =<br />
This OWASP cheat sheet for 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 (1)institutionalization of an application security program and also (2)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".<br />
<br><br><br />
<br />
= Common Program Weakness Enumeration =<br />
The comprehensive CPWE dictionary view is below.<br />
<br><br />
<br />
<br />
== CPWE-xx: Insufficient Program Resources ==<br />
'''Description'''<br />
* 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.<br />
<br />
'''Modes of Introduction'''<br />
<br />
* This weakness typically occurs in situations where there is no executive-level application security evangelist.<br />
<br />
'''Common Consequences'''<br />
<br />
* ''Prior to a Cyber Incident -'' Delayed program adoption<br />
* ''During and After a Cyber Incident -'' Unknown business risk; impaired incident response<br />
<br><br />
<br />
== CPWE-xx: ... ==<br />
<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........<br />
<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..........<br />
<br />
Etc,<br />
.. initial, then e.g. (make a pass through sp)<br />
.....some top-level generic using sp, 5 generic, e.g. missing or inadequate implementation phase activities<br />
... risky or dangerous vendor service<br />
.. risky or dangerous application or service integration ((split all these 'ors' into separate ones))<br />
.. missing policy<br />
.. missing standards<br />
.. missing systems development activity<br />
.. missing systems development gate<br />
.. failure to track compliance activities<br />
.. failure to track security bugs<br />
.. failure to protect source code from theft<br />
... missing or inadequate developer training<br />
.. no reusable common security control libraries<br />
.. no secure coding standards<br />
.. no minimum lifecycle activities<br />
.. failure to address implicit contractual or regulatory requirements<br />
.. failure to address explicit contractual or regulatory requirements<br />
.. inappropriate or inadequate secure development lifecycle activity <br />
.. portfolio posture blindness<br />
.. application posture blindness <br />
.. potentially material event (add ref to draft guidance)<br />
<br />
<br />
<br />
== CPWE-xx: ... ==<br />
<br />
= Authors and Primary Editors =<br />
<br />
Mike Boberski - boberski_michael [at] bah.com<br />
<br />
= Other Cheatsheets =<br />
{{Cheatsheet_Navigation}}<br />
<br />
[[Category:Cheatsheets]]</div>Deleted userhttps://wiki.owasp.org/index.php?title=CPWE&diff=135115CPWE2012-08-30T19:15:19Z<p>Deleted user: /* Introduction */</p>
<hr />
<div>= Introduction =<br />
This OWASP cheat sheet for 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 (1)institutionalization of an application security program and also (2)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".<br />
<br><br />
<br />
= Common Program Weakness Enumeration =<br />
The comprehensive CPWE dictionary view is below.<br />
<br><br />
<br />
<br />
== CPWE-xx: Insufficient Program Resources ==<br />
'''Description'''<br />
* 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.<br />
<br />
'''Modes of Introduction'''<br />
<br />
* This weakness typically occurs in situations where there is no executive-level application security evangelist.<br />
<br />
'''Common Consequences'''<br />
<br />
* ''Prior to a Cyber Incident -'' Delayed program adoption<br />
* ''During and After a Cyber Incident -'' Unknown business risk; impaired incident response<br />
<br><br />
<br />
== CPWE-xx: ... ==<br />
<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........<br />
<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..........<br />
<br />
Etc,<br />
.. initial, then e.g. (make a pass through sp)<br />
.....some top-level generic using sp, 5 generic, e.g. missing or inadequate implementation phase activities<br />
... risky or dangerous vendor service<br />
.. risky or dangerous application or service integration ((split all these 'ors' into separate ones))<br />
.. missing policy<br />
.. missing standards<br />
.. missing systems development activity<br />
.. missing systems development gate<br />
.. failure to track compliance activities<br />
.. failure to track security bugs<br />
.. failure to protect source code from theft<br />
... missing or inadequate developer training<br />
.. no reusable common security control libraries<br />
.. no secure coding standards<br />
.. no minimum lifecycle activities<br />
.. failure to address implicit contractual or regulatory requirements<br />
.. failure to address explicit contractual or regulatory requirements<br />
.. inappropriate or inadequate secure development lifecycle activity <br />
.. portfolio posture blindness<br />
.. application posture blindness <br />
.. potentially material event (add ref to draft guidance)<br />
<br />
<br />
<br />
== CPWE-xx: ... ==<br />
<br />
= Authors and Primary Editors =<br />
<br />
Mike Boberski - boberski_michael [at] bah.com<br />
<br />
= Other Cheatsheets =<br />
{{Cheatsheet_Navigation}}<br />
<br />
[[Category:Cheatsheets]]</div>Deleted userhttps://wiki.owasp.org/index.php?title=CPWE&diff=135114CPWE2012-08-30T19:15:01Z<p>Deleted user: /* Common Program Weakness Enumeration */</p>
<hr />
<div>= Introduction =<br />
This OWASP cheat sheet for 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 (1)institutionalization of an application security program and also (2)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".<br />
<br />
= Common Program Weakness Enumeration =<br />
The comprehensive CPWE dictionary view is below.<br />
<br><br />
<br />
<br />
== CPWE-xx: Insufficient Program Resources ==<br />
'''Description'''<br />
* 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.<br />
<br />
'''Modes of Introduction'''<br />
<br />
* This weakness typically occurs in situations where there is no executive-level application security evangelist.<br />
<br />
'''Common Consequences'''<br />
<br />
* ''Prior to a Cyber Incident -'' Delayed program adoption<br />
* ''During and After a Cyber Incident -'' Unknown business risk; impaired incident response<br />
<br><br />
<br />
== CPWE-xx: ... ==<br />
<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........<br />
<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..........<br />
<br />
Etc,<br />
.. initial, then e.g. (make a pass through sp)<br />
.....some top-level generic using sp, 5 generic, e.g. missing or inadequate implementation phase activities<br />
... risky or dangerous vendor service<br />
.. risky or dangerous application or service integration ((split all these 'ors' into separate ones))<br />
.. missing policy<br />
.. missing standards<br />
.. missing systems development activity<br />
.. missing systems development gate<br />
.. failure to track compliance activities<br />
.. failure to track security bugs<br />
.. failure to protect source code from theft<br />
... missing or inadequate developer training<br />
.. no reusable common security control libraries<br />
.. no secure coding standards<br />
.. no minimum lifecycle activities<br />
.. failure to address implicit contractual or regulatory requirements<br />
.. failure to address explicit contractual or regulatory requirements<br />
.. inappropriate or inadequate secure development lifecycle activity <br />
.. portfolio posture blindness<br />
.. application posture blindness <br />
.. potentially material event (add ref to draft guidance)<br />
<br />
<br />
<br />
== CPWE-xx: ... ==<br />
<br />
= Authors and Primary Editors =<br />
<br />
Mike Boberski - boberski_michael [at] bah.com<br />
<br />
= Other Cheatsheets =<br />
{{Cheatsheet_Navigation}}<br />
<br />
[[Category:Cheatsheets]]</div>Deleted userhttps://wiki.owasp.org/index.php?title=CPWE&diff=135113CPWE2012-08-30T19:14:50Z<p>Deleted user: /* Common Program Weakness Enumeration */</p>
<hr />
<div>= Introduction =<br />
This OWASP cheat sheet for 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 (1)institutionalization of an application security program and also (2)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".<br />
<br />
= Common Program Weakness Enumeration =<br />
The comprehensive CPWE dictionary view is below.<br />
<br><br />
<br><br />
<br />
<br />
== CPWE-xx: Insufficient Program Resources ==<br />
'''Description'''<br />
* 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.<br />
<br />
'''Modes of Introduction'''<br />
<br />
* This weakness typically occurs in situations where there is no executive-level application security evangelist.<br />
<br />
'''Common Consequences'''<br />
<br />
* ''Prior to a Cyber Incident -'' Delayed program adoption<br />
* ''During and After a Cyber Incident -'' Unknown business risk; impaired incident response<br />
<br><br />
<br />
== CPWE-xx: ... ==<br />
<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........<br />
<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..........<br />
<br />
Etc,<br />
.. initial, then e.g. (make a pass through sp)<br />
.....some top-level generic using sp, 5 generic, e.g. missing or inadequate implementation phase activities<br />
... risky or dangerous vendor service<br />
.. risky or dangerous application or service integration ((split all these 'ors' into separate ones))<br />
.. missing policy<br />
.. missing standards<br />
.. missing systems development activity<br />
.. missing systems development gate<br />
.. failure to track compliance activities<br />
.. failure to track security bugs<br />
.. failure to protect source code from theft<br />
... missing or inadequate developer training<br />
.. no reusable common security control libraries<br />
.. no secure coding standards<br />
.. no minimum lifecycle activities<br />
.. failure to address implicit contractual or regulatory requirements<br />
.. failure to address explicit contractual or regulatory requirements<br />
.. inappropriate or inadequate secure development lifecycle activity <br />
.. portfolio posture blindness<br />
.. application posture blindness <br />
.. potentially material event (add ref to draft guidance)<br />
<br />
<br />
<br />
== CPWE-xx: ... ==<br />
<br />
= Authors and Primary Editors =<br />
<br />
Mike Boberski - boberski_michael [at] bah.com<br />
<br />
= Other Cheatsheets =<br />
{{Cheatsheet_Navigation}}<br />
<br />
[[Category:Cheatsheets]]</div>Deleted userhttps://wiki.owasp.org/index.php?title=CPWE&diff=135112CPWE2012-08-30T19:14:38Z<p>Deleted user: /* Common Program Weakness Enumeration */</p>
<hr />
<div>= Introduction =<br />
This OWASP cheat sheet for 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 (1)institutionalization of an application security program and also (2)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".<br />
<br />
= Common Program Weakness Enumeration =<br />
The comprehensive CPWE dictionary view is below.<br />
<br><br />
<br />
== CPWE-xx: Insufficient Program Resources ==<br />
'''Description'''<br />
* 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.<br />
<br />
'''Modes of Introduction'''<br />
<br />
* This weakness typically occurs in situations where there is no executive-level application security evangelist.<br />
<br />
'''Common Consequences'''<br />
<br />
* ''Prior to a Cyber Incident -'' Delayed program adoption<br />
* ''During and After a Cyber Incident -'' Unknown business risk; impaired incident response<br />
<br><br />
<br />
== CPWE-xx: ... ==<br />
<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........<br />
<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..........<br />
<br />
Etc,<br />
.. initial, then e.g. (make a pass through sp)<br />
.....some top-level generic using sp, 5 generic, e.g. missing or inadequate implementation phase activities<br />
... risky or dangerous vendor service<br />
.. risky or dangerous application or service integration ((split all these 'ors' into separate ones))<br />
.. missing policy<br />
.. missing standards<br />
.. missing systems development activity<br />
.. missing systems development gate<br />
.. failure to track compliance activities<br />
.. failure to track security bugs<br />
.. failure to protect source code from theft<br />
... missing or inadequate developer training<br />
.. no reusable common security control libraries<br />
.. no secure coding standards<br />
.. no minimum lifecycle activities<br />
.. failure to address implicit contractual or regulatory requirements<br />
.. failure to address explicit contractual or regulatory requirements<br />
.. inappropriate or inadequate secure development lifecycle activity <br />
.. portfolio posture blindness<br />
.. application posture blindness <br />
.. potentially material event (add ref to draft guidance)<br />
<br />
<br />
<br />
== CPWE-xx: ... ==<br />
<br />
= Authors and Primary Editors =<br />
<br />
Mike Boberski - boberski_michael [at] bah.com<br />
<br />
= Other Cheatsheets =<br />
{{Cheatsheet_Navigation}}<br />
<br />
[[Category:Cheatsheets]]</div>Deleted user