If you’ve spent any time administering or configuring an IBM Cognos installation, then you have likely encountered and possibly pondered the feature known as the Cognos Application Firewall (CAF). The name itself seems to attract attention, and we are often asked for additional information about this feature by administrators and information security professionals who work closely with the IBM Cognos platform at their organizations.

What is the CAF?

According to the IBM Cognos 8.4 Administration and Security Guide

“IBM Cognos Application Firewall (CAF) is a security tool used to supplement the existing IBM Cognos 8 security infrastructure at the application level. CAF analyzes, modifies, and validates HTTP and XML requests before the gateways or dispatchers process them, and before they are sent to the requesting client or service. It acts as a smart proxy for the IBM Cognos product gateways and dispatchers, and prevents the IBM Cognos 8 components from malicious data. The most common forms of malicious data are buffer overflows and cross-site scripting (XSS) attacks, either through script injection in valid pages or redirection to other Web sites.”

In short, the CAF is an extra layer of application security that protects your IBM Cognos environment from complex or well-crafted malicious attacks that could in many ways compromise the security and/or privacy of both your information and your end users. You should always enable the CAF in your IBM Cognos environment unless you have a specific, documented reason for doing otherwise. In fact, some IBM Cognos applications such as Go! Dashboard, specifically require that the CAF is enabled to function properly.

How does it work?

Request Validation

The Cognos Application Firewall examines all URLs that originate or terminate within your installation of IBM Cognos 8. If a URL contains a host name that does not match those that were configured on the Environment page of your Cognos Configuration application, then it will be rejected by default. This is to prevent a scenario where a user may be unknowingly directed to a malicious site, or even a site that is masquerading as IBM Cognos where their login or personal information may be captured and later used to compromise the system.

Error Message Obfuscation

The CAF will prevent any non-administrative user from ever seeing the actual details of any error message generated by the system. Instead, the dispatcher will supply a numeric SecureError ID which can then be referenced by an administrator within the server log file in order to extract the true details of this error message. This prevents users from obtaining potentially damaging information from detailed error messages, which often contain application and database server names, as well as application or query information that could be used by a savvy hacker to develop a targeted attack that could compromise either IBM Cognos or potentially any of the systems with which it interfaces.

Parameter Signing

The CAF also provides parameter signing, where a unique key or signature is generated and appended to report parameters by the application when a URL is constructed. Those signatures are then checked by the dispatcher when it receives the request to ensure that it originated from a trusted source and were not tampered with between the client and the application.

How does it impact me?

The CAF presents itself to users and administrators in a number of ways during day to day operations. It’s important to properly configure the CAF in a way that enhances system security but does not inhibit productivity, and as always, a large part of this equation is proper user education.

Accessing External Websites

The request validation component of the CAF will prevent unknown hostnames or domains from being accessed from within IBM Cognos 8. This most readily impacts the URL Object, as well as the RSS feed portlet that is available on both Portal Pages and Go! Dashboards from within Cognos Connection. This means that if you wanted to create a hyperlink to https://www.ironsidegroup.com or add an RSS feed portlet to https://www.ironsidegroup.com/feeds from within a portal page or Go! Dashboard, you would be presented with an error similar to this one:

This is because the URL https://www.ironsidegroup.com contains a hostname that was not part of the Environmental Configuration, and thus the CAF does not see it as a trusted endpoint. Fortunately we can add additional hosts and domains to the Valid Hosts and Domains list under the CAF settings in Cognos Configuration. Once added, we can then create hyperlinks or load RSS feeds to and from these sources. In our example we could add .ironsidegroup.com as a valid wildcard domain, which would then allow us to reference both feeds.ironsidegroup.com and www.ironsidegroup.com without explicitly defining them in the list.

It should be noted that beginning in Cognos 8.4.1 the wildcard domain format has changed and in this example our entry would take the form of *.ironsidegroup.com (appending the leading asterisk).

Retrieval of Error Messages

Sometimes during report development, it may be useful for Authors or Power Users to retrieve full detailed error messages so that they may attempt to resolve their own issues without having to involve administrative resources or having access to the log files on the application server. Fortunately this feature has been implemented as a capability which can be granted to any user, group or role. By default the ability to view detailed error messages has been granted to administrators only, but you may want to consider giving this privilege to your Report Authors as well. Once this capability has been granted to any user, detailed error messages will appear in the application as normal, without the need to cross reference SecureError IDs to the log file.

Cognos SDK Applications

If you have any applications developed with the IBM Cognos 8 SDK which use your system’s gateway URI (e.g. http://hostname.domain.com:80/cognos8/cgi-bin/cognos.cgi) as their connection endpoint, as opposed to connecting directly to a dispatcher (e.g. http://dispatcher.domain.com:9300/p2pd/servlet/dispatch), you should know that enabling the CAF will filter out these requests. If you would like your SDK applications to function normally, while also enabling the CAF, you must either A) change your SDK application’s endpoint to be a dispatcher URI or B) Configure an alternate gateway that circumvents the CAF for the servicing of SDK requests.

When selecting option A, it is recommended that you take additional steps to ensure requests targeted directly at a dispatcher are from a trusted and valid source. You should also be aware that if you operate a distributed IBM Cognos environment, and your SDK endpoint dispatcher becomes unavailable, your applications will not be able to connect to IBM Cognos.

Option B is achieved by installing a separate gateway instance that is dedicated to SDK requests, and its Dispatcher URIs for Gateway entries have been altered to remove the trailing ‘/ext’ from the URI. Option B also requires that you apply additional security to ensure that only requests from trusted sources are allowed to use that gateway, but it has the added benefit of providing fault tolerance for SDK calls by way of being able to configure multiple Dispatcher URIs for Gateway entries in a distributed environment.

How can I further tune and configure the CAF?

Beyond the well documented configuration options that are available to you in IBM Cognos Configuration, there are a few additional settings that can be adjusted as needed. Those settings can be found in the file <IBM Cognos Install Root>/configuration/cafconfig.xml.sample To alter or implement any of the settings in this file, simply edit and save the file as <IBM Cognos Install Root>/configuration/cafconfig.xml and restart your IBM Cognos Services.