📘

The content on this page deals with a legacy feature of the Akamai Identity Cloud. If you are currently an Identity Cloud customer and are using SIEM event delivery, that feature is still supported. However, if you’re new to the Identity Cloud, SIEM event delivery is no longer available.

One important tool in the battle to keep networks, computers, and data safe is SIEM: Security Information and Event Management. SIEM systems (such as Splunk Enterprise Security, IBM Security QRadar SIEM, and ArcSight Enterprise Security Manager) are designed to:

• Import logs and other files from multiple devices (with “devices” meaning anything from software to computers to routers and other types of hardware).

• “Normalize” these disparate log files into a standardized format. For example, out-of-the-box Splunk can combine data extracted from such disparate sources as Apache log files, comma-separated value files, and syslog files (to name just a few).

• Provide tools for real-time (or near real-time) incident detection and trend analysis, and do so across an organization’s entire spectrum of devices.

For example, by analyzing log files a SIEM system might detect an out-of-the-ordinary flurry of login attempts, an unusual occurrence that could signal the onset of a denial of service attack. By itself SIEM software cannot prevent the attack. However, by alerting you to the situation in near real-time, SIEM enables you to take action that helps prevent the attack, or at least enables you to stop the attack and limit any damage.

SIEM tools such as Splunk or QRadar typically import data formatted as either LEEF (Log Event Extended Format) files or as CEF (Common Event Format) files; however, neither of these formats are required. And that’s good, because the Identity Cloud's General Event Delivery system uses neither the LEEF nor the CEF format. Instead, SIEM events are formatted as JSON (JavaScript Object Notation) files similar to this:

{
    "id":
    "message": {
        "app_id": "htb8fuhxnf8e38jrzub3c7pfrr",
        "client_id": "nmub5w3rru9k6rzupqaeb7bbwv6jn658",
        "endpoint_uri": "http://documentation.akamai.com/widget/traditional\_signin.jsonp",
        "event_type": "legacy_traditional_signin",
        "forward_headers": [
            {
                "name": "HTTP_X_FORWARDED\_FOR",
                "value": "192.168.1.1, 192.168.1.2, 192.168.1.3"
            },
            {
                "name": "HTTP_X_FORWARDED\_PROTO",
                "value": "http"
            },
            {
                "name": "HTTP_X_FORWARDED\_PORT",
                "value": "80"
            }
        ],
        "ip_address": "192.168.1.1",
        "origin": "https://login.documentation.akamai.com/",
        "user_agent": "Mozilla/5.0 (Android 8.1.0; Mobile; rv:68.0) Gecko/68.0 Firefox/68.0",
        "user_uuid": "437920f3-85dd-4cb7-ba8c-7025faea1d2c"
    },
    "msts": 1566206726081,
    "type:" "siem#legacy\_traditional\_signin"
}

See Import SIEM events into Splunk or more information.

It’s worth mentioning that all allowed events will be available in your SIEM delivery feeds (although organizations have the option to remove events from those feeds, and to re-add those events later on as needed). Note that this differs from the Identity Cloud's initial (and now-discontinued) SIEM offering, which exposed only a handful of events, all centered around logins, registrations, and user profile updates.

We should also note that, at this point in time, SIEM event delivery is something of a “manual” process: JSON files are automatically delivered to an Amazon S3 bucket as .ZIP files (see How the SIEM event delivery service works), but from there organizations must manually download the .ZIP files, extract the JSON files contained inside those .ZIP files, then import the JSON files to a SIEM analytic tool.

Events reported by the SIEM event delivery service

The General Event Delivery service is the Identity Cloud’s new method for generating event information, maintaining a data warehouse of that information, and – equally important – making many of these event types available to customers. At the moment, the event types exposed to the SIEM Event Delivery Service include the following (click the event name to view an example of the notification sent when that event occurs):

📘

It's possible that you might receive an event type not shown in the preceding table. That's typically because you're using an older flow that leverages mail types that the current standard flow doesn't use. If you have questions about this, contact your Identity Cloud representative.

In addition to the events listed in the preceding table, more events are being developed and will periodically be released to SIEM subscribers. That, needless to say, leads to an obvious question: what happens when the Identity Cloud releases new events? Will ​Akamai​ have to rewrite applications (such as the SIEM Event Delivery service) in order to allow for these new event types? Will customers have to reconfigure their current setup and create new event subscriptions? It’s nice that you want to extend airline service to our town, but what good does that do us if we don’t actually have an airport?

Fortunately, those are questions, and concerns, that you don’t have to worry about. Instead, any time new customer-exposed events are added to the event delivery system (a process referred to as “allow listing”), those events are automatically made available to all SIEM event customers. There’s no need to reconfigure or reinstall anything, and no need to “subscribe” to these new events: those events will simply begin showing up in your delivery feeds. If ​Akamai​ decides to add 5 new events, ​Akamai​ support will make a single API call that adds those 5 events to the allow list. And each and every SIEM-enabled application will automatically be subscribed to those new events. It’s that easy.

📘

And what if you don’t want those new events? That’s fine: you can always block the new events, and then they won’t show up in your SIEM deliveries after all. And, if you later change your mind and would like to receive these events after all, you can just as easily remove events from your application-specific block list. The General Event Delivery service is designed to let organizations manage the service as they see fit. Do you want to receive notifications each time a user updates his or her user profile? That’s fine: by default the profile_update event (along with every other exposed event type) will be delivered to you. But you say you’d rather not receive notifications each time a user updates their user profile? That’s also fine: just add the profile_update event to your application block list. Like we said, it’s that easy.

The key takeaway here? There are actually two key takeaways. First, the allow list is managed by ​Akamai​ and is global: these events apply to all SIEM-enabled applications without exception. If the profile_update event type is available at Application A, that means it’s also available to applications B, C, D, and E.

Second, block lists are managed by ​Akamai​ customers, and on an application-specific basis: if the profile_update event type is put on the block list for Application A, that has no effect at all on Applications B, C, D, and E. Those other applications all have their own event block list, separate and distinct from Application A’s block list. Manage the service -- and even your individual applications -- as you see fit.

A note concerning duplicate SIEM events

If you look closely at the list of supported events, you’ll see that there are some duplicate event types:

• The profile_create event returns the same information as the entityCreated event.
• The profile_delete event returns the same information as the entityDeleted event.
• The profile_update event returns the same information as the entityUpdated event.

Why the duplication of events? As it turns out, profile_create, profile_delete, and profile_update are “legacy” event types that have long been used in the Identity Cloud. Meanwhile, entityCreated, entityDeleted, and entityUpdated represent new event types that, over time, will replace the legacy event types. However, for backwards compatibility reasons, the decision was made to add the new event types but not immediately delete the legacy event types; that could cause issues for organizations that rely on the profile_create, profile_delete, and profile_update events. Consequently, and for an unspecified amount of time, there will be a handful of duplicate event types.

Does that matter to you? It might. After all, by default SIEM subscribers receive all the events for all the event types on the SIEM event allow list. That means:

• If you haven’t blocked SIEM events the profile_create, profile_delete, and profile_update event types you’ll start to receive duplicate event notifications. For example, suppose User A updates her user profile. In that case, two event notifications will be sent to you for that one event: one notification for the profile_update event and one notification for the entityUpdated event. To stop receiving duplicate notifications you’ll need to block one set of event types.

• If you have blocked the profile_create, profile_delete, and profile_update event types, that’s likely because you don’t want to receive notifications of user profile-related events. Now, however, you will receive those notifications. When User A updates her user profile, you won’t receive a notification for the blocked profile_update event type, but you will receive a notification for the entityUpdated event type. To stop all user profile-related notifications you’ll need to block the three new event types (entityCreated, entityDeleted, and entityUpdated).

As we hinted at a moment ago, the legacy event types will eventually be removed from the SIEM event delivery system (although no timetable for removal has been announced). Because of that, and if you want to receive user profile-related events, ​Akamai​ recommends that you block the legacy events (profile_create, profile_delete, and profile_update) and use the new event types (entityCreated, entityDeleted, and entityUpdated) instead. This keeps you from receiving duplicate event notifications, and helps to ensure that there won’t be any problems when the legacy events are removed: after all, if those events are blocked, you aren’t receiving notification for them anyway.