OWASP - User contributions [en]

REST Assessment Cheat Sheet

2017-02-13T09:41:17Z

Michaelbester: updated the link to: RESTful services - web security blind spot

__NOTOC__
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div>

{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
= About RESTful Web Services =
__TOC__{{TOC hidden}}

Web Services are an implementation of web technology used for machine to machine communication. As such they are used for Inter application communication, Web 2.0 and Mashups and by desktop and mobile applications to call a server. RESTful web services (often called simply REST) are a light weight variant of Web Services based on the RESTful design pattern. In practice RESTful web services utilizes HTTP requests that are similar to regular HTTP calls in contrast with other Web Services technologies such as SOAP which utilizes a complex protocol.

= Key relevant properties of RESTful web services =
* Use of HTTP methods (GET, POST, PUT and DELETE) as the primary verb for the requested operation.
* None standard parameters specifications:
** As part of the URL
** In headers
* Structured parameters and responses using JSON or XML in a parameter values, request body or response body. Those are required to communicate machine useful information.
* Custom authentication and session management, often utilizing custom security tokens: this is needed as machine to machine communication does not allow for login sequences.
* Lack of formal documentation. A [http://www.w3.org/Submission/wadl/ proposed standard for describing RESTful web services called WADL] was submitted by Sun Microsystems but was never officially adapted.

= The challenge of security testing RESTful web services =
* Inspecting the application does not reveal the attack surface, I.e. the URLs and parameter structure used by the RESTful web service. The reasons are:
** No application utilizes all the available functions and parameters exposed by the service
** Those used are often activated dynamically by client side code and not as links in pages.
** The client application is often not a web application and does not allow inspection of the activating link or even relevant code.
* The parameters are none standard making it hard to determine what is just part of the URL or a constant header and what is a parameter worth fuzzing.
* As a machine interface the number of parameters used can be very large, for example a JSON structure may include dozens of parameters. Fuzzing each one significantly lengthen the time required for testing.
* Custom authentication mechanisms require reverse engineering and make popular tools not useful as they cannot track a login session.

= How to pen test a RESTful web service? =
; Determine the attack surface through documentation - RESTful pen testing might be better off if some level of white box testing is allowed and you can get information about the service. This information will ensure fuller coverage of the attack surface. Such information to look for:
* Formal service description - While for other types of web services such as SOAP a formal description, usually in WSDL is often available, this is seldom the case for REST. That said, either WSDL 2.0 or WADL can describe REST and are sometimes used.
* A developer guide for using the service may be less detailed but will commonly be found, and might even be considered "black box"
* Application source or configuration - in many frameworks, including dotNet ,the REST service definition might be easily obtained from configuration files rather than from code.

; Collect full requests using a proxy - while always an important pen testing step, this is more important for REST based applications as the application UI may not give clues on the actual attack surface. Note that the proxy must be able to collect full requests and not just URLs as REST services utilize more than just GET parameters.

; Analyze collected requests to determine the attack surface:
* Look for non-standard parameters:
** Look for abnormal HTTP headers - those would many times be header based parameters.
** Determine if a URL segment has a repeating pattern across URLs. Such patterns can include a date, a number or an ID like string and indicate that the URL segment is a URL embedded parameter. For example: http://server/srv/2013-10-21/use.php
** Look for structured parameter values - those may be JSON, XML or a non-standard structure.
** If the last element of a URL does not have an extension, it may be a parameter. This is especially true if the application technology normally uses extensions or if a previous segment does have an extension. For example: http://server/svc/Grid.asmx/GetRelatedListItems
** Look for highly varying URL segments - a single URL segment that has many values may be parameter and not a physical directory. For example if the URL http://server/src/XXXX/page repeats with hundreds of value for XXXX, chances XXXX is a parameter.
; Verify non-standard parameters: in some cases (but not all), setting the value of a URL segment suspected of being a parameter to a value expected to be invalid can help determine if it is a path elements of a parameter. If a path element, the web server will return a 404 message, while for an invalid value to a parameter the answer would be an application level message as the value is legal at the web server level.

; Analyzing collected requests to optimize fuzzing - after identifying potential parameters to fuzz, analyze the collected values for each to determine -
* Valid vs. invalid values, so that fuzzing can focus on marginal invalid values. For example sending "0" for a value found to be always a positive integer.
* Sequences allowing to fuzz beyond the range presumably allocated to the current user.

; Lastly, when fuzzing, don't forget to emulate the authentication mechanism used.

= Related Resources =
* [[REST Security Cheat Sheet]] - the other side of this cheat sheet<br>
* [https://xiom.com/2016/10/31/restful-services-web-security-blind-spot/ RESTful services, web security blind spot] - a presentation (including video) elaborating on most of the topics on this cheat sheet.

= Authors and Primary Editors =

Ofer Shezaf - ofer@shezaf.com<br/>

== Other Cheatsheets ==

{{Cheatsheet_Navigation_Body}}

|}

[[Category:Cheatsheets]]

Secure SDLC Cheat Sheet

2015-11-09T15:25:21Z

Michaelbester: /* How to Apply */

= DRAFT CHEAT SHEET - WORK IN PROGRESS =

= Background =

This cheat sheet provides a quick reference on the most important initiatives to build security into multiple parts of software development processes. This cheat sheet is based on the OWASP Software Assurance Maturity Model (SAMM) which can be integrated into any existing SDLC.

SAMM is based around a set of 12 security practices, which are grouped into 4 business functions. Every security practice contains a set of activities, structured into 3 maturity levels. The activities on a lower maturity level are typically easier to execute and require less formalization than the ones on a higher maturity level.

The structure and setup of the '''SAMM maturity model''' are made to support:
# The '''assessment''' of the current software assurance posture
# The definition of the '''strategy''' (i.e. the target) that the organization should take
# The formulation of an implementation '''roadmap''' of how to get there and
# Prescriptive advice on how to '''implement''' particular activities.

In that sense, the value of SAMM lies in providing a means to know where your organization is on its journey towards software assurance, and to understand what is recommended to move to a next level of maturity. Note that SAMM does not insist that all organizations achieve maturity level 3 in every category. Indeed, you determine the target maturity level for each Security Practice that is the best fit for your organization and its needs. SAMM provides a number of templates for typical organizations to this end, but you can adapt these as you see fit.

= How to Apply =

A typical approach of using SAMM in an organization is as follows:

{| class="wikitable"
! scope="col" | Step
! scope="col" | Purpose
! scope="col" | Activities
! scope="col" | Resources
! scope="col" | Best Practices
|-
| Step 1 - '''Assess'''
| Ensure a proper start of the project
| '''Define the scope'''
Set the target of the effort (The entire enterprise, a particular application or project or team etc.)

'''Identify Stakeholders'''

Ensure that important stakeholders supposed to support and execute the project are identified and well aligned

'''Spread the word'''

Inform people about the initiative and provide them with information to understand what you will be doing
| '''Consider involving at least:'''
* Executive Sponsor
* Security Team
* Developers
* Architects
* Business Owners
* QA Testers
* Managers

The OpenSAMM main site: http://www.opensamm.org/

The model in .pdf: http://www.opensamm.org/
| Pre-screen software development maturity to have realistic expectations The smaller the scope, the easier the exercise
|-
| Step 2 - '''Assess'''
| Identify and understand the maturity of your chosen scope in each of the 12 software security practices
| '''Evaluate current practices'''
Organize interviews with relevant stakeholders to understand the current state of practice within your organization. You could evaluate this yourself if you understand the organization sufficiently well. SAMM provides lightweight and detailed assessments (where the latter is an evidence-based evaluation) – use the detailed one only if you want to have absolute certainty about the scores.

'''Determine maturity level'''

Based on the outcome of the previous activity, determine for each security practice the maturity level according to the SAMM maturity scoring system. In a nutshell, when all activities below and within a maturity level have
been implemented, this level can be used for the overall score. When extra higher-level activities have been implemented without reaching a full next level, add a “+” to the rating.
| The OpenSAMM toolbox http://LINK

Online Self Assessment Tool

https://ssa.asteriskinfosec.com.au

Both of these resources provide you with:
* Assessment questions
* Maturity level calculation
| Ensure consistent assessment for different stakeholders and teams by using the same questions and interviewer
Consider using different formats to gather data (e.g., workshops vs. interviews.
Ensure interviewees understand the particularities of activities.
Understand which activities are not applicable to the organization and take this into account in the overall scoring.
Anticipate/document whether you plan to award partial credit, or just document various judgement calls.
Repeat questions to several people to improve the assessment quality Consider making interviews anonymous to ensure honesty Don’t take questions too literally)
|-
| Step 3 - '''Set the target'''
| Develop a target score that you can use as a measuring stick to guide you to act on the “most important” activities for your situation
| '''Define the target'''

Set or update the target by identifying which activities your organization should implement ideally. Typically this will include more lower-level than higher-level activities. Predefined roadmap templates can be used as a source for inspiration. Ensure that the total set of selected activities makes sense and take into account dependencies between activities.

'''Estimate overall impact'''

Estimate the impact of the chosen target on the organization. Try to express in budgetary arguments.
| See the How-To-Guide for predefined templates Software Assurance Maturity Model (SAMM) Roadmap Chart Worksheet (part of the OpenSAMM Benchmarking as a comparative source)
| Take into account the organisation’s risk profile Respect dependencies between activities As a rough measure, the overall impact of a software assurance effort is estimated at 5 to 10% of the total development cost.
|-
| Step 4 - '''Define the plan'''
| Develop or update your plan to take your organization to the next level
| '''Determine change schedule'''
Choose a realistic change strategy in terms of number and duration of phases. A typical roadmap consists of 4-6 phases of 3 to 12 months.

'''Develop / Update the roadmap plan'''

Distribute the implementation of additional activities over the different roadmap phases, taking into account the effort required to implement them.. Try to balance the implementation effort over the different periods, and take dependencies between activities into account
| Software Assurance Maturity Model : A guide to building security into software development page 33:
http://www.opensamm.org/

Project Plan
http://www.opensamm.org/downloads/
| Identify quick wins and plan them early on Start with awareness/training Adapt to coming release cycles / key projects
|-
| Step 5 - '''Implement'''
| Work the plan
| '''Implement activities'''
Implement all activities that are part of this period. Consider their impact on processes, people, knowledge and tools. The SAMM model contains prescriptive advice on how to do this. OWASP projects may help to facilitate
this.
| Useful OWASP resources per activity are described at https://www.owasp.org
| Treat legacy software separately. Do not mandate migration unless really important. Avoid operational bottle-necks (in particular for the security team)
|-
| Step 6 - '''Roll out'''
| Ensure that improvements are available and effectively used within the organization
| '''Evangelize Improvements'''
Make the steps and improvements visible for everyone involved by organizing training and communicating.

'''Measure effectiveness'''

Measure the adoption and effectiveness of implemented improvements by analyzing usage and impact.
|
| Categorize applications according to their impact on the organization. Focus on high-impact applications. Use team champions to spread new activities throughout the organization
|}

As part of a quick start effort, the first four phases (preparation, assess, setting the target and defining the plan) can be executed by a single person in a limited amount of time (1 to 2 days). Making sure that this is supported in the organization, as well as the implementation and roll-out phases typically require much more time to execute.

= Final Notes =
The best way to grasp SAMM is to start using it. This document has presented a number of concrete steps and supportive material to execute these. Now it’s your turn. We warmly invite you to spend a day or two on following the first steps, and you will quickly understand and appreciate the added value of the model. Enjoy! Suggestions for improvements are very welcome. And if you’re interested, consider to join the mailinglist or become part of the OpenSAMM community

----

{{Cheatsheet_Navigation}}

[[Category:Cheatsheets]] [[Category:OWASP_Builders]]

Secure SDLC Cheat Sheet

2015-11-09T15:24:21Z

Michaelbester: /* Background */

= DRAFT CHEAT SHEET - WORK IN PROGRESS =

= Background =

This cheat sheet provides a quick reference on the most important initiatives to build security into multiple parts of software development processes. This cheat sheet is based on the OWASP Software Assurance Maturity Model (SAMM) which can be integrated into any existing SDLC.

SAMM is based around a set of 12 security practices, which are grouped into 4 business functions. Every security practice contains a set of activities, structured into 3 maturity levels. The activities on a lower maturity level are typically easier to execute and require less formalization than the ones on a higher maturity level.

The structure and setup of the '''SAMM maturity model''' are made to support:
# The '''assessment''' of the current software assurance posture
# The definition of the '''strategy''' (i.e. the target) that the organization should take
# The formulation of an implementation '''roadmap''' of how to get there and
# Prescriptive advice on how to '''implement''' particular activities.

In that sense, the value of SAMM lies in providing a means to know where your organization is on its journey towards software assurance, and to understand what is recommended to move to a next level of maturity. Note that SAMM does not insist that all organizations achieve maturity level 3 in every category. Indeed, you determine the target maturity level for each Security Practice that is the best fit for your organization and its needs. SAMM provides a number of templates for typical organizations to this end, but you can adapt these as you see fit.

= How to Apply =

A typical approach of using SAMM in an organization is as follows:

{| class="wikitable"
! scope="col" | Step
! scope="col" | Purpose
! scope="col" | Activities
! scope="col" | Resources
! scope="col" | Best Practices
|-
| Step 1 - '''Assess'''
| Ensure a proper start of the project
| '''Define the scope'''
Set the target of the effort (The entire enterprise, a particular application or project or team etc.)

'''Identify Stakeholders'''
Ensure that important stakeholders supposed to support and execute the project are identified and well aligned

'''Spread the word'''
Inform people about the initiative and provide them with information to understand what you will be doing
| '''Consider involving at least:'''
* Executive Sponsor
* Security Team
* Developers
* Architects
* Business Owners
* QA Testers
* Managers

The OpenSAMM main site: http://www.opensamm.org/

The model in .pdf: http://www.opensamm.org/
| Pre-screen software development maturity to have realistic expectations The smaller the scope, the easier the exercise
|-
| Step 2 - '''Assess'''
| Identify and understand the maturity of your chosen scope in each of the 12 software security practices
| '''Evaluate current practices'''
Organize interviews with relevant stakeholders to understand the current state of practice within your organization. You could evaluate this yourself if you understand the organization sufficiently well. SAMM provides lightweight and detailed assessments (where the latter is an evidence-based evaluation) – use the detailed one only if you want to have absolute certainty about the scores.

'''Determine maturity level'''

Based on the outcome of the previous activity, determine for each security practice the maturity level according to the SAMM maturity scoring system. In a nutshell, when all activities below and within a maturity level have
been implemented, this level can be used for the overall score. When extra higher-level activities have been implemented without reaching a full next level, add a “+” to the rating.
| The OpenSAMM toolbox http://LINK

Online Self Assessment Tool

https://ssa.asteriskinfosec.com.au

Both of these resources provide you with:
* Assessment questions
* Maturity level calculation
| Ensure consistent assessment for different stakeholders and teams by using the same questions and interviewer
Consider using different formats to gather data (e.g., workshops vs. interviews.
Ensure interviewees understand the particularities of activities.
Understand which activities are not applicable to the organization and take this into account in the overall scoring.
Anticipate/document whether you plan to award partial credit, or just document various judgement calls.
Repeat questions to several people to improve the assessment quality Consider making interviews anonymous to ensure honesty Don’t take questions too literally)
|-
| Step 3 - '''Set the target'''
| Develop a target score that you can use as a measuring stick to guide you to act on the “most important” activities for your situation
| '''Define the target'''

Set or update the target by identifying which activities your organization should implement ideally. Typically this will include more lower-level than higher-level activities. Predefined roadmap templates can be used as a source for inspiration. Ensure that the total set of selected activities makes sense and take into account dependencies between activities.

'''Estimate overall impact'''

Estimate the impact of the chosen target on the organization. Try to express in budgetary arguments.
| See the How-To-Guide for predefined templates Software Assurance Maturity Model (SAMM) Roadmap Chart Worksheet (part of the OpenSAMM Benchmarking as a comparative source)
| Take into account the organisation’s risk profile Respect dependencies between activities As a rough measure, the overall impact of a software assurance effort is estimated at 5 to 10% of the total development cost.
|-
| Step 4 - '''Define the plan'''
| Develop or update your plan to take your organization to the next level
| '''Determine change schedule'''
Choose a realistic change strategy in terms of number and duration of phases. A typical roadmap consists of 4-6 phases of 3 to 12 months.

'''Develop / Update the roadmap plan'''

Distribute the implementation of additional activities over the different roadmap phases, taking into account the effort required to implement them.. Try to balance the implementation effort over the different periods, and take dependencies between activities into account
| Software Assurance Maturity Model : A guide to building security into software development page 33:
http://www.opensamm.org/

Project Plan
http://www.opensamm.org/downloads/
| Identify quick wins and plan them early on Start with awareness/training Adapt to coming release cycles / key projects
|-
| Step 5 - '''Implement'''
| Work the plan
| '''Implement activities'''
Implement all activities that are part of this period. Consider their impact on processes, people, knowledge and tools. The SAMM model contains prescriptive advice on how to do this. OWASP projects may help to facilitate
this.
| Useful OWASP resources per activity are described at https://www.owasp.org
| Treat legacy software separately. Do not mandate migration unless really important. Avoid operational bottle-necks (in particular for the security team)
|-
| Step 6 - '''Roll out'''
| Ensure that improvements are available and effectively used within the organization
| '''Evangelize Improvements'''
Make the steps and improvements visible for everyone involved by organizing training and communicating.

'''Measure effectiveness'''

Measure the adoption and effectiveness of implemented improvements by analyzing usage and impact.
|
| Categorize applications according to their impact on the organization. Focus on high-impact applications. Use team champions to spread new activities throughout the organization
|}

As part of a quick start effort, the first four phases (preparation, assess, setting the target and defining the plan) can be executed by a single person in a limited amount of time (1 to 2 days). Making sure that this is supported in the organization, as well as the implementation and roll-out phases typically require much more time to execute.

= Final Notes =
The best way to grasp SAMM is to start using it. This document has presented a number of concrete steps and supportive material to execute these. Now it’s your turn. We warmly invite you to spend a day or two on following the first steps, and you will quickly understand and appreciate the added value of the model. Enjoy! Suggestions for improvements are very welcome. And if you’re interested, consider to join the mailinglist or become part of the OpenSAMM community

----

{{Cheatsheet_Navigation}}

[[Category:Cheatsheets]] [[Category:OWASP_Builders]]

Secure SDLC Cheat Sheet

2015-11-02T18:00:32Z

Michaelbester:

= DRAFT CHEAT SHEET - WORK IN PROGRESS =

= Background =

This cheat sheet provides a quick reference on the most important initiatives to build security into multiple parts of software development processes. This cheat sheet is based on the OWASP Software Assurance Maturity Model (SAMM) which can be integrated into any existing SDLC.

SAMM is based around a set of 12 security practices, which are grouped into 4 business functions. Every security practice contains a set of activities, structured into 3 maturity levels. The activities on a lower maturity level are typically easier to execute and require less formalization than the ones on a higher maturity level.

The structure and setup of the '''SAMM maturity model''' are made to support (i) the '''assessment''' of the current software assurance posture, (ii) the definition of the '''strategy''' (i.e. the target) that the organization should take, (iii) the formulation of an implementation '''roadmap''' of how to get there and (iv) prescriptive advice on how to '''implement''' particular activities.

In that sense, the value of SAMM lies in providing a means to know where your organization is on its journey towards software assurance, and to understand what is recommended to move to a next level of maturity. Note that SAMM does not insist that all organizations achieve maturity level 3 in every category. Indeed, you determine the target maturity level for each Security Practice that is the best fit for your organization and its needs. SAMM provides a number of templates for typical organizations to this end, but you can adapt these as you see fit.

= How to Apply =

A typical approach of using SAMM in an organization is as follows:

{| class="wikitable"
! scope="col" | Step
! scope="col" | Purpose
! scope="col" | Activities
! scope="col" | Resources
! scope="col" | Best Practices
|-
| Step 1 - '''Assess'''
| Ensure a proper start of the project
| '''Define the scope'''
Set the target of the effort (The entire enterprise, a particular application or project or team etc.)

'''Identify Stakeholders'''
Ensure that important stakeholders supposed to support and execute the project are identified and well aligned

'''Spread the word'''
Inform people about the initiative and provide them with information to understand what you will be doing
| '''Consider involving at least:'''
* Executive Sponsor
* Security Team
* Developers
* Architects
* Business Owners
* QA Testers
* Managers

The OpenSAMM main site: http://www.opensamm.org/

The model in .pdf: http://www.opensamm.org/
| Pre-screen software development maturity to have realistic expectations The smaller the scope, the easier the exercise
|-
| Step 2 - '''Assess'''
| Identify and understand the maturity of your chosen scope in each of the 12 software security practices
| '''Evaluate current practices'''
Organize interviews with relevant stakeholders to understand the current state of practice within your organization. You could evaluate this yourself if you understand the organization sufficiently well. SAMM provides lightweight and detailed assessments (where the latter is an evidence-based evaluation) – use the detailed one only if you want to have absolute certainty about the scores.

'''Determine maturity level'''

Based on the outcome of the previous activity, determine for each security practice the maturity level according to the SAMM maturity scoring system. In a nutshell, when all activities below and within a maturity level have
been implemented, this level can be used for the overall score. When extra higher-level activities have been implemented without reaching a full next level, add a “+” to the rating.
| The OpenSAMM toolbox http://LINK

Online Self Assessment Tool

https://ssa.asteriskinfosec.com.au

Both of these resources provide you with:
* Assessment questions
* Maturity level calculation
| Ensure consistent assessment for different stakeholders and teams by using the same questions and interviewer
Consider using different formats to gather data (e.g., workshops vs. interviews.
Ensure interviewees understand the particularities of activities.
Understand which activities are not applicable to the organization and take this into account in the overall scoring.
Anticipate/document whether you plan to award partial credit, or just document various judgement calls.
Repeat questions to several people to improve the assessment quality Consider making interviews anonymous to ensure honesty Don’t take questions too literally)
|-
| Step 3 - '''Set the target'''
| Develop a target score that you can use as a measuring stick to guide you to act on the “most important” activities for your situation
| '''Define the target'''

Set or update the target by identifying which activities your organization should implement ideally. Typically this will include more lower-level than higher-level activities. Predefined roadmap templates can be used as a source for inspiration. Ensure that the total set of selected activities makes sense and take into account dependencies between activities.

'''Estimate overall impact'''

Estimate the impact of the chosen target on the organization. Try to express in budgetary arguments.
| See the How-To-Guide for predefined templates Software Assurance Maturity Model (SAMM) Roadmap Chart Worksheet (part of the OpenSAMM Benchmarking as a comparative source)
| Take into account the organisation’s risk profile Respect dependencies between activities As a rough measure, the overall impact of a software assurance effort is estimated at 5 to 10% of the total development cost.
|-
| Step 4 - '''Define the plan'''
| Develop or update your plan to take your organization to the next level
| '''Determine change schedule'''
Choose a realistic change strategy in terms of number and duration of phases. A typical roadmap consists of 4-6 phases of 3 to 12 months.

'''Develop / Update the roadmap plan'''

Distribute the implementation of additional activities over the different roadmap phases, taking into account the effort required to implement them.. Try to balance the implementation effort over the different periods, and take dependencies between activities into account
| Software Assurance Maturity Model : A guide to building security into software development page 33:
http://www.opensamm.org/

Project Plan
http://www.opensamm.org/downloads/
| Identify quick wins and plan them early on Start with awareness/training Adapt to coming release cycles / key projects
|-
| Step 5 - '''Implement'''
| Work the plan
| '''Implement activities'''
Implement all activities that are part of this period. Consider their impact on processes, people, knowledge and tools. The SAMM model contains prescriptive advice on how to do this. OWASP projects may help to facilitate
this.
| Useful OWASP resources per activity are described at https://www.owasp.org
| Treat legacy software separately. Do not mandate migration unless really important. Avoid operational bottle-necks (in particular for the security team)
|-
| Step 6 - '''Roll out'''
| Ensure that improvements are available and effectively used within the organization
| '''Evangelize Improvements'''
Make the steps and improvements visible for everyone involved by organizing training and communicating.

'''Measure effectiveness'''

Measure the adoption and effectiveness of implemented improvements by analyzing usage and impact.
|
| Categorize applications according to their impact on the organization. Focus on high-impact applications. Use team champions to spread new activities throughout the organization
|}

As part of a quick start effort, the first four phases (preparation, assess, setting the target and defining the plan) can be executed by a single person in a limited amount of time (1 to 2 days). Making sure that this is supported in the organization, as well as the implementation and roll-out phases typically require much more time to execute.

= Final Notes =
The best way to grasp SAMM is to start using it. This document has presented a number of concrete steps and supportive material to execute these. Now it’s your turn. We warmly invite you to spend a day or two on following the first steps, and you will quickly understand and appreciate the added value of the model. Enjoy! Suggestions for improvements are very welcome. And if you’re interested, consider to join the mailinglist or become part of the OpenSAMM community

----

{{Cheatsheet_Navigation}}

[[Category:Cheatsheets]] [[Category:OWASP_Builders]]

Secure SDLC Cheat Sheet

2015-11-02T18:00:05Z

Michaelbester: Made changes as per OPENSAMM v1.1 Quick Start guide.

= DRAFT CHEAT SHEET - WORK IN PROGRESS =

= Background =

This cheat sheet provides a quick reference on the most important initiatives to build security into multiple parts of software development processes. This cheat sheet is based on the OWASP Software Assurance Maturity Model (SAMM) which can be integrated into any existing SDLC.

SAMM is based around a set of 12 security practices, which are grouped into 4 business functions. Every security practice contains a set of activities, structured into 3 maturity levels. The activities on a lower maturity level are typically easier to execute and require less formalization than the ones on a higher maturity level.

The structure and setup of the '''SAMM maturity model''' are made to support (i) the '''assessment''' of the current software assurance posture, (ii) the definition of the '''strategy''' (i.e. the target) that the organization should take, (iii) the formulation of an implementation '''roadmap''' of how to get there and (iv) prescriptive advice on how to '''implement''' particular activities.

In that sense, the value of SAMM lies in providing a means to know where your organization is on its journey towards software assurance, and to understand what is recommended to move to a next level of maturity. Note that SAMM does not insist that all organizations achieve maturity level 3 in every category. Indeed, you determine the target maturity level for each Security Practice that is the best fit for your organization and its needs. SAMM provides a number of templates for typical organizations to this end, but you can adapt these as you see fit.

= How to Apply =

A typical approach of using SAMM in an organization is as follows:

{| class="wikitable"
! scope="col" | Step
! scope="col" | Purpose
! scope="col" | Activities
! scope="col" | Resources
! scope="col" | Best Practices
|-
| Step 1 - '''Assess'''
| Ensure a proper start of the project
| '''Define the scope'''
Set the target of the effort (The entire enterprise, a particular application or project or team etc.)

'''Identify Stakeholders'''
Ensure that important stakeholders supposed to support and execute the project are identified and well aligned

'''Spread the word'''
Inform people about the initiative and provide them with information to understand what you will be doing
| '''Consider involving at least:'''
* Executive Sponsor
* Security Team
* Developers
* Architects
* Business Owners
* QA Testers
* Managers

The OpenSAMM main site: http://www.opensamm.org/

The model in .pdf: http://www.opensamm.org/
| Pre-screen software development maturity to have realistic expectations The smaller the scope, the easier the exercise
|-
| Step 2 - '''Assess'''
| Identify and understand the maturity of your chosen scope in each of the 12 software security practices
| '''Evaluate current practices'''
Organize interviews with relevant stakeholders to understand the current state of practice within your organization. You could evaluate this yourself if you understand the organization sufficiently well. SAMM provides lightweight and detailed assessments (where the latter is an evidence-based evaluation) – use the detailed one only if you want to have absolute certainty about the scores.

'''Determine maturity level'''

Based on the outcome of the previous activity, determine for each security practice the maturity level according to the SAMM maturity scoring system. In a nutshell, when all activities below and within a maturity level have
been implemented, this level can be used for the overall score. When extra higher-level activities have been implemented without reaching a full next level, add a “+” to the rating.
| The OpenSAMM toolbox http://LINK

Online Self Assessment Tool

https://ssa.asteriskinfosec.com.au

Both of these resources provide you with:
* Assessment questions
* Maturity level calculation
| Ensure consistent assessment for different stakeholders and teams by using the same questions and interviewer
Consider using different formats to gather data (e.g., workshops vs. interviews.
Ensure interviewees understand the particularities of activities.
Understand which activities are not applicable to the organization and take this into account in the overall scoring.
Anticipate/document whether you plan to award partial credit, or just document various judgement calls.
Repeat questions to several people to improve the assessment quality Consider making interviews anonymous to ensure honesty Don’t take questions too literally)
|-
| Step 3 - '''Set the target'''
| Develop a target score that you can use as a measuring stick to guide you to act on the “most important” activities for your situation
| '''Define the target'''

Set or update the target by identifying which activities your organization should implement ideally. Typically this will include more lower-level than higher-level activities. Predefined roadmap templates can be used as a source for inspiration. Ensure that the total set of selected activities makes sense and take into account dependencies between activities.

'''Estimate overall impact'''

Estimate the impact of the chosen target on the organization. Try to express in budgetary arguments.
| See the How-To-Guide for predefined templates Software Assurance Maturity Model (SAMM) Roadmap Chart Worksheet (part of the OpenSAMM Benchmarking as a comparative source)
| Take into account the organisation’s risk profile Respect dependencies between activities As a rough measure, the overall impact of a software assurance effort is estimated at 5 to 10% of the total development cost.
|-
| Step 4 - '''Define the plan'''
| Develop or update your plan to take your organization to the next level
| '''Determine change schedule'''
Choose a realistic change strategy in terms of number and duration of phases. A typical roadmap consists of 4-6 phases of 3 to 12 months.

'''Develop / Update the roadmap plan'''

Distribute the implementation of additional activities over the different roadmap phases, taking into account the effort required to implement them.. Try to balance the implementation effort over the different periods, and take dependencies between activities into account
| Software Assurance Maturity Model : A guide to building security into software development page 33:
http://www.opensamm.org/

Project Plan
http://www.opensamm.org/downloads/
| Identify quick wins and plan them early on Start with awareness/training Adapt to coming release cycles / key projects
|-
| Step 5 - '''Implement'''
| Work the plan
| '''Implement activities'''
Implement all activities that are part of this period. Consider their impact on processes, people, knowledge and tools. The SAMM model contains prescriptive advice on how to do this. OWASP projects may help to facilitate
this.
| Useful OWASP resources per activity are described at https://www.owasp.org
| Treat legacy software separately. Do not mandate migration unless really important. Avoid operational bottle-necks (in particular for the security team)
|-
| Step 6 - '''Roll out'''
| Ensure that improvements are available and effectively used within the organization
| '''Evangelize Improvements'''
Make the steps and improvements visible for everyone involved by organizing training and communicating.

'''Measure effectiveness'''

Measure the adoption and effectiveness of implemented improvements by analyzing usage and impact.
|
| Categorize applications according to their impact on the organization. Focus on high-impact applications. Use team champions to spread new activities throughout the organization
|}

As part of a quick start effort, the first four phases (preparation, assess, setting the target and defining the plan) can be executed by a single person in a limited amount of time (1 to 2 days). Making sure that this is supported in the organization, as well as the implementation and roll-out phases typically require much more time to execute.

= Final Notes =
The best way to grasp SAMM is to start using it. This document has presented a number of concrete steps and supportive material to execute these. Now it’s your turn. We warmly invite you to spend a day or two on following the first steps, and you will quickly understand and appreciate the added value of the model. Enjoy! Suggestions for improvements are very welcome. And if you’re interested, consider to join the mailinglist or become part of the OpenSAMM community

{{Cheatsheet_Navigation}}

[[Category:Cheatsheets]] [[Category:OWASP_Builders]]

Secure SDLC Cheat Sheet

2015-11-02T17:18:49Z

Michaelbester: /* Introduction */

= DRAFT CHEAT SHEET - WORK IN PROGRESS =

= Introduction =

This cheat sheet provides a quick reference on the most important initiatives to build security into multiple parts of software development processes. This cheat sheet is based on the OWASP Software Assurance Maturity Model (SAMM) which can be integrated into any existing SDLC.

SAMM is based around a set of 12 security practices, which are grouped into 4 business functions. Every security practice contains a set of activities, structured into 3 maturity levels. The activities on a lower maturity level are typically easier to execute and require less formalization than the ones on a higher maturity level.

= Purpose =

More mature organisations undertake software assurance activities across a wider spectrum of steps, and generally earlier, than less mature organisations. This has been shown to identify more vulnerabilities sooner, have then corrected at less cost, prevent them being re-introduced more effectively, reduce the number of vulnerabilities in production environments, and reduce the number of security incidents including data breaches.

...???

= Implementing a secure software development life cycle (S-SDLC) =

== Development methodology ==

Waterfall, iterative, agile...???

Whatever your development methodology, organizational culture, types of application and risk profile, this document provides a technology agnostic summary of recommendations to include within your own S-SDLC.

== Do these first ==

The items summarize the activities detailed in Open SAMM to meet level 1 maturity. It may not be appropriate to aim for level 1 across all these business practices and each organization should review the specific objectives, activities and expected results to determine how and what items to include in their own programmes. The presentation ordering is not significant.

=== Education & guidance ===

???

=== Security requirements ===

???

=== Code review ===

???

== A Plan to Achieve Level 1 Maturity ==

To have a well-rounded S-SDLC that builds security into many stages of the development lifecycle, consider whether these SAMM Level 1 practices can all be covered.

=== Strategy & metrics ===

* Assess and rank how applications add risk
* Implement a software assurance programme and build a roadmap for future improvement
* Promote understanding of the programme

=== Policy & compliance ===

* Research and identify software & data compliance requirements
* Create guidance on how to meet the mandatory compliance requirements
* Ensure the guidance is used by project teams
* Review projects against the compliance requirements
* Regularly review and update the requirements and guidance

=== Education & guidance ===

* Provide developers high-level technical security awareness training
* Create technology-specific best-practice secure development guidance
* Brief existing staff and new starters about the guidance and its expected usage
* Undertake qualitative testing of security guidance knowledge

=== Threat assessment ===

* Examine and document the likely threats to the organisation and each application type
* Build threat models
* Develop attacker profiles defining their type and motivations

=== Security requirements ===

* Review projects and specify security requirements based on functionality
* Analyze the compliance and best-practice security guidance documents to derive additional requirements
* Ensure requirements are specific, measurable and reasonable

=== Secure architecture ===

* Create and maintain a list of recommended software frameworks, services and other software components
* Develop a list of guiding security principles as a checklist against detailed designs
* Distribute, promote and apply the design principles to new projects

=== Design review ===

* Identify the entry points (attack surface/defense perimeter) in software designs
* Analyze software designs against the known security risks

=== Code review ===

* Create code review checklists based on common problems
* Encourage the use of the checklists by each team member
* Review selected high-risk code more formally
* Consider utilizing automated code analysis tools for some checks

=== Security testing ===

* Specify security test cases based on known requirements and common vulnerabilities
* Perform application penetration testing before each major release
* Review test results and correct, or formally accept the risks of releasing with failed checks

=== Vulnerability management ===

* Define an application security point of contact for each project
* Create an informal security response team
* Develop an initial incident response process

=== Environment hardening ===

* Create and maintain specifications for application host environments
* Monitor sources for information about security upgrades and patches for all software supporting or within the applications
* Implement processes to test and apply critical security fixes

=== Operational enablement ===

* Record important software-specific knowledge that affects the deployed application's security
* Inform operators/users as appropriate of this understandable/actionable information
* Provide guidance on handling expected security-related alerts and error conditions

== Do more ==

Is level 1 the correct goal? Perhaps your organization is already doing more than these? Perhaps it should do more, or less. Read SAMM, and benchmark existing activities using the scorecard. Use the information resources listed below to help develop your own programme, guidance and tools.

= Related articles =

OWASP [http://www.opensamm.org/ Open Software Assurance Maturity Model (SAMM)] and [http://www.opensamm.org/download/ Downloads (Model, mappings, assessment templates, worksheet, project plan, tracking software, charts and graphics)]

OWASP [https://www.owasp.org/index.php/Category:OWASP_CLASP_Project Comprehensive, Lightweight Application Security Process (CLASP)]

OWASP [https://www.owasp.org/ Open Web Application Security Project (OWASP)], [https://www.owasp.org/index.php/OWASP_Secure_Coding_Practices_-_Quick_Reference_Guide Security requirements], [https://www.owasp.org/index.php/Cheat_Sheets Cheat sheets], [https://www.owasp.org/index.php/OWASP_Guide_Project Development Guide], [https://www.owasp.org/index.php/Category:OWASP_Code_Review_Project Code Review Guide], [https://www.owasp.org/index.php/OWASP_Testing_Project Testing Guide] , [https://www.owasp.org/index.php/Category:OWASP_Application_Security_Verification_Standard_Project Application Security Verification Standard (ASVS)] and [https://www.owasp.org/index.php/Category:OWASP_Tool Tools]

OWASP [https://www.owasp.org/index.php/OWASP_Podcast Application security podcast] and [https://www.owasp.org/index.php/OWASP_Appsec_Tutorial_Series AppSec Tutorial Series]

BITS [http://www.bits.org/publications/security/BITSSoftwareAssurance0112.pdf Financial Services Roundtable BITS Software Assurance Framework]

CMU [http://www.cert.org/secure-coding/secure.html Team Software Process for Secure Systems Development (TSP Secure)]

DACS/IATAC [http://iac.dtic.mil/iatac/download/security.pdf Software Security Assurance State of the Art Report]

ENISA [http://www.enisa.europa.eu/act/application-security/secure-software-engineering/secure-software-engineering-initiatives Secure Software Engineering Initiatives]

ISO/IEC [http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=44378 ISO/IEC 27034 Application Security]

NIST [http://csrc.nist.gov/publications/nistpubs/800-64-Rev2/SP800-64-Revision2.pdf SP 800-64 Rev2 Security Considerations in the Information System Development Life Cycle]

SAFECode [http://www.safecode.org/publications/SAFECode_Agile_Dev_Security0712.pdf Practical Security Stories and Security Tasks for Agile Development Environments]

US DoHS [https://buildsecurityin.us-cert.gov/bsi/home.html Building Security In] and [https://buildsecurityin.us-cert.gov/swa/resources.html Software Assurance Resources]

Other [http://www.sdlc.ws/ sdlc] and [http://www.sdlc.ws/software-testing-life-cycle-stlc-complete-tutorial/ Software Testing Life Cycle], [http://www.sdlc.ws/category/models/ sdlc models]

Other [http://bsimm.com/ Building Security In Maturity Model (BSIMM)]

Other [http://www.microsoft.com/security/sdl/default.aspx Microsoft Security Development Lifecycle (SDL)] and [http://go.microsoft.com/?linkid=9767361 Process guidance v5.1], [http://go.microsoft.com/?linkid=9708425 Simplified implementation]

Other [http://www.oracle.com/us/support/assurance/index.html Oracle Software Security Assurance (OSSA)]

= Authors and primary contributors =

This cheat sheet is largely based on infortmation from OWASP SAMM v1.0 originally written by Pravir Chandra - chandra[at]owasp.org

The cheat sheet was created by:

Colin Watson - colin.watson[at]owasp.org

{{Cheatsheet_Navigation}}

[[Category:Cheatsheets]] [[Category:OWASP_Builders]]

Secure SDLC Cheat Sheet

2015-10-05T11:48:02Z

Michaelbester: /* Introduction */

= DRAFT CHEAT SHEET - WORK IN PROGRESS =

= Introduction =

This cheat sheet provides an "at a glance" quick reference on the most important initiatives to build security into multiple parts of software development processes. This cheat sheet is based on the OWASP Software Assurance Maturity Model (SAMM) which can be integrated into any existing SDLC.

SAMM is based around a set of 12 security practices, which are grouped into 4 business functions. Every security practice contains a set of activities, structured into 3 maturity levels. The activities on a lower maturity level are typically easier to execute and require less formalization than the ones on a higher maturity level.

= Purpose =

More mature organisations undertake software assurance activities across a wider spectrum of steps, and generally earlier, than less mature organisations. This has been shown to identify more vulnerabilities sooner, have then corrected at less cost, prevent them being re-introduced more effectively, reduce the number of vulnerabilities in production environments, and reduce the number of security incidents including data breaches.

...???

= Implementing a secure software development life cycle (S-SDLC) =

== Development methodology ==

Waterfall, iterative, agile...???

Whatever your development methodology, organizational culture, types of application and risk profile, this document provides a technology agnostic summary of recommendations to include within your own S-SDLC.

== Do these first ==

The items summarize the activities detailed in Open SAMM to meet level 1 maturity. It may not be appropriate to aim for level 1 across all these business practices and each organization should review the specific objectives, activities and expected results to determine how and what items to include in their own programmes. The presentation ordering is not significant.

=== Education & guidance ===

???

=== Security requirements ===

???

=== Code review ===

???

== A Plan to Achieve Level 1 Maturity ==

To have a well-rounded S-SDLC that builds security into many stages of the development lifecycle, consider whether these SAMM Level 1 practices can all be covered.

=== Strategy & metrics ===

* Assess and rank how applications add risk
* Implement a software assurance programme and build a roadmap for future improvement
* Promote understanding of the programme

=== Policy & compliance ===

* Research and identify software & data compliance requirements
* Create guidance on how to meet the mandatory compliance requirements
* Ensure the guidance is used by project teams
* Review projects against the compliance requirements
* Regularly review and update the requirements and guidance

=== Education & guidance ===

* Provide developers high-level technical security awareness training
* Create technology-specific best-practice secure development guidance
* Brief existing staff and new starters about the guidance and its expected usage
* Undertake qualitative testing of security guidance knowledge

=== Threat assessment ===

* Examine and document the likely threats to the organisation and each application type
* Build threat models
* Develop attacker profiles defining their type and motivations

=== Security requirements ===

* Review projects and specify security requirements based on functionality
* Analyze the compliance and best-practice security guidance documents to derive additional requirements
* Ensure requirements are specific, measurable and reasonable

=== Secure architecture ===

* Create and maintain a list of recommended software frameworks, services and other software components
* Develop a list of guiding security principles as a checklist against detailed designs
* Distribute, promote and apply the design principles to new projects

=== Design review ===

* Identify the entry points (attack surface/defense perimeter) in software designs
* Analyze software designs against the known security risks

=== Code review ===

* Create code review checklists based on common problems
* Encourage the use of the checklists by each team member
* Review selected high-risk code more formally
* Consider utilizing automated code analysis tools for some checks

=== Security testing ===

* Specify security test cases based on known requirements and common vulnerabilities
* Perform application penetration testing before each major release
* Review test results and correct, or formally accept the risks of releasing with failed checks

=== Vulnerability management ===

* Define an application security point of contact for each project
* Create an informal security response team
* Develop an initial incident response process

=== Environment hardening ===

* Create and maintain specifications for application host environments
* Monitor sources for information about security upgrades and patches for all software supporting or within the applications
* Implement processes to test and apply critical security fixes

=== Operational enablement ===

* Record important software-specific knowledge that affects the deployed application's security
* Inform operators/users as appropriate of this understandable/actionable information
* Provide guidance on handling expected security-related alerts and error conditions

== Do more ==

Is level 1 the correct goal? Perhaps your organization is already doing more than these? Perhaps it should do more, or less. Read SAMM, and benchmark existing activities using the scorecard. Use the information resources listed below to help develop your own programme, guidance and tools.

= Related articles =

OWASP [http://www.opensamm.org/ Open Software Assurance Maturity Model (SAMM)] and [http://www.opensamm.org/download/ Downloads (Model, mappings, assessment templates, worksheet, project plan, tracking software, charts and graphics)]

OWASP [https://www.owasp.org/index.php/Category:OWASP_CLASP_Project Comprehensive, Lightweight Application Security Process (CLASP)]

OWASP [https://www.owasp.org/ Open Web Application Security Project (OWASP)], [https://www.owasp.org/index.php/OWASP_Secure_Coding_Practices_-_Quick_Reference_Guide Security requirements], [https://www.owasp.org/index.php/Cheat_Sheets Cheat sheets], [https://www.owasp.org/index.php/OWASP_Guide_Project Development Guide], [https://www.owasp.org/index.php/Category:OWASP_Code_Review_Project Code Review Guide], [https://www.owasp.org/index.php/OWASP_Testing_Project Testing Guide] , [https://www.owasp.org/index.php/Category:OWASP_Application_Security_Verification_Standard_Project Application Security Verification Standard (ASVS)] and [https://www.owasp.org/index.php/Category:OWASP_Tool Tools]

OWASP [https://www.owasp.org/index.php/OWASP_Podcast Application security podcast] and [https://www.owasp.org/index.php/OWASP_Appsec_Tutorial_Series AppSec Tutorial Series]

BITS [http://www.bits.org/publications/security/BITSSoftwareAssurance0112.pdf Financial Services Roundtable BITS Software Assurance Framework]

CMU [http://www.cert.org/secure-coding/secure.html Team Software Process for Secure Systems Development (TSP Secure)]

DACS/IATAC [http://iac.dtic.mil/iatac/download/security.pdf Software Security Assurance State of the Art Report]

ENISA [http://www.enisa.europa.eu/act/application-security/secure-software-engineering/secure-software-engineering-initiatives Secure Software Engineering Initiatives]

ISO/IEC [http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=44378 ISO/IEC 27034 Application Security]

NIST [http://csrc.nist.gov/publications/nistpubs/800-64-Rev2/SP800-64-Revision2.pdf SP 800-64 Rev2 Security Considerations in the Information System Development Life Cycle]

SAFECode [http://www.safecode.org/publications/SAFECode_Agile_Dev_Security0712.pdf Practical Security Stories and Security Tasks for Agile Development Environments]

US DoHS [https://buildsecurityin.us-cert.gov/bsi/home.html Building Security In] and [https://buildsecurityin.us-cert.gov/swa/resources.html Software Assurance Resources]

Other [http://www.sdlc.ws/ sdlc] and [http://www.sdlc.ws/software-testing-life-cycle-stlc-complete-tutorial/ Software Testing Life Cycle], [http://www.sdlc.ws/category/models/ sdlc models]

Other [http://bsimm.com/ Building Security In Maturity Model (BSIMM)]

Other [http://www.microsoft.com/security/sdl/default.aspx Microsoft Security Development Lifecycle (SDL)] and [http://go.microsoft.com/?linkid=9767361 Process guidance v5.1], [http://go.microsoft.com/?linkid=9708425 Simplified implementation]

Other [http://www.oracle.com/us/support/assurance/index.html Oracle Software Security Assurance (OSSA)]

= Authors and primary contributors =

This cheat sheet is largely based on infortmation from OWASP SAMM v1.0 originally written by Pravir Chandra - chandra[at]owasp.org

The cheat sheet was created by:

Colin Watson - colin.watson[at]owasp.org

{{Cheatsheet_Navigation}}

[[Category:Cheatsheets]] [[Category:OWASP_Builders]]