Identity Cloud SIEM events (legacy customers only)

๐Ÿ“˜

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": "793d27fa-1391-46d1-a335-61d6c1055d4a",
    "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.

Where do SIEM events come from?

SIEM events are generated by the Authentication APIs, the JavaScript SDK, Hosted Login (up to v2), and the database itself. Note that future versions of Hosted Login won't trigger SIEM events. Instead, those upcoming versions of Hosted Login will trigger a new set of Webhook v3 events based on specific user interactions with the screens. As you might expect, we'll have more information on that process when Hosted Login v3 is released.

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
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 reason property 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).
config_changeA customer configuration value was changed by using the Identity Cloud APIs.
credentialAuthenticationAttemptsExceededUnknownUserIndicates that an unknown user 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.
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.
entityCreatedIndicates that a new entity type record (typically a new user profile) has been created.
entityDeletedIndicates that a record (typically a user profile) has been deleted from an entity type database.
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.
siem#legacy_social_registrationA user successfully registered by using a third-party identity provider.
siem#legacy_social_signinA user successfully authenticated by using a third-party identity provider (IDP).
siem#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.
siem#legacy_traditional_registrationA user successfully registered by using an email address and password.
siem#legacy_traditional_signinA user successfully authenticated by using an email address and password.
siem#new_email_verificationA user successfully verified their email address.
siem#password_recoverA user has changed their password after clicking the Forgot Password link on the sign-in screen.
siem#profile_createA new user profile database record was created.
siem#profile_deleteA user profile database record was deleted.
siem#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.
siem#resend_email_verificationA user has been sent a link for verifying their email address.

๐Ÿ“˜

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.

Blocking SIEM events

As you can see, SIEM reports on a large number of events, including a number of events that your organization isn't interested in tracking Thatโ€™s fine: you can always block an event type, meaning that event 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.

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.