http xkcd com 932 homework 2 review
play

http://xkcd.com/932/ Homework 2 Review CS 166: Information Security - PowerPoint PPT Presentation

http://xkcd.com/932/ Homework 2 Review CS 166: Information Security Authorization: Part 1 Prof. Tom Austin San Jos State University Authentication vs Authorization Authentication Are you who you say you are? Restrictions on who


  1. http://xkcd.com/932/

  2. Homework 2 Review

  3. CS 166: Information Security Authorization: Part 1 Prof. Tom Austin San José State University

  4. Authentication vs Authorization • Authentication ¾ Are you who you say you are? – Restrictions on who (or what) can access system • Authorization ¾ Are you allowed to do that? – Restrictions on actions of authenticated users • Authorization is a form of access control • But first, we look at system certification…

  5. System Certification • Government attempt to certify “security level” of products • Of historical interest – Sorta like a history of authorization • Still required today if you want to sell your product to the government – Tempting to argue it’s a failure since government is so insecure, but…

  6. The Orange Book • Trusted Computing System Evaluation Criteria (TCSEC) • Part of the "rainbow series" of DoD/NSA computer security standards

  7. Orange Book Outline • Goals – Provide way to assess security products – Provide guidance on how to build more secure products • Four divisions labeled D thru A – D is lowest, A is highest • Divisions split into numbered classes

  8. D Division • Minimal protection • Apparently, just for those that could not get into a higher division

  9. C Division – Detect Breaches • Don’t force security on users, but have means to detect breaches (audit) • C1 --- discretionary security protection • C2 --- controlled access protection • C2 slightly stronger than C1 – both are somewhat vague

  10. B Division – Mandatory Protection In C the attacker can break security, but will get caught. In B, the attacker can’t break it.

  11. B Divisions • B1 – labeled security protection – All data labeled, which restricts what can be done with it • B2 – structured protection – Adds covert channel protection onto B1 • B3 – security domains – Adds that code must be tamperproof and “small”

  12. A Division – Verified Protection • Like B3, but proved with formal methods • Formal methods are complex and difficult – Java PathFinder (NASA) • Very few companies meet this level

  13. Orange Book: Last Word • Also a 2 nd part, discusses rationale • Some people argue that we’d be better off if we’d followed it • Some consider its advice impractical and a dead end – And resulted in lots of wasted effort – Aside: people who made the orange book, now set security education standards

  14. Common Criteria • Successor to the orange book (ca. 1998) – Due to inflation, more than 1000 pages • An international government standard – And it reads like it… – Won’t ever stir same passions as orange book • CC is relevant if you want to sell to the government – Otherwise ignore it • Evaluation Assurance Levels (EALs) – 1 thru 7, from lowest to highest security

  15. EAL 1 thru 7 • EAL1 --- functionally tested • EAL2 --- structurally tested • EAL3 --- methodically tested, checked • EAL4 --- designed, tested, reviewed • EAL5 --- semiformally designed, tested • EAL6 --- verified, designed, tested • EAL7 --- formally … (blah blah blah)

  16. EAL • Note: product with a high EAL may not be more secure than one with lower EAL – Why? • Also, because a product has EAL doesn’t mean it’s better than the competition – Why?

  17. Common Criteria • EAL4 is most commonly sought – Minimum needed to sell to government • EAL7 requires formal proofs – Textbook author could only find 2 such products… • Who performs evaluations? – Government accredited labs, of course – For a hefty fee (like, at least 6 figures)

  18. Authentication vs Authorization • Authentication ¾ Are you who you say you are? – Restrictions on who (or what) can access system • Authorization ¾ Are you allowed to do that? – Restrictions on actions of authenticated users • Authorization is a form of access control • Classic authorization enforced by – Access Control Lists (ACLs) – Capabilities (C-lists)

  19. Lampson’s Access Control Matrix • Subjects (users) index the rows Accounting Insurance Accounting Payroll OS program data data data rx rx r --- --- Bob rx rx r rw rw Alice rwx rwx r rw rw Sam Accounting rx rx rw rw rw program

  20. Lampson’s Access Control Matrix • Subjects (users) index the rows • Objects (resources) index the columns Accounting Insurance Accounting Payroll OS program data data data rx rx r --- --- Bob rx rx r rw rw Alice rwx rwx r rw rw Sam Accounting rx rx rw rw rw program

  21. Are You Allowed to Do That? • Access control matrix has all relevant info • Could be 1000’s of users, 1000’s of resources • Then matrix with 1,000,000’s of entries • How to manage such a large matrix? • Need to check this matrix before access to any resource is allowed • How to make this efficient?

  22. Access Control Lists (ACLs) • ACL: store access control matrix by column • Example: ACL for insurance data is in blue Accounting Insurance Accounting Payroll OS program data data data rx rx r --- --- Bob rx rx r rw rw Alice rwx rwx r rw rw Sam Accounting rx rx rw rw rw program

  23. Capabilities (or C-Lists) • Store access control matrix by row • Example: Capability for Alice is in red Accounting Insurance Accounting Payroll OS program data data data rx rx r --- --- Bob rx rx r rw rw Alice rwx rwx r rw rw Sam Accounting rx rx rw rw rw program

  24. ACLs vs Capabilities r r Alice --- file1 Alice w file1 r rw --- w Bob Bob r file2 file2 r r --- rw r Fred r Fred --- file3 file3 r r Access Control List Capability • Note that arrows point in opposite directions… • With ACLs, still need to associate users to files

  25. ACLs and capabilities seem equivalent, but there are some surprising differences. Let's highlight one of the limitations of ACLs.

  26. The Confused Deputy Problem • Alice wants to compile her code on a 3 rd party pay-per-use service. – Alice is able to specify a debug file – She is not allowed to overwrite the billing file • The compiler process – compiles the code – updates a billing file

  27. The access control matrix Compiler BILL x --- Alice Compiler rx rw

  28. 1) Alice requests her 2) Compiler process code to be be compiled. updates billing Debug file: "debug.txt" information. Compiler 3) Debugging information written to "debug.txt". Alice Bill debug.txt

  29. 1) Alice requests her 2) Compiler process code to be be compiled. updates billing Debug file: "Bill" information. Compiler 3) Compiler overwrites bill with debugging information. Alice Bill

  30. The compiler is a deputy acting on Alice's behalf, but he has confused his authority with hers.

  31. Designators & Authorizations • With capabilities, we don't need a separate file system: a reference to a file is an intrinsic part of the design. • How does this help with the confused deputy? 1. Alice will not have a reference to Bill. 2. The Compiler can use its authority for the billing task, but Alice's for the compilation.

  32. Key analogy A capability can roughly be thought of as a key: • You can give a capability to another process, thus granting it your permissions • It cannot easily be forged • It cannot easily be stolen

  33. Problems with the key analogy • With careful design, capabilities (unlike keys) can be revoked. • Capabilities can be composed, breaking the subj/obj distinction. • For more details, see http://www.erights.org/elib/capability/du als/myths.html

  34. Object Capability Model Object capabilities extend the concepts of capabilities to object- oriented programming languages. In this system, capabilities are unforgeable references.

  35. Required properties for object capabilities 1. Memory safety: Can't get a reference unless: – You created the object – You were given a reference to the object 2. Encapsulation – Provides a form of access control: can't access internals of an object. 3. Only references enable effects 4. No powerful references by default

  36. Multilevel Security (MLS) Models

  37. Classifications and Clearances • Classifications apply to objects • Clearances apply to subjects • US Department of Defense (DoD) uses 4 levels: TO TOP SECRET SE SECRET CO CONFIDENTIAL UNC UNCLASSI ASSIFI FIED

  38. Clearances and Classification • To obtain a SE SECRET clearance requires a routine background check • A TO TOP SECRET clearance requires extensive background check • Practical classification problems – Proper classification not always clear – Level of granularity to apply classifications – Aggregation ¾ flipside of granularity

  39. Subjects and Objects • Let O be an object , S a subject – O has a classification – S has a clearance – Security level denoted L(O) and L(S) • For DoD levels, we have TOP S SECRET > SE SECRET > CO CONFIDEN ENTI TIAL > UNCLASSI SSIFI FIED

  40. Multilevel Security (MLS) • MLS needed when subjects/objects at different levels use/on same system • MLS is a form of Access Control • Military and government interest in MLS for many decades – Lots of research into MLS – Strengths and weaknesses of MLS well understood (almost entirely theoretical) – Many possible uses of MLS outside military

Download Presentation
Download Policy: The content available on the website is offered to you 'AS IS' for your personal information and use only. It cannot be commercialized, licensed, or distributed on other websites without prior consent from the author. To download a presentation, simply click this link. If you encounter any difficulties during the download process, it's possible that the publisher has removed the file from their server.

Recommend


More recommend