A bank wants to outsource some analytics functions to an outside company. A military contractor wants to limit sensitive information to those at a certain pay grade. An HR department wants to run efficiently without leaking sensitive employee data. What all these cases have in common is a need to make certain bits of information available to those that need it—and to keep private all the rest.

These are just a few examples of business needs that can be addressed by Dynamic Data Masking (DDM). DDM is a relatively newer technology that allows for the masking of production data in real-time, as the data is requested. Sensitive information is selectively “hidden” from users based on geography, role, department, and so on. Organizations can specify which bits of sensitive data to reveal, and to whom, without any serious changes to the database of the application layer.

Perhaps the biggest advantage of dynamic data masking is its impact on performance—or rather, its lack of impact. DDM is widely preferred on production systems precisely because it does not introduce huge delays in data retrieval, if a database approach is taken (as opposed to using a proxy). It also does not require changing anything in application architecture, which can save on expensive and time-consuming release cycles.

Here, then, are some prime examples of DDM being used in organizations to maintain privacy and security. (Note that, for privacy reasons, we are presenting hypothetical cases that are merely based on customer circumstances. We have purposely left out any identifying information, of course.)

Offshoring Analytics Work for a U.S. Bank

A U.S.-based bank wants to find ways to control costs. As part of that effort, they decide to offshore some of their development and analytics work to firms located in Europe and India. However, U.S. law stipulates that sensitive account information cannot leave the United States.

That said, the bank does not really need to send the data itself. It is interested in the analytics, which gives summary statistics and relationships among data items. This is a case where a sophisticated masking approach works well: Account data can be masked with “dummy data” that nevertheless preserves the relationships among items in the data.

For example, take address data. The bank might be interested in discovering how many services are being used by bank patrons in various ZIP codes. They do this by cross-referencing addresses tied to accounts with services being provided to each account. When sending the data, the actual addresses can be masked with fake addresses that nevertheless group together clients who are in like ZIP codes. The result is that the analytics results stay the same, but no actual addresses are transmitted, and no data leaves U.S. borders.

And because the data is physically and logically within U.S. borders, U.S. law is respected, even though a non-U.S. firm is providing the analytics insights.

Restricting Private Information for Sensitive Contracts

A top aviation company in Canada is working closely with Canada’s military, and data needs to be shared back and forth between the organizations. Certain bits of information—such as names, addresses, salaries, and designations—are considered private information, and access to that information is determined by pay grade. Some pay grades have access to all information; some can access only information for their own pay grade and lower. Some will not be able to see any private information at all.

With dynamic data masking, sensitive information will be masked according to who is requesting the information of the system. This way, data integrity is kept intact at all times, but only those at certain pay grades will be able to see the most sensitive data, according to the rules set forth when the masking is implemented.

Role-Based Access for HR within a Large Organization

An enterprise-sized business has a large amount of employee data for things like payroll, employee communications, etc. While employees can access their own data via a company portal, no one outside of HR needs to access that information.

Even within HR, only certain pieces of information are needed by people in certain roles. In essence, the organization wants to allow for role-based account access (RBAC). For example, the person running payroll needs to be able to access salary information and residential addresses. But the person sending communications about benefits needs only the address information—they should not see salaries.

When employee information is requested, certain bits of information are masked depending on what is actually needed by the person making the request. This allows them to have access to what they need without introducing measures that slow down the system.

Mage Provides a Faster Dynamic Data Masking Option

There are many vendors that will offer dynamic data masking, but they do so by routing requests through a security proxy. While this works, it means there can be a significant effect on performance, because the speed of the system now depends on the speed of that proxy.

Now consider what that proxy has to do with each request: It must process the query, look at the user’s access level, mask the incoming data when it is returned (according to user access levels), and send it back to the requester. While a handful of requests might be handled quickly, it is easy for such requests to pile up…and when that happens, there is a noticeable impact on system performance.

With iMask (our own dynamic data masking tool), masking rules and policies are pre-programmed into the database itself. There is no proxy serving as a “middleman”: The database itself becomes smart, knowing which pieces of data to serve as-is, and which to mask. This means there is a minimal impact on performance. iMask works for organizations of any size and allows an incredible amount of customization when it comes to access controls and anonymization methods.

BLOG LIBRARY >