web application remediation - owasp san antonio march 2007

Web Application Remediation

OWASP San Antonio

March 28th, 2007

Agenda

• Introduction• The Problem: Vulnerable Web Applications• Goals• Example Process Overview• Real World Issues To AddressReal World Issues To Address• Conclusion/Questions

1

Introduction

• Dan Cornell• Principal of Denim Group, Ltd.• Background in Software Development

– Java/JEE, .NET, etc– Java Certified Programmer, MCSD

2

Problem: Vulnerable Web Applicationspp• Your organization has identified and verified vulnerabilities in a

web application• How did you find out?

– Evidence of exploitation– External assessment or audit

I l i– Internal review

3

Goals

• Address Organizational Risk• Options:

– Fix it– Turn it off– Live with it

• Often no easy answers• Any solution must be business-driven

– Risk mitigation strategies

4

Before You Start

• Know your stakeholders – who cares about having vulnerabilities remediated

– 3rd party client– Security team– Internal/external audit

This ill determine the le el of rigor• This will determine the level of rigor– Thoroughness of testing– Volume of documentation

• Much easier to know up front than to try and reconstruct at the• Much easier to know up front than to try and reconstruct at the end

5

Example Process Overview

• Inception:– Identify Vulnerabilities– Rank– Planning Game– Prepare

Execution:• Execution:– Remediate

• Completion:Confirm– Confirm

– Report– Deploy

• Repeat as Necessary..

6

Identify Vulnerabilities

• How does this happen?– Evidence of exploitation– External assessment or penetration test– Internal assessment or audit

7

Rank

• Need to know the severity of vulnerabilities• Think in terms of:

– Confidentiality– Integrity– Availability

• Data classification policies are key– Your organization has a data classification policy, right?

• Rankings will vary by organization and by application

8

STRIDE

• Used to classify threats to an application

• Spoofing Identity• Tampering with Data• RepudiationRepudiation• Information Disclosure• Denial of Service

El ti f P i il• Elevation of Privilege

9

DREAD

• Used to rank the severity of vulnerabilities

• Damage potential• Reproducibility• ExploitabilityExploitability• Affected Users• Discoverability

• Recommend 1-3 scale rather than 1-10– How do you know if something is a 7 or an 8?

10

Planning Game

Propose SolutionSolution

Estimate Level of

EffortMake

Decision

Weigh Level of

ProtectionProtection

11

Propose Solution

• Coding Fix– No change in functionality for valid inputs

• Configuration Change• Functionality Change

– Could be large or small– May have significant requirements, architecture or design implications

• Web Application Firewall• Do Nothingg

12

Estimate Level of Effort

• Code changes tend to be simple but are often widespread throughout the application

• Functionality changes have a wide range depending on their impact

– Architecture or design changes– Business process impact

• Web Application Firewalls– Train

D l– Deploy– Manage

• Doing nothing is always easyIn the short term at least– In the short term at least…

13

Weigh Level of Protection

• SDL: Fix security bugs the right way• That is nice, but not always appropriate (unfortunately)• Quantitative Risk Assessment

– Challenging because of a lack of actuarial data– SLE – Single Loss Expectancy– ARO – Annual Rate of Occurrence– ALE – Annual Loss Expectancy– ROSI – Return on Security Investment

Q lit ti Ri k A t• Qualitative Risk Assessment– Return to data classification, STRIDE, and DREAD

14

Make Decision

• Remember that the goal is to appropriately address risk

15

Prepare

• Planning Game should have resulted in a remediation plan– What is going to be fixed and how?

• Develop test plan to confirm the remediation worked after completion

• Two types of testing– Positive– Negative

16

Positive Testing

• “Do No Harm”• Make sure the application works for valid inputs before and after• Tests should pass before and pass after

17

Negative Testing

• Make sure the remediation worked• Tests should fail before and succeed after

18

Automated Testing

• Automate as much as possible• Reasons

– Easier to test and re-test– Test scripts offer repeatable demonstration of behavior

• Types– Web Application Scanners– Unit Testing– Acceptance Testing

19

Automated Testing: Web Application Scannerspp• Compare before and after results• Most modern application scanners will compare or trend results• Excellent choice if organizations have a scan template that is a

“standard”

20

Automated Testing: Unit Testing

• Frameworks:– JUnit: www.junit.org– Nunit: www.nunit.org

21

Automated Testing: Acceptance Testingg• Frameworks

– Web Application Tests In Ruby: wtr.rubyforge.org– Web Application Tests In Java: www.watij.com– Web Application Tests In .NET: watin.sourceforce.net– Perl Mechanize: search.cpan.org/dist/WWW-Mechanize

22

Remediation Testing Patterns

• SQL Injection and Cross Site Scripting (XSS)– Fairly simple coding fixes– May be widespread– Before and after tests should be self explanatory

• AuthorizationS i t t ith diff t l– Script access to pages with different roles

• Parameter Tampering / Insecure Direct Object Reference– Testing will be data driven and specific to login

23

Remediate

• Now you actually get to make changes• Often the easiest phase• Do not forget about change control

– Tag or branch source code repositories– Note before/after versions for policies and procedures

24

Confirm

• Run through test plan• Run automated tests• Capture the results

– These will be used for reporting later

• Separation of dutiesp– One individual or team should remediate– Another individual or team should confirm that remediation was effective

25

Report

• Who are the “clients” of the remediation?– Actual 3rd party client?– Security team– Internal/external audit– Executive sponsor

Different groups will have different needs and different reporting• Different groups will have different needs and different reporting requirements

• Repeatable output from automated scripts is often usefulU l id li b li h l if• Use source control to provide line-by-line change logs if necessary

26

Deploy

• Deploying security remediation updates should be treated as any other significant release

27

Real World Concerns

• Who is going to do the work?• How does remediation get prioritized alongside other efforts?

28

Real World Concerns

• Who is going to do the work?– In house developers

• Do they have the requisite security knowledge?• Is it possible to allocate their time (versus existing projects)?

– 3rd party• Can they learn enough about the application?• How will they get access to the code and environment?

29

Real World Concerns

• How does remediation get prioritized alongside other efforts?– Business decision for the organization– Often compliance or Service Level Agreement (SLA) issues making security

remediation a priority

30

Process Improvement

• “Those who cannot remember the past are doomed to repeat it” (George Santayana)

• If an organization does not learn from their security mistakes they will repeat those security mistakes

• What to learn from remediated vulnerabilities?– Do coding standards need to be updated to help protect against technical

application vulnerabilities?• (Does the organization need coding standards?)

– What activities in the SDLC would have helped prevent the injection ofWhat activities in the SDLC would have helped prevent the injection of these vulnerabilities or would have caught them sooner

• Threat Modeling / Risk Assessment• Security code reviews

31

Thoughts and Conclusions

• Application security remediation must be business-focused because there is never enough time to fix everything perfectly

• Communication is essential – what is going to be fixed and under what conditions?

• Understand the constituencies up front so appropriate documentation and confirmation occurs

• Automate testing wherever possible to facilitate iterative development as well as create repeatable demonstrations ofdevelopment as well as create repeatable demonstrations of progress

32

Questions

Dan Cornelldan@denimgroup.com(210) 572-4400

Web: www denimgroup comWeb: www.denimgroup.comBlog: denimgroup.typepad.com

33