Privilege Management & Attribute Based Access Control

Finn Frisch, CISM Axiomatics AB

Axiomatics in Brief
Focus on Entitlement Management Attribute Based Access Control Risk Intelligent Access Control

Research spin-off from the Swedish Institute of Computer Science

R&D team working since 2000 Company Axiomatics founded in 2006

Strong commitment to OASIS XACML TC

OASIS members since 2005 Axiomatics CTO is the editor for XACML 3.0 Products implementing XACML 2.0 and 3.0 Technology provider for some of the worlds largest XACML deployments

Todays Topic How Manage Privileges With ABAC

Privilege Management vs. Entitlement Management Potential Terminology Confusion Foundation Mapping People to Resources

The Access Matrix

Roles vs. Rules IAM & GRC Identity & Access Management (IAM)

Governance, Risk & Compliance Management (GRC)

Policy Based or Attribute Based Access Control (ABAC) Entitlement Management ABAC + GRC the Paradigm Shift An Attribute Management Framework

Entitlement vs. Privilege Management

Axiomatics definition of Entitlement Management Authorization Service
StandardsCompliant External to Applications FineGrained ContextAware

Managing Privileges or Permissions

Who should be granted access to which information assets where, when, how and why and how is it controlled?

The Access Matrix

Static, predefined and preconfigured mapping of user to resources

User Joe Anne

Res1 Res2 X X

Res3 X X

Res4 Res5 Res6 Res7 Res8 Res9 X X X X X

Robert Susan
Ian Mary Keith X X

X X X
X X X

X X X
X X X

X X
X X X X

X
X X X

Grouping Permissions
Grouping permissions to simplify administration

User Joe Anne

Res1 Res2 X X

Res3 X X

Res4 Res5 Res6 Res7 Res8 Res9 X X X X X

Robert Susan
Ian Mary Keith X X

X X X
X X

X X
X

X X
X X X

X
X

X
X X X X X X

The Role Concept

Grouping permissions Bottom-up Grouping job tasks, functions Top-Down But still: Static, predefined and preconfigured

Res1 Res2 X

Res3 X

Res4 Res5 Res6 Res7 Res8 Res9 X X X X X X X X X X X X X X X X X

X
X X X X X X

X
X X X X

Static, predefined and preconfigured

Enforcing Segregation of Duties (SoD)

An example

SoD Within ERP Gartner Hype Cycles 2005-2009

Visibility

2006

2009 2008 2007

2005 ?

Technology trigger

Peak of Inflated Expectations

Trough of Disillusionment

Slope of Enlightenment

Plateau of Productivity

Maturity

SoD Within ERP Gartner MarketScope 2006-2009

Business risks due to SoD conflicts

RBAC the Never Ending Sudoku

Users
1 Roles Permissions
Removing conflicting permissions from Role 1 and/or Role 2 may solve problem for user group 2 but create new problems for user group 1 and 3.

2 Role 1 Role 2

SoD violation

Cross-application SoD the Sudoku nightmare Application A

Application B

GrA1

GrA2

GrA3

GrB1

GrB2

GrB3 Role B2

Role A1

Role A2

Role B1

SoD violation

SoD violation

SoD violation

SoD and Communication Challenges

Business Manager We need to enforce SoD on functions that allow users to Create and Maintain Vendor Master Data while also being able to Create and Release Purchase Orders What? IT Manager

What?

Who should have access to transaction XD01?

SoD and Communication Challenges

Business Manager We need to enforce SoD on functions that allow users to Create and Maintain Vendor Master Data while also being able to Create and Release Purchase Orders IT Manager

Bottom Up Perspective
Who should have access to transaction XD01?

Top Down Perspective

IAM & GRC

Identity & Access Management Common Vision

Identity & Access Management Governance

Ordering user permissions in a structured process Create, Alter or Delete

Approval by authorized managers

User provisioning for deployment

Reporting for regular recertification and auditing

User Provisioning
Built on the assumption that privileges can be predefined and preconfigured as static mappings between users and their information assets!!

Rule Based Concepts

The paradigm shift standards based ABAC

XACML offers a generic standard for rules based on attributes of: Subject Action Resource

Environment

Policy-based / rules based access control is becoming a reality on a broad scale

Dynamic, real-time assignment of user privileges

User U can access resource R

Before Static mapping of User U to Resource R (with or without roles) U -----R After Rule example: IF (Us department=Rs department) THEN Permit else Deny

