copyright © 2004 – seagate technology permission is granted to copy and distribute for fair use...

Copyright © 2004 – Seagate TechnologyPermission is granted to copy and distribute for Fair Use Only

The OWASP Foundation

OWASPAppSecJune 2004 NYC

http://www.owasp.org

Case Study: An Evolution of Putting Security into SDLC

Curtis Coleman, MSIA, CISSP, CISMDirector, Global IT GovernanceSeagate Technology

SILICON VALLEY CHAPTERMEETING

2OWASP San Jose Chapter Kick-off


AOL IM Today Gets

Hacked

— Federal Computer Week

April 27, 2002 iPlanet Server hole affects

online banking

— TheRegister

April 28,2001

Hacker Disrupts

University Website

— CNN, Sept 6, 2001

Netscape sees Red as

FBI warns of New

Attack

— Newsbytes, Aug 17, 2001

Military Hackers hit US Defense office

— vnunet.com, April 26, 2002

Code Red:Alive again and Kicking

— Zdnet Aug 1, 2001

Gov’t Payroll System

in Denver Open to

Hackers- MSNBC, July 10, 2001

Canadian Pleads Guilty

to $60 Million Online Fraud

-- Reuters,

April 30, 2002

Hackers force some banks

to cancel Visa debit cards

— ComputerWorld, Sept 5, 2001

Power Grid Vulnerable to

Hackers— LA Times, Aug 13, 2001

IIS Servers can be exploited

unnoticed - SecurityWatch, Sept 6,

2001



Application Security Is the Trend of the Future

“The biggest vulnerability to a corporation’s network is its widespread access to its applications. Security has focused on anti-virus and network security – but the most crucial part of business transaction is the application and its core data.”

-- Curtis Coleman, CISSP, Kick-off of new Application Assurance Department, 2001

3rd Age Age of Application Security2nd Age Age of Network Security1st Age Age of Anti-Virus



Web based technology simplifies attacks

Everyone gets hacked, from large e-Commerce sites, such as Yahoo!, to government agencies, such as the FBI and CIA

In the past a majority of security breaches occurred at the network layer

The next level of attacks will focus at manipulating web applications inside the firewall Given a tiny hole in the application code Armed with only a browser Hackers will access and sabotage corporate and

customer data



Why isn’t the Web Environment secure?

SSL and Data-encryption are not enough They protect the information during

transmission, but when this data is used by the system it must be in a readable form

Odds are the data is not stored in an encrypted format

It is surprisingly easy to retrieve data from many Web-based applications

Firewalls are not enough Ports 80 and 443 pass completely through the

firewall



But, I have a firewall . . .

Source: Jeremiah Grossman, BlackHat 2001



OK, but I use encryption . . .

Source: Jeremiah Grossman, BlackHat 2001



Why Application Security Defects Matter Frequent

• 3 out of 4 business websites are vulnerable to attack (Gartner)

Pervasive

• 75% of hacks occur at the Application level (Gartner)

Undetected

• QA testing tools not designed to detect security defects in applications

• Manual patching - reactive, never ending, time consuming and expensive

Dangerous

• When exploited, security defects destroy company value and customer trust

>1000 application ‘Healthchecks’ with AppScan – 98% vulnerable: all had firewalls and encryption solutions in place…

32% Hijack Session/

Identity Theft

11% e-Shoplifting

21% Full Control and Access to

Information

2% Delete Web Site

27% Privacy Breach

7% Modify Information



Bad Business

• On average, there are 5 to 15 defects in every 1,000 lines of code

US Dept. of Defense and the Software Engineering Institute

Slow Business

• It takes 75 minutes on average to track down one defect. Fixing one of these defects takes 2 to 9 hours each

5 Year Pentagon Study

• Researching each of the 4,200 vulnerabilities published by CERT last year for 10 minutes would have required 1 staffer to research for 17.5 full workweeks or 700 hours

Intel White paper, CERT, ICSA Labs

Loss of Business

• A company with 1,000 servers can spend $300,000 to test & deploy a patch; most companies deploy several patches a week

Gartner Group

Impact of Security Defects



What then shall we do?



Kepner-Tregoe* Situation Appraisal

Lack of resources for security test procedures/processes No means of measuring security testing processes Lack of consistent methodology/process for quality and testing Security test planning and execution is not uniform across IT No security testing standards/guidelines No information assurance test metrics No security test training process No clear definition of roles/responsibilities for security test activities No security acceptance testing standards for purchased products SDLC weak in security test guidelines No centralized process owner for security testing and standards Lack of rigorous security acceptance test processes

* The New Rational Manager, Kepner, H. & Tregoe, B.(1997)



System Development Lifecycle (SDLC) Security Checkpoints



Using Six Sigma in SecurityFor Tool Selection and Improvement



Automating Application Vulnerability Scanning



Key Variables - KPIVs and KPOVs



Fishbone Diagramming of Top Risks

KPIVs



Cause and Effect1 2 3 4 5 6 7 8 9 10

EF

FE

CT

S

Co

ok

ie p

ois

on

ing

Fo

rce

ful b

row

sin

g

Hid

de

n f

ield

ma

nip

ula

tio

n

Pa

ram

ete

r ta

mp

eri

ng

Cro

ss

-sit

e s

cri

pti

ng

Bu

ffe

r o

ve

rflo

w

Ste

alt

h c

om

ma

nd

ing

Pu

blis

he

d v

uln

era

bilit

ies

Th

ird

pa

rty

mis

co

nfi

gu

rati

on

Ba

ck

do

or

an

d d

eb

ug

op

tio

ns

CAUSESCookies can be modified

by client

Application do not force a browsing

order on client

Hidden fields

used to track

session

URL parameters

are changed

Forms accept

metatags

More data than the

application expects

Form fields accept

upload of malicious

code

"Bugs" and

security holes in 3rd party

code

Insecure default

settings in 3rd party

application

Developers insert

backdoors into

applications and forget to remove for production

Return of unarthorized information

to application

Hacker can jump directly

to pages normally

controlled by authentication mechanisms

Hidden fields

can be seen using View

Source

Null value causes

application to enter

undefined state

Metatag characters

are not filtered by

the application

Incoming data size is

not checked

Site defacement

or server execution

of uploaded code

Patches are

delayed while

hackers have

published exploit code

Unclear or lack of

configuration procedures

Debugging is turned on

Previously saved

cookies are modified

and sent as current

cookies to server

Client data is

not validated by server

Parameters are not

checked by application

Field validation on server are not

checked

Patches are not keep

updated

Mis-configurations are published

on hacker sites

Backdoors do not require passwords

Cookier are not

encrypted

Database statements

(insert, delete) are

not validated

Error messages and comments in

the code reveal

vulnerabilities



Measurement Systems Analysis – Design of ExperimentFully automated (without operator inference)

Design:– Test Site and scan tool on same machine– 30 scan runs with randomized start time– Classified for High-Medium-Low and Total Vulnerabilities

Conclusion: – Ability of Scan Tool to discriminate good from bad is suspect– MSA feedback to Tool Maker results in observed improvements when

applying latest subscription.Operator test

Design:– Same location, same machine, same Test Site– Operator manually steps through application– 3 operators, 3 sets of 10 scans

Conclusion:– Operator experience with Tool is key– Knowledge of application logic is important– New operators could run tool with minimum training and detect Red

Alerts



MSA: Measurement system is unreliable Tool was in its second patch release when Seagate adopted MSA showed the tool was not stable The MSA results were shared with the Sanctum’s CTO

Measurement system is suspect: 30 scans of single site should reveal the same number of High, Medium, and Low risk alerts each time scan is run



Using Auto Mode, AppScan correctly identified the number of highs, mediums, and low vulnerabilities of the Hack-Me Web site. Test was repeated 30 times.

MSA: Tool Improves After Feedback

Measurement system stablized: Over a period of 2 months and three generations of the tool code, the tool was calibrated and improved.



MSA: Demonstrates Tool Training is Important!The operators used the tool in “manual” mode. Total number of possible High vulnerabilities detected by manual mode is 99.

Anil – Most advanced operator, formal training with scan tool, knows application logic, clustered at 98/99

David – Very experienced with tool, clustered around 92 Curtis – Never used tool before MSA test, clustered around 79



Pareto (80/20) Rule

