FCS-Matrix
Übersicht: BSIG/NIS-2-Anforderungen & unterstützende FCS-Lösungen
FCS im NIS-2-Kontext
Die FCS-Lösungen unterstützen Organisationen dabei, zentrale Anforderungen aus NIS-2/BSIG in der Praxis umzusetzen – insbesondere dort, wo Transparenz, Dokumentation und operatives Handeln in IT-Prozessen erforderlich sind.
Wichtiger Hinweis: Diese Übersicht dient der fachlichen Einordnung und zeigt, welche Anforderungen durch FCS-Lösungen unterstützt werden können. Sie stellt keine Aussage zur vollständigen oder automatischen NIS-2-Compliance dar und ersetzt keine individuelle Risiko- oder Rechtsbewertung.
Kontext & Transparenz
- Strukturierte Übersicht über IT-Assets
- Zuordnung von Assets zu Bereichen/Standorten
- Nachvollziehbarkeit über Lebenszyklus & Historien
- Grundlage für Risiko- und Priorisierungsentscheidungen
Security-nahe Unterstützung
- Device-/Media-Control: USB, Wechselspeicher, CD/DVD, Bluetooth
- Protokollierung von Geräte-/Medienereignissen (z. B. Ein-/Ausstecken)
- Optionale Datei-/Transfer-Protokollierung (z. B. bei Wechselspeichern)
- OS-/Windows-Update-Transparenz als Basis für Hygiene-Maßnahmen
Operative Umsetzung
- ITSM/Ticketprozesse für Vorfälle und Maßnahmen (HEINZELMANN)
- Standardisierte Softwareverteilung (Install.Desk)
- Gezielte Rollouts auf Geräte/Gruppen/AD-Gruppen
- Status-/Erfolgskontrolle von Verteilaufträgen
| BSIG-Paragraph (NIS-2) | FCS-Lösung | Unterstützung & praktisches Beispiel |
|---|---|---|
| § 30 BSIG – Risikomanagementmaßnahmen (Art. 21 NIS-2) |
Asset.Desk, Security.Desk, HEINZELMANN (ITSM), Install.Desk | Zusammenspiel aus Transparenz, Prozess und Umsetzung: Asset.Desk unterstützt durch eine strukturierte Asset-Datenbasis. Security.Desk ergänzt endpoint-nahe Informationen (z. B. Device/Media-Control und OS-/Update-Transparenz). HEINZELMANN Service.Desk unterstützt die strukturierte Bearbeitung und Dokumentation in IT-Prozessen. Install.Desk unterstützt die operative Umsetzung durch kontrollierte Softwareverteilung. Hinweis: Die konkrete Umsetzung im Unternehmen (Richtlinien, Rollen, Workflows) bleibt entscheidend. |
| § 30 Abs. 2 – Konzepte für die Risikoanalyse | Asset.Desk, Security.Desk | Datenbasis & technische Sicht: Asset.Desk liefert die strukturierte Asset-Übersicht als Grundlage. Security.Desk ergänzt endpoint-nahe Informationen (z. B. Betriebssystemstände und Windows-Update-Konfigurationen), die für Risiko- und Hygiene-Bewertungen herangezogen werden können. Kein Vulnerability-Scanning/EDR: Security.Desk liefert Monitoring-/Konfigurationsdaten und Device/Media-Events, nicht CVE- oder Malware-Funde. |
| § 30 Abs. 2 – Sicherheit der Lieferkette | Asset.Desk | Software-Transparenz: Dokumentation eingesetzter Software (z. B. Hersteller/Versionen) als Grundlage, um Lieferkettenrisiken zu bewerten und bei Herstellerwarnungen schneller zu reagieren. Formale SBOM-Formate (z. B. SPDX/CycloneDX) werden hier nicht zugesagt – Fokus auf nachvollziehbare Software-Übersichten. |
| § 30 Abs. 2 – Cyberhygiene | Asset.Desk, Security.Desk, Install.Desk | Transparenz + Umsetzung: Asset.Desk unterstützt die Identifikation veralteter Softwarestände (z. B. End-of-Life) als Grundlage für Maßnahmen. Security.Desk unterstützt Hygiene-Entscheidungen durch OS-/Windows-Update-Transparenz. Install.Desk unterstützt die standardisierte und kontrollierte Softwareverteilung. Install.Desk-Beispiel: Rollout von Office 365 über Job mit setup.exe /configure und Verteilung auf Geräte/AD-Gruppen (gemäß Handbuch). |
| § 30 Abs. 2 – Behandlung von Sicherheitsvorfällen | HEINZELMANN (ITSM), Asset.Desk, Security.Desk, Install.Desk + ggf. SIEM/EDR | Prozess + Kontext + endpoint-nahe Evidenz + Umsetzung: HEINZELMANN unterstützt die strukturierte Ticketbearbeitung (Erfassung, Priorisierung, Bearbeitung, Dokumentation). Asset.Desk liefert den notwendigen Kontext. Security.Desk liefert device-/media-bezogene Ereignisse und Protokolle. Install.Desk unterstützt die Umsetzung technischer Maßnahmen in der Fläche. Security.Desk ist kein SIEM/EDR – kann aber relevante Device/Media-Events als Evidenz beitragen. |
| § 39 BSIG – Nachweispflichten & Audit-Unterstützung (Unterstützt zudem die Registrierungspflichten nach §§ 33/34) | Asset.Desk, HEINZELMANN (ITSM), Security.Desk | Nachvollziehbarkeit: Asset-Historien/Reports (Asset.Desk) und dokumentierte Ticketverläufe/Entscheidungen (HEINZELMANN) unterstützen Audit- und Nachweisanforderungen. Security.Desk ergänzt Nachweise durch Protokolle/Reports zu Device/Media-Nutzung. Hinweis: „Revisionssicherheit“ hängt auch von organisatorischen Regeln ab. |
| § 32 BSIG – Meldepflichten bei Sicherheitsvorfällen | Asset.Desk, HEINZELMANN (ITSM) | Grundlage für schnelle Lagebilder: Asset-Kontext (Systeme/Abhängigkeiten) und strukturierte Dokumentation im Ticketverlauf unterstützen die inhaltliche Vorbereitung von Meldungen. Keine automatische Meldung – es geht um belastbare Informationen und Dokumentation. |
| § 38 BSIG – Überwachungs- und Verantwortungspflicht der Geschäftsleitung | Asset.Desk, HEINZELMANN (ITSM) | Transparenz für Management: Berichte/Dashboards (Asset.Desk) und Kennzahlen aus Ticketprozessen (HEINZELMANN) unterstützen die Nachvollziehbarkeit von Sicherheitslage und Maßnahmenstatus. Management-Verantwortung bleibt organisatorisch – Tools liefern Sichtbarkeit. |
| Audit-Unterstützung (Querschnitt) | FCS-Lösungen | Dokumentation & Exporte: Historien, Reports und nachvollziehbare Prozesse unterstützen Prüfungen (z. B. interne Audits, externe Assessments). Formulierung bewusst allgemein: konkrete Reporttypen/Exporte hängen von Modul und Setup ab. |
Zusammenfassung: FCS vs. ergänzende Security-Tools
Typische Stärken der FCS-Lösungen
- Kontext & Transparenz über IT-Assets
- Nachvollziehbare Dokumentation (Historien/Reports)
- ITSM-Prozesse (Ticketbearbeitung & Maßnahmen-Nachweise)
- Standardisierte Softwareverteilung (Rollouts/Planung)
- Device/Media-Control & Protokollierung (Security.Desk)
Häufig ergänzende Security-Komponenten (siehe Tabelle unten)
- SIEM/SOC zur Erkennung/Korrelation
- EDR/XDR zur Endpoint-Erkennung/Response
- Vulnerability Scanner zur technischen Schwachstellen-Erkennung
- IAM/PAM für Identitäten und Rechte
"Security-Tools erkennen – Governance braucht Kontext und Nachweise."
FCS unterstützt dabei, Fragen nach Betroffenheit, Abhängigkeiten und Maßnahmen nachvollziehbar zu beantworten.
Kernbotschaft
FCS positioniert sich als Kontext- und Dokumentationsbasis sowie als Prozess-Unterstützung im NIS-2-Umfeld.
Das reduziert Blindspots in der IT-Dokumentation, beschleunigt die Bearbeitung von Vorfällen und erleichtert Nachweise gegenüber internen und externen Prüfstellen – ohne eine automatische Compliance-Zusage.
Der Kontext: Warum die Ergänzung für NIS-2 entscheidend ist
Während spezialisierte Security-Tools technische Ereignisse erkennen, liefert die FCS Suite den notwendigen administrativen und prozessualen Rahmen für die Compliance.
| Security-Komponente | FCS-Kontext (Asset.Desk & Co.) |
|---|---|
| SIEM/SOC (Erkennung/Korrelation) |
Das SIEM meldet ein Ereignis auf einer IP. Asset.Desk liefert sofort den Kontext: Welches System ist betroffen, wer ist der Verantwortliche und wie hoch ist die Kritikalität? HEINZELMANN dokumentiert die Entstörung für den NIS-2-Nachweis. |
| EDR/XDR (Abwehr/Response) |
EDR erkennt bösartiges Verhalten. Security.Desk liefert die administrative Ebene (USB-Nutzung/Media-Events). Install.Desk stellt die automatisierte Verteilung und Statusprüfung der EDR-Agenten auf allen Endgeräten sicher. |
| Vulnerability Scanner (Schwachstellen-Scan) |
Scanner finden technische Lücken. Asset.Desk dient als Abgleichbasis, um sicherzustellen, dass keine Schatten-IT vergessen wurde. Install.Desk liefert den Weg, um Patches und Updates gezielt auf die gefundenen Schwachstellen auszurollen. |
| IAM/PAM (Identitäten/Rechte) |
IAM steuert Zugriffsberechtigungen. Asset.Desk dokumentiert die physische Zuordnung von Assets zu Personen. HEINZELMANN liefert den Revisions-Workflow: Rechteänderungen werden strukturiert beantragt, genehmigt und archiviert. |
Fazit: Die Security-Tools agieren als technische Alarmanlage. Die FCS Suite fungiert als Katasteramt und Einsatzbuch – sie macht aus einem technischen Alarm einen nachvollziehbaren Prozess.