Enabling Use Cases with ABAC (policy construction example diagram pictured: Active Court Cases)

Enabling Use Cases with ABAC

The number of use cases that can be enabled by attribute-based access controls are as many and as varied as the attributes themselves. I’ve collected and anonymized a number of different cases here to illustrate what becomes possible when policy becomes the new perimeter for protecting access to data and resources.


Deny Access to classified information if: A) Security token last badge location (Subject attribute); source: Security token / badge system; logic: Room associated with last badge location == room associated with device used to access data (device <> room association from device management system) 
// Policy Rule A subj:com.acme.badge_system.last_known_loc // user attr; dynamic string-equal-ignore-case subj:com.acme.badge_system.loc // device attribute; static B) Device Exfil Capability (Subject attribute (device)); source: Device management software; logic: Ensure that device has USB ports + CD/DVD drive disabled // Policy Rule B subj:com.acme.device_mgmt.exfil_cap // device attr; static string-equal-ignore-case string:none

A government organization employing special access program protocols wished to reduce risks of unauthorized building access and exfiltration of sensitive data. They used contextual attributes about physical security tokens to ensure that individuals could not be logged in simultaneously in one room and in another room across the hall. Since even the disabling of thumb drive ports doesn’t block an administrator with burn rights, they also tightly scoped the physical locations from which data could be accessed.


Allow Access to personal health information if: A) Employee Group (Subject attribute); source: Active Directory; logic: Group in (set of allowed groups)
// Policy Rule A subject:group-name // e.g. 2020/02/01 string-at-least-one-member-of string:$allowed_groups // hard-coded for this policy B) HIPAA training date (Subject attribute); source: Training system; logic: Training date within last 6 months // Policy Rule B subject:com.acme.hippa_training_completed_date // e.g. 2020/02/01 date-greater-than add-yearMonthDuration(environment:current-dateTime,(0,-6))

A healthcare organization, expanding rapidly to meet growing needs, wanted to limit the access to personal health information to only those employees who had completed HIPAA training. They used the training system as the authoritative source of subject attributes; access could be granted as soon as training was passed, which dramatically decreased onboarding time. 


Allow Access to IP if: A) User Active Projects (list)(Subject attribute); source: Program Management system (updated daily); logic: Project in (active projects). Project comes from a data marking. // Policy Rule A subject:com.acme.project-mgmt.active-projects string-at-least-one-member-of data:com.acme.project-mgmt.allowed-project

A company with a large volume of intellectual property struggled with managing access on a project-by-project basis. They had little to no visibility about who had access to what IP, especially where it came to “temporary access” that was becoming a long-term liability. They reduced broad-based access by using assigned team members from a program management system, time-bounding temporary requests, and carefully auditing actual access attempts.


Allow Access to application (security level: baseline) if: A) Authentication level (Environmental Attribute); source: IdP; logic: Auth Level > min_auth_level (for data with certain attributes) // Policy Rule A environment:com.acme.idp.auth-level string-at-least-one-member-of list-string:$allowed_auth_levels // hard-coded for this policy B) System (Subject Attribute (For a device)); source: MDM (mobile device management) platforms; logic: MDM compliance score > threshold OR User risk score < threshold (e.g. Microsoft Security Graph) // Policy Rule B environment:com.acme.device-mgmt.risk-score double-less-than double:$max_risk // hard-coded for this policy C) Request Geolocation (Environmental Attribute); source: In allowed list of countries // Policy Rule C environment:location-country string-at-least-one-member-of list-string:$allowed_countries // hard-coded for this policy Allow Access to application (security level: sensitive) if: A) Authentication level (Environmental Attribute); source: IdP; logic: Auth Level > min_auth_level (for data with certain attributes) B) System (Subject Attribute (For a device)); source: MDM (mobile device management) platforms; logic: MDM compliance score > threshold OR User risk score < threshold (e.g. Microsoft Security Graph) C) Request Geolocation (Environmental Attribute); source: Ionic supplied, based on IP; logic: Allow only given IP range (only access from VPN, or office network) // Policy Rule C environment:ipAddress ipAddress-regexp-match string:$ip_regex // hard-coded for this policy

A technology company, pushed to rapidly expand their remote workforce capabilities, sought to minimize dependence on their VPN for all but very high security use cases. They used attributes about a user, their system, and location to manage and monitor access. Different levels of authentication–based on 1-factor, 2-factor, or a physical token–could be enforced for applications with different levels of security.


Allow Access to court case if: A) User Active Cases (list) (Subject attribute); source: Case management system; logic: Case in (active cases). Case comes from a data marking. // Policy Rule A subject:com.acme.case-mgmt.active-cases string-at-least-one-member-of data:com.acme.case-mgmt.allowed-cases B) System (Subject attribute (For a device)); source: Case management system; logic: MDM compliance score > threshold // Policy Rule B environment:com.acme.device-mgmt.risk-score double-less-than double:$max_risk // hard-coded for this policy C) Request Geolocation (Environmental attribute); source: Ionic supplied, based on IP; logic: In allowed list of networks // Policy Rule C environment:ipAddress ipAddress-regexp-match string:$ip_regex // hard-coded for this policy

A court system used to create a new role and data marking for every specific court case. They simplified this process drastically by matching subject attributes (identifying users working on a case) to data attributes (capturing case numbers). They further reduced risk with contextual attributes like preventing access outside of a particular network block or from unmanaged devices.


You should now have a sense for how policies are constructed, based on the visualizations above. Keep that process in mind as I share a few more use cases to help spark your creativity.


A package delivery service facing exponential demand needed to build defense-in-depth capabilities to address a highly fluid workforce. They used the conditional capabilities of attribute-based policy to limit access to customer data so that even if a user changing groups didn’t have a prior role removed, other conditions could prevent unauthorized access.

An application development team decided to improve the speed and security of their CI/CD pipeline. When a new build is launched, they use attributes about the process to determine what services and data it should now be able to access. 

A SaaS company, responding to multiple requests to beef up product security, realized it needed to help customers make different contextual access decisions to data within their application. They addressed security by adding contextual attributes to use in policy decision-making. Since ABAC looks and acts like code, writing automated QA-style tests sped the time to market and improved accuracy of the new controls.

An industrial plant generating copious amounts of IoT data from numerous operational technology systems wished to make claims system updates based on attributes gathered from multiple sources. To scope permission contexts, the security team used a series of binary questions such as: Is the user inside the physical building? Is a token present? Does this user have access to this specific part of the plant’s operations? Is the health of the accessing device within acceptable ranges?

A large financial services enterprise wanted to simplify the process of granting “quick access to X.” They chose to grant entitlements based on an event, where something becomes available just-in-time to a user or service. The goal of that event is not to explicitly grant permissions, but attributes identified about it can now trigger the next step in the workflow, opening access to the right set of users and services.

Two organizations participating in a deal room prior to a company merger had multiple constraints for segmenting, controlling, and reporting out on access to information. The attributes ranged from physical location to device health to project role to functional area, including members of the system integrator hired to facilitate the transition. They also needed to abstract complex access control logic into another layer that someone without coding expertise (e.g. a non-technical user in HR, legal, or audit) could easily write and dynamically implement access rules.

A large bank with an even larger supply chain sought a sustainable way to manage federated authorization to information used in multiple banking applications without pre-provisioning every potential developer into their own internal systems. They leveraged attributes about supply chain employees to grant and tightly monitor access. The carefully audited visibility reduced their risk and ultimately their risk insurance payments.


How could attribute-based access controls change your business? Contact us to diagram an ABAC use case to enable your business.

Part 5/7 ABAC Blog Series: Policy is the New Perimeter