Date post: | 19-Oct-2014 |
Category: |
Technology |
View: | 2,144 times |
Download: | 0 times |
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 [email protected](210) 572-4400
Web: www denimgroup comWeb: www.denimgroup.comBlog: denimgroup.typepad.com
33