Defender Connection Filtering

Zonder een zorgvuldig ontworpen connection filter ontstaat een blinde vlek in de verdediging van Exchange Online. Kwaadwillenden kunnen de reputatie van eerder gebruikte IP-adressen uitbuiten, waardoor phishingkits of spamgolven rechtstreeks langs de beveiligingslijnen glippen. Bovendien bestaat het risico dat uitzonderingen ad hoc worden toegevoegd zonder documentatie, waardoor shadow-IT ontstaat die niet wordt meegenomen in controles volgens de Baseline Informatiebeveiliging Overheid of AVG-verplichtingen. Het ontbreken van governance leidt tot inconsistentie tussen tenants, vergroot de kans op resource-uitval en maakt incidentonderzoek ingewikkeld omdat niet duidelijk is welke mailserver toegang hoorde te hebben.

Implementatie

Deze maatregel introduceert een integraal proces waarin connection filtering wordt ontworpen, geïmplementeerd, bewaakt en periodiek herzien. Technische inrichting via Exchange Online PowerShell wordt gecombineerd met beleidsmatige kaders zoals eigenaarschap, audittrail en change management. Hierdoor kan de organisatie snel uitzonderingen toestaan voor hoog-prioritaire partners, terwijl ongewenste IP-adressen systematisch worden geweerd. Het resultaat is een reproduceerbare beveiligingsmaatregel die aansluit op bestaande SOC-processen, waarbij scripts, documentatie en managementrapportages elkaar versterken.

Vereisten

De voorbereidingsfase begint met een grondige inventarisatie van alle primaire en secundaire mailstromen binnen de organisatie, inclusief uitgaande relayservers van leveranciers, gedeelde diensten tussen ministeries en noodvoorzieningen voor rampencommunicatie. Zonder dat overzicht is het onmogelijk om een betrouwbare allowlist te bouwen en blijft er een aanzienlijke kans bestaan dat legitieme berichtgeving onbedoeld wordt geblokkeerd. Teams moeten daarom logbestanden van Exchange Online, historische transportregels en servicecatalogi combineren om een actueel beeld te krijgen van elke bron die ooit e-mail heeft aangeboden. Pas wanneer deze dataset is gevalideerd door zowel het functionele applicatiebeheer als de security officer kan er worden besloten welke adressen vanwege strategische of juridische redenen voorrang krijgen. Betrek hierbij ook externe partners zodat hun contactpunten vooraf gevalideerd zijn en voeg bewijsstukken zoals DPIA-conclusies toe aan het dossier. Daarnaast is het noodzakelijk om de technische randvoorwaarden te controleren die Microsoft oplegt aan connection filtering. Denk aan het vereiste Defender for Office 365-plan, het activeren van de juiste roltoewijzingen zoals Security Administrator en Exchange Administrator, en het borgen van moderne authenticatie via meervoudige verificatie. Er moeten PowerShell-verbindingen kunnen worden gelegd naar Exchange Online vanuit een beheerde werkplek die voldoet aan de Baseline Informatiebeveiliging Overheid en aan het Rijksbrede werkplekbeleid. Documenteer welke beheeraccounts toegang krijgen, hoe hun acties worden gelogd in Microsoft Purview Audit en welke netwerkuitgangen worden gebruikt om de beheerscripts uit te voeren. Deze controle voorkomt dat onbevoegden uitzonderingen kunnen toevoegen en vermindert de kans op misbruik. Controleer eveneens dat noodzakelijke firewalluitzonderingen en proxyregels aanwezig zijn zodat beheersessies niet stranden op netwerkrestricties. Documenteer hoe noodaccounts toegang krijgen wanneer reguliere authenticatieketens uitvallen, want tijdens incidentrespons moet hetzelfde proces beschikbaar blijven. Een derde vereiste is het opstellen van duidelijke selectiecriteria voor zowel toelaatbare als geblokkeerde IP-adressen. Criteria moeten rekening houden met dreigingsinformatie uit Microsoft Threat Intelligence, sectorale bronnen zoals het Nationaal Cyber Security Centrum en lokale afspraken met ketenpartners. Voor elke kandidaat moeten risico, juridische verplichtingen, privacyconsequenties en bedrijfscontinuïteit worden beoordeeld, inclusief de beschikbaarheid van alternatieve kanalen. Denk aan zorgaanbieders die medische data verzenden, gerechtelijke instanties die processtukken delen en leveranciers die incidentmeldingen sturen. Door deze context vooraf uit te werken, kunnen securityteams onderbouwd uitleggen waarom een bepaald adres wel of niet in de allowlist verschijnt, en kan het management de balans tussen veiligheid en dienstverlening toetsen. Bovendien ontstaat er input voor rapportages richting CIO-beraad of auditcommissies. Leg de besluitvorming vast in changeformulieren zodat toekomstige herbeoordelingen kunnen terugvallen op objectieve argumenten en niet afhankelijk zijn van individuele herinneringen. Tot slot moet de organisatie beschikken over operationele randvoorwaarden zoals testmailboxen, geautomatiseerde validatiescripts en een communicatieprotocol richting servicedesks en functioneel beheerders. Er hoort een draaiboek bij waarin staat hoe wijzigingen worden aangevraagd, welke impactanalyse nodig is en welke fallback bestaat wanneer verkeer onverwacht wordt geweigerd. Training voor servicedeskmedewerkers is eveneens een vereiste, omdat zij de eerste signalen van blokkades opvangen en die correct moeten analyseren voordat tickets worden geëscaleerd. Zorg dat alle documentatie beschikbaar is in het centrale kwaliteitsmanagementsysteem en dat auditors kunnen herleiden welke versie van het connection filter van kracht is. Neem in het draaiboek ook op hoe periodieke herbeoordeling verloopt zodat uitzonderingen niet onnodig lang blijven staan, wat direct bijdraagt aan een beheersbare en uitlegbare securitymaatregel. Een volwassen voorbereidingsfase eindigt pas wanneer management formeel heeft bevestigd dat alle randvoorwaarden aanwezig zijn en dat de maatregel afgestemd is met het crisiscommunicatieteam, zodat na oplevering geen improvisatie nodig is.

