Kommunikation bei einem IT-Sicherheitsvorfall, was kann da schon schiefgehen?

Dass bei der Kommunikation von IT-Sicherheits-Vorfällen einiges schiefgehen kann, ist wohl eine Binsenwahrheit. Zwei konkrete Beispiele der letzten Wochen haben das wieder einmal deutlich vor Augen geführt.

Eines vorneweg: Der Fokus liegt im folgenden auf der Art der Kommunikation, nicht auf den Vorfällen (da liegen definitiv Welten zwischen einem Informationen preisgebenden und angreifbaren Passwort-Manager und einigen schlussendlich eher theoretischen Lücken in einem Messenger).

LastPass

LastPass ist ein weitverbreiteter Password-Manager für alle gängigen Betriebssysteme mit dem sich Passwörter zwischen verschiedenen Rechnern/Geräten synchronisieren lassen damit sie auf allen Geräten zur Verfügung stehen (was es einem erlaubt, komplexe Passwörter für Online-Dienste zu verwenden welche schwer zu knacken sind). Da diese Synchronisierung über das Internet erfolgt, ist die Sicherheit der Passwort-Daten zentral für die Vertrauenswürdigkeit des Produkts, der Zugriff auf die Daten wird durch ein vom Kunden gesetztes Master-Passwort geschützt.

Technischer Einschub: Bei LastPass wird (wie bei anderen gängigen Passwort-Managern auch) nicht das Master-Passwort nicht direkt zum Verschlüsseln der Daten verwendet da es oft zu einfach erratbar/angreifbar ist. Stattdessen wird es mit einer kryptografischen Funktion namens Password-Based Key Derivation Function quasi mathematisch zufälliger gemacht um so die Sicherheit zu erhöhen. Allerdings ist PBKDF relativ leicht in Hardware zu realisieren, daher ist momentan die Verwendung von >200’000 Iterationen/Durchläufen des Algorithmus Standard (zum Vergleich: in 2005 wurden 4000 Iterationen noch als ausreichend betrachtet).

LastPass hatte in den letzten Jahren wiederholt Sicherheitsprobleme, so wurden unter anderem 2017 schwerwiegende Schwächen bekannt, erfolgte 2016 ein Phishing-Attacke und gingen 2015 bereits Daten «verloren».

Im zweiten Halbjahr 2022 kam eine weiteres Problem hinzu, welches das Unternehmen in einem immer länger werdenden Blogpost zum Vorfall Stück für Stück bekannt machte. Ein Problem welches bei jedem Blogpost-Update grösser und grösser wurde…

• Am 25.8. wurde die Entwendung von Source Code durch unbekannte Hacker bekannt gegeben. Auch wenn versichert wurde, dass keine Kundendaten entwendet worden seien und Kunden keine spezifischen Massnahmen ergreifen müssten, ist schon der Zugriff von Fremden auf proprietären Source Code (in dem anschliessend nach Sicherheitslücken gesucht werden kann) ein ernstes Problem.
• Drei Wochen später ergänzte LastPass die Meldung um Details zum Zugriff und betonte explizit, dass Kunden-Daten und -Passwörter nicht in Gefahr wären und kein Zugriff darauf erfolgt sei («We can also confirm that there is no evidence that this incident involved any access to customer data or encrypted password vaults. […] your personal data and passwords are safe in our care»).
• Die Freude währte kurz, denn am 30.11. informierte das Unternehmen darüber, dass es unbekannten Dritten mit Hilfe der im August kopierten Daten möglich gewesen war, auf einen Cloudspeicher mit Kundendaten zuzugreifen. Das Unternehmen versicherte erneut, dass die Kunden-Passwörter verschlüsselt und sicher seien.
• Am 22.12. schlussendlich musste LastPass eingestehen, dass entgegen der bisherigen Kommunikation nicht nur Daten aus den Passwort-Safes der Kunden abgeflossen seien, sondern dass diese, mit Ausnahme von Attributen wie Login-Daten und verschlüsselten Notizen, unverschlüsselt waren und von den Angreifern lesbar seien (darunter zum Beispiel auch die zu einem Login gehörige URL, womit es dem Angreifer leicht gemacht wird, attraktive Ziele fürs Knacken des Passworts schnell zu erkennen). Verbunden war dieses Eingeständnis mit Hinweisen auf von den Kunden vorzunehmenden Massnahmen und einer Beschreibung wieso LastPass trotz allem sicher sei.

