Establishing an Enterprise
Application Security Program
OWASP
AppSec
DC
October 2005
Tony Canike, CISSP, GCIH
Manager, Application Security,
The Vanguard Group
anthony_c_canike@vanguard.com
610-503-6525
Copyright © 2005 - The OWASP Foundation
Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License.
The OWASP Foundation
http://www.owasp.org/
What today’s talk is about
What is an Application Security program?
 The need for an Application Security program in
your organization
Detailed look at the components of an
Application Security program
Roadmap to establish your own Application
Security program
This talk presumes the existence of network, server,
physical, and organizational security efforts.
Canike - OWASP AppSec DC 2005
2
Setting the Stage
In my organization…
Application Security is an IT function
Information Security is a business function
 Close cooperation and some overlap
Mix of purchased and in-house developed business
applications
 Many business applications developed in-house
Canike - OWASP AppSec DC 2005
3
What is an Application Security Program?
Def. 1: An integrated approach to Application
Security in your organization
Not scattershot
Not tools with shiny red buttons
Def. 2: A corporate initiative to define, promote,
assure, and measure the security of critical
business applications.
So what does that really mean…
Canike - OWASP AppSec DC 2005
4
People, Process, and Technology all aligned to
ensure secure business applications.
People
 Policy
 Standards
 Awareness
 Training
 Roles
 Priority
 Expert
Assistance
Process
 SDLC
 App Inventory
 Standard
Requirements
 Risk
Management
 Risk Rating
 Reviews
 Governance
Technology
 Standard
Controls
 Input
Validation
 Tools
Canike - OWASP AppSec DC 2005
5
Application Security: Part of the Big Picture
Conceptual Information Security Dashboard
Business Applications
Data Security
Vendors & Partners
Business Processes
Computing Infrastructure
Intrusion Detection
Network & Telecom Infra
Physical Security
Compliance
Business Continuity
Incident Response
Fraud Prevention
Simplified example only. A complete dashboard could have 20-30 indicators.
Canike - OWASP AppSec DC 2005
6
Benefits of an Application Security program
Knowledge to…
keep the C-suite informed
communicate areas of opportunity
develop high-level action plans
assist the application development teams
optimally allocate resources and funds
protect client and corporate assets
Canike - OWASP AppSec DC 2005
7
Why do you need an Application Security program?
 What are your big application security issues, anyway?
 Can you back up recommendations with data?
 Can you justify expenditures?
 Security is more then securing the network perimeter…
 …do you have data to support that?
 Your network security colleagues have numbers, you need
numbers too.
 Use Data, Metrics, Numbers, Facts
 Data-driven decision making
 Really know what is working and what is not
 Motivate actions
Suggestions for metrics collection throughout
presentation
Canike - OWASP AppSec DC 2005
8
Knowledge in multiple dimensions
 Training and Awareness
Leading Indicator
 Are IT Staff trained and aware of security issues?
Leading Indicator
 SDLC Maturity and Compliance
 Is security baked-in to your Software Development Life Cycle?
 Are you following your SDLC?
 Reference Architectures and Standard Controls Provided?
 Security Assessment Coverage of the Application Space
 Are you doing enough assessments? Frequently enough?
 Anything you don’t know you don’t know?
 Application Risks and Vulnerabilities
Post Indicator
 When are security problems found? During Code? Test? Prod?
 Are you mitigating risks in a timely fashion?
Canike - OWASP AppSec DC 2005
9
How much security do we need?

Canike - OWASP AppSec DC 2005
10
Components of an Application Security program
People
 Policy
 Standards
 Awareness
 Training
 Roles
 Priority
 Expert
Assistance
Process
 SDLC
 App Inventory
 Standard
Requirements
 Risk
Management
 Risk Rating
 Reviews
 Governance
Technology
 Standard
Controls
 Input
Validation
 Tools
