Lektionen aus der Ransomware-Ära: Von Prävention zu Resilienz

Hinweis: Dieser Artikel stammt aus der Ausgabe 1/2025 der Zeitschrift IT-SICHERHEIT. Das komplette Heft können Sie hier herunterladen. (Registrierung erforderlich)

Wie der Überblick über die neuen Rechtsvorschriften zu Themen der Cybersicherheit in der EU deutlich zeigt, fordern die Regulierungsbehörden mehr Aufmerksamkeit für die Krisenbewältigung. Damit soll das Gleichgewicht in der Sicherheitspraxis wiederhergestellt werden, die sich in erster Linie auf die Prävention konzentriert und die Reaktion vernachlässigt hat. Die Bemühungen sind Teil einer umfassenderen Entwicklung, wie wir sie auch beim amerikanischen NIST-Rahmenwerk beobachten können (siehe Abbildung 1).

Bei der Betrachtung des NIST-Frameworks fällt auf, dass dem Bereich „Protect“, in dem die präventiven Instrumente angesiedelt sind, viel Aufmerksamkeit gewidmet wird. Dies ist unausgewogen. Der Gesetzgeber fordert deswegen mehr Beachtung für Identify, Incident Response und Recovery. Die andere Auffälligkeit ist die Aufmerksamkeit für die Lieferkette, sowohl in NIS-2 als auch in NIST 2.0. Dies wird wahrscheinlich zu einer tektonischen Verschiebung der Zuständigkeitsbereiche führen und die Verantwortung für Cybersicherheit weg von der traditionellen IT-Abteilung verlagern.

Dieser Strategiewechsel ist eine Folge der harten und teuren Lektion von Ransomware. Denn es hat sich gezeigt, dass die Reaktionsfähigkeit (Response) in vielen Unternehmen unterentwickelt ist, sobald die Prävention umgangen wird, und so haben sich Vorfälle unnötigerweise zu echten Katastrophen ausgeweitet.

Fokusverschiebung

Dieses strukturelle Ungleichgewicht ist eine logische, aber unbeabsichtigte Folge des risikobasierten Ansatzes, bei dem der Schwerpunkt auf der Identifizierung bekannter Risiken liegt, bevor eine spezifische Reaktion festgelegt wird. Das führt dazu, dass unwahrscheinliche Risiken übersehen werden, die Lieferkette außer Acht gelassen wird, die Prävention zu kurz kommt und die Bemühungen durch punktuelle Lösungen zersplittert werden.

Im Finanzrisikomanagement wird dies als „Black-Swan-Effekt“ bezeichnet, der dazu führt, dass Unternehmen auf unvorhergesehene Ereignisse oder sogar auf eine Kombination von erwartbaren Ereignissen zur gleichen Zeit nicht vorbereitet sind. Mit NIST 2.0 in den USA und NIS-2 in der EU verlangen die Gesetzgeber nicht, dass man bei der Prävention nachlässt oder die risikobasierte Vorgehensweise vergisst, aber sie fordern mehr Ausgewogenheit. Daher lenkt er die Aufmerksamkeit auf die Reaktion auf Vorfälle, die Kommunikation und die Krisenbewältigung – in Zusammenarbeit mit der Lieferkette und den Behörden. Themen, die für die Cyberresilienz von zentraler Bedeutung sind.

Gedanken zur Incident Response

Incident Response ist das, was Organisationen tun, wenn etwas schiefläuft. Im Bereich der Cybersicherheit gibt es Vorfälle, die sich zu ausgewachsenen Katastrophen entwickeln können, wenn sie unbeachtet bleiben. Deshalb existieren Computer Security Incident Response Teams (CSIRTs). Besser gesagt, viele Unternehmen behaupten, sie hätten „CSIRT-Fähigkeiten“, da sie ein Security Operations Center (SOC) haben. Oder sie haben die IT an einen Anbieter ausgelagert, der über ein SOC verfügt. Manchmal handelt es sich um ein virtuelles Team, das der IT untersteht. Oft ist der IT-Helpdesk in der Praxis das CSIRT, während sich der Rest in der Semantik und der Büropolitik verliert. Die meisten Unternehmen haben kein CSIRT und tun sich schwer, die „Gleichwertigkeit“ dessen, was sie haben, zu erklären.

Der Begriff Incident Response ist für die Cybersicherheit vielleicht auch nicht die glücklichste Wahl, da es im IT-Support einen Prozess gibt, der fast den gleichen Namen trägt – Incident Management – mit einer marginalen und meist optischen Überschneidung. Das führt häufig dazu, dass die IT-Abteilung in einen Topf geworfen und für den großen Bereich der Business Resilience verantwortlich gemacht wird, für den sie eigentlich nicht gerüstet ist.

