Welke datasecurity-fouten maakte Ticketmaster?

In juni werd een ernstig datalek bekendgemaakt door Ticketmaster, waarbij mogelijk persoonlijke informatie en betalingsgegevens gestolen zouden zijn. Dit is het zoveelste bewijs dat zelfs grote online verkopers als Ticketmaster hun zaken niet goed op orde hebben op het gebied van privacybescherming. Waarom was de informatiebeveiliging van Ticketmaster ontoereikend? 

Sinds de privacywetgeving AVG van kracht is geworden, is elk bedrijf wettelijk verplicht om melding te maken van beveiligingsincidenten waarbij persoonlijke informatie van klanten zijn buitgemaakt. Voor een populair bedrijf als Ticketmaster is het des te pijnlijker dat het uitgerekend nu met de billen bloot moet. Zij kunnen de Autoriteit Persoonsgegevens, én uiteraard hun klanten, tegenwoordig niet meer afschepen met een algemene schuldbekentenis en de belofte om alle problemen op te gaan lossen. Ze moeten daadwerkelijk inzicht geven in de oorzaak van het datalek, zodat bepaald kan worden of de bescherming van privacygevoelige gegevens wel voldoende was. Nu de eerste details naar buiten komen staat één ding vast: de beveiliging van de infrastructuur van Ticketmaster is op zijn minst niet afdoende geweest.

Vingerwijzen is geen oplossing

Ticketmaster meldde het datalek vier dagen nadat het was ontdekt. Toen begon het grote wijzen: volgens Ticketmaster lag de bron van het probleem bij een op kunstmatige intelligentie gebaseerde klantenservice chatbot-service van het bedrijf Inbenta. Dit bedrijf reageerde op zijn beurt dat het lek in een stuk JavaScript-code zat, dat buiten Inbenta’s weten om door Ticketmaster geïmplementeerd was. Maar in plaats van op zoek te gaan naar de schuldige, zouden de betrokkenen zich eerder moeten afvragen waarom een third party app direct toegang had tot onversleutelde persoonsgegevens in de database.

Beperk de complexiteit

Bij de meeste databases werkt informatiebeveiliging voornamelijk op basis van algemene toegangscontrole. Ofwel: als je toegang hebt tot een bepaalde database, kun je daar in principe zonder beperkingen query’s op doen. Er zijn wel aanvullende producten op de markt om de beveiliging te verbeteren met uitgebreidere, en soms meer granulaire controles, maar dit maakt de beveiliging vanzelfsprekend nog complexer. Het mag in elk geval niet zo zijn dat een onveilig front-end product ertoe leidt dat de volledige back-end database op straat komt te liggen.

Security op dataniveau

Het is te hopen dat de AVG/GDRP, en het verplicht melden van datalekken, meer bedrijven de ogen doet openen om op een andere manier naar security te kijken. De oplossing voor het eerdergenoemde probleem is volgens mij om beveiliging en restricties in te bouwen op het laagste niveau van de infrastructuur: namelijk in de database zelf. Dit is mogelijk door een database te gebruiken waarmee gegevens op dataniveau beschermd kunnen worden, onder andere met functies als ‘redaction’. Hiermee kunnen bepaalde gegevens in de database verwijderd of gemaskeerd worden op het moment dat ze geëxporteerd of uitgewisseld worden met externe systemen. Het is zelfs mogelijk om specifieke gegevens in documenten maskeren. Een andere geavanceerde database beveiligings-feature is ‘compartment security’, waarmee datatoegang zoveel mogelijk beperkt kan worden door van gebruikers te eisen dat ze meer dan één rol nodig hebben om bepaalde gegevens te bekijken, en niet slechts één van de juiste rollen. Hierdoor is er dus niet langer slechts één sleutel die toegang geeft tot het hele huis, maar slechts een aantal kamers. Deze techniek wordt steeds meer gebruikt bij het beveiligen van vertrouwelijke gegevens in overheidssystemen, maar helaas niet bij Ticketmaster, dat vanwege kostenbesparing overstapte (zie afbeelding) naar een traditionele open source relationele database, zonder de bovengenoemde functies.

Controleer externe leveranciers

Het is geen verrassing dat de oorzaak van het datalek bij Ticketmaster te herleiden is naar software van een externe leverancier. Het grootste gedeelte van cybersecurityinbraken en datalekken komt namelijk uit die hoek. Nadat het datalek was geconstateerd meldde Ticketmaster binnen enkele dagen op zijn website dat het de bewuste applicatie had uitgeschakeld op alle websites van het bedrijf. Gevaar geweken, zou je zeggen. Zonder de datalekkende applicatie is er niets meer aan de hand, toch? Maar vergelijk het eens met je eigen huis. Als je een scheur in de muur ziet, ga je die dan alleen even plamuren en opnieuw verven? Of pak je het goed aan door de oorzaak van het probleem aan te pakken?