Software-Ablösung in KRITIS: Sicher und auditfest umsetzen

© jamesteoh.art

Welche Sicherheitsanforderungen gelten bei der Software-Ablösung in KRITIS-Betrieben?

Eine Software-Ablösung in KRITIS-Betrieben folgt einem Grundsatz: Versorgungssicherheit hat Vorrang vor Liefertermin. Laut Bitkom-Studie Wirtschaftsschutz 2025 wurden 86 Prozent der KRITIS-Unternehmen binnen zwölf Monaten Opfer analoger oder digitaler Angriffe. Drei Viertel halten den Aufwand bei Cyber-Meldungen für zu hoch. Veraltete Software wird in diesem Umfeld zum Einfallstor und erschwert die Nachweisführung.

Die Softwareentwicklung für KRITIS-Betreiber muss diesen Sondermaßstab spiegeln. Audit-Bereitschaft und Hochverfügbarkeit gehören zu den Kerneigenschaften. Auch im laufenden Betrieb greifen dieselben Maßstäbe. Die IT-Wartung in KRITIS-Umgebungen folgt denselben Prinzipien. Ein Wechsel beginnt damit, beide Phasen zusammenzudenken. Ein früher Blick auf typische Stolperfallen weiter unten lohnt sich.

Versorgungssicherheit als oberstes Schutzziel

Versorgungssicherheit bedeutet, dass die kritische Dienstleistung während des gesamten Wechsels lieferfähig bleibt. KRITIS-Betreiber arbeiten deshalb mit Schattenumgebungen, redundanten Pfaden und definierten Eskalationsketten. Anders als in regulären IT-Projekten lässt sich ein Cutover nicht spontan verschieben — der zugelassene Zeitkorridor wird Wochen vorher mit Aufsicht und internen Stabsstellen abgestimmt. Die Anwendungshärtung der Nachfolgesoftware muss vor dem Wechsel abgeschlossen sein, sonst entstehen während des Übergangs neue Schwachstellen. Der Wechsel ist erst dann sicher, wenn jeder Schritt umkehrbar dokumentiert ist und jede Rolle einen klaren Vertreter hat.

Audit-Pflicht beim Wechsel

Das BSI verlangt beim Software-Wechsel eine geschlossene Nachweiskette. Jede Architekturentscheidung, jede Konfigurationsänderung und jeder Test muss revisionssicher festgehalten werden. Wer Lücken in der Dokumentation hinterlässt, riskiert Bußgelder und nachgelagerte Prüfungen. Auch Cyber-Resilienz und IT-Compliance verlangen, dass beim Wechsel keine Daten unkontrolliert in Testumgebungen wandern. Maskierte Datensätze und striktes Berechtigungsmanagement sind Pflicht — nicht Kür. Hinzu kommt eine erweiterte Meldepflicht: 24 Stunden für die Erstmeldung, 72 Stunden für den Bericht, falls während des Cutovers ein sicherheitsrelevantes Ereignis auftritt.

Software-Ablösung KRITIS in Phasen statt Big Bang

Software-Ablösung KRITIS gelingt in Phasen, niemals als Big Bang. Die Erfahrung aus regulierten Umgebungen zeigt: Je größer der Schritt, desto schwieriger der Rollback. Sinnvoll sind eng abgegrenzte Funktionsbereiche, die einzeln umgezogen werden, während Altsystem und Nachfolger zeitweise parallel laufen. Eine Cloud-Migration folgt denselben Prinzipien — sie ergänzt das Phasenmodell um eine zweite Achse. Wer beide Aspekte strukturiert plant, reduziert die Angriffsfläche während des Übergangs spürbar. Phasenmodelle dauern länger als Big-Bang-Pläne, dafür sind sie audit-tauglich. Verbindliche Vorgaben aus dem NIS-2-Kontext für KRITIS gehören dabei früh in die Planung.

Welche Cutover-Strategien eignen sich für KRITIS-Software?

Drei Cutover-Strategien dominieren in KRITIS-Projekten:

