Uber, maar voor hacking: Bug bounties zijn niet zonder risico.

U hebt het ongetwijfeld gehoord: Uber werd gehackt in Oktober 2016. Er heerst veel onduidelijkheid over de situatie, daarom zetten we een aantal feiten op een rij:

  • Uber werd in november 2016 op de hoogte gebracht van het feit dat aanvallers AWS sleutels vonden en hiermee toegang kregen tot onder meer private data van klanten.
  • Uber betaalde daarop $100.000 en regelde een Non Disclosure Agreement met de betrokken personen, met daarin ook de afspraak dat de gegevens verwijderd zouden worden.

Terwijl het nieuwsbericht op z’n minst sensationeel te noemen is, zijn er een aantal zaken belangrijk om nader te bekijken. Er zijn de laatste jaren namelijk verschillende publieke gevallen geweest waar het effect op de betrokken bedrijven niet altijd onverdeeld positief was. Facebook in 2015 en zeer recent DJI, de Chinese drone producent, zijn hier voorbeelden van.

Bug bounties : niet zonder risico

De laatste jaren zagen we steeds meer bug bounties verschijnen. Dit zijn tijdelijke of permanente projecten waar bedrijven ethische hackers uitnodigen om hun applicaties en infrastructuur te testen. In ruil voor de confidentiële rapporten bieden de bedrijven soms relatief hoge bedragen. Ook Uber runt zo’n programma en heeft daar ongetwijfeld goede resultaten mee behaald.

Bij het overwegen van een bug bounty is het altijd belangrijk om de regels duidelijk te documenteren. Welke systemen mogen getest worden? Welke zeker niet? Welke acties zijn toegelaten of verboden? Het moet voor alle betrokkenen duidelijk zijn, zodat er tijdens de interactie met de ethische hackers en de bredere security community geen frustratie ontstaat.

In het geval van Uber werden gevonden toegangssleutels gebruikt om data te downloaden. Ethische hackers zouden kunnen zeggen dat dit nodig was om de impact van hun vondst te illustreren maar in principe is het voldoende om de gevonden sleutels te tonen.

Er zijn enorm grote voordelen aan het starten van een “bug bounty program”, maar “bezint eer ge begint”. Het is altijd nuttig om de interne processen hierrond te evalueren.

Data breach of niet?

Je zal het maar meemaken. Dan werk je enthousiast samen met de security community en ontdek je dat een hoeveelheid data door een van de ethical hackers werd gevonden. Is dat nu een data breach?

We horen momenteel het argument dat binnen geijkte processen dit niet als een breach moet geïnterpreteerd worden. Dat lijkt ons een beetje vergezocht. Als een personeelslid na een meeting met een externe partij een USB-schijf met persoonlijke data verliest, is dit ook een data breach. Toch?

In functie van de GDPR, waar we allemaal ongetwijfeld mee bezig zijn, is dit een zeer pertinent vraagstuk. Voor ons geldt het principe “als persoonlijke gegevens verkregen worden door externe niet-geautoriseerde partijen, dan is het een breach” en dus moet dit altijd gerapporteerd worden.

Natuurlijk is de eerste reactie in zo’n geval paniek, maar net daarvoor implementeren we de nodige processen die ons een plan van aanpak bieden. Indien we ons hier aan houden, dan kunnen we de nodige voorbereidingen treffen en ervoor zorgen dat alle betrokken partijen duidelijkheid hebben.

Wat brengt de toekomst?

Zonder twijfel zullen er de komende weken verhitte en publieke discussies plaatsvinden over het nut van bug bounties, de definitie van een data breach, en het risico rond penetration testing in het algemeen.

Bij SpotIT zijn wij ervan overtuigd dat een juiste inschakeling van offensive security nodig is om infrastructuren en applicaties beter te beschermen. Zowel via bug bounties als via meer traditionele penetration testing activiteiten. Met de juiste ervaring, duidelijke afspraken en processen zullen bedrijven meerwaarde blijven halen uit deze activiteiten.

Anderzijds zijn we ervan overtuigd dat bedrijven zich continu moeten voorbereiden op een eventuele data breach. Het is niet voldoende om de processen te beschrijven en ze pas uit de kast te halen als een breach zich voordoet. Via het uitvoeren van table top exercises waar bepaalde scenario’s uitgevoerd worden alsof ze echt gebeuren, kunnen bedrijven hun processen testen en de betrokken personeelsleden continu opleiden. Het mag niet langer een bijkomstigheid zijn. Het moet een prioriteit worden en deel uitmaken van een totale security strategie

Ten laatste is het belangrijk om op te merken dat hackers voortdurend op zoek zijn naar paswoorden en toegangssleutels. Die worden regelmatig gevonden in applicaties, publieke code repositories, of via social engineering. Evalueer daarom op regelmatige basis of u zelf nog in controle bent van alle sleutelmateriaal.

Neem gerust contact op bij extra vragen over deze topics.

Lees ook meer over GDPR en Penetration Testing