Skip to content

Algorithm Implementation

This section details a number of security consideration developers should be aware of when creating plugin algorithms for the Delphix Masking Engine.

The Security Sandbox

During execution, all plugin code is sandboxed using the Java Security Manager. Plugins are granted all permissions except for the following non-FilePermission:

Class Target Action
java.net.SocketPermission localhost:- accept, connect, listen, resolve
java.lang.RuntimePermission exitVM
java.lang.RuntimePermission createClassLoader
java.lang.RuntimePermission accessClassInPackage.sun
java.lang.RuntimePermission setSecurityManager
java.security.SecurityPermission setPolicy
java.security.SecurityPermission setProperty.package.access

With regards to FilePermissions, read access is granted to all, though write is only allowed for the following directories:

  • the masking user's home directory (System.getProperty("user.home"))
  • the JVM's default temp directory (System.getProperty("java.io.tmpdir"))

Please note that both of these locations are shared, so care will need to be taken to avoid collisions.

The set of permissions granted to plugins is static and cannot be modified. To facilitate testing, the same security restrictions are applied when plugins are run using the maskApp or maskScript utilities in the Masking SDK (with the exception of the SocketPermission and all instances of write FilePermission).

Handling Errors

One important aspect of ensuring that an algorithm securely masks sensitive data is proper handling any errors that might occur during algorithm execution.

One particular category of error that might occur is when the input value does not match the format expected by the algorithm. Perhaps an account number masking algorithm is applied to a column containing free-text comments, or an image blurring algorithm is applied to non-image binary data. This is referred to as Non-conformant data. The Algorithm Extension Plugin API defines how an algorithm may trigger the Non-conformant data handling mechanisms built into the Masking Engine.

Reporting Non-conformant Data

Whenever a Non-conformant input value is encountered, and the algorithm cannot mask it, the algorithm mask method should throw an exception of class NonConformantDataException supplied by the Masking Plugin API. This triggers the Non-conformant data reporting mechanism of the masking engine. The String value used to construct this exception must not include the unmasked input value, as this would result in the sensitive value being saved in the Masking Engine logs and made visible in the engine UI. A redacted sample of the Non-conformant data will be saved automatically by the reporting mechanism.

Handling Other Errors

In general, other code errors should be handled as responsibly as possible by the algorithm implementations, following these guidelines:

  • Under no circumstances should the unmasked input values (the input argument to the mask method) be included in any Exception thrown. Exception details are recorded in the engine logs, making them visible to the engine operator and subject to potential disclosure in support bundles. Similarly, exceptions should not simply be re-thrown as NonConformantDataException as the original exception's message may contain the sensitive value.
  • Whenever possible, configuration problems should be reported in the validate or setup method, rather than the mask method. Waiting until the mask method has run to report an error allows the masking job to run, potentially leaving the database table or file partially masked.
  • An algorithm should never fail in such a way that sensitive values pass through without being masked. In such cases, non-conformant can be reported as described above.

Logging

The extensibility framework provides the capability for an algorithm to create a logger in order to write diagnostic messages to the Delphix Masking Engine logs. Under no circumstances should unmasked data (any input argument values to the mask method) be logged. Logged messages are visible to users via the UI and web API, and may be disclosed in support bundles. It is recommended that production algorithms never log in the mask method, for both performance and security reasons.

Additionally, plugin code should never read or write any of the System input or output streams. Specifically, these are System.in, System.out, and System.err. All logging should be done using the provided logging interfaces.

Handling Secret Credentials and Keys

The JSON document describing the configuration of each algorithm is stored unencrypted on the Delphix Masking Engine and made visible to users with access privileges through the UI and web API. For these reasons, secret values of any kind should never be part of an algorithm's configuration, regardless of whether the algorithm is user-created or built into a plugin. This includes secret keys, as well as access credentials or API keys that might be used to access remote systems. The only mechanism available as of release 6.0.3.0 that would allow an algorithm to load a sensitive value without the risk of compromise is reading the value from a file stored on an NFS or CIFS mounted filesystem.

Note

A feature to allow plugins to securely access managed credentials will be added in a future Delphix release.

Secret values (keys) or seeds that drive the output "randomization" an algorithm should not be embedded in the algorithm code. Instead, the algorithm's assigned key should be accessed via the CryptoService interface. Static secrets of this kind of risk disclosure should the plugin JAR file be disclosed. There are also risks associated with the algorithm producing the same masking results in all cases, especially if the plugin is to be used for masking by multiple organizations.