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. See the User Guide for details. 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.

Audit logging

Audit logging as described in Logging and debugging delivers logs to an external log collector outside of the HSM. It uses an integrity mechanism to protect the logs. 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.

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.