IBM Cognos Security Bulletin FAQ

Danny Gargus, September 4, 2020

Anyone who has spent significant time using or developing with IBM software has probably seen a security bulletin or two arrive in their email box occasionally. As a consultant, I usually scan it quickly for relevant information and then send it to my favorite Outlook folder – Deleted Items. But what if you’re in charge of a BI environment at a company? Should you be concerned about these security vulnerabilities? And if you’re new to the game how do you even find which bulletins apply to your Cognos version or environment? Maybe you didn’t even know there were security bulletins! I’ll try to break it down below.

Table of Contents

I’ll have what she’s having

I don’t remember when I first started receiving the security bulletins. It was probably shortly after I created my IBM ID but I don’t remember signing up to receive them. Maybe I did – it’s been a while. But you do have to have an IBM ID to get them and once you have an ID then you can manage your notifications. Your company may have an IBM account and if they do be sure you get added to it.

On the My Notifications page, you can control which products you would like to monitor. I have several Cognos products along with some others. You can easily search for an IBM product. Researching for this article, I searched for Cognos and noticed I was not subscribed to Cognos Analytics itself.

It’s as easy as hitting the subscribe link next to the product. Once you do, you’ll get another list to select which items related to the product you would like to receive notifications for.

You can uncheck any of them as they are all selected by default. Since we’re talking about security bulletins, I’ll be sure to leave Security Bulletin selected. Now I will receive an email whenever a new bulletin is released.

The Breakdown

Now that we’re receiving bulletins, how do we read it and what do the fields mean? Well, it depends on the type of email being sent out. Below is an example of a bulletin that is letting me know that there are new downloads and/or drivers available. The type of notifications you receive depends on what you signed up for. Clicking one of the links on the page takes you to an IBM page that explains what it is and how you can download it. This one is pretty self-explanatory and not what we’re really here to discuss.

What we really want to talk about are the Security Flash Bulletins which may indicate vulnerabilities in our system. Below is an example of one I received a while back. Notice it’s a little different in that it has the big red line across the top noting that this is something you might want to look at. We get a little bit of a description but clicking the link gets us a lot more info that we need.

On the IBM page, the first thing we see is the summary of the problem, most of which was in the email. Beneath that are the vulnerability details. There could be multiple vulnerabilities affecting the same software. These will have a reference ID for each vulnerability.

So now what? We can see the vulnerability scores but we need to know what’s considered bad or worse so we can determine our course of action. The first item we have is the CVEID. CVE stands for Common Vulnerabilities and Exposures and there is a whole website dedicated to these so this is not IBM specific. Here is a link to a FAQ page that describes what they are and how they work. Clicking on the ID will take you to the CVE site which may give you more information than what IBM included.

Next, we have a CVSS Base Score. CVSS stands for Common Vulnerability Scoring System which IBM uses to communicate the severity of the threat. It is an open standard which can be calculated and it results in a score from 0-10.

Skipping down to the CVSS Vector, this contains the method used to score the threat and the actual values used. Breaking down the long string we have:

• CVSS:3.0 – This is the method used. There are 2 methods: 2.0 and 3.0 and they both have calculators. In this case, they used 3.0 which is here. The 2.0 calculator is here.
• AV:N – Attack Vector. The context by which vulnerability exploitation is possible. The Base Score increases the more remote (logically and physically) an attacker can be in order to exploit the vulnerable component. * All possible values are in order from most to least severe.
  • Network (N)
  • Adjacent (A)
  • Local (L)
  • Physical (P)
• AC:H – Attack Complexity. Describes the conditions beyond the attacker’s control that must exist in order to exploit the vulnerability. Such conditions may require the collection of more information about the target, the presence of certain system configuration settings, or computational exceptions.
  • Low (L)
  • High (H)
• PR:N – Privileges Required. Describes the level of privileges an attacker must possess before successfully exploiting the vulnerability.
  • None (N)
  • Low (L)
  • High (H)
• UI:N – User Interaction. Captures the requirement for a user, other than the attacker, to participate in the successful compromise of the vulnerable component. It determines whether the vulnerability can be exploited solely at the will of the attacker, or whether a separate user (or user-initiated process) must participate in some manner.
  • None (N)
  • Required (R)
• S:U – Scope. Does a successful attack impact a component other than the vulnerable component? If so, the Base Score increases and the Confidentiality, Integrity and Availability metrics should be scored relative to the impacted component.
  • Changed (C)
  • Unchanged (U)
• C:N – Confidentiality. Measures the impact to the confidentiality of the information resources managed by a software component due to a successfully exploited vulnerability. Confidentiality refers to limiting information access and disclosure to only authorized users, as well as preventing access by, or disclosure to, unauthorized ones.
  • High (H)
  • Low (L)
  • None (N)
• I:N – Integrity. Measures the impact to integrity of a successfully exploited vulnerability. Integrity refers to the trustworthiness and veracity of information.
  • High (H)
  • Low (L)
  • None (N)
• A:H – Availability. Measures the impact to the availability of the impacted component resulting from a successfully exploited vulnerability. It refers to the loss of availability of the impacted component itself, such as a networked service (e.g., web, database, email). Since availability refers to the accessibility of information resources, attacks that consume network bandwidth, processor cycles, or disk space all impact the availability of an impacted component.
  • High (H)
  • Low (L)
  • None (N)

* All definitions above are from the first.org website.

In this example then, they have given us a base score of 5.9 and we can recreate that with the 3.0 calculator by selecting the values above.

The CVSS Temporal Score has three additional metrics that are used to adjust the value of the score over time. If we click on the link we are taken to another page with the values for the additional metrics as well as an adjusted score.

• E:U – Exploit Code Maturity. Measures the likelihood of the vulnerability being attacked, and is typically based on the current state of exploit techniques, exploit code availability, or active, ‘in-the-wild’ exploitation. *
  • Not Defined (X)
  • Unproven (U)
  • Proof-of-Concept (P)
  • Functional (F)
  • High (H)
• RL:O – Remediation Level. The Remediation Level of a vulnerability is an important factor for prioritization. The typical vulnerability is unpatched when initially published. Workarounds or hotfixes may offer interim remediation until an official patch or upgrade is issued. Each of these respective stages adjusts the temporal score downwards, reflecting the decreasing urgency as remediation becomes final.
  • Not Defined (X)
  • Official Fix (O)
  • Temporary Fix (T)
  • Workaround (W)
  • Unavailable (U)
• RC:C – Report Confidence. Measures the degree of confidence in the existence of the vulnerability and the credibility of the known technical details. Sometimes only the existence of vulnerabilities is publicized but without specific details. For example, an impact may be recognized as undesirable, but the root cause may not be known. The vulnerability may later be corroborated by research which suggests where the vulnerability may lie, though the research may not be certain. Finally, a vulnerability may be confirmed through acknowledgment by the author or vendor of the affected technology. The urgency of a vulnerability is higher when a vulnerability is known to exist with certainty. This metric also suggests the level of technical knowledge available to would-be attackers.
  • Not defined (X)
  • Unknown (U)
  • Reasonable (R)
  • Confirmed (C)

* The above definitions are from the first.org website.

When we plug in these additional metric values, we see that the score has been adjusted down somewhat to 5.2 as exploits are developed and disclosed and as mitigations and fixes are made available over the lifetime of the vulnerability.

He Shoots, He Scores!

OK, not that kind of score. What does this all mean for your company? Only you or your security team can answer that question. To help with the assessment there is an additional section at the bottom of the 3.0 calculator called CVSS Environmental Score which is specific to your environment. From IBM’s website:

CVSS Environmental Score: The environmental score uses the base and current temporal score to assess the severity of a vulnerability in the context of the way that the vulnerable product or software is deployed. The CVSS Environment Score is customer environment specific. Customers can evaluate the impact of the vulnerability in their environments by accessing the links in the Reference section of this Security Bulletin.

I haven’t used this so I don’t know how helpful it really is but it may be worth trying. But now that we have a score is it worth doing anything about? A deep dive into CVSS scores are located here. The CVSS groups the scores into 5 categories – None (0 score), Low (0.1 – 3.9), Medium (4.0 – 6.9), High (7.0 – 8.9) and Critical (9.0 – 10). There is no specific guide as to what to do with each severity level. The scores are just a guide to help organizations properly assess and prioritize their vulnerability management processes.

Bulletins are grouped according to similar types of vulnerabilities such as all those affecting Cognos versions 11.0 and 11.1 that target Java SE and related items. I think the best location to find info is the IBM PSIRT blog site. PSIRT stands for Product Security Incident Response Team and they compile bulletins which are a little easier to find the date of when the vulnerability was detected. The dates on the CVEs are not indicative of the actual date that the vulnerability was reported for some reason.  You can find the site here and do a search for Cognos which pulls up a list in descending order by date so you can go back as far as you want. Searching for Cognos and your version will help narrow the results even more.

Conclusion

I know this is a lot of information to comb through. But as you get used to the bulletins, you’ll be able to skip a lot of the info out there and just focus on the items that are of concern to your company and maybe even specific attack types, such as those that affect networks and confidentiality, for example. Ultimately, you’ll have to decide what to do about them. Many of the vulnerabilities have recommendations on how to fix the problem such as upgrading to a later version of Cognos.

Next Steps

We hope you found this article informative. Be sure to subscribe to our newsletter for data and analytics news, updates, and insights delivered directly to your inbox.

If you have any questions or would like PMsquare to provide guidance and support for your analytics solution, contact us today.