Low-Parameter

tampering

High-Param

eter ta

mpering

High-Cross site sc

ript ing

Medium-Forcefu

l browsing

Medium-Para

meter tamperin

g

Medium-Cookie poisoning

Others

3901 2180 2064 184 181 123 38343.3 24.2 22.9 2.0 2.0 1.4 4.2 43.3 67.4 90.3 92.4 94.4 95.8 100.0

0

1000

2000

3000

4000

5000

6000

7000

8000

9000

0

20

40

60

80

100

Defect

CountPercentCum %

Perc

ent

Cou

nt

Pareto for Vulnerabilities



What Then Shall We Test For?

These Categories Are of Most Importance… Hidden Field Manipulation Parameter Tampering Cross-site Scripting Buffer Overflow Backdoor and Debug Options Cookie Poisoning Forceful Browsing Published Vulnerabilities Stealth Commanding Third Party Misconfigurations



Vulnerability Categorty Vs Severity

1

3

2

1

1

1

2

2

1 1

1

0

1

2

3

4

5

Parametertampering

Data Flow Forcefulbrowsing

Cross-sitescripting

Buffer overflow Stealthcommanding /SQL Injection

Publishedvulnerabilities

Hidden fieldmanipulation

Vulnerability Category

No

. Of

Vu

lner

abili

ties

Op

en

RedYellow

Source: TestDirector

A Tool For Tracking Test Results



Provide Detail Report to Customer



Sample of Prioritizing Findings

Low

Vulnerability

High

Vulnerability

Low Threat

High Threat

4

3 2

1V3

V4

V5

V6

V7

Hidden Field Manipulation

Parameter Tampering

V1

Forceful Browsing

V2

V8

Cookie Poisoning



2004 Statistical Analysis of Application Vulnerabilities Discovered and Resolved

Stealth commanding/ SQL Injection

6%Hidden field manipulation

9%

Published vulnerabilities5%

Data Flow4%

Cross-site scripting26%

Parameter tampering26%

Forceful browsing14%

Third party misconfigurations

10%

Discovered Vulnerabilities Resolved and Open Vulnerabilities

Total: 176

R/Y: 65/111

Total: 89

R/Y: 2/87



Having the Tool is Nice, Having A Report is Good,

But I Need A Process – Just How Do You Conduct An Application Assurance Assessment?

Prepared by Kris Kahn, Anil Ghanta, & David Viveiros

Seagate Application Assurance Team



Our Approach

Target areas to get the most bang for the buck Review process in conceptual phase of project to

identify risks to the company, e.g. financial transactions, client data, personal information, etc.

Risk based approach – high risk applications have more requirements and more budget allocated for security.

Security Architecture review to identify design flaws

Application Assurance Review before promotion to production

Build Secure Enterprise Application Infrastructure



Process Flow SDLC

Design Include Security Principles

Develop Include Application Security Recommendations (OWASP) Include System hardening standards Include Oracle Security Best Practices

Test Submit request for Security Assessment (2-3 weeks advance

notice) Staging

Security Assessment is performed to include DB configuration audit

Production Include e-Security as part of your code change control process for

significant application changes Future Compliance Audits



6-Layers Assessment ProcessPhysical

Access control, fire protection, disaster recovery, data storage, etc.

Network Risks and vulnerabilities over the network

System Risks and vulnerabilities in system configuration

Application Weaknesses in web-based applications, Oracle applications (using

AppScan and ESM for Oracle)

Data Flow Weaknesses in the data flow (lack of encryption for confidential

information, etc.)

Process Data backup, disaster recovery, patch updates, user management,

change management, etc.



Assessment Process

Phase 1: Initiate E-Security Manager assigns resource(s) to project E-Security Manager passes football to lead assessor

Phase 2: Kick-Off E-Security and project team review assessment process and synchronize

timelines Assessor(s) meets project team

Phase 3: Gather Information Assessor interviews project team using checklist E-Security reviews all layers to determine assessment scope Project team provide a demonstration of the application to the assessor

Phase 4: Generate Plan E-Security create an assessment plan based on information gathered and

provides it to the project team for validation of scope

Phase 5: Perform Assessment Assessor performs vulnerability scans with appropriate tools and manual

