Sidechain “How To”

CipherTrust Implementation Recommendations



How to Implement Best Practices in CipherTrust

CipherTrust Best Practices Series

Architecting a resilient and fail-proof CipherTrust implementation is the first step towards stability and efficacy. CipherTrust is a powerful data security platform with many capabilities, security controls, and use cases supported. That’s the beauty of the platform. Whether you need to tokenize data, encrypt on-prem file shares, or protect cloud keys, CipherTrust does all of this and more.

Sidechain has setup hundreds of CipherTrust clusters. This guide is a walkthrough of how we go about planning a CipherTrust deployment and operational support plan. Since scale matters, we’ve added a short section specific to large clusters at the end.

These are fundamentals – there are reams of pages that could be written about managing Thales CipherTrust Manager. We recommend these best practices as non-optional items to effectively lower the risk of deployment and create a rock-solid implementation.

Whether you are considering a CipherTrust deployment, or already have an existing implementation that could be optimized, this guide will help.

For this document, we are focused on the CipherTrust Transparent Encryption (CTE) solution.

CipherTrust Deployment Best Practices

When you have a small or medium sized deployment of Thales CipherTrust, you want a streamlined, low-maintenance implementation since your resources for managing CipherTrust are likely limited. You are striving for a set cadence of maintenance activities and very few surprises.

General Maintenance Recommendations
  • Do not “set it and forget it.” It is very tempting to leave CipherTrust alone once it’s configured, and some of the time, and the high stability of encryption can lull you into a sense of false security. If you are not running maintenance on your CipherTrust implementation on a monthly basis, you run a very high risk of a surprise that makes for a very bad day (or week in some cases!).
  • Review CipherTrust logs at least monthly, preferably more frequently. Look for errors.
  • Monitor client health. Even if an agent “appears to be working” it may be in an error state indicating another health problem.
  • Ensure backups are running and successful on a monthly basis.
  • Every 6 months, test a backup restore into a test CM.
Consider the following fundamental CM configurations:
  • Run two or three CipherTrust Managers clustered for high-availability, depending on the size of the cluster and criticality of the systems protected.
  • If you have a Non-production environment, consider creating two Domains, one for Prod and one for Non-Prod. If you are just encrypting a handful of machines, we recommend you just create them at the root level and don’t worry about setting up Domains.
  • Integrate users with LDAP or Active Directory if available
  • Create a break glass local user with elevated privileges and a very hardened password that is stored in a password vault. This is essential in case the connection to LDAP is unavailable.
  • Create a single Client Profile for all of your protected systems and ensure that each client is configured to use this client profile. 
  • Consider creating a single key for use throughout your environment. This is very common and still highly secure, plus it will simply operations and key rotation.
  • Enable Persistent on Client key configurations (for recovery in the event that the CipherTrust Managers are unavailable), and use a standard password for every client. Make sure this password goes into a safe password vault.
  • Vault the CipherTrust SSH private key. This is the only way to remotely SSH to the CM, and losing this key is extremely common!
Logging
  • Ensure that the Client Profile is configured with ERROR level logs sent to the CM
  • If possible, send CM and Agent logs to a third-party log aggregation solution or SIEM. Log management within the CM console is extremely difficult, leading to missed logs and an inability to find critical information.
  • If necessary, use the CM log interface to do basic monitoring, reviewing the logs at least weekly for errors and anomalies.
Policies
  • Use Learn Mode temporarily and tune policies quickly. Using the CM logging interface for Learn Mode is difficult so we strongly recommend getting your policies to Enforcing mode quickly to save yourself the pain of reviewing Learn Mode logs in-console.
  • We recommend using one policy per system, even if those systems are similar (i.e. multiple database servers) unless they truly are identical systems (for example a MongoDB replica set). 
Upgrades
  • We recommend reviewing the release notes of every agent and CM release. This can help you prioritize upgrades. If there’s a bug fix or feature you want, that’s a reason to upgrade. Otherwise, hold until the next release.
  • Upgrade your CM’s once a year if you can. There are a significant amount of enhancement released for CipherTrust Manager, and while you don’t need to take advantage of all of them, it’s helpful to stay somewhat current.
  • CM upgrades are easy and do not require downtime. Create a runbook for performing this and you can have them done quickly. 
  • Upgrade Windows agents once a year if you can. There are some high impact issues that are found and resolved throughout a year, and keeping your agents current will minimize the likelihood you’ll run into them.
  • Always upgrade Linux agents with kernel upgrades! The CipherTrust Linux Agent is kernel-dependent. Upgrading the kernel without updating the CipherTrust agent will cause instability. Note that you may not have to update the agent every time – the only way to know is to check the Thales compatibility matrix before a kernel upgrade and see if an agent update is necessary.
Staff and Management
  • The temptation with small implementations is to let them go passive. It takes almost no time, just some discipline, to regularly maintain the CMs and agents. Structure these repeated health monitoring tasks will ensure the risk of an encryption failure is dramatically reduced.
  • Periodically monitoring the CM’s will also keep you sharp in terms of using the system. A major pain point we see is that users just stop using the system, there’s some staff turnover, and nobody knows how to administer the CM. Don’t fall into that trap if you can help it.

Large Deployment Considerations

If you have a large CM deployment, in which you operate several clusters and/or hundreds or thousands of agents, you have particular needs and resource requirement. We recommend the following best practices.

  • Log Management: Setting up an external log solution is absolutely required to adequately manage client health risk and stability. We do not mean sending logs to a SIEM managed by a different team that looks for security alerts. You need access to CM and agent logs for operational resilience and keeping a tab on the overall health of your CipherTrust cluster(s).
    • NOTE: We are big advocates of creating separate, centralized log management for CipherTrust. This is aligned with Thales design and guidance, and the increase in health visibility and proactive response for errors is immeasurable. Email us for more information on our recommendations here.
  • Policy Management: It will be helpful to standard policy configurations such as process sets and user sets, and also creating a policy per protected system. The reason we recommend this is that the additional overhead of managing large numbers of policies is worth increasing your operational resilience and enabling effective troubleshooting if a system goes unhealthy or data is unavailable.
    • Example: Learn Mode is a powerful tool for diagnosing data access issues. If you have a single policy applied to a hundred systems, and need to enable Learn Mode on one of them, you effectively turn it on for all of them. This can easily create a log storm that is impossible to manage. Being able to isolate a machine and diagnose errors increases recovery time significantly.
  • HSM’s: Everything is more complicated if you are using HSM’s as the root of trust for CipherTrust. Make sure you have strong management best practices for your HSM’s, and that they are configured in a HA fashion within the CM’s. While not required, we recommend considering the use of non-root of trust backups periodically (stored in a secure location) so that CM’s aren’t entirely dependent on the HSM’s in the event of a system failure.
  • Staff Training: Resist single points of skills for CipherTrust. Cross-train additional staff and ensure that the team knows how to manage the CipherTrust solution in the event of churn. Staff turnover is a fact of life. Many of our clients come to us because they had “one” subject matter expert on CipherTrust, who left, and now the team doesn’t have an effective way of managing a complex solution.

In Conclusion

These recommendations merely scratch the surface of how to effectively manage CipherTrust. We consider these the fundamentals. Your implementation is unique, and may require exceptions or additional considerations. 

If you want to discuss your CipherTrust implementation in more detail, we’d be happy to connect you with a certified engineer. They can review your CipherTrust footprint and offer suggestions and considerations. 

We offer these health check services at no cost to Thales customers.

Please email us at [email protected] to correspond with an engineer.