Security-Bausteine, Teil 5: Vier Stufen – Risiko und Security Levels

Es soll also etwas für die Security getan werden. Aber: wie viel? Immerhin kostet das Zeit, Geld und oft auch Bequemlichkeit ("Usability"). Hundertprozentige Security ist bekanntermaßen nicht erreichbar. Da aber der zusätzliche Nutzen höherer Investitionen immer weiter abnimmt, muss man sich über das richtige Maß Gedanken machen.

Inhalt der Artikelreihe "Security-Baukasten"

Theoretische Einführungen in und umfangreiche Standards zur IT-Sicherheit gibt es viele. Wenn man den Gedanken dieser sechsteiligen Miniartikelreihe folgt, entsteht unterwegs die Basis für ein schlankes und schlagkräftiges Securityprogramm.

• Teil 1: Null Vertrauen: Zero-Day und Zero Trust
• Teil 2: Ein Passwort: Assets und Zugriff
• Teil 3: Zwei Faktoren: Authentifizierung und Backup
• Teil 4: Drei Werte: CIA or DIE
• Teil 5: Vier Levels: Risiko und Security-Levels
• Teil 6: Fünf Bedrohungen: Threats und Models

Viele handelsübliche Vorgehensweisen versuchen, einen Schutzbedarf für Werte wie Daten, Anwendungen oder Systeme zu bestimmen. Dafür zieht man häufig qualitative Kategorien heran. Im IT-Grundschutz etwa heißen diese normal (begrenzte Auswirkung bei (Zer-)Störung des Werts), sehr hoch (im Fall der Fälle existenziell bedrohlich) und hoch (alles dazwischen). Schäden können dabei auf verschiedene Weise entstehen, etwa Verstöße gegen Gesetze oder Verträge, negative Innen- oder Außenwirkung oder finanzielle Verluste. Die Auswirkung muss man dabei in allen relevanten Dimensionen von Schützenswertem betrachten, etwa Vertraulichkeit, Integrität und Verfügbarkeit.

Was als normal, hoch oder sehr hoch gilt, muss jede Organisation selbst definieren, sofern es von außen keine Vorgaben dazu gibt. Letzteres ist teilweise bei kritischen Infrastrukturen der Fall, wo der Gesetzgeber vermeiden will, dass Betreiber ihr Ziel-Sicherheitsniveau herunterrechnen, um Aufwände zu sparen. Erst wenn die Schadensszenarien, die Stufen und Schwellenwerte klar sind, kann man beginnen, jedes einzelne Asset nach diesem Maßstab zu bewerten. Dabei kommen Prinzipien wie Maximum, Vererbung und Verteilung zum Einsatz, um etwa den Verfügbarkeitsbedarf eines Servers von dem der Daten oder gar Geschäftsprozesse abzuleiten, die mithilfe dieses Servers erbracht werden. Dann lassen sich im nächsten, nicht weniger aufwendigen Schritt die Risiken bestimmen. Risiken drückt man dabei häufig als Produkt von Eintrittswahrscheinlichkeiten und Schutzbedarf oder Schadenspotenzial aus.

David Fuhr

David Fuhr ist Cofounder und CTO der intcube GmbH.

Anforderung rein, Aktion raus

Anstelle dieses aufwendigen Wegs gibt es zwei andere Ansätze, die versprechen, einen Teil der anstrengenden Denk- und Dokumentationsarbeit zu sparen. Der Erste nennt sich Mindeststandards: Anstatt zu versuchen, die Menge, Stärke und Tiefe der IT-Sicherheitsmaßnahmen genau auf den Anwendungsfall zuzuschneiden, nutzt man eine One-Size-fits-all-Liste von Anforderungen. So funktionieren etwa die meisten rein technischen Standards, die sich mit Security beschäftigen. TLS 1.3 etwa fragt nicht, welchen Schutzbedarf die zu übertragenden Daten haben, SSH gibt es nicht in Normal-, Hoch- und Sehr-hoch-Geschmack. Der Mindeststandard ist entweder umgesetzt oder nicht.

Einen nuancierteren Ansatz versuchen Normen wie die aus der Industrial Security stammende IEC 62443 umzusetzen. Die IEC 62443 definiert vier Security Levels, die die Anzahl der umzusetzenden Maßnahmen steuern. Der Prozess ist somit zweischrittig: Sage mir, welches Security Level (SL) du bist/hast/willst, und ich sage dir, wie viel du tun musst. Höhere SLs führen neue Maßnahmen ein oder verschärfen die bereits umgesetzten.

Interessanterweise definiert die IEC 62443 das SL nicht über den Wert der Assets, sondern über die im Worst Case zu erwartende Angreiferkompetenz. Wer würde meine Umgebung schlimmstenfalls attackieren wollen? SL 1 meint den Nicht-Angreifer, nämlich das technische Versagen, das uns auch dann treffen kann, wenn niemand uns Böses will. SL 2 beschreibt im Wesentlichen Script Kiddies, SL 3 Cybercrime und SL 4 Advanced Persistant Threats, also ressourcenreiche staatlich gesteuerte Akteure. Das Konzept erlaubt es, die Risikoanalyse kurzzuhalten: Man muss nur bewerten, welches SL zu erreichen ist, und entscheidet das entweder einmal für die Infrastruktur oder je Zone. Sinnvollerweise unterscheidet die Norm auch nach Schutzzielen, in der IEC 62443 Foundational Requirements genannt. Beispiel: Integrität SL 3, Authentizität SL 2 und so weiter. Am Ende stehen unterm Strich automatisch die umzusetzenden Maßnahmen, wodurch dieser Ansatz einem den Großteil der Risikoanalyse abnimmt.

Letztendlich geht es darum, wie viel Gehirnschmalz und Expertise man auf welchen Teil der Analyse ver(sch)wenden möchte. Kann ich mir den Luxus leisten, für jede Komponente einzeln den Schutzbedarf zu bestimmen? Habe ich genug Fachwissen im Zugriff, um alle Risiken zu bewerten? Dort, wo die Antwort kein hundertprozentiges Ja ist, können sowohl Mindeststandards als auch Security Levels helfen, ein einigermaßen angemessenes Set an Maßnahmen für das jeweilige Risikoprofil zu ermitteln. Umsetzen muss man sie so oder so noch.

(pst)