URL Filtering

Wat is URL Filtering?

URL Filtering is een beveiligingsmaatregel die webverkeer toestaat of blokkeert op basis van de opgevraagde URL, het domein of de categorie van de website, zodat systemen en gebruikers geen verbinding maken met onveilige, ongewenste of niet-geautoriseerde webbronnen. Het filter zit meestal in een proxy, een next-gen firewall of een DNS-dienst en vergelijkt elk webverzoek met beleid, categorielijsten en reputatiegegevens. In OT-omgevingen voorkomt URL Filtering dat systemen zoals een engineering station, HMI of jump server contact leggen met malafide sites, onbekende cloudservices of de command-and-control-servers van een aanvaller.

🧠 Waarom is URL Filtering belangrijk in OT?

OT-systemen horen zelden vrij op internet te kunnen. Toch hebben engineering stations, servers in de DMZ en onderhoudslaptops vaak (tijdelijk) webtoegang nodig voor licenties, documentatie of updates. Juist daar wordt webverkeer een onderschat aanvalskanaal: malware wordt binnengehaald via een drive-by download, een phishinglink steelt inloggegevens of een besmet systeem neemt via HTTPS contact op met zijn beheerder.

URL Filtering werkt daarmee in twee richtingen: het verkleint de kans op besmetting via uitgaande webverzoeken en het bemoeilijkt de communicatie van malware die al binnen is.

🔧 Hoe werkt URL Filtering technisch?

Elk webverzoek doorloopt bij het filter grofweg dezelfde stappen: het filter bepaalt de bestemming, zoekt die op in een lokale of cloudgebaseerde database en past daarna het beleid toe (toestaan, blokkeren, waarschuwen of loggen). Wat het filter precies kan zien, hangt af van de plek en van versleuteling:

Een belangrijk technisch punt: bij HTTPS ziet een filter zonder TLS-inspectie alleen de hostnaam, niet het pad. Een regel op /download/firmware.exe werkt dan niet. Met Encrypted Client Hello (ECH) wordt ook de hostnaam in de handshake versleuteld; filters die op de SNI vertrouwen, verliezen dan zicht. DNS-filtering blijft in dat geval grotendeels werken, en daarom combineren organisaties beide lagen.

🔍 Waarop kunt u filteren?

Voor kantoornetwerken is filteren op categorie het uitgangspunt: alles mag, behalve wat expliciet riskant is (denylist). Voor OT is het omgekeerde gebruikelijk: niets mag, behalve een korte lijst met goedgekeurde bestemmingen (allowlist, vroeger whitelist genoemd).

🛠️ Waar plaatst u URL Filtering in een OT-netwerk?

In het Purdue Model hoort direct internetverkeer niet thuis op niveau 0 tot en met 2. Systemen op die niveaus halen updates en bestanden op via een server in de DMZ, en alleen die server krijgt (gefilterde) toegang naar buiten.

📐 Welke normen vragen om URL Filtering?

• IEC 62443-3-3 - binnen de fundamentele eis “Restricted Data Flow” vraagt SR 5.2 om bewaking van zonegrenzen, met de versterking “alles weigeren, uitzonderingen toestaan”. SR 5.3 vraagt de mogelijkheid om algemene persoon-tot-persoon-berichten, zoals e-mail en chat, van gebruikers of processen buiten het besturingssysteem tegen te houden; webtoegang vanaf besturingssystemen valt in de geest van dezelfde eis.
• ISO 27002:2022 - beheersmaatregel 8.23 “Web filtering” is nieuw in de editie van 2022 en vraagt organisaties de toegang tot externe websites te beheren om blootstelling aan kwaadaardige inhoud te verminderen.
• CIS Controls v8 - safeguard 9.2 vraagt om DNS-filtering en safeguard 9.3 om netwerkgebaseerde URL-filters op basis van categorie, reputatie of blokkeerlijsten.
• NIST SP 800-82 - de NIST-richtlijn voor OT-beveiliging adviseert internettoegang vanuit OT-netwerken zoveel mogelijk te beperken en via gecontroleerde punten te laten lopen.

Voor organisaties die onder de Cyberbeveiligingswet (de Nederlandse invulling van NIS2, van kracht sinds 15 augustus 2026) vallen, is URL Filtering een concrete, aantoonbare maatregel binnen de zorgplicht voor netwerkbeveiliging.

✅ Hoe voert u URL Filtering stapsgewijs in?

1. Inventariseer de behoefte - leg per OT-systeem vast welke externe bestemmingen echt nodig zijn: licentieservers, leveranciersportals, updatebronnen.
2. Kies de plek - centraal via een proxy in de DMZ heeft de voorkeur boven losse regels op elk systeem.
3. Start met monitoren - zet het filter eerst in logmodus en analyseer een paar weken verkeer, zodat u geen legitieme verbindingen breekt.
4. Schakel naar default-deny - sta alleen de allowlist toe en blokkeer de rest, inclusief categorieën als nieuw geregistreerde domeinen.
5. Koppel aan detectie - stuur blokkades naar uw SIEM of SOC; een besturingsnetwerk dat een onbekend domein probeert te bereiken, is een sterk signaal.
6. Beheer en herzie - controleer periodiek op onterechte blokkades en gemiste dreigingen en verwijder bestemmingen die niet meer nodig zijn, net als bij firewallregelbeheer.

Zorg ook dat tijdelijke verbindingen, bijvoorbeeld een laptop van een leverancier tijdens onderhoud op afstand, via hetzelfde filter lopen.

🔐 Hoe combineert u URL Filtering met andere maatregelen?

URL Filtering is één laag in defense in depth: DNS-filtering, het URL-filter, endpointbescherming en monitoring vangen elk een ander deel van de aanvallen af.

❓ Veelgestelde vragen

Wat is het verschil tussen URL Filtering en DNS-filtering?

DNS-filtering blokkeert een bestemming al bij het opzoeken van de domeinnaam en ziet dus alleen het domein. URL Filtering kijkt naar het volledige webverzoek en kan ook op pad, bestand of categorie filteren, mits het verkeer zichtbaar is. De twee vullen elkaar aan en worden in de CIS Controls als aparte safeguards genoemd.

Werkt URL Filtering ook bij HTTPS-verkeer?

URL Filtering werkt bij HTTPS-verkeer op hostnaamniveau, via de SNI in de TLS-handshake of het CONNECT-verzoek aan een proxy. Voor filteren op het volledige pad is TLS-inspectie nodig, waarbij de proxy of firewall het verkeer ontsleutelt. In OT-netwerken wordt TLS-inspectie vaak beperkt tot de proxy in de DMZ.

Is een allowlist of een denylist beter voor OT?

Voor OT-systemen is een allowlist beter, omdat het aantal legitieme webbestemmingen klein en voorspelbaar is. Een denylist laat alles toe wat (nog) niet als kwaadaardig bekend is. Op kantoornetwerken is een categoriegebaseerde denylist meestal praktischer.

Kan URL Filtering malware tegenhouden?

URL Filtering houdt malware tegen die via bekende kwaadaardige of verdachte sites wordt verspreid, en blokkeert verbindingen naar command-and-control-servers. Malware die via een USB-stick binnenkomt of een goedgekeurde site misbruikt, gaat er langs. URL Filtering is daarom een aanvulling op endpointbescherming en segmentatie, geen vervanging.

Kan URL Filtering worden omzeild?

URL Filtering kan worden omzeild met een vast IP-adres, versleutelde DNS (DNS over HTTPS) of Encrypted Client Hello, omdat het filter dan de bestemming niet meer ziet. Blokkeer daarom in OT alle uitgaand verkeer dat niet via de proxy loopt en sta alleen de eigen DNS-servers toe. Zo blijft het filter het enige pad naar buiten.

Moeten PLC’s en HMI’s achter een URL-filter?

PLC’s en HMI’s horen helemaal geen internettoegang te hebben, dus een URL-filter is voor hen geen oplossing maar een vangnet. Blokkeer uitgaand webverkeer vanaf die niveaus volledig en laat alleen servers in de DMZ via een gefilterde proxy naar buiten. Een geblokkeerde poging vanaf een HMI is een waardevol signaal voor uw SOC.

📌 Samengevat

URL Filtering beschermt OT-systemen tegen ongecontroleerd webverkeer door elk webverzoek te toetsen aan een allowlist, categorie of reputatie. Met een centrale proxy in de DMZ, default-deny, aanvullende DNS-filtering en koppeling aan uw SIEM vormt het een concrete invulling van IEC 62443-3-3 SR 5.2, ISO 27002 8.23 en CIS Controls 9.3.