Private Network Requests Geblokkeerd

Websites op het publieke internet kunnen standaard verzoeken maken naar private IP-adressen binnen bedrijfsnetwerken (RFC 1918: 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16). Dit kan worden misbruikt voor poortscanning van interne netwerken, aanvallen op interne diensten zoals routers en printers met standaard wachtwoorden, gegevensexfiltratie via onbeveiligde interne API's, en CSRF-aanvallen op beheerinterfaces van IoT-apparaten. Veel interne apparaten hebben zwakke beveiliging omdat ze verondersteld worden alleen intern toegankelijk te zijn. Een kwaadaardige website kan de browser als proxy gebruiken om deze te compromitteren. Door private network requests te blokkeren, kunnen publieke sites niet langer communiceren met interne diensten, wat het aanvalsoppervlak aanzienlijk vermindert.

Implementatie

Deze maatregel configureert de Edge-beleidsregel PrivateNetworkRequestPolicy via de registerinstelling HKLM:\SOFTWARE\Policies\Microsoft\Edge\PrivateNetworkRequestsAllowed op 0 (Blokkeren). Wanneer geblokkeerd, kunnen websites op het publieke internet geen HTTP/HTTPS-verzoeken maken naar private IP-adressen in de bereiken 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 127.0.0.0/8 (localhost), 169.254.0.0/16 (link-local), en IPv6-equivalenten. Dit beschermt interne diensten tegen aanvallen die via de browser worden uitgevoerd. Legitieme interne webapplicaties blijven toegankelijk wanneer rechtstreeks benaderd, alleen verzoeken van publieke sites worden geblokkeerd.

Vereisten

Voor de succesvolle implementatie van deze beveiligingsmaatregel zijn verschillende technische en organisatorische vereisten van essentieel belang. Deze vereisten vormen de basis waarop de configuratie wordt gebouwd en bepalen in grote mate het succes van de implementatie. Organisaties moeten zorgvuldig nagaan of alle benodigde componenten aanwezig zijn voordat met de daadwerkelijke configuratie wordt begonnen. De primaire technische vereiste betreft de versie van Microsoft Edge die op de werkstations en servers wordt gebruikt. Deze beveiligingsmaatregel vereist minimaal Microsoft Edge versie 85 of hoger, omdat eerdere versies de benodigde policy-ondersteuning niet bevatten. Deze versie-eis is cruciaal omdat de Private Network Request Policy pas vanaf Edge 85 volledig wordt ondersteund volgens de W3C Private Network Access specificatie. Organisaties die nog werken met oudere versies van Edge of andere browsers zullen deze maatregel niet kunnen implementeren en moeten eerst een upgrade traject doorlopen. Het besturingssysteem vormt een tweede belangrijke technische vereiste. Voor de registry configuratie is Windows 10, Windows 11 of Windows Server vereist, omdat de registry-structuur waar de Edge policies worden opgeslagen specifiek is voor deze Windows-versies. De registry path HKLM:\SOFTWARE\Policies\Microsoft\Edge\PrivateNetworkRequestsAllowed is alleen beschikbaar en functioneel op deze moderne Windows-versies. Organisaties die nog werken met Windows 7 of Windows 8.1 kunnen deze maatregel niet implementeren en moeten overwegen om een migratie naar een ondersteunde Windows-versie te plannen. Administrator rechten vormen een derde kritieke vereiste voor de implementatie. Het wijzigen van registry-instellingen in de HKLM (HKEY_LOCAL_MACHINE) hive vereist lokale administrator rechten op het systeem. Dit betekent dat de persoon die de configuratie uitvoert beschikking moet hebben over een account met administrator privileges. In productieomgevingen wordt dit typisch opgelost door gebruik te maken van gecentraliseerde beheertools die deze rechten hebben, of door de configuratie uit te voeren tijdens de systeemdeployment wanneer administrator toegang nog beschikbaar is. Voor organisaties die werken met cloud-managed devices biedt Microsoft Intune een geoptimaliseerde oplossing voor gecentraliseerde policy deployment. Intune maakt het mogelijk om de Edge policy centraal te configureren en automatisch uit te rollen naar alle beheerde devices zonder dat handmatige interventie op elk individueel systeem nodig is. Dit vereist wel dat de organisatie beschikt over een Microsoft 365 licentie die Intune omvat, en dat de devices correct zijn ingeschreven in het Intune beheersysteem. De Intune-aanpak is bijzonder geschikt voor moderne hybride en cloud-first organisaties die streven naar zero-touch deployment. Voor traditionele on-premises omgevingen met Active Directory biedt de Group Policy Management Console een alternatieve methode voor domein-brede uitrol. Deze aanpak vereist dat de organisatie beschikt over een Active Directory domein en dat de Group Policy Management Console is geïnstalleerd op een beheerserver. Via Group Policy kunnen dezelfde registry-instellingen worden uitgerold naar alle computers in het domein, wat zorgt voor consistente configuratie zonder handmatige interventie. Deze methode is vooral geschikt voor organisaties met een traditionele IT-infrastructuur die nog niet volledig zijn overgestapt naar cloud-based management. Naast deze technische vereisten zijn er ook organisatorische overwegingen die aandacht vereisen. IT-beheerders moeten begrijpen wat de impact is van deze configuratie op de gebruikerservaring, hoewel deze impact minimaal zou moeten zijn voor normale browsing-activiteiten. Daarnaast moet er een proces zijn voor het testen van de configuratie voordat deze breed wordt uitgerold, om te voorkomen dat legitieme interne webapplicaties onbedoeld worden geblokkeerd. Organisaties moeten ook overwegen hoe ze zullen monitoren of de configuratie correct is toegepast en hoe ze zullen reageren op eventuele compliance-issues die worden gedetecteerd.

