Bug bij betaaldienst Klarna geeft duizenden klanten toegang tot andere accounts

Door een bug bij betaaldienst Klarna hebben meer 9500 klanten een half uur lang toegang gekregen tot de accounts van een willekeurige andere gebruiker. Dat heeft de betaaldienst in een reactie laten weten. Volgens Klarna konden zij hierdoor enkel ongevoelige data inzien.

De bug vond donderdag rond 11 uur plaats, laat Klarna in een uitgebreide reactie weten. 31 minuten lang kregen tot 9500 gebruikers na inloggen toegang tot niet hun account, maar die van een willekeurige andere gebruiker. Volgens Klarna was er geen gevoelige data zichtbaar, zoals bank- of creditcardgegevens.

De bug ontstond nadat Klarna een kwartier eerder een update uitrolde, en Klarna noemt het een menselijke fout. Volgens het bedrijf is er geen externe breuk geweest in het systeem. Volgens het bedrijf werd de bug snel ontdekt en 31 minuten nadat deze geïntroduceerd werd, was deze gefikst. Klarna onderzoekt nu welke gebruikers precies geraakt zijn door de bug.

De update van Klarna sluit niet helemaal aan bij klachten die gebruikers eerder meldden. Zo zegt een gebruiker op Twitter toegang te hebben tot alle informatie die willekeurige andere gebruikers in hun account opgeslagen hebben, waaronder gedeeltelijke bankgegevens, adressen, telefoonnummers en aankopen. Zij zegt gegevens van zeker twintig andere accounts te hebben gezien.

Reacties (56)

De update van Klarna sluit niet helemaal aan bij klachten die gebruikers eerder meldden. Zo zegt een gebruiker op Twitter toegang te hebben tot alle informatie die willekeurige andere gebruikers in hun account opgeslagen hebben, waaronder gedeeltelijke bankgegevens, adressen, telefoonnummers en aankopen. Zij zegt gegevens van zeker twintig andere accounts te hebben gezien.

Toegeveogd dat Klarna claimed dat deze gegevens niet vallen onder de AVG...
https://twitter.com/esraefe/status/1397961096674299905
https://www.klarna.com/uk/blog/written-statement-on-app-bug/

In de screenshots is niet te zien dat er (al dan niet geblurred) gegevens te zien waren, tuurlijk voornaam +bedrag is niet netjes maar vanuit AvG niet te herleiden tot persoon en dus geen persoonsgegevens. Is er meer zoals achternamen, volledige bank details(dus niet alleen laatste drie cijfers) dan is het wat anders

Ja, maar een reactie iets verderop geven ze toch toe dat er mogelijk een paar gebruikers meer hebben kunnen zien: https://twitter.com/AskKlarna/status/1397912074630569985

PS: Wel apart dat de Sonya en Kristel in de screenshots exact hetzelfde moesten betalen/hadden openstaan.

Dat klinkt als een mogelijke oorzaak van de bug.

Dat is helemaal niet wat Klarna claimt. Klarna stelt het volgende: ''Even though GDPR would classify the information visible as “non-sensitive”, for Klarna all data is important''. Daarmee zegt Klarna met zoveel woorden dat het wél persoonsgegevens zijn in de zin van de AVG, maar dat zij de betreffende persoonsgegevens niet hebben aangemerkt als 'gevoelig' (wat daar verder ook van zij). Het zijn hoe dan ook persoonsgegevens en deze bug zal sowieso moeten leiden tot een datalekmelding bij de toezichthouder.

Gevoelige gegevens zijn een aparte categorie onder de AVG en gaat over bijvoorbeeld medische gegevens of lidmaatschap van een politieke partij. Je adresgegevens worden niet als zodanig geclassificeerd.

Neen, dat zijn bijzondere persoonsgegevens. Daarvoor geldt inderdaad een ander regime onder de AVG. Dit valt in principe gewoon onder de categorie ‘reguliere’ persoonsgegevens.

