Kommentar: Das Security-Risiko trägt Schlips

Inhaltsverzeichnis

In letzter Zeit werde ich immer häufiger gefragt, wo "die Security" "aufgehängt" werden sollte. Der Fokus des Interesses scheint sich zu verschieben vom WAS (müssen wir tun, um sicherer zu sein) zum WIE (kriegen wir das effektiv hin). Das ist erst mal eine gute Nachricht.

Kolumne: Patch me if you can

Er hat eine Schwachstelle für Risiken und Über-Cyber-Schreiben: Im Hauptberuf CTO bei der intcube GmbH, tobt und lässt David Fuhr sich in dieser Kolumne über aktuelle Ereignisse und allgemeingültige Wahrheiten der Informationssicherheit aus.

So wie es, je nach Branche, einen Großteil der 80er- (Banken), 90er- (sonstige Bitschubsereien wie IT-Dienstleistungen aller Art), 2000er- (E-Commerce) oder 2010er-Jahre (kritische Infrastrukturen) gebraucht hat, vom OB (mensch Security überhaupt braucht) zum WAS (tun) zu kommen, steht nun anscheinend der nächste Evolutionsschritt an: Von der Awareness (Ob) über das Anpacken (Was) nun zum Nachdenken (Wie).

Klingt falsch rum? Ist es auch! Die ungeeignete Organisation der Security ist einer der Hauptgründe, warum die effektive Absicherung gegen Cyberattacken und andere digitale Unbill so schleppend vorangeht. Instinktiv ist zwar klar, dass es geeigneter organisatorischer Verankerung bedarf, um derart viele und tiefgreifende Veränderungen zu bewirken, wie es für Cybersicherheit notwendig ist. Und doch wird die dafür benötigte Struktur oftmals unbedacht irgendwo drangestrickt. Das geschieht meist nach einem der folgenden drei Muster:

Anhängsel

IT-Sicherheit ist doch IT!? Also reportet der IT-Sicherheitsbeauftragte an die IT-Leiterin / die CISO an den CIO. Vorteil: Die Wege sind kurz, insbesondere wenn es ums konkrete Doing geht. Und Budgets sind schnell hin- und hergeshiftet, wenn auch die Hauptpriorität oftmals nicht auf Security liegt. Blöd nur, wenn von den wichtigen Aktivitäten außer bei Vorfällen nichts im Bewusstsein des Unternehmens ankommt – und, schlimmer, keine Ausrichtung der Security-Strategie am Business stattfindet.

Überbau

Vielleicht also doch die Security möglichst weit "oben" und weit weg von der IT ansiedeln, etwa im Enterprise Risk Management, in der Revision oder als eigene Stabsstelle? Dann sitzt sie zumindest bei bestimmten entscheidenden Diskussionen mit am Tisch und kann in ihrer Wertigkeit in Bezug auf andere Unternehmensziele eingeordnet werden. Dafür haben entstehende Papiertiger es schwerer, ihren Weg zurück in die Infrastruktur zu finden.

Einbettung

Dann muss die Security-Expertise also in den einzelnen Teams verteilt sitzen? Das Business / Engineering / die Produktion sind ja eh die Einzigen, die wissen, worauf es dort ankommt. Das ist tatsächlich ein vielversprechender Ansatz, hat allerdings den Nachteil, dass eine zentrale Steuerung fehlt, Aufwände sich doppeln und Reifegrade drohen, auseinanderzudriften.

Der Autor und Unternehmensberater Simon Sinek hat uns mit seinem Buch "Start With Why" gelehrt, mit dem Warum vor das Was und das Wie zurückzugehen. Warum also möchte (m)eine Organisation sich mit Sicherheit beschäftigen? Darauf gibt es fundamental zwei mögliche Antworten. Erstens Compliance: Ich muss etwas tun, weil Verträge oder Gesetze es verlangen. Beispiel Datenschutz, Kritis, Lieferantenaudit. Zweitens Risiko: Ich möchte mich mit Security beschäftigen, um mit Unsicherheiten in der Erreichung meiner Geschäftsziele umzugehen, Beispiel Ransomware.

Je nachdem, was ich mit meiner Beschäftigung mit Security bezwecken will, sind unterschiedliche Organisationsmodelle besser geeignet. Für ein großes Unternehmen könnte es sinnvoll sein, sowohl eine zentrale Funktion für die Steuerung oder Governance zu haben als auch dezentrale Security Champions in relevanten Teams. In KMUs (hingegen) kann man es sich nicht leisten, Sicherheit in einem Dutzend verschiedener Rollen anzulegen. Wenn das Unternehmen oder die Behörde jedoch in irgendeiner Form IT auch als Output hat, ergibt sich eine weitere charmante Möglichkeit:

Zu Diensten

Egal, ob es smarte oder elektronische Produkte, Software oder mit IT hinterlegte Dienstleistungen sind, die eine Organisation produziert – am Ende kommt es immer darauf an, ob im Lebenszyklus die (Sicherheits-)Ziele erfüllt werden. Egal, ob das Rechenzentrum verschlüsselt oder das SCADA-System verseucht ist – solange der Zahlungslauf pünktlich und die Überwachung lückenlos läuft, ist kein kritischer Schaden eingetreten. In das Produkt- oder Servicemanagement gehört daher das Nachdenken über Security.

Ideen wie "Security by Service Design" (SxSD) können helfen, das richtige Maß und die geeignete Form von Security von hinten in den Produktionsprozess einzuführen. Wenn sich über drei Ecken herausstellt, dass wir dafür MS Office und 279 weitere Anwendungen patchen müssen, dann sei es so.

Wenn wir die Idee völlig umarmen, dass Security eine unabdingbare Qualitätseigenschaft dessen ist, was unsere Unternehmung in die Welt hineingibt, stehen die Chancen gut, dass sie sich bei uns angemessen etabliert.

Diese Kolumne ist erstmals in iX 7/2022 erschienen.

(ur)