Van poortwachter naar waakhond: pre-auth en post-auth beveiliging met elkaar verbinden

By Mirko Peters · 2026-08-11

Welkom terug bij de podcast en de bijbehorende technische deep dive! Als je ooit het gevoel hebt gehad dat je identiteitsbeveiligingsstrategie een blinde vlek heeft direct nadat een gebruiker…

Automatically translated with AI from the original post. Read the English original

Welkom terug bij de podcast en bij de bijbehorende technische verdieping! Als je ooit het gevoel hebt gehad dat je identiteitsbeveiligingsstrategie een blinde vlek heeft direct nadat een gebruiker succesvol is ingelogd, dan ben je zeker niet de enige. Jarenlang hebben organisaties sterk vertrouwd op pre-auth-maatregelen om de slechteriken buiten de deur te houden, en de voordeur als het laatste bastion van beveiliging behandeld. Maar wat gebeurt er als een aanvaller met een geldig token of een gestolen set inloggegevens toch die deur passeert? Precies dat dilemma stond centraal in onze recente aflevering, Conditional Access with Defender for Identity Signals. In deze post gaan we dieper in op die concepten en laten we zien hoe je je pre-auth-poortwachter en post-auth-waakhond kunt combineren tot een werkelijk veerkrachtige identiteitsarchitectuur.

Het kernidee (TL;DR)

Om moderne identiteitsbescherming echt te begrijpen, moet je je tools zien als gespecialiseerde rollen die realtime samenwerken:

• Conditional Access (CA) is je portier. Het is uitstekend in het nemen van pre-auth-beslissingen op basis van wie er probeert binnen te komen, vanwaar die persoon komt en de staat van het apparaat.
• Defender for Identity (DfI) is je cameratoezicht gecombineerd met je beveiligingspersoneel op de vloer. Het blinkt uit in het monitoren van post-auth-gedrag, laterale beweging en afwijkingen binnen het netwerk.
• Echte veerkracht ontstaat pas wanneer post-auth-risico de pre-auth-wrijving automatisch en dynamisch verhoogt, precies daar, tijdens de sessie.

Mentaal model

Laten we het mentale model verfijnen van hoe deze componenten in je omgeving met elkaar samenwerken:

• Poortwachter (CA): Beoordeelt wie er inlogt, waar die persoon zich bevindt, de staat van het apparaat en het risico bij aanmelden, en dwingt directe sessiebeheersing af.
• Waakhond (DfI + M365 Defender): Speurt naar laterale beweging, afwijkende toegangspatronen tot bronnen, Kerberoasting, misbruik van NTLM en onverwachte escalaties van bevoegdheden.
• Terugkoppelingslus: De waakhond signaleert verdacht gedrag, wat op zijn beurt de gebruikersrisico- of sessierisicoscore verhoogt. Daardoor moet de poortwachter de controles direct aanscherpen door MFA af te dwingen, de toegang volledig te blokkeren of de actieve sessie te beperken.

Integratieblauwdruk (wat je in welke volgorde inschakelt)

Om deze systemen met elkaar te laten communiceren, is een gestructureerde uitrol nodig. Dit is de blauwdruk die je moet volgen:

1. Risicobewuste CA (basislijn)
   • Entra ID Protection: schakel de evaluatie van Gebruikersrisico en Aanmeldingsrisico in.
   • Maak CA-beleidsregels aan:
     • Blokkeren bij Gebruikersrisico = Hoog (of vereis een wachtwoordwijziging als je helpdeskprocessen dat ondersteunen).
     • MFA vereisen bij Aanmeldingsrisico ≥ Gemiddeld.
     • Vereis een compliant apparaat voor apps met gemiddelde tot hoge gevoeligheid; gebruik apparaatfilters voor niet-beheerde endpoints om ze direct naar beperkte sessiebeheersing te leiden.
