OWASP CLASP Project Moving toward a maturity model

OWASP CLASP Project Moving toward a maturity model Pravir Chandra OWASP CLASP Project Lead Managing Principal Cognosticus OWASP chandra@cognosticus. com September 2008 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 http: //www. owasp. org/

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

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

Other approaches to Security in the SDLC OWASP 4

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

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 4 Combination of people, process, and automation <There is no single formula for all organizations 4 Business risk from software depends on what the business does <An assurance program must be built over time 4 Organizations can’t change overnight. Use a phased approach. OWASP 6

The Software Assurance Maturity Model (SAMM) OWASP 7

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

How does SAMM work? OWASP 9

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 10

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

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

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

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 14

What can you do with SAMM? OWASP 15

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

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 4 In Phase 1, several Functions are moved from 0 to 1 4 In Phase 2, some are further advanced from 1 to 2, some remain at 1, and others are moved from 0 to 1 4 Etc… <SAMM includes case studies with specific details on implementation OWASP 17

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 4 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 18

A sample scorecard OWASP 19 19

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

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

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 4 Thanks to Fortify! 4 Anyone interested in being an early reviewer can have a copy if they provide feedback OWASP 22

Pravir Chandra chandra@cognosticus. com OWASP 23