Retroactive Security Approach by Butler Lampson in January 2017

Retroactive security proposed by Butler Lampson addresses the limitations of traditional access control mechanisms. Emphasizing a focus on events that have actually occurred, this approach aims to improve real-world security by enabling accountability, blame assignment, and selective undo capabilities. The strategy also highlights the importance of deterrence through accountability rather than solely relying on preventive measures like locks.

• Retroactive Security
• Access Control
• Accountability
• Real-world Security
• Butler Lampson

christner_r Follow

Uploaded on Sep 23, 2024 | 0 Views

Download Presentation

Please find below an Image/Link to download the presentation.

The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. Download presentation by click this link. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.

Presentation Transcript

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

2. Why Retroactive? Access control doesn t work 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 Retroactive security focuses on things that actually happened rather than all the many things that might happen September 27, 2016 Lampson: Retroactive Security 2

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

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

5. Aspects of Retroactive Security What about enforcing rules? Blame and punishment 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 Still need access control, but it s much coarser September 27, 2016 Lampson: Retroactive Security 5

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

7. What About Blame? Auditing Use access control just to keep out people you can t punish End nodes enforce accountability Otherwise 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 Needs authentication, and an admin-friendly audit log September 27, 2016 Lampson: Retroactive Security 7

8. What About Integrity? Selective Undo A better form of reinstall and reload from backup Log all state changes, their inputs and their outputs To fix a corrupted system: 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 This doesn t always work, but it works remarkably often Sometimes it needs user advice to resolve conflicts Kaashoek, Zeldovich et al September 27, 2016 Lampson: Retroactive Security 8

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

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

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

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

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

14. What About Bugs? Control Inputs Bugs will always subvert access control 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 A bug is only dangerous if it gets tickled So keep the bugs from getting tickled Bugs get tickled by inputs to the program So refuse dangerous inputs 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

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

16. What About Compromise? Stuff happens, so good guys can be compromised Though less likely with accountability Need careful management of accountable machines Second line of defense: Sanitizing 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

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

18. Why R|G? Problems: Any OS will always be exploitable The richer the OS, the more bugs Need internet access to get work done, have fun The internet is full of bad guys Solution: Isolated work environments: 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 Good guys: more trustworthy / accountable Bad guys: less trustworthy or less accountable September 27, 2016 Lampson: Retroactive Security 18

19. Data Transfer Mediates data transfer between machines Drag / drop, Cut / paste, Shared folders Problems Red Green : Malware entering Green Red : Information leaking Possible policy Restrict transfers. Examples: 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

20. Conclusions Access control hasn t worked. Learn from real-world experience. Security should depend mostly on retroactive, after-the-fact response 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