PingDataGovernance

How Fine-grained Authorization Addresses Data Privacy and Security in an Age of Increasing Regulatory Pressure

Read Time: 13 minutes

Introduction

For a long time, security was primarily focused on controlling access to applications. Developers built authentication logic into their applications via simple HTML authentication dialogues, looked up the user in whatever user directory or database that was in use, and then decided what the user was allowed to do.

Over time, authentication and authorization decisions generally moved to web access management systems (WAM) such as PingAccess. These systems provided organizations with a centrally managed control plane for applications, ensuring enterprise-wide compliance with organizational security policies and providing vastly improved audit capabilities. With only a few exceptions, like PCI and HIPAA, the concern over access to data occurred mainly at the application and development team levels, with each team determining or implementing its own data policies.

Then, the General Data Protection Regulation (GDPR) came along and changed all of that. GDPR was the first generally applicable data privacy regulation that required both companies and SaaS providers to address the following questions on a consistent and enterprise-wide basis:

What data is considered to be personally identifiable information (PII)?
How is the data collected?
Where is it stored?
How long is it retained?
Is there any way to delete it if requested?

A slew of privacy-focused regulations followed shortly after GDPR, including CCPA, NJ S2834 and the U.S. Data Care Act to name a few. But that was only the beginning. Next came regulations to secure democratization of valuable consumer financial data, like PSD2, Open Banking and various other open banking initiatives in the UK, Australia, Hong Kong and more.

These regulations, combined with digital transformation initiatives and API security standards, are causing global enterprises to think about their customer data in new ways and find answers to questions like:

How could the data be exposed securely to third-party entities in a controlled manner?
How can the enterprise be transparent about what data is being shared and why?
How could users grant fine-grained consent over data they want exposed?
How could the consent be enforced to actually control the dispersion of data?

The consumers themselves are also paying close attention to how these issues are being addressed. We’ve seen a number of high-profile data exposures and breaches, and we’ve had the unfortunate revelation that companies were disclosing—or, in some cases, selling—customer data without the customer’s knowledge. This has made customers wary about where their data is being collected and how it’s being used.

The impact of all these regulations and changing customer expectations is causing companies to focus intently on privacy, consent and compliance. But while these problems are pressing, the solutions are rarely simple.

Governing access to data is increasingly complex for a global enterprise. In addition to complying with data protection regulations and higher customer expectations, they also have internal obstacles to overcome—like the security teams, database administrators, API developers and business units that rely on customer data and consider themselves the authority on how it’s managed and by whom.

Yet, with challenge also comes opportunity. Consent can be leveraged as a mechanism for building consumer trust, and a balance can be struck between personalization and privacy.

Enterprises that are transparent about the data they would like to collect and why, and who give consumers an easy way to manage their privacy preferences, are positioned to take the lead. Furthermore, user data, once a loosely monitored byproduct of service and application offerings, can create competitive advantage when managed properly.

Controlling Data

When we combine the notion of data as a strategic asset with the need to comply with data privacy regulations and provide transparency and consent, it becomes apparent that a consistent enterprise-wide solution for controlling data is needed.

Similar to the evolution of WAM, we must move away from control on an application-by-application basis in favor of an enterprise-wide control plane. We want to move toward a centralized, fine-grained data authorization and access control system, or put another way, a single, central control plane for data.

An enterprise-wide solution needs to provide dynamic, policy-based, fine-grained access controls for attribute-by-attribute data protection, as well as filtering for privacy, regulatory compliance and consent management. Providing these capabilities and more, PingDataGovernance provides a graphical user interface for business users to collaboratively build, test and enforce access control policies to data across user directories and APIs.

Able to authorize, block, filter and obfuscate data request and response payloads in real time, PingDataGovernance solves the challenges of, and provides opportunities for, managing and enforcing customer data privacy.

In this model, policies can be based on any data attribute that can be looked up. These policies can be:

Developed and deployed on a per-application basis
Applied across all applications to ensure enterprise-wide compliance with internal company policies, as well as directives such as HIPAA or GDPR
Built to operate on the request or response data (as shown in Figure 1)
Set up to use data acquired from external data sources via REST APIs

Figure 1: Policies can be built to operate on the request or response data.

Policies can also be layered if desired. This allows an application’s owners to write and deploy policies in a bottom-up manner to best meet the needs of the application and eliminate a central security team as a bottleneck, while still having guardrail policies in place to ensure compliance with corporate data policies.

Figure 2 illustrates an example of an Open Banking compliance policy set in PingDataGovernance. Business users aren’t expected to build out a complete hierarchy of policy logic all by themselves. In the Trust Framework section of the user interface, development teams pre-build abstracted, lower-level policy conditions that reference attributes and external information sources. These pre-written condition statements are made available in the “toolbox” from which business security and compliance teams then easily build and visually test a set of policies. Building policies with abstractions written in plain English makes it a much simpler task.

Figure 2: Policies are written and deployed in a bottom-up manner.

Integrating With Existing API Gateways

With PingDataGovernance, policies are enforced at the API level, in production with major API lifecycle management gateways. Acting as a policy decision point (PDP) and policy enforcement point (PEP), PingDataGovernance is run in a sideband configuration with an API Gateway or Web Access Management Gateway. Policy information can be read from from various policy information points (PIP), such as user directories, databases and external REST-based APIs.

Figure 3: PingDataGovernance running in a sideband configuration with an API Gateway or Web Access Management Gateway.

Data-centric Use Cases

With these capabilities in mind, let’s look at some key data-centric concerns and use cases and dig deeper into how this approach can address them.

4.1

Data Privacy and Consent