Implementatie

De implementatiefase begint met het veiligstellen van de huidige configuratie zodat elke wijziging reversibel blijft. Beheerders exporteren bestaande connection filter policies via Exchange Online PowerShell en slaan deze configuratiebestanden versleuteld op in het change-dossier. Tijdens een technische werksessie wordt vastgesteld welke onderdelen kunnen worden hergebruikt, welke transportregels overbodig zijn geworden en welk beleid conflicteert met nieuwe baselines. Ook wordt een onderhoudskalender opgesteld waarin staat wanneer allow- en blocklijsten worden herbeoordeeld, zodat de implementatie niet verzandt in een eenmalige actie maar onderdeel wordt van een doorlopend proces. Tijdens workshops worden eveneens afhankelijkheden met hybride Exchange-servers en mailflow connectors beoordeeld, zodat on-premises componenten niet onverwacht worden geraakt. Het projectteam plant bovendien onderhoudsvensters buiten piekuren om de beschikbaarheid van ketenpartners niet te schaden. Vervolgens worden de gewenste uitzonderingen vertaald naar concrete IP-adresranges. Voor elk adres wordt bepaald of het een structurele partner betreft, een tijdelijke migratiepartner of een bron die juist geweerd moet worden. Deze classificatie wordt vastgelegd in een configuratiebestand waarin naast het IP-adres ook de business owner, het verantwoordelijke team en de vervaldatum staan vermeld. Door deze metadata op te nemen kan later precies worden aangetoond waarom een regel aanwezig is en wie kan beslissen over aanpassingen. Bovendien maakt dit het mogelijk om het beheer te automatiseren, omdat scripts het bestand kunnen uitlezen en zo consistente policies genereren. Elke wijziging wordt voorzien van een risico-classificatie en een korte beschrijving van het onderliggende proces, zodat auditors direct context hebben en beslissers inzicht houden in de impact op dienstverlening. Het script defender-connection-filtering.ps1 vormt het hart van de technische uitvoering. Het script opent een beveiligde sessie richting Exchange Online met moderne authenticatie, valideert de ingevoerde lijsten op overlappingen, creëert of wijzigt de connection filter policy en logt elke actie in een csv-rapport dat naar het SOC wordt gestuurd. Foutafhandeling zorgt ervoor dat ongeldige IP-ranges worden geweigerd voordat ze impact hebben. Daarnaast registreert het script welke beheerder de actie heeft uitgevoerd, zodat de audittrail volledig is. Het script ondersteunt ook een dry-runmodus waarmee wijzigingen eerst worden gesimuleerd en vergeleken met de huidige configuratie, zodat onverwachte effecten zichtbaar worden voordat ze in productie komen. Waar nodig worden meerdere policies uitgerold, bijvoorbeeld wanneer verschillende bedrijfsonderdelen eigen uitzonderingen hanteren maar wel onder hetzelfde governancekader moeten vallen. Na het toepassen van de configuratie volgt een uitgebreide verificatie. Er worden testmails verstuurd vanaf toegestane en geblokkeerde adressen, waarbij de respons van de service wordt gemonitord via de message trace en near real-time telemetry. De resultaten worden vergeleken met de ontwerpspecificaties en gedeeld met zowel het security operations center als het functioneel beheer. Eventuele afwijkingen leiden direct tot een update van de lijsten of tot een extra risicoanalyse wanneer blijkt dat een partner verkeer via onverwachte routes laat lopen. Pas wanneer alle testcases zijn geslaagd en de change advisory board akkoord geeft, wordt de policy breed geactiveerd. Naast technische tests wordt een communicatiescenario doorlopen waarin wordt geoefend hoe servicedesks eindgebruikers informeren wanneer berichten worden geweigerd, zodat de impact op de organisatie beperkt blijft. Tot slot wordt de implementatie afgerond met documentatie en kennisoverdracht. Het definitieve configuratiebestand wordt opgeslagen in een versiebeheersysteem, de scriptuitvoer wordt gekoppeld aan het wijzigingsnummer en de servicedesk ontvangt instructies over de nieuwe foutcodes die eindgebruikers kunnen ervaren. Tevens worden dashboards in Microsoft Defender opgesteld zodat het SOC direct indicatoren ziet wanneer verkeer plotseling wordt geweigerd. Deze afsluitende activiteiten zorgen ervoor dat connection filtering niet slechts een technische wijziging is, maar een volwaardige beheerdienst met duidelijke verantwoordelijkheden en inzicht voor alle betrokken partijen. Lessons learned uit deze fase worden direct ingevoerd in het beheerproces, zodat toekomstige wijzigingen sneller en met minder risico worden uitgevoerd.

