Das Inkrafttreten der europäischen RichtlinieNIS 2 (Netzwerk- und Informationssicherheit)markiert einen historischen Wendepunkt für die Cybersicherheit in Europa. Im Gegensatz zur ersten Version, die sich nur an Betreiber wichtiger Infrastruktur richtete, erweitert NIS 2 seinen Anwendungsbereich erheblich. Mittlerweile fallen Tausende von KMU, mittelständischen Unternehmen und Managed Service Providern (MSSPs) in die Kategorie „wesentliche“ oder „wichtige Unternehmen“.
Zu den zentralen Pflichten dieser Gesetzgebung gehört die Verpflichtung, Maßnahmen zur Störungsbewältigung umzusetzen und eine einwandfreie Nachvollziehbarkeit aller im Netz vorgenommenen Korrekturmaßnahmen sicherzustellen. Für Unternehmen und ihre Cyber-Dienstleister ist das Verständnis, wie diese Maßnahmen überprüft werden können, keine Option mehr, sondern eine rechtliche Einschränkung, die mit hohen finanziellen Strafen verbunden ist.
Anforderungen an das NIS 2-Vorfallmanagement
Die NIS 2-Richtlinie erfordert einen proaktiven und dokumentierten Ansatz zur Cyberverteidigung. Es reicht nicht mehr aus, einen Angriff im Hintergrund abzuwehren; Sie müssen es beweisen könnenWieDu hast es blockiert,Wanndie Maßnahme wurde ergriffen undWHOhat diesen Eingriff genehmigt.
In Artikel 21 der Richtlinie heißt es ausdrücklich, dass Unternehmen über Fähigkeiten zur Reaktion auf Vorfälle verfügen müssen, die den Risiken angemessen und verhältnismäßig sind. Im Falle einer Prüfung durch nationale Behörden (wie ANSSI in Frankreich oder BSI in Deutschland) muss das Unternehmen in der Lage sein, detaillierte Prüfprotokolle der Aufsichtsinfrastruktur bereitzustellen. Wenn Ihr Security Operations Center (SOC) oder Orchestrator (SOAR) Notfallbefehle ausführt, ohne unveränderliche und nachvollziehbare Aufzeichnungen zu führen, verstößt Ihr Unternehmen gegen die Vorschriften.
Die Herausforderung der Rechenschaftspflicht für MSSPs und interne SOCs
Für einen Cyber-Service-Provider (MSSP), der die Microsoft-Sicherheitsmandanten von Dutzenden von Kunden verwaltet, oder für ein internes IT-Team, das eine Flotte mittelständischer Unternehmen verwaltet, ist die größte Prüfungsfalle das Fehlen einer echten Verantwortlichkeit.
In vielen handwerklichen Architekturen verwenden Behebungsskripte oder IT-Ticketing-Tools ein einheitliches generisches Dienstkonto (ein „Schattenkonto“), um Microsoft Graph-APIs aufzurufen. Wenn eine Maschine vom Netzwerk isoliert oder eine Benutzersitzung widerrufen wird, zeigt das native Überwachungsprotokoll von Microsoft einfach Folgendes an:„Von der SOAR-XYZ-Anwendung ausgeführte Aktion“.
In den Augen eines NIS 2-Prüfers ist diese Rückverfolgbarkeit unzureichend. Das Tool ist nicht in der Lage, die technische Aktion mit dem tatsächlichen menschlichen Bediener zu verknüpfen, der sich vor seinem Bildschirm befand und auf die Schaltfläche klickte. Die Rechenschaftspflicht ist gebrochen.
Die „Compliance by Design“-Architektur von Akuity SOC
Der OrchestratorAkuity SOCwurde in Bayern nach strengen Sicherheitsstandards und der Einhaltung europäischer Vorschriften entwickelt. Sein Audit-Log-Verwaltungsmodul (zentralisiert in der Konfigurationsdateiaudit.ts) löst nativ das von NIS 2 geforderte Verantwortlichkeitsproblem.
1. Automatische Kontextauflösung
Immer wenn eine aktive Korrekturmaßnahme auf der Plattform ausgelöst wird – sei es eine Netzwerkisolation einer von Intune verwalteten Maschine (ISOLATEDEVICE) oder eine globale Löschung einer Phishing-E-Mail (SOFTDELETE_EMAIL) – die Backend-FunktionlogAuditfängt die Anfrage ab. Es analysiert das Supabase-Sitzungstoken (sb-access-token) in den Server-Anfrage-Cookies vorhanden. Das System fragt sofort das Supabase Auth-Modul ab, um die genaue E-Mail-Adresse und UUID des angemeldeten Analysten zu extrahieren. Die Handlung wird somit in unbestreitbarer Weise einem echten Menschen zugeschrieben und ihm zugeschrieben.
2. Das SOC 2 standardisierte JSON-Format
Die generierten Audit-Protokolle sind keine einfachen bearbeitbaren Textzeilen. Sie sind nach einem standardisierten JSON-Rohschema strukturiert und werden direkt in die Standardausgabe geschrieben (console.log). Diese Nutzlast zeichnet unveränderlich auf:
- Ein genauer Zeitstempel im ISO-UTC-Format (
timestamp). - Der Kontext des Schauspielers (
actormit E-Mail und UUID). - Die spezifische ausgeführte Aktion (
action). - Der Umfang des Arbeitsbereichs (
workspace_id). - Die betroffenen spezifischen Ziele (
targets(z. B. PC-Name oder Benutzer-UPN).
3. Garantien für inhaltliche Aufgaben
Wenn eine Aktion ohne Benutzersitzungstoken ausgeführt wird (z. B. eine automatisierte geplante Bereinigungsaufgabe oder ein Systemskript), weigert sich die Akuity-Engine, das Feld leer zu lassen. Es ordnet das Ereignis automatisch dem institutionellen Akteur zu"System", um sicherzustellen, dass in der Protokollzeitleiste keine blinden Flecken vorhanden sind.
Fazit: Einschränkung in Schild umwandeln
Die Einhaltung der NIS-2-Richtlinie sollte nicht als eine weitere Verwaltungsaufgabe betrachtet werden. Durch die Einführung eines souveränen Orchestrators, der Rückverfolgbarkeit und Verantwortlichkeit tief in seinen Code integriert, schützen Sie Ihre Kunden und Ihr Unternehmen. Sie verfügen über ein einwandfreies Logbuch für Ihre offiziellen Audits und stärken das Vertrauen Ihrer Geschäftspartner.
Bringen Sie Ihren SOC-Betrieb in Einklang mit den europäischen Anforderungen.> Entdecken Sie unsere PlattformNIS 2- und SOC 2-kompatible Orchestrierungund sichern Sie noch heute Ihre Audit-Protokolle.