Wie das Modell der geteilten Verantwortung zum AT&T-Verstoß beigetragen hat

von | 23.7.2024

Die Kunden von Snowflake, einem US-amerikanischen Cloud-Dienst, der Datenspeicherung und -analyse anbietet, mussten kürzlich einen massive und öffentlichkeitswirksame Datenschutzverletzung die nach Meinung einiger die größte in der Geschichte sein könnte. Von der Sicherheitsverletzung waren fast 170 Organisationen betroffen, darunter "fast alle" Kunden des Mobilfunkanbieters AT&T sowie Kunden anderer Unternehmen wie Ticketmaster und LendingTree.

Aber die Sicherheitsverletzung ist nicht nur für die betroffenen Kunden und Unternehmen verheerend. Sie ist auch ein hervorragendes Beispiel dafür, was passieren kann, wenn das Modell der gemeinsamen Verantwortung in der Cloud zusammenbricht. Lassen Sie uns herausfinden, wie.

Inhaltsübersicht

Sichere Cloud-Dateiübertragung

MASV ist ein nach ISO 27001/SOC 2 zertifizierter und von TPN verifizierter (Gold Shield Status) sicherer Dateiübertragungsdienst.

Was ist das Modell der geteilten Verantwortung?

Lassen Sie uns zunächst definieren, worüber wir hier sprechen: Das Modell der geteilten Verantwortung oder das Modell der geteilten Sicherheitsverantwortung ist ein Sicherheitsrahmen, der von vielen Anbietern öffentlicher Clouds verwendet wird, darunter Schneeflockedie die Verantwortung für die Datensicherheit zwischen dem Anbieter und seinen Endnutzern aufteilt.

Das Modell der geteilten Verantwortung sieht in der Regel eine klare Abgrenzung der Zuständigkeiten für Datenschutz und Schwachstellenmanagement zwischen dem Kunden auf der einen und dem Anbieter auf der anderen Seite vor.

Verantwortung des Anbieters in Verbindung mit der Verantwortung des Kunden. Klingt doch ganz einfach, oder?

Problematisch wird es jedoch, wenn Nutzer davon ausgehen, dass ihr Cloud-Anbieter sich um die Datensicherheit kümmert, die eigentlich nicht in seiner Verantwortung liegt - oder wenn sie die vom Anbieter angebotenen Tools nicht nutzen. (wie z. B. die Durchsetzung der Multi-Faktor-Authentifizierung (MFA)).

Wenn das passiert, bricht das Modell der gemeinsamen Sicherheitsverantwortung zusammen. Und die Wahrscheinlichkeit einer Datenschutzverletzung steigt erheblich.

Die AT&T-Datenpanne: Wie ist es dazu gekommen?

Diese Datenschutzverletzung scheint ein direktes Ergebnis dieser Art des Zusammenbruchs des Modells der gemeinsamen Verantwortung für die Cloud zu sein.

Im Einklang mit diesem Modell und wie viele andere Cloud-Dienste hat Snowflake traditionell Cybersicherheits-Tools und -Funktionen zur Verfügung gestellt, aber den Benutzern die Möglichkeit gegeben, ihre Sicherheitslage selbst zu verwalten. So stellte Snowflake beispielsweise Tools für die Zugriffsverwaltung wie MFA zur Verfügung, verlangte aber bisher nicht, dass die Nutzer diese durchsetzen.

Platzhalterbild

QUELLE: Urteil.co.uk

A kurze Erklärung Der Cloud-Service-Anbieter räumte ein, dass es sich bei dem Einbruch um eine gezielte Kampagne handelte, die auf Benutzer mit Einzelfaktor-Authentifizierung (SFA) abzielte, und fügte hinzu, dass die Passwörter für Snowflake-Konten mit SFA entweder zuvor gekauft oder mit Hilfe von Malware erlangt wurden.

Übersetzung: Malware, die Tastatureingaben protokolliert (oder ähnliches), sammelte Benutzerpasswörter, die dann dazu verwendet wurden, in unsichere Snowflake-Konten einzubrechen und (vorhersehbar) die darin enthaltenen Daten zu zerstören. Die traurige Tatsache ist jedoch, dass dieser Verstoß mit ziemlicher Sicherheit nicht stattgefunden hätte, wenn die Administratoren der betroffenen Snowflake-Konten die MFA-Zugangskontrolle für ihre Benutzer durchgesetzt hätten - eine relativ einfache Anforderung.

