Der erweiterte Blast-Radius: Was wir über den Nissan-Red Hat-Verstoß wissen

Moderne Bedrohungsakteure und Datendiebe betrachten Unternehmen nicht mehr als Monolith. Stattdessen wenden sie eine klinische Taxonomie auf ihre Ziele an und triagieren die Vermögenswerte einer Organisation systematisch in vier (anfängliche) strategische Interessensgebiete. Dazu gehören Kundenvertrauen (PII), interne Stabilität (Mitarbeiterdaten), intellektuelles Kapital (Unternehmensdaten) und am kritischsten, funktionale Souveränität (Betriebskontrolle). Dies erleichtert es, Angriffswege herauszufinden und die relevanten Datenbits mit mehr Fokus, Aufmerksamkeit und Taktik zu sammeln.  

In der Automobilwelt, die von Hochrisikotechnologie geprägt ist, sprechen wir oft über Cybersicherheit innerhalb der "Perimeter" unseres Geschäfts und behandeln sie, als wären es solide Mauern. Unternehmen investieren auch Millionen in Firewalls, EDR und SOCs, um ihre internen Tore zu sichern. Wie der kürzliche Verstoß gegen Nissan und Red Hat zeigt, hat das moderne Unternehmen jedoch keine Wände. Stattdessen hat es ein gut vernetztes Kreislaufsystem, das sich bis zu externen Beratern erstreckt, die vorübergehende Datenwächter sein sollen. Und wenn eine große Arterie wie ein globaler Beratungspartner beschädigt wird, kann der Einfluss eines Lecks (egal wie klein) Tausende von Meilen weit gespürt werden.

Der Zeitverlauf des Angriffs

Irgendwann am Morgen des 26. September, ein Freitag, wurde der Angriff in Form eines unerlaubten Zugriffs erstmals von Red Hat entdeckt. RedHat sperrte sofort den Zugang zu den Daten und isolierte den Server, um weiteren Zugriff auch von validierten Quellen zu verhindern.

Eine Woche später, nach einer Runde interner Bestätigungen, übermittelte RedHat die Informationen über den Verstoß am 3. Oktober (dem darauffolgenden Freitag) an Nissan, die den Verstoß sofort der Datenschutzbehörde meldeten. Zusätzlich, gemäß Nissan, kontaktierten sie auch die Kunden, von denen man annahm, dass sie direkt vom Verstoß betroffen waren oder deren Daten kompromittiert wurden. Das Unternehmen gab auch eine Entschuldigung auf seiner Website heraus.   

Es war nicht bekannt, dass der betroffene Server außer den kompromittierten Daten noch andere Informationen enthielt, so Nissan.

Die Anatomie des Angriffs auf Nissan und dessen Nachwirkungen

Aus einer höheren Perspektive betrachtet ist die Nachricht eine standardmäßige Meldung über eine Datenschutzverletzung: Die persönlichen Daten von 21.000 Nissan-Kunden in Japan wurden offengelegt, einschließlich derer, die Fahrzeuge gekauft haben oder in den Service bei der ehemaligen Fukuoka Nissan Motor Co., Ltd. (derzeit Nissan Fukuoka Sales Co., Ltd.) eingetreten sind.

Doch die Quelle des Lecks war kein ungesicherter oder vergessener Nissan-Server. Der Vorfall umfasste einen indirekten Einschlag auf Nissan, der möglicherweise von einem kompromittierten GitLab-Instanz ausging, die von Red Hat Consulting genutzt wurde. Der Schutzgrad des Servers ist derzeit unbekannt.

Der sogenannte "Crimson Collective", der Bedrohungsakteur hinter dem Verstoß, stahl nicht nur Aufzeichnungen. Sie stahlen 570 GB "Kundenbindungsberichte" (CERs), insgesamt etwa 800 Stück.

