OWASP Application Security
Assessment Standards Project
OWASP
AppSec
Seattle
Oct 2006
Cliff Barlow
Assessment Standards Project Lead
Director Security Services, KoreLogic, Inc.
cliff.barlow@korelogic.com
269.982.1707
Copyright © 2006 - The OWASP Foundation
Permission is granted to copy, distribute and/or modify this document under the
terms of the Creative Commons Attribution-ShareAlike 2.5 License. To view this
license, visit http://creativecommons.org/licenses/by-sa/2.5/
The OWASP Foundation
http://www.owasp.org/
Presentation Agenda
Impetus for Project
Project Objectives
Project Roadmap
Progress To Date
The Guts
The Road Ahead
How You Can Help
OWASP AppSec Seattle 2006
2
Project Impetus
 Current lack of standardization over what constitutes an
application security assessment
 No single set of criteria being referenced
 Lots of definitions, little consistency in what differing
assessment techniques constitute
 Build a standard that will be flexible in design to
accommodate a range of security assurance levels
 Keep standard from placing requirements on any party
 Ensure standard makes recommendations about what
should be done to be consistent with what the OWASP
community believes is best practice
 Who better than OWASP to create this standard?
 If OWASP doesn’t, will someone else impose one on us?
OWASP AppSec Seattle 2006
3
Project Objectives
 Create standards defining baseline approach to
conducting differing levels of application assessment
 Establish common, consistent methods for application
assessments that organizations can use as guidance on:
 What tasks should be completed;
 How the tasks should be completed;
 Who should be involved; and,
 What level is appropriate based on business requirements.
 Will not define how to technically to conduct an
assessment; instead meant to tie business practices to
application security in order to establish a common,
consistent guidance in conducting assessments
 Adhering to standards increases consumer confidence
that assessment meets industry agreed-upon approach
OWASP AppSec Seattle 2006
4
Project Roadmap
Phase I – Project Approach: Comment Period for
Proposed Project Approach, Solicit Contributor Support
Phase II – Application Assessment Definitions: Establish
core definitions to ensure common base terminology
Phase III – Assessment Context: Establish assessment
context, selection, qualification and process frameworks
Sept 2006
Oct 2006
Nov 2006
Schedule Can Only Be
Meet With Volunteer Help!
Dec 2006
Jan 2007
Feb 2007
Mar 2007
Apr 2007
May 2007
Phase IV – Assessment Levels: Establish a
common set of application assessment levels to
be used as business guidance to ensure
conducting assessments to appropriate level
Phase V – OWASP Integration: Document integration
and linkages with other OWASP projects
OWASP AppSec Seattle 2006
5
Assessment Standards Project Status
Phase I
Phase II
Develop Project Approach
Define Common
Business Application
Types
Define Standard
Assessment
Process Framework
Define
Assessment
Techniques
Establish Assessor
Qualification Criteria
Per Level
1
Define
Assessment
Scope Per Level 1
Phase III
Define Business
End Preparation
For Assessment
[ Stub Started – Open to
Comment And Edit ]
[ Stub Needed – Open to
Contribution ]
Establish Where
in SDLC Assessment
Components Lie
Phase IV
1 – Can establish baseline now but will
need further detail post Phase IV
OWASP AppSec Seattle 2006
6
The Path Forward
 Phase IV – Assessment Levels:
Establish assessment level system decision criteria
 Analysis and documentation of corresponding security
measurements (i.e. common security metrics, security
assurance/maturity models, related legislation, other
standards, etc.)
Establish Assessment levels based on Phase II and III
 Define assessment depth, testing components required and
tools usage per level (not products)
Establish guidance parameters to allow organizations to
determine appropriate assessment level based on business
application to be assessed
 Phase V – OWASP Integration: Document integration
and linkages with other OWASP projects.
OWASP AppSec Seattle 2006
7
Key Determinants To Assessment Levels
Business Criticality
Expected Security Assurance
Testing Requirements
Accredited/Certified App
Independent 3rd Party Required
Easily Understood By The Business Layman
?
What Needed To Get There
Decision Criteria – How Do We Get To Agreement
Decision Criteria – How Does Layman Determine
Which Level They Should Use
OWASP AppSec Seattle 2006
8
The Guts of Project… Assessment Levels
Manual Security Code Review (Specialist)
3
4
Manual Penetration Testing (Specialist)
Auto Source Code Review (Tool)
1
2
External App Scan (Tool)
Threat Analysis & Architecture Review (Analyst)
0
(Defined by Business)
Business Criticality
(Impact of Loss)
5
Security Assessment Techniques – Relative Depth ?
0
1
2
3
4
5
Expected Security Assurance
(Assessment
Depth – Expected Level of Security)
(Defined by Corporate Security)
OWASP AppSec Seattle 2006
9
The Guts of Project… Assessment Levels
5
One Approach…
3
AL5
2
(Defined by Business)
AL6
AL4
AL3
1
Business Criticality
4
Details to be developed
AL2
0
AL1
0
1
2
3
4
5
Expected Security Assurance
(Defined by Corporate Security)
 AL1: Architecture Review/Threat Analysis - Design level review to identify critical assets,
sensitive data stores and business critical interconnections. In addition to architecture reviews is
threat analysis to determine potential attack vectors, which could be used in testing.
 AL2: Quick Hit Application Security Check - Automated scans (either external vulnerability
scan or code scan or both) with minimal interpretation and verification.
 AL3: Basic Application Security Check – AL2 + verification and validation of scan results.
Security areas not scanned (encryption, access control, etc.) must be lightly tested or code
reviewed.
OWASP AppSec Seattle 2006
10
The Guts of Project… Assessment Levels
5
One Approach…
3
AL5
2
(Defined by Business)
AL6
AL4
AL3
1
Business Criticality
4
Details to be developed
AL2
0
AL1
0
1
2
3
4
5
Expected Security Assurance
(Defined by Corporate Security)
 AL4: Standard Application Security Verification – AL3 + verification of common security
mechanisms and common vulnerabilities using either manual penetration testing or code review or
both. Not all instances of problems found - Sampling allowed.
 AL5: Enhanced Application Security Verification – AL1 + AL3 + verification of all security
mechanisms and vulnerabilities based on threat analysis model using either manual penetration
testing or code review or both.
 AL6: Comprehensive Application Security Verification – AL1 + AL4 + search for malicious
code. All code must be manually reviewed against a standard and all security mechanisms tested.
OWASP AppSec Seattle 2006
11
Help…
 We hope you find the OWASP Application Security
Assessment Standards Project useful
 Please contribute back to the project by sending your
comments, questions, and suggestions to
owasp@owasp.org
 To join the OWASP Assessment Standards mailing list or
view the archives, please visit the subscription page
http://lists.owasp.org/mailman/listinfo/owasp-appsecstandards
OWASP AppSec Seattle 2006
12