![]() ![]() (Note: events can be of both admin and security interest.) This incorporates, and extends, the Okta Events categorization found here. security_interest: A field set to “1” if the event has particular security interest, such as the identification of a threat within ThreatInsight, or the start of a support technician impersonation session.admin_interest: A field set to “1” if the event is pertaining to admin-level activity, such as the modification of an email template, or the creation of an app sign-on policy.event_type_tags: The various tags (pipe-delimited) that the event is categorized under, such as “admin” or “oauth2” or “workflows.”.event_type_description: The full-text description of the event.csv, this solution enriches them automatically with the following new fields, using the field format_event_type as a matching key. What Additional Information Do You Get?Īs you search in Splunk for each of the System Log events defined in the. Also, this new TA will be Splunk Cloud certified. csv file above remains compatible, at which point I will update this post. Once this new TA releases in the next month or two, I will evaluate it, and ensure that the. csv file – should be applicable to many other SIEM/log management solutions.Īn important note! Splunk is, at the time of this writing, taking over responsibility from Okta for the Technical Add-On for Splunk. While this is designed for Splunk, the same methodology – and the same. csv lookup that provides significant additional enrichment to System Logs as you search them in Splunk. Since Okta maintains a Technical Add-On for Splunk (TA), I thought it might be helpful to extend the existing TA to leverage a custom. Google Chronicle offers both: via references or directly in the parser during ingestion - more about this later.īoth Splunk and Sumo Logic call this functionality “lookup tables”. Microsoft Sentinel has the concept of watchlists, and IBM’s QRadar provides reference data sets. Many SIEM, security analytics, and log management solutions have ways of adding enrichment to events, either upon ingestion or upon query. This search link will allow you to see all Okta Knowledge Base articles that reference System Log - there are plenty more gems in there. For example, we have write-ups on the events emitted by Okta ThreatInsight and on events that can be used to monitor for account takeover attempts. We’ve published a number of resources about Okta System Log to help customers understand the more important entries for security monitoring and common administrative tasks. Splunk has an entire Technical Add-On devoted to Okta System Log, complete with Common Information Model mapping. Partners like Databricks have published blog entries on ingesting System Log data, and Microsoft and Google have published Okta System Log connectors. System Logs can either be ingested using the Okta System Log API or streamed using Okta’s Log Streaming service, and specific logs can also be sent to an external service using Okta’s Event Hook feature. These logs are provided in nicely formatted nested JSON. Many Okta customers send the log entries to their log management or SIEM of choice. Okta offers numerous ways that System Log can be streamed, exported or programmatically queried. The native way to leverage Okta’s System Log is via the Okta Admin console. There must be an easier way to enrich this data! Sending System Logs to a SIEM While the most important of these events are well documented already, the significance of others are only understood when you look them up. When I started writing this post, there were 766 potential System Log types that can appear in System Log, the logging platform in every Okta administrative console.īy the time I finished it, there were 768. Update 06-21-2022: Eleven new System Log events have been added to the Github project to bring the total number of cataloged events to a lucky 777. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |