Risikomanagement mit NIST: RMF (800-37) und 800-30 im Zusammenspiel

Problem in der Praxis

In vielen Organisationen existiert Risikomanagement als Dokument, nicht als Entscheidungsprozess. Es gibt ein Risikoregister, eine Tabelle mit Eintrittswahrscheinlichkeit und Auswirkung, vielleicht eine Heatmap. Was fehlt, ist die Verbindung zwischen der Bewertung eines Risikos und einer bewussten Freigabeentscheidung für den Betrieb.

Typisch sind drei Bruchstellen. Erstens wird die Risikobewertung als einmalige Übung vor einem Go-live durchgeführt und danach nicht mehr angefasst. Zweitens bewerten Teams ohne saubere Methode: Wahrscheinlichkeit und Auswirkung werden geschätzt, ohne Bedrohungsquellen, Bedrohungsereignisse, Schwachstellen und begünstigende Bedingungen zu trennen. Drittens entscheidet niemand sichtbar: Systeme gehen produktiv, ohne dass jemand das Restrisiko formal akzeptiert hat. Im Vorfall waren dann alle informiert, aber niemand hat entschieden.

Das RMF adressiert diese Lücke, weil es die Freigabe als eigenen, namentlich zugeordneten Schritt erzwingt, und SP 800-30 sorgt dafür, dass die Bewertung dahinter methodisch belastbar ist.

CISO-Einordnung

Das RMF nach SP 800-37 Rev. 2 besteht aus sieben Schritten: Prepare, Categorize, Select, Implement, Assess, Authorize, Monitor. Sie bilden einen Lebenszyklus, keinen Wasserfall: Der Monitor-Schritt speist Erkenntnisse zurück und kann jeden früheren Schritt erneut anstoßen.

• Prepare: Kontext, Rollen und Risikostrategie klären, auf Organisations-, Geschäftsprozess- und Systemebene (NIST nennt diese drei Risikomanagement-Tiers).
• Categorize: Das System nach möglicher Auswirkung auf Vertraulichkeit, Integrität und Verfügbarkeit einstufen (US-Logik nach FIPS 199; im Katalog RA-2 Security Categorization).
• Select: Controls aus SP 800-53 auswählen, ausgehend von den Baselines in SP 800-53B (Low/Moderate/High) und auf den Kontext zugeschnitten.
• Implement: Controls umsetzen und im Systemsicherheitsplan dokumentieren.
• Assess: Wirksamkeit prüfen, methodisch nach SP 800-53A; Ergebnis ist ein Assessment-Bericht (CA-2 Control Assessments).
• Authorize: Die verantwortliche Stelle, in NIST-Sprache der Authorizing Official, akzeptiert das Restrisiko und erteilt die Betriebsfreigabe (CA-6 Authorization).
• Monitor: Controls, Risiken und Systemzustand laufend beobachten; das Konzept der kontinuierlichen Überwachung steht in SP 800-137 (ISCM), im Katalog CA-7.

SP 800-30 setzt vor allem bei Categorize, Select und Assess an und strukturiert die Risikobewertung in vier Phasen: vorbereiten, durchführen, kommunizieren, pflegen. In der Durchführung werden Bedrohungsquellen, Bedrohungsereignisse, Schwachstellen und begünstigende Bedingungen identifiziert, daraus Wahrscheinlichkeit und Auswirkung abgeleitet und das Risiko bestimmt. Die saubere Trennung dieser Faktoren macht eine Bewertung nachvollziehbar und wiederholbar und unterscheidet sie von einer geratenen Ampelfarbe.

Die Verklammerung lautet: RMF gibt Takt und Verantwortlichkeiten, 800-30 liefert den methodischen Inhalt, und die Authorization macht aus der Bewertung eine Managemententscheidung.

Umsetzungsperspektive

Für Organisationen außerhalb des US-Behördenraums ist das RMF kein Pflichtprogramm, aber ein brauchbares Gerüst. Wer nach ISO/IEC 27001 arbeitet, betreibt Risikomanagement ohnehin; SP 800-30 lässt sich als Methodenbaustein neben oder anstelle von ISO/IEC 27005 nutzen, und der Authorization-Gedanke schließt eine häufige Lücke in der Risikoakzeptanz.

Pragmatisch beginnt die Umsetzung mit wenigen, aber verbindlichen Festlegungen:

• Eine benannte Rolle, die für kritische Systeme das Restrisiko formal akzeptiert, das Pendant zum Authorizing Official, geschäftlich entscheidungsbefugt, nicht nur fachlich.
• Eine einheitliche Bewertungsmethode entlang 800-30: gleiche Faktoren, Skalen und Definitionen für alle Systeme.
• Ein Freigabepaket pro kritischem System: Sicherheitsplan, Bewertungsergebnis und Maßnahmenplan für offene Punkte (CA-5 Plan of Action and Milestones).
• Eine Taktung für den Monitor-Schritt, damit Freigaben nicht unbegrenzt gelten, sondern an Bedingungen und Wiedervorlage gekoppelt sind.

