Secure Design James Walden Northern Kentucky University Topics

  • Slides: 40
Download presentation
Secure Design James Walden Northern Kentucky University

Secure Design James Walden Northern Kentucky University

Topics 1. Design Principles 2. Design By Contract 3. Legacy Issues CSC 666: Secure

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

Meta Principles 1. Simplicity § § Fewer components and cases to fail. Fewer lines

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

Security Design Principles 1. 2. 3. 4. 5. 6. 7. 8. Least Privilege Fail-Safe

Security Design Principles 1. 2. 3. 4. 5. 6. 7. 8. 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

Least Privilege § A user or program should be given only the privileges necessary

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

Least Privilege Example § Problem: A web server. § § Serves files under /var/www/html.

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

How do we run with least privilege? § List required resources and special tasks

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

Fail-Safe Defaults § Default action is to deny access. § When an action fails,

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

Fail Safe Defaults Example § Problem: Retail credit card transaction. § Card looked up

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

Fail Safe Defaults Example § Problem: MS Office Macro Viruses. § MS office files

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

Economy of Mechanism § Keep system as simple as possible. § Use the simplest

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

Economy of Mechanism Example § Problem: SMB File Sharing Protocol. § Used since late

Economy of Mechanism Example § Problem: SMB File Sharing Protocol. § Used since late 1980 s. § 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

Complete Mediation § Check every access. § Usually checked once, on first access: §

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

Open Design § Security should not depend on secrecy of design or implementation. §

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

Open Design Example: Problem: MPAA wants control over DVDs. § Region coding, unskippable commercials.

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 without keys 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.

Open Source § Linus’ Law: Given enough eyeballs, all bugs are shallow. § Not

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

Separation of Privilege Require multiple conditions to grant access. § Separation of duty. §

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

Separation of Duty § Functions are divided so that one entity does not have

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

Compartmentalization § Problem: A security violation in one process should not affect others. §

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

Defence in Depth § Diverse defensive strategies § Different types of defences. - Protection

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

Defence in Depth Example § Problem: Bank. § How to secure the money? §

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

Least Common Mechanism § Mechanisms used to access resources should not be shared. §

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

Least Common Mechanism § Problem: § Compromising web server allows attacker access to entire

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

Psychological Acceptability Security mechanisms should not add to the difficulty of accessing a resource.

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

Psychological Acceptability § Users will not read documentation. § Make system secure in default

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

Acceptability Example § Problem: Your workstation is myws, but you log into green every

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

Sendmail 8 Architecture Local Mail Running as root Sendmail MDA Mail Queue Mail Box

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

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

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

Design Principles Questions § Many systems disable an account after a small number of

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? 1. Least Privilege 2. 3. 4. 5. 6. 7. 8. Fail-Safe Defaults Economy of Mechanism Complete Mediation Open Design Separation of Privilege Least Common Mechanism Psychological Acceptability CSC 666: Secure Software Engineering

Design By Contract Executable contract btw class and clients. § Client must guarantee certain

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

Design by Contract (Eiffel) put (x: ELEMENT; key: STRING) is -- Insert x so

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

Contract Features Contract § Preconditions (require) § Invariants (invariant 0 <= count) § Postconditions

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

JML Example /*@ requires a != null @ && (forall int i; @ 0

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

Legacy Issues § How can you design security into legacy applications without source code?

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

Retrofitting: Wrappers § Move existing application to special location. § Replace old application with

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: Aus. CERT overflow_wrapper § http: //www. auscert. org. au/render. html? it=2016 CSC 666: Secure Software Engineering

Retrofitting: Interposition § Interpose software between two programs we cannot control. § Add access

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

Maintenance: Sun tar flaw § 1993: Every tar file produced under Solaris 2. 0

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

Legacy Issues: Maintenance § How can you avoid adding new security flaws when performing

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

Legacy Issues: Maintenance 1. Understand security model and mechanisms already in place. 2. Learn

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

References 1. 2. 3. 4. 5. 6. 7. Matt Bishop, Computer Security: Art and

References 1. 2. 3. 4. 5. 6. 7. Matt Bishop, Computer Security: Art and Science, Addison. Wesley, 2004. Mark Graff and Kenneth van Wyk, Secure Coding: Principles & Practices, O’Reilly, 2003. Gary Mc. Graw, 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 Mc. Graw, Building Secure Software, Addison -Wesley, 2002. CSC 666: Secure Software Engineering