(TechCrunch hat kürzlich berichtet, dass "Hunderte" von angeblichen Snowflake-Kundenanmeldedaten, wie sie bei diesem Angriff verwendet wurden, immer noch online verfügbar sind).

Es überrascht nicht, dass Snowflake nach Bekanntwerden der Sicherheitsverletzung eine neue Authentifizierungspolitik die es Administratoren ermöglicht, alle Snowflake-Benutzer zur Verwendung von MFA zu zwingen.

Wer ist schuld, wenn es eine geteilte Verantwortung gibt?

Ist Snowflake in diesem Szenario wirklich für diese Datenverletzung verantwortlich?

  • Snowflake empfahl den Kontoadministratoren, folgende Maßnahmen zu ergreifen sichere Passwörter bei der Einschreibung.
  • Snowflake bot eine optionale MFA-Zugriffsverwaltung an, um die Konten ihrer Benutzer noch besser zu schützen, aber einige Kontoadministratoren entschieden sich, diese nicht einzurichten.
  • Snowflake bot vor der Sicherheitsverletzung keine Tools für Administratoren zur Durchsetzung von MFA an.

Während der letzte Punkt eindeutig auf Snowflake zurückzuführen ist, könnten die ersten beiden Punkte entweder als Fehler des Cloud-Anbieters oder des Nutzers angesehen werden. In Wirklichkeit ist es wahrscheinlich ein bisschen von beidem (geteilte Verantwortung bedeutet auch geteilte Verantwortung, wenn etwas schief geht).

Der Vorfall hat eine der größten Schwachstellen des Modells der geteilten Verantwortung deutlich gemacht.

Unseren Beobachtungen zufolge - und das überrascht vielleicht nicht - geht die Stimmung in der Branche langsam dahin, dass die Anbieter strengere Sicherheitskontrollen einführen, um zu verhindern, dass sich die Kunden selbst ins Bein schießen (wie in diesem Fall): Ein Modell mit geteilter Verantwortung, bei dem der Anbieter etwas mehr Verantwortung für das Schwachstellenmanagement trägt als der Benutzer.

Lektionen für Unternehmen (und Nutzer) in der Cloud

Es ist für uns alle wichtig, aus unseren Fehlern zu lernen, und das gilt auch für Public-Cloud-Dienste und -Nutzer.

Neben den Anbietern, die es den Administratoren ermöglichen, sinnvolle Cybersicherheitsmaßnahmen wie MFA durchzusetzen, gibt es noch weitere wertvolle Lehren für den Datenschutz, die aus diesem Vorfall gezogen werden können:

Durchsetzung von MFA/2FA und anderen sinnvollen Sicherheitsvorgaben

Datenschutzverletzungen sind inzwischen so alltäglich geworden, dass selbst die meisten normalen Geschäftsanwender wissen, wie wichtig eine Zugangskontrolle mit MFA oder Zwei-Faktor-Authentifizierung (2FA) ist. Admins sollten dies immer durchsetzen und Cloud-Anbieter sollten diese Option immer anbieten.

Auch wenn MFA bei den Mitarbeitern einige Reibungsverluste verursacht - ich habe vor kurzem den Computer gewechselt und musste bei der Einrichtung in ein paar Stunden etwa 100 MFA-Überprüfungen durchführen -, kann sie viele Cyberangriffe schon im Keim ersticken. Das allein ist schon ein Grund, warum sie nicht verhandelbar sein sollte. 

Ein Cloud-Service sollte auch Schulungen und Unterstützung für Kunden anbieten, die MFA für ältere Konten aktivieren, die mit automatisierten Prozessen verbunden sind, da der MFA-Schritt diese Prozesse wahrscheinlich unterbrechen wird, wenn die Migration nicht sorgfältig durchgeführt wird.

Andere Sicherheitsvorgaben, wie die automatische Konfiguration aller neuen Ressourcen (z. B. Speicherbereiche, Datenbanken oder virtuelle Maschinen), um den öffentlichen Zugang zu blockieren (anstatt standardmäßig für die Öffentlichkeit zugänglich zu sein), sollten ebenfalls von Cloud-Anbietern implementiert werden.

Diese Maßnahmen sind zwar für den Endnutzer mit einigen Reibungsverlusten verbunden, zwingen ihn aber auch dazu, den Weg zu mehr Sicherheit einzuschlagen - und nicht umgekehrt.

Sammeln von Informationen über offene Bedrohungen (OSINT)

