1 / 47

SECURING CYBERSPACE: THE OM-AM, RBAC AND PKI ROADMAP

SECURING CYBERSPACE: THE OM-AM, RBAC AND PKI ROADMAP. Prof. Ravi Sandhu Laboratory for Information Security Technology George Mason University sandhu@gmu.edu www.list.gmu.edu. INTERNET INSECURITY. Internet insecurity spreads at Internet speed Morris worm of 1987

august-elliott
Download Presentation

SECURING CYBERSPACE: THE OM-AM, RBAC AND PKI ROADMAP

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. SECURING CYBERSPACE: THE OM-AM, RBAC AND PKI ROADMAP Prof. Ravi Sandhu Laboratory for Information Security Technology George Mason University sandhu@gmu.edu www.list.gmu.edu

  2. INTERNET INSECURITY • Internet insecurity spreads at Internet speed • Morris worm of 1987 • Password sniffing attacks in 1994 • IP spoofing attacks in 1995 • Denial of service attacks in 1996 • Email borne viruses 1999 • Distributed denial of service attacks 2000 • Internet insecurity grows at super-Internet speed • security incidents are growing faster than the Internet (which has roughly doubled every year since 1988)

  3. INTERNET INSECURITY • Its only going to get worse

  4. INTERNET SECURITY • There are no clear cut boundaries in modern cyberspace • AOL-Microsoft instant messaging war of 1999 • Hotmail password bypass of 1999 • Ticketmaster deep web links • ebay versus auction aggregators

  5. SECURITY OBJECTIVES CONFIDENTIALITY disclosure INTEGRITY modification AVAILABILITY access USAGE-CONTROL purpose

  6. AUTHORIZATION, TRUST AND RISK • Information security is fundamentally about managing • authorization and • trust so as to manage risk

  7. SECURITY DOCTRINE • Prevent • Detect • Correct • Accept

  8. SECURITY DOCTRINE • absolute security is impossible does not mean absolute insecurity is acceptable • security is a journey not a destination

  9. SOLUTIONS • OM-AM • RBAC • PKI • and others

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

  11. LAYERS AND LAYERS • Multics rings • Layered abstractions • Waterfall model • Network protocol stacks • OM-AM

  12. 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

  13. 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

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

  15. ROLE-BASED ACCESS CONTROL (RBAC) • A user’s permissions are determined by the user’s roles • rather than identity or clearance • roles can encode arbitrary attributes • multi-faceted • ranges from very simple to very sophisticated

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

  17. RBAC96IEEE Computer Feb. 1996 • Policy neutral • can be configured to do MAC • roles simulate clearances (ESORICS 96) • can be configured to do DAC • roles simulate identity (RBAC98)

  18. RBAC1 ROLE HIERARCHIES RBAC2 CONSTRAINTS RBAC96 FAMILY OF MODELS RBAC3 ROLE HIERARCHIES + CONSTRAINTS RBAC0 BASIC RBAC

  19. USER-ROLE ASSIGNMENT PERMISSION-ROLE ASSIGNMENT USERS ROLES PERMISSIONS ... SESSIONS RBAC0

  20. ... RBAC1 ROLE HIERARCHIES USER-ROLE ASSIGNMENT PERMISSION-ROLE ASSIGNMENT USERS ROLES PERMISSIONS SESSIONS

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

  22. Supervising Engineer Hardware Engineer Software Engineer Engineer HIERARCHICAL ROLES

  23. Hardware Engineer’ Software Engineer’ Supervising Engineer Hardware Engineer Software Engineer Engineer PRIVATE ROLES

  24. EXAMPLE ROLE HIERARCHY Director (DIR) Project Lead 1 (PL1) Project Lead 2 (PL2) Production 1 (P1) Quality 1 (Q1) Production 2 (P2) Quality 2 (Q2) Engineer 1 (E1) Engineer 2 (E2) Engineering Department (ED) PROJECT 1 PROJECT 2 Employee (E)

  25. EXAMPLE ROLE HIERARCHY Project Lead 1 (PL1) Project Lead 2 (PL2) Production 1 (P1) Quality 1 (Q1) Production 2 (P2) Quality 2 (Q2) Engineer 1 (E1) Engineer 2 (E2) Engineering Department (ED) PROJECT 1 PROJECT 2 Employee (E)

  26. EXAMPLE ROLE HIERARCHY Director (DIR) Project Lead 1 (PL1) Project Lead 2 (PL2) Production 1 (P1) Quality 1 (Q1) Production 2 (P2) Quality 2 (Q2) Engineer 1 (E1) Engineer 2 (E2) PROJECT 1 PROJECT 2

  27. EXAMPLE ROLE HIERARCHY Project Lead 1 (PL1) Project Lead 2 (PL2) Production 1 (P1) Quality 1 (Q1) Production 2 (P2) Quality 2 (Q2) Engineer 1 (E1) Engineer 2 (E2) PROJECT 1 PROJECT 2

  28. ... RBAC3 ROLE HIERARCHIES USER-ROLE ASSIGNMENT PERMISSIONS-ROLE ASSIGNMENT USERS ROLES PERMISSIONS SESSIONS CONSTRAINTS

  29. CONSTRAINTS • Mutually Exclusive Roles • Static: The same individual can never hold both roles • Dynamic: The same individual can never activate both roles in the same context • Mutually Exclusive Permissions • Cardinality Constraints on User-Role Assignment • Cardinality Constraints on Permissions-Role Assignment

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

  31. CLIENT-SERVERSERVER-PULL ARCHITECTURE Client Server Authorization Server Authentication Server

  32. CLIENT-SERVER USER-PULL ARCHITECTURE Client Server Authorization Server Authentication Server

  33. CLIENT-SERVER PROXY OR THREE-TIER Client Authorization Server Server Authentication Server

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

  35. Related Mechanisms • Cookies • in widespread current use for maintaining state of HTTP • becoming a standard • not secure • Public-Key Certificates (X.509) • support security on the Web based on PKI • standard • simply, bind users to keys • have the ability to be extended

  36. Cookies

  37. Security Threats to Cookies • Cookies are not secure • No authentication • No integrity • No confidentiality • can be easily attacked by • Network Security Threats • End-System Threats • Cookie Harvesting Threats

  38. How to Use Secure Cookies

  39. Secure Cookies on the Web

  40. Applications of Secure Cookies • User Authentication • Electronic Transaction • Pay-Per-Access • Attribute-based Access Control

  41. X.509 Certificate • Digitally signed by a certificate authority • to confirm the information in the certificate belongs to the holder of the corresponding private key • Contents • version, serial number, subject, validity period, issuer, optional fields (v2) • subject’s public key and algorithm info. • extension fields (v3) • digital signature of CA • Binding users to keys • Certificate Revocation List (CRL)

  42. X.509 Certificate

  43. Smart Certificates • Short-Lived Lifetime • More secure • typical validity period for X.509 is months (years) • the longer-lived certificates have a higher probability of being attacked • users may leave copies of the corresponding keys behind • No Certificate Revocation List (CRL) • supports simple and less expensive PKI

  44. Smart Certificates • Containing Attributes Securely • Web servers can use secure attributes for their purposes • Each authority has independent control on the corresponding information • basic certificate (containing identity information) • each attribute can be added, changed, revoked, or re-issued by the appropriate authority • e.g., role, credit card number, clearance, etc.

  45. Applications of Smart Certificates • Very similar to applications of secure cookies

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

  47. INTERNET INSECURITY • Its only going to get worse • But security is a fun and profitable business and will get more so

More Related