BEKOM MANAGEDOPNsense für KRITISAuditfähig im Managed Service
OPNsense strukturiert in KRITIS-Umgebungen einsetzen: BSI-KritisV und NIS-2 umsetzen, Nachweisführung, Managed-Service-Betrieb mit belegbaren Reportings.
Die Situation in KRITIS-Einrichtungen
Einrichtungen kritischer Infrastrukturen stehen unter doppelter Regulierungsdichte. BSI-Kritisverordnung (BSI-KritisV) und NIS-2-Richtlinie verlangen Stand-der-Technik-Sicherheitsmaßnahmen mit auditfähiger Nachweisführung. Die Firewall ist in beiden Regelwerken die zentrale Kontrollinstanz für Segmentierung, Zugriffskontrolle und Protokollierung. OPNsense lässt sich in KRITIS-Umgebungen strukturiert einführen und unter den Anforderungen der Regulierung betreuen – als eine von mehreren bewährten Lösungen, die BEKOM unter BEKOM MANAGED Security im Managed Service einführt.
BSI-KritisV und §8a-Pflichten
Die BSI-KritisV definiert über sektorale Schwellenwerte, welche Energie-, Wasser-, Gesundheits-, Transport- und Finanzdienste zur Kritischen Infrastruktur zählen. Aus §8a BSIG ergeben sich nachweispflichtige Sicherheitsvorkehrungen mit turnusmäßiger externer Prüfung. → Managed Compliance
Pflichten aus §8a BSIG:
Stand-der-Technik-Sicherheitsmaßnahmen mit dokumentiertem Sicherheitskonzept
Mindestens alle zwei Jahre Nachweis gegenüber dem BSI durch geeignete Prüfgrundlage
Meldepflicht bei erheblichen Störungen nach §8b BSIG mit definierten Zeitfenstern
Regelmäßige interne Überprüfung mit mindestens jährlichem Review
Sektorale Konkretisierung:
- Branchenspezifische Sicherheitsstandards (B3S) als anerkannte Prüfgrundlage
- Audit nach §8a Abs. 3 durch zugelassene Prüforganisationen
- Sektoraler Aufsichtsbehörden-Bezug (BNetzA, BaFin, RKI je nach Branche)
- Eskalationspfade bei erkannten Mängeln in der Umsetzung
NIS-2 als erweiterter Anwendungsbereich
Die NIS-2-Richtlinie verlagert den Anwendungsbereich deutlich – auch Einrichtungen, die bislang nicht unter KRITIS fielen, werden zu „wesentlichen" oder „wichtigen" Einrichtungen mit analogen Pflichten. Die Umsetzung erfordert vergleichbare Strukturen wie die BSI-KritisV, mit ergänzender Risikomanagement- und Lieferketten-Verpflichtung.
Anforderungen aus NIS-2:
Risikomanagement nach Stand der Technik mit dokumentierter Bewertung
Frühe Meldepflicht innerhalb der gesetzlichen Fristen nach Sicherheitsereignis
Lieferkettensicherheit mit Bewertung relevanter Drittparteien
Geschäftsführungs-Haftung für die Umsetzung der Sicherheitsmaßnahmen
Abgrenzung zur BSI-KritisV:
- Erweiterter Anwenderkreis auch unterhalb der KRITIS-Schwellenwerte
- Strengere Meldefristen mit Erstmeldung innerhalb weniger Stunden
- Sanktionen mit deutlich höherem Bußgeldrahmen als bisher
- Geschäftsführungs-Verantwortung statt rein technischer Sicht
Firewall als zentrale Kontrollinstanz
In beiden Regelwerken ist die Firewall einer der zentralen Sicherheits-Bausteine. Netzwerksegmentierung, Zugriffskontrolle, Protokollierung und Angriffserkennung sind explizit gefordert, und die Nachweisführung gegenüber prüfenden Stellen geht über die reine Konfiguration hinaus.
Geforderte Funktionen:
Segmentierung zwischen IT- und OT-Zonen im Energie-, Wasser- und Gesundheitssektor
Dokumentierte Regelwerks-Änderungen mit Vier-Augen-Prinzip im Change-Prozess
Protokollierung sicherheitsrelevanter Ereignisse mit definierter Aufbewahrungsfrist
Angriffserkennung (IDS/IPS) mit Alarmierungspfaden und Reaktionszeiten
Geforderte Nachweise:
- Sicherheitskonzept mit dokumentierter Schutzbedarfs-Einordnung
- Regelwerks-Baseline und Versionierung als Audit-Grundlage
- Protokollauszüge zum geforderten Zeitraum mit revisionssicherer Ablage
- Incident-Übersicht und Policy-Review-Berichte des Berichtszeitraums
Warum OPNsense für KRITIS-Umgebungen
OPNsense bringt strukturelle Eigenschaften mit, die im KRITIS-Kontext gut passen – verpflichtet aber zu einer sorgfältigen Betriebsorganisation, ohne die keine Firewall-Plattform auditfähig wird. Drei Eigenschaften sind für die Auditfähigkeit besonders relevant.
Transparente Architektur und Auditierbarkeit
Die OPNsense-Konfiguration liegt in versionierbarer XML-Struktur offen vor, nicht in einer proprietären Black Box. Änderungen lassen sich in Versionskontrolle ablegen, Regelwerks-Diffs sind lesbar, Automatisierung über REST-API ist möglich.
Auditfähige Eigenschaften:
Konfiguration in lesbarer XML-Struktur mit Diff-fähiger Versionierung
Regelwerks-Historie als technischer Nachweis ohne Hersteller-Portal-Abhängigkeit
REST-API für Automatisierung mit Ansible, Terraform oder CI/CD
Strukturiertes Logging (Syslog, EVE-JSON) ohne proprietäre Collector
Audit-Vorteil im Vergleich:
- Diff-Nachweis pro Change ohne Rekonstruktion aus Hersteller-Systemen
- Vollständige Konfigurations-Rekonstruktion aus dem versionierten Repository
- Externe Auditoren lesen die Konfiguration ohne Plattform-Schulung
- Keine versteckten Telemetrie-Pfade an Hersteller außerhalb des EU-Rechtsraums
Europäische Trägerschaft und Datenresidenz
Deciso B.V. als Entwickler sitzt in den Niederlanden; die Community-Infrastruktur ist europäisch verankert. Für KRITIS-Einrichtungen mit DSGVO-Anforderungen und Datensouveränitäts-Erwartungen ist diese Herkunft ein dokumentierbares Merkmal.
Trägerschafts-Merkmale:
Entwickler-Sitz in den Niederlanden im EU-rechtlichen Rahmen
BSD-2-Clause-Lizenz für den Kern mit vollständiger Quelloffenheit
Optionale Business-Edition als kommerzielle Variante mit Hersteller-Support
Keine Cloud-Zwangsanbindung und keine obligatorische Telemetrie
Budget-Planbarkeit:
- Lizenzfreier Kern ohne jährliche Subscription-Schere kommerzieller NGFW-Produkte
- Hardware-Wahl unabhängig vom Lizenzmodell (Deciso oder qualifizierte Drittanbieter)
- Budget bleibt für SIEM-Anbindung, Monitoring und Dokumentationsaufwand verfügbar
- Kostenstruktur planbar über mehrjährige Beschaffungs- und Audit-Zyklen
Offene SIEM- und Monitoring-Schnittstellen
OPNsense integriert sich gut in SIEM-Landschaften – typische Kombinationen sind Wazuh für Host- und Netzwerk-Event-Korrelation oder Zabbix für Systemmonitoring. Syslog-Export, JSON-Logs und API-Zugriff sind nativ.
Verfügbare Schnittstellen:
Syslog-Export mit standardkonformen Formaten für beliebige SIEM-Ziele
EVE-JSON-Logs aus Suricata für strukturierte IDS/IPS-Ereignis-Korrelation
REST-API für lesenden Zugriff auf Konfiguration und Betriebsdaten
SNMP-Schnittstelle für klassisches Monitoring-Tooling
Integration in bestehende Landschaften:
- Wazuh-Anbindung für Host- und Netzwerk-Event-Korrelation
- Zabbix-Integration für Verfügbarkeits- und Performance-Monitoring
- Anbindung an Splunk, Graylog oder Elastic Stack ohne Lizenz-Zusatzkosten
- Geringes Lock-in-Risiko bei späterem SIEM-Wechsel oder -Erweiterung
Architektur und Einführung
Für KRITIS-Umgebungen wird OPNsense nicht als Einzel-Appliance aufgesetzt, sondern als Teil einer dokumentierten Sicherheitsarchitektur eingeführt. BEKOM begleitet die Einführung in drei Arbeitsblöcken.
Schutzbedarfs- und Zonen-Analyse
Ausgangspunkt ist eine Schutzbedarfs-Analyse der IT- und OT-Systeme, die über die Firewall vernetzt sind. Auf dieser Basis entsteht ein Zonenmodell mit klar definierten Übergängen und Regeln, das als Teil des Sicherheitskonzepts nach §8a BSIG festgeschrieben wird.
Analyseschritte:
Erhebung der Systeme mit Schutzbedarf (Vertraulichkeit, Integrität, Verfügbarkeit)
Identifikation der Daten- und Steuerflüsse zwischen Systemen und externen Stellen
Bewertung der Risikoexposition je Zone und Übergang
Abstimmung mit dem Informationssicherheits-Beauftragten und der Geschäftsführung
Typische Zonenmodelle:
- Energie- und Wasserversorger: Office-IT, Leitstand, Prozessnetz, Fernzugriff getrennt
- Gesundheitswesen: Medizintechnik, Verwaltungs-IT, Patientendatenzugriff getrennt
- Transportwesen: Buchungs- und Vertriebssysteme von Leit- und Stellsystemen getrennt
- Finanzdienste: Backoffice, Kundenportale und Zahlungsverkehr in getrennten Zonen
Regelwerk-Baseline und Hochverfügbarkeit
Die Firewall-Regeln werden bewusst minimal und kommentiert angelegt: Explizite Allow-Listen, aussagekräftige Alias-Benennungen, Zone-zu-Zone-Matrix als Dokumentationsgrundlage. Für kritische Übergänge werden HA-Cluster mit CARP und pfsync aufgesetzt.
Regelwerk-Aufbau:
Allow-Listen als Standard mit dokumentierter Begründung je Freigabe
Alias-basierte Regelstruktur mit lesbaren Namen statt IP-Listen im Regelblock
Zone-zu-Zone-Matrix als Übersicht für Audit und Change-Diskussion
Versionierung der Baseline mit Festschreibung als Version 1.0
Hochverfügbarkeits-Setup:
- HA-Cluster mit CARP zur Interface-IP-Übernahme zwischen Knoten
- pfsync für Zustandsabgleich aktiver Verbindungen ohne Session-Verlust
- Räumlich getrennte Aufstellung in zwei Racks oder Brandabschnitten
- Hardware-Auswahl nach Kapazitäts- und Zertifizierungsanforderungen
SIEM-Integration und Incident-Prozess
Vor Produktivgang werden Log-Strecken in das bestehende oder neu aufzubauende SIEM (Wazuh, Graylog, Splunk) eingerichtet. Alarmierungspfade und Reaktionszeiten werden mit dem Informationssicherheits-Beauftragten abgestimmt.
Integrationsschritte:
Definition der Log-Quellen (Firewall, IDS/IPS, VPN, Proxy) und Sammelpfade
Anbindung an das SIEM mit Normalisierung der Ereignis-Formate
Detektionsregeln für KRITIS-relevante Bedrohungsmuster
Aufbewahrungsfristen entsprechend sektoraler Anforderung und Compliance-Profil
Incident-Prozess-Verankerung:
- Alarmierungsketten und Eskalationspfade in Runbooks dokumentiert
- Reaktionszeiten je Severity-Klasse mit dem Beauftragten abgestimmt
- Zuständigkeits-Matrix für Erstbewertung, Triage und Meldepflicht-Reaktion
- Übergabepunkte zwischen BEKOM, internem SOC und Geschäftsführung definiert
Betrieb und Nachweisführung
Der produktive Betrieb im KRITIS-Kontext ist die eigentliche Prüfungsfläche. Regelwerk-Ownership, Change-Prozess und Dokumentationsqualität entscheiden über Auditfähigkeit. Drei Bereiche bilden den Kern der laufenden Nachweisführung.
Change-Prozess und Policy-Reviews
Jede Regelwerks-Änderung folgt einem definierten Prozess: Antrag mit Begründung, fachliche Prüfung, Vier-Augen-Freigabe, Umsetzung, Nachkontrolle. In mindestens quartalsweisem Turnus wird das Regelwerk auf Aktualität, Nutzung und Risikoprofil überprüft.
Change-Mechanik:
Antrag mit Begründung und Risiko-Einschätzung je Änderung
Fachliche Prüfung durch BEKOM-Spezialisten mit dokumentierter Stellungnahme
Vier-Augen-Freigabe nach abgestimmtem Genehmigungspfad
Umsetzung mit Nachkontrolle und Konfigurationsversion im Change-Ticket
Policy-Review-Inhalte:
- Rule-Hit-Analyse zur Identifikation ungenutzter und redundanter Regeln
- Aktualitätsprüfung gegen veränderte Bedrohungs- und Risiko-Profile
- Dokumentierter Rückbau obsoleter Regeln mit Begründung im Audit-Bericht
- Policy-Review-Bericht als Bestandteil der jährlichen §8a-Nachweise
§8a-Jahresnachweis und Audit-Bündel
Für nachweispflichtige Einrichtungen werden die firewall-relevanten Belege strukturiert vorbereitet. Das Bündel ist so aufbereitet, dass es direkt in die §8a-Dokumentation eingeht – ohne Zusammensuchen aus Hersteller-Portalen.
Bestandteile des Bündels:
Regelwerks-Baseline mit vollständiger Änderungshistorie im Berichtszeitraum
Protokollauszüge mit definierter Aufbewahrung und revisionssicherer Ablage
Rule-Hit-Analyse und Policy-Review-Berichte aus dem Berichtszeitraum
Incident-Übersicht und Dokumentation der HA-Tests
Übergabeformate:
- Konsolidierter PDF-Bericht mit nachvollziehbaren Quellverweisen
- Strukturierte Datenexporte für die Weiterverarbeitung durch den Auditor
- Maschinenlesbare Konfigurations-Snapshots zur Stichprobenprüfung
- Audit-Begleitung durch BEKOM-Fachansprechpartner während der Prüfung
Incident-Reaktion und SOC-Anbindung
Sicherheitsrelevante Ereignisse werden über IDS/IPS-Signaturen, SIEM-Korrelation und Verfügbarkeits-Monitoring erfasst. Die OPNsense-Telemetrie wird mit SOC-Analyse verknüpft, sodass Firewall-Ereignisse im Kontext weiterer Signale bewertet werden.
Detection und Reaktion:
IDS/IPS-Signaturen über Suricata mit ET-Open- und ET-Pro-Feeds
SIEM-Korrelation mit Endpoint-, Schwachstellen- und Identity-Signalen
Verfügbarkeits-Monitoring der Firewall-Knoten und HA-Strecken
False-Positive-Reduktion durch betriebsangepasste Detektionsregeln
Meldepflicht-Unterstützung:
- Erstbewertung „meldepflichtig?" durch BEKOM-Spezialisten im Playbook
- Aufbereitung von Meldungen gegenüber BSI und sektoraler Aufsicht
- Frist-Tracking innerhalb der gesetzlichen Zeitfenster (KRITIS §8b, NIS-2)
- Nachbericht und Lessons-Learned im Anschluss an das Ereignis
BEKOM-Differenzierung für KRITIS-Betrieb
Der OPNsense-KRITIS-Betrieb lässt sich auf drei Wegen organisieren: im Eigenbetrieb, über Hyperscaler-Angebote oder über einen Managed-Service-Partner. Die folgenden Gegenüberstellungen beschreiben, wie sich der BEKOM-Ansatz von diesen Alternativen abgrenzt.
Gegenüber Eigenbetrieb in der internen IT
Im Eigenbetrieb liegt die Verantwortung für 24/7-Bereitschaft, Audit-Vorbereitung und Spezialwissen vollständig beim internen Team. In KRITIS-Einrichtungen ist die Personaldecke dafür häufig knapp – besonders außerhalb der Kernzeiten und während Audit-Phasen.
Mechanik im Eigenbetrieb:
24/7-Schichtbesetzung für sicherheitsrelevante Ereignisse im eigenen Team
Audit-Vorbereitung als zusätzliche Belastung des operativen Teams
Aufbau und Erhalt von Spezialwissen für OPNsense, IDS/IPS und SIEM
Vertretungsregelung mit Risiko der Einzelkopf-Abhängigkeit
Was BEKOM stattdessen leistet:
- 24/7-Monitoring und Incident-Reaktion mit dokumentierten Reaktionszeiten
- Audit-Bündel als monatliche Standard-Lieferung statt Sonder-Projekt vor Prüfungen
- Definierte Spezialisten-Rollen für OPNsense, IDS/IPS und SIEM
- Vertretungs-Matrix über mehrere Spezialisten ohne Einzelkopf-Abhängigkeit
Gegenüber Hyperscaler-Firewall-Angeboten
Hyperscaler-Firewall-Dienste sind technisch leistungsfähig, verlagern aber Datenverarbeitung und Eskalationswege in internationale Strukturen. Für KRITIS-Einrichtungen entstehen daraus Fragen zu Datenresidenz, sektoraler Aufsicht und Sprache der Auditdokumentation.
Strukturelle Eigenschaften der Hyperscaler-Variante:
Datenverarbeitung in den Regionen des Anbieters, oft mit Cross-Border-Komponenten
Eskalationswege über internationale Support-Tiers mit Übersetzungsschleifen
Auditdokumentation häufig in englischer Sprache und Hersteller-Formaten
Bindung an proprietäre Plattform-APIs und Lizenzmodelle
BEKOM-Ansatz im Vergleich:
- Datenverarbeitung in deutschen Rechenzentren ohne Weitergabe an internationale Tiers
- Deutschsprachige Ansprechpartner für BSI-KritisV- und NIS-2-Anforderungen
- Auditdokumentation in deutscher Sprache und auf §8a-Formate ausgerichtet
- Offene OPNsense-Plattform ohne Vendor-Lock-in und mit dokumentiertem Exit-Pfad
Gegenüber klassischem Systemhaus-Modell
Klassische Systemhaus-Modelle arbeiten häufig auf Time-and-Material-Basis mit reaktiver Ticket-Bearbeitung. Für KRITIS-Einrichtungen entsteht daraus ein Risiko: weder Reaktionszeiten noch Audit-Liefergegenstände sind verbindlich geregelt.
Strukturelle Eigenschaften des Systemhaus-Modells:
Abrechnung nach Time-and-Material mit schwer planbaren Eskalationsaufwänden
Reaktive Ticket-Bearbeitung ohne durchgängiges 24/7-Monitoring
Audit-Dokumentation als Einzelprojekt vor jedem Prüftermin
Keine vertraglich zugesicherten Reaktions- und Wiederherstellungszeiten
BEKOM-Ansatz im Vergleich:
- Monatspauschale für definierten Leistungsumfang mit dokumentierten SLA
- Proaktives Monitoring und Detection statt reine Ticket-Reaktion
- Audit-Bündel als Standard-Bestandteil der monatlichen Leistung
- Service-Design-Dokument als Vertragsbestandteil, direkt audit-verwendbar
Häufige Fragen zu OPNsense in KRITIS
Erfüllt OPNsense die Anforderungen nach §8a BSIG?
OPNsense als Produkt erfüllt keine Regulierung aus sich heraus – das gilt für jede Firewall-Plattform. Die Anforderungen nach §8a BSIG beziehen sich auf die Umsetzung (Sicherheitskonzept, Segmentierung, Protokollierung, Change-Management). OPNsense bietet die technischen Bausteine, um diese Umsetzung transparent und auditfähig zu realisieren. Der Nachweis entsteht durch die Kombination aus Regelwerk, Change-Prozess, Dokumentation und SIEM-Anbindung.
Gibt es eine BSI-Zertifizierung für OPNsense, oder reicht das ohne Zertifizierung für KRITIS?
Nein, für die Community-Distribution gibt es keine formale BSI-Zertifizierung im Sinne eines Common-Criteria-Zertifikats. Für KRITIS-Einsätze ist das nicht automatisch ausschließend: Relevant ist die Umsetzung nach Stand der Technik und die Nachvollziehbarkeit der Sicherheitsmaßnahmen. Einzelne Deciso-Hardware-Plattformen haben spezifische Zertifizierungen; für KRITIS-relevante Zertifizierungsanforderungen prüft das Assessment den konkreten Bedarf und schlägt geeignete Hardware- und Architektur-Optionen vor.
Wie wird OPNsense in NIS-2-pflichtigen Einrichtungen eingeführt, und unterscheidet sich der Ansatz?
Die NIS-2-Umsetzung verlangt ähnliche Strukturen wie die BSI-KritisV: Risikomanagement, Sicherheitsmaßnahmen nach Stand der Technik, definierte Meldepflichten innerhalb gesetzlicher Fristen. Die Einführung folgt den gleichen Arbeitsblöcken (Zonen-Analyse, Regelwerk-Design, HA-Architektur, SIEM-Integration) und wird um die NIS-2-spezifischen Elemente (Risikomanagement-Dokumentation, Lieferkettensicherheit) ergänzt. Die organisatorische Einbettung variiert nach Einrichtungsgröße, Sektor und vorhandenen Compliance-Strukturen und wird im Strategiegespräch festgelegt.
Reicht OPNsense allein als KRITIS-Schutzmaßnahme, oder werden weitere Komponenten benötigt?
Nein, keine Firewall allein reicht für vollständige KRITIS-Anforderungen. Die Firewall ist ein Baustein im Gesamtsystem aus Identity-Management, Endpoint-Schutz, Patch-Management, SIEM, Backup und Incident-Response mit dokumentierten Reaktionsketten. OPNsense deckt die Netzwerk-Kontrollebene ab; ergänzende Komponenten wie Wazuh für Host-Intrusion-Detection und Zabbix für Verfügbarkeits-Monitoring werden bei Bedarf in eine kohärente Sicherheits-Architektur mit dokumentierten Schnittstellen integriert.
Welche Protokolle und Logs werden für den Audit-Nachweis geliefert, und in welcher Tiefe?
Standardmäßig werden Firewall-Logs (Allow/Deny je Regel, Quelle/Ziel mit Zeitstempel), Verbindungs-Logs der Proxies (Web-Zugriffe, Reverse-Proxy-Anfragen), VPN-Auf- und -Abbau-Events sowie IDS/IPS-Alarme produziert. Diese werden an das SIEM weitergeleitet, dort korreliert und archiviert. Aufbewahrungsfristen werden entsprechend sektoraler Anforderung und Compliance-Profil im Vertrag konfiguriert (häufig 90–180 Tage online, länger im Archiv mit revisionssicherer Speicherung).
Wie lange dauert eine OPNsense-Einführung in einer KRITIS-Umgebung typischerweise?
Die Dauer hängt stark von Zonen-Komplexität, Altsystem-Ablösung und Audit-Kalender ab. Eine überschaubare Einrichtung mit wenigen Zonen und klarer Ausgangslage kann in wenigen Wochen pilotiert und produktiv genommen werden; komplexere Mehrstandort-Landschaften mit IT-/OT-Trennung, mehreren Zertifizierungen und parallelen Audit-Zeitfenstern erstrecken sich über mehrere Monate. Das Assessment liefert einen an der Ausgangslage ausgerichteten Zeitplan, keinen pauschalen Richtwert.
Welche Rolle spielt der Informationssicherheits-Beauftragte in dem Projekt?
Der Informationssicherheits-Beauftragte ist in KRITIS-Projekten nicht nur Empfänger des Ergebnisses, sondern aktiver Mitgestalter. Er prüft die Schutzbedarfsfeststellung, bewertet das Zonenkonzept im Kontext des Sicherheitskonzepts nach §8a BSIG, begleitet den Change-Prozess und zeichnet die Policy-Review-Berichte gegen. BEKOM arbeitet mit dem Beauftragten auf Augenhöhe zusammen – entsprechende Abstimmungstermine, Dokumentationsformate und Eskalationswege sind Teil der Projektstruktur.
Kann BEKOM den laufenden OPNsense-KRITIS-Betrieb vollständig übernehmen, und wer behält die Hoheit?
Ja. Im Fully-Managed-Modell übernimmt BEKOM Change-Prozess, Patch-Management, 24/7-Monitoring, Incident-Reaktion mit dokumentierten Reaktionszeiten, SIEM-Betreuung und quartalsweise Policy-Reviews. Die strategische Sicherheitsverantwortung (Schutzbedarfsfeststellung, Freigabe von Architektur-Änderungen) bleibt bei der Einrichtung. Das Modell ist speziell für KRITIS-Einrichtungen ausgelegt, deren interne IT-Organisation die 24/7-Sicherheitsoperationen nicht selbst leisten kann oder will, mit klar geregelter Verantwortungsmatrix und definierten Eskalationsketten.
Welche Kosten entstehen bei der Umstellung von einer bestehenden KRITIS-Firewall auf OPNsense?
Die Umstellungskosten hängen primär von der Komplexität der bestehenden Regelwerke und Dokumentationstiefe ab. BEKOM führt zunächst eine KRITIS-konforme Bestandsaufnahme der aktuellen Firewall-Architektur durch, bewertet Migrationsaufwände für Regelsets und erstellt einen Überführungsplan. Die Implementierungskosten sind durch die standardisierte OPNsense-Plattform gut kalkulierbar. Parallel zur Migration wird die vollständige BSI-KritisV-Dokumentation erstellt, sodass keine separaten Compliance-Nacharbeiten entstehen.
Lässt sich der Betrieb bei Unzufriedenheit wieder in den Eigenbetrieb zurückführen?
Der Rückzug in den Eigenbetrieb ist jederzeit möglich, da OPNsense auf Standard-Hardware läuft und alle Konfigurationen vollständig portierbar sind. BEKOM übergibt bei Vertragsende die vollständige KRITIS-konforme Dokumentation, alle Konfigurationsdateien und Betriebshandbücher. Da keine proprietären Cloud-Services oder Herstellerbindungen bestehen, kann die interne IT-Organisation den Betrieb nahtlos übernehmen. Die während der Managed-Service-Phase erstellten Audit-Nachweise und Compliance-Dokumentationen bleiben vollständig verfügbar und erleichtern den Übergang.
Nächste Schritte: KRITIS-Assessment vereinbaren
Der Einstieg bildet ein Strategiegespräch zur aktuellen Firewall-Landschaft, zu den regulatorischen Anforderungen (BSI-KritisV, NIS-2, sektoral) und zur Eignung von OPNsense im konkreten Kontext. Das Gespräch ist unverbindlich und löst keine Folgeverpflichtung aus.
Das KRITIS-Assessment für OPNsense verschafft Klarheit über Compliance-Lücken in der bestehenden Firewall-Infrastruktur und liefert eine Bestandsaufnahme der BSI-KritisV- und NIS-2-Anforderungen. BEKOM erstellt eine Architektur-Empfehlung für den regulierungskonformen OPNsense-Betrieb und definiert den Betriebsumfang für alle nachweispflichtigen Sicherheitsmaßnahmen. Das Service-Design dokumentiert die für Audits erforderlichen Kontrollmechanismen und Eskalationswege.
Strategiegespräch vereinbaren
Im Strategiegespräch klären BEKOM-Spezialisten mit Informationssicherheits-Beauftragtem und IT-Leitung die Ausgangslage: sektoraler Rahmen, bestehende Sicherheitsarchitektur, Audit-Kalender und Betriebsstruktur. Das Ergebnis ist eine erste fachliche Einordnung – ergebnisoffen und ohne vorfestgelegte Plattform.
KRITIS-Assessment beauftragen
Im Assessment entstehen Schutzbedarfs-Einordnung, Zonenmodell-Vorschlag, OPNsense-Eignung im Kontext, Alternativenvergleich und Phasenplan. Der schriftliche Bericht ist unmittelbar als Grundlage für das §8a-Sicherheitskonzept verwendbar.
Einführung und Managed-Service-Betrieb begleiten
Nach Freigabe begleitet BEKOM die Umsetzung: Architektur-Implementierung, Regelwerk-Aufbau, SIEM-Integration und den Managed-Service-Betrieb mit dokumentierter Nachweisführung – bis zum nächsten Audit und darüber hinaus.