Kontinuierliche Überwachung von Bedrohungen im Dark Web und im regulären Internet im Namen der Kunden und Reaktion auf alle Anzeichen eines möglichen Verstoßes. Es ist zur Tradition geworden, dass unvorsichtige Nutzer versehentlich API-Schlüssel in offenen Code-Repositories veröffentlichen, wie zum Beispiel dieser Nutzer, der seine Stripe-API-Schlüssel auf GitHub (oops).

Cloud-Unternehmen sollten Open-Source-Code-Repositories auf Schlüssellecks überwachen und die betroffenen Kunden kontaktieren, wenn sie solche entdecken. Anbieter können hierfür automatisierte Tools wie CrowdStrike verwenden.

Tooling anbieten, um über potenzielle Bedrohungen auf dem Laufenden zu bleiben

Cloud-Anbieter sollten auch Tools und die Integration mit führenden Cybersicherheitsplattformen anbieten, um DevSecOps-Teams zu bewerten, über potenzielle Bedrohungen auf dem Laufenden zu bleiben und den Nutzern mehr Flexibilität bei der Einhaltung bewährter Cybersicherheitsverfahren zu bieten. Wenn Cloud-Anbieter solche Sicherheitskontrollen nicht anbieten, sollten Administratoren diese Tools trotzdem suchen.

  • Ein typisches Beispiel: Dienste wie Splunk oder Wiz können eine passive Überwachung aller Aktionen innerhalb einer Cloud-Infrastruktur durchführen und so automatisch Nutzungsanomalien erkennen, die ein eindeutiges Indiz für eine Sicherheitsverletzung sein können, aber ansonsten möglicherweise unentdeckt bleiben.
  • Ein weiteres Beispiel: Rotation der API-Schlüssel. Wenn ein Nutzer seinen API-Schlüssel z. B. alle drei Monate ändern möchte, sollte der Anbieter ihm einen Mechanismus zur Verfügung stellen, mit dem er dies tun kann, ohne dass es zu erheblichen Systemausfallzeiten kommt. Das bedeutet, dass er die Möglichkeit bieten sollte, mehrere API-Schlüssel gleichzeitig zu generieren.

Nehmen Sie die Dinge nicht als selbstverständlich hin

Endlich, Insbesondere als Kunde sollten Sie das Modell der geteilten Verantwortung nie als selbstverständlich ansehen oder sich damit zufrieden geben.. Manchmal verfällt man leicht in eine Denkweise, die besagt, dass "das andere Unternehmen dafür verantwortlich ist", oder man geht davon aus, dass ein Sicherheitstool, das nicht zwingend vorgeschrieben ist, nicht wichtig ist.

Cloud-Anbieter sollten so viel Aufklärung und Dokumentation wie möglich bereitstellen, um die Nutzer zu einer verantwortungsvollen Sicherheitshaltung anzuleiten und gleichzeitig ihre eigenen Mitarbeiter über die neuesten Sicherheitsbedrohungen und bewährte Verfahren zu informieren.

Und als Nutzer sollten Sie immer die besten Praktiken befolgen, die Dokumentation lesen und nie davon ausgehen, dass Ihr Cloud-Infrastrukturanbieter sich um etwas kümmert, bevor Sie es nicht schriftlich haben.

 

MASV: Ein mehrschichtiger Sicherheitsansatz

MASV basiert nicht nur auf AWS-Sicherheit mit starker TLS 1.2 und AES-256-basierter Verschlüsselung und strengen Zugriffskontrollen, sondern schützt auch alle gespeicherten und übertragenen Daten durch eine mehrschichtiger Sicherheitsansatz die umfassen:

  • Schulung des Sicherheitsbewusstseins der Mitarbeiter und starke interne Passwortgeneratoren.
  • Produktsicherheit einschließlich regelmäßiger Code-Scans und automatischer Warnmeldungen bei Admin-Anmeldungen.
  • Schutz der Kunden wie die obligatorische Durchsetzung starker Passwörter und die Förderung der obligatorischen Verwendung von MFA und Passwortgeneratoren.
  • Validierung durch Prüfungen der Cybersicherheit durch Dritte und Einhaltung von Vorschriften.

Für MASV anmelden und starten Sie noch heute kostenlos.

Hochwertige Cloud-Infrastruktur

MASV läuft auf einer hochsicheren AWS-Cloud-Infrastruktur, so dass Ihre Dateien immer sicher sind.