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

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

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)

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

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

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

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

OWASP

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”

OWASP

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

OWASP

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

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)

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

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

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

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

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

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)

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

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

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

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

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

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

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

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

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

OWASP

NIST Guides to Security  SP “An Introduction to Computer Security: The NIST Handbook”  SP “Generally Accepted Principles and Practices for Securing Information Technology Systems”  SP “Guide to General Server Security” Section 2.4 Server Security Principles

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