Most modern environments today handle large amounts of data. Typically the data is spread across different data sources such as relational databases or even a big data system or data lake. And within these massive data stores, therein lies data that is very sensitive and critical to protect.
There is a growing body of regulatory compliance regimes in play that direct the control of sensitive data, especially Personally Identifiable Information (PII). Some examples are HIPAA, GDPR and PCI – as well as evolving local privacy laws such as the California Consumer Privacy Act of 2018, A breach of privacy regulations can be costly for an organization both financially and from a reputation perspective.
In addition to protecting individuals’ privacy, it also makes sense to safeguard sensitive data for business and competitive purposes, such as internal financial data, product development data and so on.
Applying runtime policy-based authorization to control access to the data and being able to mask or redact the data would solve a lot of the headaches related to these use cases and regulations. Being able to dynamically control when to mask or redact information based on information about the user, the data and the context allows for an extremely powerful solution.
“Dynamic Data Masking” is defined by Gartner as, “a technology that aims for real-time data masking of data. DDM changes the data stream so that the data requester does not get access to the sensitive data, while no changes to the original production data take place.” As an aside, Axiomatics was named as a sample vendor in this category. With dynamic data masking, sensitive data is obscured or obfuscated in some way to render it ‘safe’ and “dynamic” data masking means that data is changed at the time it is requested.
As part of a policy-based approach to protecting the contents of databases and data stores, dynamic data masking is invaluable to ensuring PII is obscured from view, and helping enterprises meet privacy laws globally and in unique jurisdictions.
One way to handle this would be to retrieve all the data that is requested and have the application or client handle the masking/redaction. However, in such a scenario the data has already been “leaked” to the application and several additional threat vectors would be open.
A better approach is to handle this at runtime where the masking/redaction happens at the time the data is being retrieved. This can be achieved by applying a fine-grained policy that controls exactly how data can be accessed and when to mask/redact. The policy in combination with attribute information results in filters that can be applied directly to the data request (to a SQL query for example).
Let’s take a look at how this works with dynamic authorization. This is what a policy handling access to financial transactions could look like using the ALFA syntax.
/*Access to TRANSACTIONS (ADAF) */
target clause table_name == "TRANSACTIONS"
/*Policy for viewing transactions */
target clause action_id == "SELECT"
/*Deny if the transaction is approved */
target clause transaction.status == "approved"
/*Deny access to the amount field if the user is not the owner */
target clause column_name == "AMOUNT"
condition not(stringOneAndOnly(transaction.owner) == stringOneAndOnly(user.userId))
/*Mask the credit card number */
target clause column_name == "CREDITCARD"
/*Managers can view all transactions */
target clause user.role == "manager"
/*Tellers can access transactions in their own region */
target clause user.role == "teller"
condition stringOneAndOnly(transaction.region) == stringOneAndOnly(user.region)
/*Users can view their own transactions */
condition stringOneAndOnly(transaction.owner) == stringOneAndOnly(user.userId)
/* Policy for approving transactions */
target clause action_id == "approve"
/*Tellers can approve transactions in their own region for transactions they do not own and
* where the tellers approval limit is greater than or equal to the amount of the transaction */
target clause user.role == "teller"
condition stringOneAndOnly(transaction.region) == stringOneAndOnly(user.region) &&
user.approvalLimit >= transaction.amount
Analyzing this we can see that the policy
- Is written for the table TRANSACTIONS and when you are performing a SELECT query.
- There are six rules that apply different authorizations
- Filter approved transactions, i.e. they will not be returned as part of the result
- Mask the amount filed if the user is not the owner of the transaction
- Always mask the credit card number
- Allow managers to view all transactions. Note that filtering approved transactions and the masking takes precedent here and will be applied regardless of the user.
- A teller can only view transactions in their own region
- And other users can view transactions that they own
In addition there is also a policy controlling who can approve a transaction
- Tellers can approve transactions
- In their own region
- That they do not own
- Where their approval limit is greater than or equal to the amount of the transactions
If we run a query to get all the transactions from the data source as the user Alice who is a manager in the Sales department, the result is that we see both transactions that Alice owns and does not own. The amount field is masked/redacted for the transactions she does not own.
If we instead run the query as Bob who is an employee in Sales, the result is different. Now only transactions that Bob owns show up. Still, the credit card number is masked.
As a reference, this is the raw data that is stored in the database with no filtering or masking enabled.
As you can see, using Dynamic Data Masking with dynamic authorization provides a powerful way to manage PII and ensure the right data is shared only under the right conditions. This mechanism applies to all applications accessing the data out of the data store and as such scales across the entire organization. If you’d like to learn more about using this for your organization, request a demo here.