5 Biggest Mistakes with IBM Cognos Security

By Paul Hausser, Envisn, Inc.
mistakes in cognos security

This blog focuses on the biggest issues in the area of Cognos security as seen by Cognos administrators. It was collected informally from a series of questions responded to over the past 14 months.

• Using an outdated security model. If your current security model cannot effectively handle change and growth you have a real problem. Every organization experiences these at different rates but change and growth are always there.

Ideally you want to have groups and roles that can accommodate adding new entities and changes to existing ones as they occur. This isn’t always possible so you may need to create a new security model at some point.
When creating a new security model try to insure that is clear, simple and easily understood. Spending some time understanding why you’re current model no longer works can be helpful to designing the new one. Also, eliminating groups and roles that are no longer needed can keep them from being used incorrectly in the future.

• Inconsistent use of groups and roles across the environment. Groups and roles behave almost identically but they are different. Groups can contain only accounts and other groups, while roles can contain accounts, groups and other roles. A simple rule to follow is to use roles to control access to capabilities and groups to manage access to content. Another rule to follow is to minimize creating new groups wherever possible.

• Too many people administering security. This is a recipe for disaster. Why? Because even if you have clear rules for assigning security they may not be clearly understood or followed. Which is why this area needs to be a balance between giving developers and others the ability to assign security as needed, but also limiting it to only that which is operationally necessary (damage control). It will usually be apparent when you’ve lost control in this area.

• No tools to manage Cognos security. Wouldn’t you like to be the one that discovers problems with your Cognos security? You need the ability to analyze, validate and view security and capabilities assignments quickly and easily. Testing your own security on a regular basis for compliance with standards should be part of what you do on a regular basis.

But Cognos security is inherently complex, especially in the area of inherited security. Trying to view this within Cognos itself is difficult and tedious at best, and often impossible. This is because you’re forced to look at it by how it’s assigned in Cognos Connection. But trying to trace the thread of inherited security within Cognos through multiple layers is virtually impossible. A third party software tool like NetVisn or a similar product can make it a lot easier to see all the dimensions of security and to validate settings as well.

• Access Permissions. While easily understood within the context of the matrix in Cognos Connection their impact is less so. Access permissions on a Content Store object are by default automatically inherited from its parent. Security settings inheritance in Cognos makes administration easier when dealing with large numbers of objects. The problem arises when security is overridden at lower levels making it difficult to determine where these overrides exist and their impact. Most of this can be avoided by a well thought out organization of your Content Store objects minimizing the need for single object securing changes.