INSTITUTE FOR CYBER SECURITY Security Models: Past, Present and Future Prof. Ravi Sandhu Executive Director and Endowed Chair Institute for Cyber Security University of Texas at San Antonio July 2009 ravi. sandhu@utsa. edu www. profsandhu. com © Ravi Sandhu 1
INSTITUTE FOR CYBER SECURITY THE BIG PICTURE © Ravi Sandhu 2
INSTITUTE FOR CYBER SECURITY Security Objectives INTEGRITY modification AVAILABILITY access CONFIDENTIALITY disclosure © Ravi Sandhu 3
INSTITUTE FOR CYBER SECURITY Security Objectives USAGE purpose INTEGRITY modification AVAILABILITY access CONFIDENTIALITY disclosure © Ravi Sandhu 4
Security Objectives INSTITUTE FOR CYBER SECURITY USAGE purpose INTEGRITY modification USAGE AVAILABILITY access CONFIDENTIALITY disclosure © Ravi Sandhu 5
INSTITUTE FOR CYBER SECURITY Security Trends and Change Drivers Stand-alone computers Internet Vandals Criminals, Nation states, Terrorists Enterprise security Mutually suspicious yet mutually dependent security Few standard services Many and new innovative services We are at an inflection point © Ravi Sandhu 6
INSTITUTE FOR CYBER SECURITY Diffie on Information Security … 2007 “Now we face a new challenge to security, a world of shared computing and web services. As with radio, this technology is too valuable to go unused, By contrast with radio, which could be protected with cryptography, there may be no technology that can protect shared computation to the degree we would call secure today. In a decade or a generation, there may be no secure computing. ” Need to be realistic in our security expectations © Ravi Sandhu 7
INSTITUTE FOR CYBER SECURITY Butler Lampson Paraphrased (I think) Computer scientists could never have designed the web because they would have tried to make it work. But the Web does “work. ” What does it mean for the Web to “work”? Security geeks could never have designed the ATM network because they would have tried to make it secure. But the ATM network is “secure. What does it mean for the ATM network to be “secure”? © Ravi Sandhu 8
INSTITUTE FOR CYBER SECURITY Information needs to be protected Trying to approximate absolute security is a bad strategy “Good enough” security is feasible and meaningful Better than “good enough” is bad Security is meaningless without application context In motion At rest In use Absolute security is impossible and unnecessary Foundational Security Assumptions Cannot know we have “good enough” without this context Models and abstractions are all important Without a conceptual framework it is hard to separate “what needs to be done” from “how we do it” We are not very good at doing any of this © Ravi Sandhu 9
INSTITUTE FOR CYBER SECURITY Our Basic Premise There can be no security without application context Courtney’s Law (1970 s, 1980 s ? ? ): Ø You cannot say anything interesting (i. e. significant) about the security of a system except in the context of a particular application and environment Corollary Application Context There can be no security model without application context Reality Existing security models are application neutral Ø Assumption is they can be readily “configured” or “policyfied” to suit application context There is also a notion of technology context for security models but of scope for this lecture © Ravi Sandhu 10
Application Context INSTITUTE FOR CYBER SECURITY Software. Architect Alice Bob % Time 25% 75% 100% Label U S U What precisely is Secret? Project Vista Secure. Vista XP There exists a Secure. Vista project Alice works on Secure. Vista Alice’s effort on Secure. Vista is 75% All or some of the above How do we maintain integrity of the database? Depends Much work and $$$ by researchers and vendors, late 80’s-early 90’s © Ravi Sandhu 11
INSTITUTE FOR CYBER SECURITY Emerging Application-Centric Era (ACE) ECE ACE Enterprise-Centric Era Applications are cyber analogs of previously existing enterprise-centric applications • • • on-line banking brokerage e-retail auctions search engines © Ravi Sandhu Future applications will be fundamentally different • • • ? ? ? 12
INSTITUTE FOR CYBER SECURITY PEI Models: 3 Layers/5 Layers This lecture is focused on the policy models layer Idealized Enforceable (Approximate) Codeable At the policy layer security models are essentially access control models © Ravi Sandhu 13
INSTITUTE FOR CYBER SECURITY THE PAST © Ravi Sandhu 14
INSTITUTE FOR CYBER SECURITY Discretionary Access Control (DAC) Owner controls access but only to the original, not to copies Mandatory Access Control (MAC) Same as Lattice-Based Access Control (LBAC) Access Control Models Access based on security labels Labels propagate to copies Role-Based Access Control (RBAC) Access based on roles Can be configured to do DAC or MAC © Ravi Sandhu 15
ACCESS MATRIX MODEL INSTITUTE FOR CYBER SECURITY Objects (and Subjects) G F S u b j e c t s U V rw own rights © Ravi Sandhu 16
INSTITUTE FOR CYBER SECURITY ACCESS CONTROL LISTS (ACLs) F G U: r U: w V: r U: own V: w V: own each column of the access matrix is stored with the object corresponding to that column © Ravi Sandhu 17
INSTITUTE FOR CYBER SECURITY CAPABILITY LISTS U F/r, F/w, F/own, G/r V G/r, G/w, G/own each row of the access matrix is stored with the subject corresponding to that row © Ravi Sandhu 18
INSTITUTE FOR CYBER SECURITY Subject ACCESS CONTROL TRIPLES Access Object U r F U w F U own F U r G V w G V own G commonly used in relational database management systems © Ravi Sandhu 19
INSTITUTE FOR CYBER SECURITY TROJAN HORSE EXAMPLE ACL File F File G A: r A: w B cannot read file F © Ravi Sandhu 20
INSTITUTE FOR CYBER SECURITY TROJAN HORSE EXAMPLE ACL A executes Program Goodies read File F Trojan Horse write File G A: r A: w B can read contents of file F copied to file G © Ravi Sandhu 21
INSTITUTE FOR CYBER SECURITY Traditional DAC does not prevent copies from being made and there is no control over copies DAC Summary Modern approaches to information sharing and trusted computing seek to maintain control over copies Traditional DAC is weak with respect to confidentiality but may have value with respect to integrity © Ravi Sandhu 22
LATTICE STRUCTURES INSTITUTE FOR CYBER SECURITY Top Secret Confidential Unclassified dominance © Ravi Sandhu can-flow 23
INSTITUTE FOR CYBER SECURITY BELL LAPADULA (BLP) MODEL SIMPLE-SECURITY Subject S can read object O only if • label(S) dominates label(O) STAR-PROPERTY (LIBERAL) Subject S can write object O only if • label(O) dominates label(S) STAR-PROPERTY (STRICT) Subject S can write object O only if • © Ravi Sandhu label(O) equals label(S) 24
LATTICE STRUCTURES INSTITUTE FOR CYBER SECURITY {ARMY, CRYPTO} {ARMY } Compartments and Categories {CRYPTO} {} © Ravi Sandhu 25
LATTICE STRUCTURES INSTITUTE FOR CYBER SECURITY Hierarchical Classes with Compartments {A, B} TS {B} {A} S {} product of 2 lattices is a lattice © Ravi Sandhu 26
LATTICE STRUCTURES INSTITUTE FOR CYBER SECURITY TS, {A, B} TS, {A} Hierarchical Classes with Compartments TS, {} S, {A, B} S, {A} S, {B} S, {} © Ravi Sandhu 27
INSTITUTE FOR CYBER SECURITY SMITH'S LATTICE TS-AKLQWXYZ TS-KLX TS-KY TS-KQZ TS-KL TS-W TS-X TS-L TS-K TS-Y TS-Q TS-Z TS-X S-LW S-L TS S-A S-W S C © Ravi Sandhu U 28
INSTITUTE FOR CYBER SECURITY EQUIVALENCE OF BLP AND BIBA HI (High Integrity) LI (Low Integrity) BIBA LATTICE © Ravi Sandhu HI (High Integrity) EQUIVALENT BLP LATTICE 29
INSTITUTE FOR CYBER SECURITY EQUIVALENCE OF BLP AND BIBA HS (High Secrecy) LS (Low Secrecy) BLP LATTICE © Ravi Sandhu HS (High Secrecy) EQUIVALENT BIBA LATTICE 30
INSTITUTE FOR CYBER SECURITY COMBINATION OF DISTINCT LATTICES HI HS HS, LI HS, HI LI LS BLP LS, LI LS, HI BIBA GIVEN © Ravi Sandhu EQUIVALENT BLP LATTICE 31
INSTITUTE FOR CYBER SECURITY LIPNER'S LATTICE S: System Managers O: Audit Trail LEGEND S: Subjects O: Objects S: Repair S: Production Users O: Production Data O: Repair Code © Ravi Sandhu S: System Control S: Application Programmers O: Development Code and Data O: Production Code O: System Programs S: System Programmers O: System Code in Development O: Tools 32
CHINESE WALL EXAMPLE INSTITUTE FOR CYBER SECURITY OIL COMPANIES BANKS A © Ravi Sandhu B X Y 33
CHINESE WALL LATTICE INSTITUTE FOR CYBER SECURITY SYSHIGH A, X A, Y B, X B, Y A, - -, X -, Y B, - SYSLOW © Ravi Sandhu 34
INSTITUTE FOR CYBER SECURITY High User Information is leaked unknown to the high user Low User © Ravi Sandhu COVERT CHANNELS High Trojan Horse Infected Subject COVERT CHANNEL Low Trojan Horse Infected Subject 35
INSTITUTE FOR CYBER SECURITY MAC/LBAC Summary LBAC fails to control covert channels LBAC fails to control inference and aggregation It is too rigid for most commercial applications It has strong mathematical foundations © Ravi Sandhu 36
INSTITUTE FOR CYBER SECURITY RBAC: Role-Based Access Control Access is determined by roles A user’s roles are assigned by security administrators A role’s permissions are assigned by security administrators Is RBAC MAC or DAC or neither? © Ravi Sandhu First emerged: mid 1970 s First models: mid 1990 s 37
INSTITUTE FOR CYBER SECURITY Fundamental Theorem of RBAC can be configured to do MAC RBAC can be configured to do DAC RBAC is policy neutral RBAC is neither MAC nor DAC! © Ravi Sandhu 38
RBAC 96 Model INSTITUTE FOR CYBER SECURITY USER-ROLE ASSIGNMENT ROLES USERS . . . © Ravi Sandhu PERMISSIONS-ROLE ASSIGNMENT PERMISSIONS SESSIONS 39
RBAC 96 Model INSTITUTE FOR CYBER SECURITY ROLE HIERARCHIES USER-ROLE ASSIGNMENT ROLES USERS . . . © Ravi Sandhu PERMISSIONS-ROLE ASSIGNMENT PERMISSIONS SESSIONS 40
RBAC 96 Model INSTITUTE FOR CYBER SECURITY ROLE HIERARCHIES USER-ROLE ASSIGNMENT ROLES USERS . . . © Ravi Sandhu PERMISSIONS-ROLE ASSIGNMENT SESSIONS PERMISSIONS CONSTRAINTS 41
INSTITUTE FOR CYBER SECURITY Example Role Hierarchy Director (DIR) Project Lead 1 (PL 1) Production 1 (P 1) Project Lead 2 (PL 2) Quality 1 (Q 1) Production 2 (P 2) Engineer 1 (E 1) Inheritance hierarchy Quality 2 (Q 2) Engineer 2 (E 2) Engineering Department (ED) Employee (E) © Ravi Sandhu 42
INSTITUTE FOR CYBER SECURITY Example Role Hierarchy Director (DIR) Project Lead 1 (PL 1) Production 1 (P 1) Project Lead 2 (PL 2) Quality 1 (Q 1) Production 2 (P 2) Engineer 1 (E 1) Inheritance and activation hierarchy Quality 2 (Q 2) Engineer 2 (E 2) Engineering Department (ED) Employee (E) © Ravi Sandhu 43
NIST/ANSI RBAC Standard Model 2004 INSTITUTE FOR CYBER SECURITY Permission-role review is ROLE HIERARCHIES advanced requirement USER-ROLE ASSIGNMENT ROLES USERS Overall formal model is more complete © Ravi Sandhu PERMISSIONS-ROLE ASSIGNMENT . . . SESSIONS PERMISSIONS Limited to separation of duties CONSTRAINTS 44
The RBAC Story INSTITUTE FOR CYBER SECURITY Proposed Standard Adopted RBAC 96 paper © Ravi Sandhu 45
INSTITUTE FOR CYBER SECURITY THE PRESENT © Ravi Sandhu 46
INSTITUTE FOR CYBER SECURITY Discretionary Access Control (DAC) Access based on security labels Labels propagate to copies Role-Based Access Control (RBAC) Owner controls access but only to the original, not to copies Mandatory Access Control (MAC) Same as Lattice-Based Access Control (LBAC) Access Control Models Access based on roles Can be configured to do DAC or MAC Attribute-Based Access Control (ABAC) Access based on attributes, to possibly include roles, security labels and whatever © Ravi Sandhu 47
INSTITUTE FOR CYBER SECURITY Founding Principles of RBAC 96 Abstraction of Privileges Credit is different from Debit even though both require read and write Separation of Administrative Functions Separation of user-role assignment from rolepermission assignment Least Privilege Right-size the roles Don’t activate all roles all the time Separation of Duty Static separation: purchasing manager versus accounts payable manager Dynamic separation: cash-register clerk versus cash-register manager © Ravi Sandhu 48
INSTITUTE FOR CYBER SECURITY Abstraction of Privileges Credit vs debit Personalized permissions Separation of Administrative Functions Containment Least Privilege Separation of Duties ASCAA Principles for Future Access Control Usage Limits Automation Revocation Assignment: (i) Self-assignment, (ii) Attribute-based Context and environment adjustment Accountability Re-authentication/Escalated authentication Click-through obligations Notification and alerts © Ravi Sandhu 49
INSTITUTE FOR CYBER SECURITY Usage Control Scope Security Objectives Security Architectures © Ravi Sandhu 50
INSTITUTE FOR CYBER SECURITY Usage Control Model (UCON) unified model integrating • authorization • obligation • conditions • and incorporating • continuity of decisions • mutability of attributes • © Ravi Sandhu 51
INSTITUTE FOR CYBER SECURITY Usage Control Model (UCON) DAC LBAC RBAC ABAC … and many, many others UCON ABAC on steroids Simple, familiar, usable and effective use cases demonstrate the need for UCON Ø Automatic Teller Machines Ø CAPTCHAs at Public web sites Ø End User Licencse Agreements Ø Terms of Usage for Wi. Fi in Hotels, Airports Ø Rate limits on call center workers © Ravi Sandhu 52
INSTITUTE FOR CYBER SECURITY THE FUTURE © Ravi Sandhu 53
INSTITUTE FOR CYBER SECURITY Our Basic Premise Application-Centric Security Models There can be no security model without application context So how does one customize an application-centric security model? Meaningfully combine the essential insights of Ø DAC, LBAC, RBAC, ABAC, UCON, etcetera Directly address the application-specific trade-offs Ø Within the security objectives of confidentiality, integrity and availability Ø Across security, performance, cost and usability objectives Separate the real-world concerns of Ø practical distributed systems and ensuing staleness and approximations (enforcement layer) from Ø © Ravi Sandhu policy concerns in a idealized environment (policy layer) 54
INSTITUTE FOR CYBER SECURITY PEI Models: 3 Layers/5 Layers Idealized Enforceable (Approximate) Codeable This lecture is focused on the policy models layer © Ravi Sandhu 55
Dissemination-Centric Sharing INSTITUTE FOR CYBER SECURITY Extensive research in the last two decades ORCON, DRM, ERM, Xr. ML, ODRL, etc. Copy/usage control has received major attention Manageability problem largely unaddressed Attribute + Policy Cloud Object Alice Attribute Cloud Object Bob Attribute Cloud Attribute + Policy Cloud Object Charlie Attribute Cloud Attribute + Policy Cloud Object Eve Attribute Cloud Susie Attribute Cloud Dissemination Chain with Sticky Policies on Objects © Ravi Sandhu 56
INSTITUTE FOR CYBER SECURITY Brings users & objects together in a group Focuses on manageability using groups Co-exists with dissemination-centric Two metaphors Secure Meeting Room (E. g. Program committee) Subscription Model (E. g. Secure multicast) Group characteristics leave Group Authz (u, o, r)? E. g. Are there any core properties? Group operation semantics E. g. What is authorized by join, add, etc. ? Read-only Vs Read-Write Administrative aspects join Users Operational aspects Group-Centric Sharing (g-SIS) E. g. Who authorizes join, add, etc. ? May be application dependant Inter-group relationship Multiple groups © Ravi Sandhu remove add Objects 57
INSTITUTE FOR CYBER SECURITY join g-SIS Operation Semantics Users leave GROUP Authz (u, o, r)? add © Ravi Sandhu Objects remove 58
INSTITUTE FOR CYBER SECURITY Liberal Join Strict Join g-SIS Operation Semantics Users Strict Leave Liberal Leave GROUP Authz (u, o, r)? Strict Add Liberal Add © Ravi Sandhu Objects Strict Remove Liberal Remove 59
INSTITUTE FOR CYBER SECURITY Family of g-SIS Policy Models Traditional Groups: <LJ, SL, LA, SR> Secure Multicast: <SJ, LL, LA, *> Most Restrictive g-SIS Specification: © Ravi Sandhu 60
g-SIS Enforcement Model INSTITUTE FOR CYBER SECURITY 3. 2 Set Leave-TS (s) e t. R 5. 1 1. Read Objects TRM u eq R CC h es fr es a pd tr t e. A s ute ib t U. 2 5 TRM 4. 2 Add o to ORL … TRM CC: Control Center GA: Group Administrator 4. 1 Re Ob mo jec ve t (o ) 3. Le 1 Su av bj e ec (s t ) GA Group Subjects Subject Attributes: {id, Join-TS, Leave. TS, ORL, g. Key} ORL: Object Revocation List g. Key: Group Key Object Attributes: {id, Add. TS} Refresh Time (RT): TRM contacts CC to update attributes © Ravi Sandhu 61
INSTITUTE FOR CYBER SECURITY From Policy to Enforcement Additional Trusted/Semi-Trusted Servers Approximate Enforcement Finally, the Implementation layer models spell out protocol details and details of TRM algorithms © Ravi Sandhu 62
INSTITUTE FOR CYBER SECURITY CONCLUSION © Ravi Sandhu 63
INSTITUTE FOR CYBER SECURITY Conclusion THE PAST Discretionary Access Control (DAC) Mandatory Access Control (MAC) Equivalently Lattice-Based Access Control (LBAC) Role-Based Access Control (RBAC) THE PRESENT Usage Control (UCON) Attribute-Based Access Control (ABAC) on steroids THE FUTURE Application-Centric Access Control Models Technology-Centric Access Control Models are all important A Policy Language is not a substitute for a good model © Ravi Sandhu 64
Скачать презентацию INSTITUTE FOR CYBER SECURITY Security Models Past Present
436be323aeb8872d8588a5712bc82b10.ppt