Security considerations for HCL Compass

You can take actions to ensure that your installation is secure, customize your security settings, and set up user access controls. You can also ensure that you know about any security limitations that you might encounter with this application.

Enabling security during the installation process

The HCL Compass product has several installable components that are classified as either desktop components or server-based components. During the installation process, there are few options that are directly related to security. However, before and after the installation, you can perform configuration steps to enhance the security of the Compass applications.
  • Desktop applications include the Compass Client and the Compass Client for Windows™. For these clients to work, you must make database connections to your Compass databases. To create these connections on Windows systems, you use the Compass Maintenance tool. To create these connections on UNIX™ and Linux™ systems, you use the cqreg command-line utility.
  • A Compass web server runs on the IBM® WebSphere® Application Server. Follow general instructions for enhancing the security of your WebSphere Application Server deployment. The Compass web components can also be configured to enhance security. Best practice is to always use SSL https connections to the Compass web server from the browser because user login credentials are passed over this connection. SSL encrypts all data that is passed over an https connection.

Enabling secure communication between multiple applications

HCL Compass integrates with many types of applications. Always use SSL https connections between the Compass web server and any other web-based application.

Ports, protocols, and services

Configure HCL Compass web server to use the SSL https protocol.

Customizing your security settings

  • It is important to configure the WebSphere Application Server settings for high levels of security.
  • Feature level 7 uses stronger encryption algorithms than previous feature levels. For more information, see Features in the feature levels.
  • Compass supports configurations for the FIPS 140-2 encryption standards. Best practice is to configure Compass for this standard. For more information, see Configure FIPS 140-2 approved data encryption.

Setting up user roles and access

  • Compass manages the change management records of an organization, department, or project in a database called the user database. For more information, see User databases. A deployment might use multiple user databases, or a single database. Multiple databases might be grouped under one schema repository that contains process workflows called schemas. For more information, see Schemas and schema repositories.
    • The best data isolation is provided by having different user databases on a per-project or per-organization basis. User access to the databases can be granted to control who can access the data in a database. Each database requires a separate user login to grant access. Compass references to data records do not traverse across user databases. Data records might reference data in other user databases by using REST URLs in notes, or by using Open Services for Lifecycle Collaboration (OSLC) links if special configurations are performed.
    • It is often desirable for different projects or organizations to have access to all or some of each others data. In those situations, it is convenient to have only one user database. Compass provides a feature called security context that you can use to hide data records from users who are not a member of a specified access control group. Because all the data is in one repository, Compass references to data records can be used. You must take care to protect and hide records by using the security context feature. For more information about the security context feature and creating a security model, see Creating a security model.
    • Compass uses a role-based access control (RBAC) model for enforcing workspace security. Workspace folder permissions provide a high level of control over the visibility and modification of workspace folders by allowing those with Security Administrator and Public Folder Administrator privileges to assign specific permissions to user groups on specific folders. For more information, see Introduction to workspace folder permissions.
    • Compass provides a highly customizable system for controlling who can perform which action by using hooks. Hooks are entry points, like triggers, for scripts that run at specified times to control how users work in a Compass environment. Action access-control hooks can control who has permission to change record values. Field access-control hooks enforce access permissions that permit only the user groups that you specify to change field values. For more information, see Hooks.
  • Compass provides the User Administration tool for adding users and user groups, which controls access to Compass databases. Users and groups are added to the master schema repository. Users and groups are then subscribed to specific user databases. This subscription allows control over which users can access a user database. For more information, see Managing user accounts.
  • Compass provides two kinds of user authentication, Compass application-based and LDAP-based.
    • LDAP authentication is preferred because most LDAP servers provide password policy enforcement such as password strength and lockout after excessive failed attempts. For more information, see Using LDAP with Compass.

      Use SSL to securely pass the user credentials between the Compass application and the LDAP server. For more information, see Setting the Compass LDAP connection information for SSL.

    • Compass authentication provides a simple mode of authentication where the user name and encrypted password are stored in the Compass database. There is no password policy enforcement.
  • You can grant privileges to users to perform certain restricted operations in Compass. The Super User privilege grants all capabilities. The Super User can then grant other users their privileges. For more information, see User privileges.
  • When Compass creates a user database, it creates five user accounts for testing the initial test deployment. These accounts are admin, engineer, lead, QE, and user. Best practice is to rename the admin account to some other name that attackers are not likely to guess, and to give the account a complex password. Best practice is to change the other preloaded accounts. You can do this by changing the names on these accounts to service actual users. Or, you can mark these user accounts as inactive, change the user name and password to a complex set of characters, and remove all privileges. User accounts cannot be deleted from Compass; they can only be marked as inactive.

Privacy policy considerations

Depending on the configurations that are deployed, this software offering uses cookies that might contain personally identifiable information. For information about this offering's use of cookies, see the Notices

HCL Compass stores some persistent cookies and session cookies on the web client system. Storage of persistent cookies can be disabled. For information about persistent cookies and session cookies, see Persistent cookies and session cookies.

Security limitations

HCL Compass continuously enhances the security aspects of its components and remedies issues that are encountered. Plan to upgrade to the latest releases of Compass when they are available because these releases might contain security enhancements or corrections. Monitor the Compass and WebSphere Application Server security flash bulletins for security alerts and information about actions to perform.