Risikobasiertes Cyber Security Management: warum weniger Checkliste mehr Sicherheit bringt

Die meisten Security-Programme bestehen aus zwei Arten von Aktivität: aus sichtbaren wie Policies schreiben, Sensibilisierungskampagnen planen oder Zertifikate erneuern, und aus wirkungsvollen. Die Überschneidung ist kleiner, als sie sein sollte. Ein ISMS-Handbuch, das 140 Seiten umfasst und jedes ISO-Control peinlich genau dokumentiert, erzählt nichts darüber, ob die eine Legacy-Applikation mit dem unverschlüsselten Kundendatenspeicher wirklich geschützt ist. Das ist der Unterschied zwischen Compliance-getriebenem und risikobasiertem Security Management, und der Grund, warum diese Unterscheidung in Schweizer KMU und Grossunternehmen immer öfter zum entscheidenden Erfolgsfaktor wird.

Dieser Beitrag zeigt, was ein risikobasierter Ansatz konkret bedeutet, warum er Overhead reduziert statt erzeugt, und wie Sie die wirklichen Knackpunkte Ihrer Organisation sichtbar machen, ohne dafür ein weiteres Zertifikat an die Wand hängen zu müssen.

1 · Das Problem mit «wir machen alles»

Ein typisches Bild in vielen Unternehmen: Die IT-Security hat über Jahre einen Stapel Massnahmen aufgebaut, ein Firewall-Regelwerk, ein Patch-Management, ein Endgeräteschutz, ein SIEM, regelmässige Penetrationstests. Alles verteilt über mehrere Teams, dokumentiert in unterschiedlichen Tools, geprüft in unterschiedlichen Audits. Auf dem Papier sieht es beeindruckend aus. Fragt man aber: «Welches sind unsere fünf grössten Cyber-Risiken, und was tun wir konkret dagegen?», folgt meist ein langes Schweigen oder eine Aufzählung von Kontrollen, nicht von Risiken.

Der Unterschied ist zentral. Wer Kontrollen aufzählt, beschreibt was getan wird. Wer Risiken benennt, beschreibt wovor man sich eigentlich schützt. Ein Security-Programm, das primär auf Kontroll-Erfüllung ausgerichtet ist, produziert vier bekannte Nebenwirkungen:

• Overhead ohne Schutzgewinn. Pflichtschulungen für alle Mitarbeitenden sind günstig zu beschaffen und leicht zu berichten, schützen aber gegen moderne Angreifer nur noch marginal, während die Applikation in der DMZ mit dem ungepatchten Java-Framework jahrelang unangetastet bleibt.
• Scheinsicherheit durch Abdeckung. Ein ISO-Zertifikat bestätigt, dass ein ISMS funktioniert, nicht, dass die tatsächlich exponierten Systeme angemessen geschützt sind. Viele zertifizierte Unternehmen wurden trotzdem erfolgreich angegriffen, weil die Schwachstelle nicht im Scope war oder im generischen «mittleren Risiko» unterging.
• Paralyse durch Gleichgewichtung. Wenn alle 74 Annex-A-Controls nach ISO 27001 gleich wichtig behandelt werden, fehlt die Kapazität, die drei bis fünf wirklich kritischen Bereiche wirklich tief zu durchdringen.
• Entkopplung vom Geschäft. Security wird als «Compliance-Sache» gesehen, nicht als Business-Thema. Die Geschäftsleitung unterschreibt Budgets, weil ein Auditor etwas fordert, nicht weil sie versteht, warum dieses spezifische Risiko für dieses Unternehmen bedrohlich ist.

Risikobasiertes Security Management dreht diese Logik um. Nicht die Kontrolle ist der Ausgangspunkt, sondern das Risiko. Und nicht jedes Risiko wird gleich behandelt.

2 · Was risikobasiert wirklich heisst

Der Begriff «risikobasiert» wird inflationär verwendet, von Beratungsunternehmen, die einen neuen Ansatz verkaufen, bis zu Tools, die klassische Compliance-Matrizen nur anders benennen. Eine einfache Heuristik trennt Marketing von Methode:

Ein Security-Programm ist risikobasiert, wenn jede wesentliche Investitionsentscheidung, jede Massnahme, jede Priorisierung auf eine konkrete Risikobewertung zurückführbar ist, und wenn diese Bewertung regelmässig überprüft wird.

In der Praxis besteht ein risikobasierter Ansatz aus vier Elementen, die ineinandergreifen:

Erstens: ein aktuelles Risikoregister. Nicht eine Excel-Liste, die einmal jährlich für das Audit aufgefrischt wird, sondern ein lebendiges Verzeichnis, in dem Risiken identifiziert, bewertet und einem Eigentümer zugeordnet werden. Jedes Risiko hat mindestens einen Brutto-Wert (wie gross wäre es ohne Schutz), einen Residual-Wert (wie gross ist es mit den umgesetzten Massnahmen) und einen Status.

Zweitens: eine klare Verknüpfung Risiko → Schutzobjekt → Prozess. Ein Risiko schwebt nicht im luftleeren Raum. Es trifft ein konkretes Asset, einen Datenbank-Server, eine Applikation, einen Geschäftsprozess. Wer diese Verknüpfung nicht herstellen kann, kann die Auswirkung eines Vorfalls nicht abschätzen und im Ernstfall auch nicht priorisieren, was zuerst wiederhergestellt werden muss.

Drittens: Massnahmen mit Wirksamkeitsnachweis. Jede Kontrolle wird einem oder mehreren Risiken zugeordnet. Wer fragt, was eine bestimmte Massnahme bringt, bekommt eine Antwort in Form einer Brutto-zu-Residual-Reduktion. Massnahmen, die keinem nennenswerten Risiko zugeordnet sind, werden kritisch hinterfragt, und oft gestrichen oder konsolidiert.

Viertens: periodische Neubewertung. Die Bedrohungslandschaft, die Geschäftsprozesse und die technologische Basis verändern sich laufend. Ein risikobasiertes Programm definiert, wie oft welche Risiken neu bewertet werden, und wer das auslöst. Eine neue Drittanbieter-Anbindung, ein neues ERP-Modul, eine geänderte regulatorische Anforderung: alles Auslöser für eine Aktualisierung.

3 · Die Kronjuwelen identifizieren

Jedes Unternehmen hat einen Bereich, in dem ein erfolgreicher Angriff wirklich existenzbedrohend wäre, und drei Dutzend andere Bereiche, in denen ein Vorfall zwar unangenehm, aber beherrschbar wäre. Die erste Aufgabe eines risikobasierten Programms ist, diesen Unterschied benennen zu können.

In der Security-Literatur spricht man von den Kronjuwelen einer Organisation: jene Datenbestände, Systeme oder Prozesse, deren Kompromittierung oder Ausfall das Geschäft fundamental treffen würde. Die Kronjuwelen sind nicht identisch mit «allen personenbezogenen Daten» oder «allen Systemen mit Internet-Zugang». Eine Industriefirma mit 30 Jahren Entwicklungs-Know-how hat andere Kronjuwelen als ein Treuhänder mit Kundendossiers oder ein Spital mit Patientenakten.

Die Identifikation läuft entlang einer einfachen Frage, die in einem kurzen Workshop mit der Geschäftsleitung beantwortet werden kann: Was würde unsere Organisation in zwölf Monaten fundamental schädigen, wenn es heute unwiderruflich kompromittiert oder gelöscht würde? Die Antworten sind meist überraschend konkret:

• Der Source-Code des Flaggschiff-Produkts und die zugehörigen Build-Pipelines
• Die Kundendatenbank mit Vertragskonditionen, Zahlungsmitteln und Historie
• Das zentrale ERP, ohne das weder Bestellungen eingehen noch Rechnungen ausgehen
• Das M365-Tenant mit sämtlicher E-Mail-Kommunikation und OneDrive-Daten der Führungscrew
• Die CAD-Dateien der patentrelevanten Konstruktionen

