Wat is een egress-audit en hoe voer je er zelf één uit?

Een egress-audit is een gerichte controle van al het verkeer dat jouw netwerk of apparaat verlaat — “egress” is Engels voor uitgaand verkeer [7]. Waar de meeste beveiliging zich richt op wat er binnenkomt, kijk je bij een egress-audit de andere kant op: welke systemen en applicaties maken verbinding naar buiten, met welke bestemmingen, en klopt dat met wat je verwacht? Het is dé manier om te betrappen dat gevoelige gegevens ongemerkt je organisatie verlaten — precies wat er bij data-exfiltratie gebeurt [6]. Je voert er zelf één uit in vier stappen: (1) schrijf op welke uitgaande verbindingen je toestaat (je allowlist), (2) leg het echte verkeer vast met een tool als tcpdump of Wireshark of via je firewall-logs [9], (3) vergelijk het vastgelegde verkeer met je allowlist en onderzoek elke onverwachte bestemming, en (4) doe de tegenproef door uitgaand internet te blokkeren en te kijken of de functie blijft werken. Hieronder werk ik elke stap concreet uit, met de valkuilen die ik in de praktijk tegenkom.

Dit artikel is zorgvuldig samengesteld en van bronnen voorzien, maar is geen juridisch advies. Leg beleidskeuzes altijd voor aan je eigen jurist, FG of DPO.

Wat is een egress-audit precies?

Egress-filtering is het controleren en beperken van het verkeer dat een netwerk verlaat, in tegenstelling tot ingress-filtering, dat over binnenkomend verkeer gaat [7]. Een egress-audit is de meetkant daarvan: je legt vast wélke uitgaande verbindingen een systeem daadwerkelijk maakt en toetst die aan wat je verwacht en toestaat. Het verschil met een gewone firewall-regel is belangrijk. Een regel zegt wat er mag; een audit bewijst wat er echt gebeurt.

Waarom is dat verschil zo groot? Omdat software zelden precies doet wat je denkt. Een “lokale” app kan stiekem telemetrie, crash-rapporten of modelupdates naar buiten sturen. Een browserextensie kan meelezen. En bij een inbraak sluizen aanvallers gegevens naar buiten — vaak binnen enkele dagen na de eerste toegang. Een egress-audit maakt dat zichtbaar door niet naar de belofte te kijken, maar naar de pakketten. In de kern beantwoord je één vraag: verlaat er iets mijn organisatie dat er niet uit hoort?

Waarom je hem nodig hebt: AVG en NEN 7510

De AVG verplicht je tot “passende technische en organisatorische maatregelen”. De Autoriteit Persoonsgegevens noemt daarbij expliciet logging en firewalls als technische maatregelen, en het beperken van wie toegang heeft tot gegevens [3]. Een egress-audit is precies zo'n maatregel: hij maakt controleerbaar dat persoonsgegevens niet naar onbedoelde bestemmingen weglekken. Dat sluit ook aan op het beginsel van dataminimalisatie — hoe minder gegevens rondgaan en naar buiten stromen, hoe kleiner het risico.

In de zorg maakt NEN 7510 dit concreter. De norm vraagt om logging en monitoring van netwerkverkeer, met realtime signalering bij verdachte activiteit zoals ongebruikelijke datavolumes of verkeer naar onbekende bestemmingen [4]. Ook het NCSC rekent netwerklogging en netwerksegmentatie tot de basismaatregelen die elke organisatie zou moeten nemen: leg netwerkverkeer vast, bepaal een “normaalbeeld” (baseline) en detecteer daarmee verdacht verkeer [2]. In zijn handreiking voor detectie-oplossingen wijst het NCSC specifiek op het monitoren van grote hoeveelheden uitgaand verkeer naar één bestemming en verkeer via niet-standaard protocollen als signalen die je wilt zien [1]. Een egress-audit is de gestructureerde manier om dat normaalbeeld op te bouwen en te toetsen.

Zelf uitvoeren in vier stappen

Je hebt geen duur netwerkapparaat nodig. Met gratis gereedschap en een halve dag kom je een heel eind. Dit is de methode die ik zelf aanhoud.

Stap 1 — Stel je allowlist op

Begin niet met meten, maar met verwachten. Schrijf per systeem op welke uitgaande verbindingen je toestaat en waarom: updateservers, een licentiecontrole, een back-updienst, e-mail. Alles wat je niet kunt verantwoorden, hoort in principe niet naar buiten te gaan. Deze lijst is je meetlat — zonder meetlat is elke meting stuurloos.

Stap 2 — Kies je meetpunt en leg verkeer vast

Je kunt op twee plekken meten. Host-based, op het apparaat zelf: op macOS en Linux gebruik je tcpdump op de command line, of Wireshark met een grafische interface om al het binnenkomende en uitgaande verkeer vast te leggen [9]. tcpdump is lichtgewicht en ideaal om snel en scriptbaar op te nemen; Wireshark is sterker in het achteraf uitpluizen en filteren van wat je hebt gevangen [10]. Een host-firewall met logging (zoals de ingebouwde pf op macOS of een tool die per proces uitgaande verbindingen toont) laat bovendien zien wélk programma de verbinding maakt. Netwerk-based, op je router of switch: hier lees je de firewall-logs of spiegel je een poort (SPAN) om het verkeer van meerdere apparaten tegelijk te zien. Voor één applicatie is host-based het scherpst; voor een heel kantoor is het netwerkpunt praktischer.

Stap 3 — Draai representatief gebruik en analyseer

Een audit is maar zo goed als het gebruik dat je nabootst. Zet je opname aan en loop de applicatie door al haar scenario's: opstarten, de zwaarste functie, opslaan, exporteren, afsluiten. Stop daarna de opname en analyseer. In Wireshark geeft Statistics → Protocol Hierarchy een overzicht per protocol, en met Statistics → Conversations zie je alle bestemmingen [9]. Filter eerst je eigen lokale netwerk eruit (verkeer binnen je LAN naar bijvoorbeeld een printer of NAS is geen egress); wat overblijft, gaat richting internet. Zet elke externe bestemming naast je allowlist. Elke verbinding die er niet op staat, is een bevinding — zoek uit welk proces hem maakt en met welk doel.

Stap 4 — Doe de tegenproef

De sterkste stap komt als laatste. Blokkeer uitgaand internetverkeer (of alleen DNS) en gebruik de applicatie opnieuw. Blijft de functie gewoon werken, dan heb je bewezen dat ze er lokaal voor draait en niets naar buiten nodig heeft. Valt ze stil of komt er een foutmelding, dan leunt ze op een externe dienst — en weet je meteen wat en waar. Deze “blokkeer-en-observeer”-proef verandert een momentopname in bewijs, want ze dwingt de software haar afhankelijkheden te tonen.

Dit is precies het principe waarop Verbinn is gebouwd: de verwerking draait op één Mac in je eigen pand (de Kern), en dat er geen woord van het gesprek naar buiten gaat, is na te lopen: de Kern laat zien welke uitgaande verbindingen er wél zijn, controleerbaar met exact de stappen hierboven. Het idee is dat je het niet hoeft te geloven omdat wij het zeggen, maar omdat je het zelf kunt narekenen.

En omdat we dat serieus menen, hier alvast wat je bij een geënrollde Kern wél zult zien staan, zodat je niet hoeft te gissen:

• Een beheertunnel naar onze relay-server, permanent open, zodat we op afstand kunnen helpen als er iets stukgaat. Draagt geen audio, geen transcript, geen verslag — en je kunt hem uitzetten.
• Een statushartslag, elke vijf minuten, met twintig geaggregeerde velden: versienummer, hoe lang de Kern draait, vrije schijfruimte, de lengte van de wachtrij, of de back-up geslaagd is. Geen namen, geen gesprekstitels, geen woord transcript. Welke velden dat precies zijn, ligt vast in de code.
• Een updatecheck, die kijkt of er een nieuwe versie klaarstaat.

Drie verbindingen dus, geen nul. Wie beweert dat een apparaat in een praktijk helemáál niets naar buiten stuurt, heeft meestal niet gemeten of vertelt niet het hele verhaal: dan is er geen beheer op afstand en geen beveiligingsupdate. De vraag die telt is niet of er uitgaand verkeer is, maar of er gespreksinhoud in zit — en of de leverancier per verbinding kan uitleggen waarvoor die er is. De Kern toont die lijst zelf op zijn beheerscherm, met de reden erbij, zodat je je eigen meting ernaast kunt leggen.

Wat je vastlegt en hoe vaak je herhaalt

Een audit die je niet vastlegt, is een gevoel — geen bewijs. Bewaar per meting: de datum, het geteste systeem en de versie, je allowlist, de ruwe opname (de pcap-bestanden), de lijst met gevonden bestemmingen en je conclusie per bevinding. Zo kun je later aantonen wat je hebt gecontroleerd en wanneer. Een onwisbaar, append-only auditlog is hiervoor ideaal: het bewijst dat de vastlegging achteraf niet is bijgewerkt.

Herhaal de audit op vaste momenten en na elke ingrijpende wijziging: een software-update, een nieuwe integratie of een gewijzigde firewallregel. Software verandert, en gedrag dat vandaag klopt kan na een update afwijken. Zorgorganisaties bewaren beveiligingslogs onder NEN 7510 bovendien langjarig, dus reken erop dat je auditbewijs een tijd relevant blijft [4].

Valkuilen en grenzen

Een egress-audit is krachtig, maar niet alwetend. Let op deze punten:

• Versleuteld verkeer verbergt de inhoud, niet de bestemming. Je ziet meestal wél naar welk IP-adres of domein een verbinding gaat, ook als je de inhoud niet kunt lezen. Voor een egress-audit is de bestemming vaak genoeg — het gaat om of er iets naar buiten gaat en waarheen.
• Meet lang genoeg. Sommige verbindingen ontstaan pas na uren (een geplande update, een nachtelijke sync). Een opname van vijf minuten mist die. Meet daarom ook over een langere periode of herhaal op verschillende momenten.
• Ken je normaalbeeld. Niet elke externe verbinding is fout. Besturingssystemen doen legitieme tijd- en updatechecks. Daarom bestaat de allowlist: onderscheid het bekende van het onbekende [1].
• Een audit is een momentopname. Hij bewijst het gedrag op het moment van meten, niet voor eeuwig. Vandaar de herhaling en de vastlegging.

Wil je begrijpen waaróm er bij cloud-diensten gespreksinhoud in dat uitgaande verkeer zit en bij lokale verwerking niet, lees dan het aanvalsvlak van cloud-AI vs. lokale AI. Een egress-audit is uiteindelijk het gereedschap waarmee je die vergelijking zelf hard maakt in plaats van aanneemt.