CSC 482582 Computer Security Secure Design Principles CSC
- Slides: 38
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. 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 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 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 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 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. �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 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 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 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 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 /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 �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 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 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 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 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 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. �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 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 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 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: 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? �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 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: 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) �Defence in depth CSC 482/582: Computer Security Slide #27
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 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 � 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 �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 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 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: �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. �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 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. 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 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
- Private securty
- Csc secure browser
- Computer security principles and practice
- Computer security principles and practice solutions
- Computer security principles and practice 4th edition
- Principles of computer security
- Computer security principles and practice
- Fail-safe defaults example
- Firewall design principles in network security
- Secure socket layer and transport layer security
- Secure socket layer and transport layer security
- Secure socket layer and transport layer security
- Secure socket layer and transport layer security
- Secure architecture principles isolation and less
- Secure coding principles and practices
- Secure coding principles and practices
- Least privilege security design principle
- Computer clusters for scalable parallel computing
- System design input and output
- Flowchart for memory reference instructions
- Elements and principles of interior design ppt
- Local area network design
- Secure design patterns
- Secure design patterns
- Design and implementation of e secure transaction
- Ncsu csc senior design
- Osi security architecture
- Guide to network security
- Wireless security in cryptography
- Visa international security model in information security
- Electronic mail security in network security
- Cnss model
- E commerce security policy
- Software security touchpoints
- Security guide to network security fundamentals
- Security guide to network security fundamentals
- Sdlc principles and practices
- Failure of supporting utilities and structural collapse
- Nist sp 800-55