Cybersecurity Analytics

Getrennte Systeme, getrennte Entscheidungen: Das verborgene Cybersecurity-Risiko

Ein Unternehmen kann über moderne Sicherheitstools, erfahrene Fachkräfte und ausführliche Verfahren verfügen und dennoch Schwierigkeiten haben, gute Cybersecurity-Entscheidungen zu treffen.

Dies ist häufig darauf zurückzuführen, dass die einzelnen Bestandteile der Sicherheitsumgebung separat voneinander funktionieren. Der Schwachstellenscanner erkennt Sicherheitslücken. Das Service-Desk-System verwaltet Tickets. Das Asset-Inventar enthält Informationen über Geräte. Das Risikoregister wird in einer Tabelle geführt. Der Einkauf speichert Informationen über Lieferanten in einem anderen System. Auditfeststellungen werden separat dokumentiert, während die Business-Continuity-Pläne an einem anderen Ort abgelegt sind.

Jedes Team verfügt über Informationen, aber niemand hat das vollständige Gesamtbild.

Das Problem besteht nicht unbedingt in einem Mangel an Technologie oder Daten. Das eigentliche Problem ist, dass Systeme, Teams und Entscheidungsprozesse nicht miteinander verbunden sind. In einer solchen Situation kann selbst eine technisch fortschrittliche Sicherheitsumgebung zu langsamen Reaktionen, unklaren Verantwortlichkeiten und schlecht fundierten Entscheidungen führen.

Mehr Tools bedeuten nicht automatisch mehr Sicherheit

Unternehmen reagieren auf neue Sicherheitsanforderungen häufig mit dem Kauf eines weiteren Tools. Eine neue Plattform wird für das Schwachstellenmanagement eingeführt, eine andere für die Endgeräteüberwachung, eine weitere für das Identitätsmanagement und noch eine andere für das Management von Drittparteirisiken.

Jede dieser Investitionen kann ein bestimmtes Problem lösen. Im Laufe der Zeit kann jedoch eine Umgebung entstehen, in der zahlreiche Tools vorhanden sind, die Informationen nicht auf eine sinnvolle Weise austauschen.

Ein System weiß, dass ein Server eine kritische Schwachstelle aufweist. Ein anderes System weiß, dass dieser Server eine Produktionsanwendung unterstützt. Ein drittes System enthält den Namen des Anwendungsverantwortlichen. Im Business-Continuity-Plan ist die Anwendung als betriebsnotwendig eingestuft, aber diese Information befindet sich in einem separaten Dokument.

Die Schwachstelle kann im technischen Bericht als kritisch eingestuft sein. Die Personen, die sie bewerten, können jedoch nicht ohne Weiteres erkennen:

  • welcher Geschäftsprozess von dem betroffenen System abhängt,
  • welche Informationen von der Anwendung verarbeitet werden,
  • ob der Server über das Internet erreichbar ist,
  • welche Sicherheitsmaßnahmen bereits implementiert sind,
  • ob ein externer Lieferant das System unterstützt,
  • wer für die Akzeptanz oder Reduzierung des Risikos verantwortlich ist,
  • welche Folgen es hätte, wenn die Behebung zu einer Betriebsunterbrechung führen würde.

Ohne diesen Kontext kann das Unternehmen eine falsche Entscheidung treffen. Es kann mehrere Tage damit verbringen, eine Schwachstelle auf einem Testsystem mit geringer Bedeutung zu beheben, während eine technisch weniger schwerwiegende Schwachstelle auf einem System bestehen bleibt, das einen wichtigen Produktionsprozess unterstützt.

Getrennte Daten führen zu getrennten Entscheidungen

Cybersecurity-Entscheidungen benötigen Kontext.

Eine technische Bewertung kann zeigen, wie schwerwiegend eine Schwachstelle sein könnte. Sie kann jedoch nicht allein das vollständige Geschäftsrisiko darstellen. Eine Liste von Sicherheitsvorfällen kann zeigen, wie viele Ereignisse aufgetreten sind, aber möglicherweise nicht erklären, welche Geschäftsservices davon betroffen waren. Eine Lieferantenbewertung kann vertragliche Schwächen identifizieren, aber möglicherweise nicht darstellen, ob der Lieferant Zugriff auf sensible Daten hat oder einen kritischen Geschäftsprozess unterstützt.