Het lijkt er eerder op dat het bedrijf zich beter wil voordoen door te suggeren dat het volgens de gdpr niet de meest gevoelige persoonsgegevens betrof.

Die gevoelige persoonsgegevens, zoals gezondheidsgegevens of geloof, hoort het bedrijf waarschijnlijk niet eens te verwerken.

Daarbij stelt de gdpr al dat persoonsgegevens hoe dan ook belangrijk zijn, dus het hoort niet het verschil te maken om het als bedrijf belangrijk te vinden.

Zo, das wel een forse. Tijd voor beste test procedures?
Vrees dat de medewerker die die update heeft gemaakt een zwaar gesprek te wachten staat ...

Ik blijf het spijtig vinden dat mensen blijven denken dat iemand die een fout maakt zwaar moet aangepakt worden. Dat is gewoon de verkeerde manier van managen. Tenzij iemand zwaar nalatig is geweest of een ernstige opzettelijek fout heeft gemaakt is het belangrijker om te achterhalen hoe het is kunnen gebeuren en de procedures aan te passen om herhaling te voorkomen.

Een no blame culture is belangrijk voor werknemers om met fouten naar voren te durven komen.

Helemaal eens. Alleen een "no blame" cultuur moet niet doorslaan in een "no responsibility/accountability" cultuur.

Helemaal eens. Alleen een "no blame" cultuur moet niet doorslaan in een "no responsibility/accountability" cultuur.

Mee eens, maar ook een 'blame cultuur' kan daar toe leiden. Ik heb gewerkt in een bedrijf waar de lijken traditioneel pas uit de kast rolden bij periodieke functioneringsgesprekken, en bij sommige managers zo echt een afrekencultuur was ontstaan. Mensen die op tijdelijke contracten werkten en vlak voor hun contract voor onbepaalde tijd in eens [x] ongeschikt waren. De keerzijde daarvan was, dat -naast een op sommige afdelingen volledig verklootte werksfeer- mensen gewoon geen verantwoordelijkheid meer namen over hun taken en/of acties. En bij falen wees men naar boven, opzij of naar beneden. Duck & cover was daar eerder regel dan uitzondering.

Als interne auditor (t.b.v. ISO certificering) werd ik van hogerhand regelmatig 'vriendelijk' verzocht bepaalde constateringen af te zwakken in de rapportages, en bepaalde audits verliepen enorm stroef omdat mensen de angst hadden er achteraf op afgerekend te worden, terwijl het doel was juist is te zien of de procedures wel aansloten bij de werkmethodes, niet andersom. Uiteindelijk kostte dit de QHSE manager, die de eindverantwoordelijke was voor het bewaken van de ISO certificeringen, zelfs de kop. Ik ben blij dat ik daar al weer drie jaar geleden weg ben gegaan.

Helemaal eens. Alleen een "no blame" cultuur moet niet doorslaan in een "no responsibility/accountability" cultuur.

Over het algemeen straft een ontwikkelaar zichzelf al meer dan genoeg. Zodra dat niet meer het geval is heb je inderdaad een serieus probleem maar ook dat zal een systemisch probleem zijn wat niet opgelost wordt door iemand te slachtofferen...

Eens

Oh, absoluut niet. Een no blame cultuur heeft als doel het aanmoedigen van het melden van problemen ipv het aanmoedigen van deze onder de mat te vegen. Het einddoel moet zijn betere procedures te bekomen om herhaling van fouten tegen te gaan. Dat is uiteraard iets anders dan zeggen dat je nooit verantwoordelijk gehouden kan worden. En daarom dat in zo een cultuur mensen alsnog gestraft kunnen worden wanneer duidelijk wordt dat zij nalatig zijn geweest, maar dus niet wanneer een fout voortkomt uit het volgen van procedures die niet goed genoeg waren.

Ik vind het dan weer spijtig dat bij fouten gelijk naar management wordt gewezen. IT-ers zijn professionals en geen mensen tegen wie gezegd moet worden hoe ze een werk moeten doen door management. Zwaar aanpakken is dan ook weer zinloos want je moet leren van fouten. Maar dat doe je ook niet door de schuld op verkeerd managen te schuiven.

Iedereen is een professional in zijn of haar vak. Dus het argument "IT-ers zijn professionals" heeft geen inhoud. Het is de taak van het management om te zorgen dat een afdeling, bijvoorbeeld afdeling codekloppen, tijdig en binnen budget een bepaalde taak afrond. Bijvoorbeeld implementatie van een nieuwe functie.

Zodra 't implementeren klaar is moet er een ander proces gaan lopen, namelijk testing en klaarmaken voor release. Dat kan wellicht diezelfde afdeling doen, maar er moet wel iemand van management leiding/controle houden over het proces. Iemand moet uiteindelijk het licht op groen zetten.

Als er dan zoals hier iets mis gaat, dan heeft er toch een leidinggevende persoon hier een steekje laten vallen. De programmeur die de bug heeft geïntroduceerd heeft een fout gemaakt. De test procedure is blijkbaar in adequaat. En het vrijgeven voor release was een foute keuze.

Kortom, een opeenstapeling van fouten. Zo'n "clusterfuck" is toch iets dat management moet overzien. En daar hebben ze hier gefaald. Misschien is er teveel vertrouwen geweest naar een afdeling of persoon. Misschien heeft management onvoldoende inhoudelijke kennis. Kan van alles zijn, maar uiteindelijk is het management diegene die de verantwoordelijkheid draagt.

Als je verantwoordelijkheid van een managementfunctie verwijderd dan heeft management geen functie meer. De hele taak van management is bewaking in de breedste zin van het woord.

Ik vind het dan weer spijtig dat bij fouten gelijk naar management wordt gewezen. IT-ers zijn professionals en geen mensen tegen wie gezegd moet worden hoe ze een werk moeten doen door management. Zwaar aanpakken is dan ook weer zinloos want je moet leren van fouten. Maar dat doe je ook niet door de schuld op verkeerd managen te schuiven.

Het is een wisselwerking natuurlijk.
Ooit een manager gehad die ALLES, maar dan ook ALLES micro managede.
Dan creëer je een kleuterklasje, "mag ikd, zal ik dat"
En zolang hij niet aangaf dat er iets (extra) moest gebeuren, gebeurde het niet ( en maakten we ook minder fouten )

no blame culture wil helemaal niet zeggen dat je de verantwoordelijkheid op het management afschuift. Het wil zeggen dat je samen onderzoekt hoe het is kunnen mislopen en je je procedures aanpast om herhaling in de toekomst te voorkomen. No blaim bestaat vooral om te voorkomen dat problemen onder de mat worden geschoven. Als jij een fout maakt maar er zelf niet veel aan kon doen omdat je de procedure hebt gevolgd, dan mag het ook niet zijn dat jij schrik moet krijgen voor je baan. Dan moet je uitzoeken hoe je de procedure kunt verbeteren alsook hoe die fout in de procedure is gekomen. Dat kan bijv. ook een gebrek aan kennis zijn van die mensen die de procedure hebben opgesteld of goedgekeurd. Als je bijvoorbeeld onderzoeken leeft van vliegtuigcrashes dan zie je maar al te vaak dat ze het gevolg zijn van vele kleine fouten. Er is meestal niet 1 enkele persoon als verantwoordelijke aan te duiden. Toch zie je vaak mensen roepen dat er 1 zondebok moet zijn, dat die op staande voet ontslagen moet worden.

Aan de andere kant mag het natuurlijk ook geen excuus zijn om slecht werk te leveren, om nalatig te zijn. Daar is het ook niet voor ontworpen.