Wesentlich für ein gutes Verständnis von NIS-2 ist, dass die dort geforderten Maßnahmen zum Management von Cybersecurity-Risiken auf einem „All-Hazard-Ansatz“ zur Reaktion auf Vorfälle beruhen sollten und nicht auf identifizierbare IT-Vorfälle innerhalb der eigenen IT-Infrastruktur beschränkt sind: „Die von der Einrichtung ergriffenen Maßnahmen des Cybersicherheitsrisikomanagements sollten nicht nur die Netz- und Informationssysteme der Einrichtung, sondern auch die physische Umgebung dieser Systeme vor Ereignissen wie Sabotage, Diebstahl, Brand, Überschwemmung, Telekommunikations- oder Stromausfällen oder unbefugtem physischen Zugriff schützen, die die Verfügbarkeit, Authentizität, Integrität oder Vertraulichkeit gespeicherter, übermittelter oder verarbeiteter Daten oder der von Netz- und Informationssystemen angebotenen oder über diese Systeme zugänglichen Dienste beeinträchtigen können.“

Wenn man darüber nachdenkt, hat eine Organisation, die auf die Bewältigung von Vorfällen wie dem Tonermangel eines Druckers zugeschnitten ist, nur wenig mit dem gemein, was für den Umgang mit einem ausgewachsenen Ransomware-Angriff oder einem Brand im Rechenzentrum des Cloud-Anbieters notwendig ist.

Wir haben es hier mit einem Thema zu tun, das manche als „War Room“ bezeichnen; ein Ausnahmezustand, bei dem alle Mann an Deck sein müssen. Der Begriff fasst die Relevanz, die Dringlichkeit und die chaotische Natur dieses Themas treffend zusammen. Der War Room ist das Herzstück von NIS-2; wir müssen aus dem IT-Sicherheitsbereich in die reale Welt heraustreten und den Beschränkungen des Paradigmas der Cyberverteidigung entkommen.

Prozessgruppen zur Krisenbewältigung

Wie Abbildung 2 zeigt, gibt es drei Hauptgruppen von Prozessen, die kohärent funktionieren sollten, um eine Chance auf Erfolg zu haben:

• Erkennen: Prozesse und Akteure, die als Stolperdraht fungieren und alarmieren, wenn etwas vor sich geht. Hier ist die Cybersicherheit in der Regel angesiedelt, entweder als internes SOC oder bei einem Managed Security Provider als Outsourcing-Partner. Da alle Arten von Störungen in den Anwendungsbereich der NIS 2-Richtlinie fallen, nicht nur solche, die als Cyber- oder IT-Störungen betrachtet werden, ist es wahrscheinlich, dass das, was heute vorhanden ist, neu geplant und gestaltet werden muss.
• Handeln: Das eigentliche Krisenmanagement; kontinuierliche Analyse alias Triage (im Wesentlichen Risikobewertung dessen, was vermutlich vor sich geht, und Abwägung der Reaktionsmöglichkeiten), Forensik, Geschäftskontinuität und Eindämmung sowie Beseitigung von Angreifern. Das ist der Bereich des Blue Teams, der IT-Ingenieure, die den Sicherheitsanalysten erklären, was die Systeme tun und wie sie funktionieren (um zu entscheiden, was zu tun ist), die Dinge im Handumdrehen reparieren und Daten und Systeme verschieben – harte Arbeit, die allzu häufig übersehen und unterbewertet wird. Sie ist auch nicht in einer Dienstleistungsvereinbarung geregelt. Das ist die Fähigkeit, die im Allgemeinen durch Outsourcing und technische Tiefe am schwächsten ist – eine Grenzlinie zu verteidigen, die man kennt, ist viel einfacher als eine, die man nicht kennt. Hier geht es darum, den Heimvorteil zu haben – oder eben nicht.
• Kommunizieren: Stakeholder und Shareholder auf dem Laufenden halten und schwierige Fragen beantworten, sind ein weiterer unterentwickelter Teil, der in der NIS-2 hervorgehoben wird. Es ist verpflichtend, die Behörden, die Kunden und die Lieferketten zu informieren. Hier werden harte Fragen gestellt – alles geheim zu halten ist keine Option mehr.

Herausforderungen bei Incident Response und Identity-Management

Das Schwierigste bei Cyber-Vorfällen ist nicht das Erkennen (Detection), sondern die Erkenntnis, dass das Detektieren nicht leicht ist und die Werkzeuge nur sehr begrenzt einsetzbar sind. Wie von IBM berichtet, entdeckte nur ein Drittel der Unternehmen einen Datenmissbrauch durch ihre eigenen Teams, erstaunliche 67 Prozent der Verstöße wurden von einer gutartigen dritten Partei oder von den Angreifern selbst gemeldet.

