Externe partij veroorzaakt e-mailstoring GLS, melding bij AP gemaakt - update

GLS Netherlands laat tegenover Tweakers weten dat de e-mailstoring van gisteren inderdaad werd veroorzaakt door een 'externe IT-dienstverlener'. Grofweg 5000 gebruikers zouden door de storing onbedoeld e-mails met bezorg- en pakketinformatie van anderen hebben ontvangen.

De storing vond op dinsdagmiddag tussen 13.50 en 14.33 uur plaats; in dit tijdsbestek werden de foutieve mails verzonden. Het kan zijn dat getroffenen ook hierna nog mails ontvingen. Het probleem werd veroorzaakt door een update van een externe e-mailprovider, zo verduidelijkt Managing director Milo Kars tegenover Tweakers. Deze derde partij werd na signalering van het probleem verzocht om al het mailverkeer stop te zetten. GLS zegt dat deze dienstverlener vervolgens maatregelen heeft getroffen en dat het e-mailsysteem ondertussen weer gewoon werkt.

Ook zegt GLS Netherlands dat er een melding is gemaakt bij de Autoriteit Persoonsgegevens. Volgens Kars stonden in de mails NAW-gegevens, waaronder dus namen, e-mailadressen en adresgegevens. Er wordt 'op korte termijn' contact opgenomen met getroffenen. Alle 5000 getroffenen stonden in het systeem van GLS omdat zij eerder van de pakketdienst gebruikmaakten.

Dinsdagmiddag meldden meerdere gebruikers dat zij tientallen tot zelfs duizenden e-mails ontvingen, zowel van GLS Netherlands zelf als van andere partijen die gebruikmaken van de pakketbezorgdienst. Kars zei toen al tegen Tweakers dat het waarschijnlijk om een fout bij een externe partij zou gaan.

Update, 17.50 uur: Er is verdere informatie van Milo Kars aan het artikel toegevoegd, onder meer verduidelijking over wie er specifiek getroffen zijn en waar het probleem door veroorzaakt werd.

Reacties (22)

[swhnld]

GLS is de Eigenaar (Controller) van de persoonsgegevens.
De externe partij is de Verwerker (Processor) van de persoonsgegevens.

Als Eigenaar is GLS verantwoordelijk voor wat er met de data gebeurt en wordt geacht om daarvoor beveiliging in te bouwen in hun processen en organisatie, alsmede die eisen bij hun leveranciers te beleggen en te controleren.

De vraag hier is dan gelijk of GLS zijn werk goed gedaan heeft. Indien GLS dat allemaal goed gedaan heeft en het gaat fout, is het de derde partij die aansprakelijk gesteld wordt voor de schade.
Heeft GLS dat niet goed gedaan, zullen beide aansprakelijk zijn voor de schade.

Gaat de Autoriteit Persoonsgegevens deze zaak onderzoeken dan zal een of beide een boete krijgen als die hun zaken niet goed geregeld hadden.
Overigens kan er iets onvoorziens gebeurt zijn waardoor er besloten wordt geen of een hele lage boete op te leggen als het bedrijf zijn uiterste best gedaan had om dit risico te voorkomen..

[WouterL]

Verwerkers hebben zich bijna altijd ingedekt voor dergelijke boetes/aanspraken. Dat wil zeggen: de AP kan de verwerker dan een boete opleggen, maar die haalt dan zijn contractuele handje op bij GLS .

Dus hoewel ik de ontwikkeling toejuich dat de AP steeds vaker ook naar verwerkers kijkt, is het maar de vraag of dat echt zoden aan de dijk zet.

[Reactie gewijzigd door WouterL op 22 juli 2024 19:20]

[StefanJanssen]

Verwerkers hebben zich bijna altijd ingedekt voor dergelijke boetes/aanspraken.

Maken ze contracten waarin staat: "Als wij iets fout doen en we hiervoor een boete opgelegt krijgen wordt dit door jullie betaald"?

Ik neem aan dat hetgene waar ze zich voor indekken is "Wij gaan er vanuit dat alle data die wij van jullie krijgen legaal door ons verwerkt kunnen worden op de manier die wij hebben afgesproken".

In dit geval zou ik verwachten:
Als GLS de juiste data heeft doorgegeven aan de verwerker => De verwerker heeft zelf met de data geknoeid en is dus contractueel verantwoordelijk
Als GLS niet de juiste data heeft doorgegeven aan de verwerker => GLS heeft met de data geknoeid en de verwerker heeft gedaan wat ze contractueel moesten doen, mocht de verwerker een boete krijgen kan dit contractueel aan GLS worden doorberekend.

[WouterL]

Dat staat er inderdaad met zoveel woorden (soms) in dergelijke contracten. Dus zelfs indien de verwerker iets te verwijten valt kan het maar zo zijn dat er contractueel afspraken over gemaakt zijn over eventuele boetes en of aanspraken van derden.

Soms met een aansprakelijkheidsplafond, soms met een grove schuld/roekeloosheidsbepaling.

Er bestaat een ruime mate van contractvrijheid (behoudens zwarte en grijze bepalingen, zoals een totale uitsluiting van aansprakelijkheid bij opzet en of bewuste roekeloosheid).

De data die een verwerker krijgt van de verantwoordelijke hoeft een verwerker zich niet druk om te maken. Dat is een specifieke verantwoordelijkheid van de verantwoordelijke. De kern van de verwerker is nu juist dat de grondslag vraag voor hem niet van belang is. Maw is die niet legaal verkregen dan is dat altijd een probleem van de verantwoordelijke.

[Reactie gewijzigd door WouterL op 22 juli 2024 19:20]

[swhnld]

Dan zou GLS geen goede leverancier selectie gedaan hebben of contractonderhandelingen gevoerd.
Ik bedoel, wat denk je om iemand in te huren met de melding, als je de wet breekt betaal ik de boete, en ik betaal je daar ook voor. Over het algemeen zie ik het wel andersom geprobeerd worden.
Mijn oplossing is dan een cyber security verzekering er tegenover te zetten die dat risico deels afdekt. De eisen daaruit om die verzekering te krijgen zijn niet mals.

[WouterL]

Ik kan je verzekeren dat die verzekeringen vrijwel onbetaalbaar zijn. (als ze je al willen verzekeren, cyber security verzekeringen zijn geen vetpot voor verzekeraars)

Het is wat complexer dan dat natuurlijk; schuld is wat anders dan moedwillig 'de wet breken'. Het is geen strafrecht, opzet hoeft zeker niet in het spel te zijn. Het is ook een beetje een Calimero verhaal; staat het risico nog wel in verhouding met de contractwaarde? Daarom zijn zulke uitsluitingen helemaal zo gek nog niet.

En het hangt er inderdaad af hoe goed je dit hebt uitonderhandeld, of überhaupt kritisch naar de VWO hebt gekeken. Dat mag je lig wel van GLS verwachten, dat ze op hen afgestemde corporate standaarden gebruiken.

[Reactie gewijzigd door WouterL op 22 juli 2024 19:20]

[MikeN]

Je komt als verwerker ook eerder bij een beroepsaansprakelijkheidsverzekering uit dan een cyberverzekering. En dergelijke verzekeringen dekken zeker wel privacyinbreuken. Ja de premies worden steeds hoger en de eisen steeds strenger, maar het is zeker niet onmogelijk om deze risico's deels via een verzekering af te dekken, waarbij je de rest dan in de verwerkersovereenkomst regelt.

[Steenvoorde]

Externe IT dienstverlener of niet, GLS blijft verantwoordelijk voor de persoonlijke gegevens van hun klanten. Fouten kunnen gemaakt worden, maar meestal vinden dit soort issues plaats na een change. En het blijft gissen, maar een change die in dit geval niet (goed) getest lijkt te zijn.

In de applicaties waar ik verantwoordelijk op kantoor voor ben testen we elke change uitvoerig, inclusief de uitgezonden emails, in een (O)TAP straat. In de ontwikkel- en testomgeving zonder actieve SMTP server en in acceptatie met SMTP server en test records. We gaan pas live na akkoord van de klant, die natuurlijk betrokken wordt bij de tests. Ik vind het ook lastig te geloven dat GLS alles uitbesteed heeft en dus niets te zeggen heeft over de test procedures. Het klinkt eerder als verantwoordelijkheid afschuiven, om de schade naar hun klanten toe te beperken.

[Snow_King]

Ah, bij jullie worden nooit fouten gemaakt? Hoe uitvoerig je alles ook test, met honderd handtekeningen en akkoorden er onder, het kan gewoon fout gaan.

IT systemen zijn mega complex en hangen van heel veel processen en leveranciers aan elkaar.

Nee, ik vind het niet zo gek dat het gebeurd. Het is goed dat ze binnen 45 min hebben kunnen reageren om het probleem te stoppen. Dat is een nette reactietijd.

[Steenvoorde]

Natuurlijk maken wij ook fouten, maar die hebben we tot nu altijd kunnen afvangen met degelijke test procedures. En die zijn vervelend, saai om uit te voeren en kosten veel tijd (dus geld) maar het kost mijn werkgever nog veel meer geld als het mis gaat in een productie omgeving. Feit is dat de verzonden gegevens uit de database van GLS komen, daar kan je een externe email provider simpelweg niet de schuld van geven. En al zou de fout er toch doorheen geglipt zijn, dan zou een monitoring systeem de enorme pukkel SMTP verkeer van je applicatie servers moeten opmerken. En in die context is 45 minuten nog een best lange tijd imho. Je hebt het hier wel over privé gegevens van je klanten die je actief de wereld in slingert.
En als je dan ook nog de externe mail provider moet verzoeken om jouw SMTP verkeer te blokkeren, dan heb je iets echt niet op orde in je omgeving.

Maar wat ik zeg, het blijft gissen. Misschien heb ik het helemaal mis. Alleen weet ik uit ervaring dat changes vaak niet goed getest worden en als dit ook het geval wat bij GLS dan betalen ze bij deze een hoge prijs hiervoor. Ik zit er misschien een beetje fel is, maar ik heb recent ook een bestelling via GLS verzonden gekregen. Dus goeie kans dat mijn gegevens ook gelekt zijn. Maar geen nieuws van GLS in mijn mailbox, ik moet dit via Tweakers vernemen en ik vind dit kwalijk.

[Fenna]

En die zijn vervelend, saai om uit te voeren en kosten veel tijd (dus geld) maar het kost mijn werkgever nog veel meer geld als het mis gaat in een productie omgeving.

Naar mijn idee valt de kosten baten analyse juist altijd de andere kant op. Hoeveel tijd kost deze testen en dus hoeveel geld - kosten van datalek. Voor meeste bedrijven denk ik niet eens dat ze inzichtelijk hebben wat het precies kost en dus aannemen dat datalek goedkoper is.

Daarnaast wordt business beordeeld op resultaten. Dus nieuwe functie live brengen zo snel mogelijk is belangrijker dan alles in perfecte staat hebben. Dus die pushen graag door en dan achteraf wordt pas duidelijk dat het toch niet zo goed is.

[Steenvoorde]

Ik heb het hier niet perse over een datalek, maar ja dat zou kunnen voor veel organisaties. Echter, in ons geval is dat wel degelijk duidelijk. Als de productie stil valt door een fout, dan weten wij al wat dat kost. Daarbij kunnen er flinke boetes vanuit de overheid uit komen en die bedragen zijn ook voorgedefinieerd. Ook zouden grove fouten kunnen leiden tot persoonlijk letsel en in dat geval doen de kosten er helemaal niet toe, persoonlijke veiligheid is de allerhoogste prioriteit voor mijn werkgever. (Dat laatste ook omdat onze activiteiten door de overheid stilgelegd zouden kunnen worden als we die prioriteit niet zouden naleven)

