Security Guidance

The key material for your Security World keys is protected by your nShield HSM. However, as with all secure systems, administrators must remain diligent when it comes to who uses the system. All network traffic between Web Services Option Packs and clients using the REST API is passed via a secure channel, setup using TLS 1.2 with mutual authentication. Entrust make the following security related recommendations:

  • Protect your server’s TLS certificate private key by storing this in the nShield HSM. This will provide extra protection for the confidentiality of this key, even in the event of server comprise.

  • Do not change the default ownerships or permissions for the TLS directories and files set by the WSOP installer:

    • owner (root): Full permission.

    • group: Read permission, not write.

    • others: No permissions.

    • All TLS certificate private keys are protected using file permissions. When providing your own keys, corecrypto keys should be owned by the root user and the wsopd group. Other users should not be able to read or write these files. Care should be taken that private key files that live on the disk are not included in any backup, as this will compromise the confidentiality of the keys.

  • The path under /opt/nfast/wsop/corecrypto must be owned by wsopd user and group. Only wsopd user should have permission to write to files in this directory.

  • Ensure log levels are set appropriately for your environment. More verbose log levels may expose information that is useful for auditing who uses Web Services Option Pack, but the log information will also contain which REST crypto API operations have been performed. While this may be useful for diagnostics, be aware that this log information could be considered sensitive and should be suitably protected when stored.

  • The logs files may grow quickly if left unattended for long time. Whoever maintains the web service is responsible for log rotation.

  • Private key material for Security World keys is not exposed by Web Services Option Pack, it is however, usable by remote clients. Ensure client authentication is enabled at all times.

  • Create and use a separate root certificate and client certificate hierarchy that is dedicated to servicing clients of the Web Services Option Pack.

  • Maintain the certificate revocation list, restricting clients that should no longer have access to your Security World keys.

  • Use issued client certificates only in client applications, avoiding having them imported into regular web browsers, since this may enable a Cross Site Request Forgery attack.

  • The Web Services tar file integrity can be verified by using the published hash. It is recommended that you verify the integrity of this file before executing it.

  • The network environment of Web Services Option Pack should be suitably protected to maintain its availability (for example, through use of firewalls, intrusion detection/prevention systems).

  • Ensure that the Web Services Option Pack’s system clock is set accurately, and can only be modified by an authorized system administrator, so that certificate lifetimes are correctly interpreted.

  • Only authorized system administrators should have access to the Web Services Option Pack and only trusted software should be run on the platform hosting the Web Services Option Pack.

  • Standard virus prevention and detection measures should be taken on the platform hosting the Web Services Option Pack.

  • CRL revocation list shall be maintained continuously by pulling the CRL at regular intervals, or whenever it is updated. Web service operation should not be permitted if this cannot be performed.

  • The Web Services Client Certificates must be created only for approved applications.