Before
Security analysts likely had to review Microsoft Purview events manually, remove irrelevant application-generated activity, and identify the affected user and relevant operations. They then had to retrieve and compare up to seven days of historical activity before notifying the team and coordinating any account or investigation response.
How it works
- Receive the event batch, exclude non-relevant application activity, and retain sharing, permission, download, deletion, recycling, and folder events.
- Retrieve each affected user's activity from the previous seven days and compare the current event volume and operations with that history.
- If the behavior is assessed as suspicious, post an alert with supporting details and human-selectable options to lock the account, reset the password, hunt the related session, or close the alert.
Workflow details
- Event ingestion and filtering: A webhook receives a batch of Microsoft Purview activity events, removes events generated by the SharePoint application account, and retains relevant sharing, permission, download, deletion, recycling, and folder activity.
- Historical analysis: For each affected user, the workflow retrieves activity from each of the previous seven days, extracts the user's relevant operations, counts the events, and identifies the activity timeframe and associated Azure Active Directory session identifiers.
- Behavior assessment: An analysis step compares the current event batch with the user's recent activity history to determine whether the volume and pattern represent unusual behavior that may indicate possible data loss or insider-risk activity.
- Actionable notification: When suspicious behavior is identified, the workflow posts a message to a team channel containing the affected user, event count, activity assessment, relevant actions and items, and available next steps such as locking the account, resetting the password, investigating the related session, or closing the alert.
What changed
Relevant events are triaged and compared with seven days of user history automatically before an alert is sent. The security team receives the user, event count, activity details, assessment, and available response options in one notification, while the decision to lock an account, reset a password, or initiate a session hunt remains with the analyst.
Work removed
Manually reviewing event batches, filtering out application-generated noise, extracting affected users and operations, retrieving seven days of user history, counting and comparing events, assembling alert details, and manually notifying the response team.
Expected outcome
For each processed batch, the workflow can eliminate one manual event review plus up to seven daily historical lookups, while providing a consistent suspicious-activity handoff with analyst-approved remediation.