Inderdaad, ben al wat ouder en heb twee wat oudere kinderen. Ik bekijk het altijd maar op die manier, je kinderen leren ook helemaal niets van zwaar straffen. Worden ze alleen maar stiekem van en durven niets meer te vertellen, in een bedrijf is dat niet anders.
Het is wat anders wanneer iemand keer op keer moedwillig met de pet er naar gooit, dan past iemand gewoon niet in de functie. Maar fouten gebeuren, gewoon van leren en volgende keer zorgen dat het beter gaat.

Ik heb eens gehoord van een manager van de ING dat sinds ze een no blame culture hebben toegevoegd alleen maar positieven hebben meegebracht. Werknemers zijn tevredener, werksfeer is significant verbeterd en eventuele fouten komen veel eerder naar voren en wordt ook aangemoedigd om deze te melden. Het is bijna alsof mensen staan te springen om fouten te erkennen. Klinkt misschien gek maar het is alleen maar hosanna.

De andere kant van de munt waar mensen dan over spreken (expres fouten maken bijv.) is een rare redenering want als dat het geval zou zijn zou het niet uitmaken wat voor cultuur er heerst.

Even ter duidelijkheid : Ik haat de cultuur waarin ze mensen zo hard aanpakken. Maar ik vrees wel dat het nog veel te vaak gebeurd. Als een developer een fout als deze maakt en je test engineers hem niet oppakken gaat er gewoon in je hele bedrijf iets grondig mis.

Ja en dat is dan dus niet aan die persoon of personen maar aan de organisatie tenzij er specifieke procedures genegeerd zijn. Het is heel makkelijk om schuld op een persoon te schuiven maar als je processen dit soort fouten toelaten, en die acht je niet acceptabel, dan moet je dat oplossen. De betreffende medewerker zal zich er al kl*te genoeg over voelen

Aangezien personen de organisatie vormen en niet duidelijk is of deze fout via procedures en voldoende kennis voorkomen had moeten worden blijft het raden wat nodig zou zijn.

Hier zou geen test engineer aan te pas mogen komen. Buiten het schrijven van de geautomatiseerde test dan.

Dit soort dingen hoort in een CI proces ondervangen te worden. Als je dit nog handmatig gaat testen van vertrouw je er op dat ook de test engineer nooit fouten maakt.

Juist integratietesten zijn niet altijd te ondervangen met CI testen. Bij elke change kunnen er nieuwe edge-cases ontstaan, die nog niet in je unit- en CI-testen zijn ondervangen. Een goede ervaren tester kan dan beter even 'kijken' dan vertrouwen op alle teststraten (met blinde vlekken).

Juist integratietesten zijn niet altijd te ondervangen met CI testen. Bij elke change kunnen er nieuwe edge-cases ontstaan, die nog niet in je unit- en CI-testen zijn ondervangen. Een goede ervaren tester kan dan beter even 'kijken' dan vertrouwen op alle teststraten (met blinde vlekken).

Daar heb je zonder meer gelijk in. Automatiseren is goed, controleren is beter ;-)
Met uiteraard als doel deze nieuwe edge cases ook gewoon te automatiseren....

Volgens mij was het Edsger Dijkstra die de uitspraak deed dat unit tests niet de afwezigheid van bugs bewijzen maar enkel de aanwezigheid van bugs. Ik denk dat je dat ook wel kan toepassen op integration tests en test engineers. Uiteindelijk is elke test procedure niet meer dan hopen dat je de bugs vind voor de ze in productie terecht komen.

Achteraf denk je bij zoiets dat het makkelijk in een CI proces was ondervangen maar dan moet je er wel net aan denken om er de juiste test voor te schrijven, we kunnen er dan ook wel vanuit gaan dat dit nooit meer bij Klarna gaat gebeuren.

Achteraf denk je bij zoiets dat het makkelijk in een CI proces was ondervangen maar dan moet je er wel net aan denken om er de juiste test voor te schrijven, we kunnen er dan ook wel vanuit gaan dat dit nooit meer bij Klarna gaat gebeuren.

