Before
Security staff likely reviewed suspicious Okta login events one by one, manually ended the affected user's sessions, and switched between reputation, threat intelligence, and geolocation tools to investigate the source IP. They then had to copy the findings into a team message, wait for a block-or-ignore decision, and manually update the network zone and communicate the outcome.
How it works
- Receive and process each suspicious Okta login event, then clear all active sessions for the affected user.
- Enrich the source IP with reputation, threat, and geographic information and send the findings to the relevant team in Slack.
- Apply the team's decision by adding the IP to an Okta network zone when blocking is requested, or by notifying the team that the event was ignored.
Workflow details
- Event intake and processing: The workflow starts with a list of suspicious login events reported in Okta and processes each event individually so that every affected account and source IP receives the same response.
- Immediate account containment: For each suspicious login, the workflow removes all active sessions associated with the impacted Okta user, helping end existing authenticated sessions before the investigation continues.
- IP enrichment: The source IP is checked through AbuseIPDB and VirusTotal for reputation and threat information, then geolocated through IPinfo.io to provide additional context about the login.
- Team notification and decision: The collected event and IP details are sent to the relevant team in Slack, where the team can respond by choosing to block the IP or ignore the event.
- Conditional follow-up: If the team chooses to block the address, the workflow retrieves and updates the Okta network zone to include the suspicious IP, then posts an update in Slack. If the event is ignored, it posts the decision instead.
What changed
Each suspicious login now receives consistent containment and IP enrichment automatically before the team is notified. The human decision is limited to choosing whether to block or ignore the event, after which the corresponding Okta update and Slack communication are handled by the workflow.
Work removed
Manually reviewing each suspicious login, clearing user sessions, checking IP reputation, retrieving threat reports, looking up IP location, copying findings into Slack, checking the team's response, updating the Okta network zone, and sending follow-up notifications.
Expected outcome
At least five recurring per-event actions—session termination, three IP-enrichment checks, and the initial team notification—are automated, with conditional network blocking and follow-up communication handled after the team's decision.
