|
Home > |
|---|
The Secure 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:
•maintaining an audit trail that can later be used to reconstruct a particular action or set of actions (i.e., forensics);
•maintaining an audit trail that can later be used to trace the actions of an application or individual user (i.e., accounting); and
•maintaining an audit trail that can later be used to hold a specific individual accountable for his/her actions (i.e., 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.
•In the case of SafeNet Network HSM, execute the audit log tarlogs lush command regularly to archive the audit logs and transfer them to a separate machine for long term storage. Also, execute the ‘audit log clear” lush command regularly to free up the audit log disk space on SafeNet Network HSM.
•Consider installing and configuring an HSM (for example, a SafeNet USB or PCIe HSM) 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 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 (e.g., searching for buffer overflows).
An important element of the security audit logging feature is the ‘Log External’ function. See the SDK for more information Audit Logging. 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.
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:
•archive the audit logs on the host side,
•move them to some other location for safe storage,
•clear the audit log directory, and
•restart the logger daemon.
To prevent the "disk full" situation, we recommend that the audit user should routinely archive the audit logs and clear the audit log directory.