8/24/2017 Security Considerations in IBM Cognos | Rod Avissar | Pulse | LinkedIn

Back to LinkedIn.com

Security Considerations in IBM Cognos

Published on August 23, 2017

Rod Avissar Following

6 1 1
Mgr, Consulting Services at Hitachi Consulting

Following my latest article about how to keep up-to-date with recent guidelines for
passwords, and in light of cyber-attacks of different varieties becoming increasingly
prevalent, I thought it would be a good idea to write down some specific hard-learnt
lessons on security when administrating an IBM Cognos environment. Unlike some
other tools, in which report authors are given very little flexibility outside of getting
their query right, IBM Cognos offers report authors a plethora of tools which allow
them to never say a requirement cannot be met. But for the Cognos superhero, with
great flexibility comes great responsibility. Therefore, it is up to authors, modellers,
DBAs, ETL developers and administrators to be wary of security breaches.

These tips do not make an exhaustive list, in that if you follow them, it does not mean
your system is secure. I always recommend having a system-wide security test carried
out periodically by cyber experts, to expose any weaknesses and highlight risks. The
best way to identify where a hacker might effectively strike to gain access to your
systems is to pay one to try. I can help with planning such tests or dealing with the risks
that they eventually highlight – feel free to contact me for details.

https://www.linkedin.com/pulse/security-considerations-ibm-cognos-rod-avissar 1/7
8/24/2017 Security Considerations in IBM Cognos | Rod Avissar | Pulse | LinkedIn

Tip 1: Beware of Token Prompts

My first tip is around token prompts. These are very useful creatures and can really
boost performance, especially when working over a dimensional source. However, they
also allow a user to put anything as input, and that input is then is passed through
unchecked. This allows SQL injections and other attacks to be performed. The solution
is to try to avoid these where possible, and where it isn’t possible/feasible, to make sure
you defined a finite list of values the token prompt will tolerate. My good friend Paul
Mendelson wrote up one such example.

Tip 2: Keep CAF On

My second tip is about CAF and XSS filter. CAF – the Cognos Application Firewall – is
the best line of defence against URL redirection and other attacks. CAF validates
requests, meaning it looks through every URL and compares it against a whitelist of
hosts. This means Cognos will block out attempts at redirecting URLs etc. This bit also
hands cross-site scripting (XSS) validation, if enabled. XSS filter will block attempts to
inject malicious code in the URL. CAF also checks to see that the parameters of a query
sent to the dispatcher are the same as the parameters of the query when it was submitted
in the report. In other words, it blocks attempts to hijack the query and change the
parameters. Finally, CAF takes away the details of error messages for non-admin users.
These details may contain information (e.g. database server names) that could help a
hacker in their attempts.

For reasons unfathomable to me, I see many admins who turn this off. Common reasons
I heard are that it filters out legitimate URLs and that it alters parameterised URLs

https://www.linkedin.com/pulse/security-considerations-ibm-cognos-rod-avissar 2/7
8/24/2017 Security Considerations in IBM Cognos | Rod Avissar | Pulse | LinkedIn

(Both mean it wasn’t configured properly). Others are unaware of what it does; others
rely on alternative means such as a hardened server or Internet Explorer XSS filter; etc.

CAF is your best defence against exploits. Since your BI system has easy access to all
organisational data, it makes sense to secure it independently of any other security
measures the organisation normally operates. There’s no harm in adding security. For
example, if a policy – such as obligating users to turn XSS filter on in Internet Explorer
– changes, it will not necessarily be discussed or communicated to the Cognos
administrator. CAF is a resource the Cognos administrator can control.

Tip 3: Secure Data on the Back End.

My third tip is about resisting the temptation to secure on a front-end tier. This happens
a lot when authors or model developers cannot control permissions in the underlying
data source or when single sign on is not turned on for the data source. In such cases,
authors and modellers tend to secure data either using security filters in Framework
Manager, or using detail filters in the report layer.

It is always advisable to secure your data in the database. That way, even if someone
manages to gain access to your data warehouse, they will still have permissions to deal
with. I don’t know of any scenario where securing data at source isn’t the recommended
course of action. If you cannot secure your data in the database, remember you risking
your data security by implementing security in any other layer. You’re also creating
more work for yourself if any other front-end tool, such as Excel, a dashboarding
software etc., is going to be used for data access. I would recommend reconsidering –
perhaps there is a way to secure data in the database? As an example, if it is lack of out-