U.dept=xyz & R.dept=xyz Thus permit!

ABAC beyond RBAC

Role-Based Access Control Attribute-Based Access Control

UserRolePermissions

User + Action + Resource + Context

Role 1 Role 2 Role 3 Role 4

Subject A user Action wants to do something

Attributes Policies/Rules

Resource with an information asset

Context in a given context or environment

Examples: A medical doctor A banks client wants to open and edit wants to withdraw 300 a patients health record from an account in the hospitals emergency room at 3 p.m via an ATM machine in X city

XACML Technology Overview

XACML a standard for access control policies An abstract architecture A policy language, and A query-response protocol Developed within OASIS Current Version is 2.0 but Axiomatics also implements the 3.0 Working Draft to be approved in a near future adding Delegation of Administrative Privileges Broad support by the industry The only standard for access control policies

XACML Components and Architecture

Application 1
Policy Enforcement Point (PEP) Captures access requests in an application and expresses them in XACML using descriptive attributes Policy Decision Point (PDP) Responds to access requests based on XACML policies and rules - permit or deny

PEP

PDP

User A Application 2 Information assets/ Data

Policy Administration Point (PAP) Administration GUI for maintenance of policies Policy Information Point (PIP) Services providing additional information to help resolve an access request from a PEP in cases where complimentary data is needed

PAP

PIP

User B
XACML Request/ Response

AD LDAP (PIP)

Administration Point (PAP)

XACML Policy

Policy Repository

Administrator

ABAC and Governance?

Enforcing SoD? Approval workflows for privilege assignments? Reporting on actual user permissions? Certification procedures?

Permissions granted via ABAC

Policy / rule definitions (rarely updated)

Attribute values describing Subjects Resources Actions Environment (maintained in day-to-day operations)

Segregation of Duties RBAC vs. ABAC

RBAC ABAC
Signature

Drivers License

Users

Edit vendor master data

Approve payment

1
Roles

2
Role 1 Role 2

Manipulated vendors: 1) Fake company 2) My company 3) My cousins company

BILL
from Fake Corp.

Permissions Approve payments Edit vendor master data

SoD violation If action=approve resource=payment subject has a Drivers License then permit else deny

SoD violation

Context aware authorization

IF action=approve resource=payment payment.recipient not in subject.manipulated_vendors_list

THEN Permit else Deny

Edit vendor master data

SoD Enforcement

Approve payments

Approval banned
My manipulated vendors: 1) Company A 2) Company B

Approval permitted

X OK BILL

BILL
Mitigating controls built into a policy-based authorization system
from Company Z

from Company A

User Provisioning and ABAC

Secure authentication of subjects is a prerequisite for ABAC but outside the scope of ABAC itself ABAC relies on robust Identity Management for attribute lookup No provisioning can be made to the rules engine itself
Application 1

User A Application 2 Information assets/ Data

User B
XACML Request/ Response

Administration Point (PAP)

AD LDAP (PIP)

XACML Policy

Administrator

Policy Repository

Attribute Management Framework

New foundation: Attribute Management Framework

Conceptual solutin Best practices Methods Technology

PIP interface Attribute Management Framework Infrastructure with data sources

New foundation: Attribute Management Framework

Application 1 Administration Point (PAP)

AMF
User A Administrator

Data
Application 2
XACML Request/ Response

XACML Policy

Attrib Mgmt

Policy Repository Approval WF

User B

PIP interface Attribute Management Framework Infrastructure with data sources

Real-world scenarios
Customers already have an infrastructure Re-using SAP roles to manage access to document store Additional attributes about documents and users are needed SAP role management complies with corporate governance rules

Other attributes are being reused for a new purpose

Existing IAM-UP Governance
SAP Roles
HR Mgmt level Read-only AD Dept code Change-mgmt & QA: Logging updates for traceability Possible approval workflow before update is committed Authoritative source for attributes used by ABAC

AMF

PPM Project member

Other sources

Documents

An authoritative source for source attributes

Basically three types of attributes: New needed to express necessary rules Existing trusted attributes like SAP roles already used for authorizaation and maintained with solid governance

Existing but possibly not trusted attributes reused for authorization although they currently are being maintained for other purposes

Attribute Management Framework

Trusted and maintained imported Not trusted approval required New maintained within ABAC

Infrastructure with data sources

Questions?
Discussions? For more information, dont hesitate to contact me: finn.frisch@axiomatics.com