Software-Lebenszyklus in KRITIS: Versionswechsel sicher planen

© sezer66

Was bedeutet Software-Lebenszyklus in KRITIS-Anwendungen?

Software-Lebenszyklus in KRITIS umfasst alle Phasen einer Anwendung – von der Anforderungsdefinition über Entwicklung und Betrieb bis zur Stilllegung – mit besonderen Pflichten zu Sicherheit, Verfügbarkeit und Nachweisbarkeit. Sicherheit muss in jeder Lebenszyklus-Phase integriert sein, das stellt die BSI TR-03185 zum sicheren Software-Lebenszyklus als zentrale technische Richtlinie heraus.

Im Vergleich zu einem klassischen IT-Lebenszyklus liegt die Messlatte deutlich höher, weil Verfügbarkeitspflichten und Audit-Anforderungen aus dem BSIG sowie sektorspezifischen B3S-Standards parallel greifen. Diese Mehrfach-Verpflichtung prägt jede einzelne Phase. Wie die operative Wechselplanung gelingt, vertieft der Abschnitt zum Versionswechsel weiter unten – dort liegt der Schwerpunkt dieses Leitfadens.

Lebenszyklus-Phasen einer KRITIS-Anwendung

Die KRITIS-Software-Phasen folgen einem anerkannten Muster: Anforderungsanalyse, Design, Entwicklung, Test, Inbetriebnahme, Betrieb, Wartung und Stilllegung. Anders als im klassischen IT-Lebenszyklus müssen alle Phasen lückenlos dokumentiert sein, weil ein Audit jederzeit prüfen kann, wie eine Software in den jeweiligen Stand kam. Der übergeordnete Leitfaden zur Softwareentwicklung für KRITIS ordnet die Phasen einem ganzheitlichen Sicherheits-Framework zu. Phasenübergänge sind die kritischen Punkte des Lebenszyklus. Genau dort entstehen Risiken, die kontrolliert werden wollen. Hier greift die IT-Compliance-Strategie und verbindet Lebenszyklus-Pflichten mit Daten- und Geheimhaltungsanforderungen. Eine besondere Rolle spielt der Übergang zwischen Betrieb und Stilllegung – dort entscheidet sich, ob ein Versionswechsel rechtzeitig kommt oder die Software in eine ungeschützte Schwebe rutscht.

Phasen im Überblick

Folgende Phasen prägen den Software-Lebenszyklus in KRITIS:

• Anforderungsanalyse mit Sicherheits- und Verfügbarkeitsvorgaben
• Architektur und Design unter Härtungsbaselines
• Entwicklung und Code-Review nach Secure-SDLC-Prinzip
• Test einschließlich Sicherheits- und Lasttests
• Inbetriebnahme mit dokumentierter Abnahme
• Betrieb mit kontinuierlichem Schwachstellenmanagement
• Wartung inklusive Versions- und Komponentenpflege
• Stilllegung mit Datenrückgabe und Audit-Schluss

Lebenszyklus-Management in KRITIS-Software

Lebenszyklus-Management in KRITIS-Software bedeutet, aus regulatorischen Pflichten ein wiederholbares Verfahren im Tagesbetrieb zu machen. Lebenszyklus-Management beginnt mit dem Inventar – also einem genauen Bild aller Komponenten, Versionen und Support-Daten in der jeweiligen Anwendung. Erst auf dieser Grundlage lässt sich entscheiden, was wann gewechselt werden muss und in welcher Reihenfolge. Ohne diese Sicht entstehen die typischen KRITIS-Risiken: ungepatchte Bibliotheken, abgelaufene Frameworks, vergessene Schnittstellen, schleichend veraltende Laufzeitumgebungen. Eine vorgeschaltete Kritikalitätsanalyse für Software priorisiert Anwendungen nach Schadenpotenzial und gibt vor, welche Komponenten zuerst inventarisiert werden. Lebenszyklus-Management ohne diese Vorarbeit läuft zwangsläufig in Listenchaos.

Wie wird das Lebenszyklus-Inventar einer KRITIS-Anwendung aufgebaut?

Das Lebenszyklus-Inventar einer KRITIS-Anwendung entsteht in vier Schritten: vollständige Komponenten-Aufnahme, Versionsstand-Erhebung, Support-Endpunkt-Recherche und Risiko-Klassifizierung. Ein vollständiges Komponenten-Inventar mit Versionsständen bildet die Grundlage. Genau diese Aufgabe übernimmt eine SBOM-Pflege für KRITIS, die Komponenten und Versionen automatisiert in einer maschinenlesbaren Stückliste pflegt. Open-Source-Bibliotheken, Frameworks, Datenbankversionen, Laufzeitumgebungen und proprietäre Module gehören gleichermaßen aufgelistet.

