The only difference between a normal CTE policy and a CTE policy for CIP is the use of Resource Sets with DDC classification profiles. The remaining policy creation is the same as any other standard or LDT policy. However, data transformation for a standard policy works differently with CIP. For a standard policy, initial offline data transformation on your data is not required. CIP performs encryption on sensitive files classified by a DDC scan.
For information on how to create policies, refer to the CipherTrust Transparent Encryption documentation.
Creating Resource Sets
A resource set is used to create conditional encryption and access control based on the sensitivity (aka classification). You must create a resource set of Classification type for CIP. This classification is a classification profile available on CipherTrust Data Discovery and Classification.
Open the Transparent Encryption application.
Click Policies > Policy Elements.
Click Create Resource Set. The Create Resource Set dialog box is displayed.
Enter a name for the Resource Set.
For Resource Set Type, select Classification Profile and click Next
Select an appropriate Classification Profile for your data. Click Next.
Add another Resource Set if needed, or click Save.
Creating Process Sets
You must create a Process Set in your policy. In the process set, allow CipherTrust Data Discovery and Classification binaries to have full access to all files. The binaries, which are downloaded after the first scan, are located here:
Windows: C:\Program Files (x86)\Ground Labs\Enterprise Recon 2
Your Process Set should look like the following:
Creating Security Rules
When you create a policy for remediation, you must create a Security Rule for the set of valid users who have write/read access to the sensitive files. You must also deny write/read access to users who should not have access to sensitive information.
For any user who is intended to have access to the sensitive information, set the effect permissions to: applykey: permit.
For users who are not valid, meaning they should not have access to sensitive files, set their effect permissions to: Deny. This denies them access to the resource.
For the effect options for invalid users, set it to: Audit.
Following is an example of a security rule that denies access to sensitive files to invalid users, while simultaneously granting access to valid users.
|DDC agent scan
|DDC agent scan
Creating Key Rules
Create a key rule using the classification-based resource set.
This version of Remediation has a restriction of only one key per Policy.
In CTE, set your GuardPoint on a path in the data store that contains the sensitive information that you want to scan. Use the classification-based Policy that you created for remediation. You cannot create a scan for remediation for a path that does not have a GuardPoint.
When you set a GuardPoint on a path, you cannot be on that path. Make sure that you are outside of the path on which you set the GuardPoint.
LDT Behavior with CIP
The majority of LDT functionality remains the same for CipherTrust Intelligent Remediation as well. The primary difference between LDT and CipherTrust Intelligent Remediation-based policies is during the initial encryption of the files. Following are the differences observed on LDT GuardPoints used for CIP:
Initial Encryption (Transformation)
Normally, when you use an LDT (Live Data Transformation) policy, initial transformation starts immediately after the policy is enabled with a GuardPoint. However, with CipherTrust Intelligent Protection, this sequence changes.
When using CipherTrust Intelligent Protection, encryption does not start after the policy is enabled with a GuardPoint. Encryption starts after the first scan identifies and classify the sensitive files that were defined by the DDC scan against selected classification profile. Then encryption starts, but only the sensitive files are encrypted.
LDT Status for Initial Encryption
LDT status obtained with
voradmincommands are not applicable (currently) for the initial encryption because it is not triggered with the application of a GuardPoint. Rather, it is initiated with classification. Also, this remediation is per file, and not per GuardPoint for Linux Local Data Storage only.
File Access During Initial Encryption
As CipherTrust Intelligent Protection uses the function and functionality of Live Data Transformation for performing encryption of each file, this is supported in the same way as standard LDT.
Access to Partially Encrypted Files
This is supported. The user with
apply_keypermissions can access data with partially encrypted files.
Suspend/Resume & QoS for Initial Encryption
CTE-LDT enforces Quality of Service settings while rekeying GuardPoints. Those settings are not enforced on file-level rekey operations, such as lazy rekey operations, initiated outside of the scope of the GuardPoint rekey. As CipherTrust Intelligent Remediation initiates file level rekey operations, the Quality of Service settings are not enforced on CipherTrust Intelligent Protection tasks. This is supported with Linux NAS and Windows.
Rekey to New Version (key-0 → key-1)
Remediation does not affect CTE-LDT operations while rekeying GuardPoints to a new key version.
Various scenarios can occur with LDT rekey (new version) and CipherTrust Intelligent Remediation. The following table describes the behaviors for those possibilities:
Scenario# Scenario Behavior 1 Remediation: No file is remediated yet.
Rekey: Key rotates to a new version.
Remediation on the file is performed using the newer version. 2 Remediation: Remediation is in progress on a large file.
Rekey: Key rotates to a new version before completion of remediation.
First Remediation completes and then rekey is triggered. 3 Remediation: Remediation is in progress on a large number of files, and some are remediated.
Rekey: Key rotates to a new version during the remediation process.
Remediation uses the new key for the remaining files to be remediated.
Rekey is performed on already encrypted files.
4 Remediation: Sensitive files are remediated.
Rekey: Key rotates to a new version after all sensitive files are remediated.
Regular LDT rekey is performed on all of the remediated files.
After enabling a GuardPoint during the first LDT scan, and during LDT remediation, sub-directory renaming is not supported.
NFS is supported only for LDT type policies.
• SMB/CIFS is supported only for LDT type policies.
• LFS driver is supported.
Refer to Managing LDT Communication Groups for details.
Add the client machines to LDT Communication Group.
Refer to Managing Client Groups for details.
Add the client machines to Client Group.
Client Group GP Creation
Refer to Creating LDT GuardPoints for details.
Deploy LDT GuardPoint on Client Group with SMB credentials.