Configuring and Using Audit Logging

This section describes the procedures required to enable audit logging, configure it to specify what is logged and how often the logs are rotated, and how to copy, verify and read the audit logs. It contains the following information:

>Configuring Audit Logging

>Exporting the Audit Logging Secret and Importing to a Verifying HSM

>Audit Role Authentication Considerations

Configuring Audit Logging

Configure audit logging using the LunaCM audit commands.

To configure audit logging:

1.Configure the Luna USB HSM 7 host computer to use network time protocol (NTP).

2.Set the slot focus to the HSM administrative partition of the desired HSM:

lunacm:> slot set -slot <slotnum>

3.Initialize the Auditor role (you can also use the shortcut au). Specify a password if the HSM will be initialized to use password authentication. If you do not specify a password, multifactor quorum authentication will be used:

lunacm:> role init -name Auditor [-password <password>]

If you chose multifactor quorum authentication, you are referred to the touchscreen, which prompts for a white iKey.

4.Now that the Auditor role exists on the HSM, the auditing function must be configured. However, before you can configure you must log in as the Auditor user (you can also use the shortcut au):

lunacm:> role login -name au

On password-authenticated HSMs, you are prompted to enter the password for the Auditor user.

On multifactor quorum-authenticated HSMs, you are referred to the touchscreen, which prompts for the white iKey for the Auditor user.

5.Set the domain for the Audit role:

lunacm:> role setdomain

6.Synchronize the HSM’s clock with the host time (which should also be synchronized with the NTP server) so that all subsequent log records will have a valid and accurate timestamp.

lunacm:> audit time sync

7.Set the filepath where log files are to be saved. You must complete this step before you can start event logging.

lunacm:> audit config path <filepath>

If you previously configured logging on the HSM and then made changes to your configuration that made that path invalid (such as deleting the path outside of LunaCM or reinstalling the HSM in a different host system), set a valid log path by running audit config path before restarting event logging. If the log path is set incorrectly, logs will be stored in the HSM's limited memory and not exported to the file system. Event logs may be lost if the HSM's memory runs out.

8.Configure audit logging to specify what you want to log. You can specify the level of audit appropriate for needs of the organization’s policy and the nature of the application(s) using the HSM:

lunacm:> audit config evmask <event_value>

NOTE   Before you configure audit logging, we suggest using audit config ? to see all the available options in the configuration process.

Security audits can generate a very large amount of data, which consumes HSM processing resources, host storage resources, and makes the job of the Auditor quite difficult when it comes time to review the logs. For this reason, ensure that you configure audit logging such that you capture only relevant data, and no more.

For example, the First Symmetric Key Usage Only or First Asymmetric Key Usage Only category is intended to assist Auditors to capture the relevant data in a space-efficient manner for high processing volume applications. On the other hand, a top-level Certificate Authority would likely be required, by policy, to capture all operations performed on the HSM but, since it is typically not an application that would see high volumes, configuring the HSM to audit all events would not impose a significant space and/or performance premium in that situation.

As a further example, the command audit config evmask all will log everything the HSM does. This might be useful in some circumstances, but will quickly fill up log files.

9.Configure audit logging to specify how often you want to rotate the logs. Log entries are made within the HSM, and are written to the currently active log file. When a log file reaches the rotation trigger, it is closed, and a new file gets the next log entry. The number of log files grows according to the logging settings and the rotation schedule that you configured. At any time, you can copy files to a remote computer and then clear the originals from the HSM, if you wish to free the space.

a.Specify the rotation interval. You can rotate the logs hourly, daily, weekly, monthly, or never.

lunacm:> audit config interval <value>

b.Specify the maximum log file size. When the log reaches the maximum size, it is automatically rotated, regardless of rotation interval:

lunacm:> audit config size <size>

For example, the commands audit config interval daily and audit config size 4m would rotate the logs every day, unless they reached a size of 4 Mb first, in which case they would be rotated automatically. The daily rotation would still occur.

CAUTION!   This step is very important. If you do not configure the log rotation correctly, logs are stored on the HSM and have nowhere to go. If the logs fill up all available space on the HSM, most operations will fail with CKR_LOG_FULL, and cryptographic services will be interrupted.