Daraus entsteht eine Tabelle, die Hersteller-Roadmaps, End-of-Support-Daten und CVE-Trends konsolidiert. Die Logik unterscheidet sich klar von einer Software-Ablösung in KRITIS – dort wird eine ganze Anwendung ersetzt, hier werden Komponenten innerhalb einer bestehenden Anwendung systematisch inventarisiert. Dieses Inventar bildet zugleich die Grundlage jeder belastbaren Lebenszyklus-Audit-Strategie und füttert spätere Wechsel-Entscheidungen mit Fakten statt Bauchgefühl.

Indikatoren am Wechselzeitpunkt

Folgende Signale zeigen, dass eine Komponente wechselreif wird:

• Hersteller-Roadmap mit absehbarem End-of-Life
• CVE-Trend mit zunehmender Schwachstellen-Häufung
• Versionsabstand zur aktuell unterstützten Hauptversion
• Sektor-Vorlaufzeit, die ein Audit-Fenster definiert
• Schnittstellen-Inkompatibilitäten zu Nachbarsystemen
• Personalknappheit für veraltete Technologie-Stacks
• Workaround-Kosten, die Migrationskosten übersteigen

Versionswechsel KRITIS-Software sicher planen

Versionswechsel KRITIS-Software ist die operativste Disziplin im gesamten Lebenszyklus-Management einer kritischen Anwendung. Ein Versionswechsel ist gleichzeitig die häufigste und am stärksten unterschätzte Lebenszyklus-Pflicht in vielen Sektoren – von SCADA in der Energieversorgung über Klinik-Fachverfahren bis zur kommunalen Verwaltungssoftware. Anders als bei der Komplettablösung bleibt die Anwendung im Kern bestehen, einzelne Bausteine werden gezielt erneuert. Eine durchdachte IT-Wartung in KRITIS-Umgebungen bildet dabei den Tagesbetrieb-Rahmen, in dem der Wechsel sauber landet. Drei zentrale Fragen prägen die Praxis: wann wechseln, wie viel Vorlauf einplanen, wann reicht ein Versionssprung gegenüber einer vollständigen Ablösung. Antworten auf diese drei Fragen ergeben einen belastbaren Wechsel-Fahrplan.

Wann muss eine Komponente vor dem Herstellersupport-Ende gewechselt werden?

Eine Komponente in einer KRITIS-Anwendung muss spätestens zwölf Monate vor offizieller End-of-Support-Frist in einen geplanten Wechsel überführt sein. Diese Vorlaufzeit klingt zunächst großzügig, deckt aber bei genauerem Hinsehen kaum mehr als die regulären Audit-Zyklen, Test- und Abnahmefenster sowie die Vorbereitung paralleler Fachverfahren ab. Wer früher beginnt, gewinnt Spielraum für Prüf- und Pilotphasen.

Wer zu spät startet, läuft direkt in eine Compliance-Lücke. Die Fallstudie zur Plattform für Rettungswachen zeigt, wie Versorgungs-IT mit klar definierten Lebenszyklus-Stichtagen ein Versionsupgrade trotz 24/7-Betrieb umgesetzt hat. Solche Stichtage sind das Rückgrat einer geordneten Wechselplanung im KRITIS-Umfeld und übersetzen die abstrakte BSI-Pflicht in konkrete Quartalsentscheidungen. Damit jede Wechseletappe rückwärtsabsicherbar bleibt, gehört ein erprobter Wiederanlaufplan für KRITIS-Software als Begleitdokument in den Versionswechsel.

Welche Vorlaufzeit braucht ein Versionswechsel in KRITIS-Anwendungen realistisch?

Ein Versionswechsel in KRITIS-Anwendungen braucht in der Regel sechs bis 24 Monate Vorlauf – abhängig von Sektor, Komponententiefe und Audit-Zyklus. Sechs Monate reichen für klar abgegrenzte Bibliotheks-Updates mit bestehender Test-Pipeline. Zwölf Monate sind realistisch bei Framework-Sprüngen wie Java- oder .NET-Major-Versionen. 18 bis 24 Monate werden nötig, wenn Datenbankversionen, Laufzeitumgebungen oder OS-Plattformen mitwechseln. Eine laufende Anwendungsbetreuung verkürzt diese Zeiträume spürbar, weil Vorbereitungsarbeit über das Jahr verteilt im Tagesgeschäft mitläuft. Damit wird der Versionswechsel zur planbaren Disziplin und nicht zum hektischen Krisenprojekt – ein entscheidender Unterschied gerade in regulierten Sektoren.

Wie unterscheidet sich der Versionswechsel von der vollständigen Software-Ablösung?

Der Versionswechsel erneuert einzelne Bausteine bei erhaltener Anwendungs-Architektur. Modular statt Big Bang gewinnt fast immer, weil Risiko und Aufwand kontrollierbar bleiben. Eine vollständige Software-Ablösung ersetzt die Anwendung als Ganzes – andere Architektur, anderer Hersteller, andere Datenmodelle. Der Versionswechsel KRITIS-Software ist damit das Werkzeug der Wahl, solange das funktionale Kerngerüst weiter trägt.

Wo die Architektur nicht mehr zukunftsfähig ist oder regulatorische Vorgaben nur mit Neubau erfüllbar werden, dominiert die Komplettablösung. Als allgemeines Wissensfundament zum Komplettwechsel ergänzt der Software-End-of-Life-Leitfaden den Sektor-Blick. Die Entscheidung fällt anhand der Architektur-Tragfähigkeit – nicht anhand der Versionsnummer.

Wechsel-Phasen im Sektor-Vergleich

Sektor-Vorlaufzeiten variieren stark – die nachfolgenden Werte sind Praxisrichtwerte aus laufenden KRITIS-Versionswechseln und greifen über alle Sektoren in vergleichbarer Logik:

• Energie und Wasser: 18 bis 24 Monate für SCADA-Versionswechsel
• Krankenhaus 1.3: 12 bis 18 Monate für Klinik-Fachverfahren
• Verkehr: 12 bis 18 Monate für Leit- und Steuerungssoftware
• Finanzwesen: 9 bis 15 Monate für Kernsysteme
• Verwaltung: 6 bis 12 Monate für Fachverfahren
• Telekommunikation: 9 bis 18 Monate je nach Plattform

Audit-Dokumentation im Software-Lebenszyklus

Audit-Dokumentation im Software-Lebenszyklus ist mehr als das Sammeln von Belegen kurz vor der Prüfung. Audit-Reife entsteht nicht im Audit-Jahr, sondern in jedem Quartal davor. Dokumentationspflichten greifen über alle Phasen hinweg, von der Anforderungsanalyse über jeden Versions-Stand bis zur Stilllegung. Die Anforderungen aus BSI TR-03185, BSIG und sektorspezifischen B3S-Standards überlagern sich – häufig mit eigenen Berichtsformaten je Aufsicht. Ein einheitliches Lebenszyklus-Register macht die Anforderungen erfüllbar und reduziert den Suchaufwand bei jeder Prüfungsanfrage spürbar. Ohne diese Klammer entsteht jedes Mal Hektik, wenn das Auditteam einen bestimmten Versionsbeleg verlangt. Eine konsequente Doku-Routine zahlt sich messbar aus – sowohl im regulären Audit als auch bei kurzfristigen Sonderprüfungen.

Wie wird der Lebenszyklus-Status einer KRITIS-Software für Audits dokumentiert?

Der Lebenszyklus-Status einer KRITIS-Software wird über eine Lebenszyklus-Akte als zentrale Dokumentation geführt. Sie verbindet Inventar, Versionshistorie, Wechselentscheidungen, Test- und Abnahmebelege sowie End-of-Support-Stichtage in einer einzigen, konsistenten Struktur. Die Akte ist sektorspezifisch erweiterbar und folgt dem Prinzip einer einzigen Quelle für viele Berichte. So lassen sich BSI-Nachweise, B3S-Audits und interne Compliance-Reports aus demselben Datenbestand bedienen, ohne dass parallele Dokumentationen entstehen oder sich widersprechen. Im Audit-Termin spart dieses Vorgehen Tage an Vorbereitungsaufwand und macht den Software-Lebenszyklus von KRITIS-Anwendungen objektiv prüfbar. Versionssprünge, ungeplante Migrationen und Stilllegungen werden zu kalkulierbaren Vorgängen statt zu improvisierten Krisenprojekten.

Dokumentationsbausteine der Lebenszyklus-Akte

Folgende Bausteine gehören in jede Lebenszyklus-Akte einer KRITIS-Anwendung:

• Komponenten-Inventar mit Versionsständen und Support-Daten
• Hersteller-Roadmap-Auszüge mit End-of-Support-Stichtagen
• CVE-Verlauf je Komponente und Patch-Historie
• Wechselentscheidungen mit Begründung und Audit-Spur
• Test- und Abnahmeprotokolle pro Versionssprung
• Sektor-spezifische Wirksamkeitsnachweise
• Stilllegungsprotokoll mit Datenrückgabe und Löschungsnachweis