Application Security in the Real World

1. Application Security In the Real WorldWhat the OWASP Top 10 means to everyone Lora Vaughn McIntosh Security Engineering Blue Cross Blue Shield of Alabama Lora.McIntosh@bcbsal.org (205)220-2181

2. About Me • BS Computer Science from Birmingham-Southern College • Formerly employed at Accenture, National Security Agency, Regions Bank • Certifications: • Certified Information Systems Security Professional (CISSP) • EnCase Certified Examiner (EnCE)

3. Agenda • What’s an OWASP? • Why should I care? • Security myths • Hacks in the news • OWASP Top 10 in 10 minutes or less • Legacy and third party applications • Defense in depth • Where do you start?

4. OWASP Who??? • Open Web Application Security Project • 501c3 not-for-profit • Focused on improving the security of application software • Release Top 10 List periodically • 2010 • 2007 • 2004

5. Application Security:Why should I care?

6. Progress—You can’t have it all • Business demands more bells and whistles • Internal applications get ‘web-enabled’ and are exposed to Intranet or Internet • Increasing complexity of software • Rush software out without adequate testing • Poor security training and awareness

7. Things Have Changed • Threats have evolvedas the Internet and our world have evolved • Any website you visit could infect your browser—even a Google search • An infected browser can do anything you can do • An infected browser can scan, infect, spread Source: owasp.org

8. Regulations • If you’re lucky enough to NOT need to meet • PCI • SOX • HIPAA • GLBA • Etc…. That’s nice, BUT what about • Your proprietary data? • Customer confidence? • Impact to operations? • Data integrity? You still need to consider security. Period. After all, you may just be one congressional session way from a new regulation.

9. So What??? • Defacement • Phishing • Denial of Service • Data Loss • Bot Infection • Loss of <fill in the blank> • Legal action • ... See the Web Hacking Incidents Database on http://www.webappsec.org/projects/whid/

10. Ok, you’ve got me there… How about I throw some money at the problem? Buy some tools!

11. Well…. Tools Can’t Fix Everything MITRE found that all application security tool vendors’ claims put together cover only 45% of the known vulnerability types (over 600 in CWE) They found very little overlap between tools, so to get 45% you need them all (assuming their claims are true) Source: owasp.org

12. Great… But I have other controls!Security Myths

13. The Trouble with Firewalls • Joe User says: “But we have a firewall”! • 75% of Internet Vulnerabilities are at the application layer, not the network layer • Gartner • Firewalls have to allow some things through, and attackers have adapted.

14. The Trouble with Firewalls Illustrated Source: Jeremiah Grossman, BlackHat 2001 Source: owasp.org

15. But… But… We use SSL! • SSL only secures data in transit • Does not solve vulnerabilities on: • Applications • Web server • Browser • If you exploit the application, any data at rest encryption is useless too.

16. SSL Illustrated Source: Jeremiah Grossman, BlackHat 2001 Source: owasp.org

17. Myth – my perimeter will save me Your security “perimeter” has huge holes at the application layer Custom Developed Application Code Application Layer Databases Legacy Systems Web Services Directories Human Resrcs Billing APPLICATIONATTACK App Server Web Server Hardened OS Network Layer Firewall Firewall You can’t use network layer protection (firewall, SSL, IDS, hardening) to stop or detect application layer attacks Source: owasp.org

18. Real Life Application (?) Hacks • CitiGroup • May 2011 • Approximately 210,000 credit card holders • “Basically after you logged into your account as a Citi customer, the URL contained a code identifying your account. All you had to do was change around the numbers and boom, you were in someone else's account” • StuxNet • Targeted Siemens SCADA systems of Iranian nuclear facilities • Stolen encryption keys used to sign infected drivers • Zappos • January 2012 • 24+ Million customer accounts • Name, e-mail, billing and shipping addresses, phone numbers, last 4 of credit card, encrypted passwords • TJ Maxx • 2007 • 45.7 million credit/debit cards

19. OWASP Top 10 in 10 Minutes or less

20. OWASP Top 10 Risk Rating Methodology 1 2 3 Injection Example 1.66 weighted risk rating Source: owasp.org

21. OWASP Top Ten (2010 Edition) http://www.owasp.org/index.php/Top_10 Source: owasp.org

22. A1 – Injection Source: owasp.org

23. SQL Injection • A common issue in most applications • Can only occur when the application is building dynamic SQL that contains a string that is tainted with user supplied data http://xkcd.com/327/

24. SQL Injection in the Wild

25. A2 – Cross-Site Scripting (XSS) Source: owasp.org

26. XSS In The Real World

