How to bootstrap your SDLC with verification activities - Revision history

KirstenS at 13:13, 28 March 2009

2009-03-28T13:13:23Z

Deleted user at 21:07, 16 February 2009

2009-02-16T21:07:27Z

Deleted user at 21:06, 16 February 2009

2009-02-16T21:06:38Z

Deleted user at 21:01, 16 February 2009

2009-02-16T21:01:24Z

Deleted user at 17:57, 22 January 2009

2009-01-22T17:57:26Z

Deleted user at 16:10, 20 January 2009

2009-01-20T16:10:38Z

Deleted user at 16:00, 20 January 2009

2009-01-20T16:00:22Z

Deleted user at 15:54, 20 January 2009

2009-01-20T15:54:18Z

Deleted user at 15:50, 20 January 2009

2009-01-20T15:50:56Z

Deleted user at 15:47, 20 January 2009

2009-01-20T15:47:28Z

← Older revision		Revision as of 13:13, 28 March 2009
Line 1:		Line 1:
−	If you are planning on adding an application security verification activity to your existing SDLC using the [~~http~~:~~//www.owasp.org/index.php/~~Category:OWASP_Application_Security_Verification_Standard_Project OWASP Application Security Verification Standard (ASVS)], you will need to do some planning. You will need to work closely with both project managers and developers. It is not enough, although it is a necessary prerequisite, to have buy-in from application owners. This article describes one possible way to bootstrap your SDLC with verification activities.	+	If you are planning on adding an application security verification activity to your existing SDLC using the [[::Category:OWASP_Application_Security_Verification_Standard_Project\| OWASP Application Security Verification Standard (ASVS)]], you will need to do some planning. You will need to work closely with both project managers and developers. It is not enough, although it is a necessary prerequisite, to have buy-in from application owners. This article describes one possible way to bootstrap your SDLC with verification activities.

← Older revision		Revision as of 21:07, 16 February 2009
Line 1:		Line 1:
−	If you are planning on adding an application security verification activity to your SDLC using the [http://www.owasp.org/index.php/Category:OWASP_Application_Security_Verification_Standard_Project OWASP Application Security Verification Standard (ASVS)], you will need to do some planning. You will need to work closely with both project managers and developers. It is not enough, although it is a necessary prerequisite, to have buy-in from application owners. This article describes one possible way to bootstrap your SDLC with verification activities.	+	If you are planning on adding an application security verification activity to your existing SDLC using the [http://www.owasp.org/index.php/Category:OWASP_Application_Security_Verification_Standard_Project OWASP Application Security Verification Standard (ASVS)], you will need to do some planning. You will need to work closely with both project managers and developers. It is not enough, although it is a necessary prerequisite, to have buy-in from application owners. This article describes one possible way to bootstrap your SDLC with verification activities.

@@ Line 16: / Line 16: @@
 **Code and available documentation
 **Perform an ASVS Level 1 or 2 security architecture review
-**Determine an ASVS Level 1 verification strategy
+**Determine an ASVS Level 1 verification strategy (do NOT attempt higher level since is first time)
 *Produce a verification report template

@@ Line 1: / Line 1: @@
 If you are planning on adding an application security verification activity to your SDLC using the [http://www.owasp.org/index.php/Category:OWASP_Application_Security_Verification_Standard_Project OWASP Application Security Verification Standard (ASVS)], you will need to do some planning. You will need to work closely with both project managers and developers. It is not enough, although it is a necessary prerequisite, to have buy-in from application owners. This article describes one possible way to bootstrap your SDLC with verification activities.
 The first step is to clearly set expectations with both project managers and with developers. It is strongly advised to meet for a full day or two with project managers and developers after the decision has been made by application owners that  application security verification activities will be added to your SDLC. You should:
@@ Line 12: / Line 15: @@
 *Collect inputs
 **Code and available documentation
-**Perform an ASVS Level 1 security architecture review
+**Perform an ASVS Level 1 or 2 security architecture review
 **Determine an ASVS Level 1 verification strategy
-*Produce an “initial application review” document
+*Produce a verification report template
-This initial application review document will contain collected information, information about techniques that you will use, and information about how verifications can be inserted into their SDLC. This document will also contain warnings about revised cost estimates based on unexpected complexity and additional caveats.
+The verification report template document will contain collected information, information about techniques that you will use, and information about how verifications can be inserted into their SDLC. This document will also contain warnings about revised cost estimates based on unexpected complexity and additional caveats.
-The next step is to create a “verification target” document (or a comparable document) and project schedule. Take comments received on initial application review document and turn that document into a verification target document, and create a project schedule at this point as well. An addendum should also be generated for the proposal if the initial cost estimates change based on information collected up to this point.
+The next step is to collect and address comments received on the verification report template, and create a project schedule at this point as well. An addendum should also be generated for the proposal if the initial cost estimates change based on information collected up to this point.
-The next step is to perform the initial verification. Perform dynamic and static analysis using tools, and go a little deeper in reviewing the design information. Although, perhaps defer performing further design review for this go-round if available hours or patience is short. Write up your results as you perform the different reviews. Make sure not just to write up problems, but also at least identify parts of code that were reviewed that were not found to have problems. Note, keep verification reports separate than the verification target document.
+The next step is to perform the initial verification. Perform dynamic and static analysis using tools, and go a little deeper in reviewing the design information. Although, perhaps defer performing further design review for this go-round if available hours or patience is short. Write up your results as you perform the different reviews. Make sure not just to write up problems, but also at least identify parts of code that were reviewed that were not found to have problems.
@@ Line 35: / Line 38: @@
-Make sure to write down rationale for why they are going to assume the risk for those they do not plan to remediate. Update the verification target document with this information. Update verification report with any corrections based on presentation of findings. Work with project managers and developers to identify frequency and depth of future verifications as a new activity added to their ''existing'' SDLC. Update the verification report with this information. Create a proposal for future work based on proposed SDLC that has been bootstrapped with verification activities.
+Make sure to write down rationale for why they are going to assume the risk for those they do not plan to remediate. Update the verification report with this information. Further update the verification report with any corrections based on presentation of findings. Work with project managers and developers to identify frequency and depth of future verifications as a new activity added to their ''existing'' SDLC. Update the verification report with this information. Create a proposal for future work based on proposed SDLC that has been bootstrapped with verification activities.

← Older revision		Revision as of 17:57, 22 January 2009
Line 1:		Line 1:
	If you are planning on adding an application security verification activity to your SDLC using the [http://www.owasp.org/index.php/Category:OWASP_Application_Security_Verification_Standard_Project OWASP Application Security Verification Standard (ASVS)], you will need to do some planning. You will need to work closely with both project managers and developers. It is not enough, although it is a necessary prerequisite, to have buy-in from application owners. This article describes one possible way to bootstrap your SDLC with verification activities.		If you are planning on adding an application security verification activity to your SDLC using the [http://www.owasp.org/index.php/Category:OWASP_Application_Security_Verification_Standard_Project OWASP Application Security Verification Standard (ASVS)], you will need to do some planning. You will need to work closely with both project managers and developers. It is not enough, although it is a necessary prerequisite, to have buy-in from application owners. This article describes one possible way to bootstrap your SDLC with verification activities.

		+	[[Image:Asvs_boot.gif]]

	The first step is to clearly set expectations with both project managers and with developers. It is strongly advised to meet for a full day or two with project managers and developers after the decision has been made by application owners that application security verification activities will be added to your SDLC. You should:		The first step is to clearly set expectations with both project managers and with developers. It is strongly advised to meet for a full day or two with project managers and developers after the decision has been made by application owners that application security verification activities will be added to your SDLC. You should:

@@ Line 6: / Line 6: @@
 *Present an overview of the process
-**Generic info about architecture review
+**Generic information about architecture review
 **Generic information about automated and manual verification
 **Generic information about adding verification activities into SDLC

@@ Line 29: / Line 29: @@
 *Present all findings,
-*Answer any questions, and to
+*Answer any questions,
-*Identify findings which they do not plan to remediate.
+*Identify findings which they do not plan to remediate, and

@@ Line 5: / Line 5: @@
-*Present an overview of the process (generic information about dynamic and code reviews, generic info about architecture review, generic information about adding verification activities into SDLC),
+*Present an overview of the process
-*Collect inputs (code and available documentation), perform an initial high-level design review, determine a verification strategy, and
+**Generic information about automated and manual verification
-*Produce an “initial application review” document.
+**Generic info about architecture review
@@ Line 30: / Line 36: @@
-Also as part of this findings meeting, work with project managers and developers to identify frequency and depth of future verifications as part of their SDLC. Update the verification report with this information. Create a proposal for future work based on proposed SDLC that has been bootstrapped with verification activities.
+Also as part of this findings meeting, work with project managers and developers to identify frequency and depth of future verifications as part of their ''existing'' SDLC. Update the verification report with this information. Create a proposal for future work based on proposed SDLC that has been bootstrapped with verification activities.

← Older revision		Revision as of 15:47, 20 January 2009
Line 16:		Line 16:


−	The next step is to perform the initial verification. Perform dynamic and static analysis using tools, and go a little deeper in reviewing the design information. Although, perhaps ~~punt on~~ further design review for this go-round if available hours ~~are~~ short. Write up your results as you perform the different reviews. Make sure not just to write up problems, but also at least identify parts of code that were reviewed that were not found to have problems. Note, keep verification reports separate than the verification target document.	+	The next step is to perform the initial verification. Perform dynamic and static analysis using tools, and go a little deeper in reviewing the design information. Although, perhaps defer performing further design review for this go-round if available hours or patience is short. Write up your results as you perform the different reviews. Make sure not just to write up problems, but also at least identify parts of code that were reviewed that were not found to have problems. Note, keep verification reports separate than the verification target document.