Canike - OWASP AppSec DC 2005
11
People: Policies and Standards
Information Security Policies
IT Architecture Standards
Reference application architectures (w/security)
Standard security controls identified
SDLC Defined
Standard Application Security Requirements
Use reviews to govern and enforce
Dashboard Indicators, Metrics
Canike - OWASP AppSec DC 2005
12
People: Awareness and Training
 Awareness of policies and standards
 Information Security
 Corporate intranet or newsletter articles
 Web-based training
 Training
 Security architects
 Managers
 Technical leads
 Developers
 Testers
 Etc…
Dashboard Indicators, Metrics
Canike - OWASP AppSec DC 2005
13
People: Define Specialized Roles
Security Architects
Understand standard application controls and how to
implement them
Directly supporting application development
Setting enterprise-wide standard security architecture
Application Security Assessment Team
Small, quasi-independent team
Assess architectures and test for vulnerabilities
Access Management Team
Business group grants access to business applications
 Keeper of the keys (literally and figuratively)
 Not developers, not users, not system admins
Canike - OWASP AppSec DC 2005
14
People: Prioritize Security
Time to market, business functionality, and cost
all compete with security concerns.
Executive attention
One suggestion: IT VP’s present their security
metrics/dashboard to an executive committee
quarterly
Report security vulnerabilities as defects
Defect-elimination mentality already engrained?
 If so, leverage it.
 If not,…
Canike - OWASP AppSec DC 2005
15
People: Expert Assistance
Security experts are available to application
development teams
Security Architects
Central team to maintain standard security controls
 Eval, purchase, development, support of technical controls
Access management team
Information Security
Product Vendor resources
Consultants as necessary
Canike - OWASP AppSec DC 2005
16
Components of an Application Security Program
People
 Policy
 Standards
 Awareness
 Training
 Roles
 Priority
 Expert
Assistance
Process
 SDLC
 App Inventory
 Standard
Requirements
 Risk
Management
 Risk Rating
 Reviews
 Governance
Technology
 Standard
Controls
 Input
Validation
 Tools
Canike - OWASP AppSec DC 2005
17
Process: Software Development Life Cycle
 Integrate security steps into your SDLC
 Will take a few iterations to mature.
 Baked-in, not bolted-on
 End-game penetration test is not sufficient
 Find security issues early
 Much easier, cheaper to fix
 Measure compliance
 Self-reporting
 Audit a sampling
 Voice of Practitioners
 Are the processes working?
Dashboard Indicators, Metrics
Canike - OWASP AppSec DC 2005
18
Process: Application Development Life Cycle
Business Arch &
Planning
Requirements
Application
Categorization
Security
Requirements
Analysis, Design & Implementation
Access
Control
Input
Validation
Security
Architecture
Review
Design &
Code
Review
Unit &
Integration
Test
Test
Elevation
System Test
Categorize
Define Requirements
Build Controls
Vulnerability
Test
Governance
Review
Verify Controls
Governance
Review
Risk Management
Pre-Elev
Risk Review
Track Security Metrics
Track and Manage Defects and Risks
Canike - OWASP AppSec DC 2005
19
Process: Inventory and Categorize your Applications
 List all your business applications, the business owner,
and the IT owner (might be hard)
 Categorize applications w.r.t. criticality of security
 Potential Business Impact
 Quick Technical Assessment – surface area, complexity, data
classification
 Ref. NIST 800-64 and FIPS 199
 Use categorization to prioritize security attention and
assessments.
 Assessments Performed? How recently?
Dashboard Indicators, Metrics
Canike - OWASP AppSec DC 2005
20
Process: Standard Security Requirements
Define Security Requirements Standards for your
business applications.
Which controls are necessary
When are they necessary (applicability)
Why are they necessary (e.g. SEC, SOX, etc.)
 Easy to use reference for requirements teams
Standard method to implement each control
 Provide reference on how to implement
Requirements for requirements
 E.g. The need to specify functional business requirements for
