Secure Your BI Platform Part 2 – Web Tier

In my previous blog, I covered securing of the communication of your authentication providers.

In this posting, we will cover the configuration of the web tier.   It is your war file deployment, and probably the most exposed part of your deployment, especially if you’re facing the public web.

Reduce the attack surface.

The less you have deployed, the less that can be attacked.   Although the default BI install will deploy a number of components, you likely don’t need them all.

You may see a list like this of war files deployed:

AdminTools – designed for running advanced direct queries against the BI repository.   If you don’t use this, remove it.   You could also consider running it on a separate, local access only deployment.

BOE – This is the core of the BI deployment, includes CMC, BI Launchapd and OpenDocument functionality.  Note that using wdeploy, you can split the CMC and BI Launchpad deployment, and put the CMC functionality on another, more locked down application server.

dswsbobje – web service used by Crystal Reports for Enterprise, Dashboard designer, and your custom applications.  Again something you can remove if none of the above apply to you.

BusinessProcessBI – this is an SDK which is not needed for core functionality.  If you’re not deploying custom applications that make use of this, this is something you can remove from your deployment.

clientAPI – contains Crystal Reports ActiveX controls for custom application deployment.  You can almost certainly remove this.

MobiServer & MobileBIService – if you are not deploying mobile, you should have no need for these.

docs – This is the default tomcat documentation.  They are also available online, so there should not be any need for these to be deployed.  They contain information about the version of tomcat which is not necessary.

Tomcat Security

Refer to your tomcat guide.  The following is an excerpt from the tomcat guide on default web applications:

Tomcat ships with a number of web applications that are enabled by default. Vulnerabilities have been discovered in these applications in the past. Applications that are not required should be removed so the system will not be at risk if another vulnerability is discovered.

http://tomcat.apache.org/tomcat-7.0-doc/security-howto.html#Default_web_applications

Apache regularly publishes its list of fixed vulnerabilities here:

http://tomcat.apache.org/security-7.html

BI SP’s regularly bundle updates of Tomcat.  SAP continually monitors the bundled applications and works to deliver any updates as part of the regular maintenance cycle.  We regularly monitor the security listings of tomcat, and use that to drive our updates.

If you are unable to stay on the latest support packages, you may want to consider reviewing the list of vulnerabilities and using your own update of Tomcat at least until such time when you can deploy the latest BI4.x support pack.

Tomcat User Account

The user account only needs to read files under tomcat.  Create a user for the tomcat service account, give the service account “Logon as a User” rights, and read only rights on the tomcat folder.

Hide CMS Information

The single biggest benefit is usability, because users will not accidentally lose the information or put in a typo and try to connect to the wrong place.

There is no reason why someone should try to communicate anywhere other than the CMS. so set the CMS.visbile=false setting in the BIlaunchpad.properties file and the CmcApp.properties files.

Do this instead: