Security considerations for the IBM Engineering Lifecycle Management applications

Edit online

You must 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 IBM Engineering Lifecycle Management (Engineering Lifecycle Management) applications on z/OS, several tasks are required to make the Engineering Lifecycle Management functions secure and available on z/OS. For more information, see this Jazz.net article.

To be compliant with US government Special Publications SP800-131 standard that is used to accredit cryptographic modules, you must configure your servers, clients, and browsers. For more information, see Support for National Institute of Standards and Technology Special Publication 800-131.

Ports, protocols, and services

You can add a reverse proxy to your server to provide an extra layer of security.
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 IBM WebSphere Liberty

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 to collect personally identifiable information.

The IBM Engineering Lifecycle Management (Engineering Lifecycle Management), collects and processes only basic personal information for each user:
  • Username
  • 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, Engineering Lifecycle Management does not process any special categories of personal data. For example, data that is related to health, racial, ethnic origin, political opinions, religious or philosophical beliefs, trade union membership, biometrics, sexual orientation, or other personal information.

Deleting sensitive data

You can remove sensitive data from applications. Scrub the items to recover from data spills, remove information that is now confidential but wasn't before, or delete information that must 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

Certain files or directories in Report Builder, Data Collection Component, and other Engineering Lifecycle Management applications contain sensitive information. The read access of these files or directories must be restricted to the user or admin that is going to start the Engineering Lifecycle Management server. The files and directories that contain sensitive information are:

Report Builder

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

Data Collection Component and other Engineering Lifecycle Management 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
  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.

Configuring security headers

To add extra security to servers on which the Engineering Lifecycle Management products run, you must complete the following header configurations:

Disabling X-Powered-By flag

The X-Powered-By header provides information about the application frameworks that are run by the site. It is not a security vulnerability but provides information about the server on which your application is running. If you are concerned that the header is a security risk, you can complete the following steps to disable it.

IBM WebSphere Liberty:
  1. Go to JazzInstallDir/server/liberty/servers/clm and open the server.xml file to edit.
  2. Copy and paste the below code in the server.xml file.
    <webContainer com.ibm.ws.webcontainer.disablexPoweredBy="true"/>
  3. Save and close the file.
  4. Restart the server.

Setting up the X-XSS-Protection header

