Skip to main content

Wrapping Up Risk: Insider Risk Management Under the Tree with Adaptive Protection

‘Tis the Season for Security: Why Insider Risk Spikes During the Holidays and How to Manage It

You know the scenario, Halloween has passed, so people start putting up the Christmas decorations in November (much to this Grinch’s chagrin), some workshops close for Christmas, so the rush is on. There’s no time to rest, it’s nose to the grindstone, and ‘tis the season for increased risk. For example, industry analysis shows that cyberattacks and data leaks surge during periods of reduced staffing. According to DTEX Systems, 86% of organisations that experienced ransomware attacks were hit during holidays or weekends, when oversight is lowest. This same reduction in governance heightens the risk of insider-driven data loss. Emails must be sent, temporary staff may join the workshops, and normal procedures can slip. Could it be possible that in amongst these Christmas helpers a Grinch may hide?

Grinches are rare, though not rare enough. Santa checks his list twice, but those on the nice list may be tempted by gold, frankincense, or myrrh.

Fun fact: - When Santa checks his list twice, he’s doing a form of access governance.

 Naughty or Nice? Understanding Insider Risk Management

Which elves are naughty, and which are nice? If only it were that straightforward. Even nice elves can cause problems. The elves are busy slaving away, ensuring the toys are top quality. They sometimes forget to check which John Smith they are sending an email to. Or, perhaps they need to share some gift-related data, and instead of using the Santa-approved apps, they use a Grinch-approved app like WeTransfer.

These things can happen, and it does not necessarily mean that the Grinch has got to your elves. Every busy elf can make mistakes. Santa doesn’t always have time to keep an eye on the elves, and with so much happening, even if he could, there are simply too many activities to monitor. How could he even begin?

This is where Microsoft Purview Insider Risk Management comes in. Now Microsoft Purview Insider Risk Management is a bit of a mouthful – like talking with a mouthful of mince pie. From now on, we’ll call it MIRM because MPIRM doesn’t have the same jingle to it. MIRM uses a technology called Adaptive Protection. This helps separate the naughty elves from the nice but frazzled.

Adaptive Protection assigns risk scores to your elves, and this score increases every time the elves perform risky behaviours, especially when it involves Santa’s list. When switched on, by default, the nice people at Microsoft have set Adaptive Protection to assign an elevated risk level to elves who have performed three sequences, each with a high severity risk score. But then what? Does Santa have to kick each of the Grinch’s secret agents out, one by one?

Fortunately, Microsoft have the solution – Conditional Access and data loss prevention, known as CA and DLP, respectively. Think of CA as a big old boot, ready to jettison the truly naughty elves from the list room. These elves could be booted out of the room, as in prevented from accessing sensitive data, they could be forced to read Santa’s terms and conditions again, or they could be locked out of the workshop altogether until Santa has time to deal with the little reprobate.

Insider Risk Management: - boot out the bad guys

To save poor Santa time, this is all done automatically. Even better - if the naughty elves reform their behaviour, they can be automatically left back into the workshop - or even the list room - without Santa having to do a thing. MIRM uses insider risk levels (Minor, Moderate, Elevated). As elves stack up risky activities — especially involving gift data — their level increases and protections tighten automatically.   

CA can even call for phishing-resistant multi-factor authentication (MFA) to ensure the risky elf is who they say they are, and not some Grinchy imposter. Santa can also insist on using only workshop-approved devices.

Conditional Access - Insider Risk Management

This all sounds good, but it’s complicated to set up, right? It can be, but it doesn’t have to be. Microsoft have a nice gift wrapped up in a neat bow.

CA/DLP controls relating to Adaptive Protection can be viewed in Purview, Insider Risk Management, and either Conditional Access or Data Loss Prevention. The image below shows the conditional access policies applied to Adaptive Protection.

 Insider Risk - Adaptive Protection

What triggers these types of policies? That can be decided by your workshop IT team, but some common triggers of increasing risk include:

🎁 Downloading large numbers of files from Santa’s list repository
📤 Sharing sensitive gifts to personal accounts or naughty cloud apps
🗑️ Deleting large amounts of data before leaving the workshop
🔐 Changing authentication methods in suspicious ways
🚫 Trying to bypass Santa-approved devices or browsers.

 Quick Setup - Gift-Wrapped by Microsoft

Setup can be a jolly experience because Microsoft and their little helpers have made it very easy to set up your policies. Thankfully, in Santa’s tenancy, Adaptive Protection is already enabled. This option is found in the Insider Risk Section under the Adaptive Protection, which surprisingly has no snow or icicles hanging from it.

Turn on Adaptive Protection

 It may not be a festive scene, but the image above shows that turning on Adaptive Protection is a cinch (not a Grinch). Turning on Adaptive Protection automatically creates policies to help win the fight against the green grump of Christmas.

This automatically creates not one, not two, not three, but four policies – you have been on the good list, haven’t you? 

These policies include: -

  •   2 x DLP policies. One for Teams and Exchange, and one for devices.
  •   1 x CA policy to block users with elevated risk assignments.
  •   1 x Data Lifecycle Management policy to protect data deleted by risky little elves. This policy will retain anything deleted by elevated risk elves for 120 days.

Festive fact: - if multiple policies are applied to the same data, the most restrictive wins.

The latter is hidden away from the Grinch and his followers. It cannot be found in the retention policy or label policies sections. In Santa’s tenant, this safeguard was only found by using the policy look-up option under Data Lifecycle Management, Policies, Policy lookup.

Insider Risk - Data Lifecycle Management - Policy Lookup

