1
|
- Butler Lampson
- Microsoft
- September 26, 2005
|
2
|
- It’s about risk, locks, and deterrence.
- Risk management: cost of security < expected loss
- Perfect security costs way too much
- Locks good enough that bad guys break in rarely
- Bad guys get caught and punished enough to be deterred, so police /
courts must be good enough.
- Can recover from damage at an acceptable cost.
- Internet security similar, but
little accountability
- Can’t identify the bad guys, so can’t deter them
|
3
|
- Security is costly—buy only what you need
- You pay mainly in inconvenience
- If there’s no punishment, you pay a lot
- People do behave this way
- We don’t tell them this—a big mistake
- The best is the enemy of the good
- Perfect security is the worst enemy of real security
- Feasible security
- Costs less than the value it protects
- Simple enough for users to manage
- Simple enough for vendors to implement
|
4
|
- Exploitable bugs
- Bad configuration
- TCB: Everything that security depends on
- Hardware, software, and configuration
- Does formal policy say what I mean?
- Can I understand it? Can I manage it?
- Why least privilege doesn’t work
- Too complicated, can’t manage it
- The unavoidable price of reliability is simplicity
—Hoare
|
5
|
- Locks: Control the bad guys
- Coarse: Isolate—keep everybody out
- Medium: Exclude—keep the bad guys out
- Fine: Restrict—Keep them from doing damage
- Recover—Undo the damage
- Deterrence: Catch bad guys, punish them
- Auditing, police, courts or other penalties
|
6
|
|
7
|
|
8
|
- Authenticate principals: Who made a request
- Mainly people, but also channels, servers, programs
(encryption implements channels, so key is a principal)
- Authorize access: Who is trusted with a resource
- Group principals or resources, to simplify management
- Can define by a property, e.g. “type-safe”
or “safe for scripting”
- Audit: Who did what when?
- Lock = Authenticate + Authorize
- Deter = Authenticate + Audit
|
9
|
- Isolation is imperfect: Can’t get rid of bugs
- TCB = 10-50 M lines of code
- Customers want features more than correctness
- Instead, don’t tickle them.
- How? Reject bad inputs
- Code: don’t run or restrict severely
- Communication: reject or restrict severely
- Data: don’t send; don’t accept if complex
|
10
|
- Can’t identify 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
- All trust is local
- Need an ecosystem for
- Senders becoming accountable
- Receivers demanding accountability
- Third party intermediaries
- To stop DDOS attacks, ISPs must play
|
11
|
- Not being accountable enough means end nodes will reject inputs
- Application execution is restricted or prohibited
- Communication is restricted or prohibited
- Information is not shared or accepted
- Access to devices or networks is restricted or prohibited
|
12
|
- Senders must be able to make themselves accountable
- This means pledging something of value
- Friendship
- Reputation
- Money
- …
- Receivers must be able to check accountability
- Specify what is accountable enough
- Verify sender’s evidence of accountability
|
13
|
- “In principle” there is no difference
- but
- Accountability is about punishment, not locks
- Accountability is very coarse-grained
|
14
|
- Identity, reputation, and indirection services
- Mechanisms to establish trust relationships
- Person to person and person to organization
- A flexible, simple user model for identity
- Stronger user authentication
- Smart card, cell phone, biometrics
- Application identity: signing, reputation
|
15
|
- Just enough to block DDoS attacks
- Need ISPs to play. Why should they?
- Servers demand it; clients don’t get locked out
- Regulation?
- A server asks its ISP to block some IP addresses
- ISPs propagate such requests to peers or clients
- Probably must be based on IP address
- Perhaps some signing scheme to traverse unreliable intermediaries?
- High priority packets can get through
|
16
|
- Partition world into two parts:
- Green Safer/accountable
- Red Less safe/unaccountable
- Two aspects, mostly orthogonal
- User Experience
- Isolation mechanism
- Separate hardware with air gap
- VM
- Process isolation
|
17
|
|
18
|
|
19
|
|
20
|
- 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
- Good guys: more trustworthy / accountable
- Bad guys: less trustworthy or less accountable
|
21
|
- Green = locked down = only whitelist inputs
- Requires professional management
- Few users can make these decisions
- Avoid “click OK to proceed”
- To escape, use Red
- Today almost all machines are Red
|
22
|
- People don’t want complete isolation
- They want to:
- Cut/paste, drag/drop
- Share parts of the file system
- Share the screen
- Administer one machine, not multiple
- …
- But more integration can weaken isolation
- Add bugs
- Compromise security
|
23
|
- 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, ...
|
24
|
- As productivity applications, they must be well integrated in the work
environment (green)
- Threats—A tunnel from the bad guys
- Executable attachments
- Exploits of complicated data formats
- Choices
- Run two copies, one in Green and one in Red
- Run in Green and mitigate threats
- Green platform does not execute arbitrary programs
- Green apps are conservative in the file formats they accept
- Route messages to appropriate machine
|
25
|
|
26
|
- Security is about risk management
- Cost of security < expected
loss
- Security relies on deterrence more than locks
- Deterrence requires the threat of punishment
- This requires accountability
- Accountability needs an ecosystem
- Senders becoming accountable
- Receivers verifying accountability
- Accountability limits freedom
- Beat this by partitioning: red | green
- Don’t tickle bugs in green, dispose of red
|