Gemäß dem Automobilgiganten legt Nissans Kundenbindungsstrategie großen Wert auf personalisierte mobile Nachrichten, ein nahtloses digitales Erlebnis im Autohaus und die Nutzung von Datenanalysen, um relevante Inhalte und Dienstleistungen zu liefern. Das Unternehmen strebt an, langfristige Loyalität aufzubauen und hohe Konversionsraten zu erzielen, und es ist möglich, dass diese Daten im Rahmen dieser Maßnahmen gesammelt und als Teil eines Projekts an Red Hat übermittelt wurden.

Die gestohlenen Berichte enthalten Details wie:

·         Verifizierte vollständige Namen

·         Physische Adressen

·         Telefonnummern

·         E-Mail-Adressen

·         Kundendaten, die in Verkaufs- und versicherungsbezogenen Operationen verwendet werden

Das Unternehmen hat erklärt, dass Kreditkartendetails nicht Teil des Verstoßes waren. Nissan hat auch eine Warnung an die betroffenen Kunden ausgegeben, bei Anrufen über ihre Fahrzeuge vorsichtig zu sein. 

Wenn diese Daten mit anderen Informationen aus gestohlenen Datenbanken kombiniert werden, könnten die Kunden leicht einem Phishing-Angriff ausgesetzt werden. Diese Daten könnten auch genutzt werden, um ein Käuferprofil des Kunden zu erstellen, was im Grunde genommen der Anfang einer Abwärtsspirale wäre.   

Der "Berater-Blindpunkt"

Nissan hatte mehrere Kooperationsprojekte mit Red Hat.

Laut verfügbarer Informationen engagierte Nissan Red Hat mit einer Beratungsmöglichkeit, um den Automobilgiganten zu einem Schlüsselspieler im Bereich der softwaredefinierten Fahrzeuge zu transformieren. Dies war eine datenschwere Zusammenarbeit. Tatsächlich hatte Nissan angekündigt, dass es das Red Hat In-Vehicle Operating System verwenden würde, um seine nächste Generation der softwaredefinierten Fahrzeugplattformen zu betreiben.  Gemäß Red Hat kann das neue Fahrzeugbetriebssystem fortschrittliche Fahrerassistenzsysteme, digitale Cockpits, Telematik, Infotainment und hochentwickelte KI-Modelle unterstützen.

Darüber hinaus hatte Nissan auch Red Hat engagiert, um ein Kundenverwaltungssystem zu entwickeln. Die Details dieses Projekts sind nicht sehr klar. Aus den uns zur Verfügung gestellten Informationen, die von unserem Forschungsteam analysiert wurden, scheint es, dass dieses Projekt vom Verstoß betroffen war.

Die geleakten Daten waren Informationen, die Nissan den Beratern von Red Hat zur Verfügung gestellt hatte, um am Projekt des Kundenverwaltungssystems zu arbeiten. Die Beratungsabteilung von Red Hat hatte die Informationen in ihrer eigenen internen GitLab-Instanz neben anderen Artefakten des Projekts gespeichert. Leider war dies genau der Server, der verletzt wurde. Technisch gesehen handelt es sich daher nicht um einen Verstoß bei Nissan.

Seit Jahren argumentiere ich, dass Beratungsfirmen zu ultimativen Sammelpunkten für Anmeldedaten werden. Wir engagieren Experten, um uns zu skalieren, aber dabei gewähren wir ihnen oft ein Vertraueniveau, das unsere standardmäßigen Zero-Trust-Protokolle umgeht. Ein solcher Widerspruch in den Sicherheitskontrollen könnte leicht von einem Bedrohungsakteur ausgenutzt werden. Tatsächlich achten Bedrohungsakteure auf Berater, die solche Daten bearbeiten. Das soll hier niemanden beschuldigen. Aber das ist eine Standardpraxis in vielen Branchen, die auf dem Vertrauen basiert, das zwischen dem Kunden und dem Berater besteht (in manchen Fällen könnte der Berater sogar eine Einzelperson sein). 

