Hardening Guidelines
CipherTrust Manager should be deployed into as secure an environment as possible. Every effort has been made to make CipherTrust Manager as secure as possible, however, additional precautions should be taken especially when CipherTrust Manager is deployed into an untrusted environment. Refer to CipherTrust Manager Hardening Guidelines for details.
General Hardening Recommendations
When a scan is run, all the data is transferred from data stores to Agents so that they can read and discover info types. As a result, potentially sensitive data is transferred between data stores and Agents. Although we cannot provide the comprehensive list of actions to secure the data being transferred, for security and performance reasons, we offer at least the following recommendations:
As a general rule, take all necessary actions to eliminate or minimize the transfer of data between data stores and Agents.
It is recommended to install a different Agent in each subnet with sensitive data, and to configure the firewalls to block any connection to the sensitive data stores from Agents in different subnets. This ensures that sensitive data does not leave the subnet and company policies are respected.
Agents should not be in a different network security zone. This ensures that data does not cross the network security zone boundaries.
Agents should be used in the same subnet as the data stores for Big Data stores. This can prevent firewalls from collapsing.
Local Agents should be used, when possible, in data stores with huge amount of data. This ensures that the data never leaves the server.
Contact your corporate security teams if data stores reside in different network security zones to determine where to locate the CipherTrust Manager appliance.
Agents should be hardened to comply with the company security policies for the sensitivity of the data located in the data stores they will scan, as all the scanned data will be transferred to the Agents.
DDC should be configured with secure protocols (for example, using TLS) to connect to data stores whenever possible, to ensure that the data travels protected with channel encryption.
Use firewalls to restrict the access to data stores, so only the allowed computers can connect to their endpoints.
Certificate Security Recommendations
Certificate generation
Certificate private keys must not be generated or transformed on public web services.
The certificate format must not be transformed on public web services.
Cryptographic algorithms and key length must satisfy a minimum security strength of 112 bits.
For the symmetric key, we recommend to use at least AES128.
For the asymmetric key: use DSA-2048, RSA-2048, and ECDSA224-255.
Certificate validity and Key usage period should not exceed 2 years.
Digital signatures must use a strong hash function. We recommend using at least SHA256.
Certificate usage
User must keep secret his private key and related activation data.
Receivers of a certificate must verify the certificate.
Users must respect the PKI Certificate Policy requirements when using a certificate.
Do not share Wildcard Certificates for Different Security Contexts or Security Levels.
Certificate revocation
- Subscribers must revoke their certificates when necessary (for example, when it's compromised).
Certificate renewal
- Subscribers must renew their certificate before it expires.
TDP (On-prem) Security
Refer to Thales Data Platform (On-prem) Hardening Guidelines for general guidelines on securing your TDP (On-prem) deployment.
TDPaaS Security
Download and store the TDPaaS credentials at a secure location. These credentials could be valuable in the event that TDPaaS settings cannot be retrieved from the database. If such a situation arises, please reach out to the Thales Customer Support.