Wenn Informationen in getrennten Systemen gespeichert werden, basiert jede Entscheidung nur auf einem Teil der verfügbaren Fakten.

Dadurch entstehen mehrere typische Probleme.

Prioritäten basieren ausschließlich auf dem technischen Schweregrad

Sicherheitsteams verfügen häufig über mehr Feststellungen, als sie sofort bearbeiten können. Deshalb müssen sie entscheiden, welche Probleme zuerst behoben werden sollen.

Wenn die verfügbaren Informationen auf den technischen Schweregrad beschränkt sind, wird sich das Team verständlicherweise auf die höchsten technischen Bewertungen konzentrieren. Dieser Ansatz wirkt objektiv, berücksichtigt jedoch möglicherweise nicht die Kritikalität des Assets, die betriebliche Exposition, vorhandene kompensierende Sicherheitsmaßnahmen oder die Folgen einer Systemunterbrechung.

Eine bessere Entscheidung erfordert sowohl technische als auch geschäftliche Informationen.

Verantwortlichkeiten bleiben unklar

Eine Schwachstelle kann einem IT-Administrator zugewiesen werden. Dieser verfügt jedoch möglicherweise nicht über die Befugnis, eine Betriebsunterbrechung zu genehmigen oder das verbleibende Risiko zu akzeptieren.

Ein Problem mit einem Lieferanten kann an den Einkauf weitergeleitet werden, obwohl der betroffene Service einer anderen Abteilung zugeordnet ist. Eine Auditfeststellung kann offenbleiben, weil mehrere Teams beteiligt sind und niemand als verantwortlich benannt wurde.

Wenn Systeme voneinander getrennt sind, wird die Verantwortung häufig zwischen Teams weitergegeben. Das Ticket bewegt sich durch das Unternehmen, das Risiko bleibt jedoch bestehen.

Eskalationen erfolgen zu spät

Viele Unternehmen verfügen über Eskalationsverfahren. Diese Verfahren sind jedoch auf vollständige und rechtzeitig verfügbare Informationen angewiesen.

Eine kritische Maßnahme kann überfällig werden, ohne dass das Management davon erfährt. Eine Schwachstelle kann ihre Behebungsfrist überschreiten, ohne dass ein wirksamer Ausnahmeprozess eingeleitet wird. Eine Sicherheitsmaßnahme kann nicht mehr ordnungsgemäß funktionieren, während ihr Status weiterhin als implementiert gemeldet wird, weil kein aktueller Nachweis mit ihr verknüpft ist.

Bis das Problem das Management erreicht, kann die ursprüngliche Frist bereits abgelaufen sein.

Die verborgenen Auswirkungen auf Service Levels

Getrennte Systeme haben direkte Auswirkungen auf Cybersecurity-Service-Level-Agreements.

Wenn ein Sicherheitsproblem erkannt wird, müssen möglicherweise mehrere Schritte durchgeführt werden, bevor die Behebung beginnen kann:

  1. Die Feststellung muss überprüft werden.
  2. Das betroffene Asset muss identifiziert werden.
  3. Der technische Verantwortliche muss ermittelt werden.
  4. Der fachliche Verantwortliche muss einbezogen werden.
  5. Die betrieblichen Auswirkungen müssen bewertet werden.
  6. Ein Maßnahmenplan muss genehmigt werden.
  7. Möglicherweise muss ein Wartungsfenster eingeplant werden.
  8. Die Änderung muss umgesetzt und getestet werden.
  9. Die Feststellung muss mit entsprechenden Nachweisen geschlossen werden.

Wenn Informationen über das Asset, den Verantwortlichen, den Geschäftsprozess und die vorhandenen Sicherheitsmaßnahmen an verschiedenen Orten gespeichert sind, wird ein großer Teil der verfügbaren Reaktionszeit für die Suche nach Informationen und die Kontaktaufnahme mit den richtigen Personen verwendet.

