Creating an LDT GuardPoint

After you have installed the license and registered the LDT host (see Installing LDT), you can create an LDT GuardPoint on the host. When you create the LDT GuardPoint, you select a Live Data Transformation policy and apply that policy with its transformation keys to that GuardPoint. CTE automatically gets the Quality of Service settings from the associated Client Profile in CipherTrust Manager.

This section describes two scenarios:

• Creating an LDT GuardPoint for an Unguarded Directory

• Converting a Standard GuardPoint to an LDT GuardPoint

Creating an LDT GuardPoint for an Unguarded Directory

To create an LDT GuardPoint on what was previously an unprotected/unguarded directory:

1. Create an Live Data Transformation policy that transforms data from clear text to a versioned key. In the policy, set Current Key to clear_key and Transformation Key to the versioned key. For details, see Creating LDT Policies.

2. Set, or modify, the Quality of Service (QoS) parameters in the Client Profile associated with the CTE client to account for LDT on all GuardPoints on this client. For details see Quality of Service.

   

   Note

   Stop all applications so that they're not accessing any data in the directory that you intend to guard/protect.

3. In the CipherTrust Manager Applications Page, select the CTE application.

4. In the Clients table, click on the name of the client you want to protect.

5. Above the GuardPoints table, click Create GuardPoint.

6. In the Create GuardPoint page:

   1. In the Policy field, select the LDT policy you created earlier.

   2. In the Type field, select the type of device. For LDT, you can select Auto Directory or Manual Directory.

   3. In the Path field, enter the directories you want to protect with this policy or click Browse to select them from a Windows-style explorer.

      If you want to enter multiple paths, put each path on its own line.

   4. Keep the Preserve Sparse Regions option selected if you want CTE to ignore sparse regions during data transformation.

      A sparse region is a region within the file size that has not yet been written to. Therefore, it is not allocated with disk blocks. Any attempt to read a sparse region reads stream of zeros as data. A file may have one or more sparse regions, or an entire file may be sparse.

      If you select Preserve Sparse Regions, LDT detects and skips transforming sparse regions. Therefore, it does not change the number of blocks utilized in the file system. This is the default.

      If you disable Preserve Sparse Regions, LDT transforms a file without checking or skipping sparse regions, if they exist. Consequently, as LDT operations transform and fill sparse regions with encrypted stream of zeros, sparse regions are allocated with disk blocks. This increases the number of disk blocks utilized in the file system.

   5. Click Create.

   6. If you want to use the same policy and GuardPoint type on another path, click Yes when prompted. Otherwise, click No.

   The CipherTrust Manager pushes the GuardPoint configuration to the client and CTE immediately beings transforming the data in the specified folders from clear-text to cipher-text.

7. Once the GuardPoint is in the Active state, you can bring applications back online. Data continues to get encrypted in the background while the application is online, according to the QoS settings defined in the policy. Once the rekeying state reaches 100%, or shows rekeyed, that means that all of the current data was successfully encrypted.

Converting a Standard GuardPoint to an LDT GuardPoint

Note

When converting a CIFS GuardPoint, ensure that the client is running the vmlfs driver and is a part of an LDT Communication Group. To determine which driver your node has installed, type: fltmc from the administrative command line. For more information, see LDT Communication Groups and LDT GuardPoint Groups.

After enabling LDT on a client, you can change a standard GuardPoint to an LDT GuardPoint. LDT GuardPoints provide the advantage of allowing users to access all files in the GuardPoints while encryption is occurring. There is no downtime for the user except for the time needed to apply the GuardPoint.

1. Clone the key:

   a. In CipherTrust Manager, navigate to the key section in the left navigation bar.

   b. For the key that needs cloning, click the (...) button at the end of the row and select clone.

   c. Type a unique name for the cloned key.

   d. Toggle CTE Versioned to on.

   e. Click Clone.

   f. Select the key and open the CTE properties tab.

   g. Verify that CTE Versioned is selected.

   

   

   Note

   • This is mandatory because keys used in Standard policies are not versioned for CTE.

2. Create a new LDT policy that transforms data from the standard/non-versioned key used in the existing GuardPoint, to an LDT versioned key.

   • Policy name: Make the new policy name the same as the standard policy name but append it with _LDTPol or something similar to differentiate it.

   • Security Rules: Create the exact same security rules that are used in the relevant standard policy.

   • Current key: Use the encryption key defined in the standard policy.

   • Transformation key: Use the corresponding cloned/versioned Key of the current key.

3. Make sure there is no application activity within the GuardPoint.

   

   Caution

   This step is critical. Do not skip it. Make sure there is no application activity within the GuardPoint.

4. Remove/Unguard the current GuardPoints.

   1. Open the CTE application and click Clients in the left-hand menu bar.

   2. Click on the name of the client whose GuardPoint you want to change.

   3. Find the GuardPoint that you want to change in the GuardPoints table, click the (...) button at the end of the row, and select Unguard.

5. Guard the directory again using the new LDT policy.

   • Use the steps above in Creating an LDT GuardPoint for an Unguarded Directory to guard the directory with the new policy.

6. Once the GuardPoint is in the Active state, you can bring applications back online. Data continues to get encrypted in the background while the application is online, according to the QoS settings defined in the policy. Once the rekeying state reaches 100%, or shows rekeyed, that means that all of the current data was successfully encrypted.