Implementatie

De implementatie van deze beveiligingsmaatregel kan worden uitgevoerd via verschillende methoden, afhankelijk van de infrastructuur en beheersfilosofie van de organisatie. Elke methode heeft zijn eigen voor- en nadelen, en de keuze hangt af van factoren zoals de omvang van de organisatie, de beschikbare beheertools, en de mate van centralisatie van het IT-beheer. Voor organisaties die werken met cloud-managed devices en Microsoft 365 is Microsoft Intune de aanbevolen implementatiemethode. Deze aanpak biedt de hoogste mate van automatisering en centralisatie, wat zorgt voor consistente configuratie across alle beheerde devices. De implementatie via Intune begint in het Microsoft Endpoint Manager admin center, waar beheerders navigeren naar de sectie Devices en vervolgens naar Configuration profiles. Hier kunnen nieuwe configuratieprofielen worden aangemaakt die specifiek zijn gericht op Windows 10 en latere versies van het besturingssysteem. Bij het aanmaken van een nieuw profiel selecteren beheerders het profile type Administrative Templates, wat toegang geeft tot een uitgebreide bibliotheek van Edge-beleidsinstellingen. Binnen deze bibliotheek navigeren beheerders naar de Microsoft Edge sectie en vervolgens naar de Network subcategorie. Hier vinden ze de policy genaamd "Private network access from websites" of "InsecurePrivateNetworkRequestsAllowed". Deze policy moet worden ingesteld op Disabled, wat ervoor zorgt dat Edge alle requests van publieke websites naar private IP-adressen blokkeert. Na het configureren van de policy-instelling moet het profiel worden toegewezen aan de relevante device groepen. Deze toewijzing kan gebeuren op basis van verschillende criteria, zoals organisatorische eenheden, security groepen, of specifieke device tags. Het is belangrijk om een gefaseerde uitrol te overwegen, waarbij eerst een testgroep wordt geconfigureerd om te verifiëren dat de configuratie correct werkt en geen onbedoelde gevolgen heeft voor de gebruikerservaring. Na succesvolle verificatie kan de configuratie worden uitgerold naar de rest van de organisatie. Voor organisaties die nog werken met een traditionele on-premises Active Directory omgeving biedt Group Policy een alternatieve implementatiemethode. Deze aanpak vereist toegang tot de Group Policy Management Console, die typisch wordt geïnstalleerd op een domain controller of een dedicated management server. Binnen de Group Policy Management Console kunnen beheerders een nieuwe Group Policy Object (GPO) aanmaken of een bestaand GPO bewerken. De Edge policy-instellingen worden geconfigureerd via Computer Configuration, Policies, Administrative Templates, Microsoft Edge, en vervolgens de Network sectie. Dezelfde policy-instelling moet hier worden ingesteld op Disabled, en de GPO moet worden gekoppeld aan de relevante Organizational Units (OUs) binnen Active Directory. Voor organisaties die werken met een hybride omgeving, waarbij sommige devices worden beheerd via Intune en andere via Group Policy, is het belangrijk om te zorgen voor consistente configuratie across beide beheersystemen. In dergelijke scenario's moet dezelfde policy-instelling worden geconfigureerd in zowel Intune als Group Policy, waarbij aandacht wordt besteed aan eventuele conflicten die kunnen ontstaan wanneer een device door beide systemen wordt beheerd. Voor kleinere organisaties of specifieke use cases kan handmatige implementatie via PowerShell een geschikte optie zijn. Het bijgeleverde PowerShell script private-network-requests-blocked.ps1 biedt de functie Invoke-Remediation die automatisch de benodigde registry-instellingen configureert. Dit script maakt het Edge policy pad aan in de registry en stelt de PrivateNetworkRequestsAllowed waarde in op 0, wat overeenkomt met de Block-instelling. Het script kan worden uitgevoerd met lokale administrator rechten en is bijzonder geschikt voor ad-hoc implementaties of voor het testen van de configuratie voordat deze via gecentraliseerde methoden wordt uitgerold. Ongeacht welke implementatiemethode wordt gekozen, is het van cruciaal belang om na de implementatie te verifiëren dat de configuratie correct is toegepast. Dit kan worden gedaan door de registry-waarde te controleren op een testdevice, door de Edge policy te verifiëren via edge://policy in de browser, of door gebruik te maken van de monitoringfunctie in het PowerShell script. Daarnaast moet worden getest of legitieme interne webapplicaties nog steeds toegankelijk zijn wanneer ze rechtstreeks worden benaderd, en of publieke websites inderdaad geen toegang meer hebben tot private IP-adressen.

Gebruik PowerShell-script private-network-requests-blocked.ps1 (functie Invoke-Remediation) – Automatische configuratie van de registry instelling via PowerShell. Maakt Edge policy path aan en stelt PrivateNetworkRequestPolicy in op 0 (Block)..

Monitoring

Effectieve monitoring van deze beveiligingsmaatregel is essentieel om te garanderen dat de configuratie correct blijft geïmplementeerd en dat eventuele wijzigingen of non-compliance snel worden gedetecteerd. Monitoring moet worden gezien als een continu proces dat regelmatig wordt uitgevoerd, niet als een eenmalige verificatie na implementatie. Organisaties moeten een gestructureerde monitoringstrategie ontwikkelen die verschillende verificatiemethoden combineert om een volledig beeld te krijgen van de compliance status. De primaire monitoringmethode betreft de verificatie van de registry-instelling op elk beheerd systeem. De registry-waarde PrivateNetworkRequestsAllowed moet op 0 staan om te voldoen aan de beveiligingsvereisten. Deze verificatie kan handmatig worden uitgevoerd door de registry te openen en de waarde te controleren op het pad HKLM:\SOFTWARE\Policies\Microsoft\Edge\PrivateNetworkRequestsAllowed, maar voor grootschalige omgevingen is geautomatiseerde monitoring veel efficiënter. Het bijgeleverde PowerShell script biedt de functie Invoke-Monitoring die automatisch alle beheerde systemen kan scannen en een gedetailleerd compliance rapport genereert. Dit script controleert niet alleen of de registry-waarde correct is ingesteld, maar rapporteert ook welke systemen non-compliant zijn en welke acties nodig zijn om de configuratie te herstellen. Een tweede belangrijke monitoringmethode is de verificatie via de Edge browser zelf. Gebruikers of beheerders kunnen navigeren naar edge://policy in de Edge browser om te zien welke policies actief zijn en wat hun huidige waarden zijn. Deze methode is bijzonder nuttig voor gebruikers om zelf te verifiëren dat de beveiligingsmaatregel actief is, en voor helpdeskmedewerkers om snel te diagnosticeren of er problemen zijn met de policy-configuratie. De edge://policy pagina toont alle geconfigureerde Edge policies, inclusief de Private Network Request Policy, en geeft duidelijk aan of de policy is ingesteld op Block, Allow, of niet is geconfigureerd. Voor organisaties die Microsoft Intune gebruiken voor device management biedt het Intune admin center uitgebreide compliance rapportage mogelijkheden. Het Intune compliance dashboard toont per device of de configuratieprofielen correct zijn toegepast en of er eventuele fouten zijn opgetreden tijdens de deployment. Beheerders kunnen compliance rapporten genereren die laten zien welk percentage van de devices voldoet aan de beveiligingsvereisten, en welke devices aandacht nodig hebben. Deze rapportage kan worden geautomatiseerd door compliance alerts te configureren die automatisch worden verzonden wanneer een device non-compliant wordt, waardoor beheerders proactief kunnen reageren op configuratiewijzigingen. Functionele testing vormt een cruciale aanvulling op technische verificatie. Het is belangrijk om daadwerkelijk te testen of de beveiligingsmaatregel werkt zoals bedoeld door te proberen een private IP-adres te benaderen vanaf een publieke website. Dit kan worden gedaan door een testpagina te ontwikkelen die probeert een HTTP-request te maken naar een private IP-adres binnen het RFC 1918 bereik, zoals 192.168.1.1 of 10.0.0.1. Wanneer de policy correct is geconfigureerd, moet deze request worden geblokkeerd door de browser, wat kan worden geverifieerd door de browser console te controleren op specifieke foutmeldingen die aangeven dat de private network request is geweigerd. Naast deze directe monitoringmethoden moeten organisaties ook aandacht besteden aan indirecte indicatoren die kunnen wijzen op problemen met de configuratie. Gebruikersklachten over het niet kunnen benaderen van interne webapplicaties kunnen bijvoorbeeld wijzen op een te restrictieve configuratie, hoewel dit normaal gesproken niet zou moeten gebeuren omdat legitieme interne applicaties die rechtstreeks worden benaderd niet worden beïnvloed door deze policy. Security incidenten waarbij interne services worden gecompromitteerd via browser-based aanvallen kunnen wijzen op een niet-functionerende of ontbrekende configuratie. Monitoring moet worden geïntegreerd in het algemene security operations proces van de organisatie. Compliance checks moeten regelmatig worden uitgevoerd, bijvoorbeeld maandelijks of kwartaal, en de resultaten moeten worden gedocumenteerd voor audit doeleinden. Eventuele non-compliance moet worden geëscaleerd naar het security team of IT-beheer voor onmiddellijke remediatie. Organisaties moeten ook overwegen om monitoring te automatiseren door gebruik te maken van security information and event management (SIEM) systemen die kunnen worden geconfigureerd om alerts te genereren wanneer registry-wijzigingen worden gedetecteerd die de Edge policy-instellingen beïnvloeden.

