De firewall staat aan. Maar ziet hij eigenlijk nog wel iets?
We investeren miljoenen in netwerkbeveiliging, vertrouwen op indrukwekkende dashboards en presenteren onze securityarchitectuur alsof we alles onder controle hebben. Ondertussen reist een groot deel van ons digitale verkeer versleuteld door de organisatie. Dat is goed voor onze privacy, maar roept een ongemakkelijke vraag op: hoeveel van dat verkeer controleren we eigenlijk? En belangrijker nog, weten we wat onze beveiliging niet ziet?
De duurste portier van Nederland
Stel je een kantoorgebouw voor met een indrukwekkende hoofdingang. Draaideuren, toegangspoortjes, camera’s en beveiligers die iedere bezoeker vriendelijk maar beslist om een toegangspas vragen. Niemand komt zomaar binnen. De organisatie heeft serieus geïnvesteerd in veiligheid.
Totdat iemand ontdekt dat vrijwel iedere bezoeker een grote, afgesloten koffer meeneemt.
De beveiligers controleren de toegangspas, kijken waar de bezoeker vandaan komt en registreren het tijdstip. De koffers blijven gesloten. Dat is nu eenmaal zo afgesproken.
Op de vraag wat erin zit, antwoordt de beveiliger dat hij dat niet kan zien. Maar de beveiliging werkt uitstekend, verzekert hij. Alle lampjes op het dashboard staan immers op groen.
Welkom bij een aanzienlijk deel van onze moderne netwerkbeveiliging.
De firewall is al tientallen jaren een vertrouwd onderdeel van de IT-infrastructuur. Ooit was zijn belangrijkste taak betrekkelijk overzichtelijk: bepalen welk netwerkverkeer wel of niet mocht passeren. Tegenwoordig hebben we het over next-generation firewalls, intrusion prevention, applicatieherkenning, threat intelligence en geavanceerde detectietechnieken.
Een indrukwekkende verzameling functionaliteiten, waarvoor organisaties jaarlijks aanzienlijke bedragen betalen.
Maar er zit een ongemakkelijke tegenstelling in die technische vooruitgang. Terwijl onze beveiligingsapparatuur steeds slimmer is geworden, hebben we tegelijkertijd een steeds groter deel van het internetverkeer onleesbaar gemaakt voor diezelfde apparatuur.
En dat hebben we met de beste bedoelingen gedaan.
We hebben het internet veiliger gemaakt. Ook voor criminelen.
Vrijwel iedereen kent inmiddels het slotje in de browser. Het geeft aan dat een verbinding beveiligd is met HTTPS, waarbij TLS de communicatie versleutelt. Daardoor kunnen anderen onderweg niet zomaar meelezen met wachtwoorden, persoonlijke gegevens of zakelijke informatie.
Dat is een enorme verbetering ten opzichte van het internet van vroeger, waarin veel informatie nog onversleuteld over netwerken reisde.
Alleen maakt TLS geen onderscheid tussen goede en slechte bedoelingen.
Een medewerker die zijn salarisstrook bekijkt, gebruikt versleuteling. Een arts die medische informatie raadpleegt, eveneens. Maar ook een aanvaller die malware downloadt, opdrachten naar een geïnfecteerde computer verstuurt of gestolen bedrijfsinformatie naar buiten probeert te brengen, kan gebruikmaken van precies dezelfde technologie.
Voor het netwerk ziet dat verkeer er aan de buitenkant soms verrassend vergelijkbaar uit.
Een moderne firewall kan zonder decryptie nog steeds waardevolle informatie verzamelen. Hij kan IP-adressen, verbindingen, verkeerspatronen en afhankelijk van de gebruikte protocollen bepaalde domein- of certificaatgegevens beoordelen. Ook zijn er detectietechnieken die versleuteld verkeer analyseren zonder de inhoud te ontsleutelen.
Maar de daadwerkelijke inhoud van een beveiligde verbinding blijft bij gewone certificaatinspectie buiten beeld.
En daar ontstaat een probleem.
Want wanneer een beveiligingsoplossing is aangeschaft om kwaadaardige bestanden, verdachte opdrachten of bepaalde aanvalspatronen te herkennen, moet die oplossing wel toegang hebben tot de informatie die daarvoor nodig is.
In discussies over netwerkbeveiliging wordt regelmatig gesteld dat 90 procent of meer van het internetverkeer versleuteld is. Of dat percentage voor een specifieke organisatie klopt, hangt af van de omgeving, het soort verkeer en de meetmethode. Zonder meting is het vooral een overtuigend klinkend getal.
De exacte verhouding is uiteindelijk minder interessant dan de werkelijke vraag: hoeveel verkeer passeert onze beveiligingsapparatuur zonder dat de inhoud kan worden gecontroleerd?
Als niemand dat kan beantwoorden, hebben we een probleem dat groter is dan een ontbrekend vinkje in de firewallconfiguratie.
We weten dan niet waar onze beveiliging ophoudt.
De illusie van bescherming
IT-beveiliging heeft een merkwaardige eigenschap. Hoe meer producten een organisatie aanschaft, hoe gemakkelijker het wordt om aan te nemen dat de beveiliging daarmee automatisch verbetert.
Er komt een nieuwe firewall. Vervolgens een beveiligingsabonnement met aanvullende detectiemogelijkheden. Daarna een SOC dat de meldingen beoordeelt. En uiteindelijk een dashboard waarmee de directie kan zien hoeveel bedreigingen zijn tegengehouden.
Dat laatste is natuurlijk bijzonder prettig. Een mooie grafiek met tienduizenden geblokkeerde aanvallen geeft iedereen het gevoel dat het geld goed besteed is.
Alleen vertelt zo’n grafiek maar een deel van het verhaal.
Hij laat zien wat de beveiliging heeft herkend. Niet noodzakelijk wat onopgemerkt is gebleven.
Een inbraakalarmsysteem dat iedere nacht tien katten detecteert, kan een indrukwekkend rapport produceren. Maar wanneer de achterdeur buiten het bereik van de sensoren valt, zegt het aantal meldingen weinig over de werkelijke veiligheid van het gebouw.
Met netwerkbeveiliging is het niet anders.
Misschien worden duizenden ongewenste verbindingen geblokkeerd. Misschien werkt de intrusion prevention uitstekend op verkeer dat daadwerkelijk wordt geïnspecteerd. Maar als grote delen van de relevante communicatie buiten die inspectie vallen, ontstaat een blinde vlek.
Daarbij is het moderne bedrijfsnetwerk allang niet meer het overzichtelijke landschap van vroeger.
Medewerkers werken thuis, applicaties draaien in verschillende cloudomgevingen en apparaten communiceren rechtstreeks met externe diensten. Verkeer loopt via lokale internetverbindingen, VPN’s, SaaS-platformen en uiteenlopende netwerksegmenten.
De traditionele firewall aan de rand van het datacenter ziet lang niet altijd meer al die communicatie.
Je kunt dus beschikken over uitstekende beveiligingsapparatuur die technisch correct functioneert, maar zich simpelweg niet bevindt op de plek waar een aanval plaatsvindt.
Dat is geen defect van het product.
Dat is een tekortkoming in de architectuur.
En geen enkele licentieverlenging lost dat vanzelf op.
Citrix NetScaler: een pijnlijke les uit de praktijk
Wie denkt dat dit vooral een theoretische discussie is, hoeft alleen maar naar de recente problemen rondom Citrix NetScaler te kijken.
Op 27 september 2026 publiceerde Citrix een beveiligingsadvies over acht kwetsbaarheden in NetScaler ADC en NetScaler Gateway. Twee daarvan, CVE-2026-88771 en CVE-2026-88772, kregen een kritieke beoordeling en werden daadwerkelijk misbruikt door aanvallers.
De kwetsbaarheden maakten onder bepaalde omstandigheden het uitvoeren van schadelijke code op kwetsbare systemen mogelijk. Voor één van de kwetsbaarheden was geen aanvullende configuratie nodig. De andere was afhankelijk van ingeschakelde DTLS-functionaliteit, die bij bepaalde VPN-configuraties standaard actief is.
Ook de Amerikaanse beveiligingsautoriteit CISA waarschuwde voor actief misbruik en riep organisaties op hun blootstelling te beoordelen, systemen bij te werken en mogelijke sporen van een eerdere compromittering te onderzoeken.
Het is precies het soort situatie waarin de waarde van goede netwerkzichtbaarheid duidelijk wordt. Een organisatie moet kunnen vaststellen of verdachte verzoeken de kwetsbare dienst hebben bereikt, welke activiteit daaraan voorafging en of na een eventuele compromittering afwijkend netwerkverkeer is ontstaan.
Maar hier moeten we zorgvuldig zijn met een populaire conclusie.
Het inschakelen van TLS-decryptie betekent namelijk niet dat zo’n aanval automatisch wordt tegengehouden.
Wanneer een kwetsbare NetScaler zelf de versleutelde verbinding beëindigt, beschermt een firewall die uitsluitend het versleutelde verkeer ervoor ziet die kwetsbaarheid niet vanzelf. Daarvoor kan inspectie vóór de kwetsbare dienst nodig zijn, bijvoorbeeld via een geschikte reverse proxy, WAF of andere beveiligingslaag.
Zelfs wanneer het verkeer wordt ontsleuteld, moet de beveiligingsoplossing de aanval nog herkennen en daadwerkelijk kunnen blokkeren. Een onbekende exploit kan ook door een inspecterende beveiligingslaag heen komen.
Bovendien zijn niet alle aanvalstechnieken op dezelfde manier zichtbaar. Een aanval op een protocolimplementatie of een kwetsbaarheid in de verwerking van versleutelde communicatie laat zich niet noodzakelijk herkennen door uitsluitend de ontsleutelde applicatie-inhoud te inspecteren.
Daarom blijft patchmanagement essentieel, net als het beperken van blootgestelde diensten, het beoordelen van configuraties en het onderzoeken van mogelijke compromittering.
Dat is misschien minder aantrekkelijk dan de belofte dat één instelling alle ellende voorkomt, maar wel een stuk dichter bij de werkelijkheid.
De les van NetScaler is niet dat iedere firewall zonder decryptie waardeloos is.
De les is dat organisaties precies moeten weten welke bescherming een beveiligingslaag biedt, welke aanvallen deze kan herkennen en waar andere maatregelen noodzakelijk blijven.
Anders ontdekken we de grenzen van onze beveiliging pas wanneer iemand anders ze heeft gevonden.
Waarom zetten we decryptie dan niet gewoon aan?
Wanneer versleuteling een deel van het zicht belemmert, lijkt de oplossing eenvoudig. Ontsleutel het verkeer, controleer de inhoud en versleutel het vervolgens opnieuw.
Technisch is dat precies wat TLS-inspectie kan doen.
Een beveiligingsapparaat of proxy plaatst zich gecontroleerd tussen de client en de bestemming. In plaats van één doorlopende versleutelde verbinding ontstaan twee afzonderlijk beveiligde verbindingen, met inspectie daartussen.
Zo kan de beveiligingslaag de inhoud beoordelen voordat deze verder wordt doorgestuurd.
Dat klinkt overzichtelijk, totdat de praktijk zich ermee gaat bemoeien.
Sommige applicaties accepteren deze tussenkomst niet. Ze gebruiken bijvoorbeeld certificate pinning of aanvullende beveiligingsmechanismen om vast te stellen dat ze rechtstreeks met de verwachte dienst communiceren. Andere toepassingen gebruiken protocollen of cryptografische technieken waarvoor de bestaande beveiligingsapparatuur onvoldoende ondersteuning biedt.
Wie zomaar decryptie inschakelt, loopt daardoor het risico dat bedrijfsapplicaties niet meer functioneren.
Dan ontstaat de bekende situatie waarin IT iets veiliger probeert te maken, waarna de halve organisatie belt omdat een applicatie niet meer werkt. De druk om de wijziging terug te draaien is doorgaans aanzienlijk groter dan de belangstelling voor de onderliggende beveiligingsarchitectuur.
Daarnaast vraagt decryptie om rekenkracht. Een firewall die alleen verbindingen verwerkt, levert niet automatisch dezelfde prestaties wanneer hij ook grote hoeveelheden versleuteld verkeer moet ontsleutelen, analyseren en opnieuw versleutelen.
De capaciteit, beschikbaarheid en mogelijke vertraging moeten dus onderdeel zijn van het ontwerp.
Maar de belangrijkste discussie is misschien helemaal niet technisch.
Het is een privacyvraagstuk.
Willen we werkelijk dat de werkgever de inhoud van iedere beveiligde verbinding kan inspecteren? Ook wanneer medewerkers persoonlijke informatie raadplegen, met hun bank communiceren of medische gegevens bekijken?
De Algemene verordening gegevensbescherming stelt voorwaarden aan het verwerken en controleren van persoonsgegevens. De Autoriteit Persoonsgegevens benadrukt dat monitoring van werknemers noodzakelijk en proportioneel moet zijn, met een passende juridische grondslag. Afhankelijk van de inrichting kan ook instemming van de ondernemingsraad nodig zijn.
Dat maakt de roep om honderd procent decryptie niet alleen technisch onverstandig, maar ook juridisch en maatschappelijk moeilijk verdedigbaar.
Veiligheid is geen vrijbrief om iedere vorm van vertrouwelijkheid op te heffen.
Een volwassen organisatie zal daarom onderscheid moeten maken tussen verschillende verkeersstromen. Zakelijke applicaties en verbindingen met een verhoogd risico kunnen andere inspectiemaatregelen rechtvaardigen dan persoonlijke communicatie of bijzonder gevoelige informatie.
Sommige verbindingen worden volledig geïnspecteerd. Andere krijgen bewust een uitzondering, waarbij aanvullende beveiligingsmaatregelen het resterende risico beperken.
Daar is niets mis mee.
Het wordt pas problematisch wanneer die uitzonderingen niet bewust zijn gemaakt, niemand ze beheert en het uitgesloten verkeer ongemerkt blijft groeien.
Dan verandert een zorgvuldig ontworpen privacymaatregel langzaam in een verzameling onbeheerde ontsnappingsroutes.
Een firewall is geen beveiligingsstrategie
De discussie over TLS-inspectie raakt aan een fundamenteler probleem binnen de IT.
We hebben beveiliging jarenlang georganiseerd rondom producten, terwijl we eigenlijk risico’s en informatiestromen zouden moeten beschermen.
De vraag welke firewall het beste is, krijgt vaak meer aandacht dan de vraag welke gegevens absoluut niet in verkeerde handen mogen vallen.
Organisaties vergelijken doorvoersnelheden, aantallen gelijktijdige sessies, threat prevention-scores en licentiemodellen. Allemaal relevante eigenschappen, maar alleen wanneer duidelijk is welk probleem ermee moet worden opgelost.
Een firewall aan de internetgrens biedt weinig bescherming tegen een aanvaller die via een gestolen identiteit toegang krijgt tot een legitieme cloudapplicatie.
Een perfect geconfigureerde inspectievoorziening helpt evenmin wanneer een medewerker met te veel rechten toegang heeft tot gevoelige bestanden en die vanuit een vertrouwde applicatie deelt.
Ook kan een gecompromitteerde computer proberen te communiceren met andere interne systemen zonder ooit de centrale internetfirewall te passeren.
Daarom is moderne netwerkbeveiliging meer dan het controleren van verkeer op één centrale plek.
Endpointdetectie kan verdachte processen herkennen die in het netwerkverkeer onzichtbaar blijven. Identiteitsbeveiliging kan ongebruikelijke aanmeldingen en misbruik van rechten signaleren. Segmentatie beperkt de bewegingsvrijheid van een aanvaller. DNS-beveiliging en analyse van netwerkgedrag kunnen helpen om verdachte verbindingen te herkennen, ook wanneer de inhoud versleuteld blijft.
En een goed ingericht SOC brengt die signalen samen, onderzoekt afwijkingen en reageert wanneer meerdere aanwijzingen op een aanval wijzen.
Dat betekent niet dat de firewall minder belangrijk wordt. Het betekent dat we moeten stoppen met doen alsof één beveiligingsproduct verantwoordelijk kan zijn voor de volledige digitale weerbaarheid.
Juist de combinatie van maatregelen maakt het verschil.
Zero Trust gaat in die zin niet over het wantrouwen van medewerkers, maar over het niet automatisch vertrouwen van een verbinding omdat die van binnen het netwerk komt of langs een vertrouwd beveiligingsapparaat is gegaan.
Vertrouwen moet voortdurend worden onderbouwd.
Ook wanneer het dashboard groen is.
De vraag die eigenlijk in iedere bestuurskamer moet worden gesteld
De meeste bestuurders zullen niet wakker liggen van een technisch verschil tussen certificaatinspectie en volledige TLS-decryptie. En dat hoeft ook niet.
Van een bestuurder verwachten we niet dat hij een firewallconfiguratie kan beoordelen. We mogen wel verwachten dat hij begrijpt welke risico’s zijn organisatie accepteert.
Daarvoor moet de informatievoorziening vanuit IT en security veranderen.
In plaats van uitsluitend te rapporteren hoeveel aanvallen zijn geblokkeerd, zouden we moeten laten zien welk deel van onze relevante digitale communicatie daadwerkelijk onder toezicht staat.
Weten we hoeveel verkeer volledig wordt geïnspecteerd? Welke verkeersstromen zijn bewust uitgezonderd? Waar bevindt zich netwerkverkeer dat onze centrale beveiligingsvoorzieningen helemaal niet passeert?
Zijn de detectiemechanismen actueel? Worden beveiligingsregels daadwerkelijk toegepast op het verkeer waarvoor ze bedoeld zijn? Heeft het SOC zicht op de relevante meldingen? En wanneer hebben we voor het laatst getest of een realistische aanval ook daadwerkelijk werd ontdekt?
Misschien is de interessantste vraag wel of een aanval die vandaag niet wordt geblokkeerd, morgen tenminste nog gereconstrueerd kan worden.
Dat vraagt om meetbare beveiligingsdekking in plaats van een verzameling mooie producteigenschappen.
Een organisatie zou bijvoorbeeld moeten kunnen uitleggen waarom bepaalde bedrijfskritische verbindingen intensief worden gecontroleerd, welke technische of privacyredenen er zijn om andere verbindingen uit te sluiten en welke aanvullende maatregelen daarvoor zijn ingericht.
Ook moet duidelijk zijn wie verantwoordelijk is voor die keuzes.
Een uitzondering zonder eigenaar is uiteindelijk geen bewuste risicoacceptatie, maar een probleem dat op de volgende verantwoordelijke ligt te wachten.
En die komt doorgaans pas nadrukkelijk in beeld wanneer het misgaat.
Het belangrijkste is dat beveiligingsrapportages niet uitsluitend vertellen wat goed gaat.
Ze moeten ook zichtbaar maken wat we niet weten.
Dat is misschien ongemakkelijk tijdens een bestuursvergadering. Maar aanzienlijk minder ongemakkelijk dan achteraf moeten verklaren waarom een aanval wekenlang onopgemerkt kon blijven terwijl de securitydashboards niets bijzonders meldden.
Wat is dan de echte IT-realiteit als standaard
We leven in een tijd waarin organisaties steeds meer investeren in cybersecurity, maar waarin de complexiteit van onze digitale omgeving minstens zo snel groeit.
We versleutelen communicatie om gegevens te beschermen. We bouwen steeds intelligentere beveiligingslagen om aanvallen te herkennen. We verplaatsen applicaties naar de cloud, ondersteunen thuiswerken en verbinden duizenden apparaten die lang niet allemaal dezelfde beveiligingsmogelijkheden hebben.
Dat zijn op zichzelf verstandige ontwikkelingen.
Maar samen zorgen ze ervoor dat de vertrouwde gedachte van één controlepunt aan de rand van het netwerk steeds minder overeenkomt met de werkelijkheid.
De oplossing is niet om overal zonder onderscheid decryptie aan te zetten. Evenmin is het verstandig om versleutelde communicatie volledig buiten beschouwing te laten.
De oplossing begint met inzicht.
Weten welke verbindingen onze beveiligingsapparatuur daadwerkelijk ziet. Begrijpen welke inhoud wordt gecontroleerd. Bewust bepalen waar inspectie noodzakelijk en verantwoord is. Uitzonderingen documenteren, aanvullende controles inrichten en regelmatig aantonen dat de gekozen beveiligingsmaatregelen daadwerkelijk functioneren.
En vooral erkennen dat detectie, preventie, patchmanagement, identiteitsbeveiliging en incidentrespons elkaar moeten aanvullen.
Een firewall die niet alles kan inspecteren, is niet automatisch een slechte firewall.
Een organisatie die niet weet wat haar firewall wel en niet inspecteert, heeft daarentegen een serieus bestuurlijk probleem.
Misschien moeten we bij de volgende investering in netwerkbeveiliging daarom niet beginnen met de vraag welke nieuwe functionaliteit de leverancier beschikbaar heeft.
Misschien moeten we eerst eens kijken naar de apparatuur die er al staat.
Niet naar de mooie dashboards, de aangeschafte licenties of het aantal geblokkeerde verbindingen.
Maar naar het verkeer dat er ongezien doorheen gaat.
Want de echte IT-realiteit is dat je niet veilig bent omdat je beveiliging hebt aangeschaft. Je bent pas aantoonbaar beter beveiligd wanneer je weet wat die beveiliging daadwerkelijk doet, wat zij niet kan en hoe je met die beperkingen omgaat.
En dat verhaal laat zich helaas wat minder gemakkelijk verkopen in een PowerPoint-presentatie.
Ontdek meer van IT realiteit
Abonneer je om de nieuwste berichten naar je e-mail te laten verzenden.