mcpField
I
insider-risk-baseline

insider-risk-baseline

github.com/vinayaklattheSecurity17876 installsUpdated 19w ago
Repository

About insider-risk-baseline

A setup guide for Microsoft Purview Insider Risk Management programs, aimed at teams handling insider threats. It covers policy selection, privacy controls, investigation workflows, and signal tuning.

Key features

  1. 01Choose insider-risk policy templates
  2. 02Connect HR data and configure indicators
  3. 03Protect privacy with pseudonymisation and RBAC
  4. 04Review alerts, investigate cases, and escalate
  5. 05Tune thresholds and use Adaptive Protection

Use cases

  1. 01Set up departing-employee data theft detection
  2. 02Investigate sensitive-data leaks or policy violations
  3. 03Define privacy controls for insider-risk reviews

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/vinayaklatthe/microsoft-security-skills --skill insider-risk-baseline

After installing, type/insider-risk-baselinein Claude Code to confirm it loaded.

Details

From the project README

Microsoft Purview Insider Risk Management (Baseline)

Insider Risk Management (IRM) uses signals across Microsoft 365 and connected sources to detect, investigate, and act on risky insider activity - data theft, leaks, and policy violations - with privacy-by-design controls (pseudonymisation, RBAC, separation of duties).

When to use

Standing up an insider-risk program: departing-employee data theft, sensitive-data leaks, and security-policy violations - with legal/HR/privacy sponsorship in place.

Do not use this skill for risk-adaptive DLP design after IRM is running (use purview-advanced-dlp) or for general communication compliance (use purview-communication-compliance if available).

Pick the right starting policy template

ConcernTemplate
Employees leaving with dataData theft by departing users (needs HR connector for resignation/termination)
Sensitive-content leaks to unauthorised recipientsData leaks (general / by priority users / by disgruntled users)
Security-policy violations (malware, AV disable, etc.)Security policy violations
Risky AI usageRisky AI usage (preview/GA as available)
Patient data / healthcare scenariosPatient data leaks (sector-specific)

Rule of thumb: pick one template per quarter, tune it to acceptable signal-to-noise, then add the next. Multiple templates active simultaneously without tuning swamps reviewers.

Approach

  1. Engage stakeholders - Bring legal, HR, privacy, and (where applicable) works councils to the design table; document the lawful basis for monitoring. Verify: signed-off scope document specifying data sources, retention, reviewer roles.
  2. Configure prerequisites - Set IRM settings, enable required indicators (Office, device, physical badging via connectors), and connect HR data via the Microsoft 365 HR connector for events like resignation/termination. Verify: HR connector status is healthy and a test resignation event appears within 24 hours.
  3. Choose policy templates - Start with templates: data theft by departing users, data leaks, security policy violations, and risky AI usage; configure scope. Verify: policy is in place with a defined user scope (pilot first) and indicator set.
  4. Privacy by design - Enable pseudonymisation of usernames, scope analyst/reviewer roles tightly (RBAC, separation of duties), and configure anonymisation per legal/works-council needs. Verify: reviewers see pseudonymised identifiers by default; un-anonymise requires elevated role.
  5. Triage & investigate - Review alerts, build cases, examine the user activity timeline, and escalate (e.g., to eDiscovery / HR) per the documented workflow. Verify: case management workflow exists with stages, owners, SLAs.
  6. Tune indicators and thresholds - Adjust thresholds to acceptable signal-to-noise; document tuning decisions for audit. Verify: alert volume per reviewer per week within the agreed range.
  7. Adaptive Protection - Feed IRM risk levels into Adaptive Protection so DLP/Conditional Access tighten dynamically for elevated-risk users. Verify: an elevated-risk test user triggers the stricter DLP branch.

Guardrails

  • Engage legal/HR/privacy stakeholders before deployment; insider risk monitoring is sensitive and getting governance wrong damages employee trust and creates legal risk.
  • Use pseudonymisation and least-privilege reviewers by default; separate IRM analyst from investigator roles.
  • Tune indicator thresholds to avoid alert overload; start with a focused scope (one BU or priority-user group) before tenant-wide.
  • HR connector is mandatory for departing-user detection - resignation/termination events drive the highest-confidence signal; without it the template is half-blind.
  • Document retention for IRM signals/cases per legal/regulatory requirements; do not retain longer than justified.

Common anti-patterns

  • Switching on every template tenant-wide on day one - reviewer fatigue within a week.
  • No HR connector - departing-user template fires on weak signal and misses real cases.
  • Pseudonymisation off because "we trust our analysts" - works council and legal disagree later.
  • Single role group with full IRM permissions - no separation of duties.
  • No defined escalation path to HR/legal - cases die in the queue.

Example prompts

  • Stand up an Insider Risk Management policy for departing-employee data theft.
  • How do I configure pseudonymisation and least-privilege reviewers in IRM?
  • Connect HR data so resignation/termination events trigger IRM signals.
  • Feed IRM risk levels into Adaptive Protection.
  • Tune IRM indicator thresholds to reduce alert overload.

Microsoft Learn

Comments

Markdown supported