Delphix Products

Enterprise DataOps Security

Secure your enterprise dataops platform

The security of data is a known priority in the modern data driven businesses of today and de-sensitising data before it is shared to data consumers is a process most are now employing as a matter of course. The process ensures the real production data stays where it should, in production, and all non-production environments only receive the anonymised data. Production is where the security of the data platform and infrastructure is implemented with strict design methodologies and controls in place to ensure the environment is hardened to the 'nth degree.

But what about the platform and infrastructure employed to perform the data masking and move the data around the organisation? These environments contain copies of the untouched production data and therefore must be treated with the same rigorous hardening processes as their production sources.

Enterprises spend huge amounts of time and effort on the security of their production environments. So why would you let a third party tool connect to, and in fact take a copy of your production data without ensuring it meets the same standards.

Components of the DDP

There are two core components of the DDP, the virtualisation engine and the masking engine. Each has its own set of challenges when securing the environment. But there is also a third component that must be considered - the source and target data servers.

Data[base] servers are generally part of the enterprises existing infrastructure and not managed by Delphix but must be configured to allow Delphix to work with them.

Whether on-premise or in the cloud the same rules apply but often the production data is kept on-premise while masked copies are located in the cloud. This article intends to highlight the areas of the production side of the infrastructure where a secure implementation is paramount.

Security Controls

There are 8 key areas of a Delphix DDP implementation that must be addressed:

1. Appliance/Software installation

2. Default system accounts

3. User accounts and privileges

4. Segregation of production and non-production

5. Operational standards

6. Data source and target access

7. Auditing

8. System Inventory

Controls must be implemented, whether they be technical and/or process oriented, for each of the key areas. By breaking the system down to key areas like this allows for a methodical and focussed approach to the hardening of the environment and provides a checklist to be used as a basis for post-build and regular quality assurance checking.

Security Standards

Every organisation has their own set of security standards they apply to their IT systems. When disrupting technologies come along the traditional standards often do not completely fit and therefore must be reviewed by all stakeholders and updated accordingly. Loosening of the standard should not be allowed however exceptions may have to be granted. Where this happens the exception must always be qualified with a follow up action to remove the exception at a defined future date. In other words, rectify the issue so the exception can be removed.

DDP Key Security Topic Summary

• Appliance/Software Installation

Delphix engines are appliances delivered as virtual machine images and loaded onto a VMWare or cloud hypervisor. As appliances they are “black boxes” from an operating system and software installation perspective, which means there is no traditional hardening of the underlying software stack to undertake.

Instead, the control is to ensure the version of Delphix installed is fully certified and supported with any remedial hotfix sub versions applied. With an up-to-date and supported system there is assurance that no known vulnerabilities exist.

• Default System Accounts

A default system account is a generic user account created on the appliance by Delphix at installation time.

Default system accounts have full administrator access and provide no way of auditing actions against an individual. Therefore, they must not be used under normal operation and should be locked once an administrator level individual user account is created.

There are various methods to ensure the account can be used in break-glass situations depending on the organisations standards.

• User Accounts and Privileges

Between the virtualisation and masking engines there are at least seven categories of user accounts that can be created. The categories cover administrator, non- administrator, self-service and batch/automation accounts.

Both engines must be configured to use the enterprise LDAP service to overcome limitations in the local account configuration. For example, the virtualisation engine local user accounts do not enforce password policies. By utilising the enterprise LDAP service, current standards are automatically enforced, such as password complexity, automatic password changes and password retrieval.

Without LDAP integration user access to the engines cannot be controlled sufficiently.

• Segregation of Production and Non-Production

A virtualisation or masking engine must be classified as a production environment if it contains or connects to production data. And therefore, all production security controls (the controls described in this document) must be applied.

A key feature of the Delphix DDP is replication, where whole engines or a subset of objects can be replicated using Delphix own protocol (DSP) to another engine. When replicating masked objects Selective Data Distribution (SDD) must be used, which ensures no unmasked blocks are replicated.

In this scenario it is possible to mask the production data in the production engine before replicating the masked virtual dataset to another target engine. The target engine can be classified as non-production providing it only contains fully de- sensitised data.

Regardless of whether replication is used, the target data server (the server hosting virtual datasets) may be classified as non-production as long as the data is fully de- sensitised. Security controls for either non-production engines or target data servers may be relaxed but this subject is outside the scope of this document.

• Operational standards

Operational standards refer to how the system is interacted with and its features utilised from a process perspective. Access controls, account auditing, infrastructure design and process definition are key to ensuring the environment is operated in a secure manner.

An example has already been mentioned – no generic administrator access is allowed and only individual user accounts must be used.

Another example would be in the design and implementation – only known specified target servers can receive the provision of a virtual dataset.

Operational standards can be complex to implement and should be given detailed attention.

• Data source and target access

Delphix has a defined list of requirements and configurations needed for every data source type and corresponding target environment e.g. a Delphix specific operating system user, toolkit directories, open network ports and many more.

When considering the pre-requisites for the first time, each configuration must be assessed to ensure it fits with existing standards. Where it does not, either a work- around can be implemented or the standard must be adapted or an exception granted using mitigating controls. A prime example is for Oracle database servers where the Delphix owned operating system user account must have the same group memberships as the Oracle software owner. This often contravenes enterprise security standards.

This area of a Delphix implementation can be the most difficult to accomplish from a security perspective. Understanding the complexities of enterprise data platforms and a deep knowledge of the Delphix product will aid the process significantly.

• System Inventory

Inventories ensure that assets are known and that ownership is clearly identified.

This is important to ensure that security incidents can be managed.

Although not a Delphix specific configurable control, a system inventory must be part of the Delphix implementation security checklist.

Be Secure

As described in this paper, there are several security related topics to tackle during a Delphix implementation, some are well known and some require in depth knowledge of database, data virtualisation, data masking and enterprise security policy and procedure to appreciate fully.

Understanding and mitigating security risk when implementing new technology is often overlooked at the planning stage, which can lead to lengthened project timelines.

Ensure you meet project deadlines, and more importantly be secure, by considering these key topics early.

Engaging with an experienced delivery services provider with a proven track record of delivering such solutions into global enterprises will smooth the journey to DataOps success. And the CIO/CISO/CDO can sleep easy at night knowing it’s secure!