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.
>Execute lunash:> audit log tarlogs regularly to archive the audit logs and transfer them to a separate machine for long term storage. Also, execute audit log clear regularly to free up the audit log disk space on Luna Network HSM.
>Consider installing and configuring a 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 Luna Network 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 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.
NOTE Audit log and syslog entries are timestamped in UTC format.
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
lunash:> service restart cbs
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 initialization will fail, preventing the user from clearing the logs. This will effectively lock out the appliance and RMA may be necessary.
