Before
Security personnel likely had to review each suspicious-login alert, move between the detection and identity-management tools, and manually notify the relevant channel. If containment was required, they also had to identify the affected user, revoke active sessions, and retrieve the user's grants for follow-up review.
How it works
- Receive suspicious-login details from the detection alert and post the incident context, including severity, user, outcome, and location change, to a security channel.
- Evaluate the selected response from the notification to determine whether the user's access sessions should be revoked.
- If revocation is selected, remove all active sessions and retrieve the user's grants; otherwise, complete the workflow without further action.
Workflow details
- Detection: The workflow starts when a Panther alert webhook reports suspicious login activity involving an Okta user, including the alert severity, user identity, outcome, and location change details.
- Incident notification: It formats the alert information into a message for a designated Slack channel so security personnel can review the event and choose how to proceed.
- Human decision: The notification presents Approve and Revoke actions, and the workflow evaluates the returned interaction to determine whether containment should be performed.
- Session containment: When the revoke action is selected, the workflow removes all active identity provider sessions for the affected user, helping invalidate currently active access sessions.
- Access review: After session revocation, it retrieves all grants associated with the user so the user's access permissions can be assessed; if revocation is not selected, the workflow completes without taking further containment action.
What changed
The alert context is delivered to the security channel automatically, and the containment branch is executed from the selected response. A human still chooses whether to revoke access, but the session revocation and subsequent grant lookup no longer require separate manual tool actions.
Work removed
Reviewing each suspicious-login alert for the affected user, copying alert details into a security-channel notification, manually revoking all active identity-provider sessions, and manually retrieving the user's grants for access review.
Expected outcome
For each confirmed revocation, the workflow can conservatively remove at least two manual operator actions—terminating active sessions and compiling the user's grants—while ensuring the incident details are available for review in the security channel.
