All Platform Recommendations and Considerations
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 CTE-LDT policy, will use different signatures for an CTE-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 CTE-LDT metadata
Before launching CTE-LDT on a GuardPoint:
-
Check the available free disk space in the file system where your GuardPoint resides.
-
Type the following command to check the disk space requirement of CTE-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)In this example, the output shows that CTE-LDT requires 169MB of available disk space to launch and execute CTE-LDT on
/oxf-fs1/gp1.Make sure that the free space in your file system exceeds the disk space requirement for CTE-LDT.
CTE-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 CTE-LDT policies, CTE-LDT imposes a hard requirement on the backup application, or process, to backup or restore CTE-LDT metadata. The CTE-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 CTE-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.
Make sure that you suspend CTE-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 CTE-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.
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 CTE-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 CTE-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 CTE-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 CTE-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 CTE-LDT feature upgrade to version 7.2.0.128.
