Purpose-based access control: Putting data access requests into context

Access control is the heart of data protection. Striking the right balance between easy access and tight security isn’t easy, but getting it right is how you maintain business agility while still meeting regulatory and fiduciary data protection responsibilities.

Role-based access control

The runaway favorite access control framework relies on user roles – for a few good reasons. Role-based access control (RBAC) is a simple, understandable approach to making data access permit/deny decisions.

In the financial sector, for example, SEC regulations prohibit trading based on insider data. Complex financial services organizations often employ client services teams (with access to pre-public financial information) and traders who cannot legally access that information. Role-based access controls keep those with trading roles from accessing private or pre-public information. There are many more examples of this approach across a variety of industries:

• Only physicians or other clinical staff have access to sensitive medical records
• In education, access to student transcripts is limited to the registrar’s office
• High-tech firms protect intellectual property by restricting access to the engineering team

An effective RBAC system can also support hierarchies that provide more sophisticated control while easing the administrative burden by allowing for governance at the group level. Directory services, popular sources for information about an individual’s assigned roles, typically offer support for role hierarchies. Also used to provide broader access to senior personnel, hierarchies make RBAC simpler to manage and maintain.

But RBAC has some notable weaknesses. Roles are not always the best proxies for access, and exceptions to the rules the IT team creates can bring about unexpected management overhead.

For example, one of Concentric’s customers in the financial services sector recently decided to tighten up their RBAC solution by using roles for limiting sensitive client information access to their client engagement group. They quickly discovered how many other functional teams used this information for legitimate business purposes. Their contract negotiation teams often needed access to prepare quotes for new business, and accounts receivable needed access for accurate billing based on performance-related contract terms. They were forced to fall back to a less aggressive model for access control. It was a real-world example of how InfoSec professionals can struggle to optimize the balance between access and business agility, especially when it is based on roles.

That gives an RBAC framework inertia when responding to dynamic business requirements. Roles are slow to change and often don’t reflect actual needs for data access. In a healthcare setting, patients come and go, and clinical teams constantly form and reform. An RBAC system that grants PHI access to anyone with the role of “Physician” isn’t very granular, and it’s an open invitation for abuse (even physicians get curious about the medical status of celebrity guests). Creating new dynamic roles based on current care groups would improve the situation – but it would also create an unstainable maintenance burden.

Purpose-based access control

A more modern approach to data security, called purpose-based access control (PBAC), aims to overcome the limitations of RBAC. PBAC evaluates each data access request in the context of the purpose of the request. For example, a financial aid officer at a university can access academic records to verify eligibility for financial assistance; but access can be denied to a doctor who is not on a patient’s care team. It’s a powerful way to solve the agility problem without compromising security.

PBAC relies on three critical elements for accurate permit/deny decisions: role, purpose, and the nature of data in use. An in-the-moment awareness of all three factors enables robust access control without blocking valid and necessary access to information.

Of these elements, information about roles is already available from most IT estates, and information about the purpose of an access request, on the other hand, is not.

PBAC implementations fill that gap by taking cues from enhanced authentication models to add additional verification hoops under certain conditions. For PBAC, those hoops can include a request that users justify why they need access to sensitive data. For example, an employee in accounts payable at a financial services firm may need to confirm access to private client information is needed to prepare an invoice. Such a model provides users actionable information and accountability while providing an audit trail.

Data insights are another essential element of any successful PBAC program. Without understanding the nature and context of the accessed data, it’s impossible to apply PBAC to access requests. Fortunately, new deep learning-based solutions automate the data discovery and categorization process. With granular, accurate information about content and sensitivity, InfoSec professionals can craft PBAC frameworks that focus on the most sensitive and at-risk data at the right time.