Copyright © The OWASP Foundation Permission is granted to copy, distribute and/or modify this document under the terms of the OWASP License. The OWASP Foundation OWASP September OWASP CLASP Project Moving toward a maturity model Pravir Chandra OWASP CLASP Project Lead Managing Principal Cognosticus

OWASP 2 Agenda  Review of CLASP Today  Moving to a maturity model  Software Assurance Maturity Model (SAMM)  Goals and Purpose  How does SAMM work?  Definition and usage of the model itself  What can you do with SAMM?  Recommended roadmaps and case studies  Assurance program scorecards/certification  Mappings to existing standards

OWASP 3 The OWASP CLASP Resources  Comprehensive, Lightweight Application Security Process  Prescriptive and Proactive  Centered around 7 AppSec Best Practices  Cover the entire software lifecycle (not just development)  Adaptable to any development process  CLASP defines roles across the SDLC  24 role-based process components  Start small and dial-in to your needs

OWASP 4 Other approaches to Security in the SDLC

OWASP 5 Lessons learned  Microsoft SDL  Heavyweight, appropriate to large ISVs selling boxed software  Touchpoints  High-level map without enough details to execute against  CLASP  Large collection of activities, but no priority ordering  Good for experts to use as a guide, but hard for non- security folks to use off the shelf

OWASP 6 Motivation for a maturity model approach  Changing an organization is hard Simple, well-defined, measurable always trumps complex, nuanced, ethereal  Software security is a result of many activities  Combination of people, process, and automation  There is no single formula for all organizations  Business risk from software depends on what the business does  An assurance program must be built over time  Organizations can’t change overnight. Use a phased approach.

OWASP 7 The Software Assurance Maturity Model (SAMM)

OWASP 8 Goals and Purpose  To define building blocks for an assurance program  Delineate all functions within an organization that could be improved over time  To allow organizations to create customized roadmaps  Each organization can choose the order and extent they improve each function  To provide sample roadmaps for common types of organizations  Each roadmap is a baseline that can be tweaked based on the specific concerns of a given organization

OWASP 9 How does SAMM work?

OWASP 10 Four high-level Disciplines  All security-related activities mapped under 4 Disciplines, each representing a group of related business functions Alignment & Governance Requirements & Design Verification & Assessment Deployment & Operations Activities related to security program management and cross-cutting organizational concerns Activities related to the product conception and software design processes Activities related to reviewing, testing, and validating software Activities related to knowledge transfer and maintenance of running software

OWASP 11 What’s under each Discipline? Alignment & Governance Requirements & Design Verification & Assessment Deployment & Operations  The 4 Disciplines are high-level categories for activities  Three security Functions under each Discipline are the specific silos for improvement within an organization Disciplines Functions

OWASP 12 What’s under each Function?  Three successive Objectives under each Function define how that Function can be improved over time  This establishes a notion of a “level” at which an organization fulfills a given Function  The three Objectives for a Function generally correspond to:  *0: Implicit starting point with the Function unfulfilled  1: Initial understanding and ad hoc provision of the Function  2: Increase efficiency and/or effectiveness of the Function  3: Comprehensive mastery of the Function at scale  Each Objective defines:  Activities that must be performed  Success metrics  Required personnel  Associated costs  Benefits for the organization

OWASP 13 Function Objectives Activities For example, Education & Guidance:

OWASP 14 Approach to phased improvement  Since the twelve Functions are each a maturity area, the successive Objectives represent the “building blocks” for any assurance program  Simply put, improve an assurance program in phases by: 1.Select security Functions to be improved in next phase of assurance program 2.Achieve the next Objective in each Function by performing the corresponding activities at the specified success metrics

OWASP 15 What can you do with SAMM?

OWASP 16 Recommended roadmaps  To make the “building blocks” usable, SAMM defines sample Roadmaps for typical kinds of organizations  Independent Software Vendors (ISVs)  Online Service Providers (OSPs)  Financial Services Organizations (FSOs)  Government Organizations (GOs)  Organization types chosen because  They represent common use-cases  Each organization has variations in typical software-induced risk  Optimal creation of an assurance program is different for each

OWASP 17  A roadmap is a phased plan for achieving Objectives for each security Function  The sample on the right is a generic plan for ISVs  In Phase 1, several Functions are moved from 0 to 1  In Phase 2, some are further advanced from 1 to 2, some remain at 1, and others are moved from 0 to 1  Etc…  SAMM includes case studies with specific details on implementation A sample roadmap

OWASP 18 Assurance program scorecards  By assessing an organization’s practices, they can be scored against SAMM’s Objectives and given a score for each Function  Compare assessed scores to recommended roadmaps for the organization type  Demonstrates gaps against best practices  Using a scorecard, an organization can demonstrate quantifiable improvement  Down the road possibility: certification of an organization’s assurance program

OWASP 19 A sample scorecard 19

OWASP 20 Mappings to existing standards  Mapping from CLASP activities into SAMM  There already exist a large number of standards that organizations follow  PCI, COBIT, SOX, ISO-17799/27002  Each Objective in SAMM can be mapped to section numbers in the existing standards  By accomplishing the SAMM Objective, the corresponding parts of the existing standards are achieved  Partially done for PCI, but more are planned

OWASP 21 SAMM Inventory today  Introduction and role definition  Definition of the maturity model  Details on each Objective in each Function under each Discipline  Recommended roadmaps  For ISVs and OSPs, planned additions for FSOs, GOs  Case Studies  Example organizations and how they would employ SAMM  Medium ISV complete, planned additions for online retailer, etc.  Mappings to standards and regulations  PCI partially complete, planned additions for COBIT, ISO, etc.

OWASP 22 What’s next?  Feedback and real-world case studies to refine the model itself  Additional roadmaps where it makes sense  Migrating the rest of the CLASP resources into SAMM  Mappings to more standards and regulations  Public release  Thanks to Fortify!  Anyone interested in being an early reviewer can have a copy if they provide feedback

OWASP 23 Pravir Chandra