Yup. De hele crux van testen is altijd dat je er aan moet denken een specifiek iets te testen.(of eigenljk: Dat je je moet realiseren dat iets een risico is...)
De truuk met automatische tests is dat wanneer je er één keer aan denkt, je er nooit meer aan hoeft te denken. Daarmee is het een stuk beter dan een menselijke test waarbij je er iedere keer weer aan moet denken.

Unit testing, code reviews, voldoende middelen om die fouten te ondervangen lijkt me. Geen reden inderdaad om de ontwikkelaar persoonlijk aan te pakken. Ik neem aan dat die betaaldienst niet op 1 ontwikkelaar draait dus een fout van één is een fout van allen.

Als ze het goed doen pakken ze de procedures aan en niet de developer. Zeker bij een financiële instantie zoals Klarna zou je verwachten dat er meerdere rondes van tests overheen gaan voordat een update uitgerold wordt. Alleen wanneer iemand doelbewust procedures omzeilt wordt het persoonlijk.

Ik vrees alleen dat je gelijk hebt en mensen die fouten maken worden aangepakt, zonder naar de procedures te kijken.

Dit kan nooit deze ene medewerker alleen kwalijk worden genomen. De QA is gewoon niet op orde.

Zou jammer zijn als Klarna het probleem afschuift op 1 persoon en weer doorgaat alsof er niets aan de hand is.

Als er slechts 1 medewerker de update heeft gemaakt, dan is het de manager die ontslagen moet worden. Bij een financiële instelling zijn veel regels en 1 daarvan zou moeten zijn dat de code getest en gereviewed wordt door iemand anders. Daarbuiten heb je de beheersorganisatie die een update moet controleren.
Een medewerker zou nooit de optie moeten hebben geld door te sluizen naar een eigen account of iets dergelijks doordat er niemand anders naar de code kijkt.

[Reactie gewijzigd door rko4u op 28 mei 2021 08:29]

Want met een dergelijke aanpak:
* Zal deze medewerker of een collega deze fout niet (nog een keer) maken?
* Wordt de fout in de toekomst voorkomen?
We weten ook nog eens de context niet, het zal vast ook niet opzettelijk zijn of zo.

Ik vind het heel merkwaardig dat een bedrijf beslist over wat gevoelige informatie is.
Zonder daadwerkelijk te melden wat er zichtbaar is geweest. Die onduidelijkheid vind ik niet oke, en ik vind dat ze zich er makkelijk vanaf maken.

Volgens Klarna konden klanten alleen ongevoelige data zien, of zoals in de uitgebreide reactie staat:

The bug led to random user data being exposed to the wrong user when accessing our user interfaces. It is important to note that the access to data has been entirely random and not showing any data containing card or bank details (obfuscated data was visible). Even though GDPR would classify the information visible as “non-sensitive”, for Klarna all data is important. We are taking this incident very seriously and we will work tirelessly to regain the affected consumers’ trust.

At 11:04 am CET this morning we discovered that an update introduced 15 min earlier had led to an error affecting our app users. Our payment services, the Klarna Card, the merchant checkouts and the merchant’s user interfaces, were completely unaffected by this. At 11.20.42 am CET the error was deemed to be contained and fixed


Voor een persverklaring is dit niet extreem gedetailleerd maar ook niet echt onduidelijk. Het is voor zover ik weet voor niet-tech bedrijven en ook voor veel tech bedrijven niet gebruikelijk om alle technische details vrij te geven

Niet gebruikelijk maakt het nog niet terecht. ik kan misschien wel invullen wat ze bedoelen maar ik zou dat niet al moeten weten of moeten onderzoeken, dat zou voor iedereen die betrokken kan zijn of die klarna gebruikt duidelijk moeten zijn. Klarna kan en zou duidelijke informatie moeten verschaffen.