Der Reifegrad zeigt sich am Übergang von der periodischen zur laufenden Bewertung: Mit ISCM und ongoing authorization beschreibt NIST ein Modell, in dem die Freigabe durch kontinuierliche Überwachung gestützt statt alle paar Jahre erneuert wird. Das ist anspruchsvoll, aber die Richtung reifer Programme.

Typische Fehler

1. Die Risikobewertung wird einmalig vor dem Go-live erstellt und nie aktualisiert; der Monitor-Schritt findet faktisch nicht statt.
2. Wahrscheinlichkeit und Auswirkung werden geschätzt, ohne Bedrohungsquellen, Ereignisse und Schwachstellen zu trennen.
3. Es gibt keine benannte Person, die das Restrisiko formal akzeptiert; Systeme gehen ohne Authorization in Betrieb.
4. Die Categorize-Stufe wird übersprungen, sodass die Control-Auswahl nicht zum Schutzbedarf passt, zu viel oder zu wenig.
5. Offene Punkte landen nicht in einem nachverfolgten Maßnahmenplan, sondern verschwinden nach der Freigabe.

Risiken und Trade-offs

Das RMF schafft Nachvollziehbarkeit, kostet aber Aufwand. Vollständig auf jedes System angewandt erzeugt es erhebliche Dokumentations- und Prüflast. Der Trade-off liegt in der Skalierung: Welche Systeme rechtfertigen den vollen Durchlauf, welche eine vereinfachte Variante? Eine undifferenzierte Anwendung auf alles bindet Kapazität, die an kritischen Systemen fehlt.

Ein zweiter Trade-off betrifft die Genauigkeit. SP 800-30 erlaubt qualitative, halb-quantitative und quantitative Ansätze. Mehr Präzision verbessert Entscheidungen, kostet aber Zeit und Daten, die oft fehlen. Scheinpräzision, eine Zahl ohne belastbare Grundlage, ist gefährlicher als eine ehrliche qualitative Einschätzung.

Drittens besteht die Gefahr, die Authorization als formalen Stempel zu behandeln. Unterschreibt der Authorizing Official ohne echte Prüfung, entsteht eine dokumentierte Scheinentscheidung, die im Ernstfall Verantwortung verschleiert statt sie zu klären.

Entscheidungspunkte

• Welche Systeme durchlaufen das volle RMF, welche eine reduzierte Variante, und nach welchem Kriterium?
• Wer ist die entscheidungsbefugte Person für die Risikoakzeptanz kritischer Systeme?
• Welche Bewertungsmethode (qualitativ, halb-quantitativ, quantitativ) nach SP 800-30 passt zu welcher Systemklasse?
• Wie lange gilt eine Freigabe, und welche Ereignisse lösen eine Neubewertung aus?
• Wie verbindet sich der NIST-Ansatz mit einem bestehenden ISO-27001-Risikomanagement, ohne Doppelstrukturen zu erzeugen?

Praktische Empfehlungen

1. Nutzen Sie die sieben RMF-Schritte als gemeinsame Sprache für den Systemlebenszyklus, auch ohne formale US-Verpflichtung.
2. Standardisieren Sie die Risikobewertung entlang SP 800-30: definierte Faktoren, dokumentierte Skalen, einheitliche Begriffe für alle Teams.
3. Machen Sie die Authorization zu einer echten, benannten Entscheidung mit Auflagen und Gültigkeitsdauer, nicht zu einem Formblatt.
4. Führen Sie pro kritischem System ein Freigabepaket aus Sicherheitsplan, Bewertungsergebnis und Maßnahmenplan und halten Sie es aktuell.
5. Koppeln Sie den Monitor-Schritt an konkrete Auslöser (Änderungen, Vorfälle, Fristen) statt an Kalenderroutine allein.
6. Differenzieren Sie den Aufwand nach Schutzbedarf, damit Kapazität auf die wirklich kritischen Systeme entfällt.

Relevante Normreferenzen

• NIST SP 800-37 Rev. 2: Risk Management Framework (sieben RMF-Schritte). Public Domain.
• NIST SP 800-30 Rev. 1: Guide for Conducting Risk Assessments (Bewertungsmethode). Public Domain.
• NIST SP 800-39: Managing Information Security Risk (Risikomanagement-Tiers Organisation/Geschäftsprozess/System). Public Domain.
• FIPS 199: Standards for Security Categorization (Grundlage der Categorize-Stufe nach Vertraulichkeit/Integrität/Verfügbarkeit; RA-2 im Katalog). Public Domain.
• NIST SP 800-53 Rev. 5 und Begleitwerke: Control-Katalog (20 Familien, 324 Basis-Controls, 872 Enhancements; relevant RA und CA); SP 800-53A (Assessment), SP 800-53B (Baselines Low/Moderate/High), SP 800-137 (ISCM). Public Domain.
• ISO/IEC 27005: Referenz für Risikomanagement im ISMS-Kontext; Edition vor Nutzung prüfen.