Die technische Arbeit kann nur wenige Stunden dauern. Der gesamte Prozess kann dennoch mehrere Wochen in Anspruch nehmen.

Dies ist einer der Gründe, warum Sicherheitsteams Fristen überschreiten, obwohl sie kontinuierlich an der Bearbeitung arbeiten. Die Verzögerung entsteht nicht immer während der technischen Behebung. Häufig entsteht sie, bevor überhaupt jemand eine klare Entscheidung treffen kann.

Manuelles Reporting verdeckt das eigentliche Problem

Getrennte Umgebungen sind in der Regel stark von Tabellen und manuell erstellten Berichten abhängig.

Tabellen sind nützlich und flexibel. Sie lassen sich jedoch nur schwer pflegen, wenn mehrere Teams unterschiedliche Bezeichnungen, Kategorien und Berichtszeitpunkte verwenden. Dieselbe Anwendung kann unter mehreren Namen erscheinen. Eine bereits geschlossene Schwachstelle kann in einem Managementbericht weiterhin als offen angezeigt werden. Eine Risikobewertung kann aktualisiert werden, ohne dass der zugehörige Risikobehandlungsplan entsprechend angepasst wird.

Die Erstellung eines Berichts wird dadurch zu einer aufwendigen Aufgabe, bei der Informationen gesammelt, verglichen und korrigiert werden müssen.

Dies führt zu zwei wesentlichen Risiken.

Erstens verbringen Sicherheitsspezialisten ihre Zeit mit der Vorbereitung von Berichten, anstatt Risiken zu reduzieren. Zweitens erhält das Management ein Dokument, das nur den Stand zu einem bestimmten Berichtszeitpunkt darstellt, anstatt einen aktuellen Überblick über die Sicherheitslage zu bekommen.

Auch ein sorgfältig gestalteter Bericht kann irreführend sein, wenn die zugrunde liegenden Daten unvollständig oder veraltet sind.

Dashboards schaffen nicht automatisch Integration

Unternehmen versuchen manchmal, das Problem durch die Einführung eines Dashboards zu lösen.

Ein Dashboard kann Informationen übersichtlicher darstellen. Es korrigiert jedoch keine unzureichenden Beziehungen zwischen den zugrunde liegenden Daten. Wenn die Asset-Verantwortung nicht definiert ist, kann ein Dashboard nicht zuverlässig anzeigen, wer verantwortlich ist. Wenn Systeme unterschiedliche Namen für dasselbe Asset verwenden, kann das Dashboard ein System mehrfach zählen. Wenn die geschäftliche Kritikalität nicht festgelegt wurde, kann das Dashboard diesen Kontext nicht eigenständig erzeugen.

Das Ziel sollte nicht darin bestehen, mehr Diagramme auf einem Bildschirm darzustellen. Stattdessen sollten zuverlässige Verbindungen zwischen folgenden Elementen geschaffen werden:

  • Geschäftsprozessen,
  • Informationen,
  • Anwendungen,
  • Infrastruktur,
  • Identitäten,
  • Lieferanten,
  • Schwachstellen,
  • Bedrohungen,
  • Sicherheitsmaßnahmen,
  • Risiken,
  • Sicherheitsvorfällen,
  • Auditfeststellungen,
  • Maßnahmen,
  • Verantwortlichen,
  • Nachweisen.

Die Qualität einer Entscheidung hängt von der Qualität dieser Beziehungen ab.

Wie ein verbundenes Cybersecurity-Modell aussieht

Ein verbundenes Cybersecurity-Modell erfordert nicht, dass alle bestehenden Tools ersetzt werden.

Spezialisierte Tools können weiterhin ihre vorgesehenen Aufgaben erfüllen. Schwachstellenscanner können technische Sicherheitslücken erkennen. Endpoint-Systeme können verdächtige Aktivitäten identifizieren. Identitätsplattformen können Zugriffsrechte verwalten. Service-Management-Tools können operative Aufgaben koordinieren.

Die wesentliche Veränderung besteht darin, eine gemeinsame Struktur zu schaffen, welche die von diesen Tools erzeugten Informationen miteinander verbindet.

Betrachten wir eine Schwachstelle in einer extern erreichbaren Anwendung. In einem verbundenen Modell sollte das Sicherheitsteam folgende Informationen einsehen können:

  • das betroffene technische Asset,
  • die darauf betriebene Anwendung,
  • den von der Anwendung unterstützten Geschäftsservice,
  • die Klassifizierung der verarbeiteten Informationen,
  • die technischen und fachlichen Verantwortlichen,
  • die damit verbundenen Lieferanten,
  • vorhandene Sicherheitsmaßnahmen,
  • bekannte Sicherheitsvorfälle oder frühere Feststellungen,
  • die geltende Behebungsfrist,
  • die aktuelle Risikobehandlungsmaßnahme und deren Frist.

Dadurch kann das Unternehmen das Problem anhand seiner tatsächlichen Umstände bewerten, anstatt sich auf eine einzelne Kennzahl zu verlassen.

Verantwortung muss der Entscheidung folgen

Die Verbindung von Systemen allein reicht nicht aus. Auch der Entscheidungsprozess muss eindeutig definiert sein.

Verschiedene Personen können für unterschiedliche Teile desselben Problems verantwortlich sein:

  • Ein Sicherheitsanalyst überprüft die Feststellung.
  • Ein Systemadministrator definiert die technische Lösung.
  • Ein Anwendungsverantwortlicher bewertet die möglichen Auswirkungen auf den Service.
  • Ein Geschäftsprozessverantwortlicher beurteilt die betrieblichen Folgen.
  • Ein Risikoverantwortlicher akzeptiert oder lehnt das verbleibende Risiko ab.
  • Das Management genehmigt Ausnahmen, die oberhalb des akzeptierten Risikoniveaus liegen.

Diese Rollen dürfen nicht miteinander verwechselt werden.

Die Person, der ein technisches Ticket zugewiesen wurde, ist nicht automatisch dazu berechtigt, ein Geschäftsrisiko zu akzeptieren. Ein Sicherheitsteam kann eine Maßnahme empfehlen. Es sollte jedoch kein betriebliches Risiko im Namen einer anderen Abteilung akzeptieren.

Ein verbundener Prozess sollte sowohl den für die Umsetzung zuständigen Bearbeiter als auch den rechenschaftspflichtigen Entscheidungsträger anzeigen.

Wie Unternehmen ihre Umgebung schrittweise verbinden können

Der erste Schritt sollte nicht der Kauf einer weiteren Plattform sein. Zunächst sollte untersucht werden, wie Entscheidungen gegenwärtig getroffen werden.

Eine praktische Überprüfung kann mit folgenden Fragen beginnen:

  • Welche Informationen werden für eine Cybersecurity-Entscheidung benötigt?
  • Wo werden diese Informationen gespeichert?
  • Wer pflegt sie?
  • Wie wird ein Asset mit einem Geschäftsprozess verknüpft?
  • Wie werden technische Feststellungen mit Risiken verbunden?
  • Wer entscheidet, ob eine Behebungsmaßnahme verschoben werden darf?
  • Wie werden überfällige Maßnahmen eskaliert?
  • Welche Nachweise werden benötigt, bevor ein Problem geschlossen werden kann?
  • Welche Berichte werden manuell erstellt?
  • Welche Daten werden wiederholt zwischen Systemen übertragen?

Die Antworten zeigen, an welchen Stellen der Entscheidungsprozess unterbrochen ist.

Anschließend kann das Unternehmen eine gemeinsame Sprache für Assets, Risiken, Sicherheitsmaßnahmen, Aktivitäten und Verantwortlichkeiten definieren. Es kann festlegen, welche Mindestinformationen für wichtige Entscheidungen erforderlich sind, und Regeln für die Aktualisierung dieser Informationen einführen.

Die Integration sollte sich am Entscheidungsbedarf orientieren und nicht umgekehrt.

