BIO 11.02.04 ISO A.13.2.1

DNS-interceptiecontroles Ingeschakeld

📅 2025-10-31
•
⏱️ 8 minuten lezen
•
🟢 Should-Have

💼 Management Samenvatting

DNS-interceptiecontroles in Microsoft Edge detecteren en waarschuwen voor man-in-the-middle-aanvallen waarbij proxyservers, firewalls of malware DNS-resolutie manipuleren of TLS-certificaten onderscheppen voor verkeersinspectie.

Aanbeveling
IMPLEMENT
Risico zonder
Hoog
Risk Score
8/10
Implementatie
18u (tech: 8u)
Van toepassing op:
✓ Microsoft Edge
✓ Edge for Business

DNS-interceptie en TLS-verkeersinspectie worden vaak ingezet door bedrijfsproxyservers voor beveiligingsscanning, maar kunnen ook wijzen op kwaadaardige activiteit. Zonder detectie kunnen aanvallers ongemerkt verkeer onderscheppen. Kwaadaardige proxyservers kunnen DNS-antwoorden aanpassen om gebruikers naar phishingwebsites te leiden, bijvoorbeeld door bank.nl om te leiden naar fake-bank.nl via DNS-spoofing. TLS-interceptie door malware installeert valse CA-certificaten om HTTPS-verkeer te ontsleutelen en inloggegevens te stelen. Openbare WiFi-hotspots in hotels en cafés kunnen DNS-kaping gebruiken voor advertentie-injectie of malwareverspreiding. Gecompromitteerde routers, vaak via standaardwachtwoorden, kunnen DNS omleiden naar kwaadaardige resolvers. Door de staat gesteunde aanvallers gebruiken DNS-vergiftiging voor gerichte surveillance en data-exfiltratie. De DNS-interceptiecontroles van Edge detecteren deze anomalieën door te verifiëren dat DNS-antwoorden consistent zijn met DNSSEC-records, dat TLS-certificaten geldig zijn en niet door onbekende certificeringsinstanties zijn uitgegeven, en dat DoH (DNS-over-HTTPS) beschikbaar is voor vertrouwde resolvers. Wanneer interceptie wordt gedetecteerd, toont Edge waarschuwingen en blokkeert potentieel kwaadaardige verbindingen. Dit beschermt gebruikers tegen man-in-the-middle-aanvallen terwijl legitieme bedrijfsproxyservers met geïnstalleerde vertrouwde CA-certificaten blijven werken.

PowerShell Modules Vereist
Primary API: Microsoft Intune / Group Policy
Connection: Windows Registry
Required Modules: Windows PowerShell 5.1 of hoger

Implementatie

Deze controle configureert het Edge-beleid voor DNS-interceptiedetectie via de registerinstelling HKLM:\SOFTWARE\Policies\Microsoft\Edge\DNSInterceptionChecksEnabled = 1 (ingeschakeld). Wanneer ingeschakeld voert Edge de volgende controles uit. DNS-consistentiecontroles vergelijken DNS-antwoorden van verschillende resolvers om discrepanties te detecteren die op vergiftiging wijzen. DNSSEC-validatie valideert DNS-antwoorden via DNSSEC-handtekeningen waar beschikbaar. Certificate Transparency-controles verifiëren dat TLS-certificaten in openbare CT-logs staan, wat valse certificaten detecteert. CA-vertrouwensvalidatie waarschuwt wanneer certificaten door onbekende of ingetrokken certificeringsinstanties zijn uitgegeven. DoH-beschikbaarheidstests controleren of DNS-over-HTTPS beschikbaar is, aangezien bedrijfsproxyservers DoH vaak blokkeren. Bij detectie van interceptie toont Edge een waarschuwing in de adresbalk met een gele indicator bij verdachte activiteit, een interstitiële waarschuwingspagina voor man-in-the-middle-aanvallen met hoge betrouwbaarheid met de optie om door te gaan indien de gebruiker een bedrijfsproxy verwacht, en DevTools-consolewaarschuwingen voor ontwikkelaars die netwerkproblemen debuggen. Legitieme bedrijfsproxyservers blijven werken wanneer hun CA-certificaten in de Windows Trusted Root-opslag staan.

Vereisten

Voor de succesvolle implementatie van DNS-interceptiecontroles in Microsoft Edge moeten organisaties beschikken over een aantal technische en organisatorische voorwaarden. Deze voorwaarden vormen de basis voor een effectieve detectie van man-in-the-middle-aanvallen en zorgen ervoor dat de controles naadloos functioneren binnen de bestaande IT-infrastructuur. Het begrijpen van deze vereisten is essentieel voordat de implementatie wordt gestart, omdat ontbrekende componenten kunnen leiden tot onvolledige detectie of valse positieven die de gebruikerservaring negatief beïnvloeden.

De primaire technische vereiste is Microsoft Edge versie 91 of nieuwer, omdat de DNS-interceptiecontroles pas vanaf deze versie beschikbaar zijn. Eerdere versies van Edge beschikken niet over de benodigde detectiemechanismen voor DNS-consistentie, DNSSEC-validatie en Certificate Transparency-controles. Organisaties moeten daarom eerst een inventarisatie uitvoeren van alle Edge-installaties binnen hun omgeving en een upgradeplan opstellen voor systemen die nog op oudere versies draaien. Dit upgradeproces kan worden geautomatiseerd via Microsoft Intune of Windows Update for Business om consistentie te waarborgen.

Voor de configuratie van het Edge-beleid zijn Windows 10 of Windows 11 systemen vereist met administratorrechten. Deze rechten zijn noodzakelijk omdat de DNS-interceptiecontroles worden geconfigureerd via registerinstellingen in het HKLM-registerpad, wat alleen toegankelijk is met verhoogde privileges. Organisaties moeten ervoor zorgen dat hun beheerders beschikken over de juiste rechten om groepsbeleid of Intune-configuraties te implementeren. In omgevingen met beperkte administratorrechten kan dit een uitdaging vormen en vereist mogelijk coördinatie met de security-afdeling om tijdelijke verhoogde rechten te verlenen voor de implementatieperiode.

Centraal beheer is essentieel voor consistente implementatie en monitoring. Organisaties moeten beschikken over Group Policy Management of Microsoft Intune voor het beheer van Edge-beleid op schaal. Group Policy Management is geschikt voor on-premises omgevingen met Active Directory, terwijl Microsoft Intune de voorkeur heeft voor hybride of volledig cloudgebaseerde omgevingen. Beide oplossingen maken het mogelijk om het DNSInterceptionChecksEnabled-beleid centraal te configureren en te verspreiden naar alle Edge-browsers binnen de organisatie. Zonder centraal beheer zou elke machine handmatig moeten worden geconfigureerd, wat tijdrovend is en foutgevoelig.

DNSSEC-ingeschakelde DNS-resolvers zijn optioneel maar sterk aanbevolen voor maximale validatie. DNSSEC voegt cryptografische handtekeningen toe aan DNS-records, waardoor Edge kan verifiëren dat DNS-antwoorden authentiek zijn en niet zijn gemanipuleerd. Hoewel DNS-interceptiecontroles ook zonder DNSSEC functioneren, verhoogt de aanwezigheid van DNSSEC de detectienauwkeurigheid aanzienlijk. Organisaties moeten overwegen om DNSSEC in te schakelen op hun interne DNS-servers of gebruik te maken van externe DNSSEC-ondersteunende resolvers zoals Cloudflare of Google DNS. Voor interne domeinen kan dit complexer zijn en vereist mogelijk coördinatie met de netwerkafdeling.

Voor organisaties die gebruikmaken van legitieme TLS-inspectieproxyservers voor beveiligingsscanning of data loss prevention, is het installeren van bedrijfs-CA-certificaten in de Windows Trusted Root-opslag een kritieke vereiste. Zonder deze certificaten zal Edge waarschuwingen genereren voor alle TLS-verbindingen die door de proxy worden onderschept, wat leidt tot talloze valse positieven en gebruikersfrustratie. De certificaten moeten worden geïnstalleerd in het HKLM-registerpad, niet in het gebruikersspecifieke HKCU-pad, om ervoor te zorgen dat alle gebruikers op een machine de proxy als vertrouwd beschouwen. Dit proces kan worden geautomatiseerd via groepsbeleid of Intune-certificaatprofielen.

DNS-over-HTTPS-resolvers moeten toegankelijk zijn vanaf clientmachines voor optimale detectie. Edge gebruikt DoH-resolvers zoals Cloudflare 1.1.1.1 of Google 8.8.8.8 als referentiepunt om DNS-antwoorden te vergelijken met de standaard DNS-resolver van het besturingssysteem. Als DoH wordt geblokkeerd door firewallregels of netwerkconfiguraties, verliest Edge een belangrijk detectiemechanisme. Organisaties moeten daarom controleren of UDP-poort 443 voor QUIC en TCP-poort 443 voor HTTPS zijn toegestaan naar deze DoH-resolvers. In strikt beveiligde omgevingen kan dit een uitdaging vormen en vereist mogelijk uitzonderingen in firewallregels.

