This preview shows page 1-2-3 out of 9 pages.

Save
View full document
View full document
Premium Document
Do you want full access? Go Premium and unlock all 9 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 9 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 9 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 9 pages.
Access to all documents
Download any document
Ad free experience

Unformatted text preview:

1Lecture 2Page 1CS 239, Winter 2005Security Principles and PoliciesCS 239Computer Security Peter ReiherJanuary 13, 2005Lecture 2Page 2CS 239, Winter 2005Outline• Security terms and concepts• Security policies– Basic concepts– Security policies for real systemsLecture 2Page 3CS 239, Winter 2005Security and Protection• Security is a policy– E.g., “no unauthorized user may access this file”• Protection is a mechanism– E.g., “the system checks user identity against access permissions”• Protection mechanisms implement security policiesLecture 2Page 4CS 239, Winter 2005Policy vs. MechanismPeople shouldn’t drive that fast in my neighborhood!That’sapolicyThat’samechanismThat’sadifferenttypeofmechanismLecture 2Page 5CS 239, Winter 2005Design Principles for Secure Systems• Economy• Complete mediation• Open design• Separation of privileges• Least privilege• Least common mechanism• Acceptability• Fail-safe defaultsLecture 2Page 6CS 239, Winter 2005Economy in Security Design• Economical to develop– And to use– And to verify• Should add little or no overhead• Should do only what needs to be done• Generally, try to keep it simple and small2Lecture 2Page 7CS 239, Winter 2005Complete Mediation• Apply security on every access to a protected object– E.g., each read of a file, not just the open• Also involves checking access on everything that could be attackedLecture 2Page 8CS 239, Winter 2005Open Design• Don’t rely on “security through obscurity”• Assume all potential attackers know everything about the design– And completely understand it• This doesn’t mean publish everything important about your security system– Though sometimes that’s a good ideaLecture 2Page 9CS 239, Winter 2005Separation of Privileges• Provide mechanisms that separate the privileges used for one purpose from those used for another• To allow flexibility in security systems• E.g., separate access control on each fileLecture 2Page 10CS 239, Winter 2005Least Privilege • Give bare minimum access rights required to complete a task• Require another request to perform another type of access• E.g., don’t give write permission to a file if the program only asked for readLecture 2Page 11CS 239, Winter 2005Least Common Mechanism• Avoid sharing parts of the security mechanism – among different users– among different parts of the system• Coupling leads to possible security breachesLecture 2Page 12CS 239, Winter 2005Acceptability• Mechanism must be simple to use• Simple enough that people will use it without thinking about it• Must rarely or never prevent permissible accesses3Lecture 2Page 13CS 239, Winter 2005Fail-Safe Designs• Default to lack of access• So if something goes wrong or is forgotten or isn’t done, no security lost• If important mistakes are made, you’ll find out about them– Without loss of security– But if it happens too often . . .Lecture 2Page 14CS 239, Winter 2005Thinking About SecurityWhen considering the security of any system, ask these questions:1. What assets are you trying to protect?2. What are the risks to those assets?3. How well does the security solution mitigate those risks?4. What other security problems does the security solution cause?5. What tradeoffs does the security solution require?(This set of questions was developed by Bruce Schneier, for his book Beyond Fear)Lecture 2Page 15CS 239, Winter 2005An Example• Access to computers in the graduate workstation room• Current security solution– Must provide valid CS department user ID and passwordLecture 2Page 16CS 239, Winter 2005What Assets Are We Trying to Protect?•?Lecture 2Page 17CS 239, Winter 2005What Are the Risks to Those Assets?•?Lecture 2Page 18CS 239, Winter 2005How Well Does the Security Solution Mitigate Those Risks?•?4Lecture 2Page 19CS 239, Winter 2005What Other Security Problems Does the Security Solution Cause? •?Lecture 2Page 20CS 239, Winter 2005What Tradeoffs Does the Security Solution Require?•?Lecture 2Page 21CS 239, Winter 2005Security Policies• Security policies describe how a secure system should behave• Generally, if you don’t have a clear policy, you don’t have a secure system– Since you don’t really know what you’re trying to doLecture 2Page 22CS 239, Winter 2005What Is a Security Policy?• A complete description of the security goals the system should achieve– Not a description of how to achieve them• Sometimes described informally• Sometimes described very formally– Using mathematical modelsLecture 2Page 23CS 239, Winter 2005Informal Security Policies• “Users should only be able to access their own files, in most cases.”• “Only authorized users should be able to log in.”• “System executables should only be altered by system administrators.”• The general idea is pretty clear• But it can be hard to determine if a system meets these goalsLecture 2Page 24CS 239, Winter 2005Access Control Policies• Describe who can access what resources• Mandatory access control– The system enforces its own policy• Discretionary access control– Policy set by individual users5Lecture 2Page 25CS 239, Winter 2005Formal Security Policies• Typically expressed in a mathematical security policy language• Tending towards precision– Allowing formal reasoning about the system and policy• Often matched to a particular policy model– E.g., Bell-La Padua modelLecture 2Page 26CS 239, Winter 2005Bell-La Padula Model• Probably best-known computer security model• Corresponds to military classifications• Combines mandatory and discretionary access control•Two parts:– Clearances– ClassificationsLecture 2Page 27CS 239, Winter 2005Clearances• Subjects (people, programs, etc.) have a clearance• Clearance describes how trusted the subject is• E.g., unclassified, confidential, secret, top secretLecture 2Page 28CS 239, Winter 2005Classifications• Each object (file, database entry, etc.) has a classification• The classification describes how sensitive the object is• Using same categories as clearances• Informally, only people with the same (or higher) clearance should be able to access objects of a particular classificationLecture 2Page 29CS 239, Winter 2005Goal of Bell-LaPadula Model• Prevent any subject from ever getting read access to objects at higher classification levels than subject’s clearance• Really,


View Full Document

UCLA COMSCI 239 - lecture2

Download lecture2
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view lecture2 and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view lecture2 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?