Secure Design Patterns

1. Secure Design Patterns James Walden Northern Kentucky University

2. Topics • Design Patterns • Security Patterns • MTA Architecture Example • OpenSSH Architecture Example • PatternShare Patterns CSC 666: Secure Software Engineering

3. Design Patterns • A solution to a problem in context that can be re-used in different ways in software. • Standard name • Concise summary of problem • Description of solution, usually with UML • Examples of pattern in use • Pattern variations • Architectural patterns • Antipatterns • Pattern languages CSC 666: Secure Software Engineering

4. Security Patterns • A solution to a recurring security problem. • Often are not design patterns with UML. • Scope • Design principle • Architectural • Procedural • Design CSC 666: Secure Software Engineering

5. Security Patterns Sources • Munawar Hafiz, "Security Patterns and Secure Software Architecture," OOPSLA Tutorial 51, OOPSLA ’06, 2006. available https://netfiles.uiuc.edu/mhafiz/www/research/patterns/Patternshare_Security_Patterns.ppt • Darrel M. Kienzle and Matthew C. Elder, "Final Technical Report: Security Patterns for Web Application Development," available at http://www.scrypt.net/~celer/securitypatterns/, 2002. • Markus Schumacher at. al., Security Patterns—Integrating Security and Systems Engineering, Wiley, 2006. • Security Patterns home page, available at http://www.securitypatterns.org/patterns.html • Joseph Yoder and Jeffrey Barcalow, "Architectural Patterns for Enabling Application Security." Proceedings of the 4th Conference on Patterns Language of Programming (PLoP’97), 1997. CSC 666: Secure Software Engineering

6. Mail Transport Agent MTA Requirements • Receive mail from local users • Receive mail from remote users • Deliver mail to local users • Send mail to remote users CSC 666: Secure Software Engineering

7. Security Requirements of a MTA Administrative access required for • Opening port 25 for SMTP. • Delivery of mail to local users. Administrative or group account needed to • Create files in mail queue. • Delete files from mail queue. CSC 666: Secure Software Engineering

8. Architecture of Sendmail Monolithic program performs all tasks • Always runs as root. • Drops privilege when unnecessary. • Large code base. • Complex configuration files. Security history • Debug command exploited by Morris worm. • Many remote root exploits. • Last root exploit in 2006. CSC 666: Secure Software Engineering

9. Architecture of qmail CSC 666: Secure Software Engineering

10. Pattern: Compartmentalization • Problem: A security failure in one part of a system allows another part of the system to be exploited. • Solution: Put each part in a separate security domain. Even when the security of one part is compromised, the other parts remain secure. CSC 666: Secure Software Engineering

11. Pattern: Distributed Responsibility • Problem: A security failure in a compartment can cahnge any data in that compartment. A compartment has both an interface that is at risk of a security failure and data that needs to be secure. • Solution: Partition responsibility across compartments such that compartments that are likely to fail do not have data that needs to be secure. Assign responsibilities in such a way that several of them need to fail in order for the whole system to fail. • AKA: Distributed Delegation CSC 666: Secure Software Engineering

12. qmail queue • All messages stored in queue first. • Queue is accessible only by qmailq user. • Subdirectories • pid: initial location of messages; files named after process ID of qmail-queue process • mess: second location of messages; files named after inode to ensure uniqueness • intd: contains envelopes for each message • todo: links to envelopes to be delivered CSC 666: Secure Software Engineering

13. Pattern: Unique Atomic Chunks • Problem: Many processes need to add information to a database concurrently. How do we ensure that multiple write operations are handled correclty and even if there is a crash no trace is left of the failure? • Solution: Ensure that every write request is to a different location. Thus, different processes are never writing to the same file at the same time. CSC 666: Secure Software Engineering

14. Pattern: Checkpointed System • Problem: A component failure can result in loss or corruption of state information maintained by the failed copmonent. How can we design a system so that its state can be recovered and restored to a knonw valid state in case a component fails? • Solution: Design the system as a FSM. Make the state information persistent. Use configurations that provide ability to restart system from known valid state. CSC 666: Secure Software Engineering

15. Architecture of Postfix Uses many of same patterns as qmail. • Compartmentalization • Distributed responsibility Adds focus on compatibility • Uses mbox as well as maildir format. • Violates Unique Atomic Chunks in mbox mode. Adds focus on performance • Qmail uses processes for single delivery. • Postfix processes last longer. • Uses Secure Preforking pattern. CSC 666: Secure Software Engineering

16. Pattern: Secure Preforking • Problem: The consequences of security compromise are worse in the case of daemon processes because they have a long lifetime. How can the vulnerability associated with daemon processes be reduced? • Solution: Limit the lifetime of daemon processes and fork them again after a configurable, short lifetime. Run the daemons in a contained environment to minimize the exploits. CSC 666: Secure Software Engineering

17. Architecture of OpenSSH SSH login requires privileges to • Open port 22. • Access host key and password information. • Open new pseuo-terminal devices. • Change UID to that of user logging in. Privilege separation • Divide SSH into multiple processes. • Operate at root, user, and unprivileged levels. • Limit scope of exploit. CSC 666: Secure Software Engineering

18. Architecture of OpenSSH Monitor • Privileged • FSM that accepts requests from child for privileged actions. Unprivileged • Handles auth requests. User-privileged • Runs as user once user authenticated. CSC 666: Secure Software Engineering

19. Architecture of OpenSSH Patterns Followed • Compartmentalization • Least Privilege • Reducing the TCB Comparisons • Much more interaction btw priv/unpriv than qmail or postfix. • Very Secure FTPd (vsftpd) follows a privilege separation approach too. CSC 666: Secure Software Engineering

