Hoe het model van gedeelde verantwoordelijkheid heeft bijgedragen aan de inbraak bij AT&T

Klanten van Snowflake, een Amerikaanse clouddienst die gegevensopslag en -analyse biedt, hebben onlangs een grootschalig en zeer openbaar datalek waarvan sommigen zeggen dat het de grootste in de geschiedenis zou kunnen zijn. Het lek trof bijna 170 organisaties, waaronder "bijna alle" klanten van draadloze provider AT&T, samen met klanten van andere bedrijven zoals Ticketmaster en LendingTree.

Maar de inbreuk is niet alleen verwoestend voor de getroffen klanten en bedrijven. Het is ook een uitstekend voorbeeld van wat er kan gebeuren als het model van gedeelde verantwoordelijkheid in de cloud niet werkt. Laten we eens kijken hoe.

• Wat is het model van gedeelde verantwoordelijkheid?
• Het datalek bij AT&T: Hoe is het gebeurd?
• Wie is schuldig bij gedeelde verantwoordelijkheid?
• Lessen voor bedrijven (en gebruikers) in de cloud
• MASV: een gelaagde beveiligingsaanpak

Wat is het model van gedeelde verantwoordelijkheid?

Laten we eerst definiëren waar we het hier over hebben: Het gedeelde verantwoordelijkheidsmodel, of shared security responsibility model, is een beveiligingsraamwerk dat wordt gebruikt door veel publieke cloudproviders, waaronder SneeuwvlokDe aanbieder van gegevensbeveiliging is een organisatie die de verantwoordelijkheden voor gegevensbeveiliging verdeelt tussen de aanbieder en zijn eindgebruikers.

Verantwoordelijkheid van de verkoper gecombineerd met verantwoordelijkheid van de klant. Klinkt eenvoudig genoeg, toch?

Het probleem is echter wanneer gebruikers ervan uitgaan dat hun cloudaanbieder zorgt voor gegevensbeveiliging die eigenlijk niet onder de verantwoordelijkheid van de aanbieder valt, of wanneer ze geen gebruik maken van de tools die de aanbieder biedt. (zoals het afdwingen van multifactorauthenticatie (MFA)).

Als dat gebeurt, valt het model van gedeelde beveiligingsverantwoordelijkheid weg. En neemt de kans op een datalek enorm toe.

Het datalek bij AT&T: Hoe is het gebeurd?

Dit datalek lijkt een direct gevolg te zijn van dit soort inbreuken op het model van gedeelde verantwoordelijkheid in de cloud.

In overeenstemming met dit model, en zoals veel cloudservices, heeft Snowflake van oudsher cyberbeveiligingshulpmiddelen en -mogelijkheden geleverd, maar gebruikers in staat gesteld om hun beveiligingshouding zelf te beheren. Snowflake bood bijvoorbeeld tools voor toegangsbeheer zoals MFA, maar eiste voorheen niet van zijn gebruikers dat ze deze afdwongen.

BRON: Verdict.nl

A korte uiteenzetting De Cloud Service Provider erkende dat de inbraak een "gerichte campagne was gericht op gebruikers met single-factor authenticatie (SFA)" en voegde eraan toe dat wachtwoorden voor Snowflake accounts met SFA "eerder waren gekocht of verkregen met behulp van info-stelende malware".

Vertaling: Malware die toetsaanslagen registreert (of vergelijkbare malware) verzamelde wachtwoorden van gebruikers, die vervolgens werden gebruikt om in te breken in onveilige Snowflake-accounts en (voorspelbaar) een ravage aan te richten op de gegevens binnen die accounts. Maar het trieste feit is dat als de beheerders van de Snowflake accounts die zijn geschonden MFA toegangscontrole hadden afgedwongen bij hun gebruikers - een relatief eenvoudige vereiste - deze schending bijna zeker niet zou hebben plaatsgevonden.

(TechCrunch heeft onlangs gemeld dat het "honderden" vermeende Snowflake klantgegevens, zoals gebruikt in deze aanval, nog steeds online beschikbaar heeft gezien).

Het zal niemand verbazen dat Snowflake sinds de bekendmaking van het lek een nieuw authenticatiebeleid waarmee beheerders alle Snowflake gebruikers kunnen dwingen MFA te gebruiken.

Wie is schuldig bij gedeelde verantwoordelijkheid?

Is Snowflake in dit scenario echt verantwoordelijk voor dit datalek?

• Snowflake beveelt aan dat accountbeheerders het volgende afdwingen sterke wachtwoorden bij aanmelding.
• Snowflake bood optioneel MFA-toegangsbeheer aan om de accounts van hun gebruikers verder te beveiligen, maar sommige accountbeheerders kozen ervoor om dit niet in te stellen.
• Snowflake bood geen tools voor beheerders om MFA af te dwingen voordat de inbreuk plaatsvond.

Terwijl de laatste zeker aan Snowflake te wijten is, kunnen de eerste twee worden gezien als een fout van de cloudaanbieder of van de gebruiker. In werkelijkheid is het waarschijnlijk een beetje van beide (gedeelde verantwoordelijkheid betekent ook gedeelde verantwoordelijkheid als er dingen fout gaan).

Het incident heeft een van de grootste kwetsbaarheden van het model van gedeelde verantwoordelijkheid scherp geïllustreerd.

Volgens onze waarnemingen, en misschien niet verrassend, verschuift het sentiment in de branche langzaam in de richting van leveranciers die strengere beveiligingscontroles implementeren om te voorkomen dat klanten zichzelf in de voet schieten (zoals in deze situatie): Een model met gedeelde verantwoordelijkheid, alleen met een beetje meer verantwoordelijkheid voor het beheer van kwetsbaarheden bij de leverancier dan bij de gebruiker.