Bessere Verbindungen ermöglichen bessere Investitionsentscheidungen

Getrennte Systeme erschweren es außerdem, zu bestimmen, in welchen Bereichen Sicherheitsinvestitionen den größten Nutzen schaffen.

Eine Abteilung kann ein weiteres Sicherheitstool verlangen, weil sie eine hohe Anzahl an Warnmeldungen sieht. Eine andere Abteilung kann zusätzliches Personal anfordern, weil die Bearbeitung von Sicherheitsproblemen zu lange dauert. Das Management kann beiden Anträgen zustimmen, ohne zu erkennen, dass das eigentliche Problem in unzureichenden Asset-Informationen, unklaren Verantwortlichkeiten oder doppelten Prozessen liegt.

Eine verbundene Übersicht kann zeigen, ob dem Unternehmen tatsächlich eine Sicherheitsfunktion fehlt oder ob eine vorhandene Fähigkeit ineffizient eingesetzt wird.

Sie kann außerdem sichtbar machen, an welchen Stellen mehrere Sicherheitsmaßnahmen dasselbe Risiko behandeln, während ein anderes wichtiges Risiko nur unzureichend berücksichtigt wird.

Dies bedeutet nicht, dass jede Entscheidung einfach wird. Es bedeutet, dass Entscheidungen auf transparenten Beziehungen und aktuellen Nachweisen statt auf Annahmen beruhen.

Das Ziel sind nicht perfekte Daten

Unternehmen verschieben die Integration manchmal, weil ihre Daten unvollständig sind.

Perfekte Daten sind jedoch kein realistischer Ausgangspunkt. Asset-Inventare verändern sich. Mitarbeitende wechseln ihre Rollen. Lieferanten führen neue Services ein. Anwendungen werden ersetzt. Risiken entwickeln sich weiter.

Das praktische Ziel besteht darin, festzustellen, welche Informationen für wichtige Entscheidungen erforderlich sind, und diese Informationen schrittweise zu verbessern.

Ein verbundenes Modell kann auch fehlende Informationen sichtbar machen. Wenn eine kritische Anwendung keinen fachlichen Verantwortlichen hat, wird diese fehlende Beziehung erkennbar. Wenn für eine Sicherheitsmaßnahme keine aktuellen Nachweise vorliegen, kann ihr Status hinterfragt werden. Wenn ein Lieferant einen kritischen Service unterstützt, aber noch nicht bewertet wurde, kann diese Lücke einer verantwortlichen Person zugewiesen und nachverfolgt werden.

Unvollständige Informationen werden beherrschbar, sobald das Unternehmen erkennen kann, an welchen Stellen Informationen fehlen.

Von getrennten Tools zu verbundener Verantwortlichkeit

Der größte Nutzen einer Verbindung von Cybersecurity-Informationen ist nicht technischer, sondern organisatorischer Natur.

Teams verstehen, warum ein Problem relevant ist. Verantwortliche wissen, welche Entscheidungen von ihnen erwartet werden. Das Management erkennt, welche Risiken Aufmerksamkeit erfordern. Technische Spezialisten erhalten Prioritäten, die die geschäftliche Bedeutung widerspiegeln. Auditoren können eine Anforderung bis zur entsprechenden Sicherheitsmaßnahme, der verantwortlichen Person und den unterstützenden Nachweisen zurückverfolgen.

Dadurch entwickelt sich Cybersecurity weg von voneinander getrennten Berichten und punktuellen Compliance-Aktivitäten. Sie wird zu einem Bestandteil des täglichen operativen und geschäftlichen Managements.

Das verborgene Cybersecurity-Risiko besteht nicht nur darin, dass Systeme keine Daten austauschen. Es besteht darin, dass fragmentierte Informationen zu fragmentierter Verantwortung, langsamen Entscheidungen und unwirksamen Maßnahmen führen.

Die Verbindung von Systemen ist deshalb nur der Anfang. Das eigentliche Ziel besteht darin, Informationen mit Kontext, Kontext mit Verantwortung und Verantwortung mit konkreten Maßnahmen zu verbinden.