Managing Policies
The primary job of a CipherTrust Manager Security Administrator is to create policies that protect data. Policies govern access to, and encryption of, the files in GuardPoints.
Overview
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.
The following criteria are processed by the policy enforcement engine:
| Criteria | Description |
|---|---|
| Order | Security rule enforcement sequence. |
| Resource | Files and/or directories to which the policy will apply, plus key rules that govern those files and directories. |
| User | Users and user groups authorized to access the resources. |
| Process | Executables which will access the files. |
| Action | Type of user access being made (read, write, copy, move etc.). Before you can define Data Transformation Rules, you must select an Action type of Key_op. |
| Effect | When all the other rules match, this describes the type of access granted or denied per the rule. |
| Browsing | Allow browsing is enabled by default, while the Enable Communication check box is enabled on the client. This allows the server to browse the client’s file system. This option can be deselected even if client communication is still enabled. |
A policy comprises Security Rules, Key Rules, and Data Transformation Rules.
Policy Rule Criteria and Effects
Policy Rules consist of five criteria, which specify the attributes of an access attempt, and effects, which define whether that access is permitted or denied, and whether encryption/decryption is required.
Policy Rule Criteria
| Criteria | Action |
|---|---|
| Resource | Files and/or directories in a GuardPoint to be blocked. Example: /secure_dir/financials. |
| User | Users or groups of users that can access the files. |
| Process | Executables that can operate on the files. |
| Action | Allowed file action. Example: read, write, remove, rename, and make directory. |
Policy Rule Effects
| Effect | Action |
|---|---|
| Permit | Allows access to the data. |
| Deny | Disallows access to the data. |
| Apply Key | Encrypts data written to a GuardPoint with the specified key. Decrypts data that is accessed using the same key. |
| Audit | Creates an entry in the Message Log that describes what is being accessed, when it is being accessed, and the security rule being applied. |
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 the secret (resource), by the user Harry (user), using the command cp (process), and includes the permission write (action).
A blank criteria field specifies a value of All. If User is blank, the rule applies to all users; if Process is blank, the rules applies to all executables, and so on. Effect can never be blank. 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, and evaluation stops when a rule is found for which all the criteria are met. The effect for that rule is then enforced. So, carefully order a policy's rules to achieve the desired result.
