Considerations Before Creating GuardPoints

Before creating GuardPoints, consider the following:

• If a client is to be added to a client group, do not apply a GuardPoint at the client level, rather, apply the GuardPoint at the client group level. You can do both, but it is harder to keep track of GuardPoints applied at the client group level and custom GuardPoints applied at the client level.

• Certain directories are protected against guarding. So plan your GuardPoints accordingly:

  Linux Platforms

  • The following directories cannot be guarded:

    • <secfs install root>/agent/secfs/

    • <install root>/agent/secfs/bin and everything under it

    • <secfs install root>/agent/vmd and everything under it

    • /etc/vormetric and everything under it

    • /etc

    • /etc/pam.d and everything under it

    • /etc/security and everything under it

    • /usr

    • /usr/lib

    • /usr/lib/pam

    • /usr/lib/security and everything under it

    • /etc/rc* and everything under it

    • /var/log/vormetric

  • You cannot apply CTE Agent protection to already mounted and guarded directories, nor can you nest GuardPoints.

    • The /opt/vormetric/DataSecurityExpert/agent/secfs/.sec directory is automatically mounted and guarded by secfs when the CTE Agent process starts on the client.

    • You cannot apply a GuardPoint to /opt because it contains the existing GuardPoint, /opt/vormetric/DataSecurityExpert/agent/secfs/.sec; however, you can guard a directory like /opt/myapps because it is in a different hierarchy and has no impact on /opt/vormetric.

    • Mounted and guarded directories can be displayed using the df command.

  Windows Platforms

  • Be careful when specifying paths for Windows agents. Cross-guarding the same folder with different policies and encryption keys returns unexpected results and corrupts the files in that folder.

  • GuardPoint paths must use standard Windows path notation and delimiters.

    • Incorrect notation and delimiters are ignored and discarded by the Windows agent. Therefore, it is possible to enter two paths that resolve to the same Windows folder and successfully guard both of them. The CipherTrust Data Security Platform Service reports that it is guarding two unique folders when, in fact, it is guarding the same folder twice.

    • Do not use any of the following characters as path delimiters: | ? < > : * " / ,

      For example, both C:\gp\ and C:\gp/\ are allowed by the CipherTrust Data Security Platform Service. When the second GuardPoint is applied, the extraneous / is discarded by the Windows CTE Agent and the Windows CTE Agent applies a GuardPoint to C:\gp\ a second time.

• Both CipherTrust Data Security Platform Service and CTE support a new enhanced encryption mode (CBC-CS1). If your client groups contain clients with older versions of CTE, you cannot apply policies containing keys that use this new encryption mode. The action fails with an error message informing you that all clients in the client group do not support the key’s encryption mode. Refer to the CTE Agent Advanced Configuration and Integration Guide specific to your platform for details.

When Changing a Policy or Rekeying a GuardPoint

• To change a policy or rekey a GuardPoint, be prepared to temporarily stop access to the GuardPoint. Changing policies for a GuardPoint requires an interruption of service because the transition process entails disabling one policy and then enabling another policy. The GuardPoint must be inactive during the transition period to ensure GuardPoint integrity. The same rule applies to moving a client between client groups when it includes a change in policies. Coordinate policy changes during a maintenance outage window.

• If LDT is enabled on your clients, encryption and rekeying of GuardPoint data is done without blocking user or application access to the data. LDT is a separately licensed feature, refer to Enabling Live Data Transformation.