Aus “Uuups, es hat uns zwar jemand den Quellcode geklaut aber alles kein Problem” wurde so innert vier Monaten “es wurden Passwort-Safes von Kunden entwendet und die darin enthaltenen Daten sind teilweise gar nicht verschlüsselt”. Und auch wenn das jeweilige Master-Passwort der Kunden nicht geknackt wurde, so enthalten die unverschlüsselten Teile des Passwort-Safes oft genügend identifizierende Details um Passwort-Safes zu identifizieren bei denen sich das Knacken dieses Master-Passworts lohnen könnte.

Es dauerte anschliessend nicht lange, bis IT Security-Experten auf diverse Ungereimtheiten in der Kommunikation und den Ereignissen hinwiesen:

• Die Kommunikation am 22.12. führte dazu, dass die Brisanz im Weihachtstrubel weitgehend unterging (und wohl auch viele Kunden gar nicht realisierten, welche Probleme da auf sie zukommen).
• Es ist schwer erklärbar, wieso LastPass nicht schon im September erkannt haben soll, dass neben Teilen des Source Codes auch Zugriffsschlüssel für den Cloudspeicher entwendet wurden. «Solche Schlüssel dürfen nicht in einer Entwicklungsumgebung gespeichert werden» mag als Richtlinie zwar gelten, aber im Falle eines unautorisierten Zugriffs sollte man sich da, vor allem als Unternehmen aus dem Sicherheitsbereich, nicht darauf verlassen und eine Prüfung vornehmen. Wenn man nicht sowieso aus reiner Vorsicht vom Schlimmsten ausgeht und alle Zugangsdaten generell erneuert.
• Auf die Problematik der nicht-verschlüsselten Zusatzdaten wie URLs wurde LastPass schon in der Vergangenheit (2015, 2017, 2018) mehrfach aufmerksam gemacht. Das Unternehmen sah es offenbar nicht als notwendig an, da etwas zu ändern.
• Die im Blog-Post unter «What Should LastPass Customers Do?» empfohlenen Massnahmen (Masterpassword mindestens 12-stellig, >100’000 Iterationen für die Schlüssel-Generierung (siehe technischer Einschub am Anfang dieses Artikels)) tönen zwar gut, werden in der Praxis von LastPass aber in keinster Weise aktiv eingefordert: Wer seit Jahren ein kürzeres Passwort nutzte, wurde nie dazu gezwungen, ein längeres zu verwenden; viele seit längerem bestehenden Accounts haben bei der Schlüssel-Generierung Iterations-Werte deutlich unter 100’000 definiert. Bei beidem hätte LastPass schon seit längerer Zeit die Sicherheitsstandards selbständig erhöhen können (und bei den Iterationen stellt sich die grundsätzliche Frage, wieso Nutzerinnen überhaupt unsichere Werte definieren können), zieht es im Blogpost mit Formulierungen wie «If you use the default settings above» aber vor, den Kunden die Schuld in die Schuhe zu schieben (da die Default-Settings bei älteren Accounts eben nicht greifen).

Kein Wunder also, dass diverse Blogs von IT-Sicherheitsexperten wie auch verschiedene Medienberichte sehr explizit empfahlen, auf einen anderen Passwort-Manager zu wechseln da LastPass weder als Produkt noch als Unternehmen weiter vertrauenswürdig seien. Die Tatsache, dass der Besitzer von LastPass unterdessen weitere Lecks bekannt gegeben hat, dürfte dies noch unterstreichen.

Threema

Anfangs Oktober 2022 wurde Threema von der Applied Cryptography Group der ETH Zurich über eine Reihe von Schwachstellen im Messenger informiert welche ein Master-Student im Rahmen seiner Masterarbeit entdeckt hatte. Die Forschungsgruppe und das Unternehmen vereinbarten in der Folge eine dreimonatige Stillhaltefrist während der das Unternehmen die Probleme beheben konnte, und eine öffentliche Bekanntmachung («public disclosure») anfangs 2023.

Diese erfolgte dann am 9. Januar auf mehreren Kanälen:

• Das Unternehmen selbst publizierte unter dem Titel «New Paper on Old Threema Protocol» eine technisch fokussierte Erklärung der Forschungsergebnisse und der ergriffenen Massnahmen. Es betonte dabei insbesondere, dass die gefundenen Schwachstellen unter reellen Bedingungen nicht ausnutzbar gewesen wären und in den neusten Versionen entweder behoben oder durch die mittlerweile erfolgte Einführung eines neuen Protokolls obselet geworden waren.
• Die Forschungsgruppe publizierte ihre Ergebnisse auf einer eigens aufgesetzten Website mit dem sprechenden Namen breakingthe3ma.app. Auf dieser werden die gefundenen Schwachstellen teilweise recht drastisch beschrieben, auch findet sich ein Link auf ein Paper mit weiterführenden Details.
• In der NZZ erschien ein längerer Artikel mit dem Titel «Verschlüsselung hinkt Jahre hinterher: Der Schweizer Messenger Threema setzte bis vor kurzem auf veraltete Kryptografie». Und auch wenn der Artikel inhaltlich versucht, verschiedene Stimmen (inklusive dem Anbieter selbst) zu Wort kommen zu lassen, geben sowohl der Titel wie auch einzelne Abschnitte dem Thema einen negativen Spin.

