Security Design

1
Security Design

• Nice idea evil bit, RFC 3514
• Some of these observations due to Viega, McGraw
• Security is not a feature (now, with more
  fonts!) that you can just add on
• Its more like the feature that a program
  doesnt crash, or performs well
• Lexar JumpDrive Secure
• iChoose and 56-bit DES
• x10 XCam2 http//www.x10.com/products/x10_vk45a.ht
  m

2
Security Design

• This class focuses more on the technology than on
  the process
• Main outcome of this course you will be
  conversant in basic security building blocks
• Not a certified security integrator or anything
  like that
• Many of our examples are under specified, not
  real applications
• Once looking at real applications, responsibility
  to look at much larger picture
• The programming project/homeworks are kind of
  dangerous!
• Big problem common platforms not designed with
  security in mind, and was added on later
• UNIX
• DOS/Windows
• Arpanet protocols (sensitivity field)

3
Standards FIPS-140, TCSEC, ITSEC Common Criteria

• FIPS-140
• Requirements for U.S. government use of
  cryptography
• Not meeting FIPS-140(-2) is like working with
  plaintext
• http//csrc.nist.gov/cryptval/
• TCSEC (US military)
• "Orange book"
• TCSEC defines criteria for trusted computer
  products. There are four levels, A, B, C, and D.
  Each level adds more features and requirements
• D is a non-secure system.
• C1 requires user log-on, but allows group ID.
• C2 requires individual log-on with password and
  an audit mechanism.
• Levels B and A provide mandatory control. Access
  is based on standard Department of Defense
  clearances
• B1 requires DoD clearance levels.
• B2 guarantees the path between the user and the
  security system and provides assurances that the
  system can be tested and clearances cannot be
  downgraded.
• B3 requires that the system is characterized by a
  mathematical model that must be viable.
• A1 requires a system characterized by a
  mathematical model that can be proven.

4
Standards

• ITSEC (Europe)
• a structured set of criteria for evaluating
  computer security within products and systems.
• Each evaluation involves a detailed examination
  of IT security features culminating in
  comprehensive and informed functional and
  penetration testing.
• ITSEC operates with concept of assurance levels
  E0 to E6.
• Common Criteria effort to merge TCSEC, ITSEC
• Common vocabulary
• Protection profiles indicate requirements
• Evaluation labs compare products/practices to
  protection profiles
• http//www.cesg.gov.uk/site/iacs/index.cfm?menuSel
  ected1displayPage1
• CISSP Certified Information Systems Security
  Professionals
• Don't know much about this, but looks like a good
  way to get a job

5
Principles Bumper Stickers

• Define security goals
• Define threat model
• Brainstorm attacks
• STRIDE
• Spoofing
• Tampering
• Repudiation
• Information disclosure
• DOS
• Elevation
• (Hey, what about covert channels?)
• Rank by risk
• Figure out what to do
• Iterate

6
Secure the weakest link

• Attackers are presumably interested in fruits of
  attack, not reenacting David v. Goliath
• _at_TTY03
• Distributing secure software insecurely

7
Defense in depth

• In other words, use more than one chain
• Surveillance cameras, visible and hidden.
  Visible guards. Bulletproof glass and electronic
  locks on cash drawers. Sensors in drawers and
  dye in cash. Vaults.
• Compare "we have had some hacked computers on
  campus, so we need a firewall"

8
Fail securely

• Backwards compatibility and downgrading
• SMB, SSL 2.0
• credit card authorization
• threat model tolerates this
• Known-good rather than known-bad
• Project 1
• SafeWeb and unrecognized input

9
Use secure defaults

• Windows NULL DACLs mean access to everything in
  WinNT
• C\Documents and Settings\dm\My Documents\Writing
  Secure Code\Secureco\Chapter 4
• less restrictive is a OR of flags
• improved in W2K SDDL (sec descr def lang)
• improved in ATL
• IE6 privacy settings no P3P policy gt no 3rd
  party cookie
• No specification of server DH component in Proj 3
  gt failure rather than "any"

10
Least privilege

• Valet keys
• Listening on an SMTP connection (lt1024)
• the submit program runs as root
• needs to deliver file to instructor directory
• should only read
• Need to know
• Compartmentalize
• Access lists are much better than UID matching /
  superuser

11
Keep it simple

• Dont reinvent the wheel
• E.g., dont write your own RSA and
  Diffie-Hellman!
• See PKCS standards
• User Interface
• Users will not read the documentation
• Externalities. So what if my PC is used as a
  DDOS drone? How does that affect me?
• Common approach make user responsible for their
  computer/account use. A threat.
• Setting up for wireless with 802.1x

12
Consider privacy

• Auditing everything may be good for security and
  is bad for privacy
• Define auditing needs
• Who should be able to inspect audit log?
• Use crypto on audit log
• Dont neglect to secure debugging trail
• Be careful of data leaks
• E.g., customer numbers in Web URLs

13
Connect with security community

• Follow news
• Is that exploit going to affect me?
• Primality in P does that affect RSA?
• MD5 collisions... does that affect HMAC-MD5?
• How about authentication sessions that predated
  the break?
• Try to use existing protocols

14
Make sure the secrets can be changed

• Not security through obscurity
• Hiding secrets in public code is basically
  impossible
• DVD DeCSS
• RC2 and RC4 were trade secrets
• Don't put your server key in your code in Proj 3
• Open source vs closed source
• Yes, security through obscurity is bad
• No, open source does not guarantee better security

15
Final thoughts

• Dont trust lightly
• Don't trust the good guys unless you have to
• Who is liable if it breaks?
• Will a judge and jury be able to understand this
  system?
• No particular legal weight given to RSA versus
  plaintext signature (in U.S.)