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

>Copying Log Files Off the Appliance

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

>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 configuring 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 7 appliance to use the network time protocol (NTP). See NTP on Luna Network HSM 7.

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 7 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 7 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 HSM SO and partition user(s):

lunash:> audit init

On password-authenticated HSMs, you are prompted for the password.

On multifactor quorum-authenticated HSMs, you are referred to Luna PED, which prompts you for a blank or rewritable white Audit 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 multifactor quorum-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 7, to simplify configuration within its closed and hardened environment, the following rules apply:

>The maximum log file size is capped at 50 MB.

>The log path is internal to the Luna Network HSM 7 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 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 7'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 7.

6.On the appliance, you can now clear the audit log file system to make space for more audit logs.

lunash:> audit log clear

7.If you are clearing logs because of a CKR_LOG_FULL condition, the cbs service must also be restarted. The audit user is unable to access this command; the admin user must log in to LunaSH and restart the service.

lunash:> service restart cbs

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 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.On the Luna Network HSM 7 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 7 or Luna USB HSM 7, you can use that HSM's host computer.

If you are planning to verify logs with a second Luna Network HSM 7, 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 7:

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

This copies the identified file from the remote Luna Network HSM 7'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 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

4.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>

5.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.

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 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.