Der harte Grund für NIS2-Zögerer: Technische Schulden

Technische Schulden sind im NIS2-Kontext besonders wichtig, weil sie erklären, warum Unternehmen trotz erkennbarer Risiken nicht einfach „schnell sicherer“ werden können.

Was sind Sicherheitsschulden?

Gemeint ist der aufgelaufene Mehraufwand aus früheren Abkürzungen, nicht getroffenen Architekturentscheidungen, veralteten Systemen und verschobenen oder minimierten Sicherheitsmaßnahmen. Technische Schulden erhöhen langfristig Kosten, Komplexität und Ausfallrisiken.

Technische Schulden entstehen beispielsweise, wenn ein Unternehmen eine Anwendung schnell produktiv setzt, Dokumentation und Tests aber später nachholen will. Werden diese Aufgaben dauerhaft verschoben, entstehen daraus unter anderem:

• Sicherheitsschulden: ungepatchte Schwachstellen, fehlende MFA, schwache Berechtigungen.

• Architekturschulden: veraltete oder monolithische Systeme, fehlende Segmentierung, unsichere Schnittstellen.

• Infrastrukturschulden: manuelle Konfigurationen, unübersichtliche Cloud-Ressourcen, nicht verwaltete Endgeräte.

• Dokumentationsschulden: unbekannte Abhängigkeiten, unvollständige Asset-Listen und veraltete Notfallpläne.

• Testschulden: fehlende Schwachstellenanalysen, Penetrationstests, Wiederanlauf- und Krisenübungen.

• Prozessschulden: unklare Verantwortlichkeiten, fehlende Eskalationswege und nicht automatisierte Kontrollen.

Der Begriff „Schuld“ ist dabei eine Metapher: Eine technische Abkürzung kann zunächst wirtschaftlich sinnvoll sein. Problematisch wird sie erst, wenn sie nicht bewusst dokumentiert, bewertet und später abgebaut wird.

Wie entstehen diese Schulden?

Das ist nicht unbedingt Unwissenheit oder böser Wille und das Umfeld ist nicht immer optimal, aber typische Ursachen sind:

• Zeitdruck: Eine Anwendung muss vor dem nächsten Geschäftstermin live gehen. Man weiß aber, dass dies nicht ideal ist und Folgemaßnahmen gehen im Tagesgeschäft unter.

• Budgetentscheidungen: Ersatz, Segmentierung oder Modernisierung werden immer wieder verschoben.

• M&A und Wachstum: Neue Standorte und Systeme werden integriert, ohne die Architektur zu harmonisieren, "schnell" geht vor "richtig".

• Legacy-Abhängigkeiten: Alte Systeme sind geschäftskritisch, kaum dokumentiert und nicht ohne Weiteres ersetzbar, die Ablösung wird verschoben.

• Falsches Vertrauen auf erfahrene Mitarbeiter: Diese halten heute den Betrieb in Gang, können mit den Altsystemen umgehen, scheiden aber nach und nach aus dem Unternehmen aus.

• Verantwortungslücken: Niemand fühlt sich dauerhaft für Systeme, Schnittstellen oder Sicherheitsmaßnahmen verantwortlich.

• Fehlende Lebenszyklusplanung: Systeme werden eingeführt, aber Stilllegung, Migration und sichere Ablösung werden nicht eingeplant.

Besonders gefährlich sind „temporäre“ Lösungen, die über Jahre bestehen bleiben: ein gemeinsam genutztes Administratorkonto, ein dauerhaft offener Fernwartungszugang, ein nicht segmentiertes Produktionsnetz oder ein ungetestetes Backup.

Häufig anzutreffen ist ein Provisorium, das bekanntlich lange lebt......

Warum NIS2 das Problem verschärft sichtbar macht

NIS2 verlangt (außer MFA) keine konkreten einzelnen technischen Maßnahmen, sondern ein systematisches Risikomanagement, angemessene Sicherheitsmaßnahmen, Incident-Management, Business Continuity, Lieferkettensicherheit und Verantwortlichkeit der Leitung. Dadurch reicht es nicht mehr aus, einzelne Systeme punktuell zu sichern.

Man muß das gesamte System betrachten und das kann aufwendig werden. Denn "Technische Schulden" werden damit zu einem Governance-Problem:

• Ohne vollständiges Asset-Inventar ist keine belastbare Risikoanalyse möglich.

• Ohne Systemverantwortliche lassen sich Risiken nicht wirksam behandeln.

• Ohne aktuelle Abhängigkeiten ist die Auswirkung eines Ausfalls schwer bewertbar.

• Ohne getestete Wiederanlaufverfahren ist Business Continuity nur eine Annahme.

• Ohne Nachweise kann das Unternehmen die Wirksamkeit seiner Maßnahmen nicht belegen.

NIS2 erzeugt die technischen Schulden nicht. Die Richtlinie macht lediglich sichtbar, dass viele Organisationen ihre Sicherheitsarchitektur über Jahre aufgeschoben haben. In diesem Sinne wirkt NIS2 wie ein "Tilgungsplan für aufgelaufene Cyber-Risiken".

Ein Beispiel

Ein Produktionsunternehmen betreibt eine alte Steuerungsanwendung. Sie läuft stabil, unterstützt aber keine moderne Authentisierung. Der Austausch wurde mehrfach verschoben, weil ein Produktionsstillstand teuer wäre.

Die unmittelbare technische Schuld besteht in der veralteten Authentisierung. Daraus entstehen weitere Schulden:

• privilegierte Konten werden nicht ausreichend geschützt;

• der Zugriff wird möglicherweise über gemeinsam genutzte Konten organisiert;

• die Anwendung kann nicht vollständig in moderne Identity-Prozesse integriert werden;

• Logging und Monitoring sind lückenhaft;

• ein Sicherheitsvorfall lässt sich nur schwer rekonstruieren;

• die Wiederherstellung nach einem Ausfall ist nicht ausreichend getestet.

Ein einzelnes Legacy-System erzeugt dadurch Auswirkungen auf Zugriffsschutz, Incident Response, Nachweisfähigkeit, Business Continuity und Lieferfähigkeit.

Warum Unternehmen die Schulden nicht einfach abbauen

Der Abbau ist schwierig, weil technische Schulden häufig miteinander verkettet sind.

• MFA lässt sich nicht einführen, wenn alte Anwendungen keine modernen Authentisierungsverfahren unterstützen.

• Segmentierung funktioniert nicht ohne aktuelle Kommunikationsbeziehungen.

• Patchen ist riskant, wenn Testumgebung und Testprozesse fehlen.

• Ein Asset-Inventar bleibt unvollständig, wenn niemand die Eigentümerschaft für Systeme übernimmt.

Daher führt NIS2 bei manchen Unternehmen zunächst nicht zu schnellen Verbesserungen, sondern zu einer unangenehmen 'Erkenntnis nach der Bestandsaufnahme: Die Organisation erkennt gleichzeitig viele Baustellen, hat aber nicht genug Personal, Budget und Wartungsfenster, um alle zu bearbeiten.

Technische Schulden wurden in der Vergangenheit oft unsichtbar bilanziert; jetzt werden sie als Sicherheits- und Haftungsrisiko sichtbar.

Fachliche Schlussfolgerung

Technische Schulden sind nicht automatisch ein Zeichen schlechter Arbeit. In einem dynamischen Geschäft können bewusste Kompromisse notwendig sein. Unprofessionell wird es, wenn die Organisation irgendwann nicht mehr weiß, welche Schulden bestehen, wem sie gehören, welches Risiko daraus entsteht und wann sie auf welche Art und Weise abgebaut werden sollen.

Dann schiebt man oft einen Berg an Aufgaben vor sich her, den man lieber nicht gar nicht erst angehen will, weil man weiß, daß es viel Arbeit ist und weil dann auch die Fehler der Vergangenheit deutlich werden, zu denen man situativ gezwungen war oder die man ggf. selbst begangen hat.

Man muss also mit Augenmaß handeln, für NIS2 ist es deshalb ein unrealistisches Ziel, eine „schuldenfreie“ IT zu versprechen.

Glaubwürdig ist ein risikobasierter Ansatz, dass die Organisation ihre technischen und sicherheitsbezogenen Schulden kennt, priorisiert, kompensiert und mit einem verbindlichen "Tilgungsplan" reduziert, also alles nötige tut, um NIS2 angemessen und risikoorientiert umzusetzen.