By Elwood Philbrick, Envisn, Inc.
It’s likely that most Cognos environments seldom, if ever, get a self-audit of their security when in reality it’s a great opportunity to determine if key parts of security are correctly applied. It does of course require the right tools to do this since many parts of Cognos are totally opaque within itself and security is the best example of this. But in most cases today it’s only an annual audit from outside the organization that tests the security model across the entire Cognos environment. And in many cases, it likely doesn’t happen at all. This is unfortunate since a security audit or review can often uncover major issues.
So what would a self-audit of Cognos security cover? Mostly it’s simply checking to see if the organization’s security model is set up and working the way it was designed to. But even if there is not a formal security model in place, doing a self-audit will allow you to question if what you have really makes sense. The results could form the basis of a plan to create a more robust security model.
Recognizing that the definition of security may be slightly different from one environment to another, a list of key areas might include the following:
- Random testing of how data security is currently being applied.
- Membership of all groups and roles.
- Testing of overridden and inherited security.
- A test of 5 – 6 randomly selected accounts to validate their access within Cognos.
- Is access to data being applied on the basis of “a need to know”?
- Is there a log of all changes made to security within Cognos?
- Check distribution lists of automated reports to validate recipients.*
Let’s take a look at some of these areas.
Simply reviewing the memberships of groups and roles can often quickly identify issues or problems. And since groups and roles can have other groups and roles within them, this gets somewhat difficult in Cognos since it can be tedious to sort through them without tools to help. In Figure 1 we can see how the role of BI Marketing Staff is comprised of two roles that are further comprised of two more roles plus accounts, which further shows Expanded Members of those two roles. This is only possible by being able to “explode” these out fully so that you can easily see how they all relate to each other. And it’s clearly the best way to quickly and easily validate that these are used and tiered together as they should be.
Inherited and overridden security is another area where it is difficult to easily see where and how this is applied in Cognos without using a tool to make this access easier. Inherited security simplifies setting up security in Cognos since you can assume, for example, that all reports in a given folder have the same access security. But since exceptions often need to be granted, doing this by selectively overriding security is a great advantage. But how do you know that those exceptions are valid? You may not without actually testing these in some or all cases.
In Figure 2 we can see an example of part of a report showing overridden security in this environment.
An external audit of Cognos security often involves a Cognos administrator being given a list of account names and asking to see what each of them has access to within the Cognos environment. Trying to do this in Cognos can take some time and even then it’s likely that not everything an account has access to can be identified, and may possibly be misidentified. What we need is something like what we see in Figure 3A below that shows summary and detail of access.
We see that the account of Duncan Reilly has access to five locations and a total of 52 objects. And in Figure 3B we can see some of the folders that account has access to along with a lot of the detail of folders, reports, queries, etc. Being able to get access to the detail like this is important since there may be confidential data or personal privacy data in these objects.
How important is having this level of detail? That question can only be answered in the context of each Cognos environment. If having the ability to validate security down to and including the actual data items used in a report object, and tied to a user account is a requirement, then a high level of detail is essential. Without it you will never be able to insure that security is properly applied.
In Figure 4 we see a log of all security changes made across a Cognos environment over the last 60 days. This level of detail can be helpful to insure that a record of security changes is kept for all areas within Cognos.
Self-audits of Cognos security on a regular basis can help insure that the organization’s security model is being followed and can correct any identified problems. And with the right tools this can be done quickly and easily. For this blog we used Envisn’s NetVisn product to create these examples.
* This is a real example. By simply reviewing distribution lists of automated reports one large company learned that key internal information was being emailed to external vendors without authorization.
© Envisn, Inc. – 2020 – All rights reserved. Tools for Cognos
