Security Recommendations
This section provides guidelines on how to maintain a safe computer and SafeNet IDPrime Virtual (IDPV) environment.
Ensuring Security in IDPV Desktop Application
Secure Environment
- Administrators must manage all configurations and installations. Access restrictions should prevent endusers to install or modify IDPV application settings.
- Avoid user accounts with administrative privileges.
- Install an anti-virus software on every computer and schedule periodic scans.
- Set up a network firewall and relevant network security utilities.
- Regularly update IDPV Client and IDPV Server. As latest build contains fixes against newly identified vulnerabilities.
- On the end-user computer, it is essential to apply security restrictions to protect against malicious application such as fake credential provider, key logger or trojans.
Secure Installation
- Only use Thales product installers. Before installing the software, verify its integrity using the checksums provided in the release guidelines.
-
Only download and install the IDPV Client Package from the official Thales website. Perform the following steps to ensure Thales certificate is being utilized:
-
After downloading the package (MSI/EXE), right-click the file, and select Properties.
-
On the Properties window, go to the Digital Signatures tab, and verify that the Thales signature is listed.
-
Select the Thales signature and click Details.
-
On the Digital Signature Details window, go to the General tab, and verify that the text "The digital signature is OK." is displayed.
-
-
Install managed applications into a target installation folder for which non-admin users do not have modification privileges.
- Secure local machine registries to avoid configuration modifications.
Secure Usage
- Restrict access to logs (Windows logs and applications logs) as well as offline bundle.
- Use MFA when the end-user authenticates through the identity provider server. Do not rely on traditional password mechanism only.
- Do not share your IDPV virtual token pin or IDP password with anyone.
- Administrator should periodically review logs for suspicious activities such as authentication and user access & changes.
- Implement regular backups of critical application data and test backup restoration procedures.
- Understand and comply with end-user license agreements (EULAs).
Ensuring Secured SafeNet IDPrime Virtual Environment
This appendix provides guidelines on how to maintain a safe computer and SafeNet IDPrime Virtual (IDPV) environment.
• Restrict exposure of sensitive information such as certificates, keys, and passwords.
• Responsibility for security certificates, keys, and passwords should be divided among multiple personnel. No individual should have responsibility for all servers (for example, IDPV, database, and HSM).
The following information is based on the security recommendations defined by Microsoft.
Strong PIN Policy
A strong PIN policy is highly recommended to ensure the secured SafeNet IDPV environment. Use a PIN with minimum length of 8 characters. The PIN must be a combination of at least one numeric character, upper case, lowercase, and a special character.
Admin Key Policy
The default Admin key of a token is 48 times zeros. If it is required to change the admin key, then its value depends on the Luna HSM’s FIPS configuration.
If you divide admin key into the following three parts of the same size:
-
k1[1-16]
-
k2[17-32]
-
k3[33-48]
The two cases available are:
-
In Luna non-FIPS mode, you can use any combination of k1, k2 & k3.
-
If Luna is configured in FIPS mode, then you can choose all the three keys unique from one another such as:
- k1≠k2≠k3 (All three keys must be unique)
- k1≠k3=k2 (k2 can be identical to k1 or k3)
This is depicted with examples in the following table.
Luna HSM Mode | Key Combination | Permission | Example |
---|---|---|---|
Non-FIPS | k1=k2=k3 or k1≠k2≠k3 (any combination) | Allowed |
|
FIPS | k1≠k2≠k3 or k1≠k3=k2 ( k2 can be identical to k1 & k3) | Allowed |
|
FIPS | k1=k2=k3 or k1=k3≠k2 (k1 & k3 can be identical) | Disallowed |
|
Windows Malware Prevention
Up-to-date security software is the best way to help protect your computer from a malware attack. Microsoft provides security software that is regularly updated to protect against the latest threats.
For more information, go to https://www.microsoft.com/en-us/security.
Enabling Automatic Windows Updates
Automatic Windows updates ensure that you are running software with the latest security enhancements. When new updates are available, Windows sends you a notification. Accept the updates with a click and they download and install automatically.
Anti-Virus Software
Make sure to choose an effective Anti-Virus/Malware software to protect your client machines. It is essential to keep the Anti-Virus/Malware software updated.
MYSQL Version
To prevent unauthorized access, ensure that the MySQL version in use is greater than v5.7.26.
SAC Package
Install SAC Package only from the Official Thales Site.
Perform the following steps to ensure Thales certificate is being utilized:
-
After downloading the package (MSI/EXE), right-click the file and select Properties.
-
In the Properties window, click Digital Signatures tab, and verify that the Thales signature is listed.
-
Select the Thales signature and click Details.
In the Digital Signature Details window, click the General tab, and verify that the text The Digital Signature is OK is displayed.
Malware Awareness
Malware authors use several common tricks to install their malicious software on your PC. Understanding the most common ways they do this can help you stay protected.
-
Email: Malware often arrives on your PC in an email attachment. You should never open an attachment from someone you do not know or if an email looks suspicious. Instant messages and requests for file transfers can also spread malware.
-
Websites: Never open links to webpages that you don’t recognize or that are sent from people you do not know. Malicious websites can install malware on your PC when you visit them.
-
Use caution: If you view a website that does not look quite right, or unexpected things happen when you visit, close your browser, download the latest updates for your security software and perform a quick scan on your PC.
-
Pirated software: Malware is often bundled together with pirated software. When you install the pirated software you may also install malware.
-
Social engineering: Malware authors often try and trick you into doing what they want. This can be clicking or opening a file because it looks legitimate, paying money to unlock your PC or visiting a malicious webpage. These deceptive appeals are known as social engineering.
-
Passwords: Attackers may try to guess your Windows account or other passwords. This is why you should always use a password that cannot be guessed easily. A strong password has at least eight characters and includes letters, numbers, and symbols.
-
Removable drives: Some types of malware, such as worms, can spread by copying themselves to any USB flash drives or other removable drives that are connected to your computer. Always be careful when sharing removable drives, and make sure you scan them.
Limit User Privileges
Many malware threats need full access to your computer to execute properly. Windows 10, Windows 8.1, Windows 7, and Windows Vista use User Account Control (UAC) to limit program's actions without permission.
This means you will be notified if any software or application tries to make any changes to your system. It can also help stop malware and unwanted software from installing themselves or changing the way your computer works.
Windows 10 Elevated Security
In Windows 10 and Windows Server 2016, you should use Credential Guard to enhance security.
For more information, refer to Microsoft site.
Additional Environment Recommendations
The following actions will help keep your information as safe as possible:
-
Enable Windows Defender.
-
Control access to your computer by locking your screen after a period of inactivity.
-
Set up secure file sharing.
-
Make sure you're running only those sharing services that you really need.
-
Use a local account - This provides greater security than, for example, a Microsoft account which, if hacked, it will enable remote logon to your applications.
-
Enable secure boot and UEFI, instead of legacy BIOS.
-
Disable Flash and Java. These frequently report security vulnerabilities.
-
Encrypt hard drive. This will protect your data if your computer accessed directly.
Restricting Non Secure Connections on Database
As an enhanced security measure, it is recommended to enable TLS on the Database and restrict non- secure connections. For more information on guidelines for securing connections to MySQL Database, refer to Setting up and Accessing MySQL Server. For other databases including MSSQL and MariaDB, refer to their official websites respectively.
Enhanced Security Configuration
HSM Partition Ownership by IDPV Server
To connect to the HSM partition, a TokenPin (HSM crypto officer pin placed in the appsettings.yml
file) and a TokenSerial (partition serial number) are required.
Presence of HSM pin in the .yml
file makes it vulnerable to the unauthorized access. To prevent this, a TokenPasscode
value is used to change the TokenPin
by the IDPV server when it boots for the first time. As this changed pin is managed by the IDPV server, the server takes the complete ownership of the HSM partition; this prevents any unauthorized access to the HSM partition.
Security Error Messages
HTTP Status Code/Error Code | Error Description | Intended Recipient |
---|---|---|
412 | A precondition provided in the request (such as an if-match header) does not match the resource's current state. | Admin User |
401 | For security reasons, you must change the token password. | Admin User |
401 | Login with admin key to unlock the token. The token authentication failed. | Admin Users |
401 | Authorization Failed. | Admin User |
401 | Resource cannot be accessed with the provided claim. Authorization Failed. | Admin User |
57 (Error Code) | Tenant record (Id:{0}) integrity might have been compromised |
Admin User |
500 | Key record (Id:{0}) integrity might have been compromised. Internal Server Error Occurred. |
Admin User |
500 | Token record (Id:{0}) integrity might have been compromised. Internal Server Error Occurred. |
Admin User |
Docker Security Guidelines
Security holds prime importance for critical business applications. This section lists the security risks using SafeNet IDPrime Virtual Server Docker images and containers. Additionally, it suggests best practices to mitigate those risks.
Recommendations
-
You should not expose the Docker API to the general public.
-
If you chose to expose the Docker API, secure it with TLS certificates.
-
Confirm that users are trained not to reveal their credentials.
-
Security of containers
-
Don’t execute processes as root
-
Don’t group security sensitive containers
-
Run AppArmor or SELinux
-
For more information, refer to CIS Docker Benchmarks.
Securing Docker with TLS
Docker gains access controls on its network API using Transport Layer Security (TLS). This protocol secures the websites with https URLs, and uses Public Key Cryptography to encrypt connections.
In this technique, keys are signed with certificates that are maintained by a trusted party, and each transaction is encrypted and authenticated. Docker provides mechanisms to authenticate both server and client. Additionally, it provides strong authentication, authorization, and encryption for any API connection over the network.
Perform the following steps to secure docker with TLS:
-
Prepare the environment, and confirm the following:
-
OpenSSL version 1.0.1 is installed on your machine.
-
Directory is created for all files and it is protected and backed up.
-
Files are similar to root password.
-
-
Create a Certificate Authority: Initialize the CA serial file and generate CA private and public keys, as
$ echo 01 > ca.srl $ openssl genrsa -des3 -out ca-key.pem 4096 $ openssl req -new -x509 -days 365 -key ca-key.pem -out ca.pem
ca.pem file will be used to sign all other keys later.
-
Create and Sign the Server Key: After getting the CA, you need to create a server key and certificate signing request. Confirm that the CN matches the hostname on which you run the Docker daemon:
$ openssl genrsa -des3 -out server-key.pem 4096 $ openssl req -subj '/CN=<Your Hostname Here>' -new -key server-key.pem –out server.csr $ openssl rsa -in server-key.pem -out server-key.pem
Thereafter, sign the key with your CA:
$ openssl x509 -req -days 365 -in server.csr -CA ca.pem -CAkey ca-key.pem -out server-cert.pem
-
Create and Sign the Client Key: Create the client key and certificate signing request as:
$ openssl genrsa -des3 -out client-key.pem 4096 $ openssl req -subj '/CN=client' -new -key client-key.pem -out client.csr $ openssl rsa -in client-key.pem -out client-key.pem
Create the
extensions config
file to make the key suitable for client authentication:$ echo extendedKeyUsage = clientAuth > extfile.cnf
Thereafter, sign the key with your CA:
$ openssl x509 -req -days 365 -in client.csr -CA ca.pem -CAkey ca-key.pem -out client-cert.pem -extfile extfile.cnf
-
Configure the Docker Daemon for TLS: To configure Docker daemon for TLS, enable remote connections using the –H flag and mention the port as 2376:
$ sudo docker -d –tlsverify --tlscacert=ca.pem --tlscert=server-cert.pem --tlskey=server-key.pem -H=0.0.0.0:2376
Modify the startup scripts on your server and the keys should be placed in a secure system directory, such as
/etc/docker
. -
Configure the Docker Client for TLS: To secure Docker client connections, move the key files to .docker directory, located in your home directory. Additionally, set the DOCKER_HOST variable:
$ cp ca.pem ~/.docker/ca.pem $ cp client-cert.pem ~/.docker/cert.pem $ cp client-key.pem ~/.docker/key.pem $ export DOCKER_HOST=tcp://:2376
Next, run Docker with the
--tlsverify
option as$ docker --tlsverify ps
TLS Deployment Recommendations
Transport Layer Security (TLS) is the cryptographic protocol for securing communications between web applications and server. When secured with TLS, communication between the client and server must follow the recommendations listed below.
The TLS certificate must be kept secured and must not be exposed.
Mandatory Recommendations
- Do not use any version of SSL. Disable support for SSL.
- Currently, IDPV solution supports TLS v1.2 and TLS v1.3 so accordingly configure on the client machines. Disable protocols at proxy server level if configured.
- Support the extension Signaling Cipher Suite Value
TLS_FALLBACK_SCSV
. This prevents the protocol downgrade attacks on TLS. -
Do not use the following cipher suites:
- Ciphers offering Null encryption: eNULL, NULL (the suites that offer no encryption)
- Ciphers offering Null authentication: aNULL (the suites that offer no authentication) aNULL includes anonymous cipher suites such as ADH (Anonymous Diffie-Hellman) and AECDH (Anonymous Elliptic Curve Diffie-Hellman)
- Ciphers using export encryption algorithms: EXP
- Ciphers suites with LOW encryption, i.e. using symmetric keys’ length less than 128-bits
- Cipher suites using MD5 as hashing algorithm
- Cipher suites using IDEA
- Cipher suites using RC4
- Cipher suites using Non-Ephemeral (Elliptic Curve) DH
- Cipher suites using DHE with DHE key-length less than 1024
- Cipher suites using DSA/DSS (Digital Signature Algorithm/Digital Signature Standard) authentication Using DSA/DSS may result in weak signature operation if a bad entropy source is used
Example:
Nginx:ssl_ciphers HIGH:!aNULL:ECDH+AESGCM: ECDH+AES256:ECDH+AES128:DH+3DES:!ADH:!AECDH:!MD5;
The above list is not exhaustive and may change when new vulnerabilities of the cipher suites are identified.
-
Once a secure session has been established, a renegotiation may be possible (renegotiation refers to an attempt to repeat the negotiation on an existing connection). There are four types of renegotiation:
- Secure Client Renegotiation
- Insecure Client Renegotiation
- Secure Server Renegotiation
- Insecure Server Renegotiation
Either disable the renegotiation, or if renegotiation is required, use only secure renegotiation.
-
Disable compression in SSL/TLS and SPDY.
-
Configure TLS cipher suite order preference. The TLS server shall define the CipherSuites Order. A TLS server determines the CipherSuites Order using a flag. This ensures that the cipher preferences defined in server setup are followed instead of those provided by the client. The method or the flag for selecting the order is not standardized. That is, it depends on the application server.
Example:
Flag or Method for the server to define the CipherSuites order:
Apache SSLHonorCipherOrder on Nginx ssl_prefer_server_ciphers On Tomcat useCipherSuitesOrder="true" honorCipherOrder="true" Pure Java SSLParameters.setUseCipherSuitesOrder(true)
Recommendations
-
The use of Authenticated Encryption (AE) or Authenticated Encryption with Associated Data (AEAD) ciphersuites, e.g. GCM (providing encryption + authentication) is preferred instead of CBC (only encryption).
-
Always use Diffie-Hellman algorithm with key-strength same as your RSA/EC key-size. The recommended key-length for DHE cipher suites with RSA is 4096 while for ECDHE, the recommended key-length is 224.
-
Use cipher suites with DHE or ECDHE key exchange. This key exchange(s) use ephemeral keys and have forward secrecy property.
-
To ensure compatibility in a Medium Term, use the following configuration:
- TLS v1.2 or TLS v1.3
- Support for Server Name Indication (SNI)
- At least TLS6+_ECDHE_RSA_WITH_AES_128_GCM_SHA256 cipher suite should be enabled.
The flags or options listed below can be added as Cryptography TLS guidelines:
Example (Nginx configuration):
ssl_session_cache shared:SSL:1m; ssl_session_timeout 10m; ssl_ciphers HIGH:!aNULL:!MD5; # Use only TLS ssl_protocols TLSv1.2 TLSv1.3; # Tell client which ciphers are available ssl_prefer_server_ciphers on; ssl_ciphers ECDH+AESGCM:ECDH+AES256:ECDH+AES128:DH+3DES:!ADH:!AECDH:!MD5; # Enable HSTS add_header Strict-Transport-Security "max-age=31536000; includeSubDomains"; # Enable session tickets ssl_session_tickets on;
-
Use a reverse proxy while deploying an IDPV server container. It manages and optimizes traffic between clients and servers enabling organizations to improve their web services.
Key Functions of a Reverse Proxy
- Load Balancing - Distributes incoming network traffic across multiple servers to optimize resource utilization and improve performance.
- Caching - Stores copies of frequently requested content to reduce load times and server strain by serving cached responses directly to users.
- Security - Filters and inspects incoming traffic, providing SSL termination, and hiding backend server details to protect against threats and attacks.
- Traffic management - Directs and controls incoming requests to appropriate backend servers based on rules, load, and performance criteria.
- SSL offloading - Handls SSL/TLS encryption and decryption on behalf of backend servers to improve performance by reducing their processing load.
Implementation Considerations
When implementing a reverse proxy, consider the following factors:
- Choice of Software - Popular software solutions for reverse proxies include NGINX, HAProxy, and Apache. The choice depends on factors, such as ease of configuration, performance requirements, and community support.
- Configuration - Proper configuration is essential for a reverse proxy to function effectively. This includes setting up DNS records, configuring virtual hosts, and ensuring that backend servers are correctly set up to handle requests forwarded by the proxy.
- Testing - After configuration, thorough testing is required to ensure that the reverse proxy operates as intended and efficiently handles requests and responses between clients and backend servers.
Note
For more information, refer to the official documentation of the above tools.
Recommendation for Azure Virtual Desktop (AVD) Multi-user Session
For Azure Virtual Desktop (AVD) multi-user session, Microsoft has recommended a minimum of 8 vCPUs, 16-GB RAM, and 32-GB storage.
For more information, refer to Microsoft documentation.