Lessen voor bedrijven (en gebruikers) in de cloud

Het is belangrijk dat we allemaal leren van onze fouten, en publieke cloudservices en -gebruikers zijn niet anders.

Naast leveranciers die beheerders in staat stellen om verstandige cyberbeveiligingsmaatregelen zoals MFA af te dwingen, zijn er nog andere waardevolle lessen op het gebied van gegevensbescherming die uit dit incident kunnen worden geleerd:

MFA/2FA en andere zinnige beveiligingsstandaarden afdwingen

Datalekken zijn nu zo gewoon geworden dat zelfs de meeste alledaagse zakelijke gebruikers zich bewust zijn van het belang van toegangscontrole met MFA of twee-factor authenticatie (2FA). Beheerders moeten dit altijd afdwingen en cloudproviders moeten deze optie altijd aanbieden.

Hoewel MFA wat wrijving veroorzaakt bij werknemers - ik ben onlangs van computer gewisseld en had te maken met ongeveer 100 MFA-verificaties in een paar uur terwijl ik dingen instelde - is het in staat om veel cyberaanvallen in hun kielzog te stoppen. Dat alleen al is een reden om er niet over te onderhandelen. 

Een cloudservice moet ook voorlichting en hulp bieden aan klanten die MFA inschakelen op bestaande accounts die zijn gekoppeld aan geautomatiseerde processen, omdat de MFA-stap deze processen waarschijnlijk zal doorbreken als de migratie niet zorgvuldig wordt uitgevoerd.

Andere beveiligingsstandaarden, zoals het automatisch configureren van alle nieuwe bronnen (zoals opslagbuckets, databases of virtuele machines) om alle publieke toegang te blokkeren (in plaats van standaard open te zijn voor het publiek), moeten ook worden geïmplementeerd door cloudaanbieders.

Hoewel dit soort maatregelen een beetje frictie toevoegen voor de eindgebruiker, dwingen ze hen ook om de weg naar meer beveiliging in te slaan, in plaats van andersom.

Informatie over open bedreigingen (OSINT) verzamelen

Voortdurend bedreigingen op het dark web en het reguliere internet in de gaten houden namens klanten en reageren op indicatoren van een mogelijke inbreuk. Het is een beetje een traditie geworden voor onvoorzichtige gebruikers om per ongeluk API-sleutels bloot te geven op open code repositories, bijvoorbeeld toen deze gebruiker zijn Stripe API sleutel op GitHub (oeps).

Cloudbedrijven moeten open source code-repositories controleren op lekken in sleutels en contact opnemen met getroffen klanten als ze deze ontdekken. Aanbieders kunnen hiervoor geautomatiseerde tools zoals CrowdStrike gebruiken.

Tooling aanbieden om bovenop potentiële bedreigingen te blijven zitten

Cloudproviders zouden ook tools en integratie met toonaangevende cyberbeveiligingsplatforms moeten aanbieden om DevSecOps-teams te beoordelen, op de hoogte te blijven van potentiële bedreigingen en gebruikers meer flexibiliteit te geven om best practices op het gebied van cyberbeveiliging te volgen. Als cloudproviders dergelijke beveiligingscontroles niet bieden, moeten beheerders toch op zoek gaan naar deze tools.

• Een goed voorbeeld: Diensten als Splunk of Wiz kunnen alle acties binnen een cloudinfrastructuur passief monitoren en automatisch afwijkingen in het gebruik detecteren die een verklikker kunnen zijn voor een inbreuk, maar die anders mogelijk onopgemerkt blijven.
• Een ander voorbeeld: API-sleutel rotatie. Als een gebruiker bijvoorbeeld elke drie maanden zijn API-sleutel wil veranderen, moet de leverancier een mechanisme bieden waarmee hij dat kan doen zonder dat het systeem veel tijd verliest. Dat betekent dat het mogelijk moet zijn om meerdere API-sleutels tegelijk te genereren.

Neem dingen niet voor lief

Eindelijk, vooral als klant, het model van gedeelde verantwoordelijkheid nooit als vanzelfsprekend of zelfgenoegzaam beschouwen. Het is soms gemakkelijk om te vervallen in een denkwijze van "het is de verantwoordelijkheid van het andere bedrijf" of aan te nemen dat als een beveiligingstool niet verplicht is, deze niet belangrijk is.

Cloudproviders moeten zoveel mogelijk voorlichting en documentatie bieden om gebruikers te begeleiden naar een verantwoordelijke beveiligingshouding, terwijl ze ook hun eigen werknemers moeten opleiden over de nieuwste beveiligingsrisico's en best practices.

En als gebruiker moet je altijd best practices volgen, de documentatie lezen en er nooit van uitgaan dat je cloudinfrastructuurprovider iets regelt totdat je het op papier ziet.

MASV: een gelaagde beveiligingsaanpak

MASV is niet alleen gebouwd op AWS-beveiliging met sterke TLS 1.2 en AES-256-gebaseerde encryptie en strenge toegangscontroles, maar houdt ook alle opgeslagen en overgedragen gegevens veilig door middel van een gelaagde beveiligingsaanpak waaronder:

• Training veiligheidsbewustzijn werknemers en sterke interne wachtwoordgeneratoren.
• Productbeveiliging inclusief het regelmatig scannen van codes en automatische waarschuwingen voor beheerdersaanmeldingen.
• Bescherming van klanten zoals het verplicht afdwingen van sterke wachtwoorden en het aanmoedigen van verplicht gebruik van MFA en wachtwoordgeneratoren.
• Validatie door cyberbeveiligingsaudits door derden en naleving van de regelgeving.

Aanmelden voor MASV en begin vandaag nog gratis.