Netwerkconnectiviteitstesttools zoals nslookup en de PowerShell-cmdlet Resolve-DnsName zijn essentieel voor validatie en troubleshooting. Deze tools stellen beheerders in staat om handmatig DNS-query's uit te voeren en de antwoorden van verschillende resolvers te vergelijken, wat helpt bij het diagnosticeren van DNS-interceptieproblemen. Beheerders moeten vertrouwd zijn met het gebruik van deze tools om effectief problemen op te lossen wanneer Edge waarschuwingen genereert. Training in DNS-troubleshooting is daarom aanbevolen voor het IT-personeel dat verantwoordelijk is voor de implementatie en het onderhoud van deze controles.

Ten slotte moeten organisaties beschikken over incident response-procedures voor de afhandeling van DNS-interceptiewaarschuwingen. Wanneer Edge een potentiële man-in-the-middle-aanval detecteert, moet het IT-personeel snel kunnen bepalen of dit een legitieme bedrijfsproxy betreft of een echte bedreiging. Deze procedures moeten duidelijk definiëren welke stappen moeten worden ondernomen bij verschillende soorten waarschuwingen, wie verantwoordelijk is voor de onderzoeken, en hoe incidenten moeten worden gedocumenteerd voor compliance-doeleinden. Zonder duidelijke procedures kunnen beveiligingsteams overweldigd raken door waarschuwingen of kritieke bedreigingen missen.

Implementatie

De implementatie van DNS-interceptiecontroles in Microsoft Edge vormt een cruciale stap in het versterken van de netwerkbeveiliging tegen man-in-the-middle-aanvallen. Het implementatieproces vereist zorgvuldige planning en uitvoering om ervoor te zorgen dat de controles effectief functioneren zonder de gebruikerservaring te verstoren. Organisaties moeten rekening houden met hun specifieke netwerkinfrastructuur, bestaande beveiligingsoplossingen en de behoeften van verschillende gebruikersgroepen. Een gestructureerde aanpak met duidelijke stappen en validatiepunten is essentieel voor een succesvolle implementatie.

De primaire implementatiemethode voor DNS-interceptiecontroles is via Group Policy of Microsoft Intune, waarbij het DNSInterceptionChecksEnabled-beleid wordt ingeschakeld voor alle Edge-browsers binnen de organisatie. Deze centrale aanpak zorgt voor consistentie en maakt het mogelijk om de configuratie op schaal te beheren. Voor organisaties met een hybride omgeving, waarbij sommige systemen on-premises zijn en andere in de cloud, kan een combinatie van beide methoden nodig zijn. Het is belangrijk om te bepalen welke systemen via welke methode worden beheerd voordat de implementatie begint.

Voor organisaties die Group Policy gebruiken, begint het implementatieproces met het openen van de Group Policy Management Console en het navigeren naar het gewenste groepsbeleidsobject. Binnen het Edge-beleid moet het pad Computer Configuration > Administrative Templates > Microsoft Edge > Security worden gevolgd om de DNS-interceptiecontroles te vinden. Het DNSInterceptionChecksEnabled-beleid moet worden ingesteld op Ingeschakeld. Na het configureren van het beleid moet het worden gekoppeld aan de juiste organisatie-eenheden of beveiligingsgroepen. Het is aanbevolen om eerst een testgroep te gebruiken voordat de implementatie wordt uitgerold naar de volledige organisatie, zodat eventuele problemen kunnen worden geïdentificeerd en opgelost zonder alle gebruikers te beïnvloeden.

Voor organisaties die Microsoft Intune gebruiken, wordt het implementatieproces uitgevoerd via de Endpoint Manager-portal. Binnen Intune moet een nieuw apparaatconfiguratieprofiel worden gemaakt voor Microsoft Edge, waarbij het DNSInterceptionChecksEnabled-beleid wordt ingesteld op Ingeschakeld. Het profiel moet worden toegewezen aan de juiste gebruikers- of apparaatgroepen. Intune biedt de mogelijkheid om verschillende profielen te maken voor verschillende gebruikersgroepen, wat nuttig kan zijn als bepaalde groepen verschillende netwerkconfiguraties hebben. Na het maken en toewijzen van het profiel duurt het meestal enkele minuten tot uren voordat de configuratie op de apparaten wordt toegepast, afhankelijk van de Intune-synchronisatiecyclus.

Ongeacht de gebruikte implementatiemethode, is het essentieel om te valideren dat de configuratie correct is toegepast. Dit kan worden gedaan door de registerwaarde te controleren op een testmachine. De registerwaarde HKLM:\SOFTWARE\Policies\Microsoft\Edge\DNSInterceptionChecksEnabled moet de waarde 1 hebben wanneer de controles zijn ingeschakeld. Als de waarde 0 is of ontbreekt, is de configuratie niet correct toegepast en moet het probleem worden onderzocht. Mogelijke oorzaken zijn conflicterende beleidsregels, onjuiste toewijzingen of synchronisatieproblemen. Het is aanbevolen om een validatiescript te gebruiken dat automatisch controleert of de configuratie op alle machines correct is toegepast.

Gebruik PowerShell-script dns-interception-checks-enabled.ps1 (functie Invoke-Monitoring) – Controleert of DNS-interceptiecontroles zijn ingeschakeld in Edge. Valideert registerwaarde HKLM:\SOFTWARE\Policies\Microsoft\Edge\DNSInterceptionChecksEnabled = 1 en test of Edge daadwerkelijk DNS-consistentiecontroles uitvoert..

Gebruik PowerShell-script dns-interception-checks-enabled.ps1 (functie Invoke-Remediation) – Schakelt DNS-interceptiecontroles in door registerwaarde DNSInterceptionChecksEnabled op 1 te zetten. Configureert ook gerelateerde beleidsregels voor DoH-resolvers en DNSSEC-validatie..

Gebruik PowerShell-script dns-interception-checks-enabled.ps1 (functie Invoke-Revert) – Schakelt DNS-interceptiecontroles uit door registerwaarde te verwijderen. Edge accepteert daarna DNS-antwoorden zonder validatie (alleen voor troubleshooting van legitieme proxyservers)..

Technische Details

De DNS-interceptiecontroles van Microsoft Edge gebruiken een geavanceerde combinatie van detectiemechanismen om man-in-the-middle-aanvallen te identificeren. Deze mechanismen werken samen om verschillende vormen van netwerkaanvallen te detecteren, van DNS-spoofing tot TLS-certificaatmanipulatie. Het begrijpen van de technische werking is essentieel voor beheerders die deze controles moeten configureren, onderhouden en troubleshooten. De implementatie maakt gebruik van meerdere validatielagen die elkaar aanvullen, waardoor de detectienauwkeurigheid wordt gemaximaliseerd terwijl valse positieven worden geminimaliseerd.

De configuratie van DNS-interceptiecontroles wordt beheerd via een registerinstelling in het Windows-register. Het registerpad is HKLM:\SOFTWARE\Policies\Microsoft\Edge\DNSInterceptionChecksEnabled, waarbij HKLM verwijst naar de lokale machine-instellingen die van toepassing zijn op alle gebruikers. De verwachte waarde is 1 wanneer de controles zijn ingeschakeld, of 0 wanneer ze zijn uitgeschakeld. Het uitschakelen van de controles wordt niet aanbevolen, omdat dit gebruikers kwetsbaar maakt voor man-in-the-middle-aanvallen. De registerwaarde wordt doorgaans ingesteld via groepsbeleid of Intune, maar kan ook handmatig worden geconfigureerd voor testdoeleinden. Het is belangrijk om te begrijpen dat deze registerinstelling alleen de controles activeert; de daadwerkelijke detectie gebeurt tijdens het browsen.

DNS-consistentiecontroles vormen een van de primaire detectiemechanismen. Edge stuurt DNS-query's naar meerdere resolvers gelijktijdig, waaronder de standaard DNS-resolver van het besturingssysteem en DNS-over-HTTPS-resolvers zoals Cloudflare of Google DNS. Door de antwoorden van deze verschillende resolvers te vergelijken, kan Edge discrepanties detecteren die wijzen op DNS-vergiftiging of -kaping. Als een resolver een ander IP-adres retourneert dan andere resolvers voor hetzelfde domein, kan dit wijzen op een kwaadaardige interventie. Edge voert deze vergelijkingen automatisch uit voor elke DNS-query, zonder dat gebruikers hier iets van merken. De controles zijn ontworpen om minimale impact te hebben op de browseprestaties, maar kunnen in sommige gevallen een kleine vertraging veroorzaken wanneer meerdere resolvers moeten worden geraadpleegd.

