All Platform Recommendations and Considerations

• Binary Re-signing

• Check for available disk space for LDT metadata

• LDT Requirements for Backup

• Learn Mode

• Quality of Service (QoS)

• Upgrade to CTE 7.2.0.128

Binary Re-signing

Any executable that is part of either a Signature set or a Host setting, and that resides in a GuardPoint that uses an LDT policy, will use different signatures for an LDT key rotation. The result is that the Host Settings binaries will no longer be authenticated, or that the Signature Set policy rules will no longer trigger for those binaries.

To prevent these issues, the Security Administrator must manually re-sign each affected binary after each key rotation.

Alternatively, CTE can generate unencrypted signatures of binaries inside GuardPoints to avoid these problems. For details, see the CipherTrust Manager documentation.

Check for available disk space for LDT metadata

Before launching LDT on a GuardPoint:

1. Check the available free disk space in the file system where your GuardPoint resides.

2. Type the following command to check the disk space requirement of LDT on a target GuardPoint:

   voradmin ldt space /oxf-fs1/gp1
   /oxf-fs1/gp1: found 1501 files without LDT extended attributes
   LDT disk space requirements: total 169MB (LDT attributes=6MB, MDS=163MB)

   Copy

   In this example, the output shows that LDT requires 169MB of available disk space to launch and execute LDT on /oxf-fs1/gp1.

Note

Make sure that the free space in your file system exceeds the disk space requirement for LDT.

LDT Requirements for Backup

CTE offers the option to backup encrypted data from files through a security rule, which skips the Apply Key function when reading encrypted files by backup applications or processes. Such files can also be restored from backup streams, to the same or a different GuardPoint, without Apply Key. If you choose to restore to another GuardPoint, the target GuardPoint must be protected with the same key and security rules as the source GuardPoint.

If you backup encrypted data from files inside GuardPoints with LDT policies, LDT imposes a hard requirement on the backup application, or process, to backup or restore LDT metadata. The LDT metadata is stored as an extended attribute on Linux and as alternate data streams on files on Windows platforms. If the backup process cannot backup the metadata, then LDT protected GuardPoints must backed up in clear key.

Customers are required to verify their backup application, or process, to ensure extended attributes (on Linux) or alternate data streams (on Windows) are backed up and restored through their backup/restore processes.

Note

Make sure that you suspend LDT operations before you start the backup process, and resume them after the backup process completes.

Learn Mode

Learn Mode provides a temporary method for disabling the blocking behavior of regular CTE or LDT policies. While useful for quality assurance, troubleshooting, and mitigating deployment risk, Learn Mode is not intended to be enabled permanently for a policy in production. This prevents the policy Deny rules from functioning as designed in the policy rule set.

Ensure that the policy is properly configured for use in Learn Mode. Any Security Rule that contains a Deny effect must have Apply Key applied as well. This is to prevent data from being written in mixed states, resulting in the loss of access or data corruption.

Note

Apply Key will have no effect when combined with a Deny rule unless the policy is in Learn Mode.

Quality of Service (QoS)

By default, the QoS component of LDT does not monitor live transformation operations unless you enable QoS on your host by entering QoS parameters in the CipherTrust Manager profile associated with the client. To avoid overhead of LDT on your production system, you must select QoS parameters suitable to your production environment. For information on tuning QoS, see Quality of Service. It is critical that you understand the impact of LDT on your system and how to manage this impact using QoS.

Upgrade to CTE 7.2.0.128

Since the the first release of the LDT feature, Thales has made several improvements in the areas of error handling, interoperability with applications, and Quality of Service (QoS). Thales strongly recommends that new deployments use version 7.2.0.128 (or later) of CTE. Thales further recommends that customers who have already deployed the LDT feature upgrade to version 7.2.0.128.