Earlier this month a leading analyst released their annual report on the state of Data Masking as a component of the overall Data Security sector; which included commentary on what’s known as ‘static’ data masking and an alternative solution known as ‘dynamic’ data masking. And these two solutions have been considered in unison for some time now within the industry overall. The question is, should they be?
Dynamic certainly sounds good, but is it what I need?
At face value, the word ‘dynamic’ certainly sounds a lot more exciting than “static” — I mean, who wouldn’t rather purchase a dynamic television, a dynamic smartphone, or a dynamic bicycle, if the alternative was a “static” version?
The problem is, these are not comparable or alternative options. In the world of data masking, dynamic and static solutions continue to be treated as alternative solutions, with vendors being assessed as to whether they offer one or the other or both. The reality is, the two solutions certainly support data security, but only static data masking actually ‘de-identifies’ or ‘masks’ data. Dynamic masking provides a cursory replacement of data in transit but leaves the original data intact and unaltered.
So, the point here is that both tools offer a solution to organizational challenges around securing data; but they are completely different technologies, solving completely different challenges, and with completely different use-cases and end users involved.
So, what’s the difference between dynamic and static solutions?
Let’s take a closer look at the two technologies. First, what is the definition of data masking? A quick Google search will lead you to a variety of closely aligned definitions, all of which reference the notion of de-identifying specific sensitive data elements within a database. So, how does this differ between Static and dynamic varieties?
Static data masking (SDM) permanently replaces sensitive data by altering data at rest within database copies being provisioned to DevOps environments. Dynamic data masking (DDM) aims to temporarily hide or replace sensitive data in transit leaving the original at-rest data intact and unaltered. There are use cases for both solutions, but comparing them as alternative options and/or calling them both ‘masking’ is clearly a misnomer of sorts.
SDM is primarily used to provide high quality (i.e., realistic) data for development and testing of applications within the non-production or DevOps environments, without disclosing sensitive information. Realism, rich data patterns, and high utility of the masked data is critical as it enables end-users to be more effective at conducting tests, completing analytics, and/or identifying defects earlier in the development cycle, therefore driving down costs and increasing overall quality. Leveraging SDM also provides critical input into privacy compliance efforts with standards and regulations such asGDPR,PCI,HIPAA, that require limits on the use of data that identifies individuals. By leveraging SDM, the organization reduces the volume of ‘real’ sensitive data within their overall data landscape, thereby reducing the risks and costs associated with a data breach while simultaneously supporting compliance efforts.
So, SDM clearly has a role in supporting overall data security efforts and in securing the DevOps environment, but what about DDM? How do they compare? Well, as previously mentioned… they don’t.
The reality is, DDM is primarily used to apply role-based (object-level) security for databases or applications in production environments, and as a means to apply this security to (legacy) applications that don’t have a built-in, role-based security model or to enforce separation of duties regarding access. It’s not intended to permanently alter sensitive data values for use in DevOps functions like SDM.
Okay, how does it work? At a high level, sensitive data remains within the reporting database that is queried by an analyst with DDM. All SQL issued by the analyst passes through the database proxy which inspects each packet to determine which user is attempting to access which database objects. The SQL is then modified by the proxy before being issued to the database so that masked data is returned via the proxy to the analyst. To that end, the complexities involved in preventing masked data from being written back to the database essentially mean DDM should really only be applied in read-only contexts such as reporting or customer service inquiry functions.
Ok, I get the differences, but dynamic still sounds intriguing- why wouldn’t I start there when looking to mask my data?
First, it’s complex and complicated. It’s not as simple as installing a software application and running it. The organization must undertake a detailed mapping of applications, users, database objects and access rights required to configure masking rules; and maintaining this matrix of configuration data requires significant effort.
Second, it can be risky. Some organizations we’ve worked with are hesitant to adopt DDM given the inherent risk of corruption or adverse production performance. In addition, relative to SDM, DDM is a less mature technology for which customer success stories are not as well known and use-cases are still being defined.
Finally, the fact remains that the underlying production values and sensitive fields are not actually de-identified or masked, meaning the risk of exposure remains; particularly if the organization in question is leveraging this data to provision to DevOps without a static masking solution in place. So, if your goal is to increase data security efforts relative to data breach risks and/or compliance support efforts, you’re no further ahead with dynamic masking.
All this is not intended to suggest DDM does not have a role in data security, or that it is not as effective as SDM. The point is that they are two fundamentally different solutions operating in differing environments, for varying purposes. The key question organizations must ask is simple: what is the business problem or data security challenge we are trying to solve? That question will help determine which solution makes the most sense.
At the end of the day… can’t both options just get along?
We’ve covered the basics of both dynamic and static data masking with the intent of outlining the unique aspects of the solutions and business challenges they aim to solve; in hopes of supporting the argument that the terms and solutions should not be used interchangeably or compared head-to-head in any sort of meaningful way. Both solutions offer value to organizations in solving different business challenges, and both — if properly implemented — deliver significant data support as part of a layered security strategy.
At the end of the day, however, data de-identification via static data masking is a data security solution recommended by industry analysts as a must-have protection layer in reducing your data risk footprint and the risk of breach by inside or outside threats. Dynamic data masking acts more like a role-based access security layer within the production environment and for internal user privilege requirements- and there are options available within other solutions to achieve this end-goal.
While terminology varies across the industry, the term data masking typically involves verbiage involving the replacement of sensitive data with a realistic fictional equivalent for the purpose of protecting DevOps data from unwanted disclosure and risk. So, it might be the right time to stop the unwanted and inaccurate comparisons between “dynamic” and “static” solutions, and get back to focusing on solving an access challenge in real-time production environments (i.e., the dynamic world); and addressing sensitive data exposure and compliance risks among users in DevOps environments (i.e., the static world).