OWASP CLASP Project Moving toward a maturity model

1. OWASP CLASP ProjectMoving toward a maturity model Pravir Chandra OWASP CLASP Project Lead Managing Principal Cognosticus chandra@cognosticus.com

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

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

4. Other approaches to Security in the SDLC

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

6. Motivation for a maturity model approach Changing an organization is hard Simple, well-defined, measurablealways trumpscomplex, 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.

7. The Software Assurance Maturity Model (SAMM)

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

9. How does SAMM work?

10. Requirements & Design Deployment & Operations Verification & Assessment Alignment & Governance 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 Four high-level Disciplines • All security-related activities mapped under 4 Disciplines, each representing a group of related business functions

11. Requirements & Design Deployment & Operations Verification & Assessment Alignment & Governance What’s under each Discipline? • 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

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

13. Offer development staff access to resources around the topics of secure programming and deployment. Mandate comprehensive security training and certify personnel for baseline knowledge. Educate all personnel in the software life-cycle with role-specific guidance on secure development. For example, Education & Guidance: Education & Guidance EG.1 EG.2 EG.3 Function Create application security support portal Utilize security coaches to enhance project teams Establish role-based examination/certification Build and maintain technical guidance Conduct technical security awareness training Conduct role-specific application security training Objectives Activities

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: Select security Functions to be improved in next phase of assurance program Achieve the next Objective in each Function by performing the corresponding activities at the specified success metrics

15. What can you do with SAMM?

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

17. A sample roadmap • 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

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

19. A sample scorecard 19

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

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.

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

23. Questions? Pravir Chandra chandra@cognosticus.com