Security considerations for the Rational solution for Collaborative Lifecycle Management and IoT CE Solution

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 installation

If you are installing Jazz® Team Server and other Rational® solution for Collaborative Lifecycle Management (CLM) applications on z/OS®, several tasks are required to make the CLM functions secure and available on z/OS.

Several WebSphere® Application Server security settings, such as administrative security, application security, and securing cookies must be enabled before deploying CLM applications. For more information, see Setting up WebSphere Application Server.

To be compliant with U.S. government Special Publications SP800-131 standards that is used to accredit cryptographic modules, you must configure your servers, clients, and browsers. For detailed information, see Support for National Institute of Standards and Technology (NIST) Special Publication (SP) 800-131.

Auditing the security infrastructure

You can use the Auditing Facility to report and track auditable events to ensure the integrity of your system in a WebSphere Application Server environment. For more information, see the WebSphere Application Server documentation.

Ports, protocols, and services

You can add a reverse proxy to your server to provide an additional layer of security.
You can import your WebSphere Application Server certificate into the HTTP server plug-in.
If you do not want to use the default port numbers, you can change them.

Customizing security settings

Configuring security certificates:

Setting up user roles and access

Managing users on WebSphere Application Server:
Managing users on IBM WebSphere Application Server Liberty Profile
Managing users on Apache Tomcat:

To understand the authentication mechanism that Jazz Team Server uses, see this Jazz.net article: TN0013: Jazz Team Server Authentication Explained.

Privacy policy considerations

Depending on the configurations that are deployed, this software offering might use cookies that can help enable you to collect personally identifiable information. For information about this offering’s use of cookies see the Notices topic.

To secure LTPA cookies, you can enable the Requires SSL setting in the WebSphere Application Server Console. For more information, see Setting up WebSphere Application Server.

The Rational solution for Collaborative Lifecycle Management (CLM), collects and processes only basic personal information for each user:
  • User name
  • Email address
  • Picture
This information is stored in the user profile. To view, modify, and remove personal information from the profile page, go to User Profile > View My Profile and Licenses in the menu.

By design, CLM does not process any special categories of personal data (data revealing health, racial or ethnic origin, political opinions, religious or philosophical beliefs, trade union membership, biometrics, sexual orientation, and so on).

Deleting sensitive data

You can remove sensitive data from applications. Scrub these items to recover from data spills and to remove information that is now confidential but wasn't before, or to delete information that should not be revealed to a wider audience. Information is permanently deleted from the application and cannot be recovered.

You might have data from one or more of these applications:

Restricting read access to certain files with sensitive information

There are certain files or directories in Report Builder, Data Collection Component and other CLM applications that contain sensitive information. These files or directories should have their read access restricted to the user or admin that is going to start up the CLM server. The files and directories containing sensitive information are:

Report Builder

  • \server\conf\rs\db directory
  • \server\conf\rs\app.properties

Data Collection Component and other CLM applications

  • \server\conf\dcc\teamserver.properties and all its backup versions
  • \server\conf\dcc\indices\ [index_name], for example \server\conf\dcc\indices\yNb0YZoVEeaftY0i9ahkQg

Non-admin users can view some server configuration parameters

It is possible for a user without administrative privileges to view some server configuration parameters from the web UI. However, a non-admin user cannot modify any of these configuration parameters. If this is a security concern for your organization, complete the following steps to enable the enhanced admin security:

IBM WebSphere Liberty, Apache Tomcat:
  1. Go to the Jazz_Install_Dir/server directory and open server.startup for editing.
  2. Add the following line to the JAVA_OPTS section:

    Linux

    JAVA_OPTS="$JAVA_OPTS -Dnet.jazz.ajax.disableEnhancedAdminSecurity=false"

    Windows

    set JAVA_OPTS=%JAVA_OPTS% -Dnet.jazz.ajax.disableEnhancedAdminSecurity="false"
  3. Save and close the server.startup file.
  4. Restart the server for changes to take effect.
IBM WebSphere Application Server
  1. Log into the WebSphere Application Server Integrated Solutions Console.
  2. Click Server > Server Types > WebSphere application servers > Server1.
  3. Under Server Infrastructure, click Java and Process Management > Process definition.
  4. Under Additional Properties, click Java Virtual Machine > Additional Properties and then click Custom properties.
  5. Click New and add the following custom property:
    • Name: net.jazz.ajax.disableEnhancedAdminSecurity
    • Value: false
  6. Click OK, and then Save directly to the master configuration.
  7. Restart the server for changes to take effect.

Enable host header validation

It is possible for a user to embed malicious JavaScript into the host header of a CLM application. To avoid this problem, you can enable host header validation on the CLM server by completing the following steps:

