Dynamic Data Masking Inside Out

Dynamic Data Masking Engine plays an essential role in the Enterprise Security and Data Privacy frameworks

By Vitaly Dubravin

Dynamic Data Masking has grown over the years into a robust and mature product. It has become one of the primary tools to combat private information leaks from production environments. It limits, if not completely eliminates, all sensitive data exposures due to the application security design flaws, inadequate testing, ever changing regulatory requirements and aggressive production release schedule.

It is important to understand that Dynamic Data Masking (DDM) is not a replacement for a traditional data protection and security measures. It was designed to address a very specific but extremely damaging situation when private data gets in the wrong hands. Data Masking works as a proxy that secures only data communication channel and should be deeply integrated with the Enterprise Authentication and Authorization infrastructure as well as network security tools to gain maximum advantage and significantly reduce implementation and operation costs.

Dynamic Data Masking Proxy and Perimeter Protection Zones.

Every business application has at least two major components that are relevant to this topic: the data storage (database) and the application itself (that includes business logic, security and processing rules). Many applications, especially Web 2.0 stores all user authentication information internally and use a superuser account to access all database records.. Business and security logic are intertwined and it becomes practically infeasible to discover all possible cases of private information leaks.

Better designed applications use some variation of a AAA Server (Authentication, Authorization and Auditing) to implement a robust user management procedures. This includes Single Sign On (SSO) servers, Active Directory (AD), Kerberos etc. AAA Server implements very narrow and specific business function. Its code does not change frequently (unless there is a security patch), is thoroughly tested by the vendor and often by a certification authority. This speeds up security implementation, testing and reduces probability of user credentials exposure due to hacker’s attack. AAA Server ensures user’s authenticity and this is the first step to control data flow. It also proved user-2-roles mapping tools with user friendly interface. Now it is very easy to define that John Doe works for the Northeast Sales Department and should have the same (not more) data access rights that all other sales people around him.

Perimeter Protection Zones

But the AAA Server does not control data flow. It only “knows” which team John belongs to. This is the function of the Dynamic Data Masking Proxy. It relies on the AAA Server as a trusted authority for user and role information and dynamically alters data flowing between the database and the application based on the predefined role permissions. DDM Proxy should also use the AAA Server to gain database access. Single superuser database account still possess an issue, if used by the DDM server, but the risk of data leak is significantly lower due to additional layer of isolation.

Database server in this scenario is not exposed to the application directly and interacts with it only through two validated components – AAA Server and DDM Proxy. Direct data leak from the database is mostly possible through physical database server access and questionable disaster recovery procedures. That is why most traditional security protection measures should not be ignored and tested independently from the application data flow through the DDM Proxy.

Business application in any scenario should never use a single (superuser) account to access the data. Every request to the Dynamic Data Masking Proxy (that becomes the database for the application) must be executed in the context of the authenticated user.

This architecture can be logically and physically divided into three security zones. Zone color is driven by the risk factor of data leaks and is based on:

• exposure to an insecure environment (like the Internet or intranet)
• frequency of the functional releases
• narrow system functionality and testing process maturity

Red zone is the primary target for privacy invaders and this is the place for the business application to be in. We always have to consider a possibility of a hacker’s attack, misinterpretation of business rules by the development team as well as insufficient testing efforts.

Database server code on the other end is much better tested. Major database vendors like Oracle, Microsoft and IBM spend millions of dollars for security testing every year. All detected vulnerabilities are promptly addressed by the frequent security patches. Even zero-day vulnerabilities are not too dangerous since the database server is not exposed to the outside world and is shielded by the stable and reliable AAA Server and DDM proxy. That is why the Database Server belongs to the Green Zone.

Two remaining component, both DDM Proxy and AAA Server should stay in the Yellow zone due to a direct threat for the malfunctioning or hacked business application. It is also a good idea to install a firewall on both borders of the Yellow zone.

Dynamic Data Masking Proxy Internals

DDM Proxy does not store any session data and is highly scalable in the server farm environment. Some DDM products may also use an external database to ensure transformation consistency, but it all depends on the masking algorithm.

Dynamic Data Masking Proxy Internals

Masking process starts from user authentication. DDM Proxy API call is the best, but not the only way to authenticate users. Authentication module support seamless integration with SSO Servers and this is the safest way to go and is always recommend for new applications. DDM Proxy may also be used when you trying to secure private information used by a vendor or legacy applications, but with some limitations. For example Active-Base DDM server can mask PeopleSoft data, though PeopleSoft does not supply user information in the database requests. Active-Base retrieves user information directly from PeopleSoft and resubmit authenticated request for further processing by Active-Base engine. Similar detection can be (and are) implemented through the Authentication Proxy for other known products. You have to be careful using this trick since it bypasses safe authentication procedure.

Roles-2-Rules module comes into play once user login information is validated. This module can retrieve group membership from the AAA Server and dynamically loads customized data masking rules into the transformation module for each individual session. Roles-2-Rules module recognizes not only membership association, but also a workstation IP-address, name, time of day and many other options. Thus masking rules can be different when the same person requests the same information from inside and outside of the company premises.

DB Session Proxy is necessary to initiate database request on behalf of a superuser (a user with unrestricted access to all database records). The need for DB Session Proxy is driven by the database licensing costs as well as user management complexity in a distributed environment. Using multiple user accounts is possible, if required for security reasons, but a superuser login to the database in no longer a major risk factor due to complete database isolation from the Red Security Zone.

High Performance Dynamic Data Masking Pump is the transformation engine. It accepts (intercepts) native SQL statements and applies transformation rules received from Roles-2-Rules module. This module is designed for the specific database engine to provide top transformation performance. Actual masking may be implemented by altering the database query or by modifying query results. Query transformation seems to have less impact on the overall system performance. Active-Base benchmarking on several GRT databases results in practically unnoticeable delays.

Other DDM Proxy components like an Audit Trail and a potential Intrusion Detection are very beneficial from a security prospective, but are not essential to understand a Dynamic Data Masking Proxy positioning for the Enterprise Architecture.

Final thoughts

Dynamic Data Masking is a power data security and privacy protection solution. It takes literally 15-20 minutes to install. It has minimum impact on the database throughput, though out team at GRT adds extra 5-7% load for server sizing calculations. Transformation rules should be designed for the individual needs and cannot be very generic. Rules quality has a direct impact on the system performance and there is always a way to put a system on its knees by applying heavy and unnecessary transformations.

Transformation rules have to be driven by privacy protection needs (like government regulations), performance requirements and the best implementation practices. System capabilities should never become a suggestive factor for transformation definitions. That is why data masking project team should always include technical, business and compliance people to make an optimal and intelligence decisions for the enterprise Dynamic Data Masking policies.