Satori selected as a representative vendor in the Gartner Market Guide for Data Security Platforms 🥳

Data Masking

Native Dynamic Masking and When It’s Not Enough

|Chief Scientist

Dynamic masking is an effective way to obscure sensitive data shared across departments for different purposes. Some data store platforms have their own native dynamic masking capabilities, and while it’s tempting to use a database’s native dynamic masking features, this might not be a good fit for all scenarios.

In this post, we will define native dynamic masking, explore its shortcomings, and discuss how to implement effective dynamic masking.

What is Native Dynamic Masking?

Data masking refers to a security technique used to mask data that looks similar to the original data but hides sensitive information. This is useful for performing data analytics without exposing sensitive information. For example, it can be used to demonstrate how a database is structured, train database users or pitch clients, and use examples of data without the risk of exposing private information.

Native data masking refers to masking tools that are built into a given database’s platform and used solely within that platform. Some examples of data masking include replacement, randomization, scrambling, and redaction.

Get the latest from Satori

Types of Data Masking

There are two main types of data masking.

  1. Static data masking. The data engineer makes a copy of the production dataset and any sensitive data is either fully or partially masked. It is important to note that this is just a snapshot of data at a specific time and while it provides value neither the data nor the mask is dynamic.
  2. Dynamic data masking. Any sensitive data is fully or partially masked. The main difference is that the masking is applied directly to the production database instead of making a copy of the data. In this case, the updated sensitive data remains masked as the database is updated and amended.

Shortfalls of Native Dynamic Masking

Although data masking is a useful security technique, placing the masks at the database level may not always be the optimal solution for your organization, chiefly due to its inflexibility. Here are a few examples of relevant issues:

1. Lack of Effective Implementation

In many cases, native dynamic masking is difficult or overly complex to implement. In order to ensure an adequate level of security you use the dynamic masking capabilities, this in and of itself can be difficult to implement. However, this situation is further complicated by the presence of semi-structured data. In this case, the dynamic masking, while useful, is usually left unimplemented due to the difficulty of completing this task with native tools. As native dynamic masking can be frustrating to set up, some organizations decide not to mask data at all, leaving sensitive data vulnerable.

2. Runaway Overhead

When there are many locations in which sensitive data has to be masked, using native dynamic masking is still possible, but it is costly. The policies and database objects needs to be carefully defined and coded to ensure the protection of sensitive data. Due to its inflexibility, data engineering teams may spend a significant amount of time and resources to ensure that these native dynamic masking policies are up-to-date. Further, this time usually pulls data engineering teams away from their preferred core responsibilities. 

To learn more:

3. Different Teams Have Different Demands

Since different teams use data for different purposes with different levels of access and privilege, creating dynamic masking with native capabilities is a stressful endeavor. Trying to get the policies or views to work properly on a single platform across multiple teams can result in spaghetti code. This is especially true if the data updates frequently, requiring your engineering team to constantly adjust the policies or views.

4. Inflexibility to Changes and Migration

Native dynamic masking tools, by nature, are reliant on the platform they’re used with. But what happens when your data changes or you want to migrate to a different platform? 

Just as your engineering team spent a significant portion of their time setting up policies or views for your current platform, they’ll have to do the same all over again after the data’s migrated to the new one. Even if you remain on the same platform, any major updates to the data model your organization has created will require a lengthy correction process.

5. Complexity Across Different Technologies

If your data is spread out across multiple technologies, since each native masking capability is unique to its platform, applying the same masking policies uniformly across different platforms becomes a complex undertaking. Like everything else we’ve mentioned, attempting to bring order to chaos will require a lot of time, energy, and money to get it right – at least for the time being until one of the databases requires a migration.

Create Effective Dynamic Masking with Satori

Satori can seamlessly integrate with your platform and provide easy to implement dynamic masking across all of your data platforms. Ensuring your sensitive data is protected Satori is easy to configure and continuously updates to include changing sensitive data.

With Satori you do not have to define the specific locations where each type of sensitive data is located, your policies can be defined by security teams or the data owners, and they work without dependency on native database capabilities.

To learn more:

Learn More About Satori
in a Live Demo
Book A Demo
About the author
|Chief Scientist

Ben is an experienced tech leader and book author with a background in endpoint security, analytics, and application & data security. Ben filled roles such as the CTO of Cynet, and Director of Threat Research at Imperva. Ben is the Chief Scientist for Satori, the DataSecOps platform.

Back to Blog