Mehr als fünf bis sieben Kronjuwelen sollte eine typische KMU nicht benennen, wer eine längere Liste produziert, hat entweder eine sehr spezielle Geschäftsstruktur oder die Unterscheidung zu allen anderen Assets noch nicht gemacht. Der Wert dieser Übung liegt gerade in der Fokussierung.

Sobald die Kronjuwelen benannt sind, wird die Security-Arbeit neu sortiert: Welche Kontrollen schützen diese konkreten Assets? Welche Massnahmen würden dort die grösste Reduktion bringen? Welche Überwachung gibt es dort, und welche fehlt? Viele Unternehmen entdecken in dieser Phase, dass die teuersten Security-Investitionen an den am wenigsten kritischen Stellen gemacht wurden, während die Kronjuwelen erstaunlich dünn geschützt sind.

4 · Knackpunkte statt Checklisten

Ein Knackpunkt ist eine Stelle, an der ein einziger Vorfall mehrere kritische Prozesse gleichzeitig betrifft. In der klassischen Compliance-Sicht erscheinen Knackpunkte als eine Kontrolle unter vielen. In der risikobasierten Sicht sind sie das, worauf die Aufmerksamkeit primär liegen muss.

Typische Knackpunkte in Schweizer Unternehmen:

• Das Active Directory / Entra ID. Ein kompromittiertes Domain-Admin-Konto bedeutet in der Regel das Ende jeder isolierten Verteidigungslinie. Trotzdem behandelt das Security-Programm die Identität oft als einen Control unter vielen, statt als die zentrale Schaltstelle, die sie ist.
• Das Backup-System. Ransomware-Angriffe der letzten Jahre haben gezeigt: der Unterschied zwischen «wiederherstellbar in 4 Stunden» und «wir zahlen das Lösegeld» sitzt fast immer im Backup-Konzept, nicht im Antivirus-Produkt. Trotzdem ist das Backup in vielen ISMS ein Nebenthema.
• Die zentrale Collaboration-Plattform. M365, Google Workspace oder entsprechende Varianten sind für viele Firmen das de-facto-Arbeitsumfeld. Eine Kompromittierung dort ist praktisch eine Kompromittierung des gesamten Unternehmens, die Konfigurationssicherheit aber ist selten auf dem Niveau, das dieser Risikolage entspricht.
• Der eine Schlüssellieferant ohne Ausfallkonzept. Das Cloud-ERP eines einzigen Anbieters, die einzige Bank-Schnittstelle, der einzige Zahlungs-Provider: wo keine Alternative existiert, entsteht ein Single Point of Failure, der in keiner Firewall-Regel sichtbar wird.
• Die Legacy-Anwendung mit privilegiertem Zugriff. Fast jede gewachsene Organisation hat mindestens eine alte Applikation, die auf einem nicht mehr gepflegten Stack läuft, aber Zugriff auf produktionskritische Daten hat. Solange sie «irgendwie funktioniert», bleibt sie aussen vor, bis sie als Angriffsvektor genutzt wird.

Das Identifizieren solcher Knackpunkte ist keine Checklisten-Aufgabe, sondern eine Analyse-Aufgabe. Sie erfordert, dass jemand die Geschäftsprozesse und die technischen Abhängigkeiten verstanden hat, und dass die Organisation bereit ist, unangenehme Antworten zu hören. Eine gute Vernetzungsansicht, die Risiken, Prozesse, Assets und Lieferanten als zusammenhängenden Graph darstellt, beschleunigt diese Analyse enorm. Man sieht dann auf einen Blick, welche Knoten am meisten hängen, das sind die Knackpunkte.

5 · Priorisierung durch Brutto-Residual-Gap

Die methodisch eleganteste Art, Investitionen zu priorisieren, ist der Blick auf die Brutto-Residual-Gap: den Abstand zwischen dem Risiko ohne Schutzmassnahmen und dem Risiko mit den aktuell umgesetzten Massnahmen. Wo diese Lücke klein ist, greifen die Kontrollen bereits. Wo sie gross ist, besteht Handlungsbedarf.