Gebruik PowerShell-script private-network-requests-blocked.ps1 (functie Invoke-Monitoring) – Controleert of de registry waarde correct is geconfigureerd en rapporteert compliance status met gedetailleerd rapport..

Remediatie

Wanneer monitoring of compliance checks non-compliance detecteren, is snelle en effectieve remediatie van cruciaal belang om de beveiligingspostuur van de organisatie te herstellen. Non-compliance kan verschillende oorzaken hebben, zoals handmatige wijzigingen aan de registry door gebruikers of andere software, conflicterende Group Policy-instellingen, of fouten tijdens de oorspronkelijke implementatie. Ongeacht de oorzaak moet er een gestructureerd remediatieproces zijn dat snel de juiste configuratie herstelt. Het remediatieproces begint met de identificatie van de oorzaak van de non-compliance. Dit kan worden gedaan door de registry te controleren om te zien wat de huidige waarde is, door de Edge policy te verifiëren via edge://policy, en door te onderzoeken of er recent wijzigingen zijn aangebracht aan Group Policy of Intune configuratieprofielen. Het is belangrijk om te begrijpen waarom de configuratie is gewijzigd, omdat dit kan helpen voorkomen dat het probleem opnieuw optreedt. Bijvoorbeeld, als de wijziging is veroorzaakt door een conflicterende Group Policy, moet deze Group Policy worden aangepast of verwijderd voordat de remediatie wordt uitgevoerd. Voor geautomatiseerde remediatie biedt het bijgeleverde PowerShell script de functie Invoke-Remediation die automatisch de correcte registry-instellingen herstelt. Deze functie controleert eerst de huidige status van de configuratie, en als deze niet correct is, wordt de registry-waarde PrivateNetworkRequestsAllowed automatisch ingesteld op 0. Het script maakt ook het benodigde registry pad aan als dit nog niet bestaat, wat kan voorkomen dat de policy niet wordt geladen door Edge. Deze geautomatiseerde aanpak is bijzonder effectief voor grootschalige omgevingen waar handmatige remediatie op elk individueel systeem niet praktisch is. Na de remediatie van de registry-instellingen is het belangrijk om Microsoft Edge opnieuw te starten op de betreffende systemen. Edge laadt policy-instellingen tijdens het opstarten, dus een herstart is noodzakelijk om ervoor te zorgen dat de nieuwe configuratie wordt toegepast. Gebruikers kunnen Edge handmatig herstarten, maar voor gecentraliseerde remediatie kan dit ook worden geautomatiseerd via Group Policy of Intune scripts die een herstart van de Edge browser forceren na het aanbrengen van registry-wijzigingen. Na de herstart moet worden geverifieerd dat de policy correct is geladen. Dit kan worden gedaan door te navigeren naar edge://policy in de Edge browser en te controleren of de Private Network Request Policy wordt weergegeven met de waarde Block. Het is belangrijk om op te merken dat de policy die wordt gecontroleerd de PrivateNetworkRequestsAllowed policy is, niet de DnsInterceptionChecksEnabled policy die in sommige documentatie wordt genoemd. Deze verificatie moet worden uitgevoerd op een representatieve steekproef van de gerepareerde systemen om te bevestigen dat de remediatie succesvol is geweest. Een kritieke verificatiestap na remediatie is het testen of legitieme interne webapplicaties nog steeds correct functioneren. Deze beveiligingsmaatregel zou geen impact moeten hebben op interne applicaties die rechtstreeks worden benaderd via hun URL of IP-adres, omdat de policy alleen requests blokkeert die afkomstig zijn van publieke websites. Organisaties moeten testen of hun interne webapplicaties, zoals SharePoint on-premises, interne management portals, of andere bedrijfsspecifieke applicaties, nog steeds toegankelijk zijn en correct functioneren. Als er problemen worden gedetecteerd, moet worden onderzocht of deze worden veroorzaakt door deze specifieke policy of door andere configuratieproblemen. Tegelijkertijd moet worden geverifieerd dat de beveiligingsmaatregel daadwerkelijk werkt door te testen of publieke websites geen toegang meer hebben tot private IP-adressen. Dit kan worden gedaan door een testpagina te ontwikkelen die probeert een request te maken naar een private IP-adres, en te verifiëren dat deze request wordt geblokkeerd door de browser. De browser console moet specifieke foutmeldingen tonen die aangeven dat de private network request is geweigerd vanwege de browser policy. Deze functionele test is essentieel om te bevestigen dat de remediatie niet alleen de configuratie heeft hersteld, maar ook dat de beveiligingsmaatregel daadwerkelijk functioneert zoals bedoeld. Na succesvolle remediatie en verificatie moeten de wijzigingen worden gedocumenteerd voor audit en compliance doeleinden. Dit omvat het vastleggen van wanneer de non-compliance werd gedetecteerd, wat de oorzaak was, welke remediatie-acties zijn ondernomen, en de resultaten van de verificatietests. Deze documentatie is belangrijk voor het aantonen van compliance tijdens audits, en kan ook helpen bij het identificeren van patronen in non-compliance die kunnen wijzen op systematische problemen in de configuratiemanagement processen van de organisatie.

