MHC-10 Continuous Control Monitoring und Policy-as-Code

Auf einen Blick

Operativer Nutzen

Verkürzt die Zeit bis zum Erkennen einer Sicherheits-Abweichung von Monaten (Audit-Takt) auf Minuten, weil Vorgaben laufend automatisch geprüft werden. Zielzustand ab Stufe Defined; setzt automatisierte Soll-Vorgaben (Policy-as-Code) voraus.

Betroffene Richtlinie

Richtlinie zur Überwachung der Wirksamkeit und Einhaltung von Sicherheitsvorgaben.

Abhängigkeiten

keine Vorbedingung; setzt maschinenlesbar formulierbare Vorgaben und Zugriff auf System-/Konfigurationsdaten voraus.

Aufwandstreiber

hängt von Zahl und Art der zu prüfenden Vorgaben und der Heterogenität der Systemlandschaft ab. Der konkrete Aufwand richtet sich nach den Ressourcen der Organisation.

Primäre Kennzahl

Continuous-Monitoring-Coverage — Anteil der als automatisierbar klassifizierten SoA-Anforderungen mit aktiver automatisierter Prüfung (mindestens täglich). Bezugsgröße ist ausdrücklich die Automatisierungs-Eignung, nicht die Gesamtzahl der SoA-Controls; beide Kennzahlen sind in Abschnitt 7 definiert (MRIS Anhang G.6a/G.6b).

Berührte Standards (ohne Erfüllungsanspruch)

ISO/IEC 27002 A.5.35/A.5.36; C5:2026 COM-03/04; NIS2-DVO Nr. 2.2; DORA Art. 6(5); NIST SP 800-137.

Control-Statement

Die Einhaltung von Sicherheitsvorgaben wird laufend und automatisiert gegen festgelegte Soll-Zustände geprüft, statt nur in periodischen Audits. Vorgaben werden, wo möglich, als ausführbare Regeln formuliert (Policy-as-Code) und in die Bereitstellungs- und Betriebsprozesse eingebunden; Abweichungen werden alarmiert und nachverfolgt. Weiterführende Härtung (Stufe Managed): Durchsetzung im Betrieb (Runtime-Enforcement) und automatisch erzeugte Bearbeitungsvorgänge bei Abweichungen.

Zweck und Bedrohungsbezug

Periodische Audits prüfen nur zu festen Zeitpunkten (etwa quartalsweise); in der Zeit dazwischen bleiben Abweichungen unentdeckt. AI-gestützte Angreifer nutzen genau diese Lücke: Sie schaffen — oder finden — eine Fehlkonfiguration und nutzen sie, lange bevor das nächste Audit stattfindet. Zudem zerlegen agentische Angreifer ihr Vorgehen in Schritte, die jeder für sich regelkonform aussehen. Eine laufende, automatisierte Prüfung erkennt Abweichungen sofort und bringt sie unmittelbar zur Reaktion. Schutzziel ist, die Zeitspanne zwischen einer Abweichung und ihrer Erkennung auf ein Minimum zu verkürzen.

Wirkung in den Regelwerken

Auf diese Controls und Anforderungen wirkt das MHC. Die Einstufung zeigt, wie stark das jeweilige Control unter KI-gestützten Angriffen an Wirkung verliert.

Alle 93 Controls in der Analysematrix · Alle 45 Controls in der Befundmatrix · Alle 23 Anforderungen der Bausteinfamilie

Reifegrad-Pfad

Initial

Compliance-Übersichten mit manueller Pflege.

Defined

Policy-as-Code in der CI-Pipeline; Echtzeit-Prüfungen gegen Soll-Zustände; Abweichungen werden alarmiert und nachverfolgt.

Managed

Durchsetzung im Betrieb (Runtime-Enforcement); automatisch erzeugte Vorgänge bei Abweichungen.

Messung und Audit-Nachweis

Kennzahl 1

Automatisierungs-Eignung — Anteil der im SoA geführten Anforderungen, die technisch automatisiert prüfbar sind. Diese Klassifikation wird einmal dokumentiert und jährlich überprüft; sie schließt Anforderungen aus, die sich einer täglichen automatisierten Prüfung entziehen (Personalthemen, Verträge, physische Maßnahmen, Governance, Managementbewertung, Behördenkontakte, Richtlinienpflege).

Kennzahl 2

Continuous-Monitoring-Coverage — Anteil der als automatisierbar klassifizierten Anforderungen mit aktiver automatisierter Prüfung (mindestens täglich, mit Alarmierung bei Abweichung). Richtwerte: ≥ 60 % nach 12 Monaten, ≥ 80 % nach 24 Monaten. Der Nenner sind ausdrücklich nur die automatisierbaren Anforderungen; die Messung gegen alle SoA-Controls würde die Kennzahl verzerren und lädt zu Kennzahlen-Optimierung ein. Optional zusätzlich risikogewichtet auswerten.

Nachweis

Regel-Repository (Policy-as-Code), Übersicht der automatisiert geprüften Controls, Protokolle ausgelöster Vorgänge bei Abweichungen.

Nachweislogik (in Anlehnung an ISO/IEC 27001, Clause 9)

dokumentiert? — Regelbestand und Abdeckungsübersicht; verantwortlich? — ISMS-Leitung; Häufigkeit? — fortlaufend (mindestens täglich); Toleranz? — wesentliche Controls ohne automatisierte Prüfung nur befristet und begründet.

Typische Fehler

• Die automatisierte Prüfung wird als Ersatz für Audits verstanden; tatsächlich ergänzt sie diese — die geforderten Überprüfungen bleiben nötig.
• Es werden Übersichten gebaut, aber Abweichungen lösen keine Reaktion aus; der Befund bleibt folgenlos.
• Nur leicht prüfbare Vorgaben werden automatisiert, die wesentlichen aber nicht; die Abdeckung wirkt hoch, deckt aber nicht das Wichtige ab.
• Die Soll-Zustände werden einmal definiert und nicht gepflegt, sodass die Prüfung an veralteten Vorgaben misst.

Abgrenzung und Restrisiko

Abgrenzung

betrifft die laufende Prüfung der Einhaltung von Vorgaben; das Erkennen aktiver Angriffe behandelt MHC-05, die automatisierte Reaktion MHC-11.

Restrisiko

geprüft wird nur, was als Regel formuliert ist — unklare oder nicht maschinell prüfbare Vorgaben bleiben außen vor; richtlinienkonforme, aber bösartige Aktivität wird erst im Zusammenspiel mit verhaltensbasierter Erkennung (MHC-05) sichtbar.

ISO/IEC 27002:2022

A.5.18 Zugangsrechte; A.5.35 Unabhängige Überprüfung der Informationssicherheit; A.5.36 Einhaltung von Richtlinien, Vorschriften und Normen für die Informationssicherheit; A.8.9 Konfigurationsmanagement.

Framework

C5:2026 COM-03/COM-04; NIS2-DVO Nr. 2.2; DORA Art. 6(5); OWASP SAMM; NIST SP 800-137 und 800-137A (ISCM); NIST OSCAL (maschinenlesbare Controls); Policy-Engines Open Policy Agent (OPA/Rego), HashiCorp Sentinel.

Umsetzung im Detail

Organisatorische und technische Umsetzung, Umsetzungsbeispiele und die Priorisierung im Gesamtprogramm beschreibt der Implementation Guide.

Implementation Guide (PDF)Zum MHC-Katalog

Quelle: MRIS Implementation Guide (ISO/IEC 27001), Fassung 2.0. Lizenz CC BY-SA 4.0. © 2026 Richard Peddi.