Santa assumes you’ve already created your own Microsoft Insider Risk Management (MIRM) policies. If not, start with this: - https://learn.microsoft.com/en-us/purview/insider-risk-management-policies. Start with at least these policies: -

    1.  Theft by Departing Users
    2.  Data Leaks
    3.  Risky AI Usage
    4. Security Policy Violations (if using Microsoft Defender for Endpoints (MDE) and sharing endpoint security alerts with the compliance portal).
    5.  Risky Browser Usage (ensuring devices are onboarded into Purview, the Microsoft Purview Extension is installed, and at least one browsing indicator is selected.

Onboarding your devices into Purview is a prerequisite. Some of these policies will work without it, but Santa prefers the level of detail you get when you're onboarded and have the Microsoft Purview extension installed. Install this regardless of your festive browser, as it will help DSPM for AI check the naughty list. That’s a story for another day, preferably around the fire with a mince pie in one hand and a sherry in the other.

There will be points towards the nice list if you also set up the following: - 

  • Data Leaks by Priority/Risky Users (set up your priority users in settings, Insider Risk Management, Priority User Groups). 
  • Security Policy Violations by Priority/Risky Users (again, if wrapped up by MDE)
  • Health Record Misuse (if appropriate to your toy factory).

Who can help Santa? (Permissions are required)

Not every elf is permitted to assist Santa on his Insider Risk journey. Here is Santa’s list for MIRM permissions.

Role

Description / Abilities

Insider Risk Management Admin

Full control over IRM set up and configuration. Can create, edit, and delete policies, manage permissions.

Insider Risk Management Analyst

Investigates alerts and cases. Can view, triage, and escalate or close cases.

Insider Risk Management Investigator

Performs deep-dive investigations, accesses sensitive data and forensic evidence, collaborates with HR/legal.

Insider Risk Management Approver

Approves requests for forensic evidence capture, ensuring privacy and compliance.

Insider Risk Management Auditor

Read-only access to audit logs and reports. Cannot modify policies or cases.

Insider Risk Management Session Approver

Approves session-based actions, such as privileged access or investigative steps.

Viewer (Read-Only)

Can view alerts and cases but cannot take action or make changes.

Make sure your elves only have enough permissions to perform their role.

Other Festive Requirements

MIRM is not an isolated workshop in the North Pole, separated from the others. For Adaptive Protection to work its magic, Santa’s list should be properly recognised using Microsoft Purview classification — such as sensitivity labels or trainable classifiers.  

Conclusion – before you get to the mince pies

As the holiday season sparkles, insider risk at work can rise—Santa’s elves are busy, procedures slip, and even the nicest helpers might make mistakes or use Grinch-approved apps. Microsoft Purview Insider Risk Management (MIRM) is Santa’s secret weapon: it spots risky elves, automatically boots out the naughty ones, and lets the reformed back in, all without Santa lifting a mitten.

Setting up MIRM is as easy as unwrapping a present. Microsoft’s gift includes ready-made policies for data leaks, risky AI usage, and more, plus festive controls to keep the workshop safe. Just remember—only elves on the nice list get the right permissions, and Santa’s list should be properly labelled for the magic to work.

 

Comments

Popular posts from this blog

Session control policies in Microsoft Defender for Cloud Apps - block copy, cut, and paste in web apps

In this article, I attempt to outline the process for creating session control policies using Conditional Access (CA) and Microsoft Defender for Cloud Apps or MDA for short. When I first set this up, I was unaware of the need to have a user sign in between setting up the CA policy and setting up the policy in MDCA which then allows session control policies to be applied. I will guide you through this, the policy setup and testing.  An overview of the setup process looks like this: 1. Setup the CA policy 2. Have a user login 3. Apply the MDA access policy and add your conditions.  4. Test it 1. Setup the CA policy Pre-requisites: -  a. the app should be available as an "Enterprise App" in Azure AD. Secondly, the app should support and be configured for SAML SSO.  b. Azure AD P1 licenses are required. My understanding was always that MDA required Microsoft 365 E5 or equivalent licenses for applying policies, but Microsoft states in the following article that Azure AD P...

Microsoft Purview Endpoint DLP for MacOS

Get onboarded The first step is to get the macOS device enrolled in Intune for easy management. To do so, follow this guide: https://learn.microsoft.com/en-us/mem/intune/user-help/enroll-your-device-in-intune-macos-cp The guide is a little out of date, but the principals work all the same. Now to get the device onboarded into Microsoft Purview. https://learn.microsoft.com/en-us/microsoft-365/compliance/device-onboarding-offboarding-macos-intune?view=o365-worldwide As you will have seen in the article above, onboarding uses the same mechanism for onboarding macOS to MDE. Once the configuration profiles are installed as seen in Intune > Devices > macOS > macOS devices > click the device name > Device configuration . They should have a nice green tick next to the word “Succeeded” under the “State” header. I had a bit of a brain spasm with the naming, I would use Microsoft’s naming suggestion as seen in their guide.   Create the DLP policy To configure the ...

Conditional Access

Learning To get the most out of this article, I would recommend building out a trial policy whilst reading. Do this on a test tenancy. If you don’t have one, sign up for a free trial on this link: https://portal.office.com/Signup?OfferId=B07A1127-DE83-4a6d-9F85-2C104BDAE8B4&dl=ENTERPRISEPACK&ali=1   What is it? Conditional Access (CA) is, as the name suggests, a way of controlling access to your Azure and Microsoft 365 data and services based on a set of conditions. These can be conditions such as “Sign-in risk” , “Device platforms” , “Locations” - which can be inside or outside the network or can be applied to a specific location, “Client apps” - what client apps are being used, and the “Device state” which can include states such a “non-compliant”/”compliant” and whether or not the device is “Azure AD joined” .  You might think that it all sounds a little bit complicated. It can be, I will not lie, but I intend to take you through Conditional Access and demystify...