De basis van onze huidige privacywetgeving is inderdaad dat iemand voor zichzelf kan bepalen wat er met zijn persoonsgegevens gebeurt. Dus zelf bepaalt wat gevoelige gegevens zijn.

Als uit de betaalgegevens blijkt dat iemand een fietsband heeft gekocht is dat niet gevoelig. Als daaruit blijkt dat het een vibrator en een SM-pakje waren wel. Tenminste, dat zou mijn persoonlijke afweging zijn.

De basis van onze huidige privacywetgeving is inderdaad dat iemand voor zichzelf kan bepalen wat er met zijn persoonsgegevens gebeurt. Dus zelf bepaalt wat gevoelige gegevens zijn.

Iedereen kan bepalen wat er met zijn persoonsgegevens gebeurt. Er is centraal bepaald wat "persoonsgegevens" zijn. Je eerste stelling is juist, je tweede volgt daar niet uit en is niet juist.

Als uit de betaalgegevens blijkt dat iemand een fietsband heeft gekocht is dat niet gevoelig. Als daaruit blijkt dat het een vibrator en een SM-pakje waren wel. Tenminste, dat zou mijn persoonlijke afweging zijn.

Als uit de betaalgegevens blijkt dat *iemand* een vibrator gekocht heeft is dat voor niemand interessant.

Het feit dat er volgens GDPR geen gevoelige informatie vrij gekomen is betekend ook dat er geen naam bij stond. Jij zou dus wellicht hebben kunnen zien dat er een vibrator gekocht is maar niet door wie. En dus is het niet interessant.

Yep. Beide formuleringen waren te kort en daardoor niet juist.

De AVG spreekt inderdaad niet van 'gevoelige' gegevens omdat het niet aan de rechter of de wetgever is om voor iemand anders te bepalen wat gevoelig is.
En inderdaad is het niet gevoelig dat iemand een vibrator heeft gekocht, behalve wanneer 'iemand' te herleiden is tot een concreet persoon.

Het is verbazend weer te lezen dat als ze zelf een lek melden, dat er niks te zien was. Maar tegendeel waar is... De geloofwaardigheid is al laag, en nu zeg ik tegen mijzelf bij het lezen van 'er was geen gevoelige informatie zichtbaar' "jaja, dat zal wel" SMH

Waarmee jij dus zegt dat de woorden van één twitter gebruiker meer waarde hebben dan de woorden van een groot bedrijf.

Laten we eerst eens afwachten voordat we, op basis van één twitter gebruiker, een heel bedrijf voor leugenaar uit maken.

Als ik een ding niet meer vertrouw, is het wel de media. Hoevaak die dingen moedwillig verdraaien of weglaten van cruciale informatie. Maar toegegeven, je hebt een punt. Echter heeft het bedrijf vaker baat, bij het verzachten van de situatie dan die random twitteraar.

Als ik een ding niet meer vertrouw, is het wel de media.

De enige partij in deze die zonder twijfel onder de noemer "Media" valt is deze website.
Dan is er nog een partij die met wat moeite er ook onder zou kunnen vallen: Twitter.
Klarna valt zonder twijfel *niet* onder de noemer "Media".

Wat je dus in feite zegt is dat je dit bericht van Tweakers niet vertrouwd, dat je het twitter bericht niet echt vertrouwd maar dat je de uitspaak van Klarna wel vertrouwd? Heb ik het zo goed samen gevat?

[Reactie gewijzigd door Croga op 28 mei 2021 08:55]

Dat laatste, je zit ernaast. Bedankt voor het lezen.

Zij zegt gegevens van zeker twintig andere accounts te hebben gezien.
Want twee accounts was niet genoeg om te zien dat er een probleem was?

