Integrating IBM Control Desk or Maximo with QRadar for monitoring logins

Background

You may need to monitor ICD/Maximo logins with QRadar, and that's what this post will detail, as there are a few steps and a lack of documentation around it. In this case, I'm using ICD 7.6.1.1 and QRadar Community Edition 7.3.3 (downloaded on 3/13/2020).

All of the steps here apply to both ICD and Maximo, since there is nothing ICD-specific about them, so I'm going to refer to the product as just ICD in the remainder of this post.

Introduction

ICD doesn't log logins by default, and even once you configure it to track logins, it logs them to a database table rather than SystemOut.log. 

Tracking logins

To enable login tracking, you need to go into the Security->Security Groups application in ICD. From there, choose the Security Controls action. In the dialog shown, select "Enable Login Tracking?" and you're done. That's it. To test it, log out and back in again, then use your favorite database tool to look at the contents of the MAXIMO.LOGINTRACKING table. You should see your login.

Configuring QRadar for a JDBC Log Source

This part is a little tricky, but that's why I'm writing this article. You need to create a new Log Source with the following important characteristics:

Type: Universal DSM

Protocol: JDBC

Database name: MAXDB76

Table name: MAXIMO.LOGINTRACKING

Compare field: ATTEMPTDATE

Those are all of the hard properties. The others should be fairly straightforward, such as hostname, port, etc. After that, deploy your changes. Once that's done, log out and back into ICD, and you should get an event that looks similar to this:

Now you can set up the normal parsing, extracting, etc. to have QRadar properly categorize your events.

Improving the QRadar to ServiceNow integration by adding QRadar event payloads to ServiceNow incident

Using the standard configuration for the QRadar/ServiceNow integration gives you some great capabilities, but some of our customers have asked for more information in the generated ServiceNow incidents. Specifically, they've asked to have the payloads from the events associated with the offense to be added to the Description of the incident in ServiceNow. This provides extensive details about the events that triggered the offense in one pane of glass so the SOC engineer doesn't have to separately open QRadar to get this information.

This can be accomplished my making some configuration changes in both QRadar and ServiceNow. I'll provide the overview here. If you would like more details, please contact me.

1. Add the offense start time to the incident description in the mapping within QRadar.
2. Create a ServiceNow business rule to parse the offense id and start time from the description whenever a new incident is created from QRadar.
3. In that same business rule, use the offense id, start time and a stop time (equal to start time +1) to submit an Ariel query to QRadar via REST to have the query run.
4. In that same business rule, parse the results of the previous REST call to get the results id, then make a second REST call to obtain the actual results, which will be the payloads of the events that caused the offense (and resulting incident) to be created.

The solution doesn't tax either system very much at all and makes life easier for the security engineer researching the issue.

QRadar has a low cost Data Store option that lets you store and search as much data as you want

It looks like this has been around since April, but I just ran across it today. The QRadar Data Store option allows you to store as much log data as you want, without having to pay the normal EPS price. Here's more information on it:

https://www-01.ibm.com/support/docview.wss?uid=swg22009471

And a short video that talks about it:

https://www.youtube.com/watch?v=YmEKdpxADXo

It does have a cost, but it's MUCH cheaper than the normal QRadar cost, and it allows you to use the same QRadar interface to search all of your log data (rather than only your security related information).