Outline Security Principles and Policies • Security terms and concepts CS 239 • Security policies Computer Security –Basic concepts Peter Reiher –Security policies for real systems January 13, 2005 Lecture 2 Lecture 2 Page 1 Page 2 CS 239, Winter 2005 CS 239, Winter 2005 Security and Protection Policy vs. Mechanism People shouldn’t drive • Security is a policy that fast in my – E.g., “no unauthorized user may access neighborhood! this file” • Protection is a mechanism That’s a mechanism – E.g., “the system checks user identity against access permissions” That’s a policy • Protection mechanisms implement security policies That’s a different type of mechanism Lecture 2 Lecture 2 Page 3 Page 4 CS 239, Winter 2005 CS 239, Winter 2005 Design Principles for Economy in Security Design Secure Systems • Economy • Economical to develop • Complete mediation –And to use • Open design –And to verify • Separation of privileges • Should add little or no overhead • Least privilege • Should do only what needs to be done • Least common mechanism • Generally, try to keep it simple and • Acceptability small • Fail-safe defaults Lecture 2 Lecture 2 Page 5 Page 6 CS 239, Winter 2005 CS 239, Winter 2005 1
Complete Mediation Open Design • Apply security on every access to a • Don’t rely on “security through obscurity” protected object • Assume all potential attackers know everything about the design –E.g., each read of a file, not just the – And completely understand it open • This doesn’t mean publish everything • Also involves checking access on important about your security system everything that could be attacked – Though sometimes that’s a good idea Lecture 2 Lecture 2 Page 7 Page 8 CS 239, Winter 2005 CS 239, Winter 2005 Separation of Privileges Least Privilege • Provide mechanisms that separate the • Give bare minimum access rights privileges used for one purpose from required to complete a task those used for another • Require another request to perform • To allow flexibility in security systems another type of access • E.g., separate access control on each • E.g., don’t give write permission to a file file if the program only asked for read Lecture 2 Lecture 2 Page 9 Page 10 CS 239, Winter 2005 CS 239, Winter 2005 Least Common Mechanism Acceptability • Avoid sharing parts of the security • Mechanism must be simple to use mechanism • Simple enough that people will use it –among different users without thinking about it –among different parts of the system • Must rarely or never prevent permissible accesses • Coupling leads to possible security breaches Lecture 2 Lecture 2 Page 11 Page 12 CS 239, Winter 2005 CS 239, Winter 2005 2
Fail-Safe Designs Thinking About Security When considering the security of any system, ask these • Default to lack of access questions: • So if something goes wrong or is 1. What assets are you trying to protect? 2. What are the risks to those assets? forgotten or isn’t done, no security lost 3. How well does the security solution mitigate those risks? • If important mistakes are made, you’ll 4. What other security problems does the security solution find out about them cause? 5. What tradeoffs does the security solution require? –Without loss of security (This set of questions was developed by Bruce Schneier, for his book Beyond Fear ) –But if it happens too often . . . Lecture 2 Lecture 2 Page 13 Page 14 CS 239, Winter 2005 CS 239, Winter 2005 What Assets Are We Trying to An Example Protect? • Access to computers in the graduate • ? workstation room • Current security solution – Must provide valid CS department user ID and password Lecture 2 Lecture 2 Page 15 Page 16 CS 239, Winter 2005 CS 239, Winter 2005 How Well Does the Security What Are the Risks to Those Assets? Solution Mitigate Those Risks? • ? • ? Lecture 2 Lecture 2 Page 17 Page 18 CS 239, Winter 2005 CS 239, Winter 2005 3
What Other Security Problems Does What Tradeoffs Does the Security the Security Solution Cause? Solution Require? • ? • ? Lecture 2 Lecture 2 Page 19 Page 20 CS 239, Winter 2005 CS 239, Winter 2005 Security Policies What Is a Security Policy? • A complete description of the security • Security policies describe how a secure goals the system should achieve system should behave –Not a description of how to achieve • Generally, if you don’t have a clear them policy, you don’t have a secure system • Sometimes described informally –Since you don’t really know what • Sometimes described very formally you’re trying to do –Using mathematical models Lecture 2 Lecture 2 Page 21 Page 22 CS 239, Winter 2005 CS 239, Winter 2005 Informal Security Policies Access Control Policies • “Users should only be able to access their • Describe who can access what own files, in most cases.” resources • “Only authorized users should be able to log in.” • Mandatory access control • “System executables should only be altered –The system enforces its own policy by system administrators.” • The general idea is pretty clear • Discretionary access control • But it can be hard to determine if a system –Policy set by individual users meets these goals Lecture 2 Lecture 2 Page 23 Page 24 CS 239, Winter 2005 CS 239, Winter 2005 4
Formal Security Policies Bell-La Padula Model • Probably best-known computer security • Typically expressed in a mathematical model security policy language • Corresponds to military classifications • Tending towards precision • Combines mandatory and discretionary – Allowing formal reasoning about the access control system and policy • Two parts: • Often matched to a particular policy model – Clearances – E.g., Bell-La Padua model – Classifications Lecture 2 Lecture 2 Page 25 Page 26 CS 239, Winter 2005 CS 239, Winter 2005 Clearances Classifications • Each object (file, database entry, etc.) has a • Subjects (people, programs, etc.) have classification a clearance • The classification describes how sensitive • Clearance describes how trusted the the object is subject is • Using same categories as clearances • E.g., unclassified , confidential , secret , • Informally, only people with the same (or higher) clearance should be able to access top secret objects of a particular classification Lecture 2 Lecture 2 Page 27 Page 28 CS 239, Winter 2005 CS 239, Winter 2005 Bell-LaPadula Simple Security Goal of Bell-LaPadula Model Condition • Prevent any subject from ever getting read • Subject S can read object O iff l O ≤ l S access to objects at higher classification • Simple enough: levels than subject’s clearance –If S isn’t granted top secret • Really, concerned not just with objects clearance, S can’t read top secret • Also concerned with the objects’ contents objects • Includes discretionary access control • Are we done? – Which we won’t cover in lecture Lecture 2 Lecture 2 Page 29 Page 30 CS 239, Winter 2005 CS 239, Winter 2005 5
Why Aren’t We Done? The Bell-LaPadula *-Property • S can write O iff l S ≤ l O • Remember, we really care about the information in an object • Prevents write-down – Privileged subjects writing high- • A subject with top secret clearance can read classification information to low- a top secret object classification objects • If careless, he could write that information – E.g., a top secret user can’t write to a to a confidential object confidential data file • Then someone with confidential clearance • Can be proven that a system meeting these can read top secret information properties is “secure” Lecture 2 Lecture 2 Page 31 Page 32 CS 239, Winter 2005 CS 239, Winter 2005 Bell-LaPadula Example Bell-LaPadula Caveats TOP S TO P SE CRET • A provably secure Bell-LaPadula system O R may be impossible to really use D Classif Cla ssified read E R S • Says nothing about some other important Write (attack the red tank) security properties Classified Top Secret write Bell-LaPadula – Like integrity doesn’t allow write-down! Secret Lecture 2 Lecture 2 Page 33 Page 34 CS 239, Winter 2005 CS 239, Winter 2005 Integrity Security Policies Example: Biba Integrity Policy • Subject set S, object set O • Designed to ensure that information is • Set of ordered integrity levels I not improperly changed • Subjects and objects have integrity levels • Often the key issue for commercial • Subjects at high integrity levels are less likely to screw up data systems – E.g., trusted users or carefully audited programs • Secrecy is nice, but not losing track of • Data at a high integrity level is less likely to be screwed up your inventory is crucial – Probably because it badly needs not to be screwed up Lecture 2 Lecture 2 Page 35 Page 36 CS 239, Winter 2005 CS 239, Winter 2005 6
Recommend
More recommend
