Cognos Security – The High Cost of Not Knowing

Written by The Envisn Team | May 31, 2019

By Paul Hausser, Envisn, Inc.

Of all the areas of Cognos administration the one that appears to cause the most anxiety is security. This likely is the result of the fact that there are so many ways that security can be applied within Cognos Analytics. The distinction between groups and roles, for example, and how they each should be used is one of the least understood aspects of correctly applying security in Cognos. Yet doing this correctly is the cornerstone of any successful implementation of security in Cognos.

A question frequently asked, but not often openly expressed, is this: “Is security correctly applied across our Cognos environment?”

You can be sure that the larger the environment the more likely this question has been on the minds of some people, likely more than once. Any major breach of data security often results in the loss of someone’s job.

Key Questions

So what’s behind this anxiety? Well, first off, simply asking the question clearly implies that there is some defined model for how security should be applied across the environment and that it’s detailed enough to cover all key dimensions of security. This presumes that one was created at some point in time and updated as the organization changed and evolved. Often however, the existing Cognos security model has been in place for a few years and the person or persons that created it are no longer around.

Secondly, this also implies that we have a means of clearly determining if the security we currently have in place across Cognos is correctly aligned with our model. Without a tool that enable us to do this relatively easily and quickly this could be seen as an impossible task and likely never addressed at all. But there are tools that make this possible and will enable you to assess all dimension of security across your Cognos environment. This means groups, roles, objects, folders, accounts, data items, etc. – everything.

In the figure below we see an analysis of roles in a sample environment. There are 47 total roles in this one and they are laid out in a way that we can see that some roles include not only accounts but other roles as well. It also shows how some of these may overlap.

Responsibilities

Perhaps the biggest question of all is, “Who is responsible for insuring that security is correctly applied across the Cognos environment?” Is it assigned to one person, a group or some combination? Without a single point of focus you should probably be nervous at this point.

So how do you get your arms around this? A good beginning would be to simply begin asking questions and see where it leads.

Every Cognos administrator should asked themselves the question, “How much is it worth for me to know that our security model is correctly applied across Cognos?” If it hasn’t already been answered, then just asking the question is likely to result in action of some type. The key is to have it focused on getting actionable results.

Some guidelines on getting the answer and dealing with results to these questions:

1. Don’t ask the question unless you’re prepared for what’s required to get the answer. This implies having a tool or tools that enables you to get the answer relatively easily and quickly.
2. Don’t ask the question unless you’re prepared to do something with the results. Often this can mean a lot of work to fix things that need to be changed.
3. Depending on what you find it can often be easier to create a new security model than trying to fix an existing one that has been corrupted over time. Often this happens for two principal reason:
a. People assigning new users or creating new groups and roles do not understand how groups and roles differ and how they should best be used.
b. Too many people have the ability to make changes to the security model.
4. Stay in the lanes. Use groups and roles for what they are intended for and minimize exceptions to using them whenever possible. For more on correctly implementing Cognos security download our eBook on this subject.
5. Restrict the number of people able to assign or make changes to security to the fewest number possible.

In an age when there is a clear expectation that the data the company uses to manage itself at all levels is rock solid secure there’s a high cost to not knowing if that’s really true.

View full post