Laura Santeusanio
Regional Director Southern Europe
Een internationaal executive met ruim 20 jaar ervaring in het realiseren van bedrijfsgroei, marktuitbreiding en grootschalige transformaties in heel Europa. Bewezen General Manager met expertise in het opschalen van operationele processen, het bouwen van high-performing teams en het executeren van strategische plannen met meetbaar resultaat.
Belangrijkste punten:
Bij een recent, veelbesproken inbreuk op een fintech-bedrijf was er helemaal geen sprake van technische inbraak: aanvallers gebruikten een gehackt e-mailaccount van de overheid om klantgegevens op te vragen, en het bedrijf gaf deze gegevens vrij in de veronderstelling dat het verzoek legitiem was.
Het patroon zou zich maandenlang hebben voortgezet voordat iemand het doorhad, niet omdat één e-mail door een filter glipte, maar omdat het verificatieproces zelf geen manier had om een goed geauthenticeerde vervalsing te detecteren.
Technische e-mailverificatie (SPF, DKIM, DMARC) bevestigt dat een bericht afkomstig is van een echt domein. Het zegt echter niets over de vraag of de specifieke persoon die het verstuurde, daartoe bevoegd was, of dat het verzoek zelf rechtmatig was.
Verschillende van de meer dramatische details die nog steeds de ronde doen, zoals de exacte hoeveelheid gegevens, het bedrag van het losgeld en hoe lang het betreffende overheidsaccount gecompromitteerd was, zijn afkomstig uit de beweringen van de aanvaller zelf en zijn nog niet bevestigd door een officiële instantie.
De oplossing is niet een beter spamfilter. Het is een gedocumenteerde, verplichte verificatiestap voor precies dit soort verzoeken, een stap die op papier bestaat en ook daadwerkelijk wordt gevolgd wanneer de druk hoog is.
Wat er precies is gebeurd
De reconstructie die uit de onderzoeksjournalistiek naar voren is gekomen, is eenvoudig, en dat is precies wat het zo verontrustend maakt. Een aanvaller kreeg de controle over een e-mailaccount van een echte overheidsinstantie. Vanuit dat account stuurde deze persoon verzoeken om klantgegevens naar het fintech-bedrijf, gepresenteerd als verzoeken van wetshandhavingsinstanties. De verzoeken kwamen van een echt overheidsdomein, waardoor ze de technische controles doorstonden die normaal gesproken identiteitsfraude signaleren, en werden doorgestuurd via het normale proces van het bedrijf voor het afhandelen van verzoeken van overheids- en wetshandhavingsinstanties.
Het bedrijf beschouwde de verzoeken als legitiem en verstrekte de gegevens. Later beschreef het bedrijf het incident als een externe identiteitsfraude in plaats van een inbreuk op eigen systemen, en die voorstelling houdt stand bij nader onderzoek: er is geen openbaar bewijs van een netwerkinbraak en het bedrijf heeft verklaard dat klantgelden en kernsystemen nooit in gevaar zijn gekomen. Wat er wel is gebeurd, is een inbreuk op persoonsgegevens, en volgens de definitie van de AVG geldt dat ongeacht of er sprake was van inbreuk op slechts één server. Ongeautoriseerde openbaarmaking aan de verkeerde partij is een inbreuk, punt uit.
Een geverifieerde afzender is niet hetzelfde als een geautoriseerd verzoek
Het ongemakkelijke inzicht dat ten grondslag ligt aan dit incident, is er een waar de meeste organisaties nog niet volledig rekening mee hebben gehouden: authenticatie en autorisatie zijn verschillende kwesties, en bij de meeste openbaarmakingsprocessen wordt alleen de eerste gecontroleerd.
SPF, DKIM en DMARC zijn bedoeld om één vraag te beantwoorden: is dit bericht daadwerkelijk afkomstig van het domein waarvan het beweert afkomstig te zijn? Daar zijn ze goed in. Ze zeggen echter niets over de vraag of de specifieke persoon die het bericht heeft verzonden, bevoegd was om dit specifieke verzoek in te dienen, of de juridische grondslag waarop men zich beroept daadwerkelijk van toepassing is, of dat de omvang en aard van het verzoek overeenkomen met een legitieme aanvraag. Een gehackt account binnen een echt overheidsdomein komt zonder problemen door alle drie de controles heen. Het domein is echt. De persoon erachter is dat in dit geval niet.
Verzoeken van de overheid en wetshandhavingsinstanties gaan gepaard met een specifiek soort institutioneel vertrouwen dat deze kloof vergroot in plaats van verkleint. Een verzoek dat er officieel uitziet, wordt doorgaans sneller verwerkt en minder in twijfel getrokken, en dat is precies de aanname waarop een aanvaller rekent.
Het aspect dat complianceteams meer zorgen zou moeten baren dan de inbreuk zelf
Als er één frauduleuze e-mail doorglipt, is dat al een slechte dag. Wat hier naar verluidt is gebeurd, is anders: hetzelfde patroon van verzoeken zette zich onopgemerkt gedurende een langere periode voort. Dit gaat niet over één e-mail die door een filter is geglipt. Dit gaat over een verificatieproces dat geen mechanisme had om een goed geauthenticeerde vervalsing te detecteren, zelfs niet nadat deze al meer dan eens succesvol was geweest.
De meeste organisaties kunnen wijzen op een beleid waarin staat dat verzoeken van de overheid zorgvuldig worden behandeld. Veel minder organisaties kunnen aantonen dat het beleid een specifieke, verplichte stap bevat, zoals het bevestigen van het verzoek via een onafhankelijk contactkanaal, en niet via het kanaal dat in het verzoek zelf wordt vermeld, voordat er iets wordt vrijgegeven. Zonder dat die stap op papier staat en daadwerkelijk wordt gehandhaafd, verandert “zorgvuldig behandeld” stilletjes in “verwerkt zoals elk ander verzoek”, en merkt niemand het op totdat het al herhaaldelijk is gebeurd.
Wat is bevestigd, en wat is nog slechts een bewering
Verantwoord verslag doen van een incident dat zich op dit moment afspeelt, houdt onder meer in eerlijk te zijn over welke details vaststaan en welke nog niet. Op het moment van schrijven:
Redelijk zeker: een aanvaller heeft een gehackt e-mailaccount van de overheid gebruikt om frauduleuze verzoeken om klantgegevens in te dienen. Het bedrijf heeft daarop gegevens vrijgegeven, in de veronderstelling dat de verzoeken legitiem waren. De eigen systemen van het bedrijf en de gelden van klanten zijn niet aangetast. De autoriteiten doen onderzoek.
Gemeld door de media, maar niet officieel bevestigd: het specifieke aantal getroffen klanten en welk account van welke overheidsinstantie precies is gecompromitteerd.
Alleen door de aanvaller beweerd, niet geverifieerd door een officiële instantie: de totale hoeveelheid gegevens die naar verluidt is verkregen, de periode waarin het betreffende overheidsaccount naar verluidt gecompromitteerd was, en de eis tot losgeld. De gangbare praktijk op dit gebied is duidelijk: de beweringen van een cybercrimineel over wat hij in zijn bezit heeft, zijn marketing voor de afpersingspoging, geen bewijs, totdat een onafhankelijke instantie deze bevestigt.
Wat dit betekent als uw organisatie ooit een verzoek van de overheid ontvangt
Vrijwel elke gereguleerde organisatie, financiële dienstverlener, zorginstelling of telecombedrijf beschikt over een procedure om te reageren op verzoeken om gegevens van wetshandhavingsinstanties en overheidsinstanties, omdat de wet dit doorgaans voorschrijft. De vraag die dit incident oproept, is niet of die procedure bestaat. Het gaat erom of de procedure een daadwerkelijke controle bevat voor precies dit scenario: een verzoek dat volkomen legitiem lijkt, maar dat misschien niet is.
Een verstandige controle is in dit geval specifiek, niet algemeen. Iets in de trant van: voordat persoonsgegevens worden vrijgegeven in reactie op een verzoek van de overheid, de rechterlijke macht of wetshandhavingsinstanties, moet de identiteit en bevoegdheid van de verzoeker, de rechtsgrondslag voor het verzoek en de reikwijdte ervan onafhankelijk worden geverifieerd, met behulp van contactgegevens die onafhankelijk zijn verkregen in plaats van die welke in het verzoek zelf zijn verstrekt. Bij grote aantallen verzoeken of ongebruikelijke verzoeken is een verplichte tweede controle vereist voordat er iets wordt vrijgegeven.
Op papier klinkt dat voor de hand liggend. De reden waarom dit in de praktijk mislukt, is dat het zich zelden op een plek bevindt waar het intaketeam het daadwerkelijk meteen ziet, en dat het zelden wordt getoetst aan een verzoek dat er precies juist uitziet.
Ontdek hoe een dergelijke verificatiestap in uw complianceprogramma past
Breng uw eigen procedure mee voor het afhandelen van verzoeken van overheidsinstanties of wetshandhavingsinstanties, hoe informeel die op dit moment ook mag zijn. We laten u liever zien hoe u de controle kunt structureren dan dat we deze in abstracte termen beschrijven.
Hoe Formalize dit ondersteunt
Dit is eerder een controleprobleem dan een technisch probleem, en de rol van Formalize is ervoor te zorgen dat de controle daadwerkelijk bestaat, en niet alleen op papier staat in een beleidsdocument dat niemand opent als er druk op staat. In de praktijk betekent dit:
Een gedocumenteerde controle voor openbaarmakingen aan overheidsinstanties en wetshandhavingsinstanties, die naast uw andere controles staat in plaats van in een aparte beleidsmap, met een benoemde verantwoordelijke.
In de workflow ingebouwde verificatiestappen, zodat een verzoek vóór de openbaarmaking wordt getoetst aan vastgestelde criteria, en niet pas daarna.
Een verslag van wie een openbaarmaking heeft goedgekeurd en waarom, zodat als een verzoek later in twijfel wordt getrokken, de redenering al voorhanden is in plaats van uit het hoofd te moeten worden gereconstrueerd.
Dezelfde controle die in verschillende frameworks wordt hergebruikt, aangezien dit soort openbaarmakingsrisico’s verband houden met de AVG en vaak ook overlappen met verplichtingen onder frameworks zoals DORA of ISO 27001.
Niets van dit alles vervangt het eigen oordeel. Het zorgt ervoor dat het oordeel consequent wordt toegepast, elke keer weer, ook op het moment dat het er het meest toe doet.