1. Copyright © The OWASP Foundation Permission is granted to copy, distribute and/or modify this document under the terms of the OWASP License. The OWASP Foundation OWASP http://www.owasp.org Organizing a Defensive Posture Source Code, Runtime, WAF, Business Logic, … Fred Donovan OWASP ASDR Member Attack Logic fred.donovan@owasp.org September 2009

2. OWASP 2 Corporate Needs and IT Posture  Detection vs. Prevention vs. Correction?  Which is more important?  Each is equally important  All are required for a Defensive Posture

3. OWASP 3 Awareness Test

4. OWASP 4 Awareness Test – Application Security What are we to be aware of? Should we be preventative or defensive? Perhaps we should rather ask who we are looking for? What are questions to ask the C-level’s?

5. OWASP 5 Preparatory Questions for Business Execs  What are your application security strengths?  How do you measure Risk?  What is the different between an attack and a vulnerability?  Describe the Architecture of your Security  Hardware vs. Software  What learning processes are in place?  Training  Knowledge Transfer  Lessons Learned

6. OWASP 6 Preparatory Questions for Business Clients  What tools do you have in place?  People  Hardware  Software  What areas in your program are excelling?  How many people in your organization are able to assist in building this new program?  What are you looking for?

7. OWASP 7 The Fight You can’t fix what hasn’t been found Hardware Security Solutions vs. Ethical Hacking

8. OWASP 8 Ethical Hacking  Assign a person to your team, that has skills in identifying vulnerabilities on running applications  It is likely that this person does not exist in your current resource pool  Do not hire or use an individual who has been in trouble cracking Websites  Consider the benefit of hiring a temporary resource to build, train, and implement this program

9. OWASP 9 Ethical Hacking SStart your AppSec program by looking at your existing Website(s) TTake the precaution of attacking your own Beta/Dev server rather than a Live system. BBe cool: It is not yet time to perform a SQL Injection or Denial of Service, or anything that is AAggressive

10. OWASP 10 Ethical Hacking – Examples in Action Let’s look at some examples of common mistakes that can be identified with no knowledge of the Development Language in which a Website was coded  These are Hypothetical

11. OWASP 11 Ethical Looks – Examples in Action

12. OWASP 12 Ethical Looks – Examples in Action

13. OWASP 13 Ethical Looks – Examples in Action

14. OWASP 14 Order of Risk – Where to Begin the Process 1.Internet facing – Existing Applications 1.Compliance Risk 2.Personally Identifiable Information 3.Dynamic Functions 2.Intranet Facing 1.Compliance Risk 2.Personally Identifiable Information 3.Dynamic Functionality 3.Desktop Applications 4.Applications Entering SDLC Process

15. OWASP 15 Order of Risk – Measurements  Your task is not to break programs  Your task is to solve a problem that is likely misunderstood  Management will need you to provide statistical measurements  Foremost measurement is Cost  Showing success factors  Be sure to use a common guide for measuring application Risk (e.g. Microsoft DREAD Model)

16. OWASP 16 Order of Risk – Decompose Your Application  Threat Modeling  Identify the entry points of your application  Use Cases  UML Diagrams  Functional Specifications (If they exist)  Identify Data Flow  Diagrams showing the flow of data as it should travel through the application  Identify Data Handoff  Functional Specifications  3 rd party PCI processor  Backend Provisioning

17. OWASP 17 Order of Risk – Mechanisms of Insecurity  Input and Data Validation  Authentication  Authorization  Configuration Management  Cryptography  Hidden Fields (Parameter Manipulation)  Sensitive Information Leakage  Session Management  Exception Handling  Auditing and Logging (Lack of)

18. OWASP 18 Source Code – Another Battle Static vs. Automated

19. OWASP 19 Source Code Cont.  When to utilize Static Source code analysis  Part of the common SDLC Process  Part of the uncommon SDLC Process  What about applications that are built by a third party development group?  Get it in writing!  Acceptance should follow a standard

20. OWASP 20 Source Code Cont A Common Picture of an SDLC Approach  Traditional Pier Review finds the functional bugs in the developers code  This leaves out many of the more serious or critical defects of a program Enter the Security Engineer

21. OWASP 21 Source Code Cont Common Diagram / Un-Common SDLC Approach  Security Engineer  At Design – partner of the normal Design Review Process  At Construction – While developer would Unit Test, the SE provide a more thorough review  At Testing – Perform Automated Review and confirm through Manual verification

22. OWASP 22 Source Code Cont Automated Source Code Scanners CCommon Misunderstanding EEliminates the need for a Security Engineer who can code in multiple languages PPoint and Click BBetter Usage – As a starting point for Source Code Review

23. OWASP 23 Web Application Firewalls Benefits (When aware of Security Violations)  Can be used to harden or validate parameter value formats (In addition to server-side validation or in place of missing validation)  Can implement customized (temporary) signature detection and validation to address known bugs/vulnerabilities that would take much longer to fix in the source code

24. OWASP 24 Web Application Firewalls cont Benefits (When aware of Security Violations)  Can see malicious traffic beyond most IDS/IPS and firewalls  Can be used to force Web page redirects when violations occur

25. OWASP 25 Web Application Firewalls cont  Important Defensive Measure  They are reactionary  Although they prevent attacks, they are not preventive  Choosing to utilize one is a good decision  If you know what you are doing  They Mitigate Risk – They do not Eliminate Risk  Their benefits do not replace the need for Developer Training or Employee Awareness

26. OWASP 26 Awareness and Training  All employees can benefit from an awareness program  Don’t expect employees to read Policies  Providing a class or an interactive Online awareness practicum  Make this mandatory  Implement Annual Re-certifications  Training  Developers, Architects and Testers  Expect Pushback from Personnel  Let them vent – but make them attend

27. OWASP 27 It’s been said…  Cost of repairing a Web Application flaw early in the SDLC is 2% of what it is in Production Ounce Labs (2009)  Pen-testing is a badness-o-meter Gary McGraw  Application Security involves Awareness, Prevention, Detection, and Correction Fred

28. OWASP 28 Summary  Fight your way using the only skills you have  Improve team skills gradually by adding knowledge, tools, or ability experts in areas where skills do not exist  Understand Mitigation vs. Remediation  Integrate Hardware Options (with limitations)  Know What is Acceptable from Management (don’t over do it)  Implement Training and Awareness Programs  Rock on!