In der Folge passierte, was in solchen Fällen schnell mal passiert: Die schnelle und weite Verbreitung sowohl des NZZ-Artikels wie auch der speziell aufgeschalteten ETH-Webseite via Social Media und einschlägigen Kanälen führten dazu, dass die sachliche (aber vielleicht etwas trockene und defensive) Darstellung des Anbieters kaum Beachtung fand. Auch der den eigenen Blogpost ankündigende Tweet rief mit einer tendenziell passiv-aggressiven Formulierung zumindest auf Twitter primär negative Reaktionen hervor.

Und spätestens nachdem die internationale Tech-Presse mit Titel wie «Threema Under Fire After Downplaying Security Research» und «Messenger billed as better than Signal is riddled with vulnerabilities» berichtete, und selbst Bruce Schneier den Blog-Post von Threema mit «The company is performing the usual denials and deflections» referenzierte, hatte Threema die Kontrolle über die Kommunikation definitiv verloren und fand sich inmitten eines Security-Shitstorms wieder.

Da half dann auch der weit über die offizielle Kommunikation hinausgehende Blog-Post eines Threema-Mitarbeiters nicht mehr, der die Hintergründe einiger der kritisierten Design-Entscheide offenlegte und auch aufzeigte, welche (teilweise unrealistischen) Voraussetzungen hätten erfüllt sein müssen um die identifizierten Schwachstellen effektiv auszunutzen. Auch Threema selbst aktualisierte den bereits publizierten Beitrag und gab ihm einen neuen Titel, die allgemeine Berichterstattung lässt zumindest bezweifeln, dass er breit gelesen wurde.

So geriet der Realitätscheck in der medialen Aufregung genauso vergessen wie die eigentlich wichtige Feststellung, dass Verschlüsselungsalgorithmen und -protokolle zwingend offengelegt und von unabhängigen Stellen geprüft werden sollten um das Vertrauen ins Produkt zu steigern. Und Threema wurde für die Bemühungen zur Behebung der Schwachstellen mit eher schlechten Publicity “belohnt”, selbst der schon seit längerem geplante Rollout des verbesserten Verschlüsselungsprotokolls (welcher ja im Grunde genommen als positive Massnahme hätte beworben werden können) wurde vielenorts als überhastete defensive Handlung interpretiert.

Was könnte man besser machen?

Kurz gesagt, einiges, in beiden Fällen.

Grundsätzlich gibt es in Krisen (unabhängig davon ob das jetzt ein Flugzeugabsturz, ein Produktrückruf oder eben ein Cyber-Vorfall ist) einige zentrale Kommunikationsregeln die man grundsätzlich beachten sollte. Die finden sich in jedem einschlägigen Handbuch (und sind den jeweiligen Kommunikationsverantwortlichen hoffentlich geläufig):

• Offene und ehrliche Kommunikation: Sagen was passiert ist, ohne Dinge zu beschönigen oder sich als Opfer dunkler Machenschaften darzustellen. Das schafft Vertrauen und beugt Gerüchten vor (die sich zwar nie ganz vermeiden, mit einer offenen Kommunikation aber im Normalfall unter Kontrolle halten lassen).
• Auswirkungen klar kommunizieren: Wer oder was ist betroffen, wer oder was nicht; verbunden allenfalls mit Handlungsanweisungen an die Betroffenen oder Empfehlungen für alle Nutzer. Auch hier gilt, zu dem zu stehen was man noch nicht weiss, und lieber mal im Interesse des Kunden zu vorsichtig zu sein (zum Beispiel im Stil von «We are still assessing the number of accounts impacted, but we have reset the passwords on all accounts. Clients can regain access by selecting «I forgot my password» the next time they want to log in.»).
• Weitere Schritte und Updates: Je nach Grösse des Vorfalls ist es mit einer einzelnen Meldung nicht getan. Das Klären von noch offenen Punkten kann ein paar Stunden oder Tage dauern, Analysen zusammen mit Partnern (oder Strafbehörden) können notwendig sein, im schlimmsten Fall sind zum Zeitpunkt der Erstinformationen generell noch wenig Details bekannt. Da ist es dann wichtig, dass den Kunden zumindest klar ist, in welchen Zeitraum mit weiteren Informationen zu rechnen ist (und was sie zwischenzeitlich allenfalls tun oder eben nicht tun sollten).

