Establishing an Enterprise Application Security Program OWASP AppSec DC October 2005 Tony Canike, CISSP, GCIH Manager, Application Security, The Vanguard Group [email protected] 610-503-6525 Copyright © 2005 - The OWASP Foundation Permission is.
Download
Report
Transcript Establishing an Enterprise Application Security Program OWASP AppSec DC October 2005 Tony Canike, CISSP, GCIH Manager, Application Security, The Vanguard Group [email protected] 610-503-6525 Copyright © 2005 - The OWASP Foundation Permission is.
Establishing an Enterprise
Application Security Program
OWASP
AppSec
DC
October 2005
Tony Canike, CISSP, GCIH
Manager, Application Security,
The Vanguard Group
[email protected]
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