Secure Design

1. Secure Design James Walden Northern Kentucky University

2. Topics • Design Principles • Design By Contract • Legacy Issues CSC 666: Secure Software Engineering

3. Meta Principles • Simplicity • Fewer components and cases to fail. • Fewer lines of code. • Fewer possible inconsistencies. • Easy to understand. • Restriction • Minimize access. • Inhibit communication. CSC 666: Secure Software Engineering

4. Security Design Principles • Least Privilege • Fail-Safe Defaults • Economy of Mechanism • Complete Mediation • Open Design • Separation of Privilege • Least Common Mechanism • Psychological Acceptability CSC 666: Secure Software Engineering

5. Least Privilege • A user or program should be given only the privileges necessary to do its work. • Function, not identity, controls. • Applies to users, systems, and subsystems. • Rights added as needed, discarded after use. • Most common violation: • Running as administrator or root. • Use runas or sudo instead. CSC 666: Secure Software Engineering

6. Least Privilege Example • Problem: A web server. • Serves files under /var/www/html. • Logs connections under /var/www/log. • HTTP uses port 80 by default. • Only root can open ports < 1024. • Solution: • Web server runs as root user. • How does this solution violate the Principle of Least Privilege and how could we fix it? CSC 666: Secure Software Engineering

7. How do we run with least privilege? • List required resources and special tasks • Files • Network connections • Change user account • Backup data • Determine access needed to resources • Access Control Matrix • Do you need create, read, write, append, &c? CSC 666: Secure Software Engineering

8. Fail-Safe Defaults • Default action is to deny access. • When an action fails, system must be restored to a state as secure as the state it was in when it started the action. CSC 666: Secure Software Engineering

9. Fail Safe Defaults Example • Problem: Retail credit card transaction. • Card looked up in vendor database to check for stolen cards or suspicious transaction pattern. • What happens if system cannot contact vendor? • Solution • No authentication, but transaction is logged. • How does this system violate the Principle of Fail-Safe Defaults? CSC 666: Secure Software Engineering

10. Fail Safe Defaults Example • Problem: MS Office Macro Viruses. • MS office files can contain Visual Basic code (macros.) • MS Office automatically executes certain macros when opening a MS Office file. • Users can turn off automatic execution. • Don’t mix code and data! • Solution • MS Office XP has automatic execution of macros turned off by default. • While the solution is a fail-safe default, does it follow least privilege too? CSC 666: Secure Software Engineering

11. Economy of Mechanism • Keep system as simple as possible. • Use the simplest solution that works. • Fewer cases and components to fail. • Can review all code of a small application. • Reuse known secure solutions • i.e., don’t write your own cryptography. CSC 666: Secure Software Engineering

12. Economy of Mechanism Example • Problem: SMB File Sharing Protocol. • Used since late 1980s. • Newer protocol version protects data integrity by employing packet signing technique. • What do you do about computers with older versions of protocol? • Solution: • Let client negotiate SMB version to use. • How does this solution violate economy of mechanism? CSC 666: Secure Software Engineering

13. Complete Mediation • Check every access. • Usually checked once, on first access: • UNIX: File ACL checked on open(), but not on subsequent accesses to file. • If permissions change after initial access, unauthorized access may be permitted. • bad example: DNS cache poisoning CSC 666: Secure Software Engineering

14. Open Design • Security should not depend on secrecy of design or implementation. • i.e. Don’t rely on “Security through obscurity” • Makes expert public scrutiny possible. • Still need to keep keys and passwords secret. • Cannot maintain secrecy of clients • Customers can reverse engineer hardware and software with decompilers, disassemblers, logic analyzers, etc. CSC 666: Secure Software Engineering

15. Open Design Example: Problem: MPAA wants control over DVDs. • Region coding, unskippable commercials. Solution: CSS (Content Scrambling System) • CSS algorithm kept secret. • DVD Players need player key to decrypt disk key on DVD to descript movie for playing. • Encryption uses 40-bit keys. • People withoutkeys can copy but not play DVDs. Result:CSS algorithm reverse engineered. • Weakness allows disk key to be recovered in an attack of complexity 225, which takes only a few seconds.

16. Open Source • Linus’ Law: Given enough eyeballs, all bugs are shallow. • Not so effective for security • More incentives to add features than security. • Few people have skills to find security holes. • Can sell vulnerability discoveries for high prices. • Having source eliminates a small barrier to entry for crackers. CSC 666: Secure Software Engineering

17. Separation of Privilege Require multiple conditions to grant access. • Separation of duty. • Compartmentalization. • Defence in depth. CSC 666: Secure Software Engineering

18. Separation of Duty • Functions are divided so that one entity does not have control over all parts of a transaction. • Example: • Different persons must initiate a purchase and authorize a purchase. • Two different people may be required to arm and fire a nuclear missile. CSC 666: Secure Software Engineering

19. Compartmentalization • Problem: A security violation in one process should not affect others. • Solution: Virtual Memory • Each process gets its own address space. • In what ways is this solution flawed? • i.e., how can the compartments communicate? • How could we improve compartmentalization of processes? CSC 666: Secure Software Engineering

20. Defence in Depth • Diverse defensive strategies • Different types of defences. • Protection • Detection • Reaction • Different implementations of defences. • If one layer pierced, next layer may stop. • Avoid “crunchy on the outside, chewy on the inside” network security. • Contradicts “Economy of Mechanism” • Think hard about more than 2 layers. CSC 666: Secure Software Engineering

21. Defence in Depth Example • Problem: Bank. • How to secure the money? • Solution: Defence in depth. • Guards inside bank. • Closed-circuit cameras monitor activity. • Tellers do not have access to vault. • Vault has multiple defences: • Time-release. • Walls and lock complexity. • Multiple compartments. CSC 666: Secure Software Engineering

22. Least Common Mechanism • Mechanisms used to access resources should not be shared. • Information can flow along shared channels. • Examples • Shared directories like /tmp • Shared memory like CPU caches, TLB • Tradeoffs • Contradicts Economy of Mechanism CSC 666: Secure Software Engineering

23. Least Common Mechanism • Problem: • Compromising web server allows attacker access to entire machine that the web server runs on. • Solution • Run web server as non-root user. • Attacker still gains “other” access to filesystem. • Attacker may be able to elevate privilege. • Better solution • Run web server in a container or VM. • Web server compromise only impacts VM. CSC 666: Secure Software Engineering

24. Psychological Acceptability Security mechanisms should not add to the difficulty of accessing a resource. • Hide complexity introduced by security mechanisms. • Ease of installation, configuration, and use. • Human factors critical here. CSC 666: Secure Software Engineering

25. Psychological Acceptability • Users will not read documentation. • Make system secure in default configuration. • Users will not read dialog boxes. • Don’t offer complex choices. • example: Mozilla/IE certificate dialogs. • Privacy vs Usability • example: one-click shopping CSC 666: Secure Software Engineering

26. Acceptability Example • Problem: Your workstation is myws, but you log into green every day to do other tasks and don’t want to type your password. • Solution: Let green trust myws. • Create ~/.rhosts file on green that lists myws as trusted host, then rlogin green will allow access without a password. • Does this solution violate other principles? • Is there a more secure alternative solution? CSC 666: Secure Software Engineering

27. Sendmail 8 Architecture Local Mail Running as root Running as root Sendmail MDA SMTP Mail Mail Queue Mail Box CSC 666: Secure Software Engineering

28. What principles are found in qmail? CSC 666: Secure Software Engineering

29. Design Principles Questions • Many systems disable an account after a small number of failed accesses. Which principle(s) does this follow? Violate? • A system that invokes a shell exposes itself to command injection attacks. What principle does that violate? How could Least Privilege be used to improve security? • When changing your password, you typically have to enter your old password despite being logged in? How does this make the system more secure? Which principle(s) does it follow? • Least Privilege • Fail-Safe Defaults • Economy of Mechanism • Complete Mediation • Open Design • Separation of Privilege • Least Common Mechanism • Psychological Acceptability CSC 666: Secure Software Engineering

30. Design By Contract Executable contract btw class and clients. • Client must guarantee certain preconditions before it calls a method. • Class guarantees certain properties will hold after the call. Applications • Static analysis to check contracts. • Dynamic analysis to check at runtime. • Design technique, similar to TDD. • Documentation. CSC 666: Secure Software Engineering

31. Design by Contract (Eiffel) put (x: ELEMENT; key: STRING)is -- Insert x so that it will be retrievable through key. require count <= capacity not key.empty do ... Some insertion algorithm ... ensure has (x) item (key) = x count = old count + 1 end CSC 666: Secure Software Engineering

32. Contract Features Contract • Preconditions (require) • Invariants (invariant 0 <= count) • Postconditions (ensure) Contracts in other languages • assert() in C/C++ • Class::Contract in perl • Java Modeling Language (JML) CSC 666: Secure Software Engineering

33. JML Example /*@ requires a != null @ && (\forall int i; @ 0 < i && i < a.length; @ a[i-1] <= a[i]); @*/ int binarySearch(int[] a, int x) { // ... } CSC 666: Secure Software Engineering

34. Legacy Issues • How can you design security into legacy applications without source code? • Wrappers • Interposition • What is the best way to fix security flaws in an existing application? • Code Maintenance Techniques CSC 666: Secure Software Engineering

35. Retrofitting: Wrappers • Move existing application to special location. • Replace old application with wrapper that: • Performs access control check. • Performs input checks. • Secures environment. • Logs invocation of application. • Invokes legacy application from new location. • Example: AusCERT overflow_wrapper • http://www.auscert.org.au/render.html?it=2016 CSC 666: Secure Software Engineering

36. Retrofitting: Interposition • Interpose software between two programs we cannot control. • Add access control. • Filter communication. • Example: Network proxy • Router blocks direct client/server comm. • Client talks to proxy, who makes connection to remote server on behalf of client. • Access Control: disallow certain clients/servers. • Filtering: scan for viruses, worms, etc. • Auditing: all connections can be logged. CSC 666: Secure Software Engineering

37. Maintenance: Sun tar flaw • 1993: Every tar file produced under Solaris 2.0 contained fragments of /etc/passwd file. • Tar reads and writes fixed size blocks. • Last block written has contents of memory block that were not overwritten by disk read. • Tar reads /etc/passwd to obtain user info. • Immediately before it allocates the block read buffer. • Heap allocation doesn’t zero out memory. • In earlier versions, other memory allocations were between reading passwd and block read alloc. CSC 666: Secure Software Engineering

38. Legacy Issues: Maintenance • How can you avoid adding new security flaws when performing code maintenance? • Before looking at a code maintenance procedure, what design principles could have prevented the Sun tar flaw? CSC 666: Secure Software Engineering

39. Legacy Issues: Maintenance • Understand security model and mechanisms already in place. • Learn how the program actually works. Read design docs, code, and profile the program. • When designing and coding the fix: • Don’t violate the spirit of the design. • Don’t introduce new trust relationships. CSC 666: Secure Software Engineering

40. References • Matt Bishop, Computer Security: Art and Science, Addison-Wesley, 2004. • Mark Graff and Kenneth van Wyk, Secure Coding: Principles & Practices, O’Reilly, 2003. • Gary McGraw, Software Security, Addison-Wesley, 2006. • Gary T. Leavens and Yoonsik Cheon, Design by Contract with JML, http://www.jmlspecs.org/jmldbc.pdf • Bertrand Meyer, Building bug-free O-O software: An introduction to Design by Contract, http://archive.eiffel.com/doc/manuals/technology/contract/ • Jermone H. Saltzer and Michael D. Schroeder, "The Protection of Information in Computer Systems," 1278-1308. Proceedings of the IEEE 63, 9 (September 1975). • John Viega and Gary McGraw, Building Secure Software, Addison-Wesley, 2002. CSC 666: Secure Software Engineering