27. A4 – Insecure Direct Object References Source: owasp.org

28. Insecure Direct Object References Illustrated • Attacker notices his acct parameter is 6065 ?acct=6065 • He modifies it to a nearby number ?acct=6066 • Attacker views the victim’s account information • Look familiar??? https://www.onlinebank.com/user?acct=6065 Source: owasp.org

29. A5 – Cross Site Request Forgery (CSRF) Source: owasp.org

30. A6 – Security Misconfiguration Source: owasp.org

31. A7 – Insecure Cryptographic Storage Source: owasp.org

32. A8 – Failure to Restrict URL Access Source: owasp.org

33. A9 – Insufficient Transport Layer Protection Source: owasp.org

34. A10 – Unvalidated Redirects and Forwards Source: owasp.org

35. What about… Legacy Applications

36. Legacy Application Problems Old Frameworks + Old Code + Old Vulnerabilities = Low hanging fruit We didn’t even know about some of these attacks 10 years ago How old are your apps?

37. Don’t forget 3rd Party Apps • Think • Frameworks • HR software • Data analytics tools • Cloud

38. So… Where do you Start???

39. Defense in Depth • Multiple layers of protection reduces the likelihood that an attacker will be successful • Firewall, IDS, etc? Useful technologies, but not as your sole defense • Penetration testing • Code analysis • Security training for your developers

40. Write secure code in the first place • Build procedures into the process to mitigate risk (SDLC) • Create standards that will assist in answering FAQs • Libraries and best practices for coding • Follow the best practices in OWASP’s Guide to Building Secure Web Applications • http://www.owasp.org/index.php/Guide • Use OWASP’s Application Security Verification Standard as a guide to what an application needs to be secure • http://www.owasp.org/index.php/ASVS • Use standard security components that are a fit for your organization • Use OWASP’s ESAPI as a basis for your standard components • http://www.owasp.org/index.php/ESAPI Don’t reinvent the wheel. If you try to write your own cleansing functions, you WILL miss something. Unless you’re a coding God, but even then…

41. But that ship already sailed, so…Know your data • What data do you care about? • Regulations help – PCI, GLBA, HIPAA • Proprietary data—What’s your “secret sauce”? • What types of data do you have? • Where is that data? • Is it encrypted? Should it be? • How about backups? • Are you sure it’s not sitting on Susan’s workstation because “it’s easier if I don’t have to log on to the server”? • Who has access to that data? • Should they have access to it? • What happens when they change roles or jobs?

42. Baby Steps - Policy • State that you intend to write secure code • Policy for remediating legacy code • Get security into the overall procurement and development cycle

43. Baby Steps - Standards • Incorporate secure development standards (Start with OWASP?) • Require minimums • In the lifecycle, get stop points in place – QA cycle?

44. Baby Steps - Procedures • Pre-deployment checklists--a low cost approach to building application security in • Code reviews • Formal application security testing • Remediation plans

45. Tools and Services • Review Your Applications • In house manual code review • Not a bad idea, but how many of your developers know the ins and outs of every single application vulnerability and exploit? • Application assisted static code analysis • Look into products like HP Fortify, Rational, Veracode, etc. • Most of these offer cloud and local solutions • Large amounts of tuning required to make sure your environment is reflected • Have an expert team or service review your applications • Review your applications yourselves following OWASP Guidelines • OWASP Code Review Guide: http://www.owasp.org/index.php/Code_Review_Guide • OWASP Testing Guide: http://www.owasp.org/index.php/Testing_Guide

46. Options: Web Application Firewalls • Can you spend the money? • Do you have the staff to manage one? • OWASP has great resources on when and where to use them

47. Code Analysis • Dynamic, static, or both? • Each type can miss things • A combination is probably best, but can be costly • On premise, hosted, or hybrid? • Do you have the staff to implement? • Plans to remediate findings?

48. Tools… again Dynamic Analysis Static Analysis • Vendors • Accunetix • Cenzic • HP Fortify • IBM • Veracode • Open Source (free or lower cost) • WebScarab • Nikto • Paros • Vendors • Coverity • IBM • HP Fortify • Veracode • Open Source (free or lower cost) • FindBugs (Java only) • Other options, but mostly targeting specific vulnerabilities like

49. You have tools – now what??? • Back to the people side • Sell it (much easier if you have regulations behind you) • Training • User • Administrator • Team to administer • Audit • Make sure developers are following procedures and using the tool • Ensure new vulnerabilities aren’t added – think “No new critical flaws” • Reporting • Can save you in an audit • Good place for metrics • . . . • Profit!!! Source: owasp.org

50. Questions?