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.

  • 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.

• Both CipherTrust Manager 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 UserSpace Agent Advanced Configuration Guide 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.