20. Broad classification using information organizing table Viewpoint PatternShare Template – Pattern Name Interrogative Classification Key: Hierarchical classification key Problem The problem statement of the pattern. Solution The solution provided by the pattern. Known Uses. Example implementation of the pattern. Related Patterns. Patterns that are related. Munawar Hafiz, Security Patterns and Secure Architecture, OOPSLA ‘06 Tags:Tags for identifying the pattern Source: Source Repository CSC 666: Secure Software Engineering

21. Viewpoint PatternShare Legends Interrogative Viewpoints Business Arch. – CEO – Integration Arch. – Ent. Arch. - Application Arch. – Arch. – Application Arch. Design - Application Arch. – Developer - Operational Arch. – Sys. Arch. - Interrogatives Function – Data - Network - Test - Everything - CSC 666: Secure Software Engineering

22. Application Architecture Pattern Application Arch. – Design Audit Interceptor Data Problem Classification Key: Core Security, Repudiation A security audit allows auditors to reconcile actions or events that have taken place in the application with the policies that govern those actions. The audit logs have to be checked periodically to ensure that the actions that users have taken are in accordance with the actions allowed by the user’s privileges. The most important part is to record an audit trail and making sure that the audit trail helps proper auditing of appropriate events and user actions associated. Deviations must be identified from the audit reports and corrective actions have to be taken so that the deviations do not recur, either through code fixes or policy changes. How can you make an auditing framework to easily support additions or changes to the auditing events? Solution Intercept business tier requests and responses. Create audit events based on the information in the request response pair using declarative mechanisms defined externally to the application. The declarative approach is crucial to maintainability of the application. This makes it easy to keep up with the changed corporate policies. Known Uses. Audit interceptor with a JMS store to store audit information. Source: Sun Book Tags:Audit Pattern 4 CSC 666: Secure Software Engineering

23. Application Architecture Pattern Application Arch. - Design Authenticator Function Classification Key: Perimeter Security, Spoofing Problem A malicious attacker might try to impersonate a legitimate user to have access to the user's resources. This could be even more serious if the impersonated user has a high level of privilege. How to prevent agents who are not allowed from entering the system? Solution Create a single point of access to receive the interactions of a subject and apply a protocol to verify the identity of the subject. Create a proof of identity if subject is successfully authenticated. Known Uses. Centralized authentication service in RADIUS. Related Patterns. Single Access Point, Policy Enforcement Point. Source: Wiley Book Tags:Authentication, Component Pattern 5 CSC 666: Secure Software Engineering

24. Application Architecture Pattern Application Arch. - Design Client Data Storage Data Classification Key: Core Security, Tampering Problem In a client server system, there may be necessity to store data on the client. This data storage is necessitated for load-balancing, session management, single sign on etc. The client should not have access to view the data. How can the data be protected from unauthorized access of the client? Solution Use encryption to protect the data that is stored on the client. Keep a hash value of the data to detect that the content is not tampered with. Use lightweight symmetric key to protect the data. Change the session key often to protect against guessing attacks. Known Uses. Amazon.com, Buy.com etc store encrypted cookie in the client. Related Patterns. Encrypted Storage. Tags:Client Server, Access Control Source: Kienzle et. al. Repository Pattern 10 CSC 666: Secure Software Engineering

25. Application Architecture Pattern Application Arch. – Arch. Single Access Point Function Classification Key: Perimeter Security, Information Disclosure Problem A security model is difficult to validate when there are multiple ways for entering the application. How can we secure a system from outside intrusion? Solution Set up only one way to get into the system and if necessary, create a mechanism to decide which sub-application to launch. Typically most applications use a log in screen to accomplish the single access point. Known Uses. Login window in Windows, Unix, MacOS. Related Patterns. Policy Enforcement Point, Security Session. Tags:Access Control, Policy Source: Wiley Book Pattern 78 CSC 666: Secure Software Engineering

26. Application Architecture Pattern Application Arch. – Design Small Processes Function Classification Key: Perimeter Security Problem A program memory processes can be limited by the memory used by the processes. If the processes grow unbounded, then there is a potential Denial of Service scenario. How can a program with many processes be made safe from resource exhaustion? Solution Make the processes small. Each process should perform one task. This will ensure that processes allocate limited memory. Known Uses. qmail processes are very small and they only perform the required task. Related Patterns. DoS Safety. Source: Hafiz et. al. Tags:Resource Limit, DoS. Pattern 82 CSC 666: Secure Software Engineering

27. References • Daniel J. Bernstein, "Some thoughts on security after ten years of qmail 1.0", Proceedings of the 2007 ACM workshop on Computer security architecture, 2007. • Munawar Hafiz, Ralph Johnson and Raja Afandi, "Security architecture of qmail." Proceedings of the 11th Pattern Language of Programs, PLoP 2004. • Munawar Hafiz, "Security Patterns and Secure Software Architecture," OOPSLA Tutorial 51, OOPSLA ’06, 2006. • Darrel M. Kienzle and Matthew C. Elder, "Final Technical Report: Security Patterns for Web Application Development," available at http://www.scrypt.net/~celer/securitypatterns/, 2002. • Niels Provos, Markus Friedl and Peter Honeyman, “Preventing Privilege Escalation,”12th USENIX Security Symposium, Washington, DC, August 2003. • Jermone H. Saltzer and Michael D. Schroeder, "The Protection of Information in Computer Systems," 1278-1308. Proceedings of the IEEE 63, 9 (September 1975). • Markus Schumacher at. al., Security Patterns—Integrating Security and Systems Engineering, Wiley, 2006. • Joseph Yoder and Jeffrey Barcalow, "Architectural Patterns for Enabling Application Security." Proceedings of the 4th Conference on Patterns Language of Programming (PLoP’97), 1997. CSC 666: Secure Software Engineering