CPWE - Revision history

Deleted user at 19:22, 26 September 2012

2012-09-26T19:22:12Z

Deleted user: /* Contributor Instructions */

2012-09-13T18:30:59Z

‎Contributor Instructions

Deleted user: /* Introduction */

2012-09-13T18:18:52Z

‎Introduction

Deleted user: /* Introduction */

2012-09-13T18:15:46Z

‎Introduction

Deleted user: /* Introduction */

2012-09-13T18:12:59Z

‎Introduction

Deleted user: /* Common Program Weakness Enumeration */

2012-09-13T18:01:41Z

‎Common Program Weakness Enumeration

Deleted user: /* Introduction */

2012-09-13T17:52:01Z

‎Introduction

Deleted user at 17:31, 13 September 2012

2012-09-13T17:31:04Z

Deleted user: moved CISO Cheat Sheet to CPWE

2012-09-13T17:29:18Z

moved CISO Cheat Sheet to CPWE

Deleted user: /* Introduction */

2012-09-09T03:13:39Z

‎Introduction

← Older revision		Revision as of 19:22, 26 September 2012
Line 69:		Line 69:

	Mike Boberski - boberski_michael [at] bah.com		Mike Boberski - boberski_michael [at] bah.com
−
−	~~= Other Cheatsheets =~~
−	~~{{Cheatsheet_Navigation}}~~
−
−	~~[[Category:Cheatsheets]]~~

@@ Line 16: / Line 16: @@
 = Contributor Instructions =
-First, thank you for considering contributing.
+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.
 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.

@@ Line 7: / Line 7: @@
        CPWE-3: Failure to Address Verification Findings For Application X  ''<-- This is an instance of a finding of type CPWE-3''
        CPWE-3: Failure to Address Verification Findings For Application Y  ''<-- This is another instance of a finding of type CPWE-3''
-       CPWE-12: Insufficient Program Resources For SwA Program For Project Z  ''<-- This is an instance of a finding of type CPWE-12''
+       CPWE-12: Insufficient Program Resources For Project Z  ''<-- This is an instance of a finding of type CPWE-12''
    '''High (xx Findings)'''
        ...

@@ Line 13: / Line 13: @@
    '''Low (xx Findings)'''
-Long-term goals for leveraging the CPWE potentially include creating an OWASP CISO Top Ten project using the CPWE as inputs (i.e. that draws from the list), perhaps also turning this into its own separate project if interest/activity warrants.
+Long-term goals for leveraging the CPWE potentially include creating an OWASP CISO Top Ten project using the CPWE as inputs (i.e. that draws from the list), similar to how the CWE/SANS Top 25 list is constructed using the CWE.
 = Contributor Instructions =

@@ Line 1: / Line 1: @@
 = Introduction =
-This OWASP initiative is intended for an executive audience and for application security program assessors. It contains a list of application security program weaknesses called the Common Program Weakness Enumeration (CPWE) that is intended to be built out over time, similar to MITRE's Common Weakness Enumeration (CWE) for software weaknesses.
+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.
-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.
+'''Example: '''Below is a notional example of reporting findings from some SwA program assessment using CPWE:
-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.
+  '''Severe (3 Findings)'''
 Long-term goals for leveraging the CPWE potentially include creating an OWASP CISO Top Ten project using the CPWE as inputs (i.e. that draws from the list), perhaps also turning this into its own separate project if interest/activity warrants.

@@ Line 27: / Line 27: @@
 Inadequate Developer Training - (xx)<br>
 Use of Insufficient Verification Technique - (xx)<br>
-Failure to Address Verification Findings - (xx)<br>
+Failure to Address Verification Findings - (3)<br>
 Failure to Protect Source Code from Theft - (xx)<br>
 Failure to Protect Sensitive Application Data from Theft - (xx)<br>

@@ Line 1: / Line 1: @@
 = Introduction =
-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.
+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.
 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.

← Older revision	Revision as of 17:29, 13 September 2012
(No difference)