Audit

The product’s environment should be audited regularly to ensure that the appropriate set of procedures, satisfying the requirements laid down in this document and any customer Security Procedures, is in place and is being used. A mechanism should be in place to enable corrective action to be taken if any procedure is not being observed or is failing. The Auditor should be independent of the Administrator of the product.

HSM and card reader location

Customer Security Procedures should state that a record is kept of the location of each HSM and card reader referenced by unique identifiers. This may include its model, serial and any local asset id numbers. This record should be updated if the HSM or card reader is moved.

  • Customer Security Procedures should state the frequency for verifying the recorded location of each HSM and card reader.

Physical inspection

Whilst checking the HSM and card reader location, inspections should also be carried to ensure the integrity of the HSM and card reader including any tamper mechanisms as described in Tamper inspection.

  • Customer Security Procedures should state the frequency for verifying the integrity of the HSM and card reader including any tamper mechanisms.

ACS and OCS

Customer Security Procedures should state that a record is kept of either the location (such as in a safe) of each card in an ACS and OCS or the owner depending on the policy stated in the customer’s security policy. This record should be updated if a card is moved or transferred.

  • Customer Security Procedures should state the frequency for verifying the recorded location or owner each card in an ACS and OCS.

Guidance on how to respond to a missing ACS and OCS cards can be found in Security Incident and Response.

Logs

Logging and debugging identifies the types of log available across the different nShield platforms. Each log fulfills a different purpose and some can be filtered to control the amount of information logged. In some instances tamper or cryptographic mechanisms are used to protect the integrity of the logs. Logs that don’t use these mechanisms should be protected through procedural controls.

A threat analysis will determine which logs are required and which filters to apply (if available) in monitoring the customer’s specific deployment of the HSM.

The Auditor should be independent of the Administrator of the HSM:

  • When modifications are made to the configuration of an HSM, the changes should be audited to ensure that the configuration has been modified in the intended way.

  • The Auditor should regularly inspect the logs to verify that the unit’s configuration reflects the Security Policy.

  • The logs should be inspected by the Auditor periodically at a frequency determined by the customer Security Procedures.

  • The customer Security Procedures should state what log entries are cause for concern.

The following example scenarios may also be a cause for concern:

  • Access outside of work hours

  • Unusual changes to the configuration

  • Unit power cycled.

The actions required to resolve the issue should also be stated using the customer’s own incident response process.

The customer Security Procedures should identify a backup policy for the logs and the authorization required to delete logs once they’ve been backed-up.

HSM Audit logging

Audit logging as described in Logging and debugging delivers HSM logs to an external log collector outside of the HSM. It is recommended that audit logging be enabled when creating a Security World. Audit logging uses an integrity mechanism to protect the logs from tampering and verify they generated by a legitimate nShield HSM (as proven by the HSM’s KLF2 key and associated KLF2 warrant which certifies its legitimacy). By default, audit logging logs important startup, setup and credential presentation events, but not all key usage, and so is a relatively lightweight option. Individual keys may additionally be specified to be logged, in which case all usage of them will result in an audit event; this is a higher-volume logging use case and is recommended for high-value low-usage keys such as Root CA keys. Common Criteria Security Worlds have additional audit logging enabled by default compared to ordinary Security Worlds. Additional controls required to support the Audit Log are described in Audit Log. As well as applying the guidance described above, further guidance specific to Audit Logging is supplied here:

The Auditor should inspect the logs to:

  • Identify missing logs

  • Verify the integrity of logs up to the trusted root

  • Identify log entries that are a cause for concern.

Log verification is done with the cef-audit-verify tool for the CEF audit logs produced prior to v13.5 firmware, and with the nShield Audit Log Service and nshieldaudit client tool for logs produced by v13.5 firmware and later.

Audit Logging time

The Date and Time provides guidance on correctly setting the time for the nShield Connect clock and RTC. If NTP is enabled then the nShield Connect clock will synchronize to that. Both clock times will appear in the Audit Log and in other logs listed in Logging and debugging. The nShield Connect’s clock (if not synchronized to NTP) and RTC are subject to drift and should be regularly set using an accurate trusted local time source.

With regard to the Audit Log we recommend only accepting that the nShield Connect and RTC time stamps represent the actual time if they match each other within a reasonable margin of error.

nShield 5 Signed System Logs

Separate from the nCore audit logs associated with the Security World, nShield 5 also contains signed system logs associated with the rest of the device operation, such as device startup events and connection attempts and operations with its non-nCore services. This logging is always enabled in nShield 5 since v13.5 firmware and later, and logs are fetched and verified by the nShield Audit Log Service and can be queried using the nshieldaudit tool, alongside the nCore logs that these tools also manage.