Etwas ausführlicher hat es Dominic Bertram an der ISSS Conference in Bern vor ein paar Tagen beschrieben. In einem Vortrag (noch nicht online) mit dem Titel «Communicating in the eye of the storm: Dos and Don‘ts for cyber crisis communications» präsentierte er je sechs Punkte die es bei der Kommunikation von Cyber-Vorfällen zu berücksichtigen oder eben zu vermeiden gilt.

• Kenne Deine Stakeholder und ihre Bedürfnisse: Simpel gesagt ist dies das A&O jeglicher Kommunikation: Wenn ich nicht weiss mit wem ich rede, kann ich auch die Botschaft nicht empfängergerecht aufbereiten. Bezogen auf Sicherheitsvorfälle bedeutet dies unter anderem, dass die Medienmitteilung ans breite Publikum anders geschrieben werden muss als die konkrete Information an die Kunden (welche uU detaillierte Handlungsanweisungen erwarten), und eine allfällige technische Analyse für interessierte Fachleute dann nochmals anders formuliert sein muss. Als zusätzliche Herausforderung muss man davon ausgehen, dass sich die verschiedenen Stakeholder-Gruppen überlappen, Mitteilungen an die verschiedenen Gruppen sollten sich daher mit Vorteil ergänzen (und nicht widersprechen) und auch nicht eine nicht direkt addressierte Gruppe vor den Kopf stossen.
• Sei Dir Deiner Pflichten bewusst: Je nach Art des Vorfalls bestehen gesetzliche Vorgaben welche einzuhalten sind. Im ab September 2023 geltenden Datenschutzgesetz ist die Information betroffenener Nutzerinnen vorgesehen, unter Umständen besteht eine generelle Meldepflicht und bei international relevanten Applikationen oder Plattformen kommen abhängig vom Standort der betroffenen Nutzer zusätzliche Regeln dazu.
• Versuche nicht, den Vorfall zu vertuschen oder auszusitzen: Egal ob Du selber auf eine sicherheitsrelevante Schwachstelle stösst, oder Du von Dritten darauf aufmerksam gemacht wirst: Wenn es mal jemand rausgefunden hat, werden es in Zukunft auch andere rausfinden, also ist es eine Frage der Zeit bis es öffentlich wird. Und da kommuniziert man am besten zeitgerecht selbst, einerseits um den eigenen Kunden weiteren Schaden zu ersparen (bzw. ihnen zu ermöglichen, einen solchen einzudämmen), andererseits um die Kontrolle über die Kommunikation und ein allfälliges Framing zu behalten. Das heisst natürlich nicht, dass man bei Sicherheitslücken kein Responsible Disclosure anwenden sollte. Aber das Ziel von Responsible Disclosure ist es, den Entwicklern Zeit zum Schliessen von Lücken zu geben bevor man sie kommuniziert (und so zu vermeiden, dass sie von jedem Möchtegern-Hacker ausgenutzt wird). Es kann nicht die Idee sein, diese Frist quasi ins Unendliche auszudehnen (mit ein Grund, wieso die Offenlegungs-Frist meist nur wenige Wochen oder Monate beträgt).
• Übernimm Verantwortung, stell Dich nicht als Opfer dar und spiel den Vorfall nicht runter: Fehler passieren, man tut gut daran, dazu zu stehen wenn sie bekannt werden. Eine «wir sind Opfer von bösen Hackern»-Strategie mag vielleicht bei unkritischen Medien teilweise funktionieren, aber sowohl bei Kunden wie auch bei interessierten Fachkreisen löst sie primär Stirnrunzeln und Misstrauen aus. Genau dieselben Fachkreise sind dann durchaus auch in der Lage, eine allzu schönmalerische Beschreibung des Vorfalls und dessen Auswirkungen zu durchschauen, und dies auch selbst entsprechend zu kommunizieren. Insofern ist «Hinstehen und sagen was ist» der beste Weg, um das Vertrauen der Stakeholder nicht zu verlieren und auch nicht die Kontrolle über den Inhalt der Kommunikation zu verlieren.
• Hole Vertrauen durch die Kommunikation von Korrekturmassnahmen zurück: Zu Fehlern zu stehen ist der wichtige erste Schritt, oft genauso wichtig ist anschliessend die Kommunikation der aus dem Fehler gezogenen Lehren und Massnahmen. Damit kann man deutlich machen, dass man gewillt ist, denselben Fehler nicht nochmals zu machen. Gerade bei Unternehmen im Security-Bereich ist es auch eine naheliegende Möglichkeit, einen zum Beispiel im Leitbild stehenden Satz «bei uns steht Sicherheit an erster Stelle» in der Praxis zu demonstrieren.
• Kommuniziere aktiv und rechtzeitig, behalte die Kommunikationsoberhand: Das geht weitgehend schon aus den obigen Punkten hervor, gerade die Thematik der Kommunikationsoberhand sollte man definitiv nicht unterschätzen. Wer ein Thema bzw. eine Sicherheitslücke als erstes kommuniziert, hat die Deutungshoheit über die Beschreibung und die wahrgenommene Kritikalität. Sollte die Oberhand nicht beim betroffenen Unternehmen selber liegen, dann ist dieses schnell mal der öffentlichen Wahrnehmung ausgeliefert und schon von Anfang an in der Defensive.

Wenn wir nun mit diesen Punkten in der Hand nochmals die Krisenkommunikation der beiden eingangs erwähnten Beispiele betrachten, dann fällt folgendes auf:

• Von einer offenen und ehrlichen Kommunikation durch LastPass kann man beim besten Willen nicht sprechen. Die Lücken und (potentiellen) Datenabflüsse wurden schleppend und spät kommuniziert, Schwachstellen schöngeredet (und seit Jahren offene Probleme nicht behoben) und die Verantwortung für die Datensicherheit bei den Kunden auch bei Aspekten in die Schuhe geschoben wo das Unternehmen selber nachbessern könnte. Gerade für einen Internet-basierten Password-Manager (bei dem man sich als Kunde ja darauf verlassen muss, dass der Anbieter alles richtig macht) ist das fatal. Ob diese Strategie (die wohl darauf hofft, dass die meisten Nutzer es nicht merken und/oder Lastpass wegen dem verhältnismässig hohen Aufwand für den Wechsel zu einer anderen Lösung nicht deinstallieren) aufgeht, wird sich zeigen. Die Tatsache, dass diverse Sicherheitsforscher und Blogposts von der weiteren Nutzung von Lastpass abraten, deutet eher darauf hin, dass sie nicht funktionieren wird.
• Ein gutes Anschauungsbeispiel für den Verlust der Kommunikationsoberhand und die daraus entstehenden Probleme zeigt sich bei Threema. Natürlich kann das Unternehmen nix dafür, dass sowohl die Präsentation der Forschungsergebnisse durch die ETH wie auch der NZZ-Artikel die gefundenen Schwächen in ein allzu krasses Licht rückten. Aber “bad news travel faster” gilt auch im Medienbusiness und so erreichten die «Threema ist nicht sicher»-Schlagzeilen deutlich mehr Verbreitung als die nüchternen und sich primär an ein technisch affines Fachpublikum wendenden Ausführungen im Statement des Unternehmens selbst. Die Deutungshoheit der (zum Publikationszeitpunkt ja bereits behobenen) Schwachstellen lag daher von Anfang an nicht beim Unternehmen selbst, welches so gezwungen war, aus der Defensive her das Vertrauen der Nutzer ins Produkt mit einem wiederholten Aktualisieren des eigenen Statements und viel Medienarbeit wieder herzustellen.

Auch wenn die Fälle aus technischer Sicht unterschiedlicher nicht sein könnten (Lastpass hatte bereits einen schlechten Security-Track Record, die technischen Lücken in Q3/Q4 2022 schlecht kommuniziert/vertuscht und ist sowohl technisch wie auch organisatorisch nicht mehr vertrauenswürdig; Threema hat die Responsible Disclosure-Frist dazu genutzt, mit dem sich bereits in Entwicklung befindlichen Protokoll-Update die Probleme an der Wurzel zu lösen und ist technisch nach aktuellem Wissen sicher), zeigen beide doch deutlich, dass bei Security-Vorfällen eine gute, aktive Kommunikation zentral ist.

Die Zeiten, in denen Applikationen von Nerds für Nerds entwickelt wurden, der Fokus rein auf der Technik lag und man quasi unter Gleichgesinnten kommunizierte, sind wohl definitiv vorbei. Ohne klare (Krisen-)Kommunikationsstrategie und für die Allgemeinheit verständliche Messages laufen auch IT-Unternehmen Gefahr, im Falle einer realen oder schon nur herbeigeredeten Krise von den Ereignissen überrollt zu werden.