De gevolgen van identity en social engineering

(Blog) Recent kwam het nieuws naar buiten dat de Twitteraccounts van bekende politici en tech-beroemdheden waren gehackt. Onder hen voormalig president Barack Obama, democratisch presidentskandidaat Joe Biden, Tesla-CEO Elon Musk, Amazon-CEO Jeff Bezos en het account van Apple. Nepberichten vanuit tientallen accounts kregen sommige volgers zo ver om bitcoins te sturen – in de verwachting hun donatie dubbel terug te krijgen.

Twitter sloot de betrokken accounts en verwijderde de neptweets. Veel accounts konden zelfs een tijdje niet meer tweeten of wachtwoorden aanpassen. Met andere woorden: er werden identiteiten vergrendeld.

Het supportteam van Twitter liet een stevig staaltje incidentcommunicatie zien met regelmatige en consistente updates. Terwijl Twitter de situatie probeerde op te lossen, dachten Twitteraars die nog wel berichten konden posten (en zij die dat later op de avond ook weer konden) mee over mogelijke oplossingen. Eén ding is duidelijk: Twitter had een plan klaarliggen, en dat is cruciaal voor het welslagen van elke respons op incidenten. Ze hadden een ‘paniekknop’ die gebruikt kon worden om hun systemen te vergrendelen. En ze hadden een team dat op een goede en consistente manier met de buitenwereld communiceerde.

Wat er precies gebeurd is en hoe het heeft kunnen gebeuren, zal de komende weken duidelijk moeten worden. Voor nu houdt Twitter het op een gecoördineerde social-engineeringaanval op Twitter-medewerkers. Sommigen beweren dat het een aanval van binnenuit was door iemand die zich heeft laten omkopen, of dat er zelfs sprake was van een ‘false flag’-aanval waarbij gevoelige informatie het echte doelwit was. Dit is voor elk bedrijf het worstcasescenario: dat via een medewerker misbruik wordt gemaakt van een beperkt toegankelijke interne tool die wordt gebruikt om klanten te helpen.

Hoewel het nog te vroeg is om er echt iets over te kunnen zeggen, waren er – toen de Twitterbrigade weer operationeel was – wel veel vingers die naar identiteit wezen als bron van het probleem. Laat dat nu net zijn wat Twitter als eerste beveiligde.

Twitters ‘paniekknop’ haalt de scherpe randjes van het worstcasescenario

Naarmate meer details bekend werden over de aanval op een intern systeem, verscheen Twitters ex-CISO Michael Coates op CNN om uit te leggen welke vormen van beveiliging Twitter had ingebouwd, zoals “logging, datascience-analyse, minimale toegang, eigenlijk alles wat je van een dergelijk systeem mag verwachten.”

Neem je eigen identiteitsprocessen onder de loep

Hoewel Twitter veel dingen goed heeft gedaan, is dit wel het moment om sommige identiteitsprocessen te optimaliseren. Want ja, deze Twitterhack was extreem, maar er zijn een paar beveiligingsbasics die elk bedrijf echt op orde moet hebben.

Toegangsbeheer is belangrijk. Wie binnen jouw bedrijf kan echt niet zonder toegang tot die belangrijke klantdata? En moeten zij permanent toegang hebben of alleen bij het uitvoeren van bepaalde taken? Hoe kun je dit volgen? Hoe kun je toegang intrekken?
Hanteer het principe dat er zo min mogelijk mensen toegang hebben tot deze gevoelige systemen. Beperk de toegang tot degenen die echt niet zonder kunnen en zorg dat op gevoelige acties extra authenticatie zit. Bekijk vervolgens regelmatig wie er toegang hebben om er zeker van te zijn dat de lijst nooit veroudert.
Zorg dat er na elke belangrijke handeling binnen een account een notificatie wordt verstuurd (bij voorkeur zowel per mail als een push-bericht naar de mobiel). Denk aan het wijzigen van een e-mailadres, het veranderen van het wachtwoord, het uitzetten van de dubbele authenticatie en het linken naar een account. Kijk niet steekproefsgewijs of het goed gaat, maar bescherm de belangrijke zaken gewoon.
Maak bij het wijzigen van het e-mailadres voor zowel de interne als de externe tools gebruik van dezelfde API. De Twitterhackers kregen toegang tot het account van de medewerker en konden hun gang gaan. Waren ze in de externe tool gekomen, dan waren er notificaties verstuurd. Als je voor beide tools gebruikmaakt van dezelfde API (zelfde code, zelfde processen), dan zou de wijziging van het e-mailadres tot notificaties geleid hebben.

Bron: Auth0