Wenn ein Berater ein "Schatten-Repository" oder eine Testumgebung erstellt, um Ihr nächstes Kundenbindungsmanagementsystem zu entwickeln, könnte diese Umgebung weit außerhalb der strengen Überwachung Ihres internen CISO oder des zuständigen Sicherheitsteams liegen. In manchen Fällen könnte sie nicht einmal den gleichen Risikoüberprüfungen unterzogen werden wie andere Teile Ihrer Infrastruktur. Es gab auch schon Fälle, in denen eine Zusammenarbeit endete, der Berater jedoch die Daten des Kunden noch eine Weile behielt. Manchmal werden die Daten im Prozess sogar vergessen. 

Eine zusätzliche Sicherheitsebene für solche Daten und Kollaborationen könnte einen erheblichen Beitrag dazu leisten, solche Vorfälle zu verhindern. 

Drei Lehren für den strategischen Cybersecurity-Leiter

Wenn Sie heute im Vorstand sitzen, sollte das Nissan-Red Hat-Ereignis drei sofortige Veränderungen in Ihrem Denken auslösen:

• Beginnen Sie mit der Prüfung von Engagements: Wir verbringen Monate damit, das Produkt eines Softwareanbieters zu prüfen, aber nur Minuten damit, einen Leistungsnachweis für ihre Berater zu unterzeichnen. Wir müssen Beratungsteams als privilegierte Nutzer behandeln, mit "dauerhaften-temporären" Zugriffen, die kontinuierliches, automatisiertes Monitoring erfordern. Der Berater sollte kontinuierlich Compliance-Berichte vorlegen, um die Anforderungen des Kunden hinsichtlich der Risikobelastung zu erfüllen.

• Das Ende der statischen Geheimnisse: Fest codierte Geheimnisse in Kundenbindungsberichten (CERs) waren der Haupttreibstoff für diesen Verstoß. In einer Ära der KI-getriebenen Bedrohungsjagd sind statische Tokens eine Haftung. Wenn ein Geheimnis aufgeschrieben werden kann, kann es gestohlen werden.

• Erkennen Sie den erweiterten "Blast-Radius": Dieser Verstoß betraf zwar Nissan, aber die gestohlenen Daten umfassten Berichte für über 800 Organisationen, einschließlich Regierungsstellen und Finanzgiganten. Wir müssen unseren "Blast-Radius" kartografieren und die Antwort auf die Frage kennen: „Wenn unser Hauptberater heute Nacht gehackt wird, über welche spezifischen Schlüssel zu unserem Reich verfügen sie derzeit noch?"

Das große Ganze. Über die Firewall hinausblicken

Bei Shieldworkz diskutieren wir oft über die Konvergenz des digitalen und physischen Raums. Im Automobilsektor geht es dabei nicht nur um "Kundennamen". Stattdessen geht es um personenbezogene Daten des Kunden und die Infrastruktur, die den Lebenszyklus des Fahrzeugs verwaltet. Wenn wir auf intelligentere, vernetzte Städte zugehen, könnte eine Sicherheitsverletzung eines "Kundenverwaltungssystems" selbst auf der Ebene eines Pilotprojekts der erste Schritt zu einer viel gefährlicheren Intrusion in die OT (Operational Technology) Schicht unseres Lebens sein.

Sicherheit ist kein technisches Problem mehr; es ist im Wesentlichen eine ständige Herausforderung der intellektuellen Wachsamkeit. Es erfordert die Vorstellungskraft, die Verbindungen, die wir geschaffen haben, zu erkennen und den Mut, sie zu sichern, selbst wenn sie außerhalb unserer direkten Sicht liegen.

Ist die Beraterschicht Ihres Unternehmens eine gut überwachte Brücke oder eine kaum verhinderte Sicherheitslücke?

Und schließlich, neue Regel (in Bill Mahers Stimme): Behandeln Sie Ihre externen Berater nicht als "vertraute Gäste", sondern als kritische Erweiterung Ihrer Angriffsfläche, die dieselbe Zero-Trust-Strenge erfordert wie Ihre internen Teams.

Eine Anmerkung zum Verstoß, die heute von Nissan veröffentlicht wurde