Accumulo Summit 2015
2015.04.29
Gurcan Gercek
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
• 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}
9
- User Attributes- LDAP
- Data Attributes- Visibility Field Content- Other Fields of Key:
RowId, ColF, ColQ, TS
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
• 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
• 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
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
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