Dynamic Data Masking, Sourceless Performance Improvements, Business-aligned Server Prioritization

ActiveBase Security
Keeping Private Data Private

Dynamic Data Masking is Data Masking at the Presentation Layer. Works for Production as well as Test!

Resources
Datasheet
FAQ
Scrambling Data
Encryption
Production Data
Test Data
Tech Overview
Rule Examples
White Paper

Critical Business Issue
Ever since the inception of Information Technology (aka Electronic Data Processing) it has become commonly accepted to allow a certain percentage of IT staff to have access to the production environment. These "trusted employees" were carefully screened and usually in close proximity to executive management due to the confidentiality of critical sensitive corporate data.

Originally, this was a practical matter and was voluntarily implemented by the enterprise. Over the years, the onslaught of international Data Privacy Legislation has made this a compliance matter as well.

Today's large, multi-national enterprise is faced with numerous cross-border data privacy exposures. Additionally with the deployment of third-party contractors, there is further separation from the traditional "trusted employee".

Challenges

Data Masking is a concept that was introduced in the early 90's in an effort to provide development teams with meaningful test data, without exposing Sensitive Private Information (SPI).

Static Data Masking
The common element among the traditional approach is to extract rows from production databases, obfuscating data values that ultimately get stored in the columns in the test databases. This is known as Static Data Masking...the obfuscated values are physically stored in the target databases.

This process has several common limitations that are painfully revealed in proportion to the size and complexity of the enterprise, such as:

Designing and creating the masking scripts is tedious and error-prone, requiring intricate functional and performance requirements. In large organizations this is so complicated task that many data masking projects have been abandoned and simply use production data in test. Among the challenges here is maintaining Referential Integrity in the target databases.
Sophisticated enterprises are often required to make drastic changes to their System Development Life Cycle simply to accommodate data masking requirements
Another significant drawback of static data masking is the impact on the Database Statistics that are automatically captured by Oracle. Huge differences in Data Distributions and Cardinality occur that cause the Query Optimizer to perform radically different functions between the test and the production environments.
Significant computer resources are consumed with the ETL processes especially in volatile data environments which may require frequent refreshes and re-masking
Static Data Masking represents another significant difference between the production and test environment, requiring modification all testing scripts that have been created with data entry values before data masking occurred or updated
Inherent in the original concept of data masking was that it does nothing to protect SPI in the Production Environment. For obvious reasons, Static Data Masking cannot be used in Production.

Dynamic Data Masking (a term coined by Gartner), is an emerging technology that performs data obfuscation at the presentation layer in real time.

Implemented at the SQL*Net Protocol Layer, operating as a database listener, in-bound SQL from any application is inspected and then dynamically re-written to include the appropriate masking function. The result is data masking at the presentation layer without having to change the underlying database or the application source code.

Based on rules that equate to enterprise security policies, ActiveBase is able to provide the appropriate access to data in order for the user to do their jobs, without exposing sensitive data to those who should not be allowed to see it.

Dynamic Data Masking opens up a whole new level of opportunity - masking in production. For the first time in the history of IT, the enterprise can close a critical exposure and truly "keep private data private".

An example is the Production DBA. These individuals have the ability to perform radical brain surgery on the production environment, during prime time, in order to keep the business up and running. But even the brain surgeon does not have access to the patient's mind... yet Production DBA's have access to the enterprise's inner mind and deep secrets. For the first time in the history of IT, this exposure can be closed!

In non-production environments, the traditional target for data masking, ActiveBase overcomes the drawbacks brought on by Static Data Masking that have continually plagued enterprise IT for decades.

One of the biggest causes of failure in Static Data Masking projects is the complexity of maintaining Referential Integrity. Dynamic Data Masking eliminates the pains-taking design, labor-intensive planning and the extensive development of ETL scripts that end up with deep errors from cascading conflicts. Many organizations have simply given up.

With Static Masking, databases are inconsistent with the Production Environment making it difficult to accurately test. Resources are drained reconciling the differences in data values. Coordinating these application requirements requires extensive changes to the SDLC that have nothing to do with the application itself.

QA Testing Scripts that were captured in production will not work in the test environment without modification.

Database Statistics are radically changed invoking unrealistic strategies by the database engine; in fact, Data Distribution and Cardinality go out the window, which has a major impact on performance testing.

ActiveBase does not require the overhead of massive ETL or Database Cloning processes. There is no processing or copying of databases for Dynamic Data Masking to be applied.

ActiveBase Does More Than Just Data Masking

Audit/Logging – ActiveBase Rule invocation can be logged. This provides two key benefits:
- You can document who accessed sensitive private information and how it was received by the requestor. A log record includes the Date/Time, UserID, Program, etc AND a representation of the data as it is actually stored in the database and what it looked like to the user.
- Even if you are not actually masking data, the audit log can give you a detailed history of who accessed what, when, where and how. Patterns will reveal unusual user behaviors which could lead to the more important question –“ why?”

Separation of Duties – ActiveBase provides the ability to prevent unauthorized users from performing Privileged Functions. An example would be to prevent a developer or end-user from Creating/Dropping database objects as well as Granting/Revoking user privileges
Block/Alert – ActiveBase provides the ability to actually BLOCK an offensive user request and additionally can send a message back to the user, and/or a notification to management

Production Environment - ActiveBase provides a way to mask sensitive private information in production. Even Production DBA’s that have the highest levels of Oracle privileges cannot see sensitive private information in either Production or Test environments
ActiveBase Data Masking Rules can be set based on UserID, (including LDAP or Active Directory), Program, Geographic Location, Time of Day and other flexible criteria. User Profiles in ActiveBase are independent of Database Privileges acting as an additional level of Access Control
ActiveBase provides a way to have a different masking algorithm invoked on a single column for different users. Example, one group of users might see ‘xxx-xx-9859’, while another group might see ‘135-xx-xxxx’, while another group might see ‘135-22-9859’.