• Strangler-Pattern: Die Altanwendung wird Schritt für Schritt eingehüllt, neue Funktionen entstehen daneben, alte werden nach und nach abgelöst.
• Parallelbetrieb mit Schattenumgebung: Das neue System läuft produktiv, das alte bleibt im Hot-Stand-by als belastbare Rückfallebene.
• Blue-Green-Deployment: Geeignet für stark standardisierte Prozesse mit klaren Schnittstellen und kurzen Umschaltfenstern.
• Phasen-Migration mit Stichtagsumzug pro Modul: Bewährt bei stark vernetzten Fachverfahren, wenn ein vollständiger Parallelbetrieb zu teuer wird.

Die Wahl hängt vom Datenstrom, Risikoprofil und Redundanz ab. Allen Mustern ist gemein: Sie verlangen funktionsfähige Rollback-Pfade. Ohne Rückweg ist eine Software-Ablösung in KRITIS nicht abnahmefähig. Ergänzend gilt: Cybersecurity-Standards wie OWASP ASVS und CIS Benchmarks sind keine Kür, sondern Grundvoraussetzung. In der Praxis bewähren sich Mischformen aus Strangler-Pattern und Blue-Green.

KRITIS-Software ersetzen mit Parallelbetrieb

KRITIS-Software ersetzen ohne Versorgungslücke gelingt am häufigsten über einen kontrollierten Parallelbetrieb. Die Nachfolgeanwendung wird zunächst im Schattenbetrieb gespiegelt: gleiche Eingaben, gleiche Datenbasis, aber kein Schreibzugriff auf den Echtbetrieb. Erst wenn die Ergebnisse über mehrere Wochen identisch sind, wird die Steuerlast schrittweise umgelegt. So wird die Legacy-Software KRITIS Modul für Modul abgelöst, ohne dass interne oder externe Stakeholder einen Bruch bemerken. Wer KRITIS-Software ersetzen möchte, plant für den Parallelbetrieb realistisch zwei bis sechs Monate ein. Die genaue Dauer hängt vom Reifegrad der Schattenumgebung und der Komplexität der Schnittstellen ab.

Legacy-Software KRITIS dokumentationssicher modernisieren

Legacy-Software KRITIS bringt zwei Probleme gleichzeitig: technisches Risiko und Compliance-Risiko. Veraltete Software in KRITIS-Sektoren ist häufig schlecht dokumentiert, abhängig von einzelnen Personen und ohne Build-Pipeline reproduzierbar. Genau das macht den Wechsel kritisch — und gleichzeitig dringend. Wer ein Altsystem im KRITIS-Umfeld modernisiert, braucht eine Inventarisierung aller Schnittstellen und Datenflüsse. Eine vorgeschaltete Kritikalitätsanalyse klärt zugleich, ob das Altsystem überhaupt eine Ablösung wert ist oder ob ein Pflegerahmen reicht. Erst danach lässt sich ein Migrationsplan aufstellen, der den BSI-Anforderungen genügt. Eine saubere Dokumentation des Nachfolgers ist Voraussetzung für jeden späteren Audit-Termin. Wer hier improvisiert, zahlt am Ende mit Bußgeldern und Mehrarbeit.

Welche BSI-Nachweise sind bei einer Software-Ablösung zu erbringen?

Beim Wechsel verlangt das BSI eine geschlossene Beweiskette über drei Phasen: vor dem Cutover, während der Übergabe und danach im Regelbetrieb. Dazu gehören eine Risikoanalyse mit Allgefahrenansatz, dokumentierte Testpläne, ein freigegebener Notfallplan und ein nachgehaltetes Change-Log. Ergänzend wird die Nachfolgesoftware gegen die einschlägigen Bedrohungsmodelle abgesichert — Stichworte sind OWASP ASVS und CIS Benchmarks. Wer eine Software-Ablösung in KRITIS auditfest dokumentiert, sollte folgende Bausteine bereithalten:

• Risiko- und Schutzbedarfsanalyse für Alt- und Nachfolgesystem
• Migrations- und Rollback-Plan mit Stichtagen
• Testprotokolle aus Schatten- und Schwellbetrieb
• Härtungsnachweise inklusive Konfigurations-Baselines
• Change-Records aller Cutover-Schritte
• Erst- und Folgemeldung im Vorfallsfall
• Übergabeprotokoll an den Regelbetrieb

KRITIS-Software ersetzen unter Branchenrecht

