Helix ALM Security Best Practices

Helix ALM clients exchange data with the Helix ALM Server, which also exchanges data with the license server and any other Helix ALM applications you use. To keep your data secure, encrypt communication between clients and servers. Encryption scrambles data to reduce the likelihood of interception, or eavesdropping, as it passes between client and server applications.

To encrypt Helix ALM communication, select Encrypt communication between clients and the server in the security options in the Helix ALM Server Admin Utility.

Note:  The OpenSSL version used by Helix ALM is displayed with the security options. Any OpenSSL vulnerabilities are published on the OpenSSL web site. To check if OpenSSL vulnerabilities impact Helix ALM, check the knowledgebase or contact Perforce Support for information.

To encrypt license server communication, select Encrypt communication between the license server and other applications in the server options in the Helix ALM License Server Admin Utility.

Note:  These options do not affect login credentials sent from Helix ALM web clients to the Helix ALM Server and license server. To encrypt communication between browsers and the CGI, configure HTTPS on your web server.

We strongly recommend using RSA key exchange on the Helix ALM Server and license server if your network is potentially insecure or any users access client applications outside your network using a username and password. RSA is a public encryption algorithm that uses separate keys for encryption and decryption, which helps prevent man-in-the-middle attacks where a hacker intercepts or alters communication between clients and servers. See Securing communication between clients and servers for information.

To enable RSA key exchange, select Use RSA key exchange when encrypting communication for Helix ALM and the license server. The following screenshot shows RSA key exchange enabled in the Helix ALM Server Admin Utility.

When RSA key exchange is enabled, public and private key files are generated and clients can only connect to the server when the correct key is exchanged. The key files remain on the server hard drive. Download the server settings XML file to a secure location and distribute it to authorized users so they can import the public key fingerprint in client applications used to connect to the Helix ALM Server or license server. The following screenshot shows a server connection configured to use a public key fingerprint.

Tip:   Update security permissions on the RSA key files to better protect them. Only the server needs read and modify access to the private and public key files on the server computer. All users need read access to the downloaded server settings file, but only administrative users should have access to modify it. See the operating system help for information about file security.

Set a license server communications password to secure communication between the license server and other Helix ALM product servers, and prevent unauthorized servers from using licenses. To set the communications password, enter and confirm the password in the server options in the license server admin utility.

After the communications password is set, you must also enter it in the Helix ALM license server options so the servers can communicate with each other. The following screenshot shows the communications password set in the Helix ALM Server Admin Utility.

If users do not connect to Helix ALM from outside your network, configure a firewall and network address translation (NAT) to separate the Helix ALM Server and license server from the internet. Any server exposed to the internet is vulnerable to hackers who can destroy data, encrypt data and hold it for ransom, or exploit your company’s products. The specific security measures needed depend on your network configuration. Ask your network administrator for help.

In the Helix ALM Registry Utility, configure server security options to control access to Helix ALM data from external source control providers. These options can help prevent hackers from decrypting provider keys for external source control provider integration and automatically disable access and reject requests from clients after failed access attempts.

Review the Helix ALM Server and license server logs regularly to check for suspicious activity. For example, consecutive failed login attempts from an external IP address in the log could indicate that a hacker is probing your server for security weaknesses and additional security measures are needed.

The following screenshots show the Helix ALM Server and license server logs.

You can also enable email notifications in the Helix ALM logging server options to stay informed as events are added to the server log and when user logins fail.

Make sure you always use the most recent Helix ALM version. Upgrading when a new version is available not only provides you with the newest features, but could also provide additional security options not available in earlier versions.

To automatically check for new versions, select Automatically check for Helix ALM updates in the auto update check options. You can also set options to automatically email users when upgrades are available.

To manually check for updates, select Check for update in the update check options.

Make sure to also review any new RDBMS updates and security patches. Installing these updates keeps your RDBMS running with the necessary features to meet current security standards. See the RDBMS help for information.

Encryption options in the Helix ALM Server and license server admin utilities only secure data that passes between desktop clients and server applications. Login credentials sent from web clients to the Helix ALM Server and license server are not encrypted. If users access Helix ALM Web from outside your network, configure HTTPS on the web server that hosts it to encrypt communication between browsers and the CGI. See the web server help for information about HTTPS.

Clickjacking can occur when hackers use transparent frames or iframes to embed content in web pages to trick users into clicking buttons or hyperlinks on a different web page in another domain or application. To protect your data and prevent clickjacking in Helix ALM Web and the license server web admin utility, configure the web server that hosts them to include X-Frame-Options and Content-Security-Policy HTTP response headers. See Preventing Clickjacking Attempts on Helix ALM Web Clients for information.

Helix ALM clients and the license server admin utility do not need write access to database files because they pass data through the server applications. Restrict access to database files to prevent users or other processes from modifying or deleting data.

If your data is hosted in native SQLite databases, only the Helix ALM Server and license server processes need write access to database files. If your data is hosted in PostgreSQL, Oracle, or SQL Server, only the database server process needs write access to database files. See the operating system help for information about configuring file security for SQLite files or ask your DBA for help with security for RDBMS files.

Always back up your data regularly. Nightly backups ensure data loss is minimal if a virus attack, hardware failure, or malicious activity occurs.

Make sure to back up the license server database, Helix ALM Server database, and Helix ALM project databases to decrease the likelihood of data loss.

Tip:  Use the Helix ALM Native Database Backup Utility to back up Helix ALM native (SQLite) project databases without stopping the Helix ALM Server. See Backing Up Native Project Databases for information.

Data loss can occur due to virus attacks, hard drive failures, or file system corruption. Take the following measures to prevent data corruption on computers that host the Helix ALM Server, license server, and the server and project databases.

• Use an uninterruptible power supply (UPS).
• Make sure the hard drive is properly maintained and in good condition.
• If you need to shut down the computer, make sure it is done correctly.

Note:  If you think your data files are corrupt, contact Perforce Support immediately. Data is recoverable in most instances. A corrupt database may lead to an extended amount of down time. If a database backup is not available, you may have to send your data files to Perforce for in-house data recovery.

Default administrative user and local admin user passwords are set on the Helix ALM Server during installation. The default administrative user (Administrator) lets you log in to Helix ALM for the first time to add users and security groups and configure project options. The local Helix ALM admin password gives you access to license server settings when Helix ALM cannot connect to the license server. Change these passwords the first time you use Helix ALM to prevent unauthorized access.

To change the administrative password, edit the Administrator user in Helix ALM. You can also delete this user after you set up another administrative user to replace it.

Note:  The default Administrator account is a global user shared between the license server, Helix ALM, and Surround SCM. Password changes for this account in Helix ALM also affect the default login credentials for the license server admin utility and Surround SCM.

To change the local Helix ALM admin password, update it in the server options in the Helix ALM Server Admin Utility.

Passwords are one of the easiest ways to protect against unauthorized access. Many users choose weak passwords. Make sure your team uses industry-standard methods to create strong passwords. Effective passwords should:

• Be a minimum of eight characters
• Use mixed case and a combination of alphanumeric characters and punctuation
• Not contain personal information or elements of the username
• Not be real words or patterns of letters on a keyword
• Not follow the pattern of previous passwords
• Be easy to remember but difficult to guess

Configure password requirements, such as minimum password length and required character types, in the license server admin utility to force users to set strong passwords.

Note:  These requirements only affect users stored on the license server. Password restrictions for LDAP and Active Directory users are configured on the corresponding server. See the LDAP or Active Directory server help for information about setting password restrictions.

Security groups control user access to Helix ALM actions. A user only has access to perform actions based on the enabled commands for the security group they are assigned to. Carefully consider the access users in different roles need and set up security groups accordingly to avoid security issues.

When creating security groups, only enable command security for the actions you want users in the group to access. This reduces the potential for users to accidentally modify data or settings they should not have access to.

Tip:   If you use the Helix ALM SDK, create a dedicated SOAP user and assign it to a security group that only has security commands enabled for actions performed by the application that uses SDK. For example, select the Allow Login Via SOAP command and clear other login commands.

The Helix ALM REST API authenticates with the Helix ALM Server when getting a list of projects or an access token. We recommend using the following configuration for stronger security with the REST API.

• Add a Helix ALM user specifically to use for changes made through the API. If you have multiple integrations, add a separate user for each integration with the API. The history and audit log will show that the API user made changes instead of individual users. Do not enable single sign-on for the dedicated REST API users.
• Add the dedicated API user to a security group that only has commands enabled for actions performed by the application that uses the API. For example, enable the Allow Login Via SOAP command, which is required to use the REST API, and disable all other login commands.
• Use an API key to authenticate the dedicated user more securely with the REST API. An API key consists of a key ID and key secret, which you add to the Authentication header in the REST API. See Authentication in the REST API help.

If you use a username and password to authenticate and the credentials for the integration are compromised:

• Anyone can log in to Helix ALM using any client the user has permission to log in to.
• Anyone may be able to use the credentials to access other network resources if an Active Directory or LDAP username and password was used.
• The only recourse is to change the password, which will require updating all integrations that use the credentials.

We recommend API key authentication because:

• The key and key secret are longer, cryptic strings that are difficult to decode.
• The key can only be used with the REST API. If a key is comprised by a hacker, they cannot use it to log in to Helix ALM clients.
• A user can have multiple keys for different integrations. If a key is compromised, you can delete the key without breaking other integrations or updating credentials in each one.