Privacy and consent are two separate but closely related topics. Privacy is defined as “the state or condition of being free from being observed or disturbed by others.” Consent is an explicit step you take to grant specific applications or individuals the right to view or modify specific data belonging to you. It means that only people who have your consent or a legal right should be able to view or manipulate your data.

Note that in many cases the subject of the data does not have complete control over the use of the data. This is the case with medical records. The hospital (data holder) may give qualified parties (data recipient) access to the data without gaining consent from the patient (data owner), while other access may be controlled by patient consent.

Australia’s Consumer Data Right law is one of several undertakings that have recognized the complexity of these relationships and created clear definitions for each:

Data Owner: The person the data is about
Data Holder: The company that captures and holds the data
Data Recipient: Another company or individual that the data is being shared with

Modeling the relationships between the data holder, the data owner and data recipient(s) involves a complex set of factors that must be taken into account at the time the data is requested in order to assure that only the right people have access to the right data. To make these decisions, a combination of RBAC and ABAC must be applied.

RBAC

RBAC stands for role-based access control. With RBAC, users and services have one or more roles associated with their identity. These roles determine what resources can be accessed. While this works well for many access-related needs, it has limitations. For one, there is typically no mechanism to assign roles to actual resources and data.

The coarse-grained nature of this type of control also poses limitations. Consider the role of staff accountant. If you are in that role, does that mean you can see every financial document in the company? Probably not. We can add more roles in an attempt to define access, like UK_Accountant, but then we end up with a growing number of roles. This adds complexity when we need to define, assign and remove these roles in response to changes in personnel, organizational structure and types of resources.

ABAC

ABAC, or attribute-based access control, was designed to help overcome these shortcomings. ABAC provides dynamic, context-aware access control via attributes that can come from many different sources, rather than being limited to what are typically static scopes associated with an OAuth access token.

In ABAC, fine-grained policies can be written that base access decisions on literally any attribute that you can look up, such as attributes attached to the identity, the resource that is being accessed, third-party risk scores or the environment in which the request was made. Furthermore, the attributes can be single valued or in a structured form such as JWT, and they can have as many levels as needed to accurately describe the data.

In ABAC, fine-grained policies can be written that base access decisions on literally any attribute that you can look up.

When we combine RBAC and ABAC, we can achieve the privacy we are looking for. Roles will define long-lived, fairly static relationships to classes of data. For example, an auditor might be able to see all of a company’s financial records, but only have read access to them, not write or delete access.

For attributes, we might see data-centric attributes, such as specific user consent to view the data. Or we might see specific privacy attributes, such as the data being subject to a particular country’s data privacy law.

4.2

Delegation

Delegation is often used in a manner that is synonymous with consent, such as “James delegated access to a document to Sarah.” However, delegation is also the ability to authorize someone to do something as your representative or to entrust responsibility to someone to complete a task.

Delegation of Role

In our attribute-based access model the authority that was delegated to you can be stored as an identity-linked attribute that could contain the following information:

The role or specific data for which authority was delegated
The person who delegated this authority
The time period for which the delegation is active

This information will be used by the policy enforcement point to allow access to data that the user wouldn’t normally have access to.

As shown in Figure 4, James, the firewall administrator, is going on vacation for a week and needs to delegate his firewall admin role to Sarah, who doesn’t usually have that role or the access that comes with it.

Figure 4: How to delegate roles using the attribute-based access model.

Delegation of Tasks

Delegation of responsibility to complete a task can be expressed with an “assigned to” attribute linked to the data itself or data associated with a resource. A real-world example would be the assignment of individuals to help complete an RFP or to configure a new application in production.

Compliance and Defense in Depth (DiD)

Insuring compliance with data privacy and data sovereignty regulations can be complicated. Development teams should be educated on the different regulations that their applications and services will be subject to so that development is done with compliance in mind.

However, enterprise-wide compliance with all applicable regulations is ultimately the responsibility of the CISO or chief data privacy officer, not just the various development teams. If ensuring compliance with relevant regulations is a corporate priority, we advocate a defense in depth (DiD) strategy.

With a DiD strategy, there’s a combination of global and local policies. The global policies ensure compliance with enterprise-wide policies or regulations such as Open Banking, HIPAA or GDPR. These policies are often written by compliance teams or regulatory specialists.

These global policies relieve development teams of the burden of determining how to implement each policy and when it applies. These global policies also provide a central audit point instead of having to look at the logs for each microservice. The local services implement policies that are specific to that service, and in fact may invoke policies in PingDataGovernance as the policy decision point to decide what data to return to a caller or whether a given operation is permitted.

Figure 5: PingDataGovernance serves as the policy decision point to decide what data to return or whether a given operation is permitted.

In this scenario, the data access control plane serves two purposes. The first is to block calls that are clearly not permitted, such as returning banking account details to a third-party provider that the user had not granted consent to.

The other role is as a safeguard against bugs or security vulnerabilities in the applications behind the control plane. PingDataGovernance examines the data being returned by applications. If it sees data being returned that violates a policy, it will either block the response so no data is returned or it may selectively redact portions of the response that are in violation of policy, as shown in Figure 6.

Figure 6: If PingDataGovernance sees data being returned that violates a policy, it can selectively redact the portion of the response that violates the policy.

Conclusion

It used to be that having a deep understanding of how data is collected and used within an organization was reserved only for those in highly regulated industries. But today, few enterprises are immune to the growing number of regulations around data privacy and consent.

More than just challenges to overcome, though, the introduction of new regulations provides an opportunity to build consumer trust and loyalty for those who go beyond mere compliance. Augmenting existing access control and API management with PingDataGovernance as a data-centric control plane gives companies the functionality and flexibility they need to ensure that their goals around privacy, consent and compliance are met on a consistent, enterprise-wide level—so they can realize the competitive advantages to be gained.

#3474 | 12.10.2019 | v001