access control
Canike - OWASP AppSec DC 2005
21
Process: Security Assessments of Applications
 Choose types of assessments that fit your organization.
 Security Architecture/Design Reviews
 Security Code Reviews
 Application Vulnerability Tests
 Risk Acceptance Review
 External Penetration Test of Production Applications
 White Box Philosophy – look inside the application
 Use all the advantages you have
 Past reviews, design documents, code, logs, interviews, etc.
 Attackers have advantages you don’t, don’t tie your hands.
 Part of your SDLC
 Define which reviews when, by whom, and how in your SDLC
 Don’t underestimate the amount of work necessary for
communication, scheduling, report writing, logistics
Canike - OWASP AppSec DC 2005
22
Security Architecture/Design Review
Architecture/Design time assessment of an
application and its security controls
Component interface and connection driven
Enumerate through the interfaces and connections
considering threats, vulnerabilities, and risks
STRIDE
Identify non-standard, home-brewed or missing
security controls
Issue a report
Identify vulnerabilities to mitigate or fix
Identify issues for follow-up
Canike - OWASP AppSec DC 2005
23
Security Code Review
Focus on code relevant to security
Utilize experts
Consider consulting firms with specialized techniques.
Specialized Tools
Have a technique to wade through 5 million lines of
code
Define Scope and Purpose
Project Manager: “since you are reviewing my code, I
can skip all my code reviews, ok?” Not so fast…
You are not reviewing the code for the application
team – they are still on the hook for code quality.
Canike - OWASP AppSec DC 2005
24
Application Vulnerability Test
 Hands-on testing of application around System Test time
 “Port 80” types of attacks
 Goal is to find most of the problems early and get them
fixed.
 Not trying to prove a point, not playing capture-the-flag
 Use a small dedicated team supported by consultants
 Educate and collaborate with development teams
 Use all advantages you have – white box
 Logs, source code, business knowledge, prior assessments
 Define purpose – are you going to validate that the
application meets all of its security requirements?
 Probably not. Make that clear up-front.
 Define scope – which components are being tested?
 Use the architecture diagram
Canike - OWASP AppSec DC 2005
25
Process: Information Security Risk Management
 Document your risk rating process
 Common risk rating method and scale
 Consider business impact and likelihood/DREAD factors
 Rationale for a particular risk rating known and documented
 Common taxonomy
 Categorize and count – perhaps 10 categories
 Weed out false positives early – reduce noise
 Draft, Review, Revise
 Apply to all IT-owned InfoSec Risks from all sources
 Consultants, IT Security Assessments, InfoSec Assessments,
Internal Audit (if possible), Corporate Risk Management, etc.
 Develop/Adapt process through consensus
 Calibrate!
Canike - OWASP AppSec DC 2005
26
Example Job Aid – Likelihood Factors
WHO?
Mitigating
Controls
Attractive?
Well
Known?
Skill Level
HIGH
L
I
K
E
L
I
H
O
O
D
LOW
Public
All Internet
Direct Access
Very Attractive
CORP Inc
Customers
CORP Inc
Unintentional
Internal
One Control
IT Employees
Two Controls
No special skills
Somewhat
Attractive
Proprietary
Technical
Very Technical
System Admins
Three or more
Illustrative example only.
Not Attractive
Theoretical
Canike - OWASP AppSec DC 2005
27
Process: Information Security Risk Management
(cont.)
 Common Repository for tracking
 Assessments
 Risks/Vulnerabilities
 Mitigation Actions and Status
 Common report formats
 Differing formats from different assessment teams (internal,
consultants, audit) confuses everyone
 Common summary reports
 Open risk counts, severity, category, owners, time-to-close, …
 Train management on how to read summary reports
