Using Identity Cloud SIEM Events and SIEM Applications

The “problem” with SIEM events (or any type of event, for that matter) is that a single event, in isolation, is often meaningless. For example, suppose you receive an event that tells you someone tried, and failed, to log on to your website. Could that be a hacker trying to gain unauthorized access to the site? Well, it could be. But, then again, it could be someone who simply mistyped their email address or password and then clicked Login. By itself, one event is often of marginal interest. Or importance.

Instead, SIEM events are most useful when they are collected and analyzed as a whole. One failed login probably doesn’t mean much; for a popular website, 1,000 failed logins in a day probably doesn’t mean much, either. But 1,000 failed logins in the past 5 minutes? Hmmm ….

This is why SIEM events are almost-always imported into an analytics application such as Splunk or QRadar, tools that help you aggregate those and help you look for patterns and anomalies. When it comes to SIEM events, this is usually the best course of action.

However, there is one catch here. As noted previously, the General Event Delivery service does not package SIEM events in the “traditional” SIEM formats: Log Event Extended Format (LEEF) or Common Event Format (CEF). That doesn’t mean that Identity Cloud SIEM events can’t be used in Splunk or QRadar; it just means that there are a couple of things you need to be aware of before importing Identity Cloud SIEM events into your analytics tool.

To begin with, although Identity Cloud events are delivered as JSON files, your SIEM application might not recognize them as such, at least not immediately. For example, if you try to import these files into Splunk as standard JSON files ( _json files), you’ll get the message No results found:

Instead, anyone using Splunk Enterprise needs to click Source type, point to Structured, and then click json_no_timestamp in order to import the files:

Do that, and Splunk will then recognize the individual events.

Admittedly, things might be different for you and for your SIEM application. But that’s the point: it could take a bit of trial and error before your SIEM tool will recognize the Identity Cloud events. But stay with it: these files can be imported.

Second, Identity Cloud SIEM events do not have an obvious timestamp that tells you when the event took place. Instead, the date and time that an event occurred is stored in the msts field using the Unix epoch datetime format. For example:

"msts": 1564596891000

The epoch time 15031201142534 represents the amount of time, in seconds, that have elapsed since midnight (UTC time) on January 1, 1970. That time also converts to Wednesday, July 31, 2019 at 6:14:51 PM UTC time. But your SIEM application won’t know this.

Fortunately, SIEM applications provide ways for you to reformat dates when you run a search query. Providing information on how to search (and how to format search results) in a SIEM application goes well beyond the scope of this documentation. However, here’s a very simple Splunk query that returns the value of the msts field along with a more human-readable datetime field (eventTime):

akamai_idcloud_siem | eval eventTime=strftime(msts/1000, "%m/%d/%Y %H:%M:%S") | table msts, eventTime

When you run that command, you’ll get back results similar to these, with the date and time translated to a more readable format: