Copyright © 2006 - The OWASP FoundationPermission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License.

The OWASP Foundation

OWASPAppSecEuropeMay 2006

http://www.owasp.org/

OWASP CLASP Project

Pravir ChandraOWASP CLASP Project LeadChief Security ArchitectSecure Softwarechandra@owasp.org

2OWASP AppSec Europe 2006

Agenda

What is CLASP anyway?

The CLASP Best practices

Resources that CLASP provides

Details on the OWASP CLASP Project

3OWASP AppSec Europe 2006

CLASP

Comprehensive, Lightweight Application Security Process

Prescriptive and ProactiveCentered around 7 AppSec Best PracticesCover the entire software lifecycle (not just development)

Adaptable to any development processCLASP defines roles across the SDLC24 role-based process componentsStart small and dial-in to your needs

4OWASP AppSec Europe 2006

Origins of CLASP

Developed by Secure SoftwareAlways 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

5OWASP AppSec Europe 2006

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 & roadmap information

6OWASP AppSec Europe 2006

Roles in the SDLC

High-level and abstractCan map one real person to more than one role

ArchitectDesignerImplementerProject ManagerRequirements SpecifierSecurity AuditorTest Analyst

7OWASP AppSec Europe 2006

The CLASP Best Practices

1. Institute awareness programs2. Perform application assessments3. Capture security requirements4. Implement secure development practices5. Build vulnerability remediation

procedures6. Define and monitor metrics7. Publish operational security

guidelines

8OWASP AppSec Europe 2006

1. Institute awareness programs

Need organizational buy-in for successDon’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

9OWASP AppSec Europe 2006

2. Perform application assessments

Probably the most well-known best practiceClearly 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 ReviewIdentify, Implement, and Perform Security TestsVerify Security Attributes of ResourcesResearch and Assess Security Posture of Technology Solutions

10OWASP AppSec Europe 2006

3. Capture security requirements

Product conception to downstream releasesGet setup for success (or vector toward it)

Activities:Identify Global Security PolicyIdentify Resources and Trust BoundariesIdentify User Roles and Resource CapabilitiesSpecify Operational EnvironmentDetail Misuse CasesIdentify Attack SurfaceDocument Security Relevant Requirements

11OWASP AppSec Europe 2006

4. Implement secure development practicesPreaching to the choir

Activities:Apply Security Principles to DesignAnnotate Class Designs with Security Properties

Implement and Elaborate Resource Policies and Security Technologies

Implement Interface ContractsIntegrate Security Analysis into Source Management Process

Perform Code Signing

12OWASP AppSec Europe 2006

5. Build vulnerability remediation proceduresFed by software assessments

Also by 3rd party vuln reportsOtherwise, 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 ProcessAddress Reported Security Issues

13OWASP AppSec Europe 2006

6. Define and monitor metrics

Crucial despite only one associated activity

Any good process must have metricsMeasuring security directly can be hardMeasure adherence to process as an indirect indicator

Metrics are easy, interpretation is trickier

Activities:Monitor Security Metrics

14OWASP AppSec Europe 2006

7. Publish operational security guidelinesCrucial that operators know how to operate securely

Lots of information gets lost from dev to opsEnvironment assumptions made by devWays to debug and interpret logsDefinition of what is ‘normal’

Activities:Specify Database Security ConfigurationBuild Operational Security Guide

15OWASP AppSec Europe 2006

Lexicon of Vulnerabilities

‘Top-down’ approach to creating a catalog of coding flawsPerhaps vulnerability is a misnomer

Arranged into 5 high-level categoriesRange and Type ErrorsEnvironmental ProblemsSynchronization and Timing ErrorsProtocol ErrorsGeneral Logic Errors

16OWASP AppSec Europe 2006

On vulnerability taxonomies

Work in progress by NIST/DHS in the USPLOVERSeven KingdomsCLASP too

The word taxonomy implies a single top-level orderingI personally don’t think that is possible and the rigidity makes it less applicable

The folksonomy approach is more useful

17OWASP AppSec Europe 2006

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 Goals1. Porting all of the CLASP v1.2 materials to

the OWASP wiki2. Generating more introductory materials to

help users get started with CLASP3. Enhancing the vulnerability catalog with

more information (descriptions, examples, etc.)

18OWASP AppSec Europe 2006

Get involved

We need volunteers and ideas

Start by browsing the wiki pages for CLASP

Project Roadmap page on the wikiHas the up-to-date goalsOpen and assigned tasks are listed

Mailing list for discussionsowasp-clasp@lists.sourceforge.net

19OWASP AppSec Europe 2006

Pravir Chandrachandra@owasp.org