Wenn geschäftskritische Anwendungen zum Sicherheitsrisiko werden

NIS 2 verschärft die Anforderungen an die Cybersecurity vieler Unternehmen in Europa. Im Mittelpunkt stehen dabei nicht nur Firewalls, Zugriffsschutz oder Incident Response. Die Richtlinie verlangt auch Maßnahmen zur sicheren Entwicklung und Wartung von Netzwerk- und Informationssystemen.

NIS 2 betrifft zahlreiche Unternehmen und Organisationen in kritischen und wichtigen Sektoren. Während Anforderungen an Risikomanagement, Meldepflichten und organisatorische Verantwortung inzwischen breit diskutiert werden, bleibt ein Aspekt häufig im Hintergrund: die Zukunftsfähigkeit der geschäftskritischen Software selbst. 

Damit rückt eine Frage in den Mittelpunkt, die in vielen NIS-2-Projekten leicht übersehen wird:

Was passiert, wenn die geschäftskritische Software eines Unternehmens technisch so weit gealtert ist, dass sie sich kaum noch sicher warten, aktualisieren oder verändern lässt?

Denn Cyberresilienz hängt nicht nur davon ab, wie sicher eine Anwendung heute ist. Entscheidend ist auch, ob sie sich morgen noch zuverlässig an neue Schwachstellen, Technologien und Sicherheitsanforderungen anpassen lässt.

Warum Wartbarkeit zum Cybersecurity-Thema wird

Viele geschäftskritische Anwendungen sind über Jahre oder Jahrzehnte gewachsen. Sie unterstützen zentrale Prozesse, enthalten wertvolles Fachwissen und sind tief mit dem Unternehmen verbunden.

Ihr Alter allein macht sie jedoch nicht unsicher. Problematisch wird es, wenn ihre technische Basis zunehmend schwer beherrschbar wird. Typische Anzeichen sind:

• nicht mehr unterstützte Frameworks oder Bibliotheken,
• fehlende Sicherheitsupdates,
• komplexe technische Abhängigkeiten,
• unzureichende Dokumentation,
• Abhängigkeit von wenigen Spezialisten,
• hoher Testaufwand selbst bei kleinen Änderungen,
• erhebliche Risiken bei Updates oder Migrationen.

Die entscheidende Frage lautet deshalb : Können wir unsere Software auch in Zukunft noch kontrolliert warten, aktualisieren und absichern?

Je schwieriger diese Frage zu beantworten ist, desto stärker kann aus technischer Schuld ein Cybersecurity-Risiko werden.

NIS 2 betrachtet Sicherheit über den gesamten Lifecycle

Artikel 21 der NIS-2-Richtlinie nennt unter anderem Incident Management, Business Continuity, Supply-Chain-Sicherheit, Zugriffskontrolle und den Umgang mit Schwachstellen.

Explizit berücksichtigt wird dabei auch die Sicherheit beim Erwerb, bei der Entwicklung und bei der Wartung von Netzwerk- und Informationssystemen.

Damit wird Cybersecurity zu einer Lifecycle-Aufgabe.

Es reicht nicht, eine Anwendung einmal sicher zu entwickeln. Unternehmen müssen ihr Sicherheitsniveau auch dann aufrechterhalten können, wenn:

• neue Schwachstellen bekannt werden,
• Technologien ihr Supportende erreichen,
• regulatorische Anforderungen steigen,
• Schnittstellen verändert werden,
• neue Benutzer oder Systeme integriert werden.

Hinzu kommt die stärkere Verantwortung der Unternehmensleitung. Cybersecurity ist damit nicht mehr allein Aufgabe von IT- und Security-Teams, sondern Teil des unternehmerischen Risikomanagements.

Wenn jeder Security-Fix zum IT-Projekt wird

Gerade bei älteren Individualanwendungen sind Geschäftslogik und technische Implementierung häufig eng miteinander verbunden.

Ein Update eines Frameworks, eine neue Datenbankversion oder der Austausch einer technischen Komponente kann dann Auswirkungen auf große Teile der Anwendung haben.

Das führt zu einem schwierigen Zielkonflikt: Auf der einen Seite muss eine Schwachstelle möglichst schnell behoben werden. Auf der anderen Seite kann genau diese Änderung den stabilen Betrieb einer geschäftskritischen Anwendung gefährden.

Im schlimmsten Fall weiß das Unternehmen, dass eine Modernisierung notwendig wäre, schiebt sie aber immer wieder auf, weil Aufwand und Risiko kaum kalkulierbar sind.

Damit wird Modernisierbarkeit selbst zu einem Bestandteil von Cyberresilienz.

Nicht, weil NIS 2 Unternehmen grundsätzlich dazu verpflichtet, ältere Software auszutauschen. Sondern weil Sicherheitsmaßnahmen langfristig nur wirksam umgesetzt werden können, wenn die zugrunde liegenden Systeme technisch beherrschbar bleiben.

Wartbarkeit beginnt bei der Softwarearchitektur

Damit stellt sich sowohl bei neuen Anwendungen als auch bei der Modernisierung bestehender Systeme eine strategische Frage:

Wie verhindern Unternehmen, dass die moderne Anwendung von heute zur Legacy-Anwendung von morgen wird?

Eine Möglichkeit besteht darin, Geschäftslogik stärker von konkreten technischen Technologien zu entkoppeln.

