establishing an enterprise application security program

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.


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


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…


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


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.


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


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


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


How much security do we need?


Components of an Application Security program


Assistance

Technology Standard

Controls Input

Validation Tools

Process SDLC App

Inventory Standard

Requirements Risk



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


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…



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


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,…


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


Components of an Application Security Program


Assistance

Technology Standard

Controls Input

Validation Tools

Process SDLC App

Inventory Standard

Requirements Risk



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?



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


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


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


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


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


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.


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


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!


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.


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



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…



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


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?


Components of an Application Security Program


Assistance

Technology Standard

Controls Input

Validation Tools

Process SDLC App

Inventory Standard

Requirements Risk



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


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


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?


Technology: Security Tools

ToolsDevelopersSystem TestersSecurity Assessors/Testers


People, Process, and Technology all aligned to ensure secure applications.


Assistance

Technology Standard

Controls Input

Validation Tools

Process SDLC App

Inventory Standard

Requirements Risk



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


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


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


Questions?


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

establishing an enterprise application security program

Documents