Security scan checklist

Make sure to apply the latest IBM TRIRIGA Application Platform Fix Pack for your Version and Release (following the IBM® numbering standard of V.R.F). If necessary, search Fix Central for the latest available Fix Pack, and apply that Fix Pack before continuing. For example, if Fix Pack 4.0.1 is the latest available Fix Pack for Version 4.0, then apply that Fix Pack before continuing.

For IBM TRIRIGA Application Platform 3.4.2 and older, plan a platform upgrade to the latest release as soon as possible.

If you must remain on IBM TRIRIGA Application Platform 3.4.2, then Production mode must be enabled (set to Y) so that ProductionMode=Y in TRIRIGAWEB.properties. This setting will prevent stack traces from being shown to the end user.

A web server with Secure Sockets Layer (SSL) should be configured, and HTTP Secure (https) must be used with IBM HTTP Server (IHS), Apache HTTP Server, or Microsoft Internet Information Services (IIS). Some scanning software will flag http (not secure) as a vulnerability.

The SSL layer should also be configured with strong encryption. Some scanning software will flag 128-bit encryption as a vulnerability. This encryption is a function of the web server layer, not central to the IBM TRIRIGA product.

A web server with Single Sign-On (SSO) should be configured in front of IBM TRIRIGA, so that company-wide password policies can be followed. Make sure that the SSO solution strips the headers (from the browser) that are used in the SSO process.

For example, with Apache HTTP Server, research the module mod_headers, and specifically, unset header.

The default application server ports should be protected by a firewall. Make sure to disable direct access to the IBM TRIRIGA-related application server that is running Single Sign-On (SSO).

No scans should be performed directly on the application server ports, since those ports are restricted to Administrators and/or the web server only.

Make sure to disable any web-based administration consoles (or admin consoles) on the web server and application server.

Make sure that the scan results are verifiable, reproducible, and make sense.

For example, if the scan results show an Apache Struts vulnerability, consider that IBM TRIRIGA does not use Struts. So, all of the results should be suspect, because the scan flagged a package that was not used. Similarly, if the scan results show a Cross-Site Scripting (XSS) vulnerability, replicate the vulnerability by hand. If you cannot replicate the result by hand, then it is likely a false positive.

Encrypt any plain-text passwords. You should encrypt your database password in the server.xml file. To set the value of the password to an encrypted value, see the WebSphere Application Server Liberty usage of securityUtility.

Set the IBM TRIRIGA account lockout options. Depending on your company requirements, you can update TRIRIGAWEB.properties to set UNSUCCESSFUL_LOGIN_ATTEMPT=X where X is the number of incorrect login attempts that are allowed before the account is disabled.

Some scanning software will flag any missing security-based HTTP response headers as a vulnerability. But these headers are somewhat arbitrary and the requirements change from scanning software to scanning software.

• Breaking functionality: Some headers will break some functionality in IBM TRIRIGA. For example, adding a "Content-Security-Policy" or "nosniff" header will break various scripts and cause issues with the dynamic nature of IBM TRIRIGA. To open an IBM Support case, IBM TRIRIGA must be proven to be exploitable via these attacks. An IBM Support case will be closed if the header is given without supporting evidence that IBM TRIRIGA is vulnerable to such attacks. Most of these headers are best practices, but are not official headers that are required by the HTTP standard.
• Adding properties: The IBM TRIRIGA Application Platform provides a way to add HTTP headers by adding properties to TRIRIGAWEB.properties. If your scan states that the HTTP headers X-My-Secure-Header and X-Frame-Options are not set, then they should contain the values "Allow-only-my-value" and "SAMEORIGIN", respectively. You can set these values by adding the following lines to TRIRIGAWEB.properties:

  httpheader.X-My-Secure-Header=Allow-only-my-value
  httpheader.X-Frame-Options=SAMEORIGIN

Some scanning software will flag any missing JSESSIONID cookie flags as a vulnerability. But IBM TRIRIGA tested and supports two flags as follows.

• Secure flag: When running your application server in a Secure Sockets Layer (SSL) environment, you must set up the JSESSIONID cookie with the Secure flag. The Secure flag can be added if you are using https (http secure) only. This setup is an application-server-dependent activity, so the IBM TRIRIGA installer will not configure this. To set this flag, see your WebSphere Application Server Liberty documentation.
• HttpOnly flag: When running WebSphere Application Server Liberty, the httpOnly flag is set by default.

Methodologies for vulnerability scanning include static source scans and dynamic web scans as follows.

• Static source scans: These scans analyze the binary code for potential coding issues that may result in an exploit. However, these scanning tools analyze the code statically, often without understanding the full context of the application stack and the variables involved. With the IBM TRIRIGA Application Platform, a large and very dynamic web-application platform, it's difficult to get reliable results from a static code scan. You may find false positives such as SQL injection, cross-site scripting, insufficient input validation, cross-site forgery, and other issues that are flagged because the code scanning tool does not have a holistic understanding of the application stack. For this reason, we do not recommend that you rely on static source scans.
  • Scanning third-party libraries: When dealing with vulnerabilities that arise because of a third-party library, it is necessary to prove that IBM TRIRIGA has a specific exploit by way of the methods that are explicitly used by such a third-party library.
  • Scanning file uploads for viruses: IBM TRIRIGA supports Internet Content Adaptation Protocol (ICAP) virus scanning, and relies upon third-party antivirus server frameworks to scan uploads for malicious content. Malicious text file contents, such as European Institute for Computer Antivirus Research (EICAR) test files, will not be detected automatically by IBM TRIRIGA without having it configured to work with the ICAP service. To point to third-party antivirus software to scan uploads, make sure to set the properties VIRUS_SCAN_ENABLED, VIRUS_SCANNER_IP_ADDRESS, and VIRUS_SCANNER_IP_PORT in TRIRIGAWEB.properties. For more information about enabling virus scanning, see Enabling virus scan for files that are uploaded to IBM TRIRIGA.
• Dynamic web scans: Recommended. These scans analyze the actual application that is running in the context of a web container.
  • Passive scans: Most of these dynamic scans are passive scans, which take a URL starting point and then "spider" (like following a "spider web") through the application to try to manipulate and exploit various endpoints.
  • Active scans: There are also active scanning tools, which run scans while using the application. An active scan is useful for true penetration testing to prove an exploit from a passive scan, because a passive application scan can also result in false positives, even if it is also much more honed than a static source scan.

For more information about known vulnerabilities or vulnerability management, see IBM Product Security Central or IBM Security Vulnerability Management.

If all of these prerequisites are followed and a vulnerability still appears in the scan, Support tickets can be opened with the IBM Support team. If you are entitled to IBM Support, follow the same process that you would normally use for any Support ticket.

For more information about known vulnerabilities or vulnerability management, see IBM Product Security Central or IBM Security Vulnerability Management.