Information Security, Risk Management and Back End – Guest Post

Paul is my good friend, a Cognos guru and a colleague for a while now, and I’m reading his blog regularly. When I read his latest post, regarding information security in Cognos reports, I felt that, untypically, some points in the post need refinement. So I asked Paul if he would kindly agree to host my claims, and he generously accepted. So, without further ado, here are my thoughts on Paul’s post.

First of all, it should be noted Paul is absolutely correct on two points: Data security should never ever be applied in report level, and data security should always be applied in the back end. However, I’m not sure that the possible leak via token prompts constitutes a viable security threat that requires extreme measures, and I am quite certain that Cognos’ Meta Data modeling tool, Framework Manager, is not really the back end of the system. Here’s why.

Information Security as Risk Management

We hold these truths to be self-evident, that all systems are vulnerable security-wise. A server is seldom hardened enough, communication is seldom encrypted enough, and passwords are rarely well kept enough to prevent a malicious hacker with intranet access from stealing data, changing data or plainly viewing data they’re not supposed to. Imagine any IT system you know, and imagine a user at least as savvy as you are, and entirely malicious and very keen to do one thing only: To view data they’re not supposed to. If that is the mental picture you  have when securing your system, you will need to double your investment in information security just to start tackling it.

But we cannot ignore two facts: One, users are seldom malicious and not very often are they savvy; and two, not all data is worth the investment of protecting. Let’s start with the first point: Users aren’t very often savvy. Users – analysts, professionals, economists and so on – are usually professional people who were hired to perform tasks they’ve specialized in. Most of them – sans IT people – did not spend their adult years learning computer systems, data structures, communication protocols and password policies. Some of them may be proficient, but very little of them will be hackers, or at the very least good hackers. Those who are, if they exist, will also know they would be the first suspects in any leak. Which brings me to the second part of this point: Users and systems do not exist in vacuum. They exist within an organization. The organization deals with many of the threats internally: There’s the risk of getting shamefully, never-to-be-hired-by-anyone fired, the risk of being sued – in short, the risk of getting caught. A system that is openly monitored can, just by the act of monitoring, seriously deter people from trying to sneak a pick at their colleagues’ salaries in the HR system. On top of that, most people come to work in order to do an honest job and get an honest pay. The majority of the people won’t attempt to hack a system or to access restricted data not just because they don’t know how to, but also because they have no reason to, because the bottom line is that most people are not evil.

The second point was that while we obscure and hide data from unauthorized users, not all data should be protected the same. A company’s customers’ credit card numbers should be protected for dear life. Their marital status, not as much. The extreme example is if we’re going to spend 10 working hours patching up a potential leak , the damage of which will be cheaper than 10 working hours.

So, when determining how to allocate our information security resources, we consider the feasibility of the loophole being found and utilized, and the sensitivity of the data, against the different costs (In terms of user friendliness, performance, labour hours and so on) of patching up the potential threat. In other words, we assess the risk and decide whether it’s worth addressing, and to what level.

If to return to Paul’s original post, while he had found a very elegant security hole with token prompts, I think in most cases it would be the kind of breach we wouldn’t invest, normally, in blocking. Even after reading and understanding Paul’s post, most users will not know how to identify that a report has a token prompt or how to make use of it. And even if they did, most users are not fluent in the database structure and SQL possibilities. If they were, we’d be out of a job. This isn’t security by obscurity because we do not assume data is secure, only that hacking it is unfeasible. On the other hand, the solution Paul offered – to use a parameter map – is costly on several levels: First, it requires republishing a package for every new token prompt, which is cumbersome and may have an effect on other reports, especially if the model is constantly developed. Also, it prolongs development times. It should also be noted that large parameter maps force Cognos to laboured local processing, thus affecting performance. On the other hand, we are talking about users who are trusted to view a certain report based on a certain package, and who are not very likely to find that breach and make use of it. So, in my opinion, unless the kind of data that can be potentially exposed is extremely sensitive, to an extent that no threat, no matter how unfeasible, can be tolerated, it isn’t worth the investment.

Framework As Middle Tier

But suppose that the data I’m protecting is the kind of data that simply cannot be risked, at any cost. This could be the case, for example, if I’m required to keep certain data safe guarded by law, under heavy penalties, or if a leak will cause publicity damages, or in the case of industrial secrets and so on. I would still argue against Paul’s solution, because Paul was right to assert security is a matter for back end, and Framework Manager is not back end.

Cognos web portal and viewer are certainly the front end. They handle data visualization, navigation and object level security (Which user should be allowed to see which reports). As mentioned earlier, they should never handle data level security. The back end is the database itself, where data is stored for safekeeping. Framework Manager is a middle tier between the front end and the back end, handling the query logic. It could be thought of as a logic engine. Data-level security isn’t normally a part of the logic, as opposed to object level security (Which fields/query subjects will be available to who), because the logic is applied on the available data. Having the same tier that manipulates the given data also decide which data to manipulate is opening the door to a host of problems. Why? Because we’re making security a part of the logic rather than an infrastructural thing, and that means we’re tying security and logic together. Any changes to each might invalidate the other. Translate tables via a parameter map for security reasons, and you’re adding relationships which might affect existing ones. Change the relationship of a few query subjects, or add fields, and you may be opening a new security leak.

