Weekday Okta sign-in security digest posted to Slack

Every weekday at 8am, review my Okta sign-in security posture from the last 24 hours and post one triaged digest to my security channel in Slack.

Start with the Okta List System Log Events operation. Pull authentication events for a bounded window covering the period since the previous run, which is normally the last 24 hours ending at the moment the workflow runs. Always set both the since and until bounds explicitly in UTC. The Okta System Log retains about 90 days by default and queries beyond that require time bounds, so keep the window short and always bounded. Page through the results until there is no next page, so a noisy night does not get silently truncated.

Group what comes back into four buckets. First, failed sign-in spikes against a single account: the same user hitting roughly 5 or more failed sign-in attempts inside the window, and call it out loudly when those failures came from 3 or more distinct IP addresses or more than one country, because that is the shape of credential stuffing. Second, account lockouts. Third, MFA denials and factor resets, meaning denied or rejected multi-factor challenges and any factor reset or re-enrollment event. Fourth, sign-ins from a new country or an unusual location for that same user: for each user with a successful sign-in, compare the location against that user's own recent prior sign-ins in the same pull, look at roughly the last three sign-in locations, and flag it when the country differs. Also flag two sign-ins from different countries that are too close together in time to be real travel.

Cross-reference the repeat offenders with the Okta List Users operation so the digest names the person rather than a bare user id. For every user who lands in a flagged section, report their full name, their login or email, their department, and their current account status, such as active, suspended, locked out, or deactivated. If a flagged sign-in attempt targets a username with no matching user record, say so explicitly, because attempts against accounts that do not exist are themselves a credential stuffing signal.

Post exactly one Slack message using the Send a Message operation to my security channel. Lead with anything that looks like credential stuffing or account takeover, then the remaining flagged items in descending order of seriousness. Give each flagged person a short section with what happened, when it happened, the source IP addresses and locations involved, their department and account status, and a one line suggestion of what a human should check. Keep routine noise out of the body: ordinary one-off password typos and isolated failures that were followed by a successful sign-in from the user's usual location belong in a single short summary line at the bottom, for example "Routine: 14 isolated failed sign-ins across 11 users, each followed by a successful sign-in from a known location." Use Slack formatting with bold section headers and short lines, and keep it to one message rather than a thread.

If nothing crossed the thresholds, still post a brief all-clear that names the window reviewed and roughly how many events were checked, so the team knows the check ran rather than silently failing.

This workflow reads and reports only. Never suspend, deactivate, lock, unlock, reset a password, or reset a factor for any Okta user, no matter how suspicious the activity looks. Recommend the action in the message and leave the decision to a person.