Öffnet in einem neuen Tab
Cybersecurity wird zur Führungskennzahl

Warum Security BI die Sprache der Geschäftsleitung spricht

Ein Sicherheitsbericht kann hervorragend aussehen, während das Unternehmen vor einem erheblichen Ausfallrisiko steht.

Warum Security BI die Sprache der Geschäftsleitung spricht

Wer Cybersecurity steuern will, muss wissen, ob die Schutzmaßnahmen dort wirken, wo ein Angriff das Geschäft zum Stillstand bringen würde. Security BI übersetzt technische Daten in diese unternehmerische Entscheidungsgrundlage. Vorausgesetzt, Unternehmen messen das Richtige.

Ihre Firewall hat Tausende Angriffe blockiert. Der Endpoint-Schutz ist auf nahezu allen Geräten installiert. Das Security Operations Center meldet, dass die meisten Vorfälle abgearbeitet sind. Im Monatsbericht stehen grüne Ampeln.

Können Sie deshalb morgen noch Aufträge annehmen, produzieren und Rechnungen stellen, wenn heute ein Angreifer ein privilegiertes Konto übernimmt?

Wenn sich diese Frage mit Ihren Sicherheitskennzahlen nicht beantworten lässt, messen Sie am Geschäft vorbei.

Die Geschäftsleitung muss beurteilen können, welche Risiken den Betrieb gefährden, ob Gegenmaßnahmen funktionieren und wo eine Entscheidung erforderlich ist. Ein Bericht, der diese Fragen offenlässt, verlagert die Bewertung auf Menschen, denen der technische Zusammenhang fehlt. So entsteht eine gefährliche Situation: Die IT berichtet ausführlich, die Führung fühlt sich informiert und das tatsächliche Betriebsrisiko bleibt ungeklärt.

Sicherheitsdaten brauchen einen geschäftlichen Zusammenhang

Cybersecurity Business Intelligence, kurz Security BI, führt Informationen aus unterschiedlichen Sicherheitswerkzeugen zusammen. Dazu gehören beispielsweise Firewalls, Endpoint-Lösungen, Schwachstellenscanner, Identitätsverwaltung und SOC-Dienste. Entscheidend ist jedoch, was anschließend mit diesen Informationen geschieht.

Eine Schwachstelle erhält ihre unternehmerische Bedeutung durch das betroffene System, dessen Erreichbarkeit und seine Rolle im Geschäft. Ein Server für eine interne Testumgebung verlangt eine andere Priorisierung als ein System, von dem Lager, Versand und Auftragsbearbeitung abhängen.

Security BI muss diese Zusammenhänge sichtbar machen. Dafür braucht es ein belastbares Bild der Systeme, ihrer Verantwortlichen und ihrer Abhängigkeiten. Fehlt diese Grundlage, werden technische Einzelmeldungen lediglich in einer gemeinsamen Oberfläche angezeigt. Die Führung weiß dann immer noch nicht, wo sie handeln muss.

Nehmen wir eine Patchquote von 98 Prozent. Die Zahl klingt beruhigend. Befindet sich unter den verbleibenden zwei Prozent aber ein ausnutzbares, erreichbares System mit Zugriff auf die zentrale Auftragsabwicklung, kann genau dort das wesentliche Risiko liegen.

Die richtige Führungsinformation lautet deshalb: Welcher Geschäftsprozess ist gefährdet? Welche Folgen hätte eine Kompromittierung? Wie wird das Risiko bis zur Behebung begrenzt? Wer übernimmt die Verantwortung und bis wann?

Anzeige

Der Unternehmenskern gibt die Kennzahlen vor

Für mich beginnt Sicherheitssteuerung mit einer klaren Frage: Was muss funktionieren, damit dieses Unternehmen operativ bleibt?

Daraus ergeben sich die schützenswerten Prozesse und ihre technischen Voraussetzungen. Oft sind das mehr Systeme, als auf den ersten Blick erkennbar ist. Eine intakte Produktionsanwendung hilft wenig, wenn die Anmeldung ausfällt. Ein verfügbares ERP-System sichert keine Lieferfähigkeit, wenn die angebundene Lagersteuerung stillsteht.

Wer diese Abhängigkeiten kennt, kann Kennzahlen entwickeln, die tatsächlich etwas über die Widerstandsfähigkeit des Unternehmens aussagen.

Schutzabdeckung kritischer Systeme: Welche Systeme, die den Betrieb tragen, verfügen nachweislich über aktive und funktionierende Schutzmaßnahmen? Die Installation einer Software reicht dafür nicht. Entscheidend ist, ob sie Daten liefert, korrekt konfiguriert ist und im vorgesehenen Szenario wirkt.

Überfällige Risiken an kritischen Prozessen: Welche relevanten Schwachstellen bestehen länger als vereinbart? Die Bewertung muss Ausnutzbarkeit, Erreichbarkeit und Geschäftsauswirkungen berücksichtigen. Eine bloße Anzahl offener Lücken schafft noch keine sinnvolle Priorität.

Zeit bis zur wirksamen Eindämmung: Wie lange dauert es bei relevanten Vorfällen oder Übungen, bis ein kompromittiertes Gerät oder Konto tatsächlich isoliert ist? Eine Meldung zu bestätigen ist etwas anderes, als einem Angreifer den weiteren Zugriff zu nehmen.

Getestete Wiederherstellungsfähigkeit: Für welche geschäftskritischen Prozesse wurde nachgewiesen, dass Wiederanlaufzeiten und tolerierbare Datenverluste eingehalten werden? Ein erfolgreiches Backup ist dafür nur eine Voraussetzung. Der Geschäftsprozess muss wieder funktionieren.

Hier treffen Cybersecurity und Business Continuity zusammen. Die Führung kann erkennen, ob Angriffe rechtzeitig begrenzt werden und welche Fähigkeiten bestehen, falls die Abwehr dennoch überwunden wird.

Eine grüne Ampel muss sich erklären lassen

Ein Gesamtwert kann Orientierung geben. Er darf kritische Einzelrisiken aber nicht verschwinden lassen.

Wenn Hunderte gut geschützte Bürogeräte einen unzureichend geschützten zentralen Server rechnerisch ausgleichen, sieht das Ergebnis besser aus als die Sicherheitslage. Die Konsequenzen eines Ausfalls lassen sich nicht durch die Anzahl unkritischer Systeme relativieren.

Deshalb muss jedes Managementdashboard zeigen, welche Risiken unabhängig vom Gesamtscore eine Entscheidung verlangen. Ebenso sichtbar gehören die Bereiche, über die keine belastbaren Informationen vorliegen.

Ein System ohne aktuelle Daten ist nicht nachweislich sicher. Sein Zustand ist unbekannt. Diese Unsicherheit gehört in den Bericht.

Auch Trends brauchen Kontext. Mehr erkannte Vorfälle können bedeuten, dass die Erkennung verbessert wurde. Weniger Meldungen können auf eine ausgefallene Datenquelle zurückgehen. Wer daraus vorschnell Erfolg oder Misserfolg ableitet, steuert in die falsche Richtung.

Zu jeder Kennzahl gehören deshalb eine nachvollziehbare Definition, ein Geltungsbereich und ein Messzeitpunkt. Änderungen an der Berechnung müssen erkennbar bleiben. Sonst diskutiert die Geschäftsleitung über Zahlen, deren Bedeutung sich zwischen zwei Berichten verändert hat.

Anzeige

Verantwortung lässt sich nicht an ein Dashboard delegieren

Für regulierte Unternehmen ist die Führungsverantwortung ausdrücklich verankert. Im Rahmen der deutschen NIS2-Umsetzung verpflichtet § 38 BSIG die Geschäftsleitungen besonders wichtiger und wichtiger Einrichtungen zur Umsetzung und Überwachung der erforderlichen Risikomanagementmaßnahmen. DORA weist dem Leitungsorgan der erfassten Finanzunternehmen die Gesamtverantwortung für das Management der IKT-Risiken zu.

Ein bestimmtes BI-Produkt wird damit nicht vorgeschrieben. Die Aufgabe bleibt jedoch klar: Die Leitung muss Risiken bewerten und die Wirksamkeit der Maßnahmen überwachen können.

Ein brauchbarer Bericht führt deshalb zu Entscheidungen. Er zeigt, welcher Geschäftsprozess gefährdet ist, wie sich das Risiko entwickelt, welche Maßnahme vorgesehen ist und welche Unterstützung dafür benötigt wird. Muss Budget freigegeben werden? Braucht es ein Wartungsfenster? Soll ein verbleibendes Risiko bewusst akzeptiert werden?

Auch der Nutzen von Sicherheitsinvestitionen wird so überprüfbar. Verbessert eine Maßnahme die Schutzabdeckung kritischer Systeme? Verkürzt sie die Zeit bis zur Eindämmung? Ermöglicht sie eine nachweislich schnellere Wiederherstellung?

Der Kauf einer Lösung beantwortet diese Fragen noch nicht. Ihr Einsatz muss eine überprüfbare Verbesserung bewirken.

Führung beginnt dort, wo Zahlen Konsequenzen haben

Unternehmen sollten mit ihren wichtigsten Geschäftsprozessen beginnen und wenige belastbare Kennzahlen festlegen. Jede benötigt einen Verantwortlichen, einen Zielwert und einen klaren Eskalationsweg. Im regelmäßigen Führungstermin werden Abweichungen bewertet, Maßnahmen beschlossen und Ergebnisse überprüft. Akute kritische Risiken müssen sofort eskalieren.

So wird Security BI Teil der Unternehmenssteuerung. Die IT erhält klare Prioritäten. Die Geschäftsleitung erkennt, wo Ressourcen fehlen und welche Risiken sie verantwortet. Aufsichtsgremien und Auditoren können nachvollziehen, auf welcher Grundlage entschieden wurde.

Für mich muss ein Sicherheitsbericht vor allem eine Frage beantworten: Wie gut können wir den Kern unseres Unternehmens schützen und auch unter Angriff operativ bleiben?

Wer diese Antwort nicht geben kann, braucht zuerst bessere Transparenz über seine tatsächlichen Risiken. Eine weitere grüne Ampel hilft ihm nicht.

Anzeige