Security considerations for the IBM Engineering Lifecycle Management applications
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
- Ports, protocols, and services
- Customizing security settings
- Setting up user roles and access
- Privacy policy considerations
- Deleting sensitive data
- Restricting read access to certain files with sensitive information
- Non-admin users can view some server configuration parameters
- Configuring security headers
- Non-admin users can view sensitive setup information
- Security limitations
- Users are not logged out after the LTPA timeout period is reached
- Sensitive information in work item links
- Setting up allowlists to prevent SSRF attacks
- Disabling external content widget
Enabling security during installation
If you are installing Jazz Team Server and other IBM® 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 Setting up security for the Rational solution for CLM on z/OS.
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
Customizing security settings
Setting up user roles and access
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.
- Username
- Email address
- Picture
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:
- Lifecycle Query Engine and the Link Index Provider
- Resolving data spill by removing sensitive data from Lifecycle Query Engine and the Link Index Provider.
- Requirements Management (RM):
- Deleting artifacts from the RM repository
- Change and Configuration Management (CCM):
- Deleting work items in the web client and Deleting work items in the Eclipse client.
- Quality Management (QM)
- Permanently deleting sensitive QM data and Deleting test artifacts.
- Global Configuration Management (GCM)
- Finding sensitive data and data spills in global configurations and components and Deleting sensitive data.
- IBM Engineering Lifecycle Optimization Engineering Insights (ENI)
- Resolving data spill by removing sensitive data from Engineering Insights.
- Rhapsody Model Manager (RMM)
- Removing sensitive data from Rhapsody Model Manager
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:
- Go to the Jazz_Install_Dir/server directory and open server.startup for editing.
- 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"
- Save and close the server.startup file.
- Restart the server for changes to take effect.
Configuring security headers
- Disabling X-Powered-By flag
- Setting up the X-XSS-Protection header
- Disabling the uncommon $WSEP header
- Setting up HTTP Strict Transport Security
- Setting up the X-Content-Type-Options header
- Enabling host header validation
- Specifying additional host names for the host header validation
- Setting up the httpOnly flag for JAS SSO cookies
- Enabling httpOnly to secure attributes for cookies using IBM WebSphere Liberty
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.
- Go to JazzInstallDir/server/liberty/servers/clm and open the server.xml file to edit.
- Copy and paste the below code in the server.xml
file.
<webContainer com.ibm.ws.webcontainer.disablexPoweredBy="true"/>
- Save and close the file.
- Restart the server.
Setting up the X-XSS-Protection header
- Connect through SSH or remote desktop to the VM where the IBM HTTP Server is installed.
- 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. - Edit the httpd.conf file. Note: The location of the httpd.conf file is /<install directory>/HTTPServer/conf/httpd.conf.
- Ensure that the following line is not commented out (no # at the beginning of the line):
LoadModule headers_module modules/mod_headers.so
- Add the following line after the LoadModule section:
Header set X-XSS-Protection "1: mode=block"
- 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
- 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.
- Go to JazzInstallDir/server/liberty/servers/clm and open the server.xml file to edit.
- Copy and paste the below code in the server.xml
file.
<webContainer com.ibm.ws.webcontainer.suppressErrorPageODRHeader="false"/>
- Save and close the file.
- 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.
- 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.
- 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
- To define the HSTS policy for clients, make the following updates in the httpd.conf file:
- 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"
- Add the Header directive to each virtual host section, <virtual host> that is enabled for Secure Sockets Layer (SSL).
- 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).
- 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]
- Add the stanza once to each virtual host section in the httpd.conf file.
- 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).
- Connect through SSH or remote desktop to the VM where the IBM HTTP Server is installed.
- 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. - Edit the httpd.conf file. The file path is: <install directory>/HTTPServer/conf/httpd.conf
- Find the following line and ensure that it is not
commented:
LoadModule headers_module modules/mod_headers.so
- Type the following line after the LoadModule
section:
Header set X-Content-Type-Options nosniff
- Save the changes.
- 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
- 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:
- Go to the Jazz_Install_Dir/server directory and open server.startup for editing.
- Add the following line to the JAVA_OPTS
section:Linux
JAVA_OPTS="$JAVA_OPTS -Dcom.ibm.team.repository.servlet.disableHostHeaderValidation=false"
Windowsset JAVA_OPTS=%JAVA_OPTS% -Dcom.ibm.team.repository.servlet.disableHostHeaderValidation="false"
- Save and close the server.startup file.
- 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.
- Go to the Jazz_Install_Dir/server directory and open server.startup for editing.
- 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"
- Save and close the server.startup file.
- 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.
- Go to the directory where you installed the Jazz Auth Server and run the following script to
stop the server.
stop-jazz
- Go to the wlp/usr/servers/jazzop directory where you installed the Jazz Auth Server and open the server.xml file for editing.
- Locate the <httpSession cookieHttpOnly="false"/> line in the server.xml file and change its value from false to true.
- 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.
- 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 thessoRequiresSSL
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"/>
- Enabling application security in
Liberty:
- 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 awebAppSecurity
element that includes ahttpOnlyCookies
attribute as shown below.- Restricting LTPA session cookies to HTTP only in
Liberty:
<webAppSecurity httpOnlyCookies="true"/>
- Restricting LTPA session cookies to HTTP only in
Liberty:
- 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 thecookieSecure
attribute as shown below.- Enabling HTTP Session cookie SSL in
Liberty:
<httpSession cookieSecure="true"/>
- Enabling HTTP Session cookie SSL in
Liberty:
- 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 acookieHttpOnly
attribute as shown below.- Restricting HTTP Session cookies to HTTP only in
Liberty:
<httpSession cookieHttpOnly="true"/>
- Restricting HTTP Session cookies to HTTP only in
Liberty:
- 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.
- Log in as a Jazz Administrator to the administrative web UI in an Engineering Lifecycle Management application.
- Click Advanced Properties.
- 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.
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.
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.
- 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.
- 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.
- On the Jazz Team Server Administration page, click the Administration icon; then, click Manage Server.
- 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
- Next, to customize filtering for each app, scroll down and configure the Jazz Authentication Proxy Whitelist property.
- To allow access for each registered application, on the Server Administration page, click the Administration icon and then, click Manage Server.
- Under Communication, click Whitelist (Outbound).
- 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](../images/whitelist_outbound.jpg)
- 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.
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.
- On the dashboard screen of the application, administrator can see the viewlet ID in the widget catalog.
- 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.