CISO AppSec Guide: Application Security Program - Revision history

Clerkendweller: /* Software assurance maturity models */ Added "Open"

2013-11-07T12:06:55Z

‎Software assurance maturity models: Added "Open"

Clerkendweller: /* Security in the SDLC (S-SDLC) methodologies */

2013-11-07T12:06:20Z

‎Security in the SDLC (S-SDLC) methodologies

Clerkendweller: /* Security in the SDLC (S-SDLC) methodologies */ BITS added

2013-11-07T12:05:45Z

‎Security in the SDLC (S-SDLC) methodologies: BITS added

Clerkendweller: /* III-5 How to Choose the Right OWASP Projects For Your Organization */ Move figure

2013-11-06T19:19:25Z

‎III-5 How to Choose the Right OWASP Projects For Your Organization: Move figure

Clerkendweller: /* Security in the SDLC (S-SDLC) methodologies */ herein -> below

2013-11-06T19:03:05Z

‎Security in the SDLC (S-SDLC) methodologies: herein -> below

Clerkendweller: NOTOC added and main headings numbered

2013-11-06T17:27:47Z

NOTOC added and main headings numbered

Clerkendweller: /* Benchmarking & maturity */ Delete section as already done in depth above

2013-11-06T16:26:24Z

‎Benchmarking & maturity: Delete section as already done in depth above

Clerkendweller: /* Benchmarking & maturity */ Remove diagram / Elevate heading

2013-11-06T16:24:57Z

‎Benchmarking & maturity: Remove diagram / Elevate heading

Clerkendweller: /* Project's categories */ Notes/missing link removed. Lifecycle -> builders, breakers, defenders

2013-11-06T16:23:23Z

‎Project's categories: Notes/missing link removed. Lifecycle -> builders, breakers, defenders

