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:
>Exporting the Audit Logging Secret and Importing to a Verifying HSM
>Deciphering the Audit Log Records
>Audit Role Authentication Considerations
Configuring Audit Logging
You configure audit logging using the LunaCM audit commands. See audit in the LunaCM Command Reference Guide.
To configure audit logging
1.Configure the SafeNet Luna PCIe HSM host computer to use network time protocol (NTP).
2.Ensure that the PEDclient service is running:
See pedclient mode show and pedclient mode start
3.Set the slot focus to the HSM administrative partition of the desired HSM:
lunacm:>slot set slot <slotnum>
4.Initialize the Auditor role (you can also use the shortcut au):
lunacm:>role init -name Auditor
•On password-authenticated HSMs, you are prompted for a password.
•On PED-authenticated HSMs, you are referred to Luna PED, which prompts for a white PED key.
5.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 PED-authenticated HSMs, you are referred to Luna PED, which prompts for the white PED key for the Auditor user.
6.Set the domain for the Audit role:
lunacm:> role setdomain
7.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
8.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
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.
9.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. See also audit config in the LunaCM Command Reference Guide.
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.
10.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.
See audit config in the LunaCM Command Reference Guide 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 PED key). You can verify logs from a SafeNet Luna PCIe HSM using a SafeNet Luna Network HSM, 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 SafeNet Luna PCIe HSM, skip this step.
•If you are planning to verify logs with a SafeNet Luna PCIe HSM, use scp or pscp to transfer the logging secret to the appliance. Provide the audit user's credentials when prompted.
Linux | <client_install_dir>:>scp <log_secret_file> audit@<hostname_or_IP>: . |
Windows | <client_install_dir>:>pscp <log_secret_file> audit@<hostname_or_IP>: . |
•If you are planning to verify logs with a SafeNet Luna PCIe HSM installed in a different host computer, you can use scp, pscp, or other secure means to transfer the logging secret.
Linux | <client_install_dir>:>scp <log_secret_file> <user>@<hostname_or_IP>: . |
Windows | <client_install_dir>:>pscp <log_secret_file> <user>@<hostname_or_IP>: . |
4.Login to the verifying HSM 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 SafeNet Luna PCIe HSM, connect via SSH and login to LunaSH as the audit user:
lunash:>audit login
•If you are using a SafeNet Luna PCIe HSM, open LunaCM and login using the Auditor role:
lunacm:>role login -name au
5.Import the audit logging secret to the HSM.
•SafeNet Luna PCIe HSM (LunaSH):
lunash:>audit secret import -serialtarget <target_HSM_SN> -serialsource <source_HSM_SN> -file <log_secret_file>
•SafeNet Luna PCIe HSM (LunaCM):
lunacm:> audit import file <log_secret_file>
6.You can now verify audit log files from the source HSM.
•SafeNet Luna PCIe HSM (LunaSH):
lunash:>audit log verify -file <audit_log_filename>.log
•SafeNet Luna PCIe HSM (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.
Deciphering the Audit Log Records
In general, the audit logs are self-explanatory. Due to limitations in the firmware, however, some audit log records required further explanation, as detailed in the following sections:
Determining the serial number of a created partition from the audit log
An audit log entry similar to the following is generated when a partition is created on the HSM:
5,12/12/17 16:14:14,S/N 150718 session 1 Access 2147483651:2669 SO container operation LUNA_CREATE_CONTAINER returned RC_OK(0x00000000) container=20 (using PIN (entry=LUNA_ENTRY_DATA_AREA))
It is not obvious from this entry what the serial number is for the created partition. This information, however, can be derived from the log entry, since the partition serial number is simply a concatenation of the HSM serial number and the partition container number, which are specified in the log entry, as highlighted below:
5,12/12/17 16:14:14,S/N 150718 session 1 Access 2147483651:2669 SO container operation LUNA_CREATE_CONTAINER returned RC_OK(0x00000000) container=20 (using PIN (entry=LUNA_ENTRY_DATA_AREA))
In the example above, the HSM serial number is 150718 and the partition container number is 20. Note that the partition container number is a three-digit number with leading zeros suppressed, so that the actual partition container number is 020. To determine the partition serial number concatenate the two numbers as follows:
150718020
Use this number to identify the partition in subsequent audit log entries.
Audit Role Authentication Considerations
>The audit role PED key 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 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.