#Splunk stats earliest update

| stats count min(_time) as _time values(outcome.result) as outcome.result dc(eval(if(eventType='policy.evaluate_sign_on',targets,NULL))) as total_challenges sum(eval(if(eventType='',1,0))) as total_successesīy authenticationContext.externalSessionId targets actor.alternateId client.ipAddress ```Stats per user/session/ip/target app``` | eval targets=mvfilter(targets LIKE 'AppInstance%') Index=main sourcetype=oktaim2:log target.displayName', ': ')

Alerts when more than half of app sign on events are unsuccessful, and challenges were unsatisfied for more than three apps.

Creates a ratio of successful SSO events to total MFA challenges related to Application Sign On Policies.

Formats target fields so we can aggregate specifically on Applications (AppInstances).

Retrieves policy evaluation and SSO details in events that contain the Application requested.

The following analytic looks for multiple attempts to open app chiclets with no successful response to an authentication challenge. Multiple Failed Requests to Access Okta ApplicationsĪ detection opportunity arises when an adversary attempts to reuse a stolen web session cookie in an org with well-configured authentication policies.

| where dc_src_ip>1 AND (dc_userAgentOS>1 OR dc_userAgentBrowser>1) ``` If we see different Operating Systems or Browsers from a UserAccount using with the same DTHash ```

Index=main sourcetype=OktaIM2:log eventType IN (policy.evaluate_sign_on) outcome.result IN (ALLOW, SUCCESS) | stats earliest(_time) as _time values(client.ipAddress) as src_ip values() as user_agent values() as userAgentOS_list values() as userAgentBrowser_list values(device.os_platform) as okta_device_os dc() as dc_userAgentBrowser dc() as dc_userAgentOS dc(client.ipAddress) as dc_src_ip values(outcome.reason) as reason by actor.alternateId Evaluates whether there is more than one IP and whether there is more than one OS or browser for each combination of User/Device Token.Aggregates/Groups by Device Token and User, providing the first policy evaluation event in the search window.Retrieves policy evaluation events from successful authentication events.The following analytic looks for one or more policy evaluation events in which multiple client values (IP, User Agent, etc.) change associated to the same Device Token for a specific user. The logic for each is presented below: Okta Phishing Detection with FastPass Origin CheckĪ detection opportunity arises when an adversary attempts to reuse a stolen web session cookie. Abuse of Push MFA (including “MFA Fatigue” attacks)Īll of these detections are relevant to Okta Identity Engine (not the Classic Engine).Post-compromise activity by threat actors abusing a stolen session token.Session Hijacking via phishing for initial access.

#Splunk stats earliest update

The Splunk update enhances their pre-existing analytic stories for Okta, and includes new approaches to detecting: James and Michael have tweaked these raw detections to make them more legible and applicable to a broader number of our mutual customers. The first of those discussions has already borne fruit with Splunk, the security analytics platform chosen most often by Okta customers, thanks to the assistance of James Brodsky, Splunk’s GVP for Security Strategy and Splunk Senior Threat Researcher Michael Haag.Īs of Splunk Enterprise Security Content Update (ESCU) v3.62.0, security teams that ingest Okta System Log events into the Splunk platform can run and modify an initial set of bespoke detections in Splunk® Enterprise Security developed by Okta’s Defensive Cyber Operations team. Over the past few months, Okta’s Defensive Cyber Operations team has shared bespoke detection logic with security analytics/SIEM providers, requesting the logic be baked into their content libraries “out of the box.” That’s where mutual friends come in handy. But we recognize that publishing them here won’t reach everybody, and it still puts the onus on customers to tune or adapt the detections. Publishing raw detection logic will suit many of our customers. So we’ve decided to publish our detection logic.

Whenever we write a detection for our own purposes (we use Okta, too!), there’s an untapped opportunity to use those detections to help other Okta customers prevent or respond to security incidents that stem from common credential-based attacks. It's a challenge that Okta Security wants to help address. There can be a misconception that cloud service providers are doing the monitoring for them. Regrettably, even organizations that are stewards of highly sensitive data often can’t afford (or don’t prioritize) the capabilities required for effective security monitoring. In an ideal world, every security function would have a Detection Engineering team.