1. Schneider Symposium on Trustworthiness
Retroactive Security
Schneider Symposium on Trustworthiness
Butler Lampson
Microsoft Research
December 5, 2013

2. Lampson: Retroactive Security
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
14 September 2018
Lampson: Retroactive Security

3. Lampson: Retroactive Security
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: 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
14 September 2018
Lampson: Retroactive Security

4. Host (CLR, kernel, hardware, VMM, ...)
Access Control
Isolation boundary limits attacks to channels (no bugs)
Access Control for channel traffic
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 September 2018
Lampson: Retroactive Security

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
14 September 2018
Lampson: Retroactive Security

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
14 September 2018
Lampson: Retroactive Security

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 culprits
Mine the record for unusual behavior, esp. overrides
Needs authentication, and admin-friendly audit log
14 September 2018
Lampson: Retroactive Security

8. What About Integrity? Selective Undo
A better form of “reinstall &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 often does
Sometimes it needs user advice to resolve conflicts
Kaashoek, Zeldovich et al
14 September 2018
Lampson: Retroactive Security

9. What About Secrecy? Undo Publication
How to stop the Internet from remembering forever
When you post something, tag it as yours
Well-behaved apps and services 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
14 September 2018
Lampson: Retroactive Security

10. Lampson: Retroactive Security
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
14 September 2018
Lampson: Retroactive Security

11. 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
14 September 2018
Lampson: Retroactive Security

12. 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
14 September 2018
Lampson: Retroactive Security

13. 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, Drawbridge, process isolation, runtime or browser sandbox
14 September 2018
Lampson: Retroactive Security

14. Stopping Dangerous Inputs: Accountability
Inputs from accountable senders are safer
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
14 September 2018
Lampson: Retroactive Security

15. Lampson: Retroactive Security
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
14 September 2018
Lampson: Retroactive Security

16. What About Freedom? Red/Green
Partition world into two parts:
Green: More safe/accountable
Red : Less safe/unaccountable
Green world needs professional management
Red-Green is our name for the creation of two different environments for each user in which to do their computing. One environment is carefully managed to keep out attacks – code and data are only allowed if of known trusted origin – because we know that the implementation will have flaws and that ordinary users trust things that they shouldn’t. This is the “Green” environment; important data is kept in it. But because lots of work, and lots of entertainment, requires accessing things on the Internet about which little is known, or is even feasible to know, regarding their trustworthiness (so it can not be carefully managed), we need to provide an environment in which this can be done – this is the “Red” environment. The Green environment backs up both environments, and when some bug or user error causes the Red environment to become corrupt, it is restored to a previous state (see the recovery slide); this may entail loss of data, which is why important data is kept on the Green side, where it is less likely to be lost. Isolation between the two environments is enforced using IPsec.
The big unknown is the user experience, at this point. We know different models:
The KVM switch model (as in NetTop)
The X-Windows model (with windows actually fronting for an execution on some other machine)
What the users will find preferable is an open question, still.
More to the point, the security of the system depends on separation that will be visible to the user. There will be things that the user will not be allowed to do because of the security policy. What also needs to be researched is the best way to communicate that separation to the user. The KVM switch model, in which the user envisions two separate PCs that have to use network shares to share files might be the simplest to grasp.
Implementation is still a matter of debate within the company – and even within the team.
Today we are going to talk about the VM-based isolation solution
Less
valuable
assets
My Red Computer
N attacks/year on less
valuable assets
More
My Green Computer
m attacks/year on more
N attacks/yr
m attacks/yr
(N >> m)
Less trustworthy
Less accountable
entities
More trustworthy
More accountable
14 September 2018
Lampson: Retroactive Security

17. Lampson: Retroactive Security
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
14 September 2018
Lampson: Retroactive Security

18. Lampson: Retroactive Security
Data Transfer
Mediates data transfer between machines
Drag / drop, Cut / paste, Shared folders
Problems
Red → Green : Malware entering
Green → Red : Information leaking
Possible policy
Allowed transfers (configurable). Examples:
No transfer of “.exe” from R to G
Only transfer ASCII text from R to G
Non-spoofable user intent; warning dialogs
Auditing
Synchronous virus checker; third party hooks, ...
Downloaded content through IE, Messenger, p2p, etc should be tagged with download source information – similar to IE zones.  As the content moves through the “airlock”, the tags should move as well.
Auditing – sync virus checker.  Mention the attachment execution services (AES) check
14 September 2018
Lampson: Retroactive Security

19. Lampson: Retroactive Security
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
14 September 2018
Lampson: Retroactive Security