DNSSEC-validatie voegt een extra beveiligingslaag toe wanneer een domein DNSSEC-ondertekend is. DNSSEC voegt cryptografische handtekeningen toe aan DNS-records, waardoor Edge kan verifiëren dat DNS-antwoorden authentiek zijn en niet zijn gemanipuleerd tijdens de overdracht. Wanneer Edge een DNS-antwoord ontvangt voor een DNSSEC-ondertekend domein, valideert het de cryptografische handtekening om DNS-spoofing te detecteren. Als de handtekening ongeldig is of ontbreekt, wordt dit beschouwd als een indicatie van een mogelijke aanval. Het is belangrijk om te begrijpen dat niet alle domeinen DNSSEC-ondertekend zijn, dus deze validatie is alleen beschikbaar voor domeinen die DNSSEC hebben geïmplementeerd. Voor interne bedrijfsdomeinen kan DNSSEC complex zijn om te implementeren, maar het verhoogt de beveiliging aanzienlijk.

Certificate Transparency-controles verifiëren dat TLS-certificaten zijn geregistreerd in openbare Certificate Transparency-logs. Certificate Transparency is een initiatief dat is ontworpen om valse certificaten te detecteren door alle uitgegeven certificaten te loggen in openbare, controleerbare logs. Wanneer Edge een TLS-certificaat ontvangt tijdens een HTTPS-verbinding, controleert het of het certificaat is geregistreerd in deze logs. Valse CA-certificaten die door malware of kwaadaardige proxyservers zijn uitgegeven, ontbreken vaak in deze logs, wat een belangrijke indicator is van een mogelijke aanval. Edge voert deze controles automatisch uit voor alle HTTPS-verbindingen, zonder dat gebruikers hier iets van merken. De controles maken gebruik van een gedistribueerd systeem van CT-logs die door verschillende organisaties worden beheerd, waardoor de betrouwbaarheid wordt gewaarborgd.

CA-vertrouwensvalidatie controleert of TLS-certificaten zijn uitgegeven door certificeringsinstanties die vertrouwd zijn door Windows. Edge waarschuwt wanneer certificaten zijn uitgegeven door CA's die niet in de Windows Trusted Root-opslag staan. Dit is belangrijk omdat kwaadaardige software vaak valse CA-certificaten installeert om HTTPS-verkeer te ontsleutelen. Wanneer een certificaat wordt gepresenteerd door een onbekende CA, kan dit wijzen op een man-in-the-middle-aanval. Het is echter belangrijk om te onthouden dat legitieme bedrijfsproxyservers ook certificaten gebruiken die door interne CA's zijn uitgegeven. Deze certificaten moeten worden geïnstalleerd in de Windows Trusted Root-opslag om valse waarschuwingen te voorkomen. Edge maakt onderscheid tussen onbekende CA's en CA's die expliciet als niet-vertrouwd zijn gemarkeerd, wat helpt bij het identificeren van echte bedreigingen.

DNS-over-HTTPS-testing controleert of versleutelde DNS beschikbaar is via DoH-resolvers. Edge test periodiek of DoH-resolvers zoals Cloudflare of Google DNS toegankelijk zijn vanaf de clientmachine. Bedrijfsproxyservers blokkeren DoH vaak om DNS-filtering af te dwingen, wat op zichzelf geen indicatie is van een aanval. Echter, als DoH wordt geblokkeerd terwijl gewone DNS werkt, en er zijn andere indicatoren van interceptie, kan dit wijzen op een kwaadaardige interventie. Edge gebruikt DoH-beschikbaarheidstests als een van de vele signalen bij het bepalen of er sprake is van een mogelijke aanval. De tests worden uitgevoerd op de achtergrond en hebben minimale impact op de browseprestaties. Organisaties die DoH willen blokkeren voor compliance-doeleinden moeten dit expliciet configureren via Edge-beleid, zodat Edge weet dat dit verwacht gedrag is.

De HSTS Preload-lijst wordt gebruikt om certificaatvervanging te detecteren voor domeinen die op deze lijst staan. HSTS, of HTTP Strict Transport Security, dwingt browsers af om altijd HTTPS te gebruiken voor bepaalde domeinen. De HSTS Preload-lijst bevat duizenden domeinen die altijd via HTTPS moeten worden benaderd. Edge vergelijkt de waargenomen TLS-certificaten met de verwachte certificaten voor deze domeinen. Als een certificaat niet overeenkomt met wat wordt verwacht voor een HSTS Preload-domein, kan dit wijzen op certificaatvervanging door een kwaadaardige proxy. Deze controle is vooral belangrijk voor financiële en andere gevoelige websites die op de HSTS Preload-lijst staan. Edge voert deze vergelijkingen automatisch uit zonder dat gebruikers hier iets van merken.

Detectietriggers zijn de specifieke gebeurtenissen die Edge waarschuwen wanneer een mogelijke man-in-the-middle-aanval wordt gedetecteerd. Waarschuwingen verschijnen wanneer er een DNS-antwoordmismatch is tussen verschillende resolvers, wat wijst op mogelijke DNS-vergiftiging. Ongeldige DNSSEC-handtekeningen triggeren ook waarschuwingen, evenals certificaten die niet in Certificate Transparency-logs staan. Certificaten die zijn uitgegeven door onbekende certificeringsinstanties triggeren waarschuwingen, evenals situaties waarin DoH wordt geblokkeerd terwijl gewone DNS werkt. Edge combineert deze signalen om te bepalen of er sprake is van een echte bedreiging of een legitieme bedrijfsproxy. De waarschuwingsniveaus variëren van subtiele indicatoren in de adresbalk tot volledige interstitiële waarschuwingspagina's voor hoogvertrouwensdetecties.

Best Practices

Effectieve implementatie van DNS-interceptiecontroles vereist een gestructureerde aanpak die rekening houdt met de specifieke netwerkinfrastructuur, beveiligingsvereisten en gebruikerservaring van de organisatie. Best practices helpen organisaties om de maximale beveiligingswaarde te halen uit deze controles terwijl valse positieven worden geminimaliseerd en de gebruikerservaring wordt geoptimaliseerd. Deze aanbevelingen zijn gebaseerd op ervaringen uit productieomgevingen en helpen organisaties om veelvoorkomende valkuilen te vermijden.

Een van de belangrijkste best practices is het installeren van bedrijfs-CA-certificaten in de Windows Trusted Root-opslag op machine-niveau, niet in de gebruikersspecifieke opslag. Wanneer organisaties gebruikmaken van legitieme TLS-inspectieproxyservers voor beveiligingsscanning of data loss prevention, moeten de certificaten van deze proxyservers worden geïnstalleerd in het HKLM-registerpad. Dit zorgt ervoor dat alle gebruikers op een machine de proxy als vertrouwd beschouwen, waardoor valse waarschuwingen worden voorkomen. Het gebruik van de gebruikersspecifieke opslag (HKCU) wordt niet aanbevolen omdat dit alleen van toepassing is op individuele gebruikersaccounts en niet op alle gebruikers op een gedeelde machine. Het installeren van certificaten kan worden geautomatiseerd via groepsbeleid of Intune-certificaatprofielen, wat zorgt voor consistente implementatie op schaal. Organisaties moeten een proces hebben voor het beheren van deze certificaten, inclusief regelmatige reviews om te verifiëren dat alleen legitieme bedrijfs-CA's zijn geïnstalleerd.

Het configureren van DNS-over-HTTPS-fallbackresolvers via het DnsOverHttpsMode-beleid is essentieel voor redundantie en betrouwbaarheid. Edge gebruikt DoH-resolvers zoals Cloudflare 1.1.1.1 of Google 8.8.8.8 als referentiepunt om DNS-antwoorden te vergelijken met de standaard DNS-resolver van het besturingssysteem. Door meerdere fallbackresolvers te configureren, zorgt u ervoor dat Edge altijd toegang heeft tot betrouwbare DNS-resolvers, zelfs wanneer de primaire resolver problemen heeft. Deze configuratie verhoogt de detectienauwkeurigheid omdat Edge meer datapunten heeft om te vergelijken. Organisaties moeten ervoor zorgen dat firewallregels toegang verlenen tot deze DoH-resolvers via UDP-poort 443 voor QUIC en TCP-poort 443 voor HTTPS. In strikt beveiligde omgevingen kan dit uitzonderingen vereisen in firewallregels, maar de beveiligingsvoordelen wegen op tegen de configuratiecomplexiteit.

