Transcript

Accumulo Summit 2015

2015.04.29

Gurcan Gercek

[email protected]

Extending Accumulo to Support ABAC using XACML

• Support the full expressivity of attribute based access controls (ABAC) using eXtensible Access Control Markup Language (XACML)

• Minimal change to current Accumulo source code

• Non-disruptive to production Accumulo implementations▫ Support simultaneous use of cell-based AC (CBAC) and XACML

▫ No performance impact on CBAC

▫ Support a controlled migration from CBAC to XACML

• Support conventional XACML open source, vendor and service provider community

Objectives of our Project

2

• ABAC vs RBAC▫ Centralized AC Policy: Easy to Change▫ Dynamic Policies Implementations

• ABAC is the strategic AC plan for:▫ Defense Information Systems Agency (DISA)▫ National Institute of Standards and Technology (NIST)▫ Federal Chief Information Officers Council (Federal CIO Council)▫ National Cybersecurity Center of Excellence (NCCoE)

• Gartner Research: ▫ by 2020, 70% of all enterprises will use ABAC

• Risk reduction for cyber security

Why ABAC?

3

Accumulo’s Cell Based Access Control

4

Audit, Finance (Audit & Finance)

5

• Characteristics of the users, cells, or environment conditions.

• Name-Value pairs

• Attributes must be enclosed by { }▫ {AttributeName:AttributeValue}

• Not replacing Security Labels

• Visibility Field of a cell contains either Attributes or Security Labels

Attributes: Extending Security Labels

6

User Security Labels User Attributes

Audit, Finance {Role:Audit}, {Department:Finance}

7

8

9

- User Attributes- LDAP

- Data Attributes- Visibility Field Content- Other Fields of Key:

RowId, ColF, ColQ, TS

10

11

3rd Party System Information- Snort Alerts -> Threat Level - Policy: Risk-based AC

- If Threat Level higher than MEDIUM deny all READ requests

- Cyber Incident Response Strategies

12

13

System Attributes(Work in progress)- Table Name- Namespace

• User Attributes

• Data Attributes (All Key Fields)

• External Attributes▫ Location, Time, 3rd party system alerts (Dynamic/Risk-based AC)

• System/Table Attributes (Work in progress)▫ Namespace, Table name, etc.

• Request Attributes▫ Providing extra information to access control process (OTP or Emergency Code)

▫ Not needed to be assigned to user by system administrator

▫ Will be handled with a different namespace/prefix to avoid name collision

Attribute Types

14

15

• Extending Access Control Mechanism

▫ Visibility Field: Attributes or Security Labels

▫ Using Attributes and Security Labels in the same system

▫ Adding XACML capabilities to Accumulo while keeping existing mechanism

• XACML Policies

▫ Policy definitions are shared over HDFS between nodes

Our Approach

16

17

• eXtensible Access Control Markup Language

• Defacto standard for ABAC

• Mature OASIS Standard

• Flexibility and Expressivity

• Administration Productivity

• Interoperability

• Open Source and Commercial vendors/support

Why XACML?

18

• PAP: Policy Administration Point

• PRP: Policy Retrieval Point

• PIP: Policy Information Point

• PDP: Policy Decision Point

• PEP: Policy Enforcement Point

XACML Architecture

19

• Adapting XACML architecture to Accumulo Architecture• Shared nothing principal▫ Decentralizing XACML architecture▫ Each tablet has its own PEP, PDP and PIP (part of the system iterator)▫ External communication may require for collecting external attributes

Caching for performance

• Plug-in Structure▫ Replaceable XACML Engine▫ First Implementation with Balana Project

Part of Open Source WSO2 Project

Accumulo and XACML Architecture

• Centralized policy administration• Commercial and open source implementations exist• Reduce the coding requirement for enforcing policies• Easy to implement PIP structure• Supporting complex access control policies▫ Privilege Elevation▫ Bypass Policies for special cases (such as emergency or incident)▫ Relational Constraints (team manager can see data of his/her team

members)▫ Take advantage of other key fields of cell for AC policies(rowid, colf, colq, ts)

