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 An Architect’s View of Application Security Multi-tiered Systems Rick Carlin, Security Architect rickrcarlin@spherion.com February 2009

2. OWASP Goals  Understand how applications fit into a multi- tiered architecture  Enhance awareness of risk outside the application  Illustrate 10 basic principles to mitigate application security risks

3. OWASP What is a Multi-tiered System (MTS)? MTS is a layered architecture that meets a business need consisting of:  Presentation layer  Application layer  Messaging layer (for multi-DB systems)  Data layer  Network Layer (interconnections)

4. OWASP Risk: Tunnel Vision Multi-tiered architectures are put together by teams, each with their unique vision for the system:  System administrators  Database administrators  Developers  Quality Assurance  Security analysts  Marketing  Communications  Web masters  Business Analysts  Help Desk  Business Units  Legal  Compliance  Human Resources  Project Managers

5. OWASP Risk: Ownership We are hampered in securing “the system” because of ownership issues for “our system” which is a single component in MTS. There is often no responsibility for “System Security” which includes each layer, interconnections and enterprise services

6. OWASP Other Risks to MTS  Vulnerabilities in systems  Vulnerabilities in applications  Vulnerabilities in networks  Vulnerabilities in design  Vulnerabilities in enterprise services  External threats  Internal threats

7. OWASP Mitigating Risk Reduce “Attack Surface” through:  System design  Layered security  Consistent processes Application of security principles (GASP)

8. OWASP

9. 1. Separation of Networks  No direct traffic from external to internal networks (zones)  Routers, switches don’t maintain state!  “Deny all that is not explicitly allowed”

10. OWASP

11. 2. Isolated Network (DMZ)  Buffer network between external and internal networks.  “Presents” the system to the user  Do not mix production and test networks

12. OWASP

13. 3. Sterile Environment  Treat DMZ systems as unsafe  Practice good housekeeping (debugs, dumps, temporary files…)  Secrets are hard to keep

14. OWASP 4. No RA to Mgmt Systems  Many applications offer administrative controls directly via presentation layer (port, url, etc)  Network or server remote access should be blocked (ssh, telnet, pca, rdp, http, etc)  Only allow this access via authenticated, secure RA services (IPSec, VPN, SSL-VPN)

15. OWASP 5. Lockdown before exposure  Require Dev, QA, SA, Sec to complete testing from documented processes  Require an approval process to place system in DMZ  Accept “residual risk” and authorize system operation in writing

16. OWASP 6. Least Access  Access granted at the minimum level required  Practice at system and network level  Document and restrict use of built-in accounts

17. OWASP 7. Least Use  Servers only used for one purpose  Remove unused services and applications  Example: Web server is not the SMTP server

18. OWASP 8. O.S. Isolation  Never install applications on the operating system partition  Use native ACL’s on application directories  No parent paths in applications

19. OWASP 9. Monitoring  Use IDS/IDP  Offload logs to central repository  Custom apps need to generate logs  Understand what’s going on - situational awareness

20. OWASP 10. Encrypted Data Transfer  Understand what data is in your system  Use standard encryption protocols for data in transit (SSL/TLS)  End-to-end encryption (transit to rest)

21. OWASP Enterprise Services  DNS  Time  Patching  Anti-Virus  Logging  Management  Authentication  Code deployment

22. OWASP The Application Interface Don’t trust input! Always perform -  INPUT VALIDATION  BOUNDS CHECKING  Never trust the client!

23. OWASP Layer Interconnections  Use discrete channels  Firewalls track state  End-to-end encryption requires change to host IDS  Don’t reinvent the encryption wheel

24. OWASP Unique to Presentation  Authentication should occur at this layer  Debugging – monitor for use  No dynamic data calls!  Point of attack if everything else is set up properly

25. OWASP Tracking the User  Parameterize the user name  Ensure uniqueness of session ID  Parameterize the session ID  Pass username and session id through successive layers

26. OWASP Unique to Application  Security is defined by business rules  Support teams at tier 2  Forgotten management interfaces  Data cross-roads

27. OWASP Unique to Database  No users access the database  Developers do not access production  Remove access to system stored procedures  All access to data via stored procedure  No code in the tables

28. OWASP Unique to Network  Border router – Not a firewall, but…  blocks rfc1918 both ways  blocks ping (ICMP echo request & echo reply)  blocks network and broadcast addresses  performs anti-spoofing  Developers – don’t invent network protocols, unless that’s your job - the firewall breaks them.  Keep address space to the minimum required

29. OWASP Putting it all Together  Use Firewall and isolated network  Use System build process  Authorize system for operation  Monitor system

30. OWASP

31. NIST Guides to Security http://csrc.nist.gov/publications/PubsSPs.html  SP 800-12 “An Introduction to Computer Security: The NIST Handbook”  SP 800-14 “Generally Accepted Principles and Practices for Securing Information Technology Systems”  SP 800-123 “Guide to General Server Security” Section 2.4 Server Security Principles

32. OWASP Thank you! Rick Carlin, CISSP (2003) 12 Years - IS/IT Security * Security Architect * Senior I.S. Systems Analyst * Security Engineer * Senior Data Security Analyst * Data Security Technician