2. Laat de waakhond met de poortwachter praten
   • Zorg dat DfI actief waarschuwingen streamt naar Microsoft 365 Defender en Sentinel (als je die voor SIEM/SOAR gebruikt).
   • Automatiseer acties "Gecompromitteerd bevestigen" op gebruikers bij DfI-waarschuwingen met hoge ernst. Dit zet Gebruikersrisico = Hoog in Entra ID Protection, waardoor je CA-beleidsregels direct reageren.
   • Automatiseringspad: M365 Defender-incident → Logic App of Power Automate → Graph Security/Identity Protection API (/riskDetections, /riskyUsers:confirmCompromised) → optioneel Afmelding forceren.
   • Schakel Continuous Access Evaluation (CAE) in voor alle ondersteunde apps (Exchange, SharePoint, Graph), zodat beleidswijzigingen daadwerkelijk lopende tokens beëindigen.
3. Sessiebeheersing voor insluiting
   • Voor niet-beheerde of riskante sessies zet je Defender for Cloud Apps (sessieproxy) rechtstreeks vanuit CA in:
     • CA → Use Conditional Access App Control (eerst monitoren, daarna dataexfiltratie blokkeren, zoals downloads, kopiëren en plakken, afdrukken en synchroniseren).
   • Koppel dit aan MDE-apparaatrisico → Intune-compliance → CA „Compliant apparaat vereisen” voor alle gevoelige toepassingen.
4. Beveiligingsvangrails voor geprivilegieerde identiteiten
   • PIM moet Just-in-Time-toegang afdwingen; vereis MFA + compliant apparaat + geen riskante gebruikersstatus voordat verhoging van rechten wordt toegestaan.
   • Implementeer een CA-beleid om geprivilegieerde rollen te blokkeren als gebruikersrisico ≥ Laag (ja, ook bij een laag risico) om direct te laten triëren voordat een beheerdersrol kan worden geactiveerd.

„If This, Then That”: DfI-signalen koppelen aan CA-acties

Door specifieke detectiesignalen van Defender for Identity te koppelen aan geautomatiseerde Conditional Access- en responsacties, overbrug je de kloof tussen passieve observatie en actieve verdediging:

Begin met deze in de modus audit/monitor gedurende 1 tot 2 weken en zet de reacties daarna per waarschuwingsklasse om naar de modus afdwingen naarmate je meer vertrouwen krijgt.

Voorbeeldbeleid (praktisch, minimaal)

Om deze strategieën in productie te brengen, zijn hier vier fundamentele beleidsregels die je moet configureren:

1. Blokkeren wanneer gebruikersrisico = Hoog
   • Toewijzen: alle gebruikers (uitsluiten: break-glass-accounts), alle cloud-apps
   • Voorwaarden: gebruikersrisico = Hoog
   • Toekenning: toegang blokkeren
2. Step-up bij aanmeldingsrisico
   • Toewijzen: alle gebruikers, apps met veel waarde (beheerportalen, Exchange, SharePoint, Entra-beheercentrum)
   • Voorwaarden: aanmeldingsrisico ≥ Gemiddeld
   • Toekenning: MFA vereisen + compliant apparaat (of beheerd apparaat) vereisen
3. Sessie beveiligen voor niet-beheerde apparaten
   • Toewijzen: alle gebruikers, SharePoint/OneDrive/Teams
   • Apparaatstatus: Hybride/Compliant = omzeilen; Niet-beheerd = afdwingen
   • Sessie: Conditional Access App Control gebruiken (downloads blokkeren)
4. Bescherming bij verhoging van rechten
   • Toewijzen: directoryrollen = geprivilegieerde beheerrollen
   • Voorwaarden: gebruikersrisico ≥ Laag OF aanmeldingsrisico ≥ Gemiddeld
   • Toekenning: MFA vereisen + compliant apparaat vereisen; blokkeren bij risico ≥ Hoog

Automatiseringsplaybooks (direct te koppelen)

Automatisering is het geheime ingrediënt dat je Mean Time to Contain (MTTC) verlaagt. Dit zijn twee playbooks die je vandaag al kunt bouwen:

Playbook A: DfI-waarschuwing met hoge ernst → identiteit insluiten

• Trigger: M365 Defender-incident met de tag IdentityThreatHigh
• Acties:
  1. Graph API – bevestig dat gebruiker is gecompromitteerd (zet gebruikersrisico op Hoog)
  2. Entra ID – vernietig vernieuwingstokens direct
  3. Intune/MDE – apparaat isoleren (als er één primair apparaat aan is gekoppeld)
  4. ServiceNow/JSM – maak een incidentticket aan met de tijdlijn en verzamelde artefacten
  5. Informeer het SOC en de gebruikerseigenaar via een adaptieve kaart in Teams, met een knop voor terugdraaien in één klik voor het geval van valse positieven

Playbook B: Verdachte piek in SharePoint-toegang

• Trigger: Defender-waarschuwing „Ongebruikelijk bestand gedownload”
• Acties:
  1. Label de gebruiker met UnderInvestigation via AAD-extensiekenmerken
  2. Verplaats de gebruiker naar een CA-beleid dat hen doorstuurt naar App Control (downloads en afdrukken blokkeren)
  3. Start een eDiscovery-bewaring op de getroffen SharePoint-sites (optioneel, afhankelijk van de compliance-eisen)
  4. Laat de insluiting automatisch verlopen na 72 uur, tenzij het SOC deze handmatig verlengt

Hunting & nuttige query's

Proactief zoeken helpt je hiaten te ontdekken voordat aanvallers ze misbruiken. Gebruik deze query's in de Advanced Hunting van M365 Defender:

Piek in SharePoint-sitetoegang door een gebruiker vergeleken met hun basislijn van 30 dagen:

let lookback=30d;
let recent=1h;
let baseline = CloudAppEvents
    | where Timestamp between (ago(lookback) .. ago(recent))
    | where Application == "SharePoint" and ActionType == "FileAccessed"
    | summarize uniqSites=dcount(SiteUrl) by AccountUpn;
CloudAppEvents
| where Timestamp >= ago(recent)
| where Application == "SharePoint" and ActionType in ("FileDownloaded","FileAccessed")
| summarize curSites=dcount(SiteUrl), dls=sumif(1, ActionType=="FileDownloaded") by AccountUpn
| join kind=leftouter baseline on AccountUpn
| where curSites > 3 * coalesce(uniqSites,1) or dls > 500

Pieken in aanmeldingsrisico die nauw samenhangen met latere DfI-waarschuwingen:

let riskySignIns = IdentityLogonEvents
| where RiskLevelDuringSignIn in ("medium","high")
| project AccountUpn, Timestamp, RiskLevelDuringSignIn;
let dfiAlerts = IdentityDirectoryEvents
| where EventType startswith "DefenderForIdentity"
| project AccountUpn, DfiTime=Timestamp, AlertType=EventType;
riskySignIns
| join kind=inner dfiAlerts on AccountUpn
| where DfiTime between (Timestamp .. Timestamp + 4h)

Metrics die het werken bewijzen

Wanneer je terugrapporteert aan het management, heb je metrics nodig die aantoonbare risicoreductie laten zien. Houd deze kpi's bij:

• Mean Time To Contain (MTTC) voor identiteitsincidenten (tijd vanaf het genereren van de waarschuwing tot handhaving van CA) ↓
• Verblijftijd van de aanvaller (tijd vanaf de eerste verdachte actie tot volledige herstel) ↓
• Geblokkeerde risicovolle sessies (door beleid getriggerde gebeurtenissen) ↑ terwijl het percentage false positives ↓
• Leeftijd van de achterstand bij risicogebruikers (open zaken ouder dan 24 uur) ↓
• Vertraging bij intrekken van tokens (gemeten in seconden) ↓
• Mislukte privilegeverhogingen door risico (vroegtijdig onderschept voordat er schade ontstaat) ↑ en daarna normaliserend in de tijd
• Secure Score over Identity, Devices en Apps ↑ zonder enige overeenkomstige piek in helpdesktickets

30/60/90-implementatiestrategie

Probeer niet alles in één keer te veranderen. Gebruik deze gefaseerde tijdlijn:

Dag 0–30 (fundament)

• Schakel de User and Sign-in risk-instellingen van Entra in en rol de CA-basisbeleidsregels uit in auditmodus, en schakel daarna over naar handhaving.
• Koppel Defender for Identity aan M365 Defender; valideer de waarschuwingen en de belangrijkste entiteitskoppelingen.
• Zet Continuous Access Evaluation (CAE) aan voor ondersteunde apps en integreer MDE-apparaatrisico met Intune-compliance.

Dag 31–60 (feedback & indamming)

• Bouw playbooks A en B in Logic Apps en test ze uitgebreid in een dry-run-status.
• Pilot App Control voor onbeheerde sessies met 2 tot 3 samenwerkende zakelijke teams.
• Implementeer het guardrail-beleid voor PIM-verhogingen.

Dag 61–90 (afdwingen & meten)

• Zet je geautomatiseerde playbooks voor waarschuwingen met hoge betrouwbaarheid over naar de volledige enforce-modus.
• Richt een identity security-werkmap in (in Sentinel of Power BI) die de hierboven genoemde metrics bijhoudt.
• Voer per kwartaal een purple-team-oefening uit om je MTTC, de snelheid van tokenintrekking en het schakelen van CA-beleid te valideren in een live-fire-scenario.

Veelvoorkomende valkuilen (en veiligere standaardinstellingen)

Let tijdens je implementatie op deze veelgemaakte fouten:

• Valkuil: uitsluitend vertrouwen op het aanmeldrisico van CA → Oplossing: reageer ook op gebruikersrisico en DfI-waarschuwingen na authenticatie.
• Valkuil: geen CAE geconfigureerd, waardoor verouderde tokens gecompromitteerde sessies in leven houden → Oplossing: schakel CAE in en bouw tokenintrekking direct in je geautomatiseerde playbooks in.
• Valkuil: downloads van bestanden breed in de hele onderneming blokkeren, wat tot verzet bij gebruikers leidt → Oplossing: pas App Control selectief toe, alleen wanneer sessies onbeheerd of risicovol zijn.
• Valkuil: waarschuwingsstormen en false positives door agressieve automatische compromitteringsworkflows → Oplossing: koppel je automatiseringen aan verificatie met meerdere signalen (bijv. DfI-waarschuwing met hoog risico + ongebruikelijk downloadvolume + toegang buiten kantooruren).
• Valkuil: break-glass-accounts die per ongeluk worden buitengesloten door geautomatiseerd risicobeleid → Oplossing: sluit twee zwaar gemonitorde break-glass-accounts uit en roteer hun inloggegevens per kwartaal.

Kopieer- en plakartefacten

Gebruik deze kant-en-klare teksten om deze wijzigingen binnen je organisatie te communiceren:

CAB-samenvatting voor het management:

We hebben het gedrag van gebruikers na aanmelding succesvol gekoppeld aan onze toegangsbeslissingen. Als een account zich ongebruikelijk gedraagt, voegen we extra beveiligingsdrempels toe of blokkeren we de toegang tijdens de sessie. Zo wordt de verblijftijd van aanvallers drastisch verkort, zonder het dagelijkse werk te vertragen.

Wijzigingsnotitie voor beheerders:

• Nieuw Conditional Access-beleid kan om step-up-MFA vragen of de toegang blokkeren wanneer afwijkend risico wordt gedetecteerd. Actieve authenticatietokens kunnen nu op basis van telemetrie tijdens de sessie worden ingetrokken. Break-glass-accounts blijven uitdrukkelijk uitgesloten. Houd de Identity Resilience-werkmap in de gaten voor een impactanalyse.

Eigenaarvriendelijke Teams-meldingskaart (geautomatiseerd):

• “We hebben ongebruikelijke bestandsactiviteit vastgesteld vanuit je account. We hebben tijdelijke beveiligingsmaatregelen toegepast (zoals het uitschakelen van downloads op onbeheerde apparaten). Was jij dit, klik dan op Bevestigen; zo niet, klik dan meteen op Melden.”