Web Application Remediation - OWASP San Antonio March 2007

2,621 views

Published on

This presentation covers best practices for organizations looking to remediate software and application security vulnerabilities they have identified in their application portfolios.

Published in: Technology
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,621
On SlideShare
0
From Embeds
0
Number of Embeds
259
Actions
Shares
0
Downloads
51
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

Web Application Remediation - OWASP San Antonio March 2007

  1. 1. Web Application Remediation OWASP San Antonio March 28th, 2007
  2. 2. Agenda • Introduction • The Problem: Vulnerable Web Applications • Goals • Example Process Overview • Real World Issues To Address • Conclusion/Questions 1
  3. 3. Introduction • Dan Cornell • Principal of Denim Group, Ltd. • Background in Software Development – Java/JEE, .NET, etc – Java Certified Programmer, MCSD 2
  4. 4. Problem: Vulnerable Web pp Applications • Your organization has identified and verified vulnerabilities in a web application • How did you find out? – Evidence of exploitation – External assessment or audit – I Internal review l i 3
  5. 5. 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
  6. 6. Before You Start • Know your stakeholders – who cares about having vulnerabilities remediated – 3rd party client – Security team – Internal/external audit • This will determine the le el of rigor ill level – Thoroughness of testing – Volume of documentation • Much easier to know up front than to try and reconstruct at the end 5
  7. 7. Example Process Overview • Inception: – Identify Vulnerabilities – Rank – Planning Game – Prepare • Execution: – Remediate • Completion: – Confirm – Report – Deploy • Repeat as Necessary.. 6
  8. 8. Identify Vulnerabilities • How does this happen? – Evidence of exploitation – External assessment or penetration test – Internal assessment or audit 7
  9. 9. 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
  10. 10. STRIDE • Used to classify threats to an application • Spoofing Identity • Tampering with Data • Repudiation • Information Disclosure • Denial of Service • Elevation of Privilege El ti f P i il 9
  11. 11. DREAD • Used to rank the severity of vulnerabilities • Damage potential • Reproducibility • Exploitability • Affected Users • Discoverability • Recommend 1-3 scale rather than 1-10 – How do you know if something is a 7 or an 8? 10
  12. 12. Planning Game Propose Solution Estimate Make Level of Decision Effort Weigh Level of Protection 11
  13. 13. 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 Nothing g 12
  14. 14. 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 easy – In the short term at least… least 13
  15. 15. 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 • Qualitative Risk Assessment Q lit ti Ri k A t – Return to data classification, STRIDE, and DREAD 14
  16. 16. Make Decision • Remember that the goal is to appropriately address risk 15
  17. 17. 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
  18. 18. Positive Testing • “Do No Harm” • Make sure the application works for valid inputs before and after • Tests should pass before and pass after 17
  19. 19. Negative Testing • Make sure the remediation worked • Tests should fail before and succeed after 18
  20. 20. 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
  21. 21. Automated Testing: Web Application Scanners pp • 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
  22. 22. Automated Testing: Unit Testing • Frameworks: – JUnit: www.junit.org – Nunit: www.nunit.org 21
  23. 23. Automated Testing: Acceptance g Testing • 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
  24. 24. 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 • Authorization – S i t access to pages with diff Script t ith different roles t l • Parameter Tampering / Insecure Direct Object Reference – Testing will be data driven and specific to login 23
  25. 25. 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
  26. 26. Confirm • Run through test plan • Run automated tests • Capture the results – These will be used for reporting later • Separation of duties p – One individual or team should remediate – Another individual or team should confirm that remediation was effective 25
  27. 27. 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 requirements • Repeatable output from automated scripts is often useful • Use U source control to provide li b li change l l id line-by-line h logs if necessary 26
  28. 28. Deploy • Deploying security remediation updates should be treated as any other significant release 27
  29. 29. Real World Concerns • Who is going to do the work? • How does remediation get prioritized alongside other efforts? 28
  30. 30. 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
  31. 31. 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
  32. 32. 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 of these vulnerabilities or would have caught them sooner • Threat Modeling / Risk Assessment • Security code reviews 31
  33. 33. 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 of progress 32
  34. 34. Questions Dan Cornell dan@denimgroup.com (210) 572-4400 Web: www denimgroup com www.denimgroup.com Blog: denimgroup.typepad.com 33

×