Dashboard Indicators, Metrics
Canike - OWASP AppSec DC 2005
28
Process: Risk Review and Acceptance
Review known security risks and mitigation
status prior to production elevation.
Business owners key participants
Need to understand and accept (or not) outstanding
risks prior to elevation
No surprises…
Dashboard Indicators, Metrics
Canike - OWASP AppSec DC 2005
29
Process: Other tests and assessments….
Of course, utilize the gamut of security
assessments, including
Internet Penetration Tests
Network and vulnerability scans
Server security scans
Up to you to define the boundary of “Application
Security” for your organization.
Cooperate, avoid fiefdoms
Canike - OWASP AppSec DC 2005
30
Process: Governance Team Reviews
IT-wide governance team of practitioners
reviews summaries of security assessments and
tests
Were the risks rated properly?
Was the assessment or test complete?
Is the responsible individual taking responsibility and
fixing the issues?
What are the common themes and trends?
What improvements to people-process-technology
can be implemented?
Canike - OWASP AppSec DC 2005
31
Components of an Application Security Program
People
 Policy
 Standards
 Awareness
 Training
 Roles
 Priority
 Expert
Assistance
Process
 SDLC
 App Inventory
 Standard
Requirements
 Risk
Management
 Risk Rating
 Reviews
 Governance
Technology
 Standard
Controls
 Input
Validation
 Tools
Canike - OWASP AppSec DC 2005
32
Technology: Standard Controls
 Provide standard technical controls to your application
development teams.
 Determine needs and prioritize
 Consider authentication, access control, certificate management,
cryptography, accountability, logging, detection, ...
 Reuse opportunity
 Don’t let app teams “roll their own” or reinvent the wheel.
 Central shared security controls team?
 Handle eval, purchase, integrate, build, test, support
 Support application teams
 Provide reference architectures with integrated security
controls
Dashboard Indicators, Metrics
Canike - OWASP AppSec DC 2005
33
Technology: Standard Controls (cont.)
Do your standard security controls cover all your
application architectures?
LAN/Desktop login
Web (Internet, intranet, J2EE, .NET, LAMP, etc.)
Thick desktop clients
Application Service Providers/Partners – SSO
UI tier, Business logic tier, data tier
Web Services
Canike - OWASP AppSec DC 2005
34
Technology: Input Validation
Is each application developer building their own
input validation code?
Or do you have a standard mechanism?
Is there a standard signature/architecture/API and a
reuse library that developers can contribute to?
For all your application models?
Do requirements/use cases/UI specifications
document necessary allowed values for each
input field?
Canike - OWASP AppSec DC 2005
35
Technology: Security Tools
Tools
Developers
System Testers
Security Assessors/Testers
Canike - OWASP AppSec DC 2005
36
People, Process, and Technology all aligned to
ensure secure applications.
People
 Policy
 Standards
 Awareness
 Training
 Roles
 Priority
 Expert
Assistance
Process
 SDLC
 App Inventory
 Standard
Requirements
 Risk
Management
 Risk Rating
 Reviews
 Governance
Technology
 Standard
Controls
 Input
Validation
 Tools
Canike - OWASP AppSec DC 2005
37
That’s a long list…
Implementing all these components of an
Application Security program is a tall order
Adapt to your needs
In-house development
Purchased applications
Outsourced applications
In-house SDLC vs. outsourcing requirements
and contract language
Canike - OWASP AppSec DC 2005
38
Roadmap to your own Application Security Program
Assess Current State – what are your
organizational and process deficiencies?
Info Sec and Internal Audit will help you here!
Develop and sell your vision
It’s a integrated program
Identify and educate your stakeholders
Have a roadmap and a project plan – 2-4 year
effort
Canike - OWASP AppSec DC 2005
39
Where to start?
Awareness and Training
2-hour course:
$100-200/seat
Seeing the look on the IT VPs’ faces when they get
SQL Injection: Priceless
Policies and Standards
Application Assessments and Reviews
Get some data
Strive to be consistent and uniform
Support Development Teams
Canike - OWASP AppSec DC 2005
40
Questions?
Canike - OWASP AppSec DC 2005
41
More Information
ISF Standard of Good Practice
ISF has a strong Business Impact assessment process
(membership required)
NIST Security Considerations in the Information
System Development Life Cycle (800-64)
OWASP Guide
Howard and LeBlanc Writing Secure Code
Canike - OWASP AppSec DC 2005
42