Gebruik PowerShell-script defender-connection-filtering.ps1 (functie Invoke-Monitoring) – Monitoren.

monitoring

Monitoring van connection filtering vereist continue zichtbaarheid in de e-mailketen zodat afwijkingen onmiddellijk worden opgespoord. Het security operations center configureert daarom near real-time alerts op basis van Defender for Office 365-telemetrie, message trace data en Exchange transport logs. Door deze bronnen te combineren ontstaat een volledig beeld van welke IP-adressen toegang proberen te krijgen, hoe vaak verbindingen worden geweigerd en of er plotselinge pieken optreden die kunnen wijzen op een gerichte aanval. De dashboards tonen niet alleen volumes maar ook context, zoals het betrokken organisatieonderdeel en het corresponderende wijzigingsnummer, zodat analisten snel kunnen beoordelen of gedrag legitiem is. Om het menselijk toezicht te versterken worden drempelwaarden ingesteld die rekening houden met normale schommelingen, bijvoorbeeld onderhoudsvensters bij ketenpartners of pieken tijdens belastingcampagnes. Wanneer het aantal geweigerde verbindingen boven het afgesproken venster uitkomt, genereert het systeem een ticket in het IT-servicebeheerplatform met een vooraf ingevulde checklist. Analisten controleren eerst of de bron-IP's zijn gewijzigd, of er recente aanpassingen zijn gedaan aan de allowlist en of Microsoft Threat Intelligence extra waarschuwingsniveaus heeft afgegeven. Deze werkwijze verkort de tijd tussen detectie en diagnose en voorkomt dat incidenten onnodig escaleren. Monitoring strekt zich ook uit tot de juistheid van documentatie en governance. Maandelijks wordt een rapportage opgesteld waarin nieuwe, aangepaste en verwijderde IP-regels worden afgezet tegen de formeel goedgekeurde changes. Afwijkingen worden automatisch gemarkeerd zodat de compliance officer kan nagaan of de wijziging wel via het juiste proces is verlopen. Daarnaast wordt gecontroleerd of vervaldatums van tijdelijke uitzonderingen in zicht komen; drie weken vooraf ontvangt de eigenaar een herinnering om te bevestigen of de uitzondering moet blijven bestaan. Zo wordt voorkomen dat tijdelijke maatregelen permanent worden zonder herbeoordeling. Het SOC maakt intensief gebruik van correlatie tussen connection filtering en andere beveiligingssignalen. Wanneer Microsoft Defender bijvoorbeeld een phishingcampagne detecteert, wordt automatisch nagegaan of de bron-IP's al op de blocklist staan. Zo niet, dan wordt een voorstel gegenereerd om de lijst uit te breiden en wordt het risico gedocumenteerd. Eveneens worden successen en false positives geregistreerd, zodat het team kan leren van casussen waarin legitieme partners per ongeluk zijn geweigerd. Deze feedback wordt meegestuurd in het wijzigingsproces en vormt input voor verbeteringen aan de selectiecriteria. Ten slotte omvat monitoring ook periodieke tests. Elk kwartaal wordt een gecontroleerde oefening uitgevoerd waarbij een testpartij verschillende IP-adressen gebruikt om mail te verzenden. De resultaten worden vergeleken met de ontwerpintentie en gedeeld met management om aan te tonen dat de maatregel nog steeds effectief is. Tijdens deze oefeningen worden ook de communicatielijnen getest; servicedesks en procesverantwoordelijken moeten kunnen aantonen dat zij weten hoe ze gebruikers informeren en incidenten escaleren. Door monitoring zo breed te definiëren ontstaat een gesloten kringloop van detectie, begrip, rapportage en verbetering. Naast deze reguliere processen wordt gebruikgemaakt van automatisering en AI-ondersteuning om verborgen patronen te detecteren. Defender-data wordt dagelijks geëxporteerd naar Microsoft Sentinel, waar analytische regels afwijkende combinaties van bronlanden, autonome systemen en mislukte verbindingen markeren. Wanneer zo'n regel wordt getriggerd ontvangt het SOC zowel de ruwe logverzameling als een samenvatting van mogelijke oorzaken, inclusief verwijzingen naar eerdere incidenten en gekoppelde changes. Analisten beoordelen vervolgens of aanvullende maatregelen nodig zijn, zoals het tijdelijk uitfaseren van een partner of het aanscherpen van DMARC-verplichtingen. Deze geavanceerde monitoring verlaagt de kans dat sluimerende dreigingen onopgemerkt blijven en geeft bestuurders vertrouwen dat connection filtering voortdurend wordt verfijnd.

Gebruik PowerShell-script defender-connection-filtering.ps1 (functie Invoke-Monitoring) – Controleren.

Remediatie

Remediatie start bij een duidelijke definitie van wat een fout scenario is. Dat kan een legitieme partner zijn die geen verbinding meer krijgt, een plotselinge stijging van spam ondanks bestaande filters of een incident waarbij een kwaadwillende een nieuw IP-adres inzet. Zodra een afwijking wordt vastgesteld registreert het SOC het issue in het ticketingsysteem en koppelt het aan het relevante connection filter. De eigenaar van de businessdienst wordt onmiddellijk geïnformeerd zodat wordt bevestigd of het verkeer toegestaan hoort te zijn. Deze eerste validatiestap voorkomt dat securityteams overhaast uitzonderingen toevoegen zonder dat de businesscontext helder is. Wanneer blijkt dat een wijziging nodig is, wordt een mini-change uitgevoerd volgens hetzelfde governancekader als bij reguliere wijzigingen. De benodigde informatie omvat het IP-adres of de range, het onderliggende proces, de verwachte duur en de risicoafweging. Bij blokkades wordt onderzocht of de bron wellicht via DMARC, SPF of DKIM kan worden gecontroleerd, zodat een meer duurzame oplossing mogelijk is dan een allowlist. Indien een additionele allowlistregel onvermijdelijk is, wordt direct een einddatum vastgelegd en wordt bepaald welk team verantwoordelijk is voor de opvolging. Deze aanpak borgt dat tijdelijke uitzonderingen niet onnodig lang blijven bestaan en dat elke stap herleidbaar is. Het script defender-connection-filtering.ps1 ondersteunt remediatie door zowel wijzigingen als verwijderingen te automatiseren. Beheerders leveren een bijgewerkte configuratiefile aan, waarna het script delta's berekent en alleen de noodzakelijke aanpassingen doorvoert. Hierdoor wordt voorkomen dat complete policies opnieuw moeten worden opgebouwd, wat de kans op fouten aanzienlijk reduceert. Het script genereert bovendien een wijzigingenlogboek dat automatisch wordt toegevoegd aan het incidentticket, inclusief de exacte tijdstempel, het account dat de wijziging heeft uitgevoerd en het resultaat van de validatie. Dit logboek is cruciaal voor forensisch onderzoek en voor audits die aantonen dat remediatie gecontroleerd verloopt. Na technische aanpassing volgt een verificatiefase waarbij opnieuw testmails worden verstuurd om te bevestigen dat het gewenste effect is bereikt. Daarbij wordt zowel inbound als outbound verkeer bekeken, omdat connection filtering invloed kan hebben op reply scenario's en op mails die via gedeelde infrastructuren lopen. Het SOC monitort gedurende minimaal 24 uur of het volume aan geweigerde verbindingen stabiliseert en of er geen nieuwe anomaliën optreden. Indien toch bijwerkingen ontstaan, wordt de wijziging teruggedraaid met de eerder opgeslagen configuratieback-up en wordt een alternatief scenario uitgewerkt. Gedurende het volledige remediatieproces blijft communicatie richting stakeholders essentieel. Servicedesks ontvangen een statusupdate, eindgebruikers krijgen waar nodig instructies over tijdelijke workarounds en management wordt geïnformeerd wanneer het incident een verhoogde impact heeft op dienstverlening richting burgers. Na afronding wordt een post-incident review gehouden waarin oorzaken, genomen maatregelen en aanbevelingen voor procesverbeteringen worden vastgelegd. Deze leerpunten voeden het ontwerp van toekomstige policies en zorgen ervoor dat connection filtering steeds volwassenere controlemechanismen biedt. Daarnaast moet het remediatieproces rekening houden met scenario's waarbij een allowlist zelf wordt misbruikt. Wanneer threat intelligence aangeeft dat een eerder vertrouwde partner is gecompromitteerd, wordt onmiddellijk onderzocht of hun IP-adressen misbruikt worden voor spoofing. Het SOC kan dan een noodprocedure starten waarbij verkeer tijdelijk via strengere scanning loopt of geheel wordt geblokkeerd terwijl de partner herstelwerkzaamheden uitvoert. Communicatieafspraken zorgen ervoor dat deze maatregelen juridisch worden afgestemd en dat bewijs voor eventuele claims beschikbaar blijft. Zo blijft remediatie niet beperkt tot ad-hocoplossingen maar vormt het een volwaardig crisisinstrument.

Gebruik PowerShell-script defender-connection-filtering.ps1 (functie Invoke-Remediation) – Herstellen.

Compliance en Auditing

Compliance vraagt om aantoonbaarheid dat connection filtering consistent, transparant en volgens wettelijke kaders wordt uitgevoerd. Voor de BIO-paragrafen over toegangsbeveiliging en logging betekent dit dat elke wijziging aan allow- en blocklijsten moet zijn herleidbaar tot een formele change inclusief risicoanalyse en managementgoedkeuring. Daarom wordt een digitaal dossier opgebouwd waarin het ontwerp, de goedkeuringsbesluiten, de export van de actuele configuratie en de resultaten van functionele tests zijn opgenomen. Dit dossier bevindt zich in het centrale kwaliteitsmanagementsysteem zodat auditors het kunnen raadplegen zonder afhankelijk te zijn van individuele beheerders. AVG-conformiteit vereist dat organisaties duidelijk kunnen uitleggen waarom bepaalde mailstromen prioriteit krijgen en hoe persoonsgegevens onderweg worden beschermd. Connection filtering kan ertoe leiden dat communicatie via alternatieve routes loopt of dat berichten tijdelijk worden vastgehouden. Daarom legt de privacy officer vast welke gegevens in de logs worden opgeslagen, hoe lang die blijven bestaan en hoe toegang tot logdata is geregeld. Door deze afspraken te combineren met een bewaartermijn van minimaal één jaar, zoals vereist voor auditbewijzen, ontstaat er een sluitende keten van verantwoordelijkheid. Voor auditdoeleinden is het belangrijk dat niet alleen de configuratie beschikbaar is, maar ook bewijs dat controles daadwerkelijk plaatsvonden. Elk kwartaal wordt een auditrapport gegenereerd met daarin de lijst van actieve IP-regels, de bijbehorende eigenaren, de vervaldatums en eventuele bevindingen tijdens monitoring. Dit rapport wordt besproken in het security governance overleg en vormt input voor de jaarcyclus van de interne auditdienst. Eventuele afwijkingen worden geregistreerd als verbetervoorstellen en opgevolgd via het reguliere risicoregister, zodat auditors duidelijk kunnen zien welke maatregelen zijn genomen en welke nog openstaan. Ten slotte moet de organisatie aantonen dat connection filtering aansluit op sectorale kaders zoals ENSIA, BIO Thema-uitwerkingen en Rijksbrede Cloudnormenkaders. Dit betekent dat bewijsstukken vaak in meerdere rapportages terugkomen, bijvoorbeeld in het ENSIA-verantwoordingsdocument voor gemeenten of in de kwartaalrapportage richting departementale auditcomités. Door standaardtemplates te gebruiken en koppelingen te leggen naar het centrale configuratieregister, wordt dubbele administratie voorkomen en blijft de informatie up-to-date. De combinatie van technische logging, formele besluitvorming en heldere rapportages maakt dat connection filtering niet alleen effectief is, maar ook volledig verdedigbaar tijdens externe inspecties. Naast formele audits wordt ook vooruitgekeken naar aankomende wet- en regelgeving, zoals de NIS2-richtlijn en de Wet beveiliging netwerk- en informatiesystemen. De organisatie beschrijft hoe connection filtering bijdraagt aan de naleving van eisen rondom detectie, respons en rapportage, zodat toekomstige assessments minder inspanning vragen. Er worden scenario's uitgewerkt waarin auditbewijzen binnen achtenveertig uur moeten worden aangeleverd, bijvoorbeeld bij toezicht door de Autoriteit Persoonsgegevens of Agentschap Telecom. Door deze voorbereidingen te combineren met periodieke zelfevaluaties blijft de documentatie actueel en kunnen toezichthouders vertrouwen op de geborgde werking van de maatregel. Ook richting externe toezichthouders wordt transparant gecommuniceerd over de werking van connection filtering. Wanneer ketenpartners of leveranciers afhankelijk zijn van uitzonderingen, ontvangen zij een samenvatting van de beveiligingsmaatregelen en de verwachte herbeoordelingsdatum, zodat hun eigen audits kunnen aansluiten. Daarnaast wordt vastgelegd hoe logbestanden veilig worden gedeeld bij een onderzoek en welke encryptiestandaarden daarvoor gelden. Deze afspraken bewijzen dat de organisatie niet alleen intern orde op zaken heeft, maar ook de ketenverantwoordelijkheid serieus neemt.

Compliance & Frameworks

• BIO: 14.02 - BIO Baseline Informatiebeveiliging Overheid - 14.02 - Email security

Automation

Gebruik het onderstaande PowerShell script om deze security control te monitoren en te implementeren. Het script bevat functies voor zowel monitoring (-Monitoring) als remediation (-Remediation).

Risico zonder implementatie

Management Samenvatting

Connection filtering in Microsoft Defender voor Office 365 creëert een aanvullende controlelaag waarbij alleen vooraf gevalideerde IP-adressen mail mogen aanbieden. Door uitzonderingen te documenteren, scripts te gebruiken voor configuratie en monitoring te koppelen aan SOC-processen, minimaliseer je het risico op misconfiguraties en houd je kritieke ketenpartners bereikbaar zonder de automatische reputatiediensten van Microsoft te omzeilen.

• Implementatietijd: 6 uur
• FTE required: 0.1 FTE