Before
When a suspicious sign-in alert arrived, an analyst had to move between identity, reputation, endpoint, activity, and incident-management tools to gather context. They then had to compare sign-in patterns, check downloads and devices, look for duplicate incidents, and copy the findings into a brief before triage could begin.
How it works
- Validate the alert, retrieve the user's account context and applications, and collect recent sign-in history for comparison.
- Check IP classification and reputation, download volume, associated devices, active device alerts, and matching open incidents, while recording unavailable data.
- Assemble the findings into a structured report for the triage agent and optionally format and email the report without performing remediation.
Workflow details
- Alert validation: The flow receives a suspicious sign-in alert and verifies that the user, timestamp, and IP address are present. It also reads an optional email address for report delivery and stops with an incomplete-alert status when required information is missing.
- Identity and sign-in analysis: For a usable alert, it checks the account profile and status, assigned applications, and recent sign-in history. It compares locations, browsers, IP addresses, and timing with the user's previous patterns to identify unusual countries, browsers, or rapid location changes, while also recording reassuring activity.
- Network and activity enrichment: Each IP address is classified against configured corporate VPN ranges or checked for external reputation. The flow also examines file downloads around the alert, compares the volume with the configured threshold, and identifies sample files and download timing when data is available.
- Device and incident checks: Known devices associated with the user are reviewed for system details, sensor status, and active alerts. The workflow searches for an existing incident for the same user and alert so the triage agent can see whether duplicate handling may already be underway.
- Triage handoff: Findings, signals, reassuring checks, missing information, timelines, source statuses, device details, downloads, and incident context are assembled into one structured report. The result is marked ready for the agent or given a specific status such as existing incident, account not found, or account disabled; an HTML version can also be emailed when a valid recipient is supplied, while escalation, ticketing, suspension, or session revocation remain human decisions.
What changed
The investigation brief is assembled automatically after the alert is received, with required-field validation, account-status gates, anomaly checks, threshold comparisons, duplicate-incident checks, and source-availability tracking performed consistently. The triage agent receives the organized facts and retains responsibility for conclusions, escalation, ticketing, and any remediation.
Work removed
Opening multiple investigation tools, running repeated identity, sign-in, IP, download, device, and incident searches, comparing activity with historical patterns, copying findings into a report, and manually sending the optional report email.
Expected outcome
A reasonable planning estimate is 15–25 minutes of context-gathering removed per alert, while producing a consistent report for human triage rather than an automated security decision.