IBM WebSphere Liberty, Apache Tomcat:
  1. Go to the Jazz_Install_Dir/server directory and open server.startup for editing.
  2. Add the following line to the JAVA_OPTS section:

    Linux

    JAVA_OPTS="$JAVA_OPTS -Dcom.ibm.team.repository.servlet.disableHostHeaderValidation=false"

    Windows

    set JAVA_OPTS=%JAVA_OPTS% -Dcom.ibm.team.repository.servlet.disableHostHeaderValidation="false"
  3. Save and close the server.startup file.
  4. Restart the server for changes to take effect.
IBM WebSphere Application Server
  1. Log into the WebSphere Application Server Integrated Solutions Console.
  2. Click Server > Server Types > WebSphere application servers > Server1.
  3. Under Server Infrastructure, click Java and Process Management > Process definition.
  4. Under Additional Properties, click Java Virtual Machine > Additional Properties and then click Custom properties.
  5. Click New and add the following custom property:
    • Name: com.ibm.team.repository.servlet.disableHostHeaderValidation
    • Value: false
  6. Click OK, and then Save directly to the master configuration.
  7. Restart the server for changes to take effect.

Specifying additional host names for the host header validation

For complex environments you might want to set up a whitelist that includes additional host name aliases. All required host names other than the default ones such as localhost, 127.0.0.1, ::1, the server's actual host name, the server's actual IP address (both IPV4 and IPV6 formats), and the configured public URI must be specified in a whitelist as a system property. Attempting to connect to a server with a host name other than those specified in the whitelist or default host names results in a 400 Bad Request status.

To set up a whitelist , a Java system property can be added to the server.startup file for WebSphere Liberty or Apache Tomcat, or a custom property in WebSphere Application Server with a value of comma separated list of host names.

Before you begin:

Ensure to carry out the procedure in the Enable host header validation section.

IBM WebSphere Liberty, Apache Tomcat:
  1. Go to the Jazz_Install_Dir/server directory and open server.startup for editing.
  2. Add the following line to the JAVA_OPTS section:

    Linux

    JAVA_OPTS="$JAVA_OPTS -Dcom.ibm.team.repository.servlet.extraValidHostNames=hostName1,hostName2,hostName3"

    Windows

    set JAVA_OPTS=%JAVA_OPTS% -Dcom.ibm.team.repository.servlet.extraValidHostNames="hostName1,hostName2,hostName3"
  3. Save and close the server.startup file.
  4. Restart the server for changes to take effect.
IBM WebSphere Application Server
  1. Log into the WebSphere Application Server Integrated Solutions Console.
  2. Click Server > Server Types > WebSphere application servers > Server1.
  3. Under Server Infrastructure, click Java and Process Management > Process definition.
  4. Under Additional Properties, click Java Virtual Machine > Additional Properties and then click Custom properties.
  5. Click New and add the following custom property:
    • Name: com.ibm.team.repository.servlet.extraValidHostNames
    • Value: hostName1,hostName2,hostName3
  6. Click OK, and then Save directly to the master configuration.
  7. Restart the server for changes to take effect.

Non-admin users can view sensitive setup information

It is possible for a user without administrative privileges to view sensitive information that is used during setup by invoking a particular service, for example, in a web browser. If this is a security concern for your organization, after you install and setup your CLM applications, complete the following steps to enforce authentication for setup information.

  1. Log in as a Jazz Administrator to the administrative web UI in a CLM application.
  2. Click Advanced Properties.
  3. Search for com.ibm.team.repository.service.internal.setup.SetupWizardDescriptorService and change the value of the Enforce authentication for setup wizard property from false to true. Save the changes.
Note: You must repeat these steps for each CLM application in your environment that has an administrative web UI with the Advanced Properties page.

Security limitations

  • Default passwords

By default, when creating a user, generated passwords are the same as user IDs. For security reasons, it is recommended to change the default password and use a strong password policy.

  • Unsuccessful log in attempts

The default application server for the Rational solution for CLM products is WebSphere Liberty, which does not lock out users after multiple unsuccessful attempts to log in. Many external LDAP directories offer this functionality. You can set up an external directory to use with WebSphere Liberty.

  • Installing with Security-Enhanced Linux®

If Security-Enhanced Linux (SELinux) is enabled, you must either disable it or change the security context of the Java™™ Runtime Environments (JREs) that are used for installing and running the server to allow text relocation. For more information, see Installing with Security-Enhanced Linux.

Users are not logged out after the LTPA timeout period is reached

When the IBM Lightweight Third Party Authentication (LTPA) timeout value is set in IBM WebSphere Application Server, the Jazz Team Server does not log out users after the timeout period is reached. This is due to the fact that the LTPA timeout setting in WebSphere Application Server and OAuth access token timeout in Jazz Team Server do not have the same value. For more information about setting these two values, see this technote.

Sensitive information in work item links

The work item summary is displayed as a link when work items are shared between private and public project areas. A user from the public project area might not have access to the work item in the private project area by clicking the link, but the summary of the private work item is displayed and viewable by all users. The best practice is not to include any sensitive information in the work item summary.

