1 / 42

Cyber-Identity, Authority and Trust in an Uncertain World

Cyber-Identity, Authority and Trust in an Uncertain World. Prof. Ravi Sandhu Laboratory for Information Security Technology George Mason University www.list.gmu.edu sandhu@gmu.edu. Outline. Perspective on security Role Based Access Control (RBAC)

druce
Download Presentation

Cyber-Identity, Authority and Trust in an Uncertain World

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Cyber-Identity, Authority and Trust in an Uncertain World Prof. Ravi Sandhu Laboratory for Information Security Technology George Mason University www.list.gmu.edu sandhu@gmu.edu

  2. Outline • Perspective on security • Role Based Access Control (RBAC) • Objective Model-Architecture Mechanism (OM-AM) Framework • Usage Control (UCON) • Discussion

  3. PERSPECTIVE

  4. Security Conundrum • Nobody knows WHAT security is • Some of us do know HOW to implement pieces of it Result: hammers in search of nails

  5. USAGE purpose • electronic commerce, electronic business Security Confusion • DRM, client-side controls INTEGRITY modification AVAILABILITY access CONFIDENTIALITY disclosure

  6. Security Successes • On-line banking • On-line trading • Automatic teller machines (ATMs) • GSM phones • Set-top boxes Success is largely unrecognized by the security community

  7. Good enough security • Exceeding good enough is not good • You will pay a price in user convenience, ease of operation, cost, performance, availability, … • There is no such thing as free security • Determining good enough is hard • Necessarily a moving target

  8. Good enough security Real-world users Security geeks SECURE EASY • end users • operations staff • help desk • whose security • perception or reality of security System owner COST • system solution • operational cost • opportunity cost • cost of fraud

  9. Good enough security • In many cases good enough is achievable at a pretty low threshold • The “entrepreneurial” mindset • In extreme cases good enough will require a painfully high threshold • The “academic” mindset

  10. ROLE-BASED ACCESS CONTROL (RBAC)

  11. MAC and DAC • For 25 years access control has been divided into • Mandatory Access Control (MAC) • Discretionary Access Control (DAC) • In the past 10 years RBAC has become a dominant force • RBAC subsumes MAC and DAC

  12. Mandatory Access Control (MAC) TS S Lattice of security labels C Information Flow Dominance U

  13. Mandatory Access Control (MAC) S,{A,B} S,{B} S,{A] Dominance Information Flow Lattice of security labels S,{}

  14. Discretionary Access Control (DAC) • The owner of a resource determines access to that resource • The owner is often the creator of the resource • Fails to distinguish read from copy

  15. ... RBAC96 model(Currently foundation of an NIST/ANSI/ISO standard) ROLE HIERARCHIES USER-ROLE ASSIGNMENT PERMISSIONS-ROLE ASSIGNMENT USERS ROLES PERMISSIONS SESSIONS CONSTRAINTS

  16. RBAC SECURITY PRINCIPLES • least privilege • separation of duties • separation of administration and access • abstract operations

  17. HIERARCHICAL ROLES Primary-Care Physician Specialist Physician Physician Health-Care Provider

  18. Fundamental Theorem of RBAC • RBAC can be configured to do MAC • RBAC can be configured to do DAC RBAC is policy neutral

  19. OM-AM(Objective/Model-Architecture/Mechanism)Framework

  20. THE OM-AM WAY A s s u r a n c e Objectives Model Architecture Mechanism What? How?

  21. LAYERS AND LAYERS • Multics rings • Layered abstractions • Waterfall model • Network protocol stacks • Napolean layers • RoFi layers • OM-AM • etcetera

  22. What? How? OM-AM AND MANDATORY ACCESS CONTROL (MAC) A s s u r a n c e No information leakage Lattices (Bell-LaPadula) Security kernel Security labels

  23. What? How? OM-AM AND DISCRETIONARY ACCESS CONTROL (DAC) A s s u r a n c e Owner-based discretion numerous numerous ACLs, Capabilities, etc

  24. What? How? OM-AM AND ROLE-BASED ACCESS CONTROL (RBAC) A s s u r a n c e Objective neutral RBAC96, ARBAC97, etc. user-pull, server-pull, etc. certificates, tickets, PACs, etc.

  25. ROLE HIERARCHIES USER-ROLE ASSIGNMENT PERMISSIONS-ROLE ASSIGNMENT USERS ROLES PERMISSIONS ... SESSIONS CONSTRAINTS RBAC96 Model

  26. Server-Pull Architecture Client Server User-role Authorization Server

  27. User-Pull Architecture Client Server User-role Authorization Server

  28. Proxy-Based Architecture Client Proxy Server Server User-role Authorization Server

  29. USAGE CONTROL (UCON)

  30. The UCON Vision:A unified model • Traditional access control models are not adequatefor today’s distributed, network-connected digital environment. • Authorization only – No obligation or condition based control • Decision is made before access – No ongoing control • No consumable rights - No mutable attributes • Rights are pre-defined and granted to subjects

  31. OM-AM layered Approach • ABC core models for UCON

  32. Prior Work • Problem-specific enhancement to traditional access control • Digital Rights Management (DRM) • mainly focus on intellectual property rights protection. • Architecture and Mechanism level studies, Functional specification languages – Lack of access control model • Trust Management • Authorization for strangers’ access based on credentials

  33. Prior Work • Incrementally enhanced models • Provisional authorization [Kudo & Hada, 2000] • EACL [Ryutov & Neuman, 2001] • Task-based Access Control [Thomas & Sandhu, 1997] • Ponder [Damianou et al., 2001]

  34. Usage Control (UCON) Coverage • Protection Objectives • Sensitive information protection • IPR protection • Privacy protection • Protection Architectures • Server-side reference monitor • Client-side reference monitor • SRM & CRM

  35. Building ABC Models • Continuity • Decision can be made during usage for continuous enforcement • Mutability • Attributes can be updated as side-effects of subjects’ actions

  36. Examples • Long-distance phone (pre-authorization with post-update) • Pre-paid phone card (ongoing-authorization with ongoing-update) • Pay-per-view (pre-authorization with pre-updates) • Click Ad within every 30 minutes (ongoing-obligation with ongoing-updates) • Business Hour (pre-/ongoing-condition)

  37. Beyond the ABC Core Models

  38. UCON Architectures • We narrow down our focus so we can discuss in detail how UCON can be realized in architecture level • Sensitive information protection X CRM • First systematic study for generalized security architectures for digital information dissemination • Architectures can be extended to include payment function

  39. Three Factors of Security Architectures • Virtual Machine (VM) • runs on top of vulnerable computing environment and has control functions • Control Set (CS) • A list of access rights and usage rules • Fixed,embedded, and external control set • Distribution Style • Message Push (MP),External Repository (ER) style

  40. Architecture Taxonomy VM: Virtual Machine CS: Control Set MP: Message Push ER: External Repository NC1: No control architecture w/ MP NC2: No control architecture w/ ER FC1: Fixed control architecture w/ MP FC2: Fixed control architecture w/ ER EC1: Embedded control architecture w/ MP EC2: Embedded control architecture w/ ER XC1: External control architecture w/ MP XC2: External control architecture w/ ER

  41. Conclusion • Perspective on security • Role Based Access Control (RBAC) • Objective Model-Architecture Mechanism (OM-AM) Framework • Usage Control (UCON) • Discussion

  42. Radical Shifts: get real Focus on • what needs to be done rather than how it is to be done • real-word business requirements rather than hypothetical academic scenarios • the 80% problem rather than the 120% problem • soft and informal rather than hard and formal • constructing the policy rather than auditing the policy • constructive safety via policy articulation and evolution rather than post-facto algorithmic safety • ordinary consumers as end-users and administrators rather than techno-geeks or math-geeks

More Related