Resilienz durch Identität

Resilienz bezeichnet die Fähigkeit einer kritischen Entität, einem Vorfall vorzubeugen, sich dagegen zu schützen, darauf zu reagieren, ihm zu widerstehen, ihn abzumildern, ihn zu absorbieren, zu bewältigen und sich davon zu erholen.

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 unten). Die neue Version, die 2.0, wird 2024 fertiggestellt und formalisiert.

Wenn Sie das NIST-Bild aufzeichnen, was im Bereich der Cyberverteidigung üblicherweise getan wird, werden Sie feststellen, dass der größte Teil der Industrie, des Budgets und der Aufmerksamkeit auf den Bereich “Protect” gerichtet ist, in dem präventive Tools angesiedelt sind. Das ist unausgewogen. Der Gesetzgeber fordert mehr Aufmerksamkeit auf Identify, Incident Response und Recovery. Die andere auffällige Ähnlichkeit ist die Aufmerksamkeit für die Lieferkette, sowohl in NIS2 als auch in NIST 2.0. Dies wird wahrscheinlich zu einer tektonischen Verschiebung in den Zuständigkeitsbereichen führen und die Verantwortung für Cybersicherheit von der traditionellen IT-Abteilung weg verlagern.

Dies ist ein aktueller Strategiewechsel – der Gamechanger ist die harte und teure Lektion von Ransomware, dass, sobald die Prävention umgangen wird, die Reaktionsfähigkeiten (Response) sich als weitgehend unterentwickelt erweisen und sich Vorfälle unnötigerweise zu ausgewachsenen Katastrophen entwickeln.

Dieses strukturelle Ungleichgewicht ist ein logisches, aber unbeabsichtigtes Ergebnis des risikobasierten Ansatzes, bei dem der Schwerpunkt auf der Identifizierung von Risiken im Zusammenhang mit bekannten Werten liegt, bevor eine spezielle Reaktion festgelegt wird. Dies führt dazu, dass unwahrscheinliche Risiken übersehen werden, die Lieferkette vergessen wird und es zu einer Voreingenommenheit gegenüber der Prävention und einer Zersplitterung der Bemühungen durch punktuelle Lösungen kommt.

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 NIS2 in der EU (und dem derzeit in Vorbereitung befindlichen Nachfolgeprojekt) fordern 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 (incident response), die Kommunikation und die Krisenbewältigung – in Zusammenarbeit mit der Lieferkette und den Behörden. Themen, die für die Cyber-Resilienz von zentraler Bedeutung sind.

Incident Response ist das, was Organisationen tun, wenn etwas schiefläuft. Feuerwehrleute löschen Brände, Sanitäter versorgen Verletzte, Soldaten schießen auf den Feind – vorbereitete und organisierte Reaktionen von spezialisierten und benannten Personen, den Incident Responders. Auch im Bereich der Cybersicherheit gibt es Vorfälle, die sich zu ausgewachsenen Katastrophen entwickeln können, wenn sie unbeachtet bleiben. Deshalb gibt es CSIRTs, Computer Security Incident Response Teams für Cyber-Vorfälle. Besser gesagt, viele Unternehmen behaupten, sie hätten “CSIRT-Fähigkeiten”, da sie ein Security Operating Centre haben. Oder sie haben die IT an einen Anbieter ausgelagert, der über ein SOC verfügt. Oder es handelt sich um einen virtuellen Prozess eines virtuellen Teams, 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. Dies führt häufig dazu, dass die IT-Abteilung in einen Topf geworfen wird und für den großen Bereich der Business Resilience verantwortlich gemacht wird, für den sie eigentlich gar nicht gerüstet ist.

Wesentlich für ein gutes Verständnis von NIS2 ist, dass die in diesem Gesetz 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 Sie für den Umgang mit einem ausgewachsenen Ransomware-Angriff oder einem Brand im Rechenzentrum Ihres Cloud-Anbieters benötigen.

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 NIS2; wir müssen aus dem IT-Sicherheitsbereich in die reale Welt heraustreten und den Beschränkungen des Paradigmas der Cyberverteidigung entkommen.

Wie oben in der Übersicht über die Reaktion auf Vorfälle ersichtlich, gibt es drei Hauptgruppen von Prozessen, die kohärent funktionieren sollten, um eine Chance auf Erfolg zu haben:

• Erkennen (detect) – die Prozesse und Akteure, die als Stolperdraht fungieren und Sie alarmieren, wenn etwas vor sich geht. Hier ist die Cybersicherheit in der Regel angesiedelt, entweder als internes SOC (Security Operating Center) oder bei einem Managed Security Provider als Outsourcing-Partner. Da alle Arten von Störungen in den Anwendungsbereich der NIS2 fallen, nicht nur solche, die als Cyber- oder IT-Störungen betrachtet werden, muss das, was heute vorhanden ist, wahrscheinlich neu geplant und gestaltet werden.
• 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 und Beseitigung von Angreifern. Dies 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. Dies 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, ein weiterer unterentwickelter Teil, der in der NIS2 hervorgehoben wird. Es ist verpflichtend, die Behörden, die Kunden und die Lieferketten zu informieren. Hier werden harte Fragen gestellt werden – alles geheim zu halten ist keine Option mehr.

Dieses Post hat nicht den Anspruch, ein vollständiges Bild der Reaktion auf Cybervorfälle zu zeichnen, denn das würde ein ganzes Buch füllen. Es dient jedoch als Hintergrund für den kommenden Post, in dem es um die Überschneidungen mit den Themen und Möglichkeiten des Identitätsmanagements geht und darum, wie Sie diese nutzen können, um Ihre Erfolgschancen in der nächsten Cyber-Krise zu verbessern.

Das Schwierigste bei Cyber-Vorfällen ist nicht die Erkennung (detection), sondern die Erkenntnis, dass die Erkennung schwierig ist und die Tools nur sehr begrenzt einsetzbar sind. Wie von IBM berichtet, entdeckte nur ein Drittel der Unternehmen Datenschutzverletzung durch ihre eigenen Sicherheitsteams, erstaunliche 67 % der Verstöße wurden von einer gutartigen dritten Partei oder von den Angreifern selbst gemeldet. Es unmöglich zu sagen, wie viele Unternehmen völlig unbemerkt angegriffen und kompromittiert wurden, und wir wissen aus anekdotischen Beweisen (APT1, Sellafield, Buckshot Yankee), dass Verstöße jahrelang andauern können; daraus müssen wir schließen, dass die Erkennung in den meisten Fällen fehlschlägt und dass der Gesetzgeber mit seiner Forderung nach einer effektiveren Incident Response Recht hat.

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 “Persistenzen” (Hintertüren), die in dem riesigen Heuhaufen Ihrer 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 großes Maß an blindem Vertrauen; Sie sollten zumindest nach Wegen suchen, die ein Angreifer möglicherweise geschaffen hat. In der Cybersicherheit wird dies als Persistenz bezeichnet.

Häufige Vektoren für Persistenz 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 Backups, die bekanntermaßen sauber sind, oder Neuaufbau von Grund auf sowie Identitätsmanagementsysteme.

Ein Blick auf das Diagramm macht deutlich, dass eine Ad-hoc-Reaktion nur bedingt erfolgreich sein wird und auch nicht sehr schnell erfolgen kann.

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 Partnern) unterstützt werden.

Aber … haben wir das nicht schon, mit unserer Best-of-Breed-IAM-Lösung?

Das ist nicht sehr wahrscheinlich.

Identitätsmanagement-Prozesse und -Systeme sind nur selten für die Wiederherstellung bei Sicherheitsverletzungen ausgelegt – schauen Sie sich die Anwendungsfälle an, und Sie werden feststellen, dass Identitätsmanagement und Incident Response nur selten zusammenkommen. Die Tools, die umfangreiche Literatur, in der bewährte IAM-Verfahren beschrieben werden, und die seit langem etablierten Standards sollten dies abdecken. Das ist kaum der Fall.

Dabei sind sie von grundlegender Bedeutung für den Erfolg. Bedenken Sie, dass die IAM-Systeme auch der Hauptangriffsvektor und der Dreh- und Angelpunkt in den späteren Phasen eines Einbruchs sind, wenn die Privilegien des Angreifers zu Root-Rechten erweitert werden, da Konten die Schlüssel zum Königreich sind. In der Literatur zum Thema Identitätsmanagement wird dieses Thema im Allgemeinen völlig außer Acht gelassen. Dies ist eine große Lücke in der Cyberabwehr. Um diese Lücke zu schließen, werden im nächsten Kapitel die Anwendungsfälle aufgelistet, die in einer Cyber-Krise relevant sein könnten. Mit diesen Informationen sollte der IAM-Prozessverantwortliche in der Lage sein, die von NIS2 angestoßene Phase der Cyber Resilience mit Zuversicht zu betreten.