OWAS PAppSecEU2006 CLASP Project


Presentation Description

No description available.


Presentation Transcript


OWASP CLASP Project Pravir Chandra OWASP CLASP Project Lead Chief Security Architect Secure Software chandra@owasp.org


Agenda What is CLASP anyway? The CLASP Best practices Resources that CLASP provides Details on the OWASP CLASP Project


CLASP 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

Origins of CLASP: 

Origins of CLASP Developed by Secure Software Always publicly available and free to use Released under the Creative Commons-SA-Attr 2.5 Based on several years of field experience Basis of the OWASP Process project

Resources that CLASP provides: 

Resources that CLASP provides We already know of some Role definitions 7 Best practices 24 Activities to bolt-on to dev process Summaries for the core security services Authz, Authn, Confidentiality, Integrity, etc. Design principles for building secure software Defense in depth, least privilege, etc. A large lexicon of vulnerabilities found in code Some use-cases for CLASP, process engineering andamp; roadmap information

Roles in the SDLC: 

Roles in the SDLC High-level and abstract Can map one real person to more than one role Architect Designer Implementer Project Manager Requirements Specifier Security Auditor Test Analyst

The CLASP Best Practices: 

The CLASP Best Practices Institute awareness programs Perform application assessments Capture security requirements Implement secure development practices Build vulnerability remediation procedures Define and monitor metrics Publish operational security guidelines

1. Institute awareness programs: 

1. Institute awareness programs Need organizational buy-in for success Don’t just educate the developers! PMs must understand high-level security goals Testers should be prepared to test for security Only one activity, but it’s broad Activities: Institute Security Awareness Program

2. Perform application assessments: 

2. Perform application assessments Probably the most well-known best practice Clearly important, but not the only thing Covers both ‘high-level’ and ‘low-level’ views Activities: Perform Security Analysis of System Requirements and Design (Threat Modeling) Perform Source Level Security Review Identify, Implement, and Perform Security Tests Verify Security Attributes of Resources Research and Assess Security Posture of Technology Solutions

3. Capture security requirements: 

3. Capture security requirements Product conception to downstream releases Get setup for success (or vector toward it) Activities: Identify Global Security Policy Identify Resources and Trust Boundaries Identify User Roles and Resource Capabilities Specify Operational Environment Detail Misuse Cases Identify Attack Surface Document Security Relevant Requirements

4. Implement secure development practices: 

4. Implement secure development practices Preaching to the choir Activities: Apply Security Principles to Design Annotate Class Designs with Security Properties Implement and Elaborate Resource Policies and Security Technologies Implement Interface Contracts Integrate Security Analysis into Source Management Process Perform Code Signing

5. Build vulnerability remediation procedures: 

5. Build vulnerability remediation procedures Fed by software assessments Also by 3rd party vuln reports Otherwise, important items may get dropped Or, lots of chaos when they occur (wasted resources) Control information when disclosure must occur Activities: Manage Security Issue Disclosure Process Address Reported Security Issues

6. Define and monitor metrics: 

6. Define and monitor metrics Crucial despite only one associated activity Any good process must have metrics Measuring security directly can be hard Measure adherence to process as an indirect indicator Metrics are easy, interpretation is trickier Activities: Monitor Security Metrics

7. Publish operational security guidelines: 

7. Publish operational security guidelines Crucial that operators know how to operate securely Lots of information gets lost from dev to ops Environment assumptions made by dev Ways to debug and interpret logs Definition of what is ‘normal’ Activities: Specify Database Security Configuration Build Operational Security Guide

Lexicon of Vulnerabilities : 

Lexicon of Vulnerabilities ‘Top-down’ approach to creating a catalog of coding flaws Perhaps vulnerability is a misnomer Arranged into 5 high-level categories Range and Type Errors Environmental Problems Synchronization and Timing Errors Protocol Errors General Logic Errors

On vulnerability taxonomies: 

On vulnerability taxonomies Work in progress by NIST/DHS in the US PLOVER Seven Kingdoms CLASP too The word taxonomy implies a single top-level ordering I personally don’t think that is possible and the rigidity makes it less applicable The folksonomy approach is more useful

The OWASP CLASP Project: 

The OWASP CLASP Project Mission Reinforce application security through a set of prescriptive and proactive process components that are adaptable to any development model. Tactical Goals Porting all of the CLASP v1.2 materials to the OWASP wiki Generating more introductory materials to help users get started with CLASP Enhancing the vulnerability catalog with more information (descriptions, examples, etc.)

Get involved: 

Get involved We need volunteers and ideas Start by browsing the wiki pages for CLASP Project Roadmap page on the wiki Has the up-to-date goals Open and assigned tasks are listed Mailing list for discussions owasp-clasp@lists.sourceforge.net


Pravir Chandra chandra@owasp.org

authorStream Live Help