CTE Policies

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.

1. Open the Transparent Encryption application.

2. Click Policies > Policy Elements.

3. Click Create Resource Set. The Create Resource Set dialog box is displayed.

4. Enter a name for the Resource Set.

5. For Resource Set Type, select Classification Profile and click Next

6. Select an appropriate Classification Profile for your data. Click Next.

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

• Linux: /var/lib/er2/

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

Creating Key Rules

Create a key rule using the classification-based resource set.

Creating GuardPoints

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.

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 voradmin commands 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_key permissions 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.

• Renaming Subdirectories

  After enabling a GuardPoint during the first LDT scan, and during LDT remediation, sub-directory renaming is not supported.

NFS GuardPoint

The same CIP policy rules (security rules and key rules) are applicable to NFS GuardPoint policy.

SMB/CIFS Policy

The same CIP policy rules (security rules and key rules) are applicable to SMB/CIFS policy.

LDT Group

Refer to Managing LDT Communication Groups for details.

Client Group

Refer to Managing Client Groups for details.

Client Group GP Creation

Refer to Creating LDT GuardPoints for details.