![]() 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.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. Replay any dataset to Splunk Enterprise by using our replay.py tool or the UI.In an ideal world, every security function would have a Detection Engineering team. Initial Confidence and Impact is set by the analytic author. The Risk Score is calculated by the following formula: Risk Score = (Impact * Confidence/100). Okta ThreatInsight has detected or prevented a high number of login failures. Known False Positivesįidelity of this is high as it is Okta ThreatInsight. ![]() This search is specific to Okta and requires Okta logs to be ingested in your Splunk deployment. List of fields required to use this analytic. It allows the user to filter out any results (false positives) without editing the SPL. Okta_threatinsight_login_failure_with_high_unknown_users_filter is a empty macro by default. | `okta_threatinsight_login_failure_with_high_unknown_users_filter` | stats count min(_time) as firstTime max(_time) as lastTime values(displayMessage) by user eventType outcome.reason `okta` eventType="" AND outcome.reason="Login failures with high unknown users count*"
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |