Vous êtes sur la page 1sur 12

OWASP Application Security

Assessment Standards
Project

Cliff Barlow
Assessment Standards Project Lead
Director Security Services, KoreLogic,
Inc.
OWAS cliff.barlow@korelogic.com
P 269.982.1707

AppSe Copyright © 2006 - The OWASP Foundation

c
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
Seattl http://creativecommons.org/licenses/by-sa/2.5/

e The OWASP
Oct 2006 http://www.owasp.org/
Foundation
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
Sept 2006 Oct 2006 Nov 2006 process
Dec 2006frameworks
Jan 2007 Feb 2007 Mar 2007 Apr 2007 May
2007

Phase IV – Assessment Levels: Establish a


common set of application assessment
Schedule Can Only Be levels to be used as business guidance to
Meet With Volunteer Help! 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 Develop
DevelopProject
Project Approach
Approach

Define Common Define


Define Common Define
Phase II Business
BusinessApplication
Application Assessment
Assessment
Types Techniques
Types Techniques

Define Standard Establish Assessor Define


Define Standard Establish Assessor Define
Assessment Qualification
QualificationCriteria Assessment
Assessment Criteria Assessment
Process
ProcessFramework Per Level Scope
Framework Per Level1 ScopePer
PerLevel
Level1
Phase III
Define
DefineBusiness Establish
Business EstablishWhere
Where
End Preparation ininSDLC Assessment
End Preparation SDLC Assessment
For Assessment Components Lie
For Assessment Components Lie

1 – Can establish baseline now but will


[ Stub Started – Open to
[ Stub Started – Open to Phase IV need further detail post Phase IV
Comment And Edit ]
Comment And Edit ]

[ Stub Needed – Open to


[ Stub Needed – Open to
Contribution ]
Contribution ]
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
Security Assessment Techniques – Relative Depth ?
5 Manual Security Code Review (Specialist)

Manual Penetration Testing (Specialist)


(Defined by Business)
4
Business Criticality
(Impact of Loss)

Auto Source Code Review (Tool)

External App Scan (Tool)


2
1

Threat Analysis & Architecture Review (Analyst)


0

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…
Details to be
developed

4
Business Criticality
(Defined by Business)
AL6

3
AL5
AL4

2
AL3

1
AL2

AL1
0

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…
Details to be
developed

4
Business Criticality
(Defined by Business)
AL6

3
AL5
AL4

2
AL3

1
AL2

AL1
0

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-appsec-s

OWASP AppSec Seattle 2006 12

Vous aimerez peut-être aussi