Home >

Administration Guide > Audit Logging > Configuring and Using Audit Logging

Configuring and Using Audit Logging

The overall sequence when initializing an HSM that will use Security Audit Logging is as follows:

1.Configure the SafeNet Network HSM appliance or the SafeNet PCIe HSM/SafeNet USB HSM host workstation to use the 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.

2.Initialize the Audit Officer role.

This enables logging for all subsequent actions performed by the SO and partition User(s).

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

4.Configure the audit category and level of audit

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

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

6.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 for SafeNet PCIe HSM or SafeNet USB HSM  

This section describes how to prepare and use audit logging with your SafeNet HSM.

Required SafeNet HSM Client version is 5.2 or later; HSM firmware version is 6.10.9 or later.

In summary, the steps are:

Initialize, to create the role on the HSM.

Configure the various logging parameters.

Begin collecting and verifying logs of HSM activities.

To configure audit logging

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

lunacm:>slot set slot <number>.   

2.Initialize the Auditor role:   

lunash:>role init -name Auditor

On password-authenticated HSMs, you are prompted for a domain string and password

On PED-authenticated HSMs, you are referred to SafeNet PED, which prompts for a white PED Key.   

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

lunacm:>role login -name Auditor

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

On PED-authenticated HSMs, you are referred to SafeNet PED, which prompts for the white PED Key for the Auditor user.   

4.Configure audit logging:

lunash:> audit config

Note:  The first time you configure audit logging, we suggest using only the "?" option, in order to see all the available options in the configuration process.

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 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 (SafeNet USB HSM) and PCI-bus internal HSMs (SafeNet PCIe HSM), the lunacm tool includes options to set the log file size and the log file path (which are then written to the config file.

Audit Log Operational Activities

lunacm:> audit export

5.Exit LunaCM and browse to see the filename of the wrapped log secret:

/user/safenet/lunaclient/bin :>cd ../../lunalog
/user/safenet/lunalog :>ls  
123456 7001347 k6secret.bin LogSecret_130115210057_123456.lws

6.On the computer where the HSM is attached, that you will use to verify the downloaded audit log file, run:

/usr/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 SafeNet 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.

7.Launch LunaCM,

/usr/safenet/lunaclient/bin :>./lunacm

8.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 SafeNet Network HSM.

9.Import the Audit Logging secret into the locally attached HSM:   

lunacm:>audit import file 151170.lws

10.Verify the file:  

lunacm:>audit verify file mylunsa1_audit_2014-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).   

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