Audit Logging General Advice and Recommendations
The Security Audit Logging feature can produce a significant volume of data. It is expected, however, that Audit Officers will configure it properly for their specific operating environments. The data produced when the feature has been properly configured might be used for a number of reasons, such as:
>Reconstructing a particular action or set of actions (forensics)
>Tracing the actions of an application or individual user (accounting)
>Holding a specific individual accountable for their actions (non-repudiation)
That last bullet point represents the ultimate conclusion of any audit trail – to establish an irrefutable record of the chain of events leading up to a particular incident for the purpose of identifying and holding accountable the individual responsible. Not every organization will want to use security audit to meet the strict requirements of establishing such a chain of events. However, all security audit users will want to have an accurate representation of a particular sequence of events. To ensure that the audit log does contain an accurate representation of events and that it can be readily interpreted when it is reviewed, these basic guidelines should be followed after the audit logging feature has been properly configured:
>Use a shell script to execute the audit sync command at least once every 24 hours, provided the host has maintained its connection(s) to its configured NTP server(s).
>Do not allow synchronization with the host’s clock if the host has lost connectivity to NTP. This ensures that the HSM’s internal clock is not set to a less accurate time than it has maintained internally. In general, the HSM’s RTC will drift much less than the host’s RTC and will, therefore, be significantly more accurate than the host in the absence of NTP.
>Review logs at least daily and adjust configuration settings if necessary. It is important that any anomalies be identified as soon as possible and that the logging configuration that has been set is effective. If possible, use the remote logging feature to transmit log data to a Security Information and Event Management (SIEM) system to automatically analyze log data and identify anomalous events.
>Consider installing and configuring a SafeNet Luna PCIe HSM in (or connected to) the remote log server to act as a “verification engine” for the remote log server. Ensure that the log secret for the operational HSM(s) has been shared with the log server verification HSM.
NOTE This is not always possible, unless you are physically copying the logs over from the .tgz archive. Because log records do not necessarily appear on the remote log server immediately, the HMAC might be incorrect. Also, if more than one SafeNet Luna PCIe HSM is posting log records to a remote server, this could interfere with record counts.
>The audit log records are comma-delimited. We recommend that full use be made of the CSV formatting to import records into a database system or spreadsheet tool for analysis, if an SIEM system is not available.
>The ASCII hex data representing the command and returned values and error code should be examined if an anomaly is detected in log review/analysis. It may be possible to match this data to the HSM’s dual-port data. The dual-port, if it is available, will contain additional data that could be helpful in establishing the context surrounding the anomalous event. For example, if an unexpected error occurs it could be possible to identify the trace through the firmware subsystems associated with the error condition. This information would be needed to help in determining if the error was unexpected but legitimate or if it was forced in an attempt to exploit a potential weakness.
An important element of the security audit logging feature is the ‘Log External’ function. See the SDK Reference Guide for more information. For applications that cannot add this function call, it is possible to use the LunaCM command-line function audit log external within a startup script to insert a text record at the time the application is started.
Disk Full
In the event that all the audit disk space is used up, audit logs are written to the HSM's small persistent memory. When the HSM's persistent memory is full, normal crypto commands will fail with "disk full" error.
To resolve that situation, the audit user must:
1.Archive the audit logs on the host side.
2.Move the audit logs to some other location for safe storage.
3.Clear the audit log directory.
4.Restart the
To prevent the "disk full" situation, we recommend that the audit user routinely archive the audit logs and clear the audit log directory.
CAUTION! If the HSM is zeroized when a "disk full" condition has occurred, hsm init will fail, preventing the user from clearing the logs. This will effectively lock out the appliance and RMA may be necessary.
