Securing the ActivID AS System

Secure the Application Servers

Follow Vendor Configuration Guidelines

To maximize the security of your application server (and the backups of the server content), you should follow the guidelines and recommendations of the vendor to configure and harden the various components of your infrastructure. For further information, refer to the technical documentation provided with your application server.

For example, such resources include:

Implement an Update Policy

Vulnerabilities on operating system components, JVMs and Application Servers are regularly discovered. The US National Vulnerability Database keeps a record on the Common Vulnerabilities and Exposures (CVE). Such resources include:

Therefore, it is strongly recommended that you implement a policy to stay up-to-date with your server OS, JVM and application server’s security patches/advisories, as well as perform non-regression tests.

Securing Web Servers

As with other third party elements, you must keep the web server component, and the cryptographic component (such as OpenSSL), up-to-date to fix any newly discovered vulnerabilities, as well as perform non-regression tests.

Regularly check for new vulnerabilities in the NVD database and security patches from vendors:

Warning! Critical Warning about SSL/TLS

All services SHOULD be configured to use strong TLS or they become liable to MiTM/MITB attacks. For more information on TLS, go to https://owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet

In addition, as new TLS vulnerabilities are discovered regularly, constant monitoring on these vulnerabilities must be maintained and acted upon.

TLS Configuration

It is recommended that you use at least TLS 1.2.

This version of the protocol is now very widely supported. TLS 1.3 suites would be even better security-wise but represent a significant change in the protocol and require newer technical stacks (such as OpenSSL 1.1.+, java 11+ etc,).

It is further recommended that you limit your deployment to the strongest and most modern cipher suites that support perfect forward secrecy, such as (for TLS 1.2 and RSA keys):

  • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

  • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

Note: It is highly recommended that you do NOT allow all the SSL_RSA ciphers as they are vulnerable to the ROBOT attack (which can be used to steal the encryption key and thus break the channel confidentiality).

Likewise, as most of the vulnerabilities of TLS 1.0 and 1.1 are now well-known and exploits easily available, it is highly recommended that these versions should be considered broken (as with SSL v2 and v3) and to use TLS 1.2+ exclusively.

Amongst these, it is preferable to prioritize ciphers that provide authenticated encryption (those using GCM) as they provide further protection against specific ciphertext attacks.

Allowed HTTP Verbs

HTTP offers a number of methods that can be used to perform actions on the web server. Many of these methods are designed to aid developers in deploying and testing HTTP applications. These HTTP methods can be used for nefarious purposes if the web server is misconfigured. Additionally, Cross Site Tracing (XST), a form of cross site scripting using the server's HTTP TRACE method, is examined.

While GET and POST are by far the most common methods that are used to access information provided by a web server, the Hypertext Transfer Protocol (HTTP) allows several other (and somewhat less known) methods. RFC 2616 (which describes HTTP version 1.1 which is the standard today) defines the following eight methods:

  • HEAD
  • GET
  • POST
  • PUT
  • DELETE
  • TRACE
  • OPTIONS
  • CONNECT

Some of these methods can potentially pose a security risk for a web application, as they allow an attacker to modify the files stored on the web server and, in some scenarios, steal the credentials of legitimate users:

  • PUT – allows a client to upload new files on the web server. An attacker can exploit it by uploading malicious files (for example, an asp file that executes commands by invoking cmd.exe), or by simply using the victim's server as a file repository.
  • DELETE – allows a client to delete a file on the web server. An attacker can exploit it as a very simple and direct way to deface a web site or to mount a DoS attack.
  • CONNECT – could allow a client to use the web server as a proxy.
  • TRACE – simply echoes back to the client whatever string has been sent to the server, and is used mainly for debugging purposes. This method, originally assumed harmless, can be used to mount an attack known as Cross Site Tracing.

As REST Web Services (such as ActivID AS SCIM APIs) typically use the GET, POST, PUT, and DELETE verbs, it is important to check that the usage of PUT and DELETE is correctly limited to trusted users and safe conditions.

HEAD, TRACE, OPTIONS and CONNECT should all be disabled.

Securing Databases

To secure your Oracle database (and the backups), you should follow the guidelines and recommendations of the vendor to protect the data and access to the database itself.

For further information, refer to the technical documentation provided with your database.

For example, go to the Oracle Databse Security Guide

Securing LDAP Directories

General Considerations

ActivID AS can leverage your corporate directory. For example, user information includes email addresses and user names that are inserted on certificates that are placed on smart cards. The security of your corporate directory depends upon the information being stored securely based organizational requirements.

Related Security Considerations

ActivID AS only reads information in the corporate LDAP directory. To perform such tasks, ActivID AS requires read access to the LDAP Directory and to the Certificate Authority (CA). This access must be carefully restricted to ensure that this user account cannot be used to compromise the ActivID AS environment.

The following recommendations apply to the LDAP configuration for ActivID AS:

  • Use LDAPS with a client certificate to authenticate the ActivID AS LDAP account to LDAP. If a client certificate to authenticate ActivID AS to LDAP is not a feasible option, then implement a password change procedure for this LDAP account. The procedure should be executed regularly in accordance with your internal policies.

    • The reason for this password change recommendation is because the user ID and password of the user that connects to the LDAP directory is configured in the Console. The password is encrypted and stored in the ActivID AS database.

    Note: If the password expires and is not changed within ActivID AS, then it will not function correctly.
  • Create the dedicated account with only the access it requires. This account typically requires only write access to the smart card serial number attribute, and read access to the branches from which it queries the user attributes.
  • Use the ActivID Management Console to configure ActivID AS to use LDAPS for any communication with the LDAP server.
    • Note: This recommendation requires that the LDAP server be configured with a server certificate that is trusted by the ActivID AS system.

Securing Message-Orientated Middleware

ActivID AS leverages Message-Oriented Middleware (MOM) to notify a web portal of a mobile validation, in compliance with the JMS specifications. It can use a MOM embedded in the application server (such as the Service Integration Bus in IBM WebSphere), or an external MOM (such as IBM MQ®, or Apache ActiveMQ®).

In order to secure your MOM, you should follow the vendor guidelines and recommendations. For further information, refer to the technical documentation related to your product:

If you choose to use an external MOM, the component must be kept up-to-date to fix any newly discovered vulnerability. Regularly check for new vulnerabilities in the NVD database. For example: