Vorige week presenteerde ik op de ONE Conference van het NCSC het technisch advies over BEC van de Cyclotron-werkgroep waar Attic deel vanuit maakt. Dertien fases, 27 technieken, 19 maatregelen. Geënt op Microsoft365 want daar draaien de meeste mailboxen van Nederlandse zakelijke gebruikers.
De sessie was behoorlijk interactief en de beste vraag vond ik: Of je van Microsoft niet gewoon een zero-trust-implementatie mag verwachten. Waarom moet je dit allemaal zelf regelen?
Microsoft levert het gereedschap, de keuzes maak je zelf
Mijn antwoord: je krijgt van Microsoft alle tools waarmee je zero-trust kan nastreven. Maar welke regels je aanzet, voor wie en met welke uitzonderingen: dat beslis je zelf. Dat is geen gebrek, dat is hoe een platform werkt dat klanten van eenmanszaken tot aan ministeries bedient.
Twee kanttekeningen weliswaar. De eerste gaat over licenties. Voor 1 van de belangrijkste functies, namelijk "voorwaardelijke toegang" vraagt om Entra ID P1. Wil je de toegangscontrole risico-gebaseerd maken, dat vraagt zelfs P2. Wie op Business Basic of Standard zit, heeft een deel van het gereedschap simpelweg niet. Business Premium is gewoonweg het minimum als je controle wilt.
De tweede is leeftijd. Een nieuwe tenant krijgt tegenwoordig behoorlijk strak beleid mee, met security defaults aan. Geen uitzonderingen meer op MFA. Een tenant waar al jaren tweehonderd mensen in werken, kan Microsoft niet zomaar dichtzetten. Ze proberen het wel: er komen Microsoft-managed Conditional Access-policies naar bestaande tenants, maar die starten in report-only en een beheerder kan ze uitzetten. Logisch ook: als een policy uitrol de boekhouding buitensluit, wordt niemand blij.
Dus ja, zero trust is mogelijk. Je moet het alleen zelf inrichten, en je bestaande tenant is waarschijnlijk ouder dan het beleid dat Microsoft nu standaard meegeeft.
Drie BEC-signalen die Defender ziet en een lage severity geeft
Dan het deel van de talk dat over incidentbehandeling ging. Een BEC-aanvaller doet een paar dingen bijna altijd. Microsoft ziet die dingen ook: ze leiden tot Defender of Purview alarmen. Alleen krijgen ze vaak een lage severity mee waardoor een klein IT-team er niet direct of zelfs helemaal nooit naar gaat kijken.
1. Een doorstuur- of omleidregel in de mailbox. De aanvaller wil meelezen zonder steeds opnieuw in te loggen, en een outlookregel overleeft een wachtwoordwijziging. De standaard alert policy "Creation of forwarding/redirect rule" staat op Informational. Bovendien let die policy alleen op regels die via Outlook op het web of PowerShell zijn gemaakt, niet in bijv. Outlook Desktop.
2. Een hergebruikt token vanaf een andere locatie. Met infostealer malware en bij een AiTM-phishingaanval steelt de aanvaller niet het wachtwoord maar de sessie. MFA is dan al gepasseerd. Het hergebruik van zo'n sessie meldt Entra ID Protection (waar P2 voor nodig is) als "Anomalous token", op laag of middel risico, en Microsoft schrijft er zelf bij dat de detectie gevoelig is voor valse alarmen. Dus: lage severity, vaak bewust genegeerd.
3. Een eDiscovery-zoekopdracht naar "factuur" of "betaling". Een account met eDiscovery-rechten doorzoekt in één handeling alle mailboxen van de organisatie en exporteert de uitkomst. De alert policy "eDiscovery search started or exported" staat op Informational.
Het zijn als alarmen van bewegingsdetectie op je IP-camera. Het werkt, maar je krijgt zoveel meldingen dat je ze vanzelf gaat negeren, of de functie zelfs uitschakelt.
Wat het NCSC-advies ervan maakt
Je zou verwachten dat het advies dan vooral over meer detectie gaat. Maar dat valt mee. Van de 19 maatregelen gaat het grootste deel over het optimaliseren van de configuratie. De volgorde die ik in de zaal noemde, is ook de volgorde waarin ik het zou aanpakken.
Eerst hardening. Phishingbestendige MFA. Voorwaardelijke toegang. OAuth-consent door gebruikers beperken (dubbelcheck of je al oip de veiliger Microsoft-standaard draait). Automatisch doorsturen van e-mails naar buiten blokkeren. Die laatste is maatregel 16 in het advies, en hij maakt het eerste signaal hierboven voor een groot deel overbodig: een regel die niet naar buiten mag, levert de aanvaller weinig op. Toch: wie of wat maakte de regel en hoe kwamen zij daar? Dus waak voor dit gedrag en zie het als een indicator dat het account gecompromitteerd is: indicator of compromise.
Dan drift bewaken. Maatregel 13 heet letterlijk monitoring op configuratiedrift. Een tenant die in januari goed stond, staat in juni anders. Een uitzondering voor de directeur die geen zin had in de authenticator-app. Een testregel die is blijven staan. Een nieuwe beheerder die iets "even" openzette. Zonder iemand die dat bijhoudt, is je hardening een momentopname.
Dan de signalen bewaken. Monitoring van verdachte inlogpogingen, de audit log aan, security alerts doorsturen naar iemand die er iets mee doet. En dan ook kijken naar wat op Low en Informational binnenkomt, want als je die bewust negeert, mis je dus alle bovenstaande voorbeelden.
Hardening kan niet zonder monitoring en vice versa. Wie begint met monitoren op een tenant die openstaat, verdrinkt in meldingen over dingen die nooit hadden mogen kunnen. Wie alleen hardt en niet meer kijkt, merkt de drift pas bij het incident en mist het gerommel aan de deur.
Wat je morgen kunt doen
Open in Defender de alert policies en zoek de drie hierboven op. Kijk welke severity ze bij jou hebben, wie de meldingen ontvangt, en wanneer iemand er voor het laatst een heeft geopend. Kijk daarna of automatisch doorsturen naar externe adressen bij jou nog aan staat. Automatiseren? Kies voor Attic MDR.
Het volledige technisch advies staat hier als pdf.
