Een paar dagen later Booking, waar “onbevoegde derden” bij boekingsgegevens konden. Reactie, statement, onderzoek loopt. Zoals dat gaat. Alleen: het zijn geen klassieke hacks.

Niet in de Hollywood zin.

Basic-Fit: een miljoen ledenrecords via een bezoekregistratie

Basic-Fit zegt dat het datalek “binnen minuten” is gestopt. Klinkt geruststellend. Draai de zin om en hij leest anders: de aanvaller had aan minuten genoeg. Geen dagen. Minuten om binnen te zijn bij een systeem dat veel meer kon zien dan nodig was. Een registratie van wie er door de draaideur loopt, bleek óók bij IBANs te kunnen. De interessante vraag is niet hoe de aanvaller binnenkwam. Het is waarom dat registratiesysteem überhaupt bij die data mocht.

Booking.com: gestolen hotel-credentials, geldige toegang

Bij Booking zit het vergelijkbaar, maar dan een niveau verderop in de keten. Booking zelf is niet gehackt. Wat er wel gebeurde is dat hotelmedewerkers via phishing hun extranet logins kwijtraakten. Die accounts worden al maanden op ondergrondse fora verhandeld, ergens tussen tien en vijfduizend dollar per stuk (afhankelijk van hoe groot het hotel is). Iemand koopt er eentje, logt in met geldige gegevens en zit dan als “hotelier” in het systeem. Eentje die boekingen bekijkt, gasten aanschrijft en om betaalgegevens vraagt. Geen lek in de techniek. Geldige toegang, misbruikt.

Geen hack, wel een breach

En dat is waar beide zaken elkaar raken. Niet in hoe de aanvaller binnenkwam. Wel in wat het systeem hem liet doen toen hij binnen was.

Ik ben geen security engineer. Ik ben programmamanager, en ik doe Identity & Access Management. Dus ik praat weinig over exploits of zero-days en bijna elke dag over toegang. Wie mag wat, waarom, en hoe weet je over een maand nog dat het klopt. Minder spannend dan een hackthriller, maar waarschijnlijk wel waar het gat zit.

De interessante vraag is niet hoe de aanvaller binnenkwam. Het is waarom dat registratiesysteem überhaupt bij die data mocht.

Compliance heeft de antwoorden al. Het probleem is organisatorisch

Least privilege, dataminimalisatie, scheiding van operationele en gevoelige data. Ik zie het al vijftien jaar in elk beleidsdocument langskomen. Op papier standaard. In de praktijk iets wat altijd op de volgende release-planning staat. Een bezoekregistratie die meeleest in de ledenadministratie is geen technisch ongeluk. Dat is een ontwerpkeuze waar niemand in de keten aan de rem heeft getrokken. Een hotel extranet waarvoor één wachtwoord genoeg is, zonder gedragsdetectie op logins vanuit landen waar geen hotel zit, is een beleidskeuze die al jaren ingehaald had moeten zijn.

En de reden dat het niet gebeurt is zelden technisch. Bijna altijd organisatorisch. Wie is eigenaar van de rechten van dat ene koppelsysteem? Wie geeft akkoord als een integratie ineens vijf velden extra ophaalt “omdat het handig is voor het dashboard”? Wie voert het gesprek met de leverancier als de default “alles mag zien” is? In de meeste programma’s die ik zie is het antwoord “iedereen een beetje”. Wat in de praktijk neerkomt op niemand.

En dat is niet even een fout die je ergens repareert. Dat is gewoon hoe de meeste IT landschappen in elkaar zijn gegroeid.

Wat wél werkt

Wat helpt, is minder spectaculair dan het probleem. Iemand aanwijzen die beslist. Elke integratie doorrekenen op “wat ziet dit systeem dat het niet hoeft te zien”. De leverancier dwingen het onnodige eruit te halen, ook als de default anders was. Saai werk. En vooral veel van.

Klanten en leden merken uiteindelijk niet het verschil tussen een hack en een breach zonder hack. Die merken alleen dat hun IBAN ergens opduikt, of dat er in naam van hun hotel ineens vragen gesteld worden die ze nooit hebben gesteld. En dat vertrouwen krijg je niet terug door snel te reageren. Je krijgt het pas terug als “binnen minuten” niet meer de benchmark is, maar “nooit zo ver”.

Of tenminste, dat denk ik.

Ric van Westhreenen

Ric van Westhreenen

Programma Manager gespecialiseerd in IAM, digitale werkplek en digitale transformatie. Pragmatisch, hands-on, getting things done.

Verbind op LinkedIn →