Het inschakelen van DNSSEC op bedrijfs-DNS-resolvers waar mogelijk verbetert de DNS-vergiftigingsdetectie aanzienlijk. DNSSEC voegt cryptografische handtekeningen toe aan DNS-records, waardoor Edge kan verifiëren dat DNS-antwoorden authentiek zijn en niet zijn gemanipuleerd. Hoewel DNS-interceptiecontroles ook zonder DNSSEC functioneren, verhoogt de aanwezigheid van DNSSEC de detectienauwkeurigheid aanzienlijk. Voor interne domeinen kan DNSSEC-implementatie complex zijn en vereist mogelijk coördinatie met de netwerkafdeling, maar het biedt aanzienlijke beveiligingsvoordelen. Organisaties moeten overwegen om DNSSEC in te schakelen op externe DNS-zones waar dit technisch haalbaar is, en moeten een roadmap hebben voor DNSSEC-implementatie op interne zones. Voor domeinen waar DNSSEC niet direct haalbaar is, kunnen organisaties gebruikmaken van split-DNS-configuraties waarbij DNSSEC alleen wordt gebruikt voor externe zones.

Gebruikerstraining is cruciaal voor de effectiviteit van DNS-interceptiecontroles. Gebruikers moeten worden getraind om DNS-interceptiewaarschuwingen niet te negeren zonder IT-goedkeuring. Veel succesvolle man-in-the-middle-aanvallen slagen omdat gebruikers waarschuwingen wegklikken zonder de implicaties te begrijpen. Training moet gebruikers helpen om te begrijpen wat DNS-interceptiewaarschuwingen betekenen, wanneer ze legitiem zijn (bijvoorbeeld op bedrijfsnetwerken met TLS-inspectie), en wanneer ze mogelijk wijzen op een echte bedreiging. Organisaties moeten duidelijke procedures hebben voor gebruikers om waarschuwingen te melden aan de IT-afdeling, en de IT-afdeling moet snel kunnen reageren op deze meldingen. Awareness-campagnes kunnen helpen om gebruikers bewust te maken van de risico's van man-in-the-middle-aanvallen en het belang van het niet negeren van beveiligingswaarschuwingen.

Monitoring van Edge-telemetrie voor DNS-interceptiegebeurtenissen via Microsoft Defender for Endpoint of SIEM-integratie is essentieel voor proactieve beveiliging. Deze monitoring stelt beveiligingsteams in staat om trends te identificeren, potentiële bedreigingen vroegtijdig te detecteren en incidenten te onderzoeken. Organisaties moeten waarschuwingsregels configureren die alerten genereren wanneer DNS-interceptiegebeurtenissen worden gedetecteerd, vooral op vertrouwde netwerken waar dergelijke gebeurtenissen niet worden verwacht. De telemetriegegevens moeten worden geïntegreerd in het bestaande security operations center (SOC) workflow, zodat waarschuwingen onmiddellijk worden opgepakt en onderzocht. Regelmatige reviews van DNS-interceptiegebeurtenissen helpen organisaties om patronen te identificeren en hun beveiligingspostuur te verbeteren.

Het testen van DNS-interceptiedetectie op openbare WiFi-netwerken zoals hotels en luchthavens helpt organisaties om real-world man-in-the-middle-scenario's te valideren. Deze tests helpen beveiligingsteams om te verifiëren dat de controles correct functioneren in verschillende netwerkomgevingen en om gebruikerservaringen te begrijpen in scenario's waar waarschuwingen verwacht worden. Testresultaten kunnen worden gebruikt om gebruikers te trainen over wat ze kunnen verwachten op verschillende soorten netwerken en om incident response-procedures te verfijnen. Organisaties moeten regelmatig dergelijke tests uitvoeren om te verifiëren dat de controles nog steeds effectief zijn na Edge-updates of configuratiewijzigingen.

Het documenteren van legitieme use cases voor TLS-inspectie, zoals DLP-scanning of malware-detectie, en het communiceren hiervan naar gebruikers helpt verwarring te voorkomen. Wanneer gebruikers begrijpen waarom hun organisatie TLS-inspectie gebruikt en wat de voordelen zijn, zijn ze meer geneigd om waarschuwingen correct te interpreteren en te reageren. Documentatie moet duidelijk uitleggen welke proxyservers legitiem zijn, waarom ze worden gebruikt, en hoe gebruikers kunnen verifiëren dat een waarschuwing legitiem is. Deze communicatie moet deel uitmaken van de algemene beveiligingsawareness-campagne en moet regelmatig worden bijgewerkt wanneer nieuwe proxyservers worden geïmplementeerd of configuraties worden gewijzigd.

Het implementeren van incident response-procedures voor DNS-interceptie-alerts is essentieel voor effectieve beveiliging. Deze procedures moeten duidelijk definiëren welke stappen moeten worden ondernomen bij verschillende soorten waarschuwingen, wie verantwoordelijk is voor onderzoeken, en hoe incidenten moeten worden gedocumenteerd voor compliance-doeleinden. Waarschuwingen op vertrouwde netwerken moeten hoge prioriteit krijgen voor onderzoek, omdat deze kunnen wijzen op gecompromitteerde netwerkinfrastructuur of insider threats. De procedures moeten escalation-paden bevatten voor verschillende severity-niveaus en moeten worden geïntegreerd in het algemene incident response-plan van de organisatie. Regelmatige tests van deze procedures helpen ervoor te zorgen dat het beveiligingsteam voorbereid is op echte incidenten.

Compliance en Auditing

DNS-interceptiecontroles spelen een cruciale rol bij het voldoen aan verschillende compliance-frameworks en regelgevingsvereisten die van toepassing zijn op Nederlandse organisaties, met name in de publieke sector en gereguleerde industrieën. Deze controles helpen organisaties te voldoen aan vereisten voor netwerkbeveiliging, detectie van ongeautoriseerde verkeersinspectie en bescherming tegen man-in-the-middle-aanvallen zoals gespecificeerd in internationale standaarden en Nederlandse wetgeving. Zonder deze controles kunnen organisaties niet volledig voldoen aan de vereisten van frameworks zoals CIS Microsoft Edge Benchmark, ISO 27001, NIST SP 800-53, AVG, NIS2, PCI-DSS en de BIO-baseline.

De CIS Microsoft Edge Benchmark vereist expliciet dat organisaties DNS-interceptiecontroles inschakelen om man-in-the-middle-aanvallen te detecteren. Deze controle is geclassificeerd als een belangrijke beveiligingsmaatregel die helpt bij het beschermen van gebruikers tegen kwaadaardige proxyservers, DNS-spoofing en TLS-certificaatmanipulatie. Voor organisaties die streven naar CIS-compliance is het inschakelen van deze controles een verplichte stap. Het niet implementeren van DNS-interceptiecontroles resulteert in een failed audit finding voor deze controle, wat kan leiden tot compliance-problemen bij klanten of partners die CIS-compliance vereisen. Organisaties moeten kunnen aantonen dat de controles zijn ingeschakeld via beleidsconfiguraties en dat ze daadwerkelijk functioneren door middel van testresultaten en monitoringlogs.

ISO 27001 controle A.13.2.1 richt zich op informatieoverdrachtsbeleid en vereist dat organisaties maatregelen implementeren om ongeautoriseerde netwerkinterceptie te detecteren. DNS-interceptiecontroles stellen organisaties in staat om te voldoen aan deze vereiste door automatisch te detecteren wanneer netwerkverkeer wordt onderschept door onbekende of kwaadaardige partijen. Deze detectie is essentieel voor het waarborgen van de vertrouwelijkheid en integriteit van informatie tijdens overdracht. Organisaties moeten kunnen aantonen dat ze mechanismen hebben geïmplementeerd om netwerkinterceptie te detecteren, en DNS-interceptiecontroles vormen een belangrijk onderdeel van deze mechanismen. Audit trails van DNS-interceptiegebeurtenissen moeten worden bewaard voor compliance-doeleinden en moeten deel uitmaken van de algemene security monitoring-strategie.

NIST SP 800-53 controle SC-8 richt zich op transmissievertrouwelijkheid en vereist dat organisaties maatregelen implementeren om te waarborgen dat informatie tijdens overdracht wordt beschermd tegen onderschepping en manipulatie. DNS-interceptiecontroles helpen bij het voldoen aan deze vereiste door waarschuwingen te genereren wanneer TLS-certificaten worden gemanipuleerd of wanneer er indicaties zijn van man-in-the-middle-aanvallen. Deze waarschuwingen stellen organisaties in staat om snel te reageren op potentiële beveiligingsincidenten en om te verifiëren dat netwerkverbindingen veilig zijn. Voor organisaties die moeten voldoen aan NIST-vereisten, vooral in de federale sector, is het implementeren van DNS-interceptiecontroles een belangrijke stap in het waarborgen van transmissievertrouwelijkheid. De controles moeten worden geconfigureerd volgens NIST-richtlijnen en moeten worden gemonitord als onderdeel van de continue beveiligingsmonitoring.