Genau hier setzt modellgetriebene Entwicklung an. Statt große Teile einer Anwendung unmittelbar in einer bestimmten Programmiersprache, einem UI-Framework oder einer technischen Architektur umzusetzen, wird die Anwendung in einem zentralen Modell beschrieben.

Bei Thinkwise ist die Geschäftslogik einer Anwendung von der zugrunde liegenden Technologie entkoppelt. Mit Technology-as-a-Service (TaaS) wird die technologische Basis kontinuierlich weiterentwickelt, während Prozesse, Datenmodelle und Geschäftslogik erhalten bleiben.

Für Unternehmen bedeutet das zugleich, auch den Lifecycle der eingesetzten Entwicklungsplattform im Blick zu behalten. Entscheidend ist, ob der Plattformanbieter technologische Veränderungen aktiv mitträgt und dafür sorgt, dass Runtime- und Plattformkomponenten kontinuierlich weiterentwickelt und unterstützt werden. 

Der Vorteil: Wird eine technische Komponente ersetzt oder weiterentwickelt, muss nicht zwangsläufig auch die gesamte fachliche Anwendung neu gebaut werden.

Technologische Erneuerung kann dadurch stärker zu einem kontinuierlichen Prozess werden, statt alle paar Jahre ein neues umfangreiches Modernisierungsprojekt auszulösen.

Security by Design statt nachträglicher Absicherung

Wartbarkeit allein reicht jedoch nicht. Sicherheit sollte möglichst über den gesamten Software Development Lifecycle (SDLC) berücksichtigt werden - von Entwicklung und Tests über Release und Deployment bis zu Betrieb und Monitoring.

Strukturierte Entwicklungsprozesse helfen dabei:

• Änderungen kontrolliert umzusetzen,
• Softwarequalität systematisch zu prüfen,
• Releases nachvollziehbar zu gestalten,
• Sicherheitsanforderungen dauerhaft in die Weiterentwicklung einzubeziehen.

Thinkwise unterstützt diesen Ansatz zudem durch zentrale Funktionen für Benutzer, Rollen und Zugriffsrechte. Hinzu kommen Funktionen für Sessions, Logs und Security Checks sowie die Integration externer Authentifizierungsmechanismen wie OpenID Connect und Single Sign-on. Mehr über Sicherheit und Governance mit Thinkwise

Diese Funktionen machen ein Unternehmen jedoch nicht automatisch NIS-2-konform.

NIS 2 betrifft weit mehr als die eingesetzte Softwareplattform. Dazu gehören beispielsweise:

• unternehmensweites Risikomanagement,
• Incident Response,
• Business Continuity und Krisenmanagement,
• Lieferantenmanagement,
• Mitarbeiterschulungen,
• Verantwortlichkeiten des Managements,
• gesetzliche Meldeprozesse.

Thinkwise kann deshalb technische und softwarebezogene Maßnahmen unterstützen, die für Cyberresilienz und die sichere Weiterentwicklung geschäftskritischer Anwendungen relevant sind. Die vollständige Umsetzung von NIS 2 bleibt jedoch eine unternehmensweite Aufgabe.

Vier Fragen für CIOs und IT-Verantwortliche

Unternehmen sollten ihre geschäftskritischen Anwendungen deshalb nicht allein nach Alter oder Technologie bewerten.

Vier Fragen sind wesentlich aussagekräftiger:

1. Wie schnell können wir auf neue Sicherheitsanforderungen reagieren?
2. Wie abhängig sind wir von veralteten Technologien oder einzelnen Experten?
3. Können wir technische Komponenten erneuern, ohne die gesamte Anwendung neu entwickeln zu müssen?
4. Können wir auch in fünf oder zehn Jahren noch kontrolliert Änderungen an unserer geschäftskritischen Software vornehmen?

Wer diese Fragen heute nur eingeschränkt beantworten kann, sollte Wartbarkeit und Modernisierbarkeit stärker in die Cybersecurity-Strategie einbeziehen.

Cyberresilienz braucht modernisierbare Software

NIS 2 macht deutlich, dass Cybersecurity kein einmaliges Projekt ist.

Bedrohungen verändern sich. Technologien entwickeln sich weiter. Neue Schwachstellen entstehen. Regulatorische Anforderungen steigen.

Unternehmen müssen deshalb nicht nur in der Lage sein, ihre geschäftskritischen Anwendungen heute sicher zu betreiben. Sie müssen diese Systeme auch morgen noch verändern, aktualisieren und absichern können.

Legacy-Modernisierung ist damit mehr als ein Thema von Effizienz, Entwicklungskosten oder Benutzerfreundlichkeit.

Wenn eine geschäftskritische Anwendung nicht mehr zuverlässig gewartet oder an neue Sicherheitsanforderungen angepasst werden kann, wird ihre technische Zukunftsfähigkeit selbst zum Cybersecurity-Thema.

Für CIOs und IT-Verantwortliche sollte NIS 2 deshalb Anlass sein, neben Security Tools und organisatorischen Prozessen auch einen kritischen Blick auf die Wartbarkeit ihrer Kernanwendungen zu werfen.

Die entscheidende Frage ist nicht nur, ob die Software heute funktioniert. Sondern ob sie sich morgen noch sicher verändern lässt.