[Jazco2nd]

Wat een onzin schrijf je. De externe leverancier draagt net zo veel verantwoordelijkheid. Standaard onder de AVG. Ze hebben dit netjes binnen de meldtermijn gemeld en opgelost. Je reactie is echt volstrekt onnodig. Mening doet er niet toe, zeker als het totaal haaks staat op wetgeving.

[Steenvoorde]

Onzin, als GLS M365 gebruikt als externe SMTP provider is Microsoft echt niet verantwoordelijk als de software van GLS verkeerde emails uitstuurt. En dat GLS het "netjes" gemeld heeft, doet niets af aan de grodheid van de fout. Dit is geen hack, maar GLS die actief persoonlijke gegevens lekt.

[Jazco2nd]

Als als als.
Feitelijk draagt zowel processor als controller verantwoordelijkheid. Dus inderdaad, ook zeker Microsoft.
Of GLS het systeem van hun vendor verkeerd heeft gebruikt en dus de veroorzaker is, is natuurlijk aan het AP om te beoordelen en daar zal Microsoft net zo goed aan moeten meewerken als GLS

[TwiekertBOB]

We weten niet hoe het exact zit maar als er een fout zit in de processen van de externe dienstverlener, waardoor deze gegevens op straat zijn komen te liggen, dan ligt de verantwoordelijkheid inderdaad bij GLS.

Zij zullen dus de melding moeten maken, want het betreft hun klanten en zij zijn de beheerder van de klantgegevens. Maar ze kunnen dan wel iedere claim verhalen op deze externe partij.

[lenwar]

In de basis klopt dat. Dat is een methode van werken. Als je in je acceptatieomgeving met kunstmatige data werkt, kan het zijn dat bepaalde type data onverwacht gedrag veroorzaakt.

Denk bijvoorbeeld aan spaties in e-mail adressen, dus bijvoorbeeld: “steen [e-mail]”. Conform de mail-standaarden een legitiem email adres.

Je code kan daar rottig mee om gaan, en als je er van niet op de hoogte bent dat dit mag, test je er mogelijk ook niet op. (De gebruikte mail libraries doen het prima, maar je eigen code allicht niet). Dan is je teststrategie mogelijk wel goed, alleen je testset incompleet.

Er zijn 20.000 redenen te bedenken waar zoiets als dit mis gaat. Dat is echt niet perse een ‘gebrekkige teststrategie’.


Het ‘afschuiven’ wat je beschrijft doen jullie zelf dus waarschijnlijk ook aan. Alleen richting jullie klanten. Stel dat de aanpassing die jullie hebben ontwikkeld toch een probleem veroorzaakt (kan altijd gebeuren), dan zullen jullie waarschijnlijk ook zeggen: “Sorry klant. Jullie hebben het zelf goedgekeurd!”

Onder aan de streep hebben de gedupeerden inderdaad niets te maken wie uiteindelijk de fout heeft gemaakt. De gedupeerden hebben een overeenkomst met GLS. Mocht er een schadevergoeding of een boete, dan is het aan GLS om dat te verhalen bij hun dienstverlener. En dat is ‘niet ons probleem’ 😊

[MvGroenigen]

Fouten maken prima.. slechte smoezen verzinnen dat dit door een externe dienstverlener veroorzaakt is niet.

Elke tweaker hier met een beetje verstand van mail systemen weet dat dit soort issues niet in mail systemen ontstaan.