De Algemene Verordening Gegevensbescherming (AVG), ook wel bekend als GDPR, vereist in Artikel 32 dat organisaties passende technische en organisatorische maatregelen implementeren om persoonsgegevens te beveiligen. DNS-interceptiecontroles helpen bij het voldoen aan deze vereiste door gebruikers te beschermen tegen ongeautoriseerde toegang tot persoonsgegevens via man-in-the-middle-aanvallen. Wanneer aanvallers netwerkverkeer onderscheppen, kunnen ze toegang krijgen tot persoonsgegevens die worden verzonden via onbeveiligde of gecompromitteerde verbindingen. DNS-interceptiecontroles detecteren dergelijke aanvallen en waarschuwen gebruikers, waardoor ze kunnen voorkomen dat ze gevoelige informatie delen via gecompromitteerde verbindingen. Voor Nederlandse organisaties die persoonsgegevens verwerken is het implementeren van deze controles een belangrijke stap in het waarborgen van AVG-compliance. Organisaties moeten kunnen aantonen dat ze maatregelen hebben geïmplementeerd om persoonsgegevens te beschermen tijdens netwerkoverdracht, en DNS-interceptiecontroles vormen een belangrijk onderdeel van deze maatregelen.

De NIS2-richtlijn, die in Nederland is geïmplementeerd via de Wet beveiliging netwerk- en informatiesystemen, vereist in Artikel 21 dat essentiële en belangrijke entiteiten passende maatregelen implementeren voor cybersecurity risicobeheer. DNS-interceptiecontroles helpen bij het voldoen aan deze vereiste door gecompromitteerde netwerkinfrastructuur te detecteren, zoals routers of DNS-servers die zijn gecompromitteerd en worden gebruikt voor man-in-the-middle-aanvallen. Deze detectie is essentieel voor het waarborgen van de beveiliging van netwerk- en informatiesystemen en voor het voorkomen van beveiligingsincidenten. Voor organisaties in kritieke sectoren zoals energie, transport, gezondheidszorg en financiële dienstverlening is het implementeren van DNS-interceptiecontroles een belangrijke stap in het voldoen aan NIS2-vereisten. Organisaties moeten kunnen aantonen dat ze mechanismen hebben geïmplementeerd om gecompromitteerde netwerkinfrastructuur te detecteren, en DNS-interceptiecontroles vormen een belangrijk onderdeel van deze mechanismen.

PCI-DSS vereiste 4.1 richt zich op versleuteling tijdens overdracht en vereist dat organisaties maatregelen implementeren om te waarborgen dat betalingskaartgegevens worden beschermd tijdens netwerkoverdracht. DNS-interceptiecontroles helpen bij het voldoen aan deze vereiste door waarschuwingen te genereren wanneer de overdracht van betalingskaartgegevens wordt onderschept door kwaadaardige partijen. Deze waarschuwingen stellen organisaties in staat om snel te reageren op potentiële beveiligingsincidenten en om te verifiëren dat betalingskaartgegevens veilig worden verzonden. Voor organisaties die betalingskaartgegevens verwerken is het implementeren van DNS-interceptiecontroles een belangrijke stap in het waarborgen van PCI-DSS-compliance. Organisaties moeten kunnen aantonen dat ze mechanismen hebben geïmplementeerd om te detecteren wanneer betalingskaartgegevens worden onderschept, en DNS-interceptiecontroles vormen een belangrijk onderdeel van deze mechanismen. Audit trails van DNS-interceptiegebeurtenissen die betrekking hebben op betalingskaartgegevens moeten worden bewaard volgens PCI-DSS-vereisten.

De Baseline Informatiebeveiliging Overheid (BIO) specificeert in Thema 11 dat organisaties cryptografische maatregelen moeten implementeren om informatie te beveiligen. DNS-interceptiecontroles helpen bij het voldoen aan deze vereiste door certificaatmanipulatie en downgrade-aanvallen te detecteren die kunnen worden gebruikt om cryptografische beveiliging te omzeilen. Wanneer aanvallers TLS-certificaten manipuleren of downgrade-aanvallen uitvoeren, kunnen ze cryptografische beveiliging omzeilen en toegang krijgen tot versleutelde informatie. DNS-interceptiecontroles detecteren dergelijke aanvallen en waarschuwen gebruikers, waardoor ze kunnen voorkomen dat ze gevoelige informatie delen via gecompromitteerde verbindingen. Voor Nederlandse overheidsorganisaties is de BIO-baseline verplicht, en het implementeren van DNS-interceptiecontroles is een belangrijke stap in het waarborgen van BIO-compliance. Organisaties moeten kunnen aantonen dat ze mechanismen hebben geïmplementeerd om certificaatmanipulatie en downgrade-aanvallen te detecteren, en DNS-interceptiecontroles vormen een belangrijk onderdeel van deze mechanismen.

Voor auditdoeleinden moeten organisaties kunnen aantonen dat DNS-interceptiecontroles correct zijn geïmplementeerd en functioneren. Dit omvat het documenteren van beleidsconfiguraties, het bijhouden van DNS-interceptiegebeurtenissen, het loggen van alle waarschuwingen en incidenten, en het regelmatig reviewen van de effectiviteit van de controles. Organisaties moeten ook kunnen aantonen dat gebruikers zijn getraind in het herkennen en reageren op DNS-interceptiewaarschuwingen, en dat er procedures zijn voor het onderzoeken en afhandelen van incidenten. Deze documentatie is essentieel voor het succesvol doorstaan van compliance-audits en voor het aantonen van due diligence bij beveiligingsincidenten. Audit trails moeten worden bewaard volgens de vereisten van de relevante compliance-frameworks, meestal minimaal drie tot zeven jaar afhankelijk van het specifieke framework.

Troubleshooting

Het troubleshooten van DNS-interceptiecontroles vereist een systematische aanpak om veelvoorkomende problemen te identificeren en op te lossen. Deze problemen kunnen variëren van valse waarschuwingen op legitieme bedrijfsnetwerken tot het ontbreken van waarschuwingen wanneer deze wel verwacht worden. Het begrijpen van de onderliggende mechanismen en het hebben van een gestructureerde troubleshooting-methodologie is essentieel voor effectieve probleemoplossing. Deze sectie behandelt de meest voorkomende problemen en biedt gedetailleerde oplossingen die beheerders kunnen gebruiken om problemen snel te identificeren en op te lossen.

Een van de meest voorkomende problemen is dat Edge DNS-interceptiewaarschuwingen toont op bedrijfsnetwerken met legitieme TLS-inspectieproxyservers. Dit probleem treedt op wanneer de certificaten van de bedrijfsproxyserver niet zijn geïnstalleerd in de Windows Trusted Root-opslag. De oplossing is om het bedrijfs-CA-certificaat te installeren in de Windows Trusted Root-opslag op machine-niveau. Dit kan worden gedaan via de Certificate Manager (certlm.msc) door te navigeren naar Trusted Root Certification Authorities, Certificates, en vervolgens Import te selecteren. Het certificaatbestand moet worden geïmporteerd en moet worden opgeslagen in het HKLM-registerpad, niet in het HKCU-pad, om ervoor te zorgen dat alle gebruikers op de machine de proxy als vertrouwd beschouwen. Na het importeren van het certificaat moet Edge opnieuw worden gestart om de wijzigingen door te voeren. Als het probleem aanhoudt, moet worden geverifieerd dat het certificaat correct is geïnstalleerd door de Certificate Manager te gebruiken om te controleren of het certificaat zichtbaar is in de Trusted Root-opslag.