Gebruik PowerShell-script private-network-requests-blocked.ps1 (functie Invoke-Remediation) – Herstelt de configuratie automatisch door de registry waarde correct in te stellen..

Compliance en Auditing

Deze beveiligingsmaatregel draagt substantieel bij aan de compliance met verschillende belangrijke cybersecurity frameworks en standaarden die relevant zijn voor Nederlandse overheidsorganisaties en bedrijven. Het begrijpen van deze compliance-verbanden is essentieel voor security officers en auditors die moeten aantonen dat de organisatie voldoet aan de vereiste beveiligingsstandaarden. De CIS Microsoft Edge Benchmark v1.0.0 identificeert deze maatregel als Control 1.17.1, geclassificeerd als Level 1, wat betekent dat het wordt beschouwd als een fundamentele beveiligingsmaatregel die door alle organisaties zou moeten worden geïmplementeerd. De CIS Benchmark specificeert expliciet dat de Private Network Request Policy moet worden ingesteld op Block om te voorkomen dat publieke websites toegang krijgen tot private netwerkadressen. Deze control is onderdeel van een bredere set van browser security best practices die zijn ontwikkeld door het Center for Internet Security, een gerenommeerde organisatie die cybersecurity standaarden ontwikkelt voor verschillende technologieën. Compliance met de CIS Benchmark wordt vaak gebruikt als basis voor security assessments en kan helpen bij het aantonen van due diligence op het gebied van cybersecurity. Voor Nederlandse overheidsorganisaties is compliance met de BIO (Baseline Informatiebeveiliging Overheid) van bijzonder belang. Deze maatregel draagt direct bij aan Themagebied 11.04, dat zich richt op de beveiliging van netwerken. Specifiek ondersteunt het de bescherming van interne netwerkservices tegen externe aanvallen, wat een kernvereiste is binnen het BIO framework. De BIO stelt dat organisaties passende maatregelen moeten nemen om hun netwerken te beveiligen tegen ongeautoriseerde toegang en aanvallen, en deze Edge policy vormt een belangrijke technische implementatie van deze vereiste. Door deze maatregel te implementeren kunnen overheidsorganisaties aantonen dat zij proactief werken aan de bescherming van hun netwerkinfrastructuur, wat essentieel is voor het behoud van vertrouwen in de digitale dienstverlening van de overheid. De internationale ISO 27001:2022 standaard voor informatiebeveiligingsmanagement bevat verschillende controls die relevant zijn voor deze maatregel. Specifiek draagt het bij aan control A.8.22, dat zich richt op segregation in networks, en aan control A.13.1.3, dat betrekking heeft op network access control. ISO 27001 vereist dat organisaties hun netwerken segmenteren en toegangscontroles implementeren om te voorkomen dat ongeautoriseerde partijen toegang krijgen tot interne systemen. Deze Edge policy vormt een belangrijke technische maatregel die deze vereisten ondersteunt door te voorkomen dat externe websites via de browser toegang krijgen tot interne netwerkservices. Voor organisaties die gecertificeerd zijn volgens ISO 27001 of die streven naar certificering, is het implementeren van deze maatregel een belangrijke stap in het aantonen van compliance met deze controls. De NIS2 richtlijn, die is geïmplementeerd in Nederlandse wetgeving, vereist dat essentiële en belangrijke entiteiten passende cybersecurity maatregelen nemen om hun netwerken en informatiesystemen te beveiligen. Artikel 21 van de NIS2 richtlijn specificeert dat organisaties network segmentation en access control maatregelen moeten implementeren als onderdeel van hun cybersecurity risicobeheer. Deze Edge policy draagt direct bij aan deze vereisten door te voorkomen dat externe partijen via de browser toegang krijgen tot interne netwerkservices, wat een vorm van network segmentation en access control is op het niveau van de browser. Voor organisaties die onder de NIS2 richtlijn vallen, zoals energiebedrijven, transportbedrijven, en financiële instellingen, is het implementeren van deze maatregel niet alleen een best practice, maar ook een compliance-vereiste. De OWASP Top 10 lijst van web application security risico's identificeert Broken Access Control als het meest kritieke risico (A01:2021). Dit risico treedt op wanneer applicaties niet correct controleren of gebruikers geautoriseerd zijn om bepaalde acties uit te voeren of toegang te krijgen tot bepaalde resources. Deze Edge policy draagt bij aan het voorkomen van broken access control door te voorkomen dat publieke websites ongeautoriseerde toegang krijgen tot interne netwerkservices via de browser. Hoewel deze policy zich richt op browser-level beveiliging in plaats van application-level beveiliging, vormt het een belangrijke defense-in-depth maatregel die helpt voorkomen dat access control problemen in interne applicaties worden misbruikt door externe partijen. De W3C Private Network Access specificatie vormt de technische basis voor deze beveiligingsmaatregel. Deze specificatie is ontwikkeld om browser-based bescherming te bieden tegen CSRF-aanvallen (Cross-Site Request Forgery) die gericht zijn op private netwerken. De specificatie definieert hoe browsers moeten omgaan met requests van publieke websites naar private IP-adressen, en stelt dat deze requests standaard moeten worden geblokkeerd tenzij expliciet toegestaan. Door deze Edge policy te configureren volgens de W3C specificatie, zorgen organisaties ervoor dat zij gebruik maken van de nieuwste browser security features en dat hun implementatie voldoet aan de geaccepteerde web standaarden. Dit is niet alleen belangrijk voor beveiliging, maar ook voor toekomstige compatibiliteit, omdat browsers steeds strikter worden in het handhaven van deze beveiligingsmaatregelen. Voor audit en compliance doeleinden is het belangrijk om te documenteren hoe deze maatregel bijdraagt aan elk van deze frameworks. Dit kan worden gedaan door in de security documentatie expliciet te verwijzen naar de relevante controls en artikelen, en door tijdens audits te kunnen aantonen dat de configuratie correct is geïmplementeerd en wordt gemonitord. Organisaties moeten ook overwegen om deze maatregel op te nemen in hun security control matrix, die laat zien hoe verschillende technische maatregelen bijdragen aan de compliance met verschillende frameworks en standaarden.

Compliance & Frameworks

• CIS M365: Control 1.17.1 (L1) - zorg ervoor dat Private Network Request Policy is set to Block - voorkomt toegang van publieke websites tot private netwerk adressen
• BIO: 11.04.1, 11.04.2 - Beveiliging van netwerken - Bescherming van interne services tegen ongeautoriseerde toegang
• ISO 27001:2022: A.8.22, A.13.1.3 - Segregation in networks - Network access control voor bescherming van interne systemen
• NIS2: Artikel - Cybersecurity risicobeheer - Network segmentation en access control maatregelen

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

Blokkeer requests van publieke websites naar private IP-adressen (RFC 1918 ranges). Beschermt interne services tegen browser-based aanvallen zoals router hijacking en IoT exploitation. CIS Edge Benchmark 1.17.1 Level 1 vereist. Implementatie: 1-2 uur via Intune of GPO. Geen gebruikersimpact voor normale browsing.

• Implementatietijd: 2 uur
• FTE required: 0.01 FTE