Tenzij de GLS IT echt niets kan en de databases en alle mail generatie ook hebben uitbesteed aan een externe partij. maar dat strookt niet met: "werd opgelost door de externe e-mailprovider te verzoeken om al het mailverkeer stop te zetten. GLS zegt dat deze dienstverlener maatregelen heeft getroffen en dat het e-mailsysteem ondertussen weer gewoon werkt."

wat er waarschijnlijk is gebeurt is dat za aan hun relay service hebben gevraagt de mail te stoppen en daar alle nog niet bezorgde mail te deleten.

Wat ze even handig achterwege laten is dat ze daarna hun eigen programmatuur gerepareerd hebben.

Hoop dat de Autoriteit Persoonsgegevens ze keihard aanpakt. Fouten maken kan, maar er over liegen is juist wat de meldingsplicht hoort te voorkomen.

[MilanSxD]

Elke tweaker hier met een beetje verstand van mail systemen weet dat dit soort issues niet in mail systemen ontstaan.

Het is inderdaad niet gebruikelijk, maar het kan zeker wel gebeuren.
We weten het dus gewoon niet en kunnen er niet over oordelen.
Dat is aan de AP.

[crazyboy01]

Denk we nou allemaal niet een beetje te veel met een standaard achter-de-schermen IT bril op? Er zijn wel meer digitale leveranciers betrokken bij dit bedrijf dan die e-mail tak hoor. Wie weet wordt dat track en trace wel gedaan via een samenwerking of uitbesteding, dan is er dus gewoon een externe verwerker van persoonsgegevens waar dit lek uit naam van GLS kan gebeuren. De kans groot dat dat een combi is die door een leverancier samen met de e-maildiensten geleverd worden. Ben het ermee eens dat woorden als e-mailsysteem en e-mailprovider wel iets anders doen vermoeden, maar menig bedrijf wijst andere partijen ook zo aan die dát in beheer hebben náást (of als onderdeel van) een hele boel andere 'diensten'.

[Reactie gewijzigd door crazyboy01 op 22 juli 2024 19:20]

[mocean]

Technisch gezien vind ik deze bug wel interessant. Want hoe kan nu een klant-adres gekoppeld zijn aan een verkeerde levering, door een update? Verkeerde foreign-key in een release? Lijkt me dat je dat wel ziet in een test. Eventueel testdata gebruikt i.c.m. live gegevens? Ook niet heel waarschijnlijk. Half uitgevoerde update waar klantgegevens moesten worden geupdate? Lijkt me ook sterk midden op de middag.

Ben dus wel benieuwd naar details van de bug, al zullen we die wellicht nooit horen.

[pietervdstar]

Ik lees hier en in een veel over mailsystemen en dat die dit soort fouten niet kunnen maken, maar de term mailsysteem kan meer dekken dan alleen de stukken elektronica en software die mail routeert. Ik hoor diezelfde term ook vaak voor het nieuwsbrief- en/of overig klantencontactsysteem. In dat geval kan de fout dus best in het mailsysteem zitten. Even los van het feit dat de fout, waar die dan ook zat, er niet in had moeten zitten.

Daarnaast is de reactie van het bedrijf niet voor mensen die wat van IT weten maar voor iedereen, en waarschijnlijk zijn ook de details die wij hier interessant vinden niet bekend bij diegene die de reactie gaf. Dat we hier dan meteen over schadevergoedingen en boetes praten vind ik minder intressant.

Belangrijker vind ik dat we als verantwoordelijken voor dit soort systemen te horen krijgen wat er fout ging zodat we kunnen leren. Als iedereen meteen de spreekwoordelijke guillotine er bij haalt zorgt er denk ik voor dat bedrijven zoveel mogelijk gaan afschermen en met minimale of geen informatie komen. Ik zeg hier niet dat er niet naar een straf/schadevergoeding gekeken moet worden, maar laten we vooral van andermans fouten leren in plaats van financiëele winst proberen te maken.

[Reactie gewijzigd door pietervdstar op 22 juli 2024 19:20]