Revision as of 18:09, 23 April 2012

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. They broadly relate to "level 1" of the Open Software Assurance Maturity Model (Open SAMM).

...???

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 enviromnents, 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 inlude within your own S-SDL:C.

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.

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 Open SAMM, and benchmark existing activities using the scorecard.

Related articles

OWASP [ (SAMM)]

OWASP []

Bits framework

MS SDL

BSIMM

ISO 27034

Other ???

Authors and primary contributors

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

OWASP Cheat Sheets Project Homepage

• OWASP Cheat Sheet Series