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 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
>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.
>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 Audit Logging for more information. For applications that cannot add this function call, it is possible to use lunacm:> audit logmsg 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.
