SECURING CYBERSPACE: THE OM-AM, RBAC AND PKI ROADMAP Prof. Ravi Sandhu Laboratory for Information Security Technology George Mason University [email protected]

SECURING CYBERSPACE:THE OM-AM, RBAC AND PKI

ROADMAP

Prof. Ravi SandhuLaboratory for Information Security Technology

George Mason University

[email protected]

www.list.gmu.edu

2© Ravi Sandhu 2000

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)


INTERNET INSECURITY

Its only going to get worse


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


SECURITY OBJECTIVES

INTEGRITYmodification

AVAILABILITYaccess

CONFIDENTIALITYdisclosure

USAGE-CONTROLpurpose


AUTHORIZATION, TRUST AND RISK

Information security is fundamentally about managing authorization and trust

so as to manage risk


SECURITY DOCTRINE

Prevent Detect Correct Accept


SECURITY DOCTRINE

absolute security is impossible does not mean absolute insecurity is acceptable

security is a journey not a destination


SOLUTIONS

OM-AM RBAC PKI and others


THE OM-AM WAY

Objectives

Model

Architecture

Mechanism

What?

How?

Assurance


LAYERS AND LAYERS

Multics rings Layered abstractions Waterfall model Network protocol stacks OM-AM


OM-AM AND MANDATORY ACCESS CONTROL (MAC)

What?

How?

No information leakage

Lattices (Bell-LaPadula)

Security kernel

Security labels

Assurance


OM-AM AND DISCRETIONARY ACCESS CONTROL (DAC)

What?

How?

Owner-based discretion

numerous

numerous

ACLs, Capabilities, etc

Assurance


OM-AM AND ROLE-BASED ACCESS CONTROL (RBAC)

What?

How?

Policy neutral

RBAC96

user-pull, server-pull, etc.

certificates, tickets, PACs, etc.

Assurance


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


RBAC SECURITY PRINCIPLES

least privilege separation of duties separation of administration and

access abstract operations


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)


RBAC96 FAMILY OF MODELS

RBAC0BASIC RBAC

RBAC3ROLE HIERARCHIES +

CONSTRAINTS

RBAC1ROLE

HIERARCHIES

RBAC2CONSTRAINTS


RBAC0

ROLES

USER-ROLEASSIGNMENT

PERMISSION-ROLEASSIGNMENT

USERS PERMISSIONS

... SESSIONS


RBAC1

ROLES

USER-ROLEASSIGNMENT

PERMISSION-ROLEASSIGNMENT

USERS PERMISSIONS

... SESSIONS

ROLE HIERARCHIES


HIERARCHICAL ROLES

Health-Care Provider

Physician

Primary-CarePhysician

SpecialistPhysician


HIERARCHICAL ROLES

Engineer

HardwareEngineer

SoftwareEngineer

SupervisingEngineer


PRIVATE ROLES

Engineer

HardwareEngineer

SoftwareEngineer

SupervisingEngineer

HardwareEngineer’

SoftwareEngineer’


EXAMPLE ROLE HIERARCHY

Employee (E)

Engineering Department (ED)

Project Lead 1(PL1)

Engineer 1(E1)

Production 1(P1)

Quality 1(Q1)

Director (DIR)

Project Lead 2(PL2)

Engineer 2(E2)

Production 2(P2)

Quality 2(Q2)

PROJECT 2PROJECT 1



Employee (E)

Engineering Department (ED)

Project Lead 1(PL1)

Engineer 1(E1)

Production 1(P1)

Quality 1(Q1)

Project Lead 2(PL2)

Engineer 2(E2)

Production 2(P2)

Quality 2(Q2)

PROJECT 2PROJECT 1



Project Lead 1(PL1)

Engineer 1(E1)

Production 1(P1)

Quality 1(Q1)

Director (DIR)

Project Lead 2(PL2)

Engineer 2(E2)

Production 2(P2)

Quality 2(Q2)

PROJECT 2PROJECT 1



Project Lead 1(PL1)

Engineer 1(E1)

Production 1(P1)

Quality 1(Q1)

Project Lead 2(PL2)

Engineer 2(E2)

Production 2(P2)

Quality 2(Q2)

PROJECT 2PROJECT 1


RBAC3

ROLES

USER-ROLEASSIGNMENT

PERMISSIONS-ROLEASSIGNMENT

USERS PERMISSIONS

... SESSIONS

ROLE HIERARCHIES

CONSTRAINTS


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



What?

How?

Policy neutral

RBAC96



Assurance


CLIENT-SERVERSERVER-PULL ARCHITECTURE

Client Server

AuthorizationServer

AuthenticationServer


CLIENT-SERVER USER-PULL ARCHITECTURE

Client Server

AuthorizationServer



CLIENT-SERVER PROXY OR THREE-TIER

Client ServerAuthorization

Server




What?

How?

Policy neutral

RBAC96



Assurance


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


Cookies


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


How to Use Secure Cookies


Secure Cookies on the Web


Applications of Secure Cookies

User Authentication Electronic Transaction Pay-Per-Access Attribute-based Access Control


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)


X.509 Certificate


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


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.


Applications of Smart Certificates

Very similar to applications of secure cookies


THE OM-AM WAY

Objectives

Model

Architecture

Mechanism

What?

How?

Assurance


INTERNET INSECURITY

Its only going to get worse But security is a fun and profitable

business and will get more so

Documents

SECURING CYBERSPACE: THE OM-AM, RBAC AND PKI ROADMAP Prof. Ravi Sandhu Laboratory for Information Security Technology George Mason University [email protected]