Benefits of a XACML Plugin

20

• AC Requirement: ▫ Patient Data can be read only by his/her Doctor

• Assumption:▫ Relationship between doctor and patient stored in an external system

• User Attribute:▫ {DOCTOR_ID:435152434}

• Data Attribute: (In Visibility Field):▫ {DATA_CLASSIFICATION:RESPONSIBLE_DOCTOR_ONLY}

& {PATIENT_ID:123456789}

Use Case: Doctor Patient Confidentiality

21

Policy: OnlyDoctorsCanRead – FirstApplicableTarget: DATA_CLASSIFICATION matches RESPONSIBLE_DOCTOR_ONLY

Rule: AllowAssignedDoctorOnly – Permit

Target: IS_PATIENTS_DOCTOR matches TRUE

Rule: DenyEverythingElse – DenyTarget: Any

Use Case: As implemented in Devera Logic PAP

22

PIP Implementation: IS_PATIENTS_DOCTOR

23

• PDP asks PIP for attributes used in policy but not exists in request▫ External

▫ Derived Attributes

• @Attribute Annotation▫ Automatically registers annotated function for associated attribute

▫ Parameters: attributeId and attributeType

PIP Implementation: IS_PATIENTS_DOCTOR

24

25

• Passive Attribute Collection▫ If there is no API to query information

▫ Security Restrictions, e.g no incoming connection

▫ Async or Event based information generation IDS alerts or any other logging system

• PIP Collector REST API▫ Pushing external system information into local PIPs

▫ AttributeId, AttributeType, AttributeValue, indexValue, ApiKey and SecurityToken

Use Case: Implementing Attributes on PIP

26

• By using Accumulo Shell

> setauths -s {DOCTOR_ID:23245} -u jim

Use Case: Assigning User Attributes

• Testing, documentation and performance characterization

• Integrating Devera Logic PAP▫ Policy Governance

Organizational policy AC policy = technical AC policy implementation

▫ Policy Integrity AC policy conflict and omissions management

▫ Policy Performance Productive and scalable XACML

Current Work

27

• Open source

• Build Community▫ [email protected]

[email protected]

Next Steps

28

29

• AC Policy requirements▫ A customer's records should only be accessed by her broker.

▫ Her broker may change over the course of time.

▫ Her broker may only access her records during business hours.

▫ Her broker may only access her records while physically in an office.

Bonus Content: Use Case – Broker

30

• Possible Attribute

Use Case – Broker

Attribute Name Possible Values

ROLE CUSTOMER | BROKER

TIMEOFDAY [00:00:00, 23:59:59]

DAYOFWEEK MONDAY | TUESDAY | WEDNESDAY | THURSDAY | FRIDAY

| SATURDAY | SUNDAY

LOCATION OFFICE_XYZ | NOT_IN_OFFICE

IS_CUSTOMERS_BROKER True | False

BROKER_ID Any unique alphanumeric identifier

31

Policy Definition: Policy: In_Office_Policy - First applicable

Target: Location regexp-match Office_[0-9] [0-9] [0-9]and Role matches Brokerand isCustomersBroker matches True

Rule: Allow_During_Wek_Day – PermitTarget: DayOfTheWeek matches one of Monday, Tuesday, Wednesday, Thursday, Friday

Condition: TimeOfTheDay after or on 09:00:00 and TimeOfTheDay before or on 17:30:00

Rule: Deny_Other_Requests – DenyTarget: any

Use Case: As implemented in Devera Logic PAP

32

• By using Accumulo Shell

> setauths -s {ROLE:BROKER},{BROKER_ID:13213-4124-23245} -u jim

• To read the data simply call scan

> scan

Use Case: Assigning User Attributes


Top Related