SECURING%20CYBERSPACE:

1
SECURING CYBERSPACE THE OM-AM, RBAC AND PKI
ROADMAP
Prof. Ravi Sandhu Laboratory for Information
Security Technology George Mason
University sandhu_at_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
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
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
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 users permissions are determined by the users
  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
RBAC96 FAMILY OF MODELS
RBAC3 ROLE HIERARCHIES CONSTRAINTS
RBAC0 BASIC RBAC
19
RBAC0
20
RBAC1
ROLE HIERARCHIES
USER-ROLE ASSIGNMENT
PERMISSION-ROLE ASSIGNMENT
ROLES
USERS
PERMISSIONS
SESSIONS
21
HIERARCHICAL ROLES
Primary-Care Physician
Specialist Physician
Physician
Health-Care Provider
22
HIERARCHICAL ROLES
23
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 2
PROJECT 1
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 2
PROJECT 1
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 2
PROJECT 1
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 2
PROJECT 1
28
RBAC3
ROLE HIERARCHIES
USER-ROLE ASSIGNMENT
PERMISSIONS-ROLE ASSIGNMENT
ROLES
USERS
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
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
Server
Authorization Server
Authentication Server
34
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)
• subjects 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