Es ist unmöglich zu sagen, wie viele Unternehmen vollkommen unbemerkt angegriffen und kompromittiert wurden, und wir wissen aus anekdotischen Beweisen (APT1, Sellafield, Buckshot Yankee), dass Verstöße jahrelang andauern können. Daraus ist zu schließen, dass die Detektion in den meisten Fällen versagt und der Gesetzgeber zu Recht eine effektivere Störfallreaktion fordert.

Noch schwieriger ist es, angemessen zu reagieren und zu wissen, wie und wann die Sicherheitsverletzung beendet ist. Wie und wann kann man das Vertrauen wiederherstellen und sagen, dass der Geschäftsbetrieb wieder sicher ist, wenn man nur unvollständige und indirekte – und wahrscheinlich zweideutige – Informationen über das Ausmaß und die Mittel der Sicherheitsverletzung hat? Die zentrale Herausforderung besteht darin, wie ein Angreifer abgewehrt werden kann, einschließlich aller Arten von möglichen Hintertüren, die in dem riesigen Heuhaufen der eigenen Infrastruktur versteckt sind. Vor allem, wenn man bedenkt, dass man wahrscheinlich nicht weiß, wie lange der Angriff andauerte und wie groß der Heuhaufen ist.

Häufig gehen die Opfer von Sicherheitsverletzungen davon aus, dass die Angriffe vorbei sind, wenn kein verdächtiges Verhalten mehr beobachtet wird. Da sie beim ersten Einbruch praktisch blind waren, bedeutet dies ein hohes Maß an blindem Vertrauen. Unternehmen sollten aber zumindest nach Wegen suchen, die ein Angreifer möglicherweise geschaffen hat. In der Cybersicherheit wird dies als Persistenz bezeichnet.

Häufige Angriffspunkte für diese Advanced Persistent Threats (APTs) sind Malware, ungeschützte Zugangspunkte, erhöhte Berechtigungen für normalerweise harmlose Accounts und kompromittierte Anmeldeinformationen, vorzugsweise von der nicht rotierenden Art, wie Systemkonten, dauerhafte Cookies, API- und SSH-Schlüssel und nicht zuletzt PKI-Zertifikate. Die drei letztgenannten Arten von Anmeldeinformationen sind nur allzu häufig in Code-Repositories in der Cloud gespeichert – Github ist voll davon.

Eine besondere Erwähnung verdient die Kategorie der externen Konten wie LinkedIn und Github, bei denen die Mitarbeiter die E-Mail-Adresse des Unternehmens als Benutzernamen verwenden und somit zur Wiederverwendung von Passwörtern verleitet werden, wodurch das Unternehmen Credential-Stuffing-Angriffen ausgesetzt ist. Credential Stuffing ist laut OWASP eine der am häufigsten verwendeten Techniken, um Benutzerkonten zu übernehmen.

Auf dieser Grundlage sollte der Wiederherstellungsansatz aus vier Komponenten bestehen: Forensik, Anti-Malware-Tools, Wiederherstellung von sauberen Backups und Identitätsmanagementsystemen. Um eine Chance auf eine rasche Wiederherstellung zu haben, können diese Fähigkeiten nicht unter Zwang improvisiert werden, sondern sollten im Voraus aufgebaut und durch Schulungen und Wissen – einschließlich das von Partnern – unterstützt werden.

Identitätsmanagementprozesse und -systeme sind jedoch nur selten für die Wiederherstellung bei Sicherheitsverletzungen ausgelegt. Betrachtet man die Anwendungsfälle, so zeigt sich, dass Identity-Management und Incident Response oft nicht zusammenkommen. Die Tools, die umfangreiche Literatur, in der bewährte Identity and-Access-Management-(IAM)-Verfahren beschrieben werden, und die seit Langem etablierten Standards sollten dies abdecken. Das ist aber kaum der Fall.

Dabei sind sie von grundlegender Bedeutung für den Erfolg. IAM-Systeme sind der Hauptangriffsvektor sowie der Dreh- und Angelpunkt in den späteren Phasen eines Einbruchs, wenn die Privilegien des Angreifers auf Root-Rechte erweitert werden. In der Literatur zum Thema Identitätsmanagement wird dieses Thema im
Allgemeinen völlig außer Acht gelassen. Das ist eine große Lücke in der Cyberabwehr.

Fazit

Die Cybersicherheit muss zu einem ganzheitlichen Resilienzansatz entwickelt werden, unter anderem Incident Response, Identitätsmanagement und Krisenbewältigung berücksichtigt. Nur so kann die Sicherheit in einer zunehmend komplexen Bedrohungslandschaft gewährleistet werden. Dieser Wandel erfordert jedoch nicht nur technologische Anpassungen, sondern auch organisatorische und kulturelle Veränderungen innerhalb der Unternehmen.