The use of the Content-Security Policy (CSP) is encouraged instead of the X-XSS-Protection header because CSP is the modern standard that is supported by most of the web browsers. X-XSS-Protection is only supported by Internet Explorer 8, Google Chrome, and Safari. However, some web security scanners such as Nikto might notify the absence of this header if the blocking mode is not set. Complete the following steps to enable the header.
Note: The following steps are only applicable for the IHS server.
  1. Connect through SSH or remote desktop to the VM where the IBM HTTP Server is installed.
  2. To stop the server, on the command line, run the following command:
    /<install directory>/HTTPServer/bin/apachectl -k stop -f /<install directory>/HTTPServer/conf/httpd.conf
    Note: Ensure that you are at the root before you enter the commands.
  3. Edit the httpd.conf file.
    Note: The location of the httpd.conf file is /<install directory>/HTTPServer/conf/httpd.conf.
  4. Ensure that the following line is not commented out (no # at the beginning of the line): 
    LoadModule headers_module modules/mod_headers.so
  5. Add the following line after the LoadModule section: 
    Header set X-XSS-Protection "1: mode=block"
  6. Save your changes and then, restart the IBM HTTP Server by using the following command: 
    /<install directory>/HTTPServer/bin/apachectl -k start -f /<install directory>/HTTPServer/conf/httpd.conf
    /<install directory>/HTTPServer/bin/httpd.exe -k restart
  7. After you complete steps 3-6, the X-XSS-Protection header is added to all responses.

Disabling the uncommon $WSEP header

The web container adds an HTTP header named $WSEP for some error conditions, for example, a 403 error code. Adding the header affects WebSphere Liberty server because some web security scanners such as Nikto flag this activity as a security risk. Complete the following steps to avoid including the $WSEP header in the error page responses.

IBM WebSphere Liberty:
  1. Go to JazzInstallDir/server/liberty/servers/clm and open the server.xml file to edit.
  2. Copy and paste the below code in the server.xml file.
    <webContainer com.ibm.ws.webcontainer.suppressErrorPageODRHeader="false"/>
  3. Save and close the file.
  4. Restart the server.

Setting up HTTP Strict Transport Security (HSTS)

You can specify HTTP Strict Transport Security (HSTS) in response headers so that your server notifies the clients that it accepts only HTTPS requests. You can redirect any non-HTTPS requests to SSL-enabled virtual hosts.

Before you begin
  • If SSL/TLS is terminated by a device ahead of the IBM HTTP Server (IHS), and if the IBM HTTP Server is not configured for SSL/TLS, the following procedure does not apply. Instead, you must configure HSTS on the device that terminated SSL/TLS. For more information about HSTS, see RFC 6797 section 7.
  • Determine whether your HSTS policy applies to only the domain or includes subdomains.
  • Determine whether the domain can be part of the preinstalled list of known HSTS hosts in a client.
  • Determine how long the client can cache the information that indicates that the domain is an HSTS host.
    Restriction: The server does not add the HSTS headers to HTTP 304 (not modified) responses. These responses are used to validate cache freshness. A client does not see the HSTS headers until it accesses at least one uncached (or stale) resource on the server.
  • HSTS works only if the client connects to the default ports for HTTP (port 80) and HTTPS (port 443). If you are using nondefault ports in your IBM HTTP Server configuration, you need to use an extra front-end device that does use the default ports. Place the additional front-end device between your IBM HTTP Server and the client. For example, Client -> load balancer (ports 80 and 443) -> IHS (other ports )
  • Additional information can be found in the httpd.conf file on the IHS server.
    Note: You can find the httpd.conf file at /<install directory>/HTTPServer/conf/httpd.conf.
Procedure
  1. To enable the modification of response headers, uncomment the following Load Module directive for the mod_headers module in the httpd.conf file:
    LoadModule headers_module modules/mod_headers.so
  2. To define the HSTS policy for clients, make the following updates in the httpd.conf file:
    1. Code the Header directive. The following example header specifies useful options for defining your HSTS policy. The directive specifies that the server always requires HTTPS connections. The HTTPS connections apply to both the domain and any subdomain. A client can keep the domain in its preinstalled list of HSTS domains for a maximum of one year (31536000 seconds).
      Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
    2. Add the Header directive to each virtual host section, <virtual host> that is enabled for Secure Sockets Layer (SSL).
  3. Redirect requests from virtual hosts that are not enabled for SSL to virtual hosts that are enabled.
    RewriteEngine on 
RewriteRule ^/(.*) https://%{HTTP_HOST}/$1 [R,L]
    1. Add the stanza once to each virtual host section in the httpd.conf file.
    2. Add the stanza once to the global httpd.conf file, but outside the virtual host sections.

Setting up the X-Content-Type-Options header

Every resource that is served from a web server is associated with MIME type (also called content-type).

Stealing content from another site is possible if the MIME type that is advertised in the Content-Type header does not match the requested type. You might prevent this vulnerability in Internet Explorer or Google Chrome by adding nosniff in the header.
  1. Connect through SSH or remote desktop to the VM where the IBM HTTP Server is installed.
  2. Run the following command to stop the server:
    <install directory>/HTTPServer/bin/apachectl -k stop -f /<install directory>/HTTPServer/conf/httpd.conf
    Note: Ensure that you are at the root directory before you type the command.
  3. Edit the httpd.conf file. The file path is: <install directory>/HTTPServer/conf/httpd.conf
  4. Find the following line and ensure that it is not commented:
    LoadModule headers_module modules/mod_headers.so
  5. Type the following line after the LoadModule section:
    Header set X-Content-Type-Options nosniff
  6. Save the changes.
  7. Restart the IBM HTTP Server by using the following command: 
    <install directory>/HTTPServer/bin/apachectl -k start -f /<install directory>/HTTPServer/conf/httpd.conf
    <install directory>/HTTPServer/bin/httpd.exe -k restart
  8. The X-Content-Type-Options header is added to all responses after you apply the changes.

Enabling host header validation

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

IBM WebSphere Liberty:
  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.

Specifying more host names for the host header validation

For complex environments you might want to set up an allowlist that includes more 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 an allowlist 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 IBM WebSphere Liberty.

Before you begin:

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

IBM WebSphere Liberty:
  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.

Setting up the httpOnly flag for JAS SSO cookies

To help prevent cross-site scripting attacks, you must set the httpOnly flag for the JAS SSO cookies.

Complete the following steps to set the httpOnly flag for the JAS SSO cookies:
  1. Go to the directory where you installed the Jazz Auth Server and run the following script to stop the server.
    stop-jazz
  2. Go to the wlp/usr/servers/jazzop directory where you installed the Jazz Auth Server and open the server.xml file for editing.
  3. Locate the <httpSession cookieHttpOnly="false"/> line in the server.xml file and change its value from false to true.
  4. Go to the directory where you installed the Jazz Auth Server and run the following script to start the server. 
    start-jazz

Enabling httpOnly to secure attributes for cookies using IBM WebSphere Liberty

To help prevent cross-site scripting attacks, you must enable httpOnly to secure attributes for cookies.

  1. To limit the LTPA cookies to SSL only in the IBM WebSphere Liberty, add a webAppSecurity element in the server’s server.xml file that includes the ssoRequiresSSL attribute as shown below. You can find the server.xml file at JazzInstallDir/server/liberty/servers/clm.
    • Enabling application security in Liberty:
      <webAppSecurity ssoRequiresSSL="true"/>
  2. By default, the LtpaToken2 (SSO) and the WASReqURL cookies are set to HTTP only in the IBM WebSphere Liberty. To manually specify this in the server’s server.xml, add a webAppSecurity element that includes a httpOnlyCookies attribute as shown below.
    • Restricting LTPA session cookies to HTTP only in Liberty:
      <webAppSecurity httpOnlyCookies="true"/>
  3. To limit the HTTP Session cookie SSL in the IBM WebSphere Liberty, add a httpSession element in the server’s server.xml file that includes the cookieSecure attribute as shown below.
    • Enabling HTTP Session cookie SSL in Liberty:
      <httpSession cookieSecure="true"/>
  4. By default, the HTTP session is set to HTTP only in the IBM WebSphere Liberty. To manually set this in the server’s server.xml file, include a httpSession element that includes a cookieHttpOnly attribute as shown below.
    • Restricting HTTP Session cookies to HTTP only in Liberty:
      <httpSession cookieHttpOnly="true"/>
  5. Restart the server.
    • Go to Jazz_Install_Dir/server directory and run ./server.shutdown to stop the server.
    • Go to Jazz_Install_Dir/server directory and run ./server.startup to start the server.

Non-admin users can view sensitive setup information

By default, authentication is not required since the service is operational before the applications are setup. Hence, it is possible for a user to view sensitive information that is used during setup without logging in. To enable authentication, you can set the Enforce authentication for setup wizard parameter value to true.

If this is a security concern for your organization, after you install and setup your Engineering Lifecycle Management applications, complete the following steps to enforce authentication for setup information.

  1. Log in as a Jazz Administrator to the administrative web UI in an Engineering Lifecycle Management 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 Engineering Lifecycle Management application in your environment that has an administrative web UI with the Advanced Properties page.

Security limitations

  • Default passwords

By default, when you create a user, generated passwords are the same as user IDs. For security reasons, you must change the default password and use a strong password policy.

  • Unsuccessful log in attempts

The default application server for the Engineering Lifecycle Management products is IBM WebSphere Liberty, which does not lock out users after multiple unsuccessful attempts to log in. Many external LDAP directories offer this function. You can set up an external directory to use with IBM 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 WebSphere® Application Server, Jazz Team Server does not log out users after the timeout period is reached. This is because the LTPA timeout setting in WebSphere Application Server and OAuth access token time out 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. However, 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. Alternatively, you can click Drag files to add them.

You can use work item access control context for attachments that are uploaded to the work item using the property Use work item access control context for attachments. In this property, the access context of the attachment is same as the access context of the work item. A user with read access to a work item can access attachments that are associated with that work item. Users without access to the work item do not have access to the attachment. A direct URL link to an attachment is denied access if the user does not have the read access to the work item that the attachment is attached to.

The Use work item access control context for attachments property is enabled by default. The new security model applies only to the new attachments created after enabling this property. It does not change the access context of existing attachments. For more information, see Configuring advanced properties.

Note: Existing attachments that were created before 7.0.0 are available to the entire project area and are not limited to the visibility of team area or work item.

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 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, Engineering Lifecycle Management 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 Engineering Lifecycle Management, 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 before 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 is no longer 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.