You are here: Administration & Maintenance Manual > HSM Administration > Audit Logging > Configuring and Using Audit Logging

Configuring and Using Audit Logging

Here is a summary of the overall sequence when initializing an HSM that will use Security Audit Logging:

Configure the Luna SA appliance or the K6/G5 host platform to use network time protocol (NTP). Configure access to at least two geographically separated NTP servers for redundancy. Select at least one NTP server that is known to have a high degree of accuracy and reliability (servers associated with national standards bodies are good candidates) as one of the configured servers.
Initialize the Audit Officer role. This enables logging for all subsequent actions performed by the SO and partition User(s).
Execute the ‘audit sync’ command. This ensures that the HSM’s clock is synchronized with the host time (which should also be synchronized with the NTP server) and that all subsequent log records will have a valid and accurate timestamp.
Configure the audit category and level of audit to suit the needs of the organization’s policy and the nature of the application(s) using the HSM. Security audit can often generate a very large amount of data, consuming HSM processing (at the expense of key usage operations, for example) and host storage resources and making the job of the Audit Officer quite difficult when it comes time to review the logs. Logging should be configured to capture all of the relevant data and No More.

For example, the ‘First 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.
Configure log rotation and remote logging server(s) as necessary. The settings for these configuration elements will often be dictated by the organization’s Audit and/or IT policies and procedures. As with configuring the audit category, the Audit Officer should be prudent in making these configuration settings. It is recommended that the default setting of ‘Rotate Log Daily’ be maintained until the typical/average logging rate can be determined. The use of redundant remote log servers, accessible only by the members of the audit team, is strongly recommended.
Initialize the HSM and create partitions as necessary. At this point, the HSM is ready to be turned over to the SO to initialize it and begin creating the partitions needed to serve the processing applications.

Configure Audit Logging

This section describes how to prepare and use audit logging with your Luna SA.

Required Luna SA appliance version is 5.2 or later; HSM firmware version is 6.10.x or later.

In summary, the steps are:

Log into the appliance as "audit" user.
Initialize, to create the role on the HSM.
Configure the various logging parameters.
Begin collecting and verifying logs of HSM activities.

The audit user's commands are not available to the admin user. The audit user has no administrative control over the Luna SA 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,

Detailed steps

Using an SSH connection (or a local serial connection), log into the Luna appliance as "audit" (not as "admin").
The default password is "PASSWORD"
Change that to a secure password.
To fulfill the purpose of the Audit role, keep the "audit" user's password separate from, and unknown to, the HSM Administrator or Security Officer.
Run the command:
lunash:>audit init
For password-authenticated HSM, you are prompted for a domain string and password; for PED-authenticated HSM, you are referred to Luna PED, which prompts for a white PED Key.
Now that the Audit role exists on the HSM, the auditing function must be configured. However, before you can configure you must authenticate. Run the command:
lunash:>audit login
For password-authenticated HSM, you are prompted for a password; for PED-authenticated HSM, you are referred to Luna PED, which prompts for a white PED Key.
When your credentials have been accepted run :
lunash:>audit config
The first time you configure, we suggest using only the "?" option, in order to see all the available options in the configuration process. For example,
lunash:>audit config -p e -v all
will log everything the HSM does. This might be useful in some circumstances, but will quickly fill up log files. The addition of,
lunash:>audit config -p r -v h
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 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 log files on the appliance grows according to the logging settings and the rotation schedule that you configured (above). 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 USB-connected external (Luna G5) and PCI-bus internal HSMs (Luna PCI-E), the lunacm tool includes options to set the log file size and the log file path (which are then written to the config file.
For Luna SA, to simplify configuration within its closed and hardened environment,

the maximum log file size is capped at 4 MB
the log path is internal to the Luna HSM appliance and
the rotation offset is set at 0.

Audit Log Operational Activities

Copy files off the appliance

View a list of the log files currently saved on the appliance with:
lunash:>my file list

For this example, assume that the list includes a file " audit.tgz ".
On the computer where you wish to capture and store the log files,
/user/safenet/lunaclient/logs :>scp audit@mylunasa1:audit.tgz mylunsa1_audit_2013-02-28.tgz
and provide the audit user's credentials when prompted. This copies the identified file from the remote Luna SA's file system (in the "audit" account) and stores the copy on your local computer file system with a useful name.
You can view and parse the plaintext portion of the file.
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 SA HSM.

Export the Audit Logging secret from the HSM and import to the verifying HSM

On the Luna SA where HSM audit log files are being created, export the Audit Logging secret:
lunash:> audit secret export
Use my file list to see the filename of the wrapped log secret.
On the computer where the HSM is attached, that you will use to verify the downloaded Audit Log file, run:
/user/safenet/lunaclient/bin :>scp audit@mylunasa1:151170.lws .
(substitute the actual file name of the exported secret in the above example command) and provide the audit user's credentials when prompted. This copies the identified file from the remote Luna SA'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.
Launch lunacm,
/user/safenet/lunaclient/bin :>./lunacm
For this example, we will assume that you have initialized the HSM Audit User role, using the same domain/secret as is associated with the source Luna SA HSM - the lunacm:> audit commands for the purpose are almost identical to the lunash:> audit commands used in the Luna SA example above.
Import the Audit Logging secret into the locally attached HSM:
lunacm:>audit import file 151170.lws
Verify the file
lunacm:>audit verify file mylunsa1_audit_2013-02-28.tgz

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

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

Additional 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. This is equivalent to the same situation for the HSM's Security Officer (SO).   The following examples illustrate some points of behavior.

Example #1: SO or audit role is not initialized, no login is needed
lunash:>hsm init -l myHSM -d default -p userpin -f
'hsm init' successful.

lunash:>audit init -d default -p userpin -f
Command Result : 0 (Success)

Example #2: SO or audit role is initialized, but not logged in
lunash:>hsm init -l myHSM -d default -p userpin -f
Error: 'hsm init' failed. (1010000 : LUNA_RET_USER_NOT_LOGGED_IN)
lunash:>audit init -d default -p userpin -f
The audit sub-command failed. (LUNA_RET_USER_NOT_LOGGED_IN)

Example #3: SO or audit role is logged in, init with the correct password and new domain
lunash:>hsm init -l myHSM -d safenet -p userpin -f
'hsm init' successful.

lunash:>audit init -d mysafenet -p userpin -f
Command Result : 0 (Success)

Example #4: SO or audit role is logged in, init with the wrong password
lunash:>hsm init -l myHSM -d safenet -p wrongpin -f
Error: 'hsm init' failed. (A00000 : LUNA_RET_UM_PIN_INCORRECT)
lunash:>audit init -d default -p wrongpin -f
The audit sub-command failed. (LUNA_RET_UM_PIN_INCORRECT)

3.       Multiple bad logins produce different results for the SO and 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_SO_LOGIN_FAILURE_THRESHOLD error is returned, but the HSM is affected. If 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 will be successful.

Client or Remote Host

To restart the pedClient daemon
/usr/safenetlunaclient/bin/pedClient -m stop
then
/usr/safenetlunaclient/bin/pedClient -m start