See audit config for additional examples.

Exporting the Audit Logging Secret and Importing to a Verifying HSM

You can export the audit log secret from one HSM and import it to another to allow the first HSM's logs to be viewed and verified on the second. The HSMs must share the same authentication method and Audit cloning domain (password string or red iKey). You can verify logs from a Luna PCIe HSM 7 using a Luna Network HSM 7, and vice-versa.

To export the Audit Logging secret from the HSM and import to the verifying HSM

1.Export the audit logging secret to the user local directory. The file is written to the subdirectory specified by a previous audit config path command.

lunacm:> audit export file <filename>

2.Exit LunaCM and list the contents of the lunalogs directory to see the filename of the wrapped log secret:

Linux

ls <client_install_dir>/lunalog

123456 7001347 123456.lws
Windows

dir <client_install_dir>\lunalog

04/12/2017  03:56 PM    <DIR>          123456
04/05/2017  02:35 PM    <DIR>          7001347
04/05/2017  02:35 PM                48 123456.lws

3.Transfer the logging secret to the HSM that will verify the logs. If you are verifying the logs with another locally-installed Luna USB HSM 7, skip this step.

If you are planning to verify logs with a Luna USB HSM 7, use pscp or scp to transfer the logging secret to the appliance. Provide the audit user's credentials when prompted.

<client_install_dir>:>pscp <log_secret_file> audit@<hostname_or_IP>: .

If you are planning to verify logs with a Luna USB HSM 7 installed in a different host computer, you can use scp, pscp, or other secure means to transfer the logging secret.

<client_install_dir>:>pscp <log_secret_file> <user>@<hostname_or_IP>: .

4.Log in to the verifying HSM appliance as the audit user. For this example, we will assume that you have already initialized the HSM audit user role, using the same domain/secret as is associated with the source HSM.

If you are using a Luna Network HSM 7, connect via SSH and log in to LunaSH as the audit user:

lunash:> audit login

If you are using a Luna PCIe HSM 7 or Luna USB HSM 7, open LunaCM and log in using the Auditor role:

lunacm:> role login -name au

5.Import the audit logging secret to the HSM.

Luna Network HSM 7 (LunaSH):

lunash:> audit secret import -serialtarget <target_HSM_SN> -serialsource <source_HSM_SN> -file <log_secret_file>

Luna PCIe HSM 7 or Luna USB HSM 7 (LunaCM):

lunacm:> audit import file <log_secret_file>

6.You can now verify audit log files from the source HSM.

Luna Network HSM 7 (LunaSH):

lunash:> audit log verify -file <audit_log_filename>.log

Luna PCIe HSM 7 or Luna USB HSM 7 (LunaCM):

lunacm:> audit verify file <audit_log_filename>.log

You might need to provide the full path to the file, depending upon your current environment settings.

NOTE   Linux users, if you notice that audit log messages are going to more than one location on your file system, you can edit the /etc/rsyslog.conf file to prevent reporting local3.info messages in /var/log/messages as follows:

//Log anything (except local3 and mail) of level info or higher.  
*.info;
local3.none;mail.none;authpriv.none;cron.none /var/log/messages

The portion highlighted in red stops the duplication of output. This change is optional.

Audit Role Authentication Considerations

>The audit role iKey or password is a critical property to manage the audit logs. If that authentication secret is lost, the HSM must be factory reset (that is, zeroize the HSM) in order to initialize the audit role again.

>Multiple bad logins produce different results for the HSM SO and for the audit role, as follows:

After 3 bad SO logins, the LUNA_RET_SO_LOGIN_FAILURE_THRESHOLD error is returned and the HSM is zeroized.

After 3 bad audit logins, the LUNA_RET_AUDIT_LOGIN_FAILURE_THRESHOLD error is returned, but the HSM is unaffected. If a subsequent login attempt is executed within 30 seconds, the LUNA_RET_AUDIT_LOGIN_TIMEOUT_IN_PROGRESS error is returned. If you wait for more than 30 seconds and try login again with the correct password, the login is successful.