Security Outline Introduction: what is security? Butler Lampson - PDF document

Security Outline Introduction: what is security? Butler Lampson Principals, the “speaks for” relation, and chains of responsibility Secure channels and encryption TECS Week 2005 Names and groups January 2005 Authenticating systems Authorization Implementation 1 2 Security in Distributed Systems B. W. Lampson 4 January 2005 Security in Distributed Systems B. W. Lampson 4 January 2005 REAL-WORLD SECURITY Elements of Security It’s about value, locks, and punishment. Policy : Specifying security − What is it supposed to do? Locks good enough that bad guys don’t break in very often. Mechanism : Implementing security − Police and courts good enough that bad guys that do How does it do it? break in get caught and punished often enough. Assurance : Correctness of security − Less interference with daily life than value of loss. Does it really work? Security is expensive—buy only what you need. − People do behave this way − We don’t tell them this—a big mistake − Perfect security is the worst enemy of real security 3 4 Security in Distributed Systems B. W. Lampson 4 January 2005 Security in Distributed Systems B. W. Lampson 4 January 2005 Abstract Goals for Security Dangers Dangers Secrecy controlling who gets to read information Vandalism or sabotage that Integrity controlling how information changes or – damages information integrity resources are used – disrupts service availability Availability providing prompt access to information Theft of money integrity and resources Theft of information secrecy Accountability knowing who has had access to Loss of privacy secrecy information or resources Security in Distributed Systems B. W. Lampson 4 January 2005 5 Security in Distributed Systems B. W. Lampson 4 January 2005 6

Vulnerabilities Defensive strategies Coarse: Isolate —Keep everybody out Vulnerabilities – Disconnect – Bad (buggy or hostile) programs Medium: Exclude —Keep the bad guys out – Bad (careless or hostile) people – Code signing, firewalls giving instructions to good programs Fine: Restrict —Let the bad guys in, but keep them from – Bad guys corrupting or eavesdropping on doing damage communications – Hardest to implement – Sandboxing, access control Threats Recover —Undo the damage. Helps with integrity. – Adversaries that can and want to exploit – Backup systems, restore points vulnerabilities Punish —Catch the bad guys and prosecute them – Auditing, police 7 8 Security in Distributed Systems B. W. Lampson 4 January 2005 Security in Distributed Systems B. W. Lampson 4 January 2005 Assurance Assurance: Defense in Depth Trusted Computing Base (TCB) Network, with a firewall – Everything that security depends on Operating system, with sandboxing – Must get it right – Basic OS (such as NT) – Keep it small and simple – Higher-level OS (such as Java) Elements of TCB Application that checks authorization directly – Hardware – Software All need authentication – Configuration Defense in depth 9 10 Security in Distributed Systems B. W. Lampson 4 January 2005 Security in Distributed Systems B. W. Lampson 4 January 2005 TCB Examples TCB: Configuration Policy: Only outgoing Web access Done again for each system, unlike HW or SW TCB: firewall allowing outgoing port 80 TCP – New chance for mistakes each time connections, but no other traffic Done by amateurs, not experts Hardware, software, and configuration – No learning from experience – Little training Policy: Unix users can read system directories, and read and write their home directories Needs to be very simple TCB: hardware, Unix kernel, any program that can write – At the price of flexibility, fine granularity a system directory (including any that runs as superuser). Also /etc/passwd , permissions on all directories. Security in Distributed Systems B. W. Lampson 4 January 2005 11 Security in Distributed Systems B. W. Lampson 4 January 2005 12

Making Configuration Simple Assurance: Configuration Control Users—keep it simple It’s 2 am. Do you know what software is running on your machine? – At most three levels: self, friends, others Three places to put objects Secure configuration ⇒ some apps don’t run – Everything else done automatically with policies – Hence must be optional: “Secure my system” Administrators—keep it simple – Usually used only in an emergency – Work by defining policies. Examples: Affects the entire configuration Each user has a private home folder – Software: apps, drivers, macros Each user in one workgroup with a private folder – Access control: shares, authentication System folders contain vendor-approved releases All executable programs signed by a trusted party Also need configuration audit Today’s systems don’t support this very well 13 14 Security in Distributed Systems B. W. Lampson 4 January 2005 Security in Distributed Systems B. W. Lampson 4 January 2005 Why We Don’t Have “Real” Security “Principles” for Security Security is not formal A. People don’t buy it – Danger is small, so it’s OK to buy features instead. Security is not free – Security is expensive. Security is fractal Configuring security is a lot of work. Secure systems do less because they’re older. Abstraction can’t keep secrets – Security is a pain. – “Covert channels” leak them It stops you from doing things. Users have to authenticate themselves. It’s all about lattices B. Systems are complicated, so they have bugs. – Especially the configuration 15 16 Security in Distributed Systems B. W. Lampson 4 January 2005 Security in Distributed Systems B. W. Lampson 4 January 2005 ELEMENTS OF SECURITY Specify: Policies and Models Policy : Specifying security Policy — specifies the whole system informally. What is it supposed to do? Secrecy Who can read information? Mechanism : Implementing security Integrity Who can change things, and how? How does it do it? Availability How prompt is the service? Assurance : Correctness of security Does it really work? Model —specifies just the computer system, but does so precisely. Access control model guards control access to resources. Information flow model classify information, prevent disclosure. Security in Distributed Systems B. W. Lampson 4 January 2005 17 Security in Distributed Systems B. W. Lampson 4 January 2005 18

Implement: Mechanisms and Assurance Information flow model (Mandatory security) Mechanisms — tools for implementation. A lattice of labels for data: Authentication Who said it? – unclassified < secret < top secret ; Authorization Who is trusted? – public < personal < medical < financial Auditing What happened? label( f ( x )) = max(label( f ), label( x )) Trusted computing base. Labels can keep track of data properties: Keep it small and simple. – how secret Secrecy Validate each component carefully. – how trustworthy Integrity When you use (release or act on) the data, user needs a ≥ clearance 19 20 Security in Distributed Systems B. W. Lampson 4 January 2005 Security in Distributed Systems B. W. Lampson 4 January 2005 Access Control Model Access Control Guards control access to valued resources. Guards control access to valued resources. Structure the system as — Authentication Authorization Objects entities with state. Principals can request operations on objects. Do Reference Object Principal monitor Operations how subjects read or change objects. operation Authentication Authorization Source Request Guard Resource Do Reference Principal Object operation monitor Audit Source Request Guard Resource log Audit log 21 22 Security in Distributed Systems B. W. Lampson 4 January 2005 Security in Distributed Systems B. W. Lampson 4 January 2005 Access Control Rules Mechanisms—The Gold Standard Authenticating principals Rules control the operations allowed for each principal and object. − Mainly people, but also channels, servers, programs (encryption makes channels, so key is a principal) Principal may do Operation on Object Authorizing access Taylor Read File “ Raises ” − Usually for groups , principals that have some Lampson Send “ Hello ” Terminal 23 property, such as “Microsoft employee” or “type- safe” or “safe for scripting” Process 1274 Rewind Tape unit 7 Auditing Schwarzkopf Fire three shots Bow gun Jones Pay invoice 432 Account Q34 Assurance – Trusted computing base Security in Distributed Systems B. W. Lampson 4 January 2005 23 Security in Distributed Systems B. W. Lampson 4 January 2005 24