Talk Abstract Cell based Access Control (CBAC) in Accumulo is a powerful and flexible feature, but it has drawbacks for addressing complex access control requirements. Security architects are unable to include data types, range operators, exceptions, or environment variables to policies for dynamic access control evaluations. It is possible to solve the complex AC requirements by implementing the AC mechanism on application layer, but this approach has its own drawbacks as well. Developing another layer of AC will create an overhead both for the system design and performance. In this talk, we present our mechanism to extend Accumulo’s Security Labels to include Attributes and XACML. This allows significantly increased Access control policy expressivity, improved policy administration, and the opportunity to implement access control models such as Attribute-based (ABAC) and Risk-Adaptable Access Control (RAdAC) in Accumulo. We will also discuss combining Accumulo's and our AC approaches to increase the capabilities of Accumulo even further. Introducing different types of attributes can be used to achieve both finer-grained and coarser-grained control over data according to access control requirements. For instance environment attributes can be used to limit access of a cell to a specific location of client whereas system specific information such as namespace/table/column can be used to simplify (or complicate) the policies. Speaker Gurcan Gercek Senior Software Developer, Devera Logic Gurcan Gercek is a Senior Software Developer at Deveralogic and a PhD Computer Science candidate researching access control in big data environments at Dalhousie University in Halifax, Nova Scotia. Gurcan is also the Lead Developer of the open source MalwareZ project at the Honeypot Project, a leading security research organization based in Ann Arbor, Michigan. Gurcan is a BSc and MSc graduate of Computer Engineering from the Izmir Institute of Technology, in Turkey, and trained in network security at the European Commission's Science Service Joint Research Centre in Ispra, Italy.

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