https://www.linkedin.com/pulse/security-considerations-ibm-cognos-rod-avissar 3/7
8/24/2017 Security Considerations in IBM Cognos | Rod Avissar | Pulse | LinkedIn

of-box single sign on capacity, I gave an example of using Oracle VPD functionality to
simulate single sign on between Cognos and Oracle in a previous example. Such
creative solutions may exist to circumvent the reason you cannot implement security in
the back end.

If you have made the informed decision to increase risks and secure data elsewhere,
always opt for the Framework Manager option. If data security is done at the report
level, apart from adding incredible complexity to reports and making maintenance a real
problem, it is also very weak. The filters appear in the URL, and a savvy user can
change them. Additionally, you will not be securing any self-service studios such as
Query Studio.

When security is done in Framework Manager, at least you can almost always be sure
that queries generated by Cognos are secured. Almost, because with pass-through SQL
queries Cognos might first retrieve the entire result set, and only then filter, in some
cases.

Tip 4: Build A Simple Permissions Tree Based on Groups

When building the permission tree inside Cognos, and when assigning capabilities, use
a simple tree and in as much as possible group users. This would require investing time
in planning, but will mean users’ permissions and capabilities are very easy to maintain.
Do not use the deny option as it causes some strange clashes. If you define that
whatever is not specifically allowed is forbidden, you set the right tone and you don’t
need to use the Deny option ever.

https://www.linkedin.com/pulse/security-considerations-ibm-cognos-rod-avissar 4/7
8/24/2017 Security Considerations in IBM Cognos | Rod Avissar | Pulse | LinkedIn

Tip 5: Keep It Up To Date

This is the most obvious but also, unless you can take your Cognos implementation to
the cloud, one of the most difficult to implement – always keep up to date with software
versions. Security patches are a part of every new version release. Hackers keep up to
date, and so should the people defending themselves from them. This is hard to do
because a Cognos server upgrade can be a trying task – and there’s report validations,
testing etc. Some businesses find it very hard to upgrade because the reports simply
cannot undergo even the slightest change, for example when they are sent to regulators
(e.g. pharmacovigilance). Strategically, it’s worth considering having a Cognos update
cycle as part of the day-to-day maintenance, where tests towards upgrades are worked
into the annual plan and new versions – now being released more rapidly than ever – are
tested and rolled out as a part of the BI department’s everyday work. Some of the
processes can be automated, and the regular nature of the task will highlight what are
the key things you need to look into for an upgrade to be approved.

Conclusion

Do you have any favourite Cognos security tips? Share them below. In addition, do take
some time today to ensure your Cognos environment is secure.

Report this

Rod Avissar
https://www.linkedin.com/pulse/security-considerations-ibm-cognos-rod-avissar 5/7
8/24/2017 Security Considerations in IBM Cognos | Rod Avissar | Pulse | LinkedIn
Rod Avissar
Mgr, Consulting Services at Hitachi Consulting
Following
20 articles

1 comment Newest

Leave your thoughts here…

Pedro Martins 19h

What's Your Data Strategy?
Hi Rob thank you for the excellent tips. Well done.
Like Reply

Don't miss more articles by Rod Avissar

How to lie with data – part 2 On Cognos Reports Performance Rethinking Reports UX – What Can BI
Rod Avissar on LinkedIn Improvement Developers Learn From Google?
Rod Avissar on LinkedIn Rod Avissar on LinkedIn

Looking for more of the latest headlines on LinkedIn?

https://www.linkedin.com/pulse/security-considerations-ibm-cognos-rod-avissar 6/7
8/24/2017 Security Considerations in IBM Cognos | Rod Avissar | Pulse | LinkedIn

Discover more stories

Help Center About Careers Advertising Talent Solutions Sales Solutions Small Business Mobile Language Upgrade Your Account
LinkedIn Corporation © 2017 User Agreement Privacy Policy Ad Choices Community Guidelines Cookie Policy Copyright Policy Send Feedback

https://www.linkedin.com/pulse/security-considerations-ibm-cognos-rod-avissar 7/7