Surround SCM Security Best Practices

Surround SCM clients exchange data with the Surround SCM 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 Surround SCM communication, select Encrypt communication between clients and the server in the general global server options.

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.

We strongly recommend using RSA key exchange on the Surround SCM 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 the Surround SCM Server for information.

To enable RSA key exchange, select Use RSA key exchange when encrypting communication in Surround SCM and the license server admin utility. The following screenshot shows RSA key exchange enabled in Surround SCM.

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 Surround SCM Server or license server. The following screenshot shows a server connection configured to use a public key fingerprint.

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 Surround SCM license server options so the servers can communicate with each other. The following screenshot shows the communications password set in Surround SCM.

If users do not connect to Surround SCM from outside your network, configure a firewall and network address translation (NAT) to separate the Surround SCM 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.

Review the Surround SCM 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 Surround SCM Server and license server logs.

You can also enable email notifications in the Surround SCM 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 Surround SCM 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 Surround SCM updates in the auto update check server 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 server 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.

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 the license server web admin utility, configure the web server that hosts it to include X-Frame-Options and Content-Security-Policy HTTP response headers. See Preventing Clickjacking Attempts on Helix ALM Web Clients for information.

Surround SCM 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.

For PostgreSQL or SQL Server, only the database server process needs write access to access database files. If the license server database is in native SQLite format, only the license server process needs write access to the database file. Ask your DBA for help with security for RDBMS files or see the operating system help for information about configuring file security.

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, Surround SCM Server database, and any mainline branch databases to decrease the likelihood of data loss.

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 Surround SCM Server, license server, and the server and mainline branch 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.

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

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

To change the local SCM admin password, update it in the general global server options.

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.

Security groups control user access to Surround SCM 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.

Security levels

Surround SCM has server, repository, and branch security. The different levels give you granular control over individual branches and repositories and let you configure more complex security scenarios when needed.

• Server security restricts actions users can perform in all branches and repositories, and controls access to general actions, administrative actions, user and security group management, and file and branch actions.
• Repository security restricts the file-related actions users can perform in specific repositories across all branches. If repository security is configured for a security group, users in the group can only perform actions enabled for the specified repositories.
• Branch security restricts the file-related actions users can perform in specific repositories in specific branches. If branch security is configured for a security group, users can only perform actions enabled for the specific branches. Branch security is generally used to give a security group access to a specific branch while maintaining the repository security settings in other branches.

Most organizations only need to configure server security based on user roles to provide access to specific actions in all branches and repositories. You can also override security for specific repositories and branches to restrict users who can access them and the actions they can perform.

How security is applied

By default, Surround SCM security is restrictive, or pessimistic, which means no commands are enabled when you create a new security group and users can only perform actions if the corresponding command is enabled. For example, new users cannot log in to the desktop client unless they are added to a group with the Login Via GUI Client command enabled. Users can be in multiple groups. If a command is enabled in at least one group a user is in, they can perform the action.

Repository or branch security can override server security file permissions. For example, users in the Developers group can destroy files because the Destroy File command is enabled for the group. If security for the Licenses repository is modified and the Destroy File command is not enabled, users in the Developers group cannot destroy files in that repository, but they still can in other repositories because of the default server security. Repository security always overrides server security and branch security always overrides repository and server security.

Repository-level security

To manage a large number of users and projects with minimal administrative effort, consider using the following repository-level security model.

1. Create an All Users security group to allow read-only access to all repositories

Add this security group as a baseline for all users, which you can then build on by creating other groups with more specific security settings and configuring security for specific repositories and branches. Add all new users to this group.

Configure server security for the group. Select all commands in the General category and make sure all commands in the Admin, Users, Security Groups, and Branch categories are cleared. In the Files (Default) category, only select the View Repository List command to allow users to view repositories and files but not perform any actions that require read/write access, such as checking files in and out. The following screenshot shows the enabled commands for the All Users group.

2. Optionally create a Power Users security group

To allow other high-level users, such as managers or team leads, to perform some administrative actions, create a Power Users group. Duplicate the default Admin group, rename the new group, and clear any commands these users do not need. For example, these users may not need to edit server options or analyze, repair, or lock databases.

3. Create a security group for each project repository

When a repository for a new project is created, add a new security group and then add users working on the project to it. Enable the appropriate file commands for the group so they can work with files as needed. If users are not assigned to the group created for a project, they can only view the repository because no other file commands are enabled in the All Users group.

4. Hide repositories from non-project users

If you only want users in a project-based group to see repositories or files, hide repositories so users who are not in the group cannot see them.

To hide a repository, modify its properties and make sure only the group that needs access to it has all or some security enabled. Add <All other groups> to disable all security for all other groups, including any groups created later. The following screenshot shows the security overrides to hide a repository from all groups except the Wysi Developers project group.

Branch-level security

When new branches are created, repository security from the parent branch is inherited and used by default. If you only want a specific group of users to have read/write access to a branch, set the branch to use its own security and add a security group for the branch users.

Only use branch security when you want to provide a group with access to a specific branch while retaining repository security settings in other branches.

1. Set the branch to start with no specific security applied

Users with access to the repository in the parent branch can access the repository in the new branch. Configuring the branch to use its own security overrides the server and repository security settings to provide access only to users in selected groups.

To set a branch to use its own security, edit the properties to start with no specific security applied.

2. Create a branch security group

After a branch is set to use its own security, add a security group that only includes users who need to access it. Make sure the branch is added on the Branch Security tab in the group and the commands for the file actions users may perform are selected. The following screenshot shows the Wysi 2.0 Developers group and the enabled commands for the WysiDraw 2.0 Code branch.

3. Override branch security for groups that do not need to access it

If a branch is set to use its own security, repository security inherited from the parent branch is removed and all security groups can view it by default. To hide a branch from a specific security group, edit the group and make sure the branch is added on the Branch Security tab with all commands cleared. The following screenshot shows the All Users group branch security overridden to disable all commands for the WysiDraw 2.0 Code branch. Users in the group cannot access the branch.