CSC 482582 Computer Security Secure Design Principles CSC

  • Slides: 38
Download presentation
CSC 482/582: Computer Security Secure Design Principles CSC 482/582: Computer Security Slide #1

CSC 482/582: Computer Security Secure Design Principles CSC 482/582: Computer Security Slide #1

Topics 1. Categories of Security Flaws Architecture/Design 2. Implementation 3. Operational 1. 2. 3.

Topics 1. Categories of Security Flaws Architecture/Design 2. Implementation 3. Operational 1. 2. 3. 4. 5. Software Security: More than Just Coding Secure Design Principles Design Issues in Legacy Code Case Study: Sendmail vs. Postfix CSC 482/582: Computer Security Slide #2

Categories of Security Flaws 1. 2. 3. Architectural/design-level flaws: security issues that original design

Categories of Security Flaws 1. 2. 3. Architectural/design-level flaws: security issues that original design did not consider or solve correctly. Implementation flaws: errors made in coding the design. Operational flaws: problems arising from how software is installed or configured. CSC 482/582: Computer Security Slide #3

Architecture/Design Flaws Race Condition �Application checks access control, then accesses a file as two

Architecture/Design Flaws Race Condition �Application checks access control, then accesses a file as two separate steps, permitting an attacker to race program and substitute the accessible file for one that’s not allowed. Replay Attack �If an attacker can record a transaction between a client and server at one time, then replay part of the conversation without the application detecting it, a replay attack is possible. Sniffing �Since only authorized users could directly access network in original Internet, protocols like telnet send passwords in the clear. CSC 482/582: Computer Security Slide #4

Implementation Flaws Buffer overflow �Application with fixed-size buffer accepts unlimited length input, writing data

Implementation Flaws Buffer overflow �Application with fixed-size buffer accepts unlimited length input, writing data into memory beyond buffer in languages w/o bounds checking like C/C++. Input validation �Application doesn’t check that input has valid format, such as not checking for “. . /” sequences in pathnames, allowing attackers to traverse up the directory tree to access any file. Back door �Programmer writes special code to bypass access control system, often for debugging or maintenance purposes. CSC 482/582: Computer Security Slide #5

Operational Flaws Denial of service �System does not have enough resources or ability to

Operational Flaws Denial of service �System does not have enough resources or ability to monitor resources to sustain availability under large number of requests. Default accounts �Default username/password pairs allow access to anyone who knows default configuration. Password cracking �Poor passwords can be guessed by software using dictionaries and permutation algorithms. CSC 482/582: Computer Security Slide #6

How can design securely? What about using checklists? �Learn from our and others’ mistakes.

How can design securely? What about using checklists? �Learn from our and others’ mistakes. �Avoid known errors: buffer overflow, code injection, race conditions, etc. �Too many known problems. �What about unknown problems? CSC 482/582: Computer Security Slide #7

How can design securely? Think about security from the beginning. �Evaluate threats and risks

How can design securely? Think about security from the beginning. �Evaluate threats and risks in requirements. �Once we understand our threat model, then we can begin designing an appropriate solution. Apply Secure Design Principles �Guidelines for security design. �Not a guarantee of security. �Tradeoffs between different principles CSC 482/582: Computer Security Slide #8

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 482/582: Computer Security Slide #9

Meta Principles Simplicity (Minimization) �Fewer components and cases to fail. �Fewer possible inconsistencies. �Easy

Meta Principles Simplicity (Minimization) �Fewer components and cases to fail. �Fewer possible inconsistencies. �Easy to understand. Restriction (Isolation) �Minimize access. �Inhibit communication. CSC 482/582: Computer Security Slide #10

Least Privilege A subject should be given only those privileges necessary to complete its

Least Privilege A subject should be given only those privileges necessary to complete its task. �Function, not identity, controls. �Rights added as needed, discarded after use. �Minimal protection domain. Most common violation: �Running as administrator or root. �Use runas or sudo instead. CSC 482/582: Computer Security Slide #11

Least Privilege Example Problem: A web server. �Serves files under /usr/local/http. �Logs connections under

Least Privilege Example Problem: A web server. �Serves files under /usr/local/http. �Logs connections under /usr/local/http/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 482/582: Computer Security Slide #12

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

How do we run with least privilege? List required resources and special tasks �Files �Network connections �Change user account �Backup data Determine what access you need to resources �Access Control model �Do you need create, read, write, append, etc. ? CSC 482/582: Computer Security Slide #13

Fail-Safe Defaults �Default action is to deny access. �When an action fails, system must

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 482/582: Computer Security Slide #14

Fail Safe Defaults Example Problem: Retail credit card transaction. �Card looked up in vendor

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 482/582: Computer Security Slide #15

Fail Safe Defaults Example Problem: Steam Do. S attack, Christmas 2015 �To keep site

Fail Safe Defaults Example Problem: Steam Do. S attack, Christmas 2015 �To keep site attack, Steam used caching. �Caching was incorrectly configured so that authenticated pages were cached. �Some users saw cached pages from other users, revealing private account information. Solution: �Test failover configuration before deployment.

Fail Safe Defaults Example Problem: MS Office Macro Viruses. �MS office files can contain

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 482/582: Computer Security Slide #17

Economy of Mechanism Keep it as simple as possible (KISS). �Use the simplest solution

Economy of Mechanism Keep it as simple as possible (KISS). �Use the simplest solution that works. �Fewer cases and components to fail. Reuse known secure solutions �i. e. , don’t write your own cryptography. CSC 482/582: Computer Security Slide #18

Economy of Mechanism Example Problem: SMB File Sharing Protocol. �Used since late 1980 s.

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 which SMB version to use. �How does this solution violate economy of mechanism? CSC 482/582: Computer Security Slide #19

Complete Mediation �Check every access. �Usually checked once, on first access: �UNIX: File ACL

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 482/582: Computer Security Slide #20

Open Design Security should not depend on secrecy of design or implementation. �Popularly misunderstood

Open Design Security should not depend on secrecy of design or implementation. �Popularly misunderstood to mean that source code should be public. �It means avoiding “Security through obscurity” �Refers to security policy and mechanism, not simple user secrets like passwords and cryptographic keys, e. g. it follows Kerchoff’s Principle. CSC 482/582: Computer Security Slide #21

Open vs. Closed Source “Is open-source software secure? ” Open: �Some people might look

Open vs. Closed Source “Is open-source software secure? ” Open: �Some people might look at security of your application (if they care) �may or may not tell you what they find Closed: �not making code available does not hide much �need diverse security-aware code reviews A business decision: Not a security one!

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

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 w/o keys can copy but not play DVDs. What happened next? �CSS algorithm reverse engineered. �Weakness in algorithm allows disk key to be recovered in an attack of complexity 225, which takes only a few seconds. CSC 482/582: Computer Security Slide #23

Flaws in the Approach What assumptions to make about adversary? �Knows algorithms? Or not?

Flaws in the Approach What assumptions to make about adversary? �Knows algorithms? Or not? �Algorithms in “binary” secret? Attackers can probe for weaknesses �reverse engineer executables �observe behavior in normal vs. aberrant conditions (fault injection) �Fuzzing: trying random input strings to find an exploit �blackmail insiders

SWS Obscurity Distributing Java bytecode of SWS (and not source code) does not provide

SWS Obscurity Distributing Java bytecode of SWS (and not source code) does not provide security. � Tools like strings can search binary for passwords, keys, etc. � Bytecode can be decompiled (see Mocha, Jad) to produce source code, including class and public member names. � Machine code can be disassembled into assembly by tools like IDA Pro and even decompiled into rough C code. � Debuggers and reflection tools can examine a running program. Code obfuscators offer some protection �Make code harder to read by replacing readable names with meaningless ones, re-organizing code, etc. �But reverse engineers can work through any obfuscation given enough time. CSC 482/582: Computer Security Slide #25

Disassembling SWS public void process. Request(java. net. Socket); 43: throws java/lang/Exception 46: Code: 47:

Disassembling SWS public void process. Request(java. net. Socket); 43: throws java/lang/Exception 46: Code: 47: 0: new 25; //class Buffered. Reader 49: 3: dup 51: 4: new 26; //class Input. Stream. Reader 54: 7: dup 56: 8: aload_1 58: 9: invokevirtual 27; 61: 12: invokespecial 28; 63: 15: invokespecial 29; 65: 18: astore_2 68: 19: new 30; //class Output. Stream. Writer 70: 22: dup 72: 23: aload_1 74: 24: invokevirtual 31; 77: 27: invokespecial 32; 80: 30: astore_3 81: 31: aload_2 82: 32: invokevirtual 33; 84: 35: astore 4 87: 99: astore 8 37: aconst_null 90: 101: aload_3 38: astore 5 91: 102: invokevirtual 44; 93: 40: aconst_null 105: return 41: astore 6 96: new 34; //class String. Tokenizer dup aload 4 ldc 35; //String invokespecial 36; astore 7 aload 7 invokevirtual 37; astore 5 aload 7 invokevirtual 37; astore 6 aload 5 ldc 38; //String GET invokevirtual 39; ifeq 90 aload_3 aload 6 invokevirtual 40; goto aload_3 ldc 41; invokevirtual 42; goto 101

Separation of Privilege Require multiple conditions to grant access. �Separation of duty �Compartmentalization (encapsulation)

Separation of Privilege Require multiple conditions to grant access. �Separation of duty �Compartmentalization (encapsulation) �Defence in depth CSC 482/582: Computer Security Slide #27

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

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 482/582: Computer Security Slide #28

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

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 482/582: Computer Security Slide #29

Defence in Depth Diverse defensive strategies �Different types of defences. � Protection � Detection

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 482/582: Computer Security Slide #30

Avoid M&M Architectures Inherently insecure system protected by another system mediating access to it

Avoid M&M Architectures Inherently insecure system protected by another system mediating access to it �Ex: Firewalls guard vulnerable systems within �Ex: Death Star “strong outer defense” but vulnerable Hard outer shell should not be sole defense

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

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 482/582: Computer Security Slide #32

Least Common Mechanisms to access resources should not be shared. �Information can flow along

Least Common Mechanisms to access resources should not be shared. �Information can flow along shared channels. �Covert channels. Contradicts Economy of Mechanism? CSC 482/582: Computer Security Slide #33

Least Common Mechanism Problem: �Compromising web server allows attacker access to entire machine. Solution:

Least Common Mechanism Problem: �Compromising web server allows attacker access to entire machine. Solution: �Run web server as non-root user. �Attacker still gains “other” access to filesystem. �Run web server in chroot jail. CSC 482/582: Computer Security Slide #34

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. �Usability: Ease of installation, configuration, and use. Hide complexity introduced by security mechanisms. �Principle of Least Astonishment: Design should match user’s experience, expectations, and mental models. Follow UI conventions.

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

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 482/582: Computer Security Slide #36

Key Points 1. Categories of Security Flaws Architecture/design 2. Implementation 3. Operational 1. 2.

Key Points 1. Categories of Security Flaws Architecture/design 2. Implementation 3. Operational 1. 2. Secure Design Principles 1. Least Privilege 2. Compartmentalization 3. Psychological Acceptability 4. … CSC 482/582: Computer Security Slide #37

References 1. Bishop, Matt, Introduction to Computer Security, Addison-Wesley, 2005. 2. Graff, Mark and

References 1. Bishop, Matt, Introduction to Computer Security, Addison-Wesley, 2005. 2. Graff, Mark and van Wyk, Kenneth, Secure Coding: Principles & Practices, O’Reilly, 2003. 3. Howard, Michael and Le. Blanc, David, Writing Secure Code, 2 nd edition, Microsoft Press, 2003. 4. Viega, John, and Mc. Graw, Gary, Building Secure Software, Addison-Wesley, 2002. 5. Wheeler, David, Secure Programming for UNIX and Linux HOWTO, http: //www. dwheeler. com/secureprograms/Secure-Programs. HOWTO/index. html, 2003. CSC 482/582: Computer Security Slide #38