Identity Cloud SIEM events

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):

Event NameDescription
config_changeA customer configuration value was changed by using the Identity Cloud APIs.
new_email_verificationA user successfully verified their email address.
legacy_social_registrationA user successfully registered by using a third-party identity provider.
legacy_social_signinA user successfully authenticated by using a third-party identity provider (IDP).
legacy_sso_signinAn end user was automatically authenticated by using single sign-on (SSO). This event occurs because the user either (1) visited a new website within the collection of sites using SSO; or, (2) had their SSO access token refreshed by a previously-visited site.
legacy_traditional_registrationA user successfully registered by using an email address and password.
legacy_traditional_signinA user successfully authenticated by using an email address and password.
password_recoverA user has changed their password after clicking the Forgot Password link on the sign-in screen.
profile_createA new user profile database record was created.
profile_deleteA user profile database record was deleted.
profile_updateA user profile database record was updated. This event is fired with numerous other events; for example, each successful login updates the lastLogin attribute of a user profile.
entityCreatedIndicates that a new entity type record (typically a new user profile) has been created.
entityUpdatedIndicates that an entity type record (typically a user profile) has been updated. This record includes the names of the attributes that have been modified, but does not include the old or the new values assigned to those attributes.
entityDeletedIndicates that a record (typically a user profile) has been deleted from an entity type database.
authenticationFailedKnownUserIndicates that registration has failed for a known user (for example, a user recognized by his or her email address). The reason property will contain one of the following values:

* accountDeactivated. Authentication failed because the user record has been deactivated.

* invalidCredentials. Authentication failed because the user submitted an incorrect password.

* null. Authentication failed for an unknown reason.
authenticationFailedUnknownUserIndicates that registration has failed for an unknown user (typically a user who submitted an unregistered email address). The reasonproperty will contain one of the following values:

* unknownUser. Authentication failed because the specified email address does not exist in the entity type database.

* invalidGrant. Authentication failed due to an invalid access grant request (for example, the user provided an invalid social login token).

* null. Authentication failed for an unknown reason (for example, a user did not complete social login).
credentialAuthenticationAttemptsExceededKnownUserIndicates that a known user (as determined by a unique identifier such as the user’s email address) has exceeded the login attempts threshold. By default, a user is allowed a maximum of six login attempts in a 60-second period before being temporarily locked out of the system.

This event can be useful in identifying potential SPAM attacks or account breaches. Alternatively, it can also point to a user who has simply forgotten his or her password.

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.


Did this page help you?