This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org

Difference between revisions of "Secure SDLC Cheat Sheet"

From OWASP
Jump to: navigation, search
(Authors and primary contributors: Author text updated)
(Migration to GitHub of the project)
 
(10 intermediate revisions by 5 users not shown)
Line 1: Line 1:
= DRAFT CHEAT SHEET - WORK IN PROGRESS =
+
__NOTOC__
 +
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div>
  
= Introduction =
+
The Cheat Sheet Series project has been moved to [https://github.com/OWASP/CheatSheetSeries GitHub]!
  
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. They broadly relate to "level 1" of the Open Software Assurance Maturity Model (Open SAMM).
+
An [https://github.com/OWASP/CheatSheetSeries/issues/13 open discussion] is pending about to exclude or not this cheat sheet of the V2 of the project.
 
 
...???
 
 
 
 
 
= 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://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]]
 

Latest revision as of 10:21, 16 February 2019

Cheatsheets-header.jpg

The Cheat Sheet Series project has been moved to GitHub!

An open discussion is pending about to exclude or not this cheat sheet of the V2 of the project.