Auf einen Blick
In einem europäischen Unternehmen waren Cybersecurity-Informationen auf verschiedene Teams, Systeme, Berichte und Tabellen verteilt.
Die IT-Abteilung verwaltete technische Asset-Daten. Das Sicherheitsteam arbeitete mit Schwachstellen, Warnungen und Sicherheitsvorfällen. Die Risiko- und Compliance-Teams betreuten Risiken, Kontrollen und Auditfeststellungen. Der Einkauf verwaltete Informationen über Lieferanten. Das Business-Continuity-Team dokumentierte kritische Geschäftsprozesse und Wiederherstellungsanforderungen.
Jedes Team verfügte über wertvolle Informationen. Trotzdem arbeiteten die Beteiligten nicht immer mit demselben Gesamtbild.
Dasselbe System konnte in verschiedenen Anwendungen unter unterschiedlichen Namen erscheinen. Eine Schwachstelle war möglicherweise mit einem Server verknüpft, aber nicht mit dem Geschäftsdienst, den dieser Server unterstützte. Ein Lieferant war im Vertragsregister erfasst, ohne dass sichtbar war, auf welche Systeme oder Daten er zugreifen konnte. Eine Sicherheitskontrolle war in einer Richtlinie beschrieben, ohne dass eindeutig dokumentiert war, wo sie galt und ob sie tatsächlich funktionierte.
Dadurch ließen sich einige grundlegende Fragen nur schwer beantworten:
- ?Welche Assets unterstützen die wichtigsten Geschäftsprozesse?
- ?Welche Schwachstellen stellen das größte betriebliche Risiko dar?
- ?Welche Lieferanten haben Zugang zu kritischen Systemen oder sensiblen Informationen?
- ?Welche Sicherheitskontrollen gelten für ein bestimmtes Risiko?
- ?Funktionieren diese Kontrollen wie vorgesehen?
- ?Wer ist für die einzelnen Assets, Risiken, Kontrollen und Maßnahmen verantwortlich?
- ?Welche weiteren Bereiche könnten betroffen sein, wenn ein System, ein Lieferant oder eine Kontrolle ausfällt?
Wir unterstützten den Kunden dabei, die bereits vorhandenen Informationen miteinander zu verbinden und in einem gemeinsamen Cybersecurity-Modell abzubilden.
Dadurch konnte das Unternehmen seine Cybersecurity-Umgebung als ein Netz zusammenhängender Beziehungen betrachten, statt mit vielen voneinander getrennten Listen zu arbeiten. Die verschiedenen Teams konnten erkennen, wie Geschäftsprozesse, Daten, Anwendungen, Infrastruktur, Lieferanten, Schwachstellen, Kontrollen, Risiken und Maßnahmen zusammenhingen.
Über den Kunden
Der Name des Kunden, die genaue Anzahl der Mitarbeitenden, die Standorte und ausgewählte operative Informationen wurden aus Vertraulichkeitsgründen nicht angegeben.
Die Herausforderung
Dem Unternehmen fehlten nicht die Cybersecurity-Informationen. Das eigentliche Problem bestand darin, dass diese Informationen für unterschiedliche Zwecke erstellt und von verschiedenen Teams gepflegt wurden.
Technische Inventare enthielten Angaben zu Servern, Endgeräten und Anwendungen. Schwachstellenscanner dokumentierten technische Sicherheitslücken. Das Risikoregister enthielt geschäftliche Risiken und Informationssicherheitsrisiken. In Auditunterlagen wurden Feststellungen und Nachweise geführt. Die Einkaufssysteme enthielten Informationen zu Lieferanten und Verträgen.
Diese Quellen verwendeten jedoch selten dieselbe Struktur.
Ein Geschäftsdienst konnte von einer Anwendung, mehreren Servern, einer Cloud-Plattform und einem externen Dienstleister abhängig sein. Diese Zusammenhänge waren aber nicht an einer zentralen Stelle sichtbar.
Wenn eine neue Schwachstelle entdeckt wurde, musste das Sicherheitsteam mehrere Personen kontaktieren, um ihre Bedeutung zu verstehen. Wenn ein Auditor Nachweise anforderte, musste das Compliance-Team Dokumente bei unterschiedlichen Verantwortlichen zusammensuchen. Änderte ein Lieferant seinen Dienst, ließ sich nur schwer feststellen, welche Geschäftsprozesse, Systeme und Kontrollen davon betroffen waren.
Berichte wurden meist erstellt, indem Informationen aus verschiedenen Systemen exportiert und manuell zusammengeführt wurden. Bis ein Bericht fertiggestellt war, konnten sich einzelne Informationen bereits wieder geändert haben.
Cybersecurity-Informationen waren vorhanden – aber fragmentiert und unverbunden.
Die Herausforderung bestand nicht in einem Mangel an Daten, sondern in der Unfähigkeit zu erkennen, wie verschiedene Informationsfragmente zusammenhingen, um eine effektive Entscheidungsfindung zu unterstützen.
Der Kunde wollte ein gemeinsames Bild schaffen, ohne alle vorhandenen Sicherheits- und Geschäftssysteme ersetzen zu müssen.
Was der Kunde erreichen wollte
Das Projekt hatte sieben Hauptziele:
Eine gemeinsame Struktur für die wichtigsten Cybersecurity-Informationen entwickeln.
Technische Assets mit Geschäftsprozessen und möglichen betrieblichen Auswirkungen verbinden.
Die Beziehungen zwischen Risiken, Schwachstellen, Kontrollen und Maßnahmen sichtbar machen.
Abhängigkeiten von Lieferanten und anderen Dritten verständlicher darstellen.
Verantwortliche Personen für wichtige Informationen und Entscheidungen festlegen.
Doppelte Datensätze und manuelle Berichtsarbeiten reduzieren.
Sicherstellen, dass sich das Cybersecurity-Modell mit dem Unternehmen und seiner Technologieumgebung weiterentwickeln konnte.
Was wir getan haben
Wir begannen mit den Entscheidungen, die getroffen werden mussten
Unser Ziel bestand nicht darin, möglichst viele Daten zu sammeln. Zuerst ermittelten wir, welche Fragen die Sicherheits-, IT-, Risiko- und Compliance-Teams sowie das Management beantworten mussten.
Wir führten Workshops mit Vertretern aus folgenden Bereichen durch:
- ✓IT und Infrastruktur;
- ✓Informationssicherheit;
- ✓Risiko und Compliance;
- ✓Datenschutz;
- ✓Einkauf und Lieferantenmanagement;
- ✓Business Continuity;
- ✓ausgewählte Fachabteilungen.
Jedes Team erklärte, welche Informationen es verwaltete, woher diese Informationen stammten und wofür sie verwendet wurden.
Dadurch konnten wir zwischen entscheidungsrelevanten Informationen und Daten unterscheiden, die zwar verfügbar waren, aber keinen klaren Zweck erfüllten. Gleichzeitig wurden doppelte Arbeiten und Abhängigkeiten von Datensätzen anderer Teams sichtbar.
Wir entwickelten ein gemeinsames Cybersecurity-Modell
Wir erstellten eine gemeinsame Struktur für die wichtigsten Cybersecurity-Informationen des Unternehmens.
Das Modell verband:
- ✓Geschäftsprozesse;
- ✓Geschäftsdienste;
- ✓Abteilungen und Standorte;
- ✓Informationen und Daten;
- ✓Anwendungen;
- ✓Server, Endgeräte und Netzwerkkomponenten;
- ✓Identitäten und privilegierte Konten;
- ✓Cloud-Dienste;
- ✓Lieferanten und externe Dienstleistungen;
- ✓Bedrohungen und Schwachstellen;
- ✓Cybersecurity-Risiken;
- ✓Sicherheitskontrollen;
- ✓Richtlinien und Verfahren;
- ✓Sicherheitsvorfälle und Auditfeststellungen;
- ✓Risikobehandlungs- und Verbesserungsmaßnahmen;
- ✓verantwortliche Personen;
- ✓Nachweise und Prüftermine.
Das Modell führte diese Informationen nicht nur an einer Stelle zusammen. Es machte auch ihre Beziehungen sichtbar.
Wir vereinbarten gemeinsame Namen, Verantwortlichkeiten und verlässliche Datenquellen
Ein praktisches Problem bestand darin, dass unterschiedliche Systeme verschiedene Namen für dasselbe Asset verwendeten.
Wir führten einen abgestimmten Identifikator für wichtige Assets ein und dokumentierten alternative Namen, die in technischen Tools, Geschäftsunterlagen und Lieferantendaten verwendet wurden.
Für jede wichtige Informationsart legten wir außerdem fest:
- ✓welche Quelle als maßgebliche Referenz galt;
- ✓welches Team für die Pflege verantwortlich war;
- ✓wie häufig die Information überprüft werden sollte;
- ✓wie Widersprüche zwischen verschiedenen Quellen zu lösen waren;
- ✓welche Änderungen eine Freigabe erforderten;
- ✓wie mit fehlenden Pflichtinformationen umzugehen war.
Dadurch wurden nicht sofort alle Unterschiede beseitigt. Die Teams erhielten jedoch eine einheitliche Methode, um Widersprüche zu klären und die Datenqualität schrittweise zu verbessern.
Wir verbanden technische Feststellungen mit ihren geschäftlichen Auswirkungen
Schwachstellen, Sicherheitsvorfälle und Warnungen wurden erheblich nützlicher, sobald sie in einen geschäftlichen Zusammenhang gestellt werden konnten.
Eine Schwachstelle konnte nun verbunden werden mit:
- ✓dem betroffenen technischen Asset;
- ✓der auf dem Asset betriebenen Anwendung;
- ✓dem von der Anwendung unterstützten Geschäftsdienst;
- ✓den verarbeiteten Informationen;
- ✓dem zuständigen Lieferanten;
- ✓vorhandenen Sicherheitskontrollen;
- ✓dem zugehörigen Cyberrisiko;
- ✓der für die Behebung verantwortlichen Person.
Das Sicherheitsteam konnte dadurch erkennen, ob ein technisches Problem Auswirkungen auf die Produktion, den Kundenservice, finanzielle Abläufe, Mitarbeitende oder sensible Informationen haben konnte. Auch Geschäftsverantwortliche konnten besser nachvollziehen, warum ein Sicherheitsproblem ihre Aufmerksamkeit erforderte.
Wir sorgten dafür, dass das Modell auf Veränderungen reagieren konnte
Ein statisches Register verliert schnell an Wert, wenn sich Systeme, Lieferanten und Geschäftsprozesse verändern.
Deshalb definierten wir Ereignisse, die eine Überprüfung der verbundenen Informationen auslösen sollten. Dazu gehörten:
- ✓Einführung einer neuen Anwendung oder eines neuen Cloud-Dienstes;
- ✓wesentliche Änderung an einem System;
- ✓Wechsel eines Lieferanten;
- ✓neu entdeckte Schwachstelle;
- ✓Sicherheitsvorfall;
- ✓Ausfall oder mangelnde Wirksamkeit einer Kontrolle;
- ✓Änderung eines kritischen Geschäftsprozesses;
- ✓neue gesetzliche, vertragliche oder kundenspezifische Anforderung;
- ✓überfällige Risikobehandlungsmaßnahme.
Trat eines dieser Ereignisse ein, konnten die damit verbundenen Informationen gemeinsam überprüft werden. Die Änderung wurde nicht länger als isolierte Aktualisierung behandelt. Ein Lieferantenwechsel konnte beispielsweise eine Überprüfung des betroffenen Dienstes, des Datenzugriffs, der Verträge, der Sicherheitskontrollen, der Kontinuitätsmaßnahmen und der verbundenen Risiken auslösen.
Wir setzten Automatisierung dort ein, wo sie wiederkehrende Arbeit reduzierte
Automatisierung wurde gezielt eingesetzt. Sie sollte manuelle Arbeit reduzieren, ohne Verantwortung oder menschliche Kontrolle zu beseitigen.
Geeignete Anwendungsbereiche waren:
- ✓Import aktualisierter Informationen über technische Assets;
- ✓Zuordnung von Scanner-Feststellungen zu bekannten Assets;
- ✓Benachrichtigung verantwortlicher Personen über neue oder überfällige Maßnahmen;
- ✓Kennzeichnung von Datensätzen ohne benannte Verantwortliche;
- ✓Erkennung von Kontrollen mit veralteten Nachweisen;
- ✓Kennzeichnung abgelaufener Risikoausnahmen;
- ✓Vorbereitung konsistenter Informationen für regelmäßige Berichte.
Die Automatisierung unterstützte den Prozess, traf aber keine Risikoentscheidungen für das Unternehmen. Geschäftsverantwortliche blieben für die Bewertung der Auswirkungen zuständig. Kontrollverantwortliche mussten weiterhin bestätigen, ob eine Kontrolle wirksam war. Risikoverantwortliche entschieden weiterhin über die Behandlung oder Akzeptanz eines Risikos.
Wir klärten die Verantwortlichkeiten zwischen den Teams
Ein gemeinsames Modell funktioniert nur, wenn klar geregelt ist, wer welche Informationen pflegt.
Wir legten Verantwortlichkeiten fest für:
- ✓Geschäftsprozesse und Geschäftsdienste;
- ✓Anwendungen und Infrastruktur;
- ✓Informationswerte;
- ✓Lieferanten und Verträge;
- ✓Cybersecurity-Risiken;
- ✓Sicherheitskontrollen und Nachweise;
- ✓Behebung von Schwachstellen;
- ✓Audit- und Verbesserungsmaßnahmen;
- ✓Prüfung und Behebung von Datenqualitätsproblemen.
Die Teams mussten keine Informationen außerhalb ihres Zuständigkeitsbereichs pflegen. Sie mussten jedoch verstehen, wie andere Bereiche ihre Informationen verwendeten und welche Änderungen weitergegeben werden mussten.
Wir verbesserten Berichte und Auswirkungsanalysen
Durch das verbundene Modell konnte das Unternehmen Berichte auf Grundlage bestehender Beziehungen erstellen. Separate Exporte mussten nicht mehr jedes Mal manuell zusammengeführt werden.
Die Managementberichte konzentrierten sich auf:
- ✓kritische Dienste mit ungelösten Risiken;
- ✓wichtige Assets ohne eindeutig benannte Verantwortliche;
- ✓priorisierte Schwachstellen mit Auswirkungen auf kritische Abläufe;
- ✓fehlende, unwirksame oder nicht ausreichend dokumentierte Kontrollen;
- ✓Lieferantenabhängigkeiten bei wichtigen Diensten;
- ✓überfällige Maßnahmen und abgelaufene Ausnahmen;
- ✓Sicherheitsvorfälle mit Auswirkungen auf verbundene Systeme oder Prozesse;
- ✓Entscheidungen, die vom Management getroffen werden mussten.
Das Modell unterstützte außerdem die Analyse möglicher Auswirkungen. Meldete ein kritischer Lieferant ein Problem, konnte das Unternehmen feststellen, welche Dienste, Systeme, Informationen, Kontrollen und Geschäftsverantwortlichen möglicherweise betroffen waren. Die Teams konnten so mit einer gemeinsamen Informationsgrundlage reagieren, anstatt für jedes neue Problem eine weitere Tabelle zu erstellen.
Was wir geliefert haben
Der Kunde erhielt:
- ✓ein einheitliches Modell für wichtige Cybersecurity-Informationen;
- ✓eine gemeinsame Struktur für geschäftliche, technische und sicherheitsbezogene Datensätze;
- ✓Verbindungen zwischen Prozessen, Daten, Anwendungen, Infrastruktur und Lieferanten;
- ✓Beziehungen zwischen Schwachstellen, Risiken, Kontrollen und Maßnahmen;
- ✓vereinbarte Verantwortlichkeiten für Pflege und Aktualisierung;
- ✓Regeln für den Umgang mit doppelten oder widersprüchlichen Datensätzen;
- ✓Prüfauslöser für wichtige Veränderungen;
- ✓ausgewählte automatisierte Aktualisierungen, Benachrichtigungen und Kontrollen;
- ✓Vorlagen für Managementberichte;
- ✓einen praktischen Prozess zur laufenden Aktualisierung des Modells.
Das Unternehmen musste nicht alle vorhandenen Tools ersetzen. Das Projekt schuf eine gemeinsame Struktur, durch die Informationen aus diesen Systemen leichter verbunden, verstanden und genutzt werden konnten.
Die Ergebnisse
Innerhalb von neun Monaten erzielte der Kunde folgende Ergebnisse:
Der Kunde etablierte eine gemeinsame Struktur, die es den Bereichen IT, Informationssicherheit, Risikomanagement, Compliance, Einkauf und Business Continuity ermöglichte, mit einer einheitlicheren Sicht auf die Cybersecurity-Umgebung zu arbeiten.
Kritische Business Services wurden mit den Anwendungen, der Infrastruktur, den Informationen, den Lieferanten und den Sicherheitskontrollen verknüpft, von denen sie abhängig waren. Dadurch erhielten technische Feststellungen einen klareren Business-Kontext. Das Unternehmen konnte Schwachstellen auf Grundlage ihrer möglichen betrieblichen Auswirkungen priorisieren, anstatt ausschließlich deren technischen Schweregrad zu berücksichtigen.
Die Einführung gemeinsamer Identifikatoren und vereinbarter Referenzquellen reduzierte Inkonsistenzen zwischen technischen Inventaren, Risikoregistern, Lieferantenunterlagen und Auditdokumentationen. Für wichtige Datensätze wurden verantwortliche Owner, festgelegte Überprüfungstermine und klare Pflegeverantwortlichkeiten definiert.
Auch die Abhängigkeiten von Lieferanten wurden transparenter. Wenn ein Lieferant einen Sicherheitsvorfall, eine Änderung seines Services oder das Versagen einer Kontrolle meldete, konnte das Unternehmen die möglicherweise betroffenen Systeme, Informationen, Business Services, vertraglichen Verpflichtungen und Business-Continuity-Vorkehrungen schneller identifizieren.
Durch ausgewählte Automatisierungen konnten wiederkehrende Tätigkeiten reduziert werden, darunter der Import aktualisierter Informationen zu technischen Assets, die Zuordnung von Schwachstellen zu bekannten Assets, die Benachrichtigung der Verantwortlichen über neue und überfällige Maßnahmen, die Identifikation von Datensätzen ohne zugewiesenen Owner, die Kennzeichnung veralteter Kontrollnachweise, die Kennzeichnung abgelaufener Risikoausnahmen und die Vorbereitung konsistenter Informationen für Managementberichte.
Die Automatisierung unterstützte die Prozesse, ohne die menschliche Verantwortung zu ersetzen. Die Business Owner blieben für die Bewertung der betrieblichen Auswirkungen verantwortlich. Die Control Owner bestätigten weiterhin die Wirksamkeit der Kontrollen. Die Risk Owner entschieden weiterhin darüber, wie mit identifizierten Risiken umgegangen werden sollte.
Das wichtigste Ergebnis bestand darin, dass die Teams dieselben Beziehungen nicht mehr bei jeder Untersuchung eines Sicherheitsvorfalls, Bewertung einer Schwachstelle, Überprüfung eines Lieferanten oder Vorbereitung eines Managementberichts manuell rekonstruieren mussten. Das einheitliche Modell erleichterte es, zu verstehen, wie sich eine Änderung oder ein Cybersecurity-Problem in einem Bereich auf die gesamte Organisation auswirken konnte.
Was sich für den Kunden verändert hat
Was wir gelernt haben
Kundenstimme
„Die meisten benötigten Informationen waren bereits vorhanden. Sie wurden jedoch von verschiedenen Teams verwaltet und unterschiedlich dokumentiert. Das gemeinsame Modell half uns zu verstehen, wie unsere Systeme, Lieferanten, Risiken und Kontrollen miteinander verbunden waren. Unsere Teams können nun mit denselben Informationen arbeiten und die weitergehenden Auswirkungen einer Änderung oder eines Sicherheitsproblems besser erkennen."
Das folgende Zitat darf nur nach ausdrücklicher Freigabe durch den Kunden verwendet werden. Wenn kein freigegebenes Kundenzitat vorliegt, sollte dieser Abschnitt entfernt werden.
Fazit
Der Kunde benötigte keine weitere unabhängige Cybersecurity-Datenbank. Er brauchte eine klarere Möglichkeit, die bereits vorhandenen Informationen miteinander zu verbinden und sinnvoll zu nutzen.
Die einzelnen Teams verfügten über wertvolle Datensätze. Die Beziehungen zwischen diesen Datensätzen waren jedoch unvollständig. Deshalb war es schwierig, Abhängigkeiten zu verstehen, geschäftliche Auswirkungen einzuschätzen und Berichte aktuell zu halten.
Mit einem einheitlichen Cybersecurity-Modell verband das Unternehmen Geschäftsprozesse, Daten, Anwendungen, Infrastruktur, Lieferanten, Schwachstellen, Kontrollen, Risiken und verantwortliche Personen.
Technische Feststellungen erhielten einen geschäftlichen Kontext. Abhängigkeiten von Lieferanten wurden sichtbar. Veränderungen konnten eine Überprüfung der verbundenen Risiken und Kontrollen auslösen. Regelmäßige Prüfungen und Berichte erforderten weniger manuelle Arbeit.
Vor allem konnten verschiedene Teams ihre Entscheidungen auf dasselbe grundlegende Bild der Cybersecurity-Umgebung stützen.
Stehen Sie vor einer ähnlichen Herausforderung?
Cybersecurity-Informationen sind häufig über technische Tools, Risikoregister, Lieferantenunterlagen, Auditberichte, Richtlinien und Tabellen verteilt.
Cybersecurity Analytics kann Sie dabei unterstützen:
- ✓Cybersecurity-Informationen aus verschiedenen Teams miteinander zu verbinden;
- ✓technische Assets mit Geschäftsprozessen und Diensten zu verknüpfen;
- ✓Zusammenhänge zwischen Risiken, Schwachstellen und Kontrollen sichtbar zu machen;
- ✓Abhängigkeiten von Lieferanten verständlicher darzustellen;
- ✓klare Verantwortlichkeiten für wichtige Informationen und Maßnahmen festzulegen;
- ✓sinnvolle Automatisierung einzuführen, ohne die menschliche Kontrolle zu beseitigen;
- ✓verständlichere Berichte für das Management vorzubereiten.
Verbinden Sie Ihre Cybersecurity-Informationen für bessere Entscheidungen.
Kontaktieren Sie uns, um zu besprechen, wie ein einheitliches Cybersecurity-Modell Ihr Unternehmen unterstützen kann.
Cybersecurity-Informationen aus verschiedenen Teams und Tools miteinander verbinden.
Technische Assets mit Geschäftsprozessen, Lieferanten und Diensten verknüpfen.
Sinnvolle Automatisierung einführen, ohne die menschliche Kontrolle zu beseitigen.
Verständlichere, beziehungsorientierte Berichte für das Management vorbereiten.
