Retroactive Security Singapore GYSS Butler Lampson Microsoft Research

Retroactive Security Singapore GYSS Butler Lampson Microsoft Research January 2017 September 27, 2016 Lampson: Retroactive Security 1

Why Retroactive? n Access control doesn’t work o o 40 years of experience says so Basic problem: its job is to say “No” ▬ ▬ This stops people from doing their work and then they weaken the access control usually too much, but no one notices until there’s a disaster n Retroactive security focuses on things that actually happened o rather than all the many things that might happen September 27, 2016 Lampson: Retroactive Security 2

Why Retroactive? n Real world security is retroactive o o Burglars are stopped by fear of jail, not by locks The financial system’s security depends on undo, not on vaults n Basic advantage of retroactive: work on real, not hypothetical cases n The best is the enemy of the good o o Retroactive security is not perfect But it’s better than what we have now September 27, 2016 Lampson: Retroactive Security 3

Access Control 1. Isolation boundary limits attacks to channels (no bugs) 2. Access Control for channel traffic 3. Policy management Authorization Authentication Agent / Principal Request Guard / Reference monitor Source Resource / Object Sink 1. Isolation boundary 2. Access control Policy Audit log 3. Policy Host (CLR, kernel, hardware, VMM, . . . ) September 27, 2016 Lampson: Retroactive Security 4

Aspects of Retroactive Security n What about enforcing rules? Blame and punishment o o n n Assigning blame? Auditing Imposing punishment? Accountability What about integrity? Selective undo What about secrecy? Undo publication What about bugs? Accountability and isolation What about freedom? Red/Green n Still need access control, but it’s much coarser September 27, 2016 Lampson: Retroactive Security 5

What About Punishment? Accountability n Real world security is about deterrence, not locks n On the net, can’t find bad guys, so can’t deter them n Fix? End nodes enforce accountability o Refuse messages that aren’t accountable enough ▬ or strongly isolate those messages o Senders are accountable if you can punish them ▬ With dollars, ostracism, firing, jail, . . . n All trust is local September 27, 2016 Lampson: Retroactive Security 6

What About Blame? Auditing n Use access control just to keep out people you can’t punish o End nodes enforce accountability n Otherwise o o o Make common sense rules Let people override the machine’s enforcement Log all accesses: who and what For problems you notice, use the log to find the culprits Mine the record for unusual behavior, especially overrides n Needs authentication, and an admin-friendly audit log September 27, 2016 Lampson: Retroactive Security 7

What About Integrity? Selective Undo n A better form of “reinstall and reload from backup” n Log all state changes, their inputs and their outputs n To fix a corrupted system: o o o Reset the system to an old good state Install patches and block known intrusions Replay the logged actions (except the blocked ones) ▬ Unchanged actions with unchanged inputs don’t need replay n This doesn’t always work, but it works remarkably often o Sometimes it needs user advice to resolve conflicts n Kaashoek, Zeldovich et al September 27, 2016 Lampson: Retroactive Security 8

What About Secrecy? Undo Publication n How to stop the Internet from remembering forever o o When you post something, tag it as yours with an ownership tag Well-behaved apps and services will respect the tags. ▬ ▬ o Carry the tag along with the data Consult the current policy for the tag To take something back, change the policy n Enforcement by social norms or regulation o Works for Google, Facebook, MS Office, etc. ▬ Of course doesn’t work for everything September 27, 2016 Lampson: Retroactive Security 9

Ownership Tags n Enough information to find the current policy o o o URL or search query for source of policy HTTP request to retrieve policy Public signing key to authenticate policy n Current policy? o o Cache retrieved policy Check for changes—perhaps once per day or once per week n Need the tag to last for decades September 27, 2016 Lampson: Retroactive Security 10

Who Controls What Your agent Identity: NID (2) Provide data NID+, data→ (4) Claim data NID→ Numeric IDs (NIDs) are public keys NID+ is the tag data items (1) Set policy Your policy service Policy: <type, handler>→Y/N. . . (3) Get policy h, NID, type Y/N→ You are in control September 27, 2016 Handler h Data items: <NID+, type, bytes>. . . Regulator makes rules Lampson: Retroactive Security 11

Ownership for Medical Data n Same idea: tag data with patient identity n Patient controls use of data o o Who gets to see it How it can be used in research n Question: Can you take data back even after it’s been used? n See PITAC report on Health IT September 27, 2016 Lampson: Retroactive Security 12

From Ownership To Provenance n Provenance: How this data came into being o o Input, with owner(s) Computed, by f(x 1, x 2, . . . ) n Trace the chain of responsibility / ownership n Recompute when inputs or program change n Problems: o o o Cost Process Non-determinism September 27, 2016 Lampson: Retroactive Security 13

What About Bugs? Control Inputs n Bugs will always subvert access control o Can’t get rid of bugs in full-function systems ▬ ▬ There’s too much code, changing too fast Timeliness and functionality are more important than security n A bug is only dangerous if it gets tickled o o o So keep the bugs from getting tickled Bugs get tickled by inputs to the program So refuse dangerous inputs ▬ o or strongly isolate those inputs To control possible inputs, isolate the program ▬ VM, containers, process isolation, runtime or browser sandbox September 27, 2016 Lampson: Retroactive Security 14

Stopping Dangerous Inputs: Accountability n Inputs from accountable senders aren’t dangerous o Senders are accountable if you can punish them ▬ o With dollars, ostracism, firing, jail, . . . Accountability deters senders from tickling bugs n Bad guys are not accountable n So keep bad guys from tickling the bugs o Refuse inputs that aren’t accountable enough ▬ or strongly isolate those inputs n End nodes enforce accountability n Need all the machinery of authentication and isolation o But coarse grained September 27, 2016 Lampson: Retroactive Security 15

What About Compromise? n Stuff happens, so good guys can be compromised o o Though less likely with accountability Need careful management of accountable machines n Second line of defense: Sanitizing o o o For each data type, define a safe subset A sanitizer forces a value to be safe Only accept safe inputs September 27, 2016 Lampson: Retroactive Security 16

What About Freedom? Red/Green n Partition world into two parts: o Green: More safe/accountable o Red : Less safe/unaccountable n Green world needs professional management Less trustworthy Less accountable entities (N >> m) More trustworthy More accountable entities N attacks/yr m attacks/yr My Red Computer My Green Computer More valuable assets Less valuable assets N attacks/year on less valuable assets September 27, 2016 m attacks/year on more valuable assets Lampson: Retroactive Security 17

Why R|G? n Problems: o Any OS will always be exploitable ▬ o The richer the OS, the more bugs Need internet access to get work done, have fun ▬ The internet is full of bad guys n Solution: Isolated work environments: o o Green: important assets, only talk to good guys ▬ Don’t tickle the bugs, by restricting inputs Red: less important assets, talk to anybody ▬ Blow away broken systems n Good guys: more trustworthy / accountable o Bad guys: less trustworthy or less accountable September 27, 2016 Lampson: Retroactive Security 18

Data Transfer n Mediates data transfer between machines o Drag / drop, Cut / paste, Shared folders n Problems o o Red → Green : Malware entering Green → Red : Information leaking n Possible policy o Restrict transfers. Examples: ▬ ▬ ▬ o o o No transfer of “. exe” from R to G Only transfer ASCII text from R to G Only transfer sanitized data from R to G Require non-spoofable user intent Audit transfers Information flow control from G to R September 27, 2016 Lampson: Retroactive Security 19

Conclusions n Access control hasn’t worked. Learn from real-world experience. n Security should depend mostly on retroactive, after-the-fact response o n n Work on actual problems, not hypothetical ones For blame and punishment: auditing and accountability For integrity: selective undo For secrecy: ownership of published data and provenance For bugs: isolation, accountable inputs, and red/green September 27, 2016 Lampson: Retroactive Security 20