6.033 2011 Lecture 21: Security principles

where are we in the course?
  previous lectures: know how to build reliable systems, despite failures.
  next few lectures: build systems that can deal with malicious attacks.
  security: upholding some goal despite actions by adversary.

attacks happen quite often.
  lots of personal info stolen
    [ slide: texas, info on 3.5M people was on a public server for a year ]
  phishing attacks
    [ slide: users at ORNL tricked by phishing email about benefits from HR ]
  millions of PCs are under control of some attacker: "botnet"
    [ slide: botnet ]
  stuxnet infected Iran's uranium processing facilities
    [ slide: stuxnet ]

real world vs. computer security.
  security in general not a particularly new concern.
  banks, military, legal system, etc have worried about security for ages.
  computer security has many similarities:
    want to compartmentalize (different keys for bike vs. safe deposit box).
    log and audit for compromises.
    use legal system for deterrence.
  computer security also has significant differences:
    internet makes attacks fast, cheap, and scalable.
      huge number of adversaries: bored teenagers, criminals worldwide, etc.
      adversaries are often anonymous: no strong identity on the internet.
      adversaries have lots of resources (compromised PCs in a botnet).
      attacks can often be automated: systems compromised faster than can react.
    users don't understand complexity of computers.
      e.g., misunderstand implications of important security decisions.

why is security hard?
  security is a negative goal.
    want to achieve something despite whatever adversary might do.
  positive goal: "Frans can read grades.txt".
    ask Frans to check that it works.
    easy to check if our system meets this positive goal.
  negative goal: "John cannot read grades.txt".
    ask John if he can read grades.txt?
    good to check, but not nearly enough..
    must reason about all possible ways in which John might get the data.
  how might John try to get the contents of grades.txt?
    change permissions on grades.txt to give him access.
    access disk blocks directly.
    access via web.mit.edu.
    reuse memory after Frans's text editor exits, read leftover grades.txt data.
    read a backup copy of grades.txt that Frans's editor saved.
    intercept network packets when Frans is accessing grades.txt on file server.
    send Frans a trojaned text editor that sends a copy to John.
    steal disk from file server containing grades.txt.
    get a discarded printout of grades.txt from the trash.
    call sysadmin and pretend to be Frans.
    .. when should we stop thinking of scenarios?
  hard to say that John will never get a copy of grades.txt.

we've seen negative goals already: all-or-nothing atomicity w/ crashes.
  with crashes, just had to think of where we might crash.
  much harder to consider all possible cases with an adversary.
  security is also often hard because system has many complex goals.

why can't we treat malicious attacks the same way as failures?
  one "failure" due to attack might be too many.
    disclosing grades file, launching rocket, etc.
  failures due to attack might be highly correlated.
    adversary will cause every replica to crash in the same way.
    hard to reason about failure probabilities due to attacks.

how to deal with an adversary?
  be clear about goals ("policy").
  be clear about what attacks you deal with ("threat model").

policy / goals.
  information security goals:
    privacy: limit who can read data.
    integrity: limit who can write data.
  liveness goals:
    availability: ensure service keeps operating.

threat model.
  often don't know in advance who might attack, or what they might do.
    attackers may have vastly different goals, techniques, resources, expertise.
  cannot be secure against arbitrary adversaries.
    adversary might be your hardware vendor, software vendor, administrator, ..
    need to make some plausible assumptions to make progress.
  what does a threat model look like?
    adversary controls some computers, networks (but not all).
    adversary controls some software on computers he doesn't fully control.
    adversary knows some information, such as passwords or keys (but not all).
    physical attacks?
    social engineering attacks?
    resources?  (can be hard to estimate either resources or requirements!)
  many systems compromised due to unrealistic / incomplete threat models.
    adversary is outside of the company network / firewall.
    adversary doesn't know legitimate users' passwords.
    adversary won't figure out how the system works.
  despite this, important to have a threat model.
    can reason about assumptions, evolve threat model over time.
    when a problem occurs, can figure out what exactly went wrong, re-design.
  overly-ambitious threat models not always a good thing.
    not all threats are equally important.
    much harder requirements can lead to much more complexity.
    complex systems can develop subtle security problems.

basic security model.
  [ diagram: client --> guard / wall --> resource ]
  client can issue requests to guard, which might perform them on resource.
    e.g., read grades.txt; write new version; change permissions on grades.txt.
  complete mediation: only way to access the resource is via the guard.
    simplifies security: need to consider guard / wall under threat model.
    e.g., adversary better be outside the wall, under the threat model.
  typical guard model: two functions.
    authentication: request -> principal.
      e.g., client's username, verified using password.
    authorization: (request, principal, resource) -> allow?
      e.g., consult access control list (ACL) for resource.

example systems in terms of our security model.
  Unix file system.
    resource: files, directories.
    client: process.
    requests: read, write files.
    wall / guard: U/K bit / system call function.
    principal: user ID.
    authentication: OS kernel keeps track of user ID for each process.
    authorization: permission bits & owner uid in each file's inode.
  typical web server running on Unix.
    resource: wiki pages.
    client: any computer that speaks HTTP.
    requests: read/write wiki pages.
    wall / guard: server stores data on local disk, accepts only HTTP reqs.
    principal: username.
    authentication: password.
    authorization: list of usernames that can read/write each wiki page.
  firewall.
    resource: internal servers.
    client: any computer sending packets.
    requests: packets.
    wall: internal network must not be connected to internet in other ways.
	  no open wifi access points on internal network for adversary to use.
	  no internal computers that might be under control of adversary.
    guard: firewall checks packets.
    principal, authentication: none.
    authorization: check for IP address & port in table of allowed connections.
  multiple instances of model typically present in any system.
    layering: Unix fs, web server, firewall, ..

model seems straightforward: what goes wrong?

software bugs.
  common estimate: one bug per 1,000 lines of code.
  adversary tricks code inside the wall to do something unintended.
  demo: SQL injection attack.
    http://localhost/cgi-bin/lookup.cgi
    lookup alice, ben, susan
    susan' OR username='
  in recitation tomorrow, will look at more bugs.

complete mediation.
  all ways to access resource must be checked by guard.
  requires thorough design.
  [ 3 slides: paymaxx ]

policy vs. mechanism.
  high-level policy is (ideally) concise and clear.
  security mechanisms (e.g., guards) often provide lower-level guarantees.
  e.g., policy is that students cannot get a copy of grades.txt.
    what should the permissions on the files be?
    what should the firewall rules be?

interactions between layers.
  [ 3 slides: symlink problem ]

general principle: least privilege.
  break system into components.
  give each component the least privileges needed to do its job.
  example of a bad design:
    shopping web site performs product searches, takes orders.
    store all product information, orders in the same database.
    bug in search software (e.g., SQL injection) can expose credit card #s.
    security jargon: all software is "trusted" w.r.t. credit card #s.
      trusted is bad: you're screwed if trusted component breaks.
  better design:
    two servers, perform orders and product search on separate machines.
    if no interactions between servers, product search cannot obtain cc#s.
    security jargon: reduced the "trusted computing base" (TCB).
      search software is now "untrusted".

summary:
  security is a negative goal:
    want to ensure certain kinds of outcomes despite any actions by adversary.
  goals: privacy, integrity, liveness, ..
  threat model: assumptions about what adversary can do.
  guard model: perform authentication, authorization.