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).
CTE also supports Kubernetes (K8s) clients. Refer to Kubernetes Clients.
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.
Kubernetes Clients
Unlike a traditional CTE Agent, a Kubernetes (K8s) client runs as a K8s pod. Multiple pods can run on a single K8s node. Every pod protects the K8s persistent volumes attached to it using a CTE for Kubernetes policy received from the CipherTrust Manager.
The name of a K8s client is a combination of:
The node on which the K8s client is running
The linked K8s StorageClass
The namespace where the K8s client pod runs
A random string attached automatically
So, the format of K8s client name is <node-name>_<csi-storage-class>_<csi-namespace>_<random-string>, for example, node1_K8sStorageClass1_K8sNamespace1_f2eaa752.
Kubernetes Storage Groups
A Kubernetes (K8s) storage group is a logical group of multiple K8s clients with the same K8s namespace and K8s StorageClass. The group helps simplify K8s configuration and administration across K8s clients. GuardPolicies created on a storage group are applied to all members of the group.
A K8s client can be a member of one storage group only.
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.
GuardPolicies
A GuardPolicy, which is similar to a CTE GuardPoint, can be attached to a K8s storage group only. It is inherited by the K8s clients attached to the storage group.
Only the policies of type CTE for Kubernetes can be included in a K8s GuardPolicy. As CTE for K8s protects a volume not a specific path, the GuardPath is automatically set to the CTE for Kubernetes policy name prefixed with a slash (/).
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.
CTE for Kubernetes: Applicable to GuardPolicies for CTE for Kubernetes clients. Access to data is blocked during initial encryption or rekeying of data.
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 Manager 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]
.batand Visual Basic programs if they are not inside a GuardPoint[On Linux]
.sofiles 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).
Note
Keys are created and stored on a CipherTrust Manager appliance.
Data Transformation Rules
Data transformation (dataxform) 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)
Signature Rules
A signature rule is a type of signature sets that contains container image signatures. Signature rules can only be associated with CTE for Kubernetes policies.
Profiles
A profile contains the CipherTrust Manager 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.
Tip
It is recommended to not delete or modify DefaultClientProfile.
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 or under Records on the CipherTrust Manager GUI (if the log level is configured as ERROR).
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.
Note
Use Learn Mode to analyze access patterns and make informed decisions about final encryption policies. Do not keep Learn Mode running for long time.
User Roles
CTE has the CTE Admins and CTE Clients users with different responsibilities in administering and using the system.
Caution
It is critical that credentials of these users are kept in a secure location. If a credential is compromised, an attacker could gain access to sensitive data.
Note
Additionally, the CipherTrust Manager provides an option to create customized groups for CTE to control permissions on CTE resources. Refer to Customized Groups for CTE for details.
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 "CA Admins")
Note
Only the users of the "CTE Admins" group can delete CTE keys.
CTE Clients
There is a System Defined Group named "CTE Clients". CTE clients registered with the CipherTrust Manager are part of this group.
Cluster Node Preference
A CTE administrator can configure preferred nodes of a CipherTrust Manager cluster for sending status updates from CTE clients. The administrator assigns a priority to every node of the cluster.
The cluster nodes can be categorized into tiers on the CipherTrust Manager GUI, with every tier assigned a priority. For example, Tier 1 is assigned higher priority than Tier 2. All tiers (for example, Tier 1 + Tier 2) can have a total of 20 nodes. This preference is configured through server settings in profiles. If not configured, the CipherTrust Manager continues working with the default settings. Refer to Communication with CipherTrust Manager for the default behavior.
After the server settings are configured, the CTE clients associated with the profile first try to send status updates to the top tier. If none of the nodes in the tier is reachable, the CTE clients try to send updates to the next tier.
This feature is applicable to the CipherTrust Manager clusters.
Multifactor Authentication
In Multifactor Authentication (MFA), access to the requested data is granted only after the requester satisfies two or more authentication criteria.
Note
MFA is applicable to the MFA-capable CTE for Windows clients.
CTE for Windows 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.
