establishing an enterprise application security program
DESCRIPTION
Establishing an Enterprise Application Security Program. Tony Canike, CISSP, GCIH Manager, Application Security, The Vanguard Group [email protected] 610-503-6525. What today’s talk is about. What is an Application Security program? - PowerPoint PPT PresentationTRANSCRIPT
Copyright © 2005 - 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
OWASP
AppSec
DCOctober
2005 http://www.owasp.org/
Establishing an Enterprise Application Security Program
Tony Canike, CISSP, GCIHManager, Application Security, The Vanguard [email protected]
2Canike - OWASP AppSec DC 2005
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.
3Canike - OWASP AppSec DC 2005
Setting the Stage
In my organization…Application Security is an IT function Information Security is a business function
Close cooperation and some overlapMix of purchased and in-house developed
business applications Many business applications developed in-house
4Canike - OWASP AppSec DC 2005
What is an Application Security Program?Def. 1: An integrated approach to
Application Security in your organizationNot scattershotNot 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…
5Canike - OWASP AppSec DC 2005
People, Process, and Technology all aligned to ensure secure business applications.
People Policy Standards Awareness Training Roles Priority Expert
Assistance
Technology Standard
Controls Input
Validation Tools
Process SDLC App
Inventory Standard
Requirements Risk
Management Risk Rating Reviews Governance
6Canike - OWASP AppSec DC 2005
Application Security: Part of the Big Picture Conceptual Information Security Dashboard
Intrusion Detection
Vendors & Partners
Computing Infrastructure
Network & Telecom Infra Physical Security
Business Processes
Data SecurityBusiness Applications
Compliance Business Continuity
Incident Response Fraud Prevention
Simplified example only. A complete dashboard could have 20-30 indicators.
7Canike - OWASP AppSec DC 2005
Benefits of an Application Security program Knowledge to…
keep the C-suite informedcommunicate areas of opportunitydevelop high-level action plansassist the application development teamsoptimally allocate resources and fundsprotect client and corporate assets
8Canike - OWASP AppSec DC 2005
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
9Canike - OWASP AppSec DC 2005
Knowledge in multiple dimensions
Training and Awareness Are IT Staff trained and aware of security issues?
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 When are security problems found? During Code? Test? Prod? Are you mitigating risks in a timely fashion?
Leading Indicator
Leading Indicator
Post Indicator
10Canike - OWASP AppSec DC 2005
How much security do we need?
11Canike - OWASP AppSec DC 2005
Components of an Application Security program
People Policy Standards Awareness Training Roles Priority Expert
Assistance
Technology Standard
Controls Input
Validation Tools
Process SDLC App
Inventory Standard
Requirements Risk
Management Risk Rating Reviews Governance
12Canike - OWASP AppSec DC 2005
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
13Canike - OWASP AppSec DC 2005
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
14Canike - OWASP AppSec DC 2005
People: Define Specialized Roles Security Architects
Understand standard application controls and how to implement them
Directly supporting application developmentSetting enterprise-wide standard security architecture
Application Security Assessment TeamSmall, quasi-independent team Assess architectures and test for vulnerabilities
Access Management TeamBusiness group grants access to business applications
Keeper of the keys (literally and figuratively) Not developers, not users, not system admins
15Canike - OWASP AppSec DC 2005
People: Prioritize Security
Time to market, business functionality, and cost all compete with security concerns.
Executive attentionOne suggestion: IT VP’s present their security
metrics/dashboard to an executive committee quarterly
Report security vulnerabilities as defectsDefect-elimination mentality already engrained?
If so, leverage it. If not,…
16Canike - OWASP AppSec DC 2005
People: Expert Assistance
Security experts are available to application development teamsSecurity ArchitectsCentral team to maintain standard security
controls Eval, purchase, development, support of technical
controlsAccess management team Information SecurityProduct Vendor resourcesConsultants as necessary
17Canike - OWASP AppSec DC 2005
Components of an Application Security Program
People Policy Standards Awareness Training Roles Priority Expert
Assistance
Technology Standard
Controls Input
Validation Tools
Process SDLC App
Inventory Standard
Requirements Risk
Management Risk Rating Reviews Governance
18Canike - OWASP AppSec DC 2005
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
19Canike - OWASP AppSec DC 2005
Business Arch & Planning
Requirements Analysis, Design & Implementation Test Elevation
Process: Application Development Life Cycle
Track Security Metrics
Track and Manage Defects and Risks
Security Requirements
Input Validation
Access Control
Security Architecture
Review
Design & Code
Review
Unit & Integration
Test
Vulnerability Test
System Test
Pre-Elev Risk Review
Application Categorization
Categorize
Define Requirements
Build Controls
Verify Controls
Risk Management
Governance Review
Governance Review
20Canike - OWASP AppSec DC 2005
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
21Canike - OWASP AppSec DC 2005
Process: Standard Security Requirements
Define Security Requirements Standards for your business applications.Which controls are necessaryWhen are they necessary (applicability)Why are they necessary (e.g. SEC, SOX, etc.)
Easy to use reference for requirements teamsStandard method to implement each control
Provide reference on how to implementRequirements for requirements
E.g. The need to specify functional business requirements for access control
22Canike - OWASP AppSec DC 2005
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
23Canike - OWASP AppSec DC 2005
Security Architecture/Design Review
Architecture/Design time assessment of an application and its security controls
Component interface and connection drivenEnumerate 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
24Canike - OWASP AppSec DC 2005
Security Code Review
Focus on code relevant to security Utilize experts
Consider consulting firms with specialized techniques.
Specialized ToolsHave 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.
25Canike - OWASP AppSec DC 2005
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
26Canike - OWASP AppSec DC 2005
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!
27Canike - OWASP AppSec DC 2005
Example Job Aid – Likelihood Factors
WHO? Mitigating Controls Skill Level
All Internet
Customers
System Admins
Direct Access
One Control
Two Controls
Three or more
Unintentional
No special skills
Technical
Very Technical
Attractive?
Very Attractive
Somewhat Attractive
Not Attractive
Well Known?
Public
Internal
Proprietary
Theoretical
IT Employees
CORP IncCORP Inc
LIKEL IHOOD
HIGH
LOW
Illustrative example only.
28Canike - OWASP AppSec DC 2005
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
29Canike - OWASP AppSec DC 2005
Process: Risk Review and Acceptance
Review known security risks and mitigation status prior to production elevation.
Business owners key participantsNeed to understand and accept (or not)
outstanding risks prior to elevationNo surprises…
Dashboard Indicators, Metrics
30Canike - OWASP AppSec DC 2005
Process: Other tests and assessments…. Of course, utilize the gamut of security
assessments, including Internet Penetration TestsNetwork and vulnerability scansServer security scans
Up to you to define the boundary of “Application Security” for your organization.Cooperate, avoid fiefdoms
31Canike - OWASP AppSec DC 2005
Process: Governance Team Reviews
IT-wide governance team of practitioners reviews summaries of security assessments and testsWere 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?
32Canike - OWASP AppSec DC 2005
Components of an Application Security Program
People Policy Standards Awareness Training Roles Priority Expert
Assistance
Technology Standard
Controls Input
Validation Tools
Process SDLC App
Inventory Standard
Requirements Risk
Management Risk Rating Reviews Governance
33Canike - OWASP AppSec DC 2005
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 controlsDashboard Indicators, Metrics
34Canike - OWASP AppSec DC 2005
Technology: Standard Controls (cont.)
Do your standard security controls cover all your application architectures?LAN/Desktop loginWeb (Internet, intranet, J2EE, .NET, LAMP, etc.)Thick desktop clientsApplication Service Providers/Partners – SSO UI tier, Business logic tier, data tierWeb Services
35Canike - OWASP AppSec DC 2005
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?
36Canike - OWASP AppSec DC 2005
Technology: Security Tools
ToolsDevelopersSystem TestersSecurity Assessors/Testers
37Canike - OWASP AppSec DC 2005
People, Process, and Technology all aligned to ensure secure applications.
People Policy Standards Awareness Training Roles Priority Expert
Assistance
Technology Standard
Controls Input
Validation Tools
Process SDLC App
Inventory Standard
Requirements Risk
Management Risk Rating Reviews Governance
38Canike - OWASP AppSec DC 2005
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 applicationsOutsourced applications
In-house SDLC vs. outsourcing requirements and contract language
39Canike - OWASP AppSec DC 2005
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
40Canike - OWASP AppSec DC 2005
Where to start?
Awareness and Training2-hour course: $100-200/seatSeeing the look on the IT VPs’ faces when they
get SQL Injection: Priceless Policies and Standards Application Assessments and Reviews
Get some dataStrive to be consistent and uniform
Support Development Teams
41Canike - OWASP AppSec DC 2005
Questions?
42Canike - OWASP AppSec DC 2005
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