Revision as of 17:18, 2 November 2015

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 Open Software Assurance Maturity Model (SAMM) and Downloads (Model, mappings, assessment templates, worksheet, project plan, tracking software, charts and graphics)

OWASP Comprehensive, Lightweight Application Security Process (CLASP)

OWASP Open Web Application Security Project (OWASP), Security requirements, Cheat sheets, Development Guide, Code Review Guide, Testing Guide , Application Security Verification Standard (ASVS) and Tools

OWASP Application security podcast and AppSec Tutorial Series

BITS Financial Services Roundtable BITS Software Assurance Framework

CMU Team Software Process for Secure Systems Development (TSP Secure)

DACS/IATAC Software Security Assurance State of the Art Report

ENISA Secure Software Engineering Initiatives

ISO/IEC ISO/IEC 27034 Application Security

NIST SP 800-64 Rev2 Security Considerations in the Information System Development Life Cycle

SAFECode Practical Security Stories and Security Tasks for Agile Development Environments

US DoHS Building Security In and Software Assurance Resources

Other sdlc and Software Testing Life Cycle, sdlc models

Other Building Security In Maturity Model (BSIMM)

Other Microsoft Security Development Lifecycle (SDL) and Process guidance v5.1, Simplified implementation

Other 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

OWASP Cheat Sheets Project Homepage

• OWASP Cheat Sheet Series