Concepts

This section describes important concepts for CTE.

Clients

A client is a computer system where the data needs to be protected. A compatible CTE Agent software is installed on the client. The CTE Agent can protect data on the client or devices connected to it. A client can be associated with multiple GuardPoints for encryption of various paths (refer to Managing GuardPoints for details).

Client Groups

A client group is used to group one or more clients to simplify configuration and administration. GuardPoints created on a client group are applied to all members of the group. Additionally, you can apply client group configuration settings to all clients in a client group. A client can be a member of multiple client groups.

If you have created a group of one type of clients, then you should only add similar clients to the group. Same configuration settings can only be applied to clients of the type with which the client group is created. If a different type of client is added, configuration settings cannot be applied to that client.

Refer to Managing GuardPoints for details on creating GuardPoints on client groups.

GuardPoints

A GuardPoint specifies the list of folders that contains paths to be protected. Access to files and encryption of files under the GuardPoint is controlled by security policies.

Refer to Managing GuardPoints for details.

Policies

A policy is a collection of rules that govern data access and encryption. Think of a policy as an if-then statement. Policy rules are processed sequentially. If the criteria of rule one are not met, the policy enforcement engine moves on to the second rule and so on.

Policies specify:

• Actors: Users, groups, and processes that are permitted/denied access to protected data.

• Actions: What actions authorized actors are allowed to perform. For example create/delete, read/write, decrypt, modify permissions, and so on.

• Files acted upon: Policy rules may apply to entire directories and mount points, or only to files named in a specific way (for example, .docx files may be encrypted and restricted to read-only access by designated users, while other files may be stored clear and read and written by anyone).

Additionally, each CTE policy specifies one or more encryption keys used to encrypt blocks of file data when applications write them, and decrypt them when they are read.

CTE encryption is transparent to applications. This means that the CTE Agent encrypts blocks of data as they are written, and decrypts data when they are read by authorized users and applications. This architecture separates administration of files from access to the data in them. Backup programs, for example, may be authorized to read files, but not view the data in them. Therefore, data can be backed up and taken offsite while remaining encrypted so that security is not breached.

A policy comprises Security Rules, Key Rules, and Data Transformation Rules.

CTE supports the following policy types:

• Standard: Access to data is blocked during initial encryption or rekeying of data.

• Live Data Transformation (LDT): Encryption and rekeying of data takes place in the background, without disrupting user or application access to that data.

• Cloud Object Storage (COS): Applicable to GuardPoints in Amazon S3 buckets. Access to data is blocked during initial encryption or rekeying of data.

• In-place Data Transformation (IDT): Access to data is blocked during encryption or rekeying of data. This policy type is needed for creating GuardPoints for Teradata clusters.

The following diagram shows the main components of a policy:

Refer to Managing Policies for details.

Security Rules

A security rule defines:

• Who can access the data (User or Group)

• What they can do with the data (Action)

• What applications or executables have access to the data (Process)

• Where the data is located (Resource)

• How the data can be accessed (Effect)

• Whether it can be enforced on the subdirectories of the GuardPoint (Browsing)

Security Rule Criteria

Security rules consist of five criteria. They specify the attributes of an access attempt, and effects, which define whether that access is permitted or denied, and whether encryption/decryption is required. The following table lists policy rule criteria.

Criteria	Description
Resource	Specifies which files and/or directories in a GuardPoint are to be protected. For example, /secure_dir/financials.
User	Specifies a which users or groups of users can access the files.
Process	Specifies executables that can operate on the files.
Action	Specifies the allowed file action. Action could be read, write, remove, rename, and make directory. Refer to Actions for the complete list of supported actions.
Effect	Describes the type of access granted or denied according to the rule. Refer to Security Rule Effects for the list of supported effects.

Actions

An action is an attempt to access protected data in some way. Action specifies the type of file and directory action (read, write, delete, and rename etc.) allowed on a GuardPoint. A policy provides a wide range of access methods to specify the action required for the security rule. The action is identified, evaluated, and used as a factor in determining whether or not to grant access. Specifying an access method is optional. If you do not specify one, the policy defaults to all_ops, or "all operations".

Any action that starts with d_ applies to directories. Any action that starts with f_ applies to files. Only a few actions are available for COS and IDT policies.

The following table lists all basic and advanced actions:

Basic Actions

Action	Description	Policy Types
all_ops	All operations. Users can access the data using any method. all_ops is the default action (when no action is specified).	All
read	Read operations. This is a collection of actions related to reading files, directories, and their attributes. The read action comprises f_rd, f_rd_att, f_rd_sec, d_rd, d_rd_attr, and d_rd_sec.	Standard, IDT, LDT
write	Write operations. This is a collection of actions related to writing to files, directories, and their attributes. The write action comprises f_wr, f_cre, f_ren, f_rm, f_link, f_chg_attr, f_chg_sec, d_ren, d_chg_att, d_chg_sec, d_mkdir, and d_rmdir.	Standard, IDT, LDT
key_op	Key operations. It requires two keys. One key is specified on the Add Security Rules screen and the other on the Add Data Transformation Rules screen. The encryption keys for the current security rule are specified on the Add Security Rules screen. The keys to migrate data from an encrypted form to a non-encrypted form or to change the encryption keys used to access the data are specified on the Data Transformation Rules screen.	Standard, LDT

Advanced Actions

Action	Description	Policy Types
f_rd	Read a file.	Standard, LDT, COS
f_wr	Write to an existing file.	Standard, LDT, COS
f_wr_app	Append data to a file.	Standard, LDT
f_cre	Create a new file.	Standard, LDT
f_ren	Rename a file.	Standard, LDT
f_link	Link to a file (for example, ln file_name link_name).	Standard, LDT
f_rm	Remove/delete a file.	Standard, LDT, COS
f_rd_att	Read the attributes of a file (for example, ls -l file).	Standard, LDT
f_chg_att	Change file attributes (for example, chmod).	Standard, LDT
f_rd_sec	View the security properties of a file.	Standard, LDT
f_chg_sec	Change any security property of a file.	Standard, LDT
d_rd	View directory contents (for example, ls dir; cd dir).	Standard, LDT, COS
d_ren	Rename a directory (for example, mv dir1 dir2).	Standard, LDT
d_rd_att	Read the attributes of a directory (for example, ls -la dir1).	Standard, LDT
d_chg_att	Change directory attributes (for example, chown usr dir1).	Standard, LDT
d_rd_sec	View the security properties of a directory.	Standard, LDT
d_chg_sec	Change any security property of a directory.	Standard, LDT
d_mkdir	Make a new directory.	Standard, LDT
d_rmdir	Delete a directory (for example, rm -r dir1).	Standard, LDT

Security Rule Effects

An effect describes the type of access granted or denied according to the rule. The following table lists policy effects that can be applied to GuardPoints.

Effect	Description
Permit	Allows access attempts to the resource. For example, you can specify an effect that allows writing to a directory.
Deny	Denies access attempts to the resource. For example, you can specify an effect that denies any attempts to access a resource.
ApplyKey	Applies an encryption key to the data in a GuardPoint. When applied, the data copied to the GuardPoint is encrypted with the specified key. When the data in the GuardPoint is accessed, it is decrypted using the same key.
Audit	Creates a message log entry for each qualifying event that records who is accessing what information and when.

How Security Policy Works

Every time a user’s application tries to access a GuardPoint file, the security policy tests that access attempt against the criteria of each rule. For example, suppose a user, Harry, wants to access and modify a file called secret, using the command cp. For Harry to be successful, there must be a rule that allows access to secret (resource), by user Harry (user), using the command cp (process), and includes the permission write (action).

• If criteria is not specified, a value of All is used.

• If resource is not specified, the rule applies to all resources.

• If user is not specified, the rule applies to all users.

• If process is not specified, the rules apply to all executables, and so on.

• Effect cannot be left unspecified. It must have at least a permit (allow access) or deny (disallow access).

A policy can have multiple rules. Rules are evaluated much like firewall rules. They are evaluated in order, from first to last. Evaluation stops when a rule is found for which all the criteria are met. The effect for that rule is then enforced. Therefore, you must carefully order a policy's rules to achieve the desired result.

Resource Sets

A resource is a combination of a directory, a file, and patterns or special variables. A resource set is a named collection of directories, files, or both, that a user or process will be permitted or denied access to.

Refer to Creating Resource Sets for details on creating resource sets.

User Sets

A user set is a collection of users and user groups that you want to grant or deny access to GuardPoints. User sets are configured in policies. Policies can be applied to user sets, not to individual users.

Refer to Creating User Sets for details on creating user sets.

Signature Sets

A signature set is a collection of hashes of processes and executables that you want to grant or deny access to GuardPoints. A signature set can be configured in a policy as part of a process set to verify the integrity of a process before it is allowed access to guarded data. Policies are applied to signature sets, not to individual signatures.

A cryptographic hash is created for each file in a signature set that meets a specific criterion. It would take longer, bloat the CipherTrust Data Security Platform Service database, and reduce performance to sign all the files in a signature set, especially when the set comprises top-level directories. The criteria is listed below. All other files are skipped.

Executables accessing a GuardPoint can be inside or outside the GuardPoint. If they are inside:

• On a Windows client, all files in a signature set that are inside a GuardPoint are signed. Only the compiled Windows executables in the signature set that are outside the GuardPoint are signed. Non-executables outside the GuardPoint are not signed.

• On a UNIX client, it makes no difference whether the files are inside or outside a GuardPoint. Only the files in a signature set with one or more execute bits set (for example, -rwxrwxrw-) are signed.

• File extension has no impact. Even files like the following are skipped:

  • [On Windows] .bat and Visual Basic programs if they are not inside a GuardPoint

  • [On Linux] .so files if they do not have an execute bit set

Every instance of a file that is copied to a different location or to a different name will have the same signature. This can be a convenient way to detect duplicate files on your system.

By default, a generic error message is displayed about a non-existent source being detected. The name of the offending file or directory is not specified. However, it is specified in the Agent log on the client. Review the logs to:

• Identify the offending file or directory.

• Determine how many files were affected, what file "is invalid for the signature request".

• Identify the files that were not signed. Look for files with "is invalid for the signature request".

Refer to Managing Signature Sets for details on the signing process.

Process Sets

A process set is a collection of processes (executables) that you want to grant or deny access to GuardPoints. Like user sets, process sets can be configured in policies. Policies can be applied to process sets, not to individual processes.

Optionally, file signing can be configured to check the authenticity and integrity of executables and applications before they are allowed to access GuardPoint data. A signature set must already exist before you can configure file signing in a policy for a process set.

Refer to Creating Process Sets for details on creating process sets.

Key Rules

A key rule defines the encryption key to apply to a specific resource set or the encryption key to use as the default key, if no other key rule matches. The key rule defines the sequence in which the key rules are to be executed (Order), the location of the data to be encrypted (Resource), and the encryption key to be applied to the resource set (Key).

When defining a key rule for an LDT policy, you can select a key that is applied to the resource set (Current Key Name) and the key to use to rekey that resource set (Transformation Key Name).

Data Transformation Rules

Data transformation rules define:

• Resources to be protected

• Symmetric encryption key to use for

  • Rekeying the specified resources from one encryption key to a different key or

  • Rekeying resources into a plaintext format (also referred to as clear, unencrypted, or decrypted)

Profiles

A profile contains the CipherTrust Data Security Platform Service logging criteria for CTE clients, Syslog server configuration, default logging level, LDT Quality of Service (QoS) settings, and other settings that can be used for several CTE clients.

A default profile, DefaultClientProfile, is created automatically when either of the following happens:

• On successful registration of the first client if no profile is specified during registration.

• On creation of the first client group. A new client group is automatically linked to DefaultClientProfile.

When registering a CTE client, the installer prompts to specify a profile for the client. If not specified, DefaultClientProfile is automatically linked to the client on successful registration. The linked profile can be modified later.

Refer to Managing Profiles.

Learn Mode

Learn Mode permits a policy to be tested without actually denying access to the GuardPoint. In Learn Mode, all actions that would have been denied are instead permitted, but logged. This allows you to test policies by tracking how rules are evaluated, without enforcing the policy. Monitor the log to determine how data is being accessed, then modify the policy accordingly.

In Learn Mode:

• If the policy contains a security rule with the effect permission Permit and the effect option ApplyKey, then a security rule with the permission Deny MUST include the option ApplyKey. If it does not include the option ApplyKey, a user with the Deny permission can overwrite or edit data, which can corrupt the data.

• Effect permission Deny has the same effect as Permit, and Deny ApplyKey has the same effect as Permit ApplyKey.

This option generates an ERROR log every time an access attempt is made that matches any security rule in the policy. The ERROR log is labeled [LEARN MODE] and can be viewed in the CTE Agent logs.

Learn Mode is recommended for policies that restrict applications (process sets). Many applications use multiple binaries that may not be known to the creator of the policy at the time of creation. So, Learn Mode should be enabled when creating policies for such applications.

User Roles

CTE has the CTE Admins and CTE Clients users with different responsibilities in administering and using the system.

CTE Admins

Initially, there is a System Defined Group named "CTE Admins". Users within the "CTE Admins" group are CTE Administrators.

A CTE Administrator is responsible for creating and managing the following resources:

• Clients and client groups

• Profiles, policy elements, and policies

• GuardPoints

• Client registration tokens (with additional rights of System Defined Group named "Client Admins")

CTE Clients

There is a System Defined Group named "CTE Clients". CTE clients registered with the CipherTrust Data Security Platform Service are part of this group.

Multifactor Authentication

In Multifactor Authentication (MFA), access to the requested data is granted only after the requester satisfies two or more authentication criteria.

CTE adds an extra layer of security before granting access to the protected GuardPoints. If MFA is enabled, the users performing specific tasks on the configured GuardPoints need to perform an additional OpenID Connect (OIDC) based authentication.

MFA can be helpful in scenarios such as when the credentials of a client machine are compromised. As an additional level of authentication is enforced, the data security cannot be breached.

Refer to Multifactor Authentication for details.