testing Assessor notify e-Security Management and project team if critical

vulnerabilities are discovered during testing



Assessment Process

Phase 6: Generate Report Assessor analyzes scan results to determine threat and probability of

identified vulnerabilities Assessor documents recommendations and findings from analysis in

Assessment Report (football) E-Security Management reviews report and passes football to project

team

Phase 7: Close-Out E-Security and project meet to review assessment report, open items are

identified and action plans are established

Phase 8: Resolution and Support Project team reviews and implements recommendations Project team reports actions in report Project team passes football back to e-Security Assessor validates fixes applied (go to Phase 5: Perform Assessment)

Process Exit: E-Security Certification for Production Deployment Provided for application when all critical vulnerabilities have been

confirmed to be resolved



Assessment Process Map

IT Staff

Assess Risk

Project Owner SubmitsRequest

Perform Assessment

Generate Report Project Approved

Policy ExceptionRisk Acceptance

ReviewRequest

Review Report

CriticalVulnerabilities?

No

Review Report

Yes

ApplyFixes

Fix orgo live?

Go liveFix

AssessmentApproved?

RequestDeferred or Rejected

Yes

No

Risk Discovery

SVPs

E-Security

Bus. Units

Assessment Cycle



Assessment Deliverables

Assessment Plan Details of assessment scope and tool configuration

Assessment Report Detailed analysis of findings Recommendations for fixing or mitigating issues

Certification No red flags means project is certified to go live! Yellow flags will be reviewed by Electronic Security and

project team for overall risk. Cannot go live with red flags.



Compliance Audit

Confined Scope Assessment Re-Assessment integrated as part of Application

Change Control Process for significant changes Significant changes includes

– User interface– Back-end processing– New features for enhanced functionality– Does not include hot-fixes or most incremental patches

for security updates Validates certification to ensure security and

determines if new vulnerabilities have been introduced



Have You May Any Changes For Sarbanes-Oxley?

IT Governance & SDLC



COBIT Application Development ControlsPO 4 – Define the Information Technology Organization &

Relationships PO 4.4, Roles & Responsibilities PO 4.7, Ownership & Custodianship PO 4.10, Segregation of Duty (SOD)

PO 10 - Manage Projects PO 10.01, Project Management Framework PO 10.02, User Participation in Project Initiation PO 10.03, Project Team Membership & Responsibilities PO 10.04, Project Definition PO 10.05, Project Approval PO 10.06, Project Phase Approval PO 10.07, Project Master Plan PO 10.08, System Quality Assurance Plan PO 10.09, Planning of Assurance Methods PO 10.10, Formal Project Risk Management PO 10.11, Test Plan PO 10.12, Training Plan PO 10.13, Post-Implementation Review Plan

PO 11 - Manage Quality PO 11.05, Systems Development Life Cycle Methodology PO 11.08, Coordination and Communication



COBIT Application Development ControlsAI 2 - Acquire & Maintain Application Software

AI 2.01, Design Methods AI 2.02, Major Changes to Existing Systems AI 2.03, Design Approval AI 2.04, File Requirements Definition & Documentation AI 2.05, Program Specifications AI 2.06, Source Data Collection Design AI 2.07, Input Requirements Definition & Documentation AI 2.08, Definition of Interfaces AI 2.09, User-Machine Interface AI 2.10, Processing Requirements Definition & Documentation AI 2.11, Output Requirements Definition & Documentation AI 2.12, Controllability AI 2.13, Availability as a Key Design Factor AI 2.14, Integrity Provisions in Application Program Software AI 2.15, Application Software Testing AI 2.16, User Reference and Support Materials AI 2.17, Reassessment of System Design

AI 6 - Manage Change AI 6.01, Change Request Initiation & Control AI 6.02, Impact Assessment AI 6.03, Control of Changes AI 6.04, Emergency Changes AI 6.05, Documentation & Procedures AI 6.06, Authorized Maintenance AI 6.07, Software Release Policy AI 6.08, Distribution of Software



Summary of Key Controls for Sarbanes-Oxley



Web Application Assurance Checklist& e-Security Academy Course



Questions?

copyright © 2004 – seagate technology permission is granted to copy and distribute for fair use...

Documents