KRITIS-Software ersetzen heißt unter B3S immer auch: branchenspezifische Vorgaben einhalten. In der Energiewirtschaft gelten andere Sicherheitskataloge als im Gesundheitswesen oder in der Wasserversorgung. Die jeweils aktuelle B3S-Version bestimmt, welche Schutzziele die Nachfolgesoftware abbilden muss. Wer eine KRITIS-Software austauschen möchte, prüft deshalb früh im Projekt: Welcher B3S ist anwendbar, welche Lücken zeigt der Bestand, welche Nachweise verlangt der nächste Audit? Eine Software-Ablösung KRITIS-konform aufzusetzen bedeutet, B3S-Schutzziele in Akzeptanzkriterien zu übersetzen und sie messbar prüfbar zu machen. Das vermeidet späte Eskalationen mit der Aufsicht.

Dienstleister-Auswahl und häufige Stolperfallen

Die Auswahl eines Dienstleisters für eine Software-Ablösung KRITIS entscheidet stark über das Projektergebnis. Reine Entwickler-Erfahrung reicht nicht — gefragt sind Audit-Routine, ISO-27001-zertifizierte Prozesse und ein realistischer Umgang mit regulatorischen Schnittstellen. Häufige Stolperfallen entstehen, wenn ein Anbieter zwar gute Software baut, aber bei Nachweisen, B3S-Branchenrecht oder Versorgungssicherheit improvisiert.

Der Markt bietet hier ein breites Spektrum, doch nur ein kleinerer Teil ist dauerhaft KRITIS-tauglich. Wer den Wechsel aufsetzt, sollte die Auswahlkriterien früh schriftlich fixieren. Eine kurze Marktanalyse mit drei bis fünf Anbietern hilft, Erwartungen und Preise realistisch einzuschätzen. Belastbare Referenzen aus regulierten Branchen sind wichtiger als Hochglanz-Folien.

Welche Rolle spielt B3S-Konformität beim Software-Wechsel in KRITIS-Sektoren?

B3S-Konformität ist beim Software-Wechsel in KRITIS-Sektoren der direkteste Weg, dem BSI Stand der Technik nachzuweisen. Branchenverbände erarbeiten B3S, das BSI prüft und gibt sie frei. Wer eine Software-Migration in KRITIS aufsetzt, deren Nachfolger einen anerkannten B3S spiegelt, verkürzt die Audit-Diskussion erheblich. Konkret heißt das: Sicherheitsmaßnahmen werden nicht mehr individuell verteidigt, sondern entlang einer akzeptierten Vorlage geprüft. Folgende Aspekte sollten KRITIS-Betreiber beim Auswahl-Check des Dienstleisters mitbringen:

• Erfahrung mit dem konkreten B3S der Branche (Energie, Gesundheit, Wasser, IT/TK)
• Nachweisbare Audit-Begleitung in vergleichbaren Vorhaben
• ISO-27001-Zertifikat mit passendem Geltungsbereich
• Pflege-Vertrag inklusive 24-/72-Stunden-Meldekette
• Klares Eskalationskonzept im Cutover-Fenster

Häufigste Fehler in KRITIS-Ablösungsprojekten

Aus zahlreichen Projekten lassen sich wiederkehrende Fehlmuster ablesen. Die Erkenntnisse aus klassischen Studien zur Software-Ablösung in KRITIS-konformer Umsetzung zeigen: Die fünf gefährlichsten Stolperfallen wiederholen sich Branche für Branche.

• Vertrauen auf Dokumentation statt auf den realen Code-Stand
• Big-Bang-Cutover statt Phasen mit Rollback-Pfad
• Unterschätzte Anwender-Akzeptanz und fehlendes Change-Management
• Lieferketten- und Subdienstleister-Risiken im neuen Stack ungeprüft
• Audit-Nachweise erst nach Go-live nachgereicht
• Keine produktionsnahen Lasttests vor dem Cutover

Wer diese Punkte früh adressiert, reduziert die typischen Eskalationen mit Aufsicht und Geschäftsführung. Rückblickend sind es selten technische Probleme, die ein Projekt kippen, sondern schwache Vorbereitung in Dokumentation, Auswahl und Kommunikation. Wer früh strukturiert vorgeht, sichert die Versorgung und das Vertrauen der Aufsicht.