The document presents a project design for extending Accumulo to support Attribute-Based Access Control (ABAC) using XACML, aiming for minimal code changes and compatibility with existing cell-based access control. It highlights the strategic importance of ABAC in various governmental and enterprise contexts, discusses the integration and architecture of XACML, and provides use cases to elaborate on policy enforcement scenarios. The initiative seeks to enhance security, including risk-based access controls, while building community support around open-source solutions.

1. Accumulo Summit 2015
2015.04.29
Gurcan Gercek
gurcan@deveralogic.com
Extending Accumulo to
Support ABAC using XACML

2. • 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

3. • 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

4. Accumulo’s Cell Based Access Control
4
Audit, Finance (Audit & Finance)

5. 5

6. • 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. 7

8. 8

9. 9
- User Attributes
- LDAP
- Data Attributes
- Visibility Field Content
- Other Fields of Key:
RowId, ColF, ColQ, TS

10. 10

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

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

14. • 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. 15

16. • 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. 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. 18
• PAP: Policy Administration Point
• PRP: Policy Retrieval Point
• PIP: Policy Information Point
• PDP: Policy Decision Point
• PEP: Policy Enforcement Point
XACML Architecture

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

20. • 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

21. • 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

22. Policy: OnlyDoctorsCanRead – FirstApplicable
Target: DATA_CLASSIFICATION matches RESPONSIBLE_DOCTOR_ONLY
Rule: AllowAssignedDoctorOnly – Permit
Target: IS_PATIENTS_DOCTOR matches TRUE
Rule: DenyEverythingElse – Deny
Target: Any
Use Case: As implemented in Devera Logic PAP
22

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

24. PIP Implementation: IS_PATIENTS_DOCTOR
24

25. 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. 26
• By using Accumulo Shell
> setauths -s {DOCTOR_ID:23245} -u jim
Use Case: Assigning User Attributes

27. • 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

28. • Open source
• Build Community
▫ gurcan@deveralogic.com
▫ info@deveralogic.com
Next Steps
28

29. 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. 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. 31
Policy Definition:
Policy: In_Office_Policy - First applicable
Target: Location regexp-match Office_[0-9] [0-9] [0-9]
and Role matches Broker
and isCustomersBroker matches True
Rule: Allow_During_Wek_Day – Permit
Target: 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 – Deny
Target: any
Use Case: As implemented in Devera Logic PAP

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