1. Secure Design Principles  secure the weakest link  reduce the attack surface  practice defense in depth  minimize privilege  compartmentalize  fail safely  keep it simple  maintain privacy  trust reluctantly  mediate completely  practice open design

2. Secure the Weakest Link Which is an attacker most likely to exploit?  encrypted data  smash the runtime stack  your company’s firewall  a naïve employee (social engineering) What does “weak” mean? Algorithm: analyze the risk; do forever { identify weakest link; mitigate weakest link; } Spend your time where it matters.

3. Reduce the Attack Surface What is an attack surface? You are put in charge of the corporate help desk. The most common task is resetting passwords. Develop a secure procedure to allow employees to reset their corporate password by phone. Example Methods to reduce an attack surface Refactoring for security

4. Practice Defense in Depth Consider the teller at your local bank What about a web server application? 

5. Minimize Privilege A student is hired to supervise the CS Department lab. How should the student be given access to the locked lab? Principle of Least Privilege List various kinds of privilege in a computer application.

6. Compartmentalize How are ocean tankers built? Separation of Privilege

7. Fail Safely  Deny by default  Close open files/ports Failure is inevitable! – Plan for it!  Drop permissions  Safe ≠ Functional  Uncaught exceptions?  Network failure?

8. Keep It Simple Example: IPSEC standards for securing TCP/IP as opposed to SSL and VPN  redundancy can improve security but adds to complexity Reuse Complex design leads to subtle vulnerabilities.  readable code improves many things …including security  more functionality = more attack surface  small is simple Ease of use 1) Remember users don’t read documentation. 2) Design for actual users, not the CEO. 3) User aren’t always right …about security. 4) Users are lazy.

9. Keep It Simple (cont’d) Chokepoint  Sometimes called a wrapper  localization of key security issues

10. Maintain Privacy Privacy is not the same as confidentiality. How do credit card companies secure card numbers? Social engineering attacks depend upon private info. How does signing code increase the attack surface? Trust Reluctantly Insider attacks are common. Ken Thompson – “Reflections on Trusting Trust”, 1984 (cm.bell-labs.com/who/ken/trust.html) Even cryptographic routines can be untrustworthy (www.interhack.net/people/cmcurtin/snake-oil-faq.html)

11. Mediate Completely Validate all input. Every access of every asset needs to be authorized. Check for out of bounds, overflow, Flush cache storage

12. Practice Open Design Example 2: NSA refused to publish their analysis of DES Example 1: early Diebold voting machines Example 3: RSA did not publish RC2 & RC4 Open design does not always imply open source. Concealing only gives a temporary sense of security Obscurity ≠ Security