Logging and Reporting

Luna Network HSM 7 allows you to track and report all activity on your HSM to encourage responsibility, ensure accountability, and maintain tight security.

Logging can be done at two levels

>the cryptographic module

>the host system that contains the crypto module.

Luna HSMs come equipped with HSM-level (that is, cryptographic module level) audit logging via the Audit HSM role. See HSM-Level Audit Logging.

The Luna Network HSM 7 also includes appliance-side audit logging and services that monitor your HSM's performance. See Appliance-Level Performance Monitoring.

For it is your responsibility to manage audit log intensity, disk-space consumption,

HSM-Level Audit Logging

Monitoring HSM activity is essential to maintaining a high level of security for the highly sensitive material on your HSM. Luna HSMs have logging and reporting abilities to support this. These features are implemented in the HSM firmware for maximum security.

Logging

Secure logging is done at the whole HSM level. The HSM stores a record of past operations that is suitable for security audit review. Audit logging, when configured, sends HSM log event records to a remote logging server, with cryptographic safeguards ensuring verifiability, continuity, and reliability of HSM event log files. Log records can also be accumulated to tar files for alternative handling, and to ensure that limited storage inside the cryptographic module is not filled.

Each log entry indicates what event occurred when, and who initiated it. Critical events are logged automatically.

Audit Management

For circumstances that require more comprehensive review of events taking place on the HSM, an HSM-level Audit role (White PED key for multifactor quorum-authenticated HSMs) can be used. Each HSM has a unique Audit role whose purpose is to manage audits and monitor HSM activity.

The Audit role is independent from the other roles on the HSM. Creating the Audit role does not require the presence of the HSM SO and if the Audit role is initialized, the HSM and partition administrators are prevented from working with the log files. Only the Auditor can add failures, successes, key usage, and other events to the HSM logging procedure.

Audit log integrity is ensured against altering log records. Separating logging and its role from other administrative roles protects critical information related to the operations of your HSM.

Appliance-Level Performance Monitoring

Luna HSMs monitor their own conditions for issues that might require administrative attention. Appliance-side logging of HSM activity moves HSM logging directly into the appliance file system. The purpose is to record HSM operations while bypassing the resource-heavy in-HSM log security features. Like at the HSM-level, appliance-level logging and auditing are split into separate services and roles. Only the Auditor on the appliance can engage in audit management. The Audit role is separate from Admin, Operator, and Monitor.

Appliance performance monitoring can be done via LunaSH, Thales Crypto Command Center, or Luna REST API. LunaSH allows you to specify commands yourself, while the latter two provide a friendly user interface to query the appliance.

Syslog

Syslog is a standard logging facility that writes messages it gets from the appliance to organized log files.

When a sensor reading on the appliance changes by an amount that crosses a configured threshold, the appliance will generate log messages according to their severity. These logs can be checked and accessed by an audit user.

SNMP

Luna HSMs also support remote monitoring of conditions on a local HSM via SNMP (Simple Network Management Protocol). Should the condition of your HSM change in a way that requires your attention, SNMP will alert you via trap notification. Condition changes can include changes in memory or CPU usage, network connection status, and some environmental variables.

You can configure SNMP according to your organization's preferences; it is a flexible and optional feature. SNMP is secure and efficient, ensuring that faults in your HSM are detected early and that your cryptographic information remains safe.

Comparing Syslog vs Audit log

 

Function or Characteristic	Syslog	Audit Log
Managed by	Managed by Luna Network HSM 7 appliance admin user via Luna Shell "syslog" commands.	Managed byLuna Network HSM 7 appliance audit user via Luna Shell "audit log" commands.
Source of log messages	Captures events in the host system, not including any activity within the embedded HSM/cryptographic module.	Captures events that occur inside the HSM/cryptographic module.
Control of behavior	Behavior is broadly standardized but specifics depend on the host and its operating system. See Configuring System Logging.	Behavior is controlled by HSM firmware, modified by configuration settings. See Audit Logging.
Location where log records are stored	Events are logged to the host file system, and can be sent to a remote logging server. Default is plain-text, but TLS encryption is a wise option.	Events are initially logged only to a dedicated space of approximately 16MB within the cryptographic module, but can be exported, in encrypted state, to the host file system, and can further be sent to a remote logging server.
	Remote logging is generally a best practice. The receiving host and port configuration must not be the same for both remote syslog and remote audit log. See syslog remotehost add and audit remotehost add.
Security of logs	Appliance host logs are stored in plain text in the default log file location. They are as secure as the physical and digital access protection that you provide for the host and for any Remote Log Server you choose to use, and can be protected in transit by invoking TLS.	Audit logs are protected by layers of encryption where they are created and initially reside, within the cryptographic module. They are encrypted when they move from the limited storage of the cryptographic module to the host file system, and remain encrypted if forwarded to a Remote Log Server. Their integrity is assured and the audit logs can be verified and unlocked by an HSM in the same security/cloning domain as the originating cryptographic module.
Log record and file accumulation	The appliance protects itself by deleting the oldest log files when/if they are allowed to accumulate to the point of filling the allotted space (see below). This allows the most recent logs to always be available. [* Remote logging is a best practice in virtually any logging scenario.] See Exporting System Logs and Deleting System Logs and Rotating System Logs. Log rotation on the Luna Network HSM 7 appliance ensures that cleanup occurs on a daily or weekly or monthly basis. NOTE   The space in the syslog folder in the Luna Network HSM 7 appliance is 9.7GB; if you reach or exceed that, you begin losing the oldest logs, and your syslog configuration might be in need of adjustment for log rotation and remote logging.	Audit log records accumulate in the limited space inside the HSM/cryptographic module (approximately 16MB in NVRAM) until that space approaches being full, at which time the cryptographic module stops performing cryptographic functions and partition creation, recording only audit log messages until the audit logs are rotated out (in encrypted form) to the host file system. Obviously, it should never be allowed to get to that state in a production environment. NOTE   The space in NVRAM that is allocated to audit logs can handle in the range of a couple of hundred thousand entries. That might sound like a lot, and it is if you are prudent with audit configuration. However, see below. The space in the Luna Network HSM 7 file system for exported Audit logs is 220GB. Once the crypto module's audit-log space is unclogged, cryptographic operations can resume. This design strategy protects the continuity of the audit logs - the audit trail - that is so important in compliance audits and forensic investigations. See Configuring and Using Audit Logging.
Logging best practices	Syslog is ubiquitous, as are compendia of best practices and advice. Confer with your organization's security and compliance teams for their requirements and wishes, regarding logging for network-connected equipment. At a minimum, consider automatic sending to a remote logging server, and invoking TLS for the transfer. Where both udp and tcp network protocols are available: •udp is faster, but can drop packets/records •tcp is slower, but verifies and resends if packets are missed or dropped. If you are in the financial industry, choose RELP for Remote Syslog, perhaps with a TLS wrapper.	For Audit Logging, best practice is very application dependent. For (say) a certification authority you might configure •"First Asymmetric Key Usage Only" (value "='first'), •"HSM management" (value 'manage'), •access attempts (value 'access'), and •Key management events (value 'keymanage') -- Security and Compliance auditors are likely to want to know when the key was first used, but might not need a record of every usage, which would generate a lot of audit records. But, if a record of every usage is a requirement, then certainly configure for it, but also configure audit log export and rotation (and remote logging*) on a schedule that keeps the audit-log corner of the cryptographic module's NVRAM from filling up with the probable high volume of audit logs. In contrast, for an application that performs many key generations, ongoing operation would generate huge numbers of logs, and it might be sufficient to configure the crypto module to log only failures. Generally, avoid logging all possible events; start small and increase logging scope until you achieve an acceptable balance between •coverage of cryptographic module activity and •performance of the of the cryptographic module (logging activity does consume or divert HSM resources). [* Remote logging is a best practice in virtually any logging scenario.]