Clerkendweller: /* Components of your security strategy */ Delete ( / Line breaks

2013-11-06T16:19:01Z

‎Components of your security strategy: Delete ( / Line breaks

@@ Line 117: / Line 117: @@
 ===Software assurance maturity models===
-Besides of following a holistic approach toward application security that considers other domains it is also important for the CISO to consider what the organization capabilities are from day one in building software security and plan on how to integrate new activities in the future.  Measuring the organizations capabilities in software security is possible today with software security maturity models such as the Build Security In Maturity Model (BSIMM) and the Software Assurance Maturity Model (SAMM). These models can also help the CISO in the assessment, planning and implementation of a software security initiative for the organization. These maturity models are explicitly designed for software security assurance. These models, even if are based upon empirical measurements, are feed from real data (e.g. software security surveys) hence allow to measure organizations against peers that already had implemented software security initiatives. By allowing their organization’s secure software development software practices to be measured using these models, CISOs can compare their organization secure software development capabilities against other software development organizations to determine in which software security activities the organization either leads or lags.
+Besides of following a holistic approach toward application security that considers other domains it is also important for the CISO to consider what the organization capabilities are from day one in building software security and plan on how to integrate new activities in the future.  Measuring the organizations capabilities in software security is possible today with software security maturity models such as the Build Security In Maturity Model (BSIMM) and the Open Software Assurance Maturity Model (SAMM). These models can also help the CISO in the assessment, planning and implementation of a software security initiative for the organization. These maturity models are explicitly designed for software security assurance. These models, even if are based upon empirical measurements, are feed from real data (e.g. software security surveys) hence allow to measure organizations against peers that already had implemented software security initiatives. By allowing their organization’s secure software development software practices to be measured using these models, CISOs can compare their organization secure software development capabilities against other software development organizations to determine in which software security activities the organization either leads or lags.
 For the software security activities for which the organization is lagging, BSIMM and SAMM measurements allow the CISO to construct a plan for software security activities to close these gaps in the future. It is important to notice that these models are not prescriptive that is, are not telling organizations what to do but rather to measure security activities in comparison with similar organizations in the field.  The models are organized along similar domains, governance, intelligence, SSDL touch points, deployment for BSIMM and governance, construction, verification, deployment for SAMM. SAMM measurements are done in three best practices and three levels of maturity for each business function.

@@ Line 109: / Line 109: @@
 ===Security in the SDLC (S-SDLC) methodologies===
-In cases when the CISO of the organization has also responsibility over promoting a software security process within the organization, it is important not to take this goal lightly since usually requires careful planning of resources and development of new processes and activities. Fortunately today, several “Security in the SDLC” (S-SDLC) methodologies can be adopted by CISOs to incorporate security in the SDLC. The most popular S-SDLC methodologies used today are Cigital’s Touch Points, Microsoft SDL, OWASP CLASP/SAMM and the BITS Software Assurance Framework.  At high level, these S-SDLC methodologies are very similar and consist on integrating security activities such as security requirements, secure architecture review, architecture risk analysis/threat modeling, static analysis/review of source code, security/penetration testing activities within the existing SDLCs used by the organization. The challenge for the integration of security in the SDLC from CISO perspective is to make sure that these software security activities are aligned with the software engineering processes used by the organization. This means for example to integrate with different types of S-SDLC s  such as Agile, RUP, Waterfall as these might be already followed by different software development teams within the organization. An example on how these can be integrated within a waterfall SDLC as well as iterated within different iterations of a SDLC process is shown below.
+In cases when the CISO of the organization has also responsibility over promoting a software security process within the organization, it is important not to take this goal lightly since usually requires careful planning of resources and development of new processes and activities. Fortunately today, several “Security in the SDLC” (S-SDLC) methodologies can be adopted by CISOs to incorporate security in the SDLC. The most popular S-SDLC methodologies used today are Cigital’s Touch Points, Microsoft SDL, OWASP CLASP and the BITS Software Assurance Framework.  At high level, these S-SDLC methodologies are very similar and consist on integrating security activities such as security requirements, secure architecture review, architecture risk analysis/threat modeling, static analysis/review of source code, security/penetration testing activities within the existing SDLCs used by the organization. The challenge for the integration of security in the SDLC from CISO perspective is to make sure that these software security activities are aligned with the software engineering processes used by the organization. This means for example to integrate with different types of S-SDLC s  such as Agile, RUP, Waterfall as these might be already followed by different software development teams within the organization. An example on how these can be integrated within a waterfall SDLC as well as iterated within different iterations of a SDLC process is shown below.
 [[File:Security in the SDLC Process.png|center|600px]]

@@ Line 109: / Line 109: @@
 ===Security in the SDLC (S-SDLC) methodologies===
-In cases when the CISO of the organization has also responsibility over promoting a software security process within the organization, it is important not to take this goal lightly since usually requires careful planning of resources and development of new processes and activities. Fortunately today, several “Security in the SDLC” (S-SDLC) methodologies can be adopted by CISOs to incorporate security in the SDLC. The most popular S-SDLC methodologies used today are Cigital’s Touch Points, Microsoft SDL and OWASP CLASP.  At high level, these S-SDLC methodologies are very similar and consist on integrating security activities such as security requirements, secure architecture review, architecture risk analysis/threat modeling, static analysis/review of source code, security/penetration testing activities within the existing SDLCs used by the organization. The challenge for the integration of security in the SDLC from CISO perspective is to make sure that these software security activities are aligned with the software engineering processes used by the organization. This means for example to integrate with different types of S-SDLC s  such as Agile, RUP, Waterfall as these might be already followed by different software development teams within the organization. An example on how these can be integrated within a waterfall SDLC as well as iterated within different iterations of a SDLC process is shown below.
+In cases when the CISO of the organization has also responsibility over promoting a software security process within the organization, it is important not to take this goal lightly since usually requires careful planning of resources and development of new processes and activities. Fortunately today, several “Security in the SDLC” (S-SDLC) methodologies can be adopted by CISOs to incorporate security in the SDLC. The most popular S-SDLC methodologies used today are Cigital’s Touch Points, Microsoft SDL, OWASP CLASP/SAMM and the BITS Software Assurance Framework.  At high level, these S-SDLC methodologies are very similar and consist on integrating security activities such as security requirements, secure architecture review, architecture risk analysis/threat modeling, static analysis/review of source code, security/penetration testing activities within the existing SDLCs used by the organization. The challenge for the integration of security in the SDLC from CISO perspective is to make sure that these software security activities are aligned with the software engineering processes used by the organization. This means for example to integrate with different types of S-SDLC s  such as Agile, RUP, Waterfall as these might be already followed by different software development teams within the organization. An example on how these can be integrated within a waterfall SDLC as well as iterated within different iterations of a SDLC process is shown below.
 [[File:Security in the SDLC Process.png|center|600px]]

@@ Line 219: / Line 219: @@
 Also note that OWASP provides several projects and guidance for CISOs to help in the development and implementation of software security development and security testing processes. Please refer to [https://www.owasp.org/index.php/CISO_AppSec_Guide:_Quick_Reference_to_OWASP_Guides_%26_Projects Appendix B] for a quick reference to OWASP guides & projects.
-In general tools can be classified in various categories (and so are also the OWASP projects):
+In general tools can be classified in various categories (and so are also the OWASP projects).
 ===Project's maturity===
@@ Line 228: / Line 230: @@
 * Inactive (former projects that have been retired or deprecated or that at some point have been abandoned).
 Obviously for a CISO, the most interesting projects and tools would be stable and reliable ones. He can rely on a certain proven quality, and on them being available and maintained to a certain degree in the future days to come. Beta projects can also be very valuable, as they may represent projects that have not finished their full review cycle yet but are already available for early adopters and can help to build good foundations for your security programs and tools going forward.
 ===Project's categories===

@@ Line 109: / Line 109: @@
 ===Security in the SDLC (S-SDLC) methodologies===
-In cases when the CISO of the organization has also responsibility over promoting a software security process within the organization, it is important not to take this goal lightly since usually requires careful planning of resources and development of new processes and activities. Fortunately today, several “Security in the SDLC” (S-SDLC) methodologies can be adopted by CISOs to incorporate security in the SDLC. The most popular S-SDLC methodologies used today are Cigital’s Touch Points, Microsoft SDL and OWASP CLASP.  At high level, these S-SDLC methodologies are very similar and consist on integrating security activities such as security requirements, secure architecture review, architecture risk analysis/threat modeling, static analysis/review of source code, security/penetration testing activities within the existing SDLCs used by the organization. The challenge for the integration of security in the SDLC from CISO perspective is to make sure that these software security activities are aligned with the software engineering processes used by the organization. This means for example to integrate with different types of S-SDLC s  such as Agile, RUP, Waterfall as these might be already followed by different software development teams within the organization. An example on how these can be integrated within a waterfall SDLC as well as iterated within different iterations of a SDLC process is shown herein
+In cases when the CISO of the organization has also responsibility over promoting a software security process within the organization, it is important not to take this goal lightly since usually requires careful planning of resources and development of new processes and activities. Fortunately today, several “Security in the SDLC” (S-SDLC) methodologies can be adopted by CISOs to incorporate security in the SDLC. The most popular S-SDLC methodologies used today are Cigital’s Touch Points, Microsoft SDL and OWASP CLASP.  At high level, these S-SDLC methodologies are very similar and consist on integrating security activities such as security requirements, secure architecture review, architecture risk analysis/threat modeling, static analysis/review of source code, security/penetration testing activities within the existing SDLCs used by the organization. The challenge for the integration of security in the SDLC from CISO perspective is to make sure that these software security activities are aligned with the software engineering processes used by the organization. This means for example to integrate with different types of S-SDLC s  such as Agile, RUP, Waterfall as these might be already followed by different software development teams within the organization. An example on how these can be integrated within a waterfall SDLC as well as iterated within different iterations of a SDLC process is shown below.
 [[File:Security in the SDLC Process.png|center|600px]]

@@ Line 1: / Line 1: @@
 [[Application Security Guide For CISOs|< Back to the Application Security Guide For CISOs]]
-__TOC__
+__NOTOC__
 = Part III: Application Security Program =
-== Executive Summary ==
+== III-1  Executive Summary ==
 From the risk management strategic point of view, the mitigation of application security risks is not a one time exercise; rather it is an ongoing activity that requires paying close attention to emerging threats and planning ahead for the deployment of new security measures to mitigate these new threats.
@@ Line 30: / Line 30: @@
 OWASP provides several projects and guidance for CISOs to help develop and implement an application security program. Besides reading this section of the guide, see the [https://www.owasp.org/index.php/CISO_AppSec_Guide:_Quick_Reference_to_OWASP_Guides_%26_Projects Appendix B: Quick Reference to OWASP Guides & Projects] for more information on the type of security engineering domain activities that can be incorporated within an application security program.
-== Introduction ==
+== III-2  Introduction ==
 Mitigating the risk of attacks that seek to exploit application vulnerabilities as well as potential gaps in protective and detective controls is one of the CISOs main concerns. In the case when vulnerabilities are only found after a security incident, the next step is to fix the identified vulnerabilities and limit further impact. Typically, this involves reproducing the vulnerabilities and re-testing the vulnerabilities after fixes are implemented to ensure vulnerabilities can no longer be exploited. If the incident is due to a gap of a security control such as a failure to filter malicious input or to detect the attack event, the next step is to implement countermeasures to mitigate the risk. Countermeasures may be a combination of deterrent, preventative, detective, corrective, and compensating security controls. To make such decisions, the CISO needs to consider both the risks of vulnerabilities as well as the weaknesses of security control measures to make a decision on how to mitigate the risks. Typically fixing a vulnerability involves a vulnerability management cycle that includes identifying the vulnerability, fixing it and then re-testing it to determine that it is no longer present.
@@ Line 65: / Line 65: @@
 </center>
-== Addressing CISO's Application Security Functions==
+== III-3  Addressing CISO's Application Security Functions==
 ===Application security governance, risk and compliance ===
@@ Line 87: / Line 87: @@
 For CISOs whose responsibility is manage application vulnerability risks, security metrics such as application vulnerability metrics constitutes an important factor in making business cases for investing in application security measures to control and reduce risks. Security metrics such as measurements of vulnerabilities found on the same applications during the roll out of application security activities aimed to reduce the number and the risk of vulnerabilities for example, can demonstrate to senior managers and company executives that the adoption of application security processes, training and tools ultimately helps the organization to deliver applications and software products that have a fewer number of vulnerabilities and pose less risk to the organization and the customers.
-== Targeting Software Security Activities and S-SDLC Processes ==
+== III-4 Targeting Software Security Activities and S-SDLC Processes ==
 OWASP provides several projects and guidance for CISOs to help in the development and implementation of software security activities and Security in the Software Life Cycle (S-SDLC). To know more, besides reading this section of the guide, please consult the [https://www.owasp.org/index.php/CISO_AppSec_Guide:_Quick_Reference_to_OWASP_Guides_%26_Projects Appendix B: Quick Reference to OWASP Guides & Projects for more information]
@@ Line 209: / Line 209: @@
 </center>
-== How to Choose the Right OWASP Projects For Your Organization==
+== III-5  How to Choose the Right OWASP Projects For Your Organization==
 Depending on the overall security level and risk profile of the organization unit different tools and standards can be particularly useful for the CISO in advancing his or her security strategy.

← Older revision		Revision as of 16:26, 6 November 2013
Line 260:		Line 260:
	Many of the security standards and tools (in OWASP and other bodies) can also be seen as focusing on parts of this framework.		Many of the security standards and tools (in OWASP and other bodies) can also be seen as focusing on parts of this framework.
	For example, staff training will enable the people to build their security understanding and do the right thing, while the various SDLC models can help an organization establish the right level of processes for its development and incident response mechanisms.		For example, staff training will enable the people to build their security understanding and do the right thing, while the various SDLC models can help an organization establish the right level of processes for its development and incident response mechanisms.
−
−	~~=== Benchmarking & maturity ===~~
−
−	One of the very first steps for a CISO is to understand his current situation by reviewing the current security maturity of his organization or the individual department and benchmark it against peers or his target security posture.
−
−	There are several maturity models published, with variations in focus and depth of detail. Usually they share a number of good practices and for a CISO it may be advisable to review whether his or her organization is already using one of the maturity models elsewhere and possibly align with this for an easier initial benchmark of the organization. In the medium term, the decision for which maturity model to use would be driven be question of: what level of detail is required, are we required by a regulatory body to use and report based on a specific type of maturity model, can our model be easily integrated with the organization’s culture and common reporting information requirements.
−
−	~~In the end, the author believes that most maturity models can equally fulfill your basic needs and that it will be up to the tactical judgment of the CISO to decide which model to use.~~
−
−	The Open SAMM maturity model has in the past been developed by OWASP and is a very mature ("stable") project, that offers a fairly lightweight way in analyzing your current security maturity and benchmarking your organization against your peers and your targets.
−	~~See also: Software Assurance Maturity Models (SAMM), OWASP, http://www.opensamm.org/~~
−	~~Other maturity models can be taken from BSIMM, CMM (Common Maturity Model), the ISO-2700x series~~
−
−	~~[[Category:OWASP Application Security Guide For CISO Project]]~~

@@ Line 261: / Line 261: @@
 For example, staff training will enable the people to build their security understanding and do the right thing, while the various SDLC models can help an organization establish the right level of processes for its development and incident response mechanisms.
-==== Benchmarking & maturity ====
+=== Benchmarking & maturity ===
 One of the very first steps for a CISO is to understand his current situation by reviewing the current security maturity of his organization or the individual department and benchmark it against peers or his target security posture.
 There are several maturity models published, with variations in focus and depth of detail. Usually they share a number of good practices and for a CISO it may be advisable to review whether his or her organization is already using one of the maturity models elsewhere and possibly align with this for an easier initial benchmark of the organization. In the medium term, the decision for which maturity model to use would be driven be question of: what level of detail is required, are we required by a regulatory body to use and report based on a specific type of maturity model, can our model be easily integrated with the organization’s culture and common reporting information requirements.

@@ Line 235: / Line 235: @@
 ===Project's categories===
-Usually OWASP projects are divided in either '''Tools''' or '''Documentation'''.
+Usually OWASP projects are divided in either Tools or Documentation. And by the category of use: Builders, Breakers and Defenders.
-And by the category of use: '''Protect''', '''Detect''' and '''Life Cycle'''.
+These categories can help the manager to quickly navigate the large portfolio of OWASP tools available and more easily find the right project for his current needs.
 === People, processes and technology ===

@@ Line 182: / Line 182: @@
 A security strategy should contain or enable the following components:<br>
 '''1. General guiding principles & priorities''' <br>
-What security investments will the organization make over the next x months. <br>(In general most companies use a time period of 12 – 24 months for their strategy definitions. It would be advisable to have a main security strategy defined for 12 months, with a second longer term planning component for between 2 and 5 years, depending on the type of organization, that outlines security investment plans for the longer term. Of course in today’s fast changing security arena, threats and risks can change very quickly and the plan should be adapted whenever underlying assumption change and be reviewed at least on a yearly basis.<br>
+What security investments will the organization make over the next x months. In general most companies use a time period of 12 – 24 months for their strategy definitions. It would be advisable to have a main security strategy defined for 12 months, with a second longer term planning component for between 2 and 5 years, depending on the type of organization, that outlines security investment plans for the longer term. Of course in today’s fast changing security arena, threats and risks can change very quickly and the plan should be adapted whenever underlying assumption change and be reviewed at least on a yearly basis.<br>
 '''2. Risk Management, risk acceptance levels''' <br>
 (see Part II)<br>