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:
>Copying Log Files Off the Appliance
>Exporting the Audit Logging Secret and Importing to a Verifying HSM
>Reading the Audit Log Records
>Audit Role Authentication Considerations
Configuring Audit Logging
Configure audit logging using the LunaSH audit commands.
NOTE Audit log and syslog entries are timestamped in UTC format.
TIP Performance and Audit Logging
Secure Audit Logging consumes HSM resources, so consider minimizing the intensity of logging that you invoke.
For example, when choosing asymmetric key usage, you have the option to specify event values to record with -value asymmetric or first.
When choosing symmetric key usage logging you can opt for the corresponding symmetric and symfirst.
An HMAC is generated for each log, so "first" and "symfirst" record the first use of a key (asymmetric sig/ver or symmetric enc/dec respectively) and are much more sparing of HSM cycles, and therefore preferred to configring for a log entry at every individual use of a given key -- unless that level of detailed logging is mandated.
Prerequisites (HSM SO)
1.Configure the Luna Network HSM appliance to use the network time protocol (NTP). See Timestamping – NTP and Clock Drift.
2.Log in to LunaSH as an admin-level user, and enable the audit user. The audit user is necessary to access and work with logs through the LunaSH interface. It is restricted from administrative functions:
lunash:> user enable -username audit
To configure audit logging (Auditor):
1.Using an SSH connection (or a local serial connection), login to LunaSH on the Luna Network HSM appliance as audit (not as admin), using the password "PASSWORD".
The first time you login as audit, you are prompted to change the password to something more secure. To fulfill the purpose of the Audit role, keep the audit user's password separate from, and unknown to, the HSM Security Officer:
The audit user sees a reduced subset of commands suitable to the audit role, only, as follows:
Name (short) Description -------------------------------------------------------------------------------- init i Initialize the Audit role changePwd ch Change Audit User Password or PED Key login logi Login as the Audit user logout logo Logout the Audit user config co Set Audit Parameters sync sy Synchronize HSM Time to Host Time show sh Display the Audit logging info log l > Manage Audit Log Files secret se > Export/Import Audit Logging Secret remotehost r > Configure Audit Logging Remote Hosts
NOTE The audit user's commands are not available to the admin user. The audit user has no administrative control over the Luna Network HSM appliance. This is a first layer in the separation of roles. This separation allows a user with no administrative control of the appliance and HSM to have oversight of the HSM logs, while also ensuring that an administrator cannot clear those logs.
2.Initialize the audit role on the HSM. This enables logging for all subsequent actions performed by the SO and partition user(s):
lunash:> audit init
•On password-authenticated HSMs, you are prompted for the password and cloning domain.
•On PED-authenticated HSMs, you are referred to Luna PED, which prompts you for the domain (red PED key) and Audit authentication (white PED key).
3.Now that the audit role exists on the HSM, you can configure the auditing function. However, before you can configure audit logging you must log into the HSM as the audit role:
lunash:> audit login
•On password-authenticated HSMs, you are prompted to enter the password for the audit role.
•On PED-authenticated HSMs, you are referred to Luna PED, which prompts for the white PED key for the audit role.
NOTE You are now logged into the appliance as the audit user and into the HSM (within the appliance) as the audit role. Both are required. The audit commands, including HSM login as the audit role do not appear if you are logged in as any other named appliance-level user.
4.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:
lunash:> audit sync
5.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:
lunash:> audit config -parameter event -value <event_value>
NOTE The first time you configure audit logging, we suggest using only the ? option, 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 Audit Officer 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 Audit Officers 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, lunash:> audit config -parameter event -value all will log everything the HSM does. This might be useful in some circumstances, but will quickly fill up log files.
6.Configure audit logging to specify how often you want to rotate the logs:
lunash:> audit config -parameter rotation -value <value>
For example, lunash:> audit config -parameter rotate -value hourly would rotate the logs every hour, cutting down the size of individual log files, even in a situation of high-volume event recording, but would increase the number of files to be handled.
Log Entries
Log entries are made within the HSM, and are written to the currently active log file on the appliance file system. 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 on the appliance 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.
For Luna Network HSM, to simplify configuration within its closed and hardened environment, the following rules apply:
>The maximum log file size is capped at 4 MB.
>The log path is internal to the Luna Network HSM appliance.
>The rotation offset is set at 0.
Copying Log Files Off the Appliance
You can copy the log files off of the appliance for viewing and verification.
To copy files off the appliance
1.Create an archive of the logs that are ready to archive:
lunash:> audit log list
lunash:> audit log tarlogs
2.View a list of the log files currently saved on the appliance:
lunash:> my file list
For this example, assume that the list includes a file named audit.tgz.
3.On the computer where you wish to capture and store the log files, use pscp or scp to transfer the file from the appliance:
/usr/safenet/lunaclient/logs :> pscp audit@myLunaHSM1:audit.tgz mylunsa1_audit_2014-02-28.tgz
Provide the audit user's credentials when prompted. This copies the identified file from the remote Luna Network HSM's file system (in the audit account) and stores the copy on your local computer file system with a useful name.
4.You can view and parse the plain-text portion of the file.
5.You can verify the authenticity of the retrieved file using a connected HSM to which you have imported the Audit logging secret from the originating Luna Network HSM.
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 Luna PCIe HSM using a Luna Network HSM, and vice-versa.
To export the Audit Logging secret from the HSM and import to the verifying HSM:
1.On the Luna Network HSM where HSM audit log files are being created, export the audit logging secret:
lunash:> audit secret export
The filename is displayed when the secret is exported. You can check the filename with my file list.
2.On a computer connected to both HSMs, use pscp or scp to transfer the logging secret from the appliance.
•If you are planning to verify logs with a Luna PCIe HSM, you can use the PCIe HSM's host computer.
•If you are planning to verify logs with a second Luna Network HSM, you must transfer the logging secret to a client computer, and then to the second appliance.
<client_install_dir>:> pscp audit@ <hostname_or_IP>:<log_secret_file> .
Then, if transferring to a second Luna Network HSM:
<client_install_dir>:> pscp <log_secret_file> audit@<hostname_or_IP>:
This copies the identified file from the remote Luna Network HSM's file system (in the audit account) and stores the copy on your local computer file system in the directory from which you issued the command. Provide the audit user's credentials when prompted.
3.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, connect via SSH and log in to LunaSH as the audit user:
lunash:> audit login
•If you are using a Luna PCIe HSM, open LunaCM and log in using the Auditor role:
lunacm:> role login -name au
4.Import the audit logging secret to the HSM.
•Luna Network HSM (LunaSH):
lunash:> audit secret import -serialtarget <target_HSM_SN> -serialsource <source_HSM_SN> -file <log_secret_file>
•Luna PCIe HSM (LunaCM):
lunacm:> audit import file <log_secret_file>
5.You can now verify audit log files from the source HSM.
•Luna Network HSM (LunaSH):
lunash:> audit log verify -file <audit_log_filename>.log
•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.
Reading 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.