Which is why if your data is very sensitive, you need to secure it in the database level. There are several ways of doing that – you could use data source command blocks to pass the user’s data to the database on every session, for either logging or identification purposes. With SQL Server, you have built in Single Sign On abilities you can facilitate. With Oracle you can implement Single Sign On using a proxy user, and if further security is required, that proxy user’s credentials can be further secured by SEPS, and the usage of alter user grants can ensure that while logged in via proxy, only certain actions are allowed.

To conclude, I believe the token prompt loophole Paul found is in most cases not worth the efforts securing. When it is – because no risk is a small risk with certain types of data – security should be implemented on the database level, not on the Framework level. But this isn’t just about Paul’s example: This is the proper way to tackle any security gaps that come up, either by a survey or from experience. Evaluating the risk to begin with, and taking proper action in the proper level eventually.

The author, Nimrod Avissar, is a Cognos Architect and Cognos Team Leader at Data-Mine Israel. 

Bug: In Cognos 10 new packages don’t inherit permissions

For the past week I’ve been researching a fix to an issue where new packages don’t inherit permissions.

Take the following scenario:

My client has a policy where all packages are saved in specific folders according to the associated project.

All projects are saved in the “Projects” folder with their own specific permissions.

Admins are granted full permission, the project admins are responsible for creating and maintaining the reports, and for granting rights to other users besides the default users for the project. Users are granted only read, execute, and traverse rights. Meaning that they can run any report, but not save anything to the folder. Admins can override this, of course, but that’s their own problem.

In theory, every new item should inherit these settings. Admins can override, but the general practice is to always allow the inheritance. Unfortunately there is a bug in Cognos in which newly created packages overwrite the inherited permissions.

Admins have their execute permissions removed, meaning they can’t run any of their reports, while users have been granted write rights. If the admins don’t notice and fix it immediately, this leaves a big hole in the security.

Fortunately IBM support is hot on the case. There response is that it’s a known issue, but the work-around is to modify the FM.ini file in the configuration directory.

To fix it, backup and open ..\cognos\c10\configuration\fm.ini in your text editor of choice.

Find the line

<Preference Name="SetPolicyPackage">FALSE</Preference>

and replace it with

<Preference Name="SetPolicyPackage">TRUE</Preference>

and save the file.

As this is not an XML file, no restart of Cognos is necessary. You probably need to restart FM if it’s open. All new packages will now inherit correctly.

My thanks to the IBM rep who helped me solve it, and to Noam at Libi who opened the ticket for me.

Use Design Locale for Reference ID in 8.4.1

Sorry, no screenshots for this one. Blame InfoSec.

Cognos 10 has a nice little checkbox that you can set to have authors use only the design language when creating reports. Without this option any changes made to any of the non-design languages may break existing reports. Report authors will have to always use the design language when building reports.

Sadly that checkbox doesn’t exist in previous versions. You can, however, manually change the model.xml and add the same tag.

First, back up your model.xml. You don’t want to mess this up.

Place the following code between the </defaultLocale> and <namespace> tags.

 <fixIdsToDefaultLocale>true</fixIdsToDefaultLocale> 

Publish your model, create a new report, drag in a data item into a query. While the data item caption should appear as your active language, the reference should appear in the design language. Remember to close your browser completely before creating the new report, as you may inadvertently use a cached version of the model.

I have only tested this in 8.4.1, but it may work in previous versions. I don’t know and don’t have access to FM of previous versions, so I’d welcome feedback indicating which versions it works.

Hiding objects from lineage

The lineage function is a great tool for users to understand how items are calculated. Business users can use it to fully understand what they’re seeing. The downside of the lineage is that users can fully understand what they’re seeing.

To the best of my knowledge there is no way of telling Cognos to obfuscate a step in the lineage path. This can cause problems if, for example, you use Cognos functions to decrypt a numeric value.

Case in point: an unnamed large company has a field called “Encrypted Data”. The users need to be able to build adhoc queries with the data, but they are not allowed, under any circumstances, to know the decryption formula. A custom database function is out, so it can only be done in Cognos. The users have a tendency to use lineage to double check numbers.

As you can see, lineage leaves a gaping hole in security. Fortunately there is a solution.

The first step is to create a calculation in FM that decrypts the field.

In the properties of the calculation set Is Hidden to true.

Next create a parameter map. Call it Decrypter.
Give it a key. Since the example I’m using is based on the orders table, I gave it the key Order. In the value give it the path of the calculation.

Now for the last step. In the business layer instead of calling the calculation directly you’ll call the parameter map with ‘Order’ as the key.

Now when the user tries to peek in at the lineage he sees this:

Instead of seeing the super secret formula, he only sees the call to the param map. If he doesn’t have access to FM, he will never be able to see the formula now.