User's Guide: Logging

1.0  Introduction: Audit Log

This article describes how to integrate Fortanix-Data-Security-Manager (DSM) with External logging systems. Fortanix DSM automatically maintains an internal audit log of system operations. You can configure Fortanix DSM to send these audit log entries to an external logging system. In this article you will learn how to send Fortanix DSM audit logs to the following external logging systems:

• Splunk

• Google Cloud’s operations suite

• Syslog Server

• Azure Log Analytics (Azure Monitor)

Typical enterprises have a requirement to collect and maintain logs of all systems including Fortanix DSM in a single place. Enterprises write rules with external logging systems such as Splunk, Google Cloud’s operations suite, Syslog, and Azure Log Analytics to define rules and generate actions such as alerts, emails, and so on to match on logs or events. Fortanix DSM supports pushing logs/system events to Splunk, Google Cloud’s operations suite, Syslog, and Azure Log Analytics for external logging.

2.0  Fortanix Data Security Manager External Logging

2.1 Fortanix Data Security Manager Audit Log

The Fortanix DSM external event logging is configured on a per-account basis. Logs/events of an account are not visible to another account within an enterprise. Fortanix DSM automatically maintains an internal audit log of system operations. To view the audit log:

1. Click the Audit Log tab in the Fortanix DSM UI.
   For convenience, when viewing the details of a Security-object and other Fortanix DSM objects, the most recent audit log entries applicable to the object are shown in the right-hand pane in the detailed view of a security object.

2.2 Set Retention Period for Audit Log

By default, audit log entries older than 3 months are automatically deleted. The following steps describe how to set the retention period of audit logs for each account:

1. In the Fortanix DSM UI, click the LOG MANAGEMENT tab on the Account settings page.

2. Click EDIT to set the retention period for audit logs.

3. To permanently retain the audit logs, select the Keep log entries forever option or set it to a future date.

4. Click SAVE to save the changes.

2.3 Log Invalid API Requests

Sometimes applications encounter invalid API requests that lead to 4XX errors, such as 400 (bad request) type error. To debug an application against 4XX errors, the Fortanix DSM enables audit logging for such errors using the Log Management feature. To enable this:

1. In the Fortanix DSM UI, go to LOG MANAGEMENT option in the Account settings page.

2. Enable the toggle for Logging invalid API requests. 

3. To see the 4XX logs, click the Audit Log tab in the Fortanix DSM UI. 

2.4 High Volume Security Objects

In scenarios where a security object is used for very high-usage cryptographic operations, audit logging related to these operations can be explicitly disabled for the security object. This is the only scenario where audit logs can be disabled for an object.

To disable the audit log on an existing security object:

1. Go to the detailed view of the security object and disable the Keep detailed log for the object toggle. 

2. If the group has a quorum policy set, then you will see “HIGHVOLUME” in the “Key operations permitted” section of the “Quorum approval request” dialog. The presence of HIGHVOLUME operation indicates that the audit log is requested to be disabled. 

To disable the audit log for a security object during object creation:

1. Scroll to the bottom of the Security Object Create/Import page.

2. Clear Keep detailed log for the object option. 

2.5 Log Management

Currently, Fortanix DSM supports the following logging systems:

• Splunk

• Google Cloud’s operations suite

• Syslog

• Azure Log Analytics (Azure Monitor)

To integrate with the above logging systems, click the Settings tab in the Fortanix DSM UI left pane, and then click the LOG MANAGEMENT tab. It will give you three options for integration: Splunk, Google Cloud’s operations suite, Syslog and Azure Log Analytics. It is possible to have more than one integration active at the same time. Logs will be pushed from Fortanix DSM to all logging facilities that are configured.

2.6 Sending Audit Logs to Splunk

You can configure Fortanix DSM to send audit log entries to a Splunk server using the HTTP Event Collector (HEC).

 To configure logging events to Splunk,

1. Click the Settings icon in the Fortanix DSM UI.

2. Click the LOG MANAGEMENT tab from the left panel.

3. In the Custom Log Management Integrations section, click the ADD INTEGRATION button for Splunk. 

4. Configuring a Splunk integration requires the following information:

   1. Enter the IP Address or the hostname of your Splunk server.

      1. Select Enable HTTPS to communicate with the Splunk server over HTTPS (recommended) and also select the Enable SSL checkbox in the Splunk Global Settings. Refer to the Appendix for the screenshot. 

         NOTE

         If you are using an HTTP connection, then clear the Enable HTTPS checkbox in the Fortanix DSM Log Management screen and also clear the Enable SSL checkbox in the Splunk Global Settings. Refer to the Appendix for the screenshot.

         Depending on the type of TLS certificate the Splunk server is using:

      2. Select Global Root CAs if you are using a certificate that is signed by a well-known public CA.

      3. Select Custom CA Certificate, if you as an enterprise want to self-sign the certificate using your own internal CA. To do this, upload the CA certificate using the UPLOAD A FILE button. When Fortanix DSM as a client connects to the Splunk server and is presented the server’s certificate, it will be able to validate it using the enrolled custom CA Certificate. To generate the CA certificate, run the following command:

         openssl s_client -connect <endoint/ipaddress>:port -showcerts

         Where,

         • ipaddress: is the IP address of the Splunk server.

         • port: is the value of the Management port, under Server settings->General settings in the Splunk Server. Refer to the Appendix for the screenshot.

      4. In case the Custom CA Certificate has a Common Name (CN) that does not match with the server in which Splunk is deployed, clear the Validate Hostname checkbox which prompts Fortanix DSM to ignore the hostname of the Splunk deployment instance. Only the certificate chain will be validated in this case.

   2. The default Port number is 80. If you are running on a different port, add the applicable port number. If you enable HTTPS in "Step a" above, then the default port number is 443.

   3. Add the name of the Splunk index in the Index field to submit events. The index value should be the same as the index in Splunk. Refer to the Appendix for the screenshot. When you push the logs to Splunk, you need to push it to a specific index. This value is sent to the Splunk server and can be set to whatever you like. This will allow distinguishing logs from different sources. For example, the logs from Fortanix DSM can be pushed to the Index source name SDKMS.

   4. Enter a valid Authentication token to authenticate to the HTTP Event Collector of your Splunk instance. The Authentication token will authenticate Fortanix DSM as a client to Splunk and allows it to push the events to Splunk. See the Splunk documentation for details about generating HEC authentication tokens.  

      NOTE

      For security reasons, the authentication token is not displayed in the interface when editing an existing configuration.

5. Click ADD INTEGRATION to save the Splunk integration.

2.7 Sending Audit Logs to Google Cloud’s operations suite

You can configure Fortanix DSM to send audit log entries to Google Cloud’s operations suite.

To configure logging events to Google Cloud’s operations suite,

1. In the Custom Log Management Integrations section, click the ADD INTEGRATION button for Google Cloud’s operations suite. 

2. Log ID is the ID of the log to write to. Log ID must be a URL-encoded within the Log Name. Log Name is the resource name of the log to which this log entry belongs. For example, organizations/1234567890/logs/cloudresourcemanager.googleapis.com%2Factivity
   For more information, see Google Cloud’s operations suite reference URL.

3. Upload the Service account key or configuration file. To connect to Google Cloud’s operations suite, you will need a configuration file that contains the Service account key and other information. Upload this configuration file using the UPLOAD A FILE button. 

4. Click ADD INTEGRATION to save the integration.

2.8 Sending Audit Logs to Syslog

You can configure Fortanix DSM to send audit log entries to the Syslog server. 

To configure logging events to Syslog,

1. In the Custom Log Management Integrations section, click the ADD INTEGRATION button for Syslog.

2. Configuring a Syslog management integration requires the following information:

   1. Enter the Hostname or IP address of your Syslog server.

   2. Select the Enable TLS check box to enable the host validation.

   3. Select the Validate host check box to verify that the host mentioned in Step a matches the host name in the server certificate.

   4. You can communicate with a Syslog server either over a non-secure connection or a secure connection using TLS. Depending on the type of TLS certificate that the Syslog server is using,

      1. Select Global Root CAs, if you are using a certificate signed by a well-known public CA.

      2. Select Custom CA Certificate, if you as an enterprise want to self-sign the certificate using your own internal CA. To do this, upload the CA certificate using the UPLOAD A FILE button. When Fortanix DSM as a client connects to the Syslog server and is presented with the server’s certificate, it will be able to validate it using the enrolled custom CA Certificate.

   5. The default Port number is TCP 514 at which the server must listen for Syslog messages. If you are running on a different port, change to the applicable port number.

   6. When you log an event in Syslog, you can choose to log it in different facilities. This allows you to filter your log for a specific facility. The facilities appearing in the Facility list are well-defined facilities in the Syslog protocol. For example, User, Local0, Local1, and so on. You can configure the Fortanix DSM system to use the Local0 facility for instance. This will help in filtering logs from a particular appliance using a facility. 

3. Click ADD INTEGRATION to save the integration.

2.9 Sending Audit Logs to Azure Log Analytics

You can configure Fortanix DSM to send audit log entries to Azure Log Analytics in the Azure Portal to write log queries and interactively analyse the Fortanix DSM log data.