Ein einfaches Beispiel. Nehmen wir drei Risiken auf einer 5×5-Skala (1 = sehr gering, 25 = katastrophal):

• Risiko A: Phishing-Angriff auf normale Mitarbeitende. Brutto 12, Residual 6. Gap = 6.
• Risiko B: Ransomware-Verschlüsselung der Kundendatenbank. Brutto 20, Residual 16. Gap = 4.
• Risiko C: Kompromittierung eines Domain-Admin-Kontos über ungepatchte RDP-Schwachstelle. Brutto 22, Residual 18. Gap = 4.

Die Compliance-Sicht würde Risiko A als «gut abgedeckt» markieren (Residual bei 6) und weitergehen. Die risikobasierte Sicht fragt: warum ist das Residual von B und C so hoch? Und noch wichtiger: wo lohnt sich die nächste Investition?

Investiert man weitere Ressourcen in Anti-Phishing, wird Risiko A vielleicht von Residual 6 auf 4 gedrückt. Ein Gewinn von 2 Punkten. Investiert man stattdessen in die Härtung des privilegierten Zugriffs, kann Risiko C von Residual 18 auf 10 fallen. Ein Gewinn von 8 Punkten, bei einem Risiko, das im Ernstfall existenzbedrohend ist.

Wer Investitionsentscheidungen konsistent auf diese Art betrachtet, kommt zu einer anderen Sicherheitsplan als wer Checklisten abarbeitet. Und die Geschäftsleitung versteht plötzlich, warum das Budget dorthin fliesst, wo es hinfliesst, weil die Argumentation nicht «ISO verlangt das» lautet, sondern «so reduzieren wir unser grösstes Residual-Risiko».

6 · Weniger Overhead, mehr Wirkung

Das Argument, ein risikobasiertes Programm sei aufwendiger als ein Compliance-getriebenes, hält der Praxis nicht stand. Das Gegenteil stimmt: der Aufwand verschiebt sich, aber er wird in Summe kleiner, und die Wirkung grösser.

Wo der Aufwand eingespart wird:

• Keine Schein-Kontrollen mehr. Massnahmen, die kein messbares Risiko adressieren, fallen bei der jährlichen Review heraus. Das reduziert den Pflege-, Berichts- und Auditaufwand für das gesamte restliche Jahr.
• Fokussiertes Sensibilisierungsprogramm. Statt generische Pflichttrainings für alle 700 Mitarbeitenden einzukaufen, läuft ein spezifisches Training für die 40 Personen mit privilegiertem Zugriff, und ein kürzeres Basis-Training für alle anderen. Gleicher Effekt, Bruchteil der Kosten.
• Wildwuchs an Anbietern reduziert. Wer die wirklichen Risiken benannt hat, kann drei Security-Produkte kaufen, die diese Risiken wirklich adressieren, statt zwölf Produkte mit überlappenden Funktionen, die einzeln nie den vollen Nutzen entfalten.
• Schlankere Audits. Ein Auditor, der ein funktionierendes Risikoregister und klare Brutto-Residual-Bewertungen vorfindet, arbeitet sich schneller durch die Prüfung als einer, der 140 Seiten Policy-Dokumentation ohne Kontext durchgehen muss.

Wo der Aufwand dazukommt:

• Initiale Identifikation und Bewertung der Risiken. Das ist nicht trivial und erfordert die Mitwirkung der Fachbereiche. Typischer Aufwand für ein mittelständisches Unternehmen: zwei bis vier Workshops über sechs bis acht Wochen, plus die laufende Pflege durch eine Teilzeit-Rolle.
• Laufende Wirksamkeitsbewertung. Statt «Kontrolle ist umgesetzt: ja/nein» wird bewertet, wie gut eine Kontrolle wirkt. Das verlangt ein bisschen mehr Denkarbeit pro Massnahme.
• Kommunikation mit der Geschäftsleitung. Die Risikosprache muss eingeführt werden, was sich aber rasch auszahlt, weil Entscheidungen transparenter und schneller getroffen werden können.

Unter dem Strich: der Gesamtaufwand sinkt, und zwar umso deutlicher, je länger das Programm läuft. Die Investition zu Beginn ist die Identifikation der Risiken und der Kronjuwelen; danach amortisiert sich das Modell jedes Jahr.

7 · Praktischer Einstieg

Wer mit einem risikobasierten Security-Programm starten will und bisher mehrheitlich compliance-orientiert gearbeitet hat, muss nicht alles umstellen. Ein gestufter Einstieg funktioniert gut:

Schritt 1: Kronjuwelen-Workshop. Ein halber Tag mit der Geschäftsleitung, idealerweise moderiert von jemandem, der die Diskussion nicht selbst fachlich belegen muss. Ziel ist eine Liste von fünf bis sieben Kronjuwelen mit klarer Begründung, warum sie kritisch sind.

Schritt 2: Risikoinventar aufsetzen. Für jedes Kronjuwel werden die drei bis fünf wichtigsten Bedrohungen identifiziert und mit Brutto- und Residual-Wert bewertet. Das ergibt die erste Version des Risikoregisters, nicht vollständig, aber aussagekräftig.

Schritt 3: Knackpunkte-Analyse. Welche gemeinsamen Infrastruktur-Komponenten (Identität, Backup, zentrale Plattformen) werden von mehreren Kronjuwelen gleichzeitig gebraucht? Diese Komponenten werden separat behandelt und priorisiert.

Schritt 4: Zuordnung der Massnahmen. Die bestehenden Kontrollen werden den identifizierten Risiken zugeordnet. Was keinem Risiko zugeordnet werden kann, wird hinterfragt. Was kein Risiko ausreichend reduziert, bekommt neue oder ergänzende Massnahmen.

Schritt 5: Quartalsweise Review. Das Risikoregister wird quartalsweise in der Geschäftsleitung besprochen, kurz, fokussiert, mit klaren Entscheidungspunkten. Neue Vorhaben (neue Applikation, neuer Lieferant, neue Regulierung) werden auf ihr Risikoprofil hin geprüft, bevor sie umgesetzt werden.

Ein Schweizer KMU schafft diese Phase typischerweise in drei bis sechs Monaten mit interner Kapazität und gelegentlicher externer Unterstützung. Am Ende steht ein Security-Programm, das nicht mehr versucht, alles gleich gut zu machen, sondern die wenigen wirklich wichtigen Bereiche wirklich gut macht, und die restlichen auf einem angemessenen Basis-Niveau hält.

Ausblick

Risikobasiertes Cyber Security Management ist kein neues Framework und kein Produkt. Es ist eine Haltung: erst verstehen, was auf dem Spiel steht, dann entscheiden, was getan wird. Diese Haltung hat praktische Konsequenzen, sie reduziert Overhead, erhöht die Wirkung, macht Sicherheitsinvestitionen für die Geschäftsleitung nachvollziehbar und bringt die Organisation in eine Lage, in der sie auf Vorfälle nicht überrascht, sondern vorbereitet reagiert.

Wer heute mit einem Compliance-getriebenen Programm startet und dazu noch eine risikobasierte Brille aufsetzt, muss nicht auf bestehende Investitionen verzichten. Im Gegenteil: vieles, was schon existiert, lässt sich in das neue Modell integrieren, die Ergebnisse werden nur sichtbarer und besser begründet. Die wirklichen Knackpunkte der Organisation werden adressiert, die irrelevanten Kontrollen fallen weg, und am Ende entsteht ein Programm, das weniger kostet, mehr wirkt und nach aussen, gegenüber Auditoren, Kunden und Regulatoren, deutlich belastbarer auftritt als jede Zertifikats-Sammlung.

Der Weg dorthin beginnt mit einer einfachen Frage, die jede Organisation sich ehrlich stellen sollte: Was würde uns in zwölf Monaten wirklich schaden, und tun wir genug, um genau das zu verhindern?