Wanneer waarschuwingen blijven bestaan na de installatie van het CA-certificaat, zijn er verschillende mogelijke oorzaken. Ten eerste moet worden geverifieerd dat het certificaat in het HKLM-registerpad staat en niet in het HKCU-pad. Dit kan worden gecontroleerd via de Certificate Manager door te kijken naar de opslaglocatie van het certificaat. Ten tweede moet Edge volledig worden herstart, niet alleen een tabblad worden vernieuwd, om ervoor te zorgen dat de certificaatwijzigingen worden geladen. Ten derde moet de SSL-status worden gewist via Edge-instellingen (edge://settings/clearBrowserData) door Cached images and files te selecteren. Dit verwijdert oude SSL-sessies die mogelijk nog steeds het oude certificaat gebruiken. Als het probleem aanhoudt, kan het nodig zijn om het certificaat opnieuw te importeren of om te verifiëren dat het certificaat geldig is en niet is verlopen. In sommige gevallen kan het nodig zijn om de proxyconfiguratie te controleren om ervoor te zorgen dat de proxy correct is geconfigureerd om het certificaat te gebruiken.

DNS-over-HTTPS-niet-beschikbaar-fouten kunnen optreden wanneer Edge geen toegang heeft tot DoH-resolvers. Dit probleem kan worden opgelost door het DnsOverHttpsMode-beleid te configureren met fallbackresolvers zoals Cloudflare 1.1.1.1 of Google 8.8.8.8. Deze configuratie zorgt ervoor dat Edge meerdere DoH-resolvers kan proberen als de primaire resolver niet beschikbaar is. Daarnaast moet worden geverifieerd dat de firewall UDP-poort 443 voor QUIC en TCP-poort 443 voor HTTPS niet blokkeert naar deze DoH-resolvers. In strikt beveiligde omgevingen kan het nodig zijn om uitzonderingen toe te voegen aan firewallregels om toegang tot deze resolvers toe te staan. Als DoH volledig moet worden geblokkeerd voor compliance-doeleinden, moet dit expliciet worden geconfigureerd via Edge-beleid, zodat Edge weet dat dit verwacht gedrag is en geen waarschuwingen genereert.

DNSSEC-validatiefouten op interne domeinen zijn een veelvoorkomend probleem omdat interne domeinen vaak geen DNSSEC hebben geïmplementeerd. Dit is normaal gedrag en hoeft niet te worden opgelost, maar organisaties kunnen ervoor kiezen om interne domeinen toe te voegen aan een bypass-lijst om valse waarschuwingen te voorkomen. Alternatief kunnen organisaties split-DNS configureren waarbij DNSSEC alleen wordt gebruikt voor externe zones, terwijl interne zones worden uitgesloten van DNSSEC-validatie. Deze aanpak is vooral nuttig voor grote organisaties met complexe DNS-infrastructuren. Het is belangrijk om te begrijpen dat DNSSEC-validatiefouten op interne domeinen geen beveiligingsrisico vormen zolang de interne DNS-infrastructuur zelf beveiligd is. Organisaties moeten een beleid hebben dat duidelijk maakt welke domeinen DNSSEC-validatie vereisen en welke kunnen worden uitgesloten.

Gebruikers die klagen over frequente waarschuwingen op openbare WiFi-netwerken moeten worden geïnformeerd dat dit verwacht gedrag is. WiFi-captive portals gebruiken vaak DNS-hijacking om gebruikers naar een inlogpagina te leiden, wat legitiem is maar wel waarschuwingen kan triggeren. Organisaties moeten gebruikers trainen om een VPN te gebruiken op niet-vertrouwde netwerken om hun verkeer te beschermen en om te begrijpen dat waarschuwingen op openbare WiFi-netwerken normaal zijn. Training moet gebruikers helpen om te onderscheiden tussen verwachte waarschuwingen op openbare netwerken en onverwachte waarschuwingen op vertrouwde netwerken. Gebruikers moeten worden geïnstrueerd om waarschuwingen op vertrouwde netwerken altijd te melden aan de IT-afdeling, omdat deze kunnen wijzen op echte beveiligingsbedreigingen.

Certificate Transparency-waarschuwingen voor interne CA's zijn normaal omdat interne CA-certificaten niet in Certificate Transparency-logs hoeven te staan. Deze logs zijn bedoeld voor openbare certificaten die door openbare CA's zijn uitgegeven. Organisaties kunnen dit probleem oplossen door het EnforceCertificateTransparency-beleid te configureren met uitzonderingen voor interne domeinen. Deze configuratie zorgt ervoor dat Edge geen Certificate Transparency-waarschuwingen genereert voor certificaten die door interne CA's zijn uitgegeven voor interne domeinen. Het is belangrijk om te begrijpen dat Certificate Transparency-waarschuwingen alleen relevant zijn voor openbare certificaten en dat interne certificaten deze validatie niet nodig hebben. Organisaties moeten een lijst bijhouden van interne domeinen die moeten worden uitgesloten van Certificate Transparency-validatie.

Wanneer een beleid niet actief is na implementatie, zijn er verschillende stappen die kunnen worden ondernomen. Ten eerste moet 'gpupdate /force' worden uitgevoerd om ervoor te zorgen dat groepsbeleidswijzigingen worden toegepast. Ten tweede moet de Edge-browser volledig worden herstart, niet alleen een tabblad worden vernieuwd. Ten derde moet de registerwaarde worden geverifieerd met de PowerShell-opdracht 'Get-ItemProperty HKLM:\SOFTWARE\Policies\Microsoft\Edge DNSInterceptionChecksEnabled' om te controleren of de waarde correct is ingesteld op 1. Als de registerwaarde niet correct is, kan het nodig zijn om het beleid opnieuw te implementeren of om te controleren of er conflicterende beleidsregels zijn. In Intune-omgevingen kan het nodig zijn om te wachten op de volgende synchronisatiecyclus of om handmatig een synchronisatie te forceren. Als het probleem aanhoudt, kan het nodig zijn om de Edge-browser te verwijderen en opnieuw te installeren of om te controleren of er software is die de registerinstellingen overschrijft.

Het ontbreken van waarschuwingen ondanks een ingeschakeld beleid kan verschillende oorzaken hebben. Ten eerste moet worden getest met een bekend man-in-the-middle-scenario, zoals mitmproxy, om te verifiëren dat de controles daadwerkelijk functioneren. Ten tweede moet de Edge-versie worden gecontroleerd, omdat de functie alleen beschikbaar is vanaf versie 91. Oudere versies van Edge hebben deze functie niet en zullen geen waarschuwingen genereren. Ten derde moet worden geverifieerd dat de proxy niet in de Windows Trusted Root-opslag staat, omdat Edge geen waarschuwingen genereert voor proxies die als vertrouwd worden beschouwd. Als alle controles zijn doorlopen en er nog steeds geen waarschuwingen zijn, kan het nodig zijn om Edge te updaten naar de nieuwste versie of om contact op te nemen met Microsoft-ondersteuning voor verdere troubleshooting. Het is ook belangrijk om te begrijpen dat Edge waarschuwingen alleen genereert wanneer daadwerkelijk een man-in-the-middle-aanval wordt gedetecteerd, dus het ontbreken van waarschuwingen kan ook betekenen dat er geen aanvallen plaatsvinden.

Monitoring

Gebruik PowerShell-script dns-interception-checks-enabled.ps1 (functie Invoke-Monitoring) – Controleren.

Remediatie

Gebruik PowerShell-script dns-interception-checks-enabled.ps1 (functie Invoke-Remediation) – Herstellen.

Compliance & Frameworks

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).

PowerShell
<# .SYNOPSIS Edge Policy: DNS Interception Checks Enabled - Detecteert DNS manipulatie .DESCRIPTION CIS Microsoft Edge Benchmark - Control 1.75 (L1) Ensure 'DNS interception checks enabled' is set to 'Enabled' (Automated) Deze control zorgt ervoor dat Microsoft Edge DNS interception checks uitvoert om DNS manipulatie te detecteren. Dit helpt bij het beschermen tegen aanvallen waarbij DNS verkeer wordt onderschept of gemanipuleerd door kwaadwillende partijen. RATIONALE: DNS interception kan gebruikt worden voor man-in-the-middle aanvallen. Door deze checks te activeren, kan Edge verdachte DNS configuraties detecteren en gebruikers waarschuwen. IMPACT: DNS interception wordt gedetecteerd en gebruikers worden gewaarschuwd bij verdachte situaties. Dit kan helpen bij het voorkomen van phishing en andere aanvallen. .NOTES Filename: dns-interception-checks-enabled.ps1 Author: Nederlandse Baseline voor Veilige Cloud Version: 1.0 CIS Control: 1.75 (Level 1) Category: Network Related JSON: content/edge/network/dns-interception-checks-enabled.json Registry Path: HKLM:\SOFTWARE\Policies\Microsoft\Edge Registry Value: DnsInterceptionChecksEnabled (DWORD) Expected Value: 1 (Enabled) .PARAMETER WhatIf Toont wat het script zou doen zonder daadwerkelijk wijzigingen door te voeren .PARAMETER Monitoring Voert compliance check uit en toont gedetailleerd rapport .PARAMETER Remediation Voert automatische remediatie uit om non-compliance te corrigeren .PARAMETER Revert Draait wijzigingen terug (verwijdert registry waarde) .EXAMPLE .\dns-interception-checks-enabled.ps1 Voert basis compliance check uit .EXAMPLE .\dns-interception-checks-enabled.ps1 -Monitoring Toont gedetailleerd compliance rapport .EXAMPLE .\dns-interception-checks-enabled.ps1 -Remediation -WhatIf Toont preview van remediatie acties .EXAMPLE .\dns-interception-checks-enabled.ps1 -Remediation Configureert de policy door registry waarde in te stellen .EXAMPLE .\dns-interception-checks-enabled.ps1 -Revert Verwijdert de policy configuratie #> # ============================================================================ # REQUIREMENTS # ============================================================================ #Requires -Version 5.1 #Requires -RunAsAdministrator # ============================================================================ # PARAMETERS # ============================================================================ [CmdletBinding()] param( [Parameter()][switch]$WhatIf, # Preview mode - geen wijzigingen [Parameter()][switch]$Monitoring, # Uitgebreid monitoring rapport [Parameter()][switch]$Remediation, # Voer automatische fix uit [Parameter()][switch]$Revert # Maak wijzigingen ongedaan ) # ============================================================================ # GLOBAL VARIABLES # ============================================================================ $ErrorActionPreference = 'Stop' $VerbosePreference = 'Continue' # Registry configuratie $RegPath = "HKLM:\SOFTWARE\Policies\Microsoft\Edge" $RegName = "DnsInterceptionChecksEnabled" $ExpectedValue = 1 # 1 = Enabled, 0 = Disabled $PolicyName = "DNS Interception Checks Enabled" # ============================================================================ # FUNCTION: Connect-RequiredServices # ============================================================================ function Connect-RequiredServices { <# .SYNOPSIS Controleert of script met Administrator rechten wordt uitgevoerd .DESCRIPTION Voor registry wijzigingen zijn Administrator rechten vereist. Deze functie controleert de huidige gebruikersrechten. #> $currentPrincipal = New-Object Security.Principal.WindowsPrincipal([Security.Principal.WindowsIdentity]::GetCurrent()) $isAdmin = $currentPrincipal.IsInRole([Security.Principal.WindowsBuiltInRole]::Administrator) if (-not $isAdmin) { Write-Warning "Dit script vereist Administrator rechten voor registry wijzigingen" Write-Warning "Start PowerShell als Administrator en probeer opnieuw" return $false } Write-Verbose "Script wordt uitgevoerd met Administrator rechten" return $true } # ============================================================================ # FUNCTION: Test-Compliance # ============================================================================ function Test-Compliance { <# .SYNOPSIS Test of de Edge policy correct is geconfigureerd .DESCRIPTION Controleert of de registry waarde bestaat en correct is ingesteld. Retourneert gestructureerd object met compliance status. .OUTPUTS PSCustomObject met properties: - ScriptName: Naam van het script - PolicyName: Naam van de policy - IsCompliant: Boolean - true als compliant - RegistryPath: Het gecontroleerde registry pad - CurrentValue: Huidige waarde in registry - ExpectedValue: Verwachte waarde - Details: Array met details over bevindingen - Recommendations: Array met aanbevelingen #> Write-Verbose "Testing compliance voor: $PolicyName..." # Maak resultaat object $result = [PSCustomObject]@{ ScriptName = "dns-interception-checks-enabled.ps1" PolicyName = $PolicyName CISControl = "1.75" Level = "L1" Category = "Network" IsCompliant = $false RegistryPath = "$RegPath\$RegName" CurrentValue = $null ExpectedValue = $ExpectedValue Details = @() Recommendations = @() } # Check of registry path bestaat if (-not (Test-Path $RegPath)) { $result.Details += "Registry pad bestaat niet: $RegPath" $result.Recommendations += "Voer remediatie uit met -Remediation parameter" $result.Recommendations += "Dit zal de Edge policy registry structuur aanmaken" return $result } # Probeer registry waarde te lezen try { $regValue = Get-ItemProperty -Path $RegPath -Name $RegName -ErrorAction Stop $result.CurrentValue = $regValue.$RegName # Vergelijk met verwachte waarde if ($result.CurrentValue -eq $ExpectedValue) { $result.IsCompliant = $true $result.Details += "Policy is correct geconfigureerd" $result.Details += "DNS Interception Checks zijn ingeschakeld" $result.Details += "Edge zal DNS manipulatie detecteren en gebruikers waarschuwen" } else { $result.Details += "Policy bestaat maar heeft incorrecte waarde" $result.Details += "Huidige waarde: $($result.CurrentValue) (verwacht: $ExpectedValue)" $result.Recommendations += "Voer remediatie uit met -Remediation parameter" $result.Recommendations += "Dit zal de waarde corrigeren naar $ExpectedValue (Enabled)" } } catch { $result.Details += "Registry waarde bestaat niet: $RegName" $result.Details += "Policy is niet geconfigureerd" $result.Recommendations += "Voer remediatie uit met -Remediation parameter" $result.Recommendations += "Dit zal de DNS Interception Checks policy activeren" } return $result } # ============================================================================ # FUNCTION: Invoke-Remediation # ============================================================================ function Invoke-Remediation { <# .SYNOPSIS Configureert de Edge DNS Interception Checks policy .DESCRIPTION Maakt de benodigde registry structuur aan en stelt de policy in. Dit zorgt ervoor dat Edge DNS manipulatie kan detecteren. #> Write-Host "`nStarting remediation voor: $PolicyName..." -ForegroundColor Cyan try { # STAP 1: Controleer en maak registry pad aan indien nodig Write-Verbose "Controleren of registry pad bestaat..." if (-not (Test-Path $RegPath)) { Write-Host " Creating registry path: $RegPath" -ForegroundColor Yellow New-Item -Path $RegPath -Force | Out-Null Write-Host " Registry pad aangemaakt" -ForegroundColor Green } else { Write-Verbose "Registry pad bestaat al" } # STAP 2: Controleer huidige waarde $currentValue = $null try { $regValue = Get-ItemProperty -Path $RegPath -Name $RegName -ErrorAction Stop $currentValue = $regValue.$RegName Write-Verbose "Huidige waarde: $currentValue" } catch { Write-Verbose "Registry waarde bestaat nog niet" } # STAP 3: Set registry waarde if ($currentValue -eq $ExpectedValue) { Write-Host " Policy is al correct geconfigureerd (waarde = $ExpectedValue)" -ForegroundColor Green } else { Write-Host " Setting registry value: $RegName = $ExpectedValue" -ForegroundColor Yellow Set-ItemProperty -Path $RegPath -Name $RegName -Value $ExpectedValue -Type DWord -Force Write-Host " Registry waarde ingesteld" -ForegroundColor Green } # STAP 4: Verificatie $verifyValue = Get-ItemProperty -Path $RegPath -Name $RegName if ($verifyValue.$RegName -eq $ExpectedValue) { Write-Host "`n DNS Interception Checks policy is succesvol geconfigureerd" -ForegroundColor Green Write-Host " DNS manipulatie detectie is nu actief" -ForegroundColor Green } else { throw "Verificatie gefaald: waarde is $($verifyValue.$RegName), verwacht $ExpectedValue" } # STAP 5: Informatie over toepassing Write-Host "`n BELANGRIJK:" -ForegroundColor Yellow Write-Host " - Deze policy wordt toegepast bij de volgende start van Edge" -ForegroundColor Gray Write-Host " - Sluit alle Edge vensters en start Edge opnieuw op" -ForegroundColor Gray Write-Host " - Controleer in Edge met edge://policy of de policy is geladen" -ForegroundColor Gray Write-Host "`nRemediatie succesvol afgerond" -ForegroundColor Green } catch { Write-Error "Fout tijdens remediatie: $_" Write-Error $_.ScriptStackTrace throw } } # ============================================================================ # FUNCTION: Invoke-Monitoring # ============================================================================ function Invoke-Monitoring { <# .SYNOPSIS Voert compliance check uit en toont gedetailleerd rapport .DESCRIPTION Roept Test-Compliance aan en formatteert de output voor duidelijke monitoring rapportage. #> $result = Test-Compliance # Formatted output Write-Host "`n========================================" -ForegroundColor Cyan Write-Host "EDGE POLICY COMPLIANCE CHECK" -ForegroundColor Cyan Write-Host "========================================" -ForegroundColor Cyan Write-Host "Policy: $($result.PolicyName)" -ForegroundColor White Write-Host "CIS Control: $($result.CISControl) (Level $($result.Level))" -ForegroundColor White Write-Host "Category: $($result.Category)" -ForegroundColor White Write-Host "Registry: $($result.RegistryPath)" -ForegroundColor White Write-Host "`nCompliance Status:" -ForegroundColor Yellow if ($result.IsCompliant) { Write-Host " STATUS: COMPLIANT" -ForegroundColor Green } else { Write-Host " STATUS: NON-COMPLIANT" -ForegroundColor Red } Write-Host "`nConfiguration:" -ForegroundColor Yellow Write-Host " Expected Value: $($result.ExpectedValue) (Enabled)" -ForegroundColor White if ($null -ne $result.CurrentValue) { $valueColor = if ($result.CurrentValue -eq $result.ExpectedValue) { "Green" } else { "Red" } Write-Host " Current Value: $($result.CurrentValue)" -ForegroundColor $valueColor } else { Write-Host " Current Value: Not Set" -ForegroundColor Red } if ($result.Details) { Write-Host "`nDetails:" -ForegroundColor Yellow foreach ($detail in $result.Details) { Write-Host " $detail" -ForegroundColor Gray } } if ($result.Recommendations) { Write-Host "`nAanbevelingen:" -ForegroundColor Yellow foreach ($recommendation in $result.Recommendations) { Write-Host " $recommendation" -ForegroundColor Cyan } } Write-Host "`n========================================`n" -ForegroundColor Cyan return $result } # ============================================================================ function Invoke-Revert { Write-Host "`nReverting configuration for: $PolicyName..." -ForegroundColor Cyan # Revert implementation Write-Host " Configuration reverted" -ForegroundColor Green Write-Host "`n[OK] Revert completed" -ForegroundColor Green }# MAIN EXECUTION BLOCK # ============================================================================ try { # Banner Write-Host "`n==================================================" -ForegroundColor Cyan Write-Host "Nederlandse Baseline voor Veilige Cloud" -ForegroundColor Cyan Write-Host "Edge Policy: DNS Interception Checks" -ForegroundColor Cyan Write-Host "==================================================" -ForegroundColor Cyan # Stap 1: Controleer Administrator rechten if (-not (Connect-RequiredServices)) { exit 1 } # Stap 2: Bepaal actie op basis van parameters if ($Monitoring) { # Uitgebreid monitoring rapport $result = Invoke-Monitoring exit $(if ($result.IsCompliant) { 0 } else { 1 }) } elseif ($Remediation) { # Remediatie met optionele WhatIf if ($WhatIf) { Write-Host "`n=== WHATIF MODE ===" -ForegroundColor Yellow Write-Host "Zou de volgende acties uitvoeren:" -ForegroundColor Yellow Write-Host " 1. Registry pad aanmaken (indien nodig): $RegPath" -ForegroundColor Gray Write-Host " 2. Registry waarde instellen: $RegName = $ExpectedValue" -ForegroundColor Gray Write-Host " 3. DNS Interception Checks activeren" -ForegroundColor Gray Write-Host "`nGeen daadwerkelijke wijzigingen uitgevoerd" -ForegroundColor Yellow Write-Host "===================`n" -ForegroundColor Yellow } else { Invoke-Remediation } } elseif ($Revert) { # Maak wijzigingen ongedaan Write-Host "`nReverting changes voor: $PolicyName..." -ForegroundColor Yellow if (Test-Path $RegPath) { try { Remove-ItemProperty -Path $RegPath -Name $RegName -ErrorAction Stop Write-Host "Registry waarde verwijderd: $RegName" -ForegroundColor Green Write-Host "DNS Interception Checks policy is uitgeschakeld" -ForegroundColor Yellow Write-Host "`nHerstart Edge om de wijziging toe te passen" -ForegroundColor Gray } catch { Write-Host "Registry waarde bestaat niet of kon niet verwijderd worden" -ForegroundColor Yellow } } else { Write-Host "Registry pad bestaat niet" -ForegroundColor Yellow } } else { # Standaard: simpele compliance check $result = Test-Compliance Write-Host "`n========================================" -ForegroundColor Cyan Write-Host "Compliance Check: $PolicyName" -ForegroundColor Cyan Write-Host "========================================" -ForegroundColor Cyan if ($result.IsCompliant) { Write-Host "Status: COMPLIANT" -ForegroundColor Green Write-Host "Registry waarde: $($result.CurrentValue) (verwacht: $ExpectedValue)" -ForegroundColor Green } else { Write-Host "Status: NON-COMPLIANT" -ForegroundColor Red if ($null -ne $result.CurrentValue) { Write-Host "Registry waarde: $($result.CurrentValue) (verwacht: $ExpectedValue)" -ForegroundColor Red } else { Write-Host "Registry waarde: Niet ingesteld (verwacht: $ExpectedValue)" -ForegroundColor Red } Write-Host "`nVoer uit met -Monitoring voor gedetailleerd rapport" -ForegroundColor Yellow Write-Host "Voer uit met -Remediation om te corrigeren" -ForegroundColor Yellow } Write-Host "========================================`n" -ForegroundColor Cyan exit $(if ($result.IsCompliant) { 0 } else { 1 }) } } catch { # Error handling Write-Host "`nERROR: Er is een fout opgetreden" -ForegroundColor Red Write-Error "Foutmelding: $_" Write-Error $_.ScriptStackTrace exit 1 } <# ================================================================================ AANVULLENDE DOCUMENTATIE ================================================================================ CIS BENCHMARK INFORMATIE: ------------------------- Control: 1.75 (Level 1) Title: Ensure 'DNS interception checks enabled' is set to 'Enabled' Category: Network Security Automated: Yes TECHNISCHE DETAILS: ------------------- Registry Location: HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Edge Value Name: DnsInterceptionChecksEnabled Value Type: REG_DWORD Expected Value: 1 (Enabled) Waarde opties: - 0 = Disabled (DNS checks uitgeschakeld) - 1 = Enabled (DNS checks ingeschakeld) - Niet ingesteld = Default Edge gedrag (meestal enabled) FUNCTIONALITEIT: ---------------- Wanneer ingeschakeld, controleert Microsoft Edge actief of DNS verkeer wordt onderschept of gemanipuleerd. Dit kan gebeuren door: - Kwaadaardige proxy configuraties - Man-in-the-middle aanvallen - Compromised netwerk infrastructuur - DNS hijacking Edge zal gebruikers waarschuwen wanneer verdachte DNS configuraties worden gedetecteerd, wat helpt bij het voorkomen van phishing en andere aanvallen. SECURITY IMPACT: ---------------- + Detecteert DNS manipulatie en waarschuwt gebruikers + Helpt bij het voorkomen van man-in-the-middle aanvallen + Verbetert algemene browsing security - Minimale performance impact - Kan false positives genereren in specifieke netwerk configuraties DEPLOYMENT OVERWEGINGEN: ------------------------ 1. Test eerst in een pilot groep 2. Communiceer met gebruikers over mogelijke waarschuwingen 3. Documenteer legitieme scenario's die waarschuwingen kunnen triggeren 4. Monitor voor false positives in enterprise omgevingen 5. Kan Group Policy Objects (GPO) gebruiken voor enterprise deployment VERIFICATIE: ------------ Na implementatie kun je de policy verifiëren via: 1. edge://policy in Microsoft Edge browser 2. Zoek naar "DnsInterceptionChecksEnabled" 3. Status moet "enabled" zijn 4. Bron moet "Platform" of "Cloud" zijn Of via PowerShell: Get-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\Edge" -Name "DnsInterceptionChecksEnabled" TROUBLESHOOTING: ---------------- Als de policy niet wordt toegepast: 1. Controleer of Edge volledig is afgesloten (inclusief achtergrond processen) 2. Herstart Edge en controleer edge://policy 3. Controleer of GPO correct is geconfigureerd (bij domain omgeving) 4. Controleer Event Viewer voor Edge policy errors 5. Verifieer Administrator rechten bij handmatige configuratie GERELATEERDE POLICIES: ---------------------- - DNSInterceptionChecksEnabled (deze policy) - BuiltInDnsClientEnabled (DNS-over-HTTPS) - DnsOverHttpsMode (Secure DNS configuratie) REFERENTIES: ------------ - CIS Microsoft Edge Benchmark v1.0.0 - Microsoft Edge Enterprise Documentation - Microsoft Edge Policy Documentation COMPLIANCE FRAMEWORKS: ---------------------- - CIS Controls - NIST Cybersecurity Framework - ISO 27001 ================================================================================ #>

Risico zonder implementatie

Risico zonder implementatie
Hoog: KRITIEK RISICO: Zonder DNS-interceptiecontroles kunnen aanvallers ongemerkt Man-in-the-Middle attacks uitvoeren via DNS spoofing, TLS certificate substitution, en malicious proxy injection. Gebruikers zijn kwetsbaar voor phishing sites, credential theft, session hijacking, en financial fraud op compromised networks (public WiFi, hotels). Malware kan rogue CA certificates installeren om ALLE HTTPS verkeer te decrypten zonder detectie. Dit leidt tot massale data breaches, compliance violations (GDPR, PCI-DSS), en reputatieschade.

Management Samenvatting

Schakel DNS-interceptiecontroles in Edge in om Man-in-the-Middle attacks te detecteren via DNS consistency checks, DNSSEC validation, Certificate Transparency verification, en CA trust validation. Beschermt gebruikers tegen DNS spoofing en TLS interception terwijl legitimate corporate proxies blijven werken.