Ongevoelige data in de ogen van Klara kunnen best de gegevens zijn die de betreffende gebruiker heeft ingezien, behalve dan de aankopen... Tuurlijk, het zijn persoonsdata maar mij lijkt dat Klara snel gereageerd heeft door dit in een half uur te fixen....

Of die persoon probeerde door te gaan totdat de eigen gegevens ingezien konden worden. Je verwacht toch niet dat iets op zo'n manier stuk is?

Ik wilde net zeggen, dit moet toch gewoon gemeld worden als datalek?

In hun eigen verklaring staat dat de dat gedaan hebben:
“ Since then we have identified the root cause, started communications efforts, rolled back the bug, prepared to take the systems live again, and informed appropriate authorities”

een gebruiker meldt wél gevoelige data te hebben gezien, maar als klarna zegt van niet, blijft het dan gewoon hierbij? geen klein onderzoekje of iets, naast te kijken welke accounts zijn getroffen?

[Reactie gewijzigd door Yinko op 28 mei 2021 08:05]

Een datalek kan gebeuren, dat levert niet direct tonnen boete's op.. Tenzij er echt iets goed mis is binnen zo'n organisatie. Als je een lek netjes meld en terugkoppelt naar het AP dan volgt er vanuit het AP meestal geen onderzoek.

Klarna zal intern vast het nodige doen, want afgezien van het datalek zelf is dit natuurlijk slechte reclame.

Ze zullen dit moeten melden als een datalek, er zijn persoonsgegevens gelekt. Of dat 'gevoelige' gegevens zijn of niet, het zijn persoonsgegevens en daarbij is relevant of met de gegevens (direct identificeerbare gegevens of niet) een persoon geïdentificeerd kan worden of niet (wel of niet in combinatie met andere gegevens). Voor de ene persoon kunnen de gelekte gegevens meer impact op de persoonlijke levenssfeer hebben dan voor een ander, dat is dan minder relevant voor de melding.

Klarna is sowieso bij uitstek een vreselijk concept, en een "hotbed" voor internet criminelen die doen bestellingen doen op naam van gehackte accounts.

Helaas spreek ik uit eigen ervaring. Waardoor ik verschillende keren een aangifte heb mogen doen door een gehackt account van bijvoorbeeld Zalando.

Ik had het gelukkig op tijd door (Heb hier zelfs een heel artikel aan gewijd of het forum). en heb de schade kunnen beperken tot 0, maar niet iedereen is zo assertief als mij.

Vormen van AfterPay zoals Klarna mogen gewoon verdwijnen wat mij betreft, ter bescherming van de consument.

Door een bug bij betaaldienst Klarna

Er spelen hier minstens twee problemen.
Het eerste probleem is de bug uit het artikel.
Maar één bug zou niet zo'n vergaande gevolgen moeten hebben.
Het adagium in de beveiliging is "beveiligen doe je in overlappende lagen".
Dat doe je omdat je weet dat er nu eenmaal overal fouten worden gemaakt.
Daarom moet je het zo in richten dat één fout geen toegang kan geven tot zoveel gevoelige data.

Daarom moeten er dus minstens twee problemen zijn.
Als er geen overlappende lagen van beveiliging zijn dan is dat het tweede probleem.

Ik zal direct toegeven dat het makkelijk praten is. Het kan behoorlijk complex zijn dingen op meerdere manieren te beveiligen en het kan forse gevolgen hebben voor de werkbaarheid. Maar ik blijf het roepen omdat dit principe nog niet echt is doorgedrongen. Ik vraag bedrijven dagelijks hoe ze bepaalde zaken beveiligd hebben en hoewel er steeds meer maatregelen getroffen worden wordt er maar zelden nagedacht over hoe al die maatregelen samenhangen en of ze elkaar aanvullen.

Ik heb ook geen makkelijke antwoorden, maar ik wil toch nog even de boodschap herhalen: "Beveiliging bestaat uit meerdere overlappende lagen van maatregelen. Één fout zou nooit grote gevolgen moeten hebben".