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.
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
To prevent the "disk full" situation, we recommend that the audit user routinely archive the audit logs and clear the audit log directory.
TIP Log entries are stored in the cryptographic module (HSM) until they are rotated off. Log entries are not rotated out of the cryptographic module until the audit user is initialized and audit logging is configured. By default, even if there is no audit user or configuration, the cryptographic module logs unconditional events within its own memory, like:
>zeroize
>decommission
>hardware tamper
>card removal
>etc.
If the crypto module internal space ever fills completely with log records,
>whether slowly from unconditional logs, or
>quickly from more voluble high-volume event recording,
...the HSM / cryptographic module would stop all operations that were not audit init and audit configuration. The HSM would resume providing service only after the audit user cleared the logs.
To avoid that ever happening, configure audit logging to organize log parameters and handling, being sure to set sufficient frequency of rotation for the volume of record generation that you enable.
Best practice is to:
>initialize the audit role as soon as the HSM is first powered on for production audit init
>configure the log storage path on the external file system, along with the types of events to log, the rotation interval, etc. audit config
>then, initialize the HSM Security Officer (this helps ensure that all messages, demanded by your auditing authority, are captured) hsm init
>then, proceed with partition initialization and usage with your application(s)
>then, revisit audit log configuration at regular intervals to tune the balance between
•desired message types,
•volume of audited actions normally performed (*),
•and so on
>when you change behavior of the crypto module or change the types of events to audit, be sure to revisit also the rotation interval.
[* Example, you might always want to record the generation of keys, but if usage of those keys is very high-volume (like in some signature use-cases), and thus would generate a high volume of log entries, it might be permissible, and prudent, to log only first-use of any key. Check with the relevant authority.]