Information attached to a work item

You can attach information to a work item by dragging the file from another application (for example, Windows Explore or the desktop) to the Attachments section of a work item or by clicking Drag files to add them.
Note: Attachments are available to the entire project area and are not limited to the visibility of team area or work item.

Updating the default user registry for your authentication in Liberty

CAUTION:
Liberty file-based user registry is not supported for production environments. You can use it for demonstration and evaluation purposes only.

You must remove the default ADMIN user access from the Liberty Admin Center, if it is still allowed.

To update the default user registry, complete the following steps:
  1. Access the Liberty Admin Center.
  2. In the server.xml file, complete one of the following steps:
    • To allow all users with the JazzAdmins role to access the console, remove the <user>ADMIN</user> from the <administrator-role> element.
      
 <administrator-role>
        <user>ADMIN</user>   
        <group>JazzAdmins</group>
 </administrator-role>
    • To allow a user outside the JazzAdmins group to access the console, you can change the default ADMIN user ID.
    • If you want to retain the default ADMIN user ID for some reason, you must change its password. For more information, see Configuring a basic user registry for Liberty.
Note: You must update the default user registry for every server that is running an instance of Liberty for which basic user registry approach for authentication is being used.

Setting up allowlists to prevent SSRF attacks

Server-Side Request Forgery (SSRF) vulnerabilities might occur when a web application includes functions to fetch content from an external service or location. The external service might be a public third-party service or an internal private system.

Attackers use this vulnerability to send requests to other public systems, internal systems within the organization, or services available on the local loopback adapter of the application server itself.

A successful attack might cause the application to disclose sensitive information to the attacker or to induce the application to retrieve and process malicious content. When Engineering Lifecycle Management (ELM) is used as an attack proxy, an attacker might attempt the following attack vectors through the SSRF vulnerability:
  • Bypass access controls that prevent accessing internal or external URLs, services, systems, and content.
  • Conduct port scanning of host in internal networks.

To prevent the SSRF issue, ELM must maintain an allowlist of externally requested services and hosts and block any interactions that do not appear on the allowlist.

To set up the allowlist, you must configure the following service areas:
  • The External resources allowlist property on the Advanced Properties page of the Jazz Team Server (JTS).
    Note: This property is available only on JTS and affects OpenSocial gadgets and the RSS Feeds service.
  • The Whitelist (Outbound) page for each registered application.
Complete the following steps to set up the allowlists:
  1. On the Jazz Team Server Administration page, click the Administration icon; then, click Manage Server.
  2. On the Advanced Properties page, configure the External resources allowlist property by adding URLs for Gadgets and Feeds for all apps.
    Note:
    • Enter absolute URLs separated by a comma. Do not add a space after the comma.
    • You can enter an asterisk (*) to allow all URLs
    Advanced Properties
  3. Next, to customize filtering for each app, scroll down and configure the Jazz Authentication Proxy Whitelist property.
  4. To allow access for each registered application, on the Server Administration page, click the Administration icon and then, click Manage Server.
  5. Under Communication, click Whitelist (Outbound).
  6. On the URL Whitelist page, in the Enter Base URL field, enter the absolute URL for the registered app and click Add.
    Note: This setting affects several features in ELM, including the OpenSocial gadgets and RSS Feeds.
Whitelist outbound
Note:
  • Changes require 10 minutes to take effect.
  • URLs to friends and registered apps are allowed on both allowlists. An empty list blocks all external URLs.
  • OpenSocial Gadgets and the RSS Feed service allow connections to any URL that is on either the External resources allowlist or on the Jazz Authentication Proxy Whitelist.
  • To restore the old behavior in the versions prior to 7.0.1 iFix009 and 7.0.2 iFix004, enter an asterisk (*) in the External resources allowlist property to allow all URLs.

Disabling external content widget

You can use the external content widget for adding materials within your enterprise. Servers can be locked down with licenses and accounts and project areas can be secured with access control. Similarly, you can control who can change dashboards. If none of these approaches work for your environment, the administrator can disable the external content widget by setting the following advanced property.

Complete the following steps to disable the external content widget.

  1. On the dashboard screen of the application, administrator can see the viewlet ID in the widget catalog.
  2. Under the Disabled Widgets advanced property, click Add Widget and add the external content viewlet ID: com.ibm.team.dashboard.viewlets.web.external.
    Note:
    • Disabled Widgets is the advanced property. This property is a comma-separated list of viewlet IDs that exists for each application which is accessible to administrator. The viewlet ID must be listed in the advanced property for the application that owns the viewlet.
    • If a viewlet ID is in the advanced property, it will no longer be listed in the Add Widget interface for all users.
    • If a viewlet ID is in the advanced property, any pre-existing instances of the viewlet in dashboards show the message This widget has been disabled by the administrator.