Perform the following steps to configure logging events to the Azure Log Analytics:

1. Ensure that you have an already create a Log Analytics Workspace in Azure portal. For more information, refer to Create a Log Analytics workspace. In the log analytics workspace, click the Agents tab to see the Workspace ID and Primary key.

   

2. In the Custom Log Management Integrations section, click the ADD INTEGRATION button for Azure Log Analytics.

   

3. On the Azure Log Management Integration page, enter the following:

   1. Enter the Workspace ID which is the Log Analytics workspace ID in the Azure portal from Step 1. It is a GUID to identify the specific log analytics workspace in the Azure cloud. For more information on how to create a log-analytics workspace, refer to Create a Log Analytics Workspace.  

   2. Enter the Primary shared key which is the Log Analytics workspace primary key from in the Azure portal from Step 1.

      

      NOTE

      For security reasons, the Primary Shared Key is not displayed in the interface when editing an existing shared key.

4. Click SAVE CHANGES to save the Azure Log Analytics integration.

5. In the Azure portal, execute the following query in Log Analytics and click Run button:

   DSM_AUDIT_LOG_CL 

   

   Running the query retrieves Fortanix DSM audit log entries from Azure Log Analytics, allowing you to analyze, filter, and monitor them.

6. The Custom Log Type is set to “DSM_AUDIT_LOG_CL” for all event logs published to Azure Log collector from Fortanix services. This field is set in HTTP POST request header of all the logs published to the Azure log collector and therefore it is used to query logs from Fortanix services in Azure Log Analytics Workspace. For more information, refer to Use Queries in Log Analytics.

   

2.10 Sending Audit Logs to Rapid7 InsightIDR

For a detailed list of instructions on how to export the Fortanix DSM log files to the Rapid7 InsightIDR centralized log management utility, refer to Using Fortanix DSM with Rapid7 InsightIDR.

2.11 Log Structure

A system event in Fortanix DSM generates a log that has the following components:

1. Log Severity – Severity of the message (Critical issues, Errors, Warnings, and Info). As of today, the backend for Logging only supports the Severities – “Info” and “Errors”. A severity is logged as “Error” when logging requests have failed for some reason such as client error or internal server error. For all the other cases where the audit logs describe crypto operations, object updates and so on the severity is logged as “Info”.

2. Groups – The Fortanix DSM group that the event belongs to.

3. IP-Address – This is the IP address of the client/user whose request triggered the log message. The client IP is recorded whenever it is available. For some logs, the IP-Address field might appear empty due to one of the following reasons:

   • When Kubernetes is used for load balancing instead of an external load balancer, Kubernetes reroutes requests and does not preserve the original client IP address. This is something Fortanix will address in the future.

   • Since this was a new field introduced recently the older logs would have the IP_Address field empty.

4. Apps/Users – The log message can be a user event or application event.

5. Time – Timestamp of when the event occurred.

6. Type – Type of event (Administrative, Auth, and Crypto Operations).

   • Administrative - Operations that users can perform such as importing/updating/deleting a key and creating/deleting/updating apps, groups, and accounts are classified as “Administrative” events.

   • Crypto Operation – Operations such as generating/encrypting/decrypting/signing/verifying/wrapping/unwrapping a key are classified as “Crypto Operation” events.

   • Auth – Operations such as logging in or logging out, applications authenticating to get a session, or terminating their session are classified as “Auth” events.

When a log is pushed to a third-party external logging system, the log structure with all the log components above is sent to the server.

The format of a message logged on any external logging system is as follows:

<message string> ip_addr=<corresponding client ip address> acct_id=<corresponding account id> groups=[corresponding group ids] actor=<Actor type>:<Actor Id> obj=<Object Id> action=<Action type>

Where,

• All the ids are UUID of the respective object

• Actor type can be a User or App

• Action type can be Administrative, Auth, or Crypto Operation

For Example,

User "[email protected]" created key "key_test" acct_id=8fb9b132-0b68-4d33-aba2-f1f9db3ab0e9 groups=[5f1d12e9-614a-4f5b-a4ed-837d9fb001b8] actor=User:9dbd5192-ee09-46f6-89fd-812e96863aa4 obj=3da3bf54-610b-4e89-816d-d4931f59f102 action=CRYPTOOPERATION

3.0 Appendix

Following are the Splunk Server screenshots:

If you are using an HTTPS connection, then in the Global Settings:

• Select the Enable SSL check box.

• Select the Default Source Type as sdkms_audit.

  

• Port number on the Splunk server used for generating Custom CA Certificate.

  

• The index value in the Fortanix DSM Splunk Log Management Integration form should be the same as the Default Index value.