Design Principles for Security Principles Protection Mechanisms • Least privilege Security is a system requirement just like • Economy of mechanism performance, capability, cost, etc. • Complete mediation • Open design Therefore, it may be necessary to trade off • Separation of privilege certain security requirements to gain others • Least common mechanism • Psychological acceptability • Fail-safe defaults Saltzer and Schroeder 1975 Security Principles CS177 2012 Security Principles CS177 2012 1 2

Least Privilege Economy of Mechanism

• Should only have the rights necessary to • Sufficiently small and simple as to be complete your task. verified and implemented • Default should be lack of access – e.g., security kernel • Simpler means less can go wrong • If access needed temporarily, then it should – And when errors occur, they are easier to be rescinded right after use understand and fix

Security Principles CS177 2012 Security Principles CS177 2012 3 4

Economy of Mechanism (2) Complete Mediation

• Complex mechanisms may not be correctly: • Every access to every object must be checked – Understood – Modeled • Must be efficient – Configured • In addition to normal runtime, must be done – Implemented at: – Used – initialization • Keep it as simple as possible – shutdown – KISS Principle – restart

Security Principles CS177 2012 Security Principles CS177 2012 5 6 Open Design Diebold Voting Machines Inspection of the code by John Hopkins team • Don’t depend on secrecy of the design found – Passwords embedded in the source code • “Security through obscurity” is a bad idea – Unauthorized privilege escalation and other vulnerabilities • Should be open for scrutiny by the – Incorrect use of cryptography community – Undetected, unlimited votes by voters • Better to have a friend/colleague find an – Insider threats - company workers or election error than a foe officials can alter voters' ballot choices without their knowledge

Security Principles CS177 2012 Security Principles CS177 2012 7 8

Separation of Privilege Least Common Mechanism

• Access to objects should depend on more • Minimize the amount of mechanism than one condition being satisfied common to more than one user and – Separation of duty depended on by all users – Two person rule • Every shared mechanism is a potential information path

Security Principles CS177 2012 Security Principles CS177 2012 9 10

Psychological Acceptability Fail-Safe Defaults

• User interface must be easy to use, so that • The default is lack of access users routinely and automatically apply the • Need to argue why a user should have mechanisms correctly. Otherwise, they will access. Do not argue why a user should not be bypassed have access • Security mechanisms should not add to • If action fails, system as secure as when difficulty of accessing resource action began

Security Principles CS177 2012 Security Principles CS177 2012 11 12 Principles for a Secure Design To Make Security Friendly

• Design security in from the start • Security should not impact users who obey • Allow for future security enhancements the rules • Minimize and isolate security controls • It should be easy for users to give access • Employ least privilege • It should be easy for users to restrict access • Structure the security relevant features • Established defaults should be reasonable • Make security friendly • Don’t depend on secrecy for security Morrie Gasser 1988 Security Principles CS177 2012 Security Principles CS177 2012 13 14

Principles for Software Security Secure the Weakest Link • Secure the weakest link • Practice defense in depth • A software security system is only as strong • Fail securely as its weakest link • Follow the principle of least privilege • Compartmentalize • Attackers go after the easy targets • Keep it simple – they will go after endpoints rather than trying to • Promote privacy crack encryption • Remember that hiding secrets is hard – they will attempt to crack an application visible • Be reluctant to trust through the firewall rather than firewall itself • Use your community resources • Identify and strengthen weak links until an Viega and McGraw 2001 acceptable level of risk is achieved Security Principles CS177 2012 Security Principles CS177 2012 15 16

Practice Defense in Depth Fail Securely

• Use diverse defensive strategies • If your software has to fail, make sure it • If one layer turns out to be inadequate, does it securely another layer will hopefully prevent a complete compromise – firewall to protect subnet, but sensitive information on the subnet is encrypted • DoD Eligible Receiver experience 1997

Security Principles CS177 2012 Security Principles CS177 2012 17 18 Follow the Principle of Least Privilege Compartmentalize

• Only the minimum amount of access • Basic access building block is not all or necessary to perform an operation should be nothing granted, and that access should be granted • Minimize the amount of damage that can be only for the minimum amount of time done by breaking the system into units necessary • Very few operating systems do this because it is difficult to manage • Root privilege is an example of how not to do it Security Principles CS177 2012 Security Principles CS177 2012 19 20

Keep it Simple Promote Privacy

• Complex design is never easy to understand • Try not to do anything that compromises the privacy of the user • Often trades off against usability – System should forget credit card numbers – Users hate having to type it in each time • Should extend to systems and code – No reason to give out any more information than necessary (e.g., os name and version)

Security Principles CS177 2012 Security Principles CS177 2012 21 22

Remember that Hiding Secrets is Hard Be Reluctant to Trust • Instead of making assumptions that need to • Skilled youth can circumvent any protection hold true, you should be reluctant to extend that a company tries to hardcode into their trust software (e.g., DVD viewers) • How can any COTS component be trusted • Binaries can be reverse engineered to be secure? • Just because a particular security feature is an emerging standard doesn’t mean it actually makes sense • Sometimes it is prudent not to trust yourself Security Principles CS177 2012 Security Principles CS177 2012 23 24 Use Your Community Resources

• Repeated use without failure promotes trust • Public scrutiny promotes trust

Security Principles CS177 2012 25