1. Resilient Cyber Security and Privacy Butler Lampson Microsoft Research Cyberforum April 7, 2015

2. Security: What we know how to do nSecure something simple very well nProtect complexity by isolation and sanitization nStage security theatre What we don’t know how to do nMake something complex secure nMake something big secure nKeep something secure when it changes o “When it comes to security, a change is unlikely to be an improvement.” —Doug McIlroy nGet users to make judgments about security

3. Lots of hype nNot much hard evidence of actual harm o As opposed to scare stories and uneasiness o Ex: Scale of identity theft, losses from cybercrime nMost numbers come from interested parties o who are in business to sell you security stuff nRarely, we see business decisions backed by data o Verifying credit card transactions nMost costs are in prevention, not in harm

4. Approaches to rational security nLimited aspirations o In the real world, good security means a bank vault ▬ There’s nothing like this in most computer systems o Requires setting priorities—what’s really important nRetroactive security o React, don’t anticipate—work on actual problems o Deterrence and undo rather than prevention ▬ Deterrence needs punishment ▬ Punishment needs accountability

5. Deterrence, punishment, accountability nReal world security is retroactive, about deterrence, not about locks nOn the net, can’t find bad guys, so can’t deter them nFix? 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,... nAll trust is local 518 March 2016Lampson: Retroactive Security

6. nPartition world into two parts: o Green: More safe/accountable o Red : Less safe/unaccountable nGreen world needs professional management Limiting aspirations: Red | Green Less valuable assets My Red Computer N attacks/year on less valuable assets More valuable assets My Green Computer More valuable assets m attacks/year on more valuable assets N attacks/yr m attacks/yr (N >> m) Less trustworthy Less accountable entities More trustworthy More accountable entities

7. What about bugs? Control inputs nBugs will always subvert security o Can’t get rid of bugs in full-function systems ▬ There’s too much code, changing too fast ▬ Timeliness and functionality trump security nA bug is only dangerous if it gets tickled o So keep the bugs from getting tickled o Bugs get tickled by inputs to the program o So refuse dangerous inputs ▬ or strongly isolate or sanitize those inputs nTo control possible inputs, isolate the program o Airgap, VM, process isolation, sandbox

8. Privacy: Personal control of data nYou are empowered to control your data o Find it, limit its use, claim it o Everywhere—Across the whole internet o Anytime, not just when it’s collected o Consistently for all data handlers and devices o Remaining anonymous if you wish

9. Personal control of data: Mechanisms nIdeal: All your data is in a vault you control o I bring you a query o If you like the query, you return a result ▬ Otherwise you tell me to go away nPractical: Data has metadata tag: link to policy o Two kinds of players: ▬ Agents you choose—like an email provider Personal Agent on your device Policy Service online ▬ Data handlers, subject to regulation Anyone who handles your data and follows the rules Must fetch and obey your current policy

10. How it works NID+ is the metadata You are in control Regulator makes rules Data items:... Handler h Your agent Identity: NID data, NID+→ (3) Get policy NID→  data items (4) Claim data (2) Provide data  handler,type,NID Y/N→ (1) Set policy Policy: →Y/N... Your policy service

11. Policy nData-centric, not device or service centric o Metadata stays with the data, points to data’s policy nStandard policy is very simple o 7 ± 2 types of data: contact, location, transaction,... ▬ Can extend a type with an optional tree of subtypes o Basic policy: handler h can/can’t use data type t nOne screen shows most policies (in big type) o Templates (from 3 rd parties) + your exceptions nEncode complex policy in apps o An app is a handler that tags its output suitably

12. Conclusions nRational security o Limited aspirations ▬ Red | Green o Retroactive security ▬ React—work on actual problems ▬ Deterrence and undo over prevention nPersonal control of data o Data tagged with metadata: a link to your policy o Handlers must obey policy

13. Backup

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

15. Incentives nPerceived threat of harm, or regulation o Harm: loss of money or reputation o For vendors, customer demand, which is weak nPerception is based on past experience o not on possible futures o because too many things might go wrong o and you’ll have a different job by then nRegulation is a blunt instrument o slow, behind changing technology and threats o expensive o prone to unintended consequences. o But it can work. Ex: US state laws on PII disclosure

16. Are people irrational? No nGoals are unrealistic, ignoring: o What is technically possible o What users will actually do o Conflicting desires for ▬ security, anonymity, convenience, features nActual damage is small o Evidence of damage is weak o Hence not much customer demand nIncentives are lacking o Experience trumps imagination o Convenience trumps security o Externalites: who benefits ≠ who pays

17. What is technically possible? nSecurity requires simplicity nMost processes add complexity o SSL/TLS recently discovered bugs o EMV chip-and-PIN system o Windows printing system o SET “standard” for internet credit card transactions n“Too complex” is a judgment call o Why? No good metrics for complexity or security o So desire outruns performance

18. What will users actually do? nWhat gets the job done o Disabling or evading security in the process nWhat is easy o 2-factor auth for banking → password + device ▬ But in Norway, one time passwords for banking nWhat works everywhere o For security, that’s nothing o So “educating” users doesn’t work nWhat solves a problem they (or a friend) actually had n“If you want security, you must be prepared for inconvenience.” —Gen. Benjamin W. Chidlaw, 1954