According to the book Paradox of Choice, the problem that people face these days isn’t that we have too few things to choose from; instead, it’s that we have too many things to choose from. As author Barry Schwartz put it:
… as the number of choices keeps growing, negative aspects of having a multitude of options begin to appear. As the number of choices grows further, the negatives escalate until we become overloaded.
At first glance, the Identity Cloud might seem to be prone to this sort of choice overload, at least when it comes to event management and analysis. After all, the Identity Cloud has no fewer than 4 separate tools that work with Identity Cloud events:
To help you navigate through this event management collection, and to help you better understand how SIEM Event Delivery fits into this collection, the primary Identity Cloud event management and analysis tools are summarized in sections.
Console Audit Logs
Data is available only in the Console, and only a handful of agent roles (Application Admin, Console Access Manager, and Console Access Viewer) have full access to the Audit Logs. However, Audit Log data can easily be exported to a comma-separated values file.
Only events triggered from within the Console are recorded in the Console Audit Logs. For example, suppose an agent logs on to the Console, goes to the Manage Profiles page, and deletes a user profile. That event (profile_delete) will be written to the event stream and will be available through the Console Audit Logs.
However, suppose that same agent later uses the entity.delete API endpoint to delete a user profile. That event (profile_delete) will be written to the event stream, but it will not be available in the Console Audit logs. That’s because the event was triggered from outside the Console itself.
Tracking administrative activities that take place by using the Identity Cloud Console. Audit Logs are especially suited for that purpose because: 1) they clearly identify events that took place within the Console; and, 2) they include information about the agent who initiated the event.
By default, data is only available in Customer Insights itself; however, you have the option to export the data, or to have reports automatically generated and emailed to you.
Currently limited to a subset of Identity Cloud events focused on four areas:
- Logins. This includes traditional, social, and single sign-on logins.
- Failed logins. This features notifications of each individual failed login (User A tried to login and failed, then managed to log in successfully) as well as notification each time a user exceeds the maximum number of login attempts (e.g., User A had five login failures in the past 60 seconds).
- Registrations. This includes both traditional and social registrations.
- User profile changes. Covers such activities as creating new user profile, and modifying or deleting existing user profiles.
Provides tables and visualizations that help you better understand who is accessing your web site or app and when they are most likely to be accessing it. Customer Insights is designed to provide demographic analyses of your user base; it is not designed for use as a security tool.
SIEM Event Delivery
Batch-driven event delivery. Relevant events are copied to an application-specific event queue and maintained until one of the following occurs:
- Five minutes have elapsed since the last event delivery.
- The total file size of the queue has reached 128 MB.
When one of the preceding conditions is met, the current contents of the queue are collected in a .ZIP file, and that file is then delivered to a corresponding Amazon Web Services S3 bucket. Organizations can then use SSH File Transfer Protocol (SFTP) to download a copy of the .ZIP file.
Note that each JSON-formatted file in the .ZIP file represents a single event: if 1,000 events occurred during the 5-minute time interval then the .ZIP file will contain 1,000 separate event notifications.
All Identity Cloud events made accessible to organizations. However, administrators can, on a per-application basis, choose to block specific event types and exclude those events from their SIEM feed. For example, an organization might opt to block the profile_update event. In that case, events referencing changes made to a user profile will no longer be included in the SIEM delivery feed.
Batch-delivery of event data designed to be imported into a SIEM analytics tool such as Splunk or QRadar. As the name implies, SIEM (Security Information and Event Management) events are typically used for web site/app security, and to help you identify and suppress potential security problems.
Notifications are sent, in near real-time, to a delivery location set up and maintained by the customer; this location must be an endpoint capable of handling HTTP/HTTPS POST requests.
Notifications are sent as Security Event Tokens (a type of JSON Web Token) and are signed using JSON Web Keys.
Currently limited to the following: entityCreated, entityUpdated, and entityDeleted. Organizations must explicitly create webhook subscriptions in order to receive notifications regarding any event type: if you do not create a subscription to the entityUpdated event then you will not receive notifications regarding changes made to a user profile.
Previously used for notifying organizations when changes are made to user accounts, forthcoming version of Webhooks will provide organizations near real-time notification of any Identity Cloud event. As such, Webhooks subscriptions should be reserved for those events of the most interest/use to an organization, and only if near-instantaneous notification of those events is important. Otherwise, the SIEM Event Delivery service (which delivers event updates every 5 minutes) might be a better solution. (And, unlike, webhooks, the event delivery service does not require you to set up and maintain an endpoint for receiving event notifications.)