Records

Audit records are logs of auditable events in CipherTrust Manager. To view these records in the GUI, go to Key & Access Management > Records > Server Records.

You can also view the records that are uploaded from the CipherTrust Manager Clients (for example, CTE). To view these records in the GUI, go to Key & Access Management > Records > Client Records.

Audit records can be fetched and searched using the CipherTrust Manager REST API, CLI, or the GUI.

Server Records Parameters

Enabling NAE Crypto Audit Records

CipherTrust Manager can be configured to keep a record of various NAE cryptographic operations that are performed by CipherTrust Manager appliance.

To record NAE cryptographic operations and activities:

1. Go to Admin Settings > System > Properties.

2. Under the Audit Record Settings, enable NAE Crypto Audit Records option.

   CipherTrust Manager will now log all NAE related operations and activities. To view these logs, go to Keys & Access Management > Records > Server Records.

   Note

   • Logging NAE Crypto activities is a memory-intensive task, as thousands of such cryptographic operations are performed every second. Thus, enabling this setting causes a significant drop in NAE performance and Crypto Operations.
   • NAE Crypto Audit Records are logged within 30 seconds after the occurrence of an operation activity.

Disabling local database audit logging

Audit records are logged to a local database by default. This is suitable for production systems and clusters with a limited load. However, for clusters that support a large number of transactions, it is recommended to configure CipherTrust Manager to disable logging to a local database and enable logging using a remote Syslog server. This significantly reduces cluster traffic and disk usage.

Example

ksctl properties modify -n ENABLE_RECORDS_DB_STORE -p false

To list all records:

ksctl records list

The response looks like:

{
  "skip": 0,
  "limit": 10,
  "total": 40,
  "Resources": [
    {
    "id": "18ef98f1-0704-4dec-a6f0-e87a581ce52f",
    "uri": "kylo:kylo:audit:records:18ef98f1-0704-4dec-a6f0-e87a581ce52f",
    "account": "kylo:kylo:admin:accounts:kylo",
    "application": "system:system:admin:applications:system",
    "devAccount": "kylo:kylo:admin:accounts:kylo",
    "createdAt": "2018-05-22T18:34:05.239823Z",
    "message": "Create Token",
    "service": "kylo",
    "requestId": "45a8dcef-0b9e-44e2-b3e1-51b3d2ef99ca",
    "instanceId": "",
    "instanceTime": "0001-01-01T00:00:00Z",
    "instanceTz": "",
    "success": true,
    "username": ""
    }
  ]
}

There will be a number of records returned (10 shown in the example above). Most have been removed in the above example for space reasons. Note that the response indicates that there are 40 records available ("total": 40,). These records can be returned with options in the ksctl records commands. Type the following command to get more information:

ksctl records list --help

Configuring remote Syslog server

Audit records can optionally be sent to one or more external Syslog server(s). By default, audit records are stored in the local database and continue to do so even if Syslog connections are configured. Each audit record will be sent to each configured Syslog connection.

A Syslog connection can either use UDP or TCP + TLS as the transport protocol. When TCP + TLS is used a trusted CA certificate in PEM format must also be provided.

All Syslog messages are generated with severity notice and facility local0.

An example entry looks as follows:

2019-08-12 06:22:16 keysecure1 KeySecure: <134>1 2019-08-12 06:22:16 keysecure KeySecure - b7999852-dd64-46e9-b924-c3999eca9fad [msg="Update Syslog Connection" sev="6" details="'Update Syslog Connection' succeeded”
({"createdAt":"2019-08-12T06:22:16.113081Z", "details":{"id":"e847e529-d331-45f9-a494-83ee7ce6ab69"},"message":"Update Syslog Connection","service":"kylo","success":true,"username":"admin","severity":"info","lineage":"","source":""})"]

The first time stamp is generated and added by Syslog and the second time stamp is the time of the actual audit record.

In a multi-node clustered environment, the Syslog connection configurations are automatically synchronized and each node is aware of all Syslog servers. The Syslog message is sent from the currently active node. This means that if an event that results in an audit record is performed on node 1, the Syslog message originates from node 1. Similarly, if an audit event is performed on node 2, the Syslog message originates from node 2.

Syslog Connections API

The Syslog connections API supports listing, adding, deleting, getting, and updating Syslog connections. Refer to the API guide, CLI Guide, or the GUI for more details.

Refer to Syslogs for instructions on configuring connection to a Syslog server on the CipherTrust Manager console.

Configuring alarm triggers based on an audit record

The audit system can be configured to trigger one or more alarms based on the content of a record. To create an alarm configuration:

1. Log on to the CipherTrust Manager console as administrator.

2. Click Keys & Access Management to open the application.

3. In the left pane, click Records. The Records page is displayed on the right.

4. Click the Alarm Configurations tab.

5. Click Configure Alarm Configuration. The Alarm Config - Create dialog box is displayed.
   Specify the following details:

   1. Severity: Defines the nature of the alarm. It can be Info, Error, Critical, or Warning.

   2. Name: Name of the alarm.

   3. ErrorThreshold: The maximum number of times the trigger condition is met in the specified time Interval before the alarm is raised.

   4. Interval: The time duration in seconds, in which if the trigger condition is met for a defined number of times (Error Threshold value) , the alarm is raised.

   5. Description: A description for the alarm.

   6. Condition: Conditional properties/events that will triggers an alarm.

      Note

      Multiple alarms may be triggered using a single record.

Example (For Windows)

ksctl records alarm-configs create --name "Weak RSA Key" --description "RSA key should be 2048 bits or higher" --severity "critical" --condition "input.success; input.message == \"Create Key\"; input.details.algorithm == \"RSA\"; input.details.size <= 1024"

Example (For Linux)

ksctl records alarm-configs create --name "Weak RSA Key" --description "RSA key should be 2048 bits or higher" --severity critical --condition 'input.success; input.message == "Create Key"; input.details.algorithm == "RSA"; input.details.size <= 1024'

Response (For Windows and Linux):

{
  "id": "4bf23269-3985-42f3-995c-8f3c8f8b6543",
  "uri": "kylo:kylo:audit:alarm-configs:4bf23269-3985-42f3-995c-8f3c8f8b6543",
  "account": "kylo:kylo:admin:accounts:kylo",
  "application": "ncryptify:gemalto:admin:apps:kylo",
  "devAccount": "ncryptify:gemalto:admin:accounts:gemalto",
  "createdAt": "2019-08-27T14:37:19.145946719Z",
  "name": "Weak RSA Key",
  "condition": "input.success; input.message == \"Create Key\"; input.details.algorithm == \"RSA\"; input.details.size <= 1024",
  "description": "RSA key should be 2048 bits or higher",
  "severity": "critical"
}

To trigger this alarm, create a weak RSA key:

ksctl keys create --name mysmallkey --alg RSA --size 1024

The alarm should be triggered and this can be confirmed by listing the alarms:

ksctl alarms list --state on

Here is an abbreviated response for brevity:

{
  "resources": [
    {
      "name": "Weak RSA Key",
      "state": "on",
      "description": "RSA key should be 2048 bits or higher",
      "severity": "critical",
      "details": {
        "details": {
          "id": "f2ec44f6977edf2d6ff7fa327b5499301732dc6b395284a71e47ac0346cf72d6",
          "uri": "kylo:kylo:vault:keys:mysmallkey-v0",
          "name": "mysmallkey",
          "size": 1024,
          "ownerId": "local|fa0e4dfa-e6fd-413b-a4a0-48c356cf0557",
          "algorithm": "RSA",
          "usageMask": 3,
          "objectType": "Private Key"
        },
        "message": "Create Key",
        "success": true,
      }
    }
  ]
}

Creating Alarm Trigger for Certificate Expiration

If it is desired to create an Alarm Trigger (and receive Email Notifications) for these events, follow the steps mentioned in Configuring alarm triggers based on an audit record section, and specify the Condtion action as input.message == "Certificate Expiry Check".

After saving this Alarm Configuration, the recipients in the email address list will receive email notifications every time a certificate expiration related record is logged. The emails will contain the certificate IDs, expiration dates, and the domain name.