Sicherheitsoptimierung in KRITIS-Systemen

Was “Sicherheitsoptimierung” in der Praxis bedeutet

Der Begriff “Sicherheitsoptimierung” klingt abstrakt. In der Praxis, konkret in einem Projekt zur Modernisierung eines Energieinfrastruktur-Systems, bedeutet er eine Sammlung von sehr konkreten Maßnahmen: Security Code Reviews durchführen, veraltete Dependencies aktualisieren, Datenbankzugriffe absichern, Authentifizierung modernisieren und Schnittstellen konsolidieren. Keine dieser Maßnahmen ist für sich genommen revolutionär. In der Summe transformieren sie die Sicherheitslage eines Systems fundamental.

Security Code Reviews: Systematisch, nicht punktuell

Ein Security Code Review ist kein normales Code Review mit Sicherheitsfokus. Es folgt einer anderen Methodik. Statt den Code zeilenweise zu lesen, wird er entlang von Angriffsvektoren analysiert:

Typische Prüfkategorien

• Injection: SQL Injection, Command Injection, LDAP Injection. Jede Stelle, an der Benutzereingaben in Queries oder Befehle einfließen.
• Authentication/Authorization: Werden Berechtigungen korrekt geprüft? Gibt es Endpoints ohne Authentifizierung? Werden Tokens korrekt validiert?
• Kryptographie: Werden veraltete Algorithmen verwendet? Werden Geheimnisse sicher gespeichert? Werden Zufallszahlen kryptographisch sicher generiert?
• Error Handling: Werden in Fehlermeldungen interne Details preisgegeben? Stack Traces in der Produktion?
• Logging: Werden sensitive Daten geloggt? Passwörter, Tokens, persönliche Daten?

In dem Energieinfrastruktur-Projekt haben wir den gesamten Codebestand systematisch nach diesen Kategorien durchgearbeitet. Das Ergebnis war eine priorisierte Liste von Findings, klassifiziert nach Schweregrad:

Schweregrad	Anzahl	Beispiele
Kritisch	3	SQL Injection in Legacy-Modul, hartcodierte Credentials
Hoch	12	Fehlende Autorisierungsprüfungen, veraltete TLS-Konfiguration
Mittel	28	Verbose Error Messages, fehlende Input-Validierung
Niedrig	45	Code-Qualität, fehlende Security-Header

Die kritischen Findings wurden sofort behoben, die hohen innerhalb von zwei Wochen. Mittel und niedrig wurden in den regulären Sprint-Backlog aufgenommen.

3rd-Party Dependency Updates: Die unterschätzte Gefahr

Die meisten Sicherheitslücken in Enterprise-Anwendungen stammen nicht aus eigenem Code, sondern aus Abhängigkeiten. Ein Java-Projekt mit Spring Boot, Hibernate und diversen Utility-Bibliotheken hat leicht 200+ transitive Dependencies. Jede davon ist ein potenzieller Angriffsvektor.

Die Log4Shell-Schwachstelle (CVE-2021-44228) hat das eindrucksvoll demonstriert: Eine einzige verwundbare Bibliothek, transitiv in tausenden Anwendungen vorhanden, ermöglichte Remote Code Execution.

Der Update-Prozess

Ein systematischer Dependency-Update-Prozess umfasst:

1. Inventarisierung: Alle direkten und transitiven Dependencies erfassen. Tools wie mvn dependency:tree oder gradle dependencies liefern die Basis.
2. Schwachstellenscan: OWASP Dependency-Check oder Snyk gegen bekannte CVE-Datenbanken prüfen.
3. Priorisierung: Nicht jede CVE ist relevant. Eine Schwachstelle in einer Bibliothek, deren betroffene Funktion nicht genutzt wird, hat eine andere Priorität als eine, die direkt exponiert ist.
4. Update und Test: Dependency aktualisieren, automatisierte Tests ausführen, manuelle Regressionstests für kritische Pfade.
5. Dokumentation: Jedes Update wird dokumentiert, welche CVE behoben wurde, welche Version eingespielt wurde, welche Tests durchgeführt wurden.

<!-- Dependency Management: Explizite Versionen für Sicherheit -->
<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>org.apache.logging.log4j</groupId>
            <artifactId>log4j-core</artifactId>
            <version>2.17.1</version> <!-- CVE-2021-44228 behoben -->
        </dependency>
        <dependency>
            <groupId>com.fasterxml.jackson.core</groupId>
            <artifactId>jackson-databind</artifactId>
            <version>2.13.4.2</version> <!-- CVE-2022-42003 behoben -->
        </dependency>
    </dependencies>
</dependencyManagement>

In KRITIS-Systemen ist dieser Prozess nicht optional, sondern Teil der regulatorischen Anforderungen. Die Nachweispflicht erfordert eine lückenlose Dokumentation aller Dependency-Updates und der zugehörigen Sicherheitsbewertungen.

Oracle DB Hardening

Datenbanken sind ein bevorzugtes Angriffsziel. Oracle DB Hardening umfasst mehrere Ebenen:

• Least Privilege: Anwendungsbenutzer erhalten nur die minimal notwendigen Berechtigungen. Kein DBA-Zugriff für die Applikation. Separate Schemas für verschiedene Module.
• Netzwerkzugriff: Die Datenbank ist nur aus der Anwendungszone erreichbar. Kein direkter Zugriff aus dem Management-Netz oder gar dem Internet.
• Verschlüsselung: TDE (Transparent Data Encryption) für Data-at-Rest, native Network Encryption für Data-in-Transit.
• Audit: Oracle Unified Audit für die Protokollierung aller relevanten Datenbankaktionen.
• Patch Management: Quartalsweise Critical Patch Updates (CPU) von Oracle müssen zeitnah eingespielt werden.

OIDC-Integration

Die Ablösung der bestehenden Authentifizierung durch OIDC war ein zentraler Baustein der Sicherheitsoptimierung. Das bestehende System verwendete eine Eigenentwicklung auf Basis von Session-Cookies und einer proprietären Benutzerverwaltung. Die Migration auf Keycloak als Identity Provider brachte mehrere Vorteile:

• Zentrales Identity Management: Benutzer werden an einer Stelle verwaltet, nicht in jeder Anwendung separat
• Standardisierte Protokolle: OIDC und OAuth2 statt proprietärer Mechanismen
• Multi-Faktor-Authentifizierung: Keycloak unterstützt MFA out of the box, mit TOTP, WebAuthn oder SMS
• Session Management: Zentrale Session-Verwaltung mit Single Logout

Die OIDC-Integration in bestehende Anwendungen erfordert Anpassungen an der Sicherheitskonfiguration. In Spring-Boot-Anwendungen ist das dank Spring Security OAuth2 Client relativ geradlinig. Legacy-Anwendungen ohne modernes Framework erfordern mehr Aufwand, hier hat sich ein vorgelagerter Reverse Proxy mit OIDC-Unterstützung als pragmatische Lösung bewährt.

Schnittstellen-Konsolidierung

Ein oft übersehener Aspekt der Sicherheitsoptimierung ist die Konsolidierung von Schnittstellen. Das System hatte sukzessive verschiedene Integrationspunkte angesammelt: SOAP-Services, REST-APIs, File-basierter Datenaustausch, direkte Datenbankzugriffe aus Fremdsystemen. Jeder Integrationspunkt ist eine Angriffsfläche.

Die Konsolidierung folgte einem klaren Prinzip: Alle Zugriffe laufen über definierte, authentifizierte und autorisierte APIs. Direkte Datenbankzugriffe wurden durch API-Aufrufe ersetzt. File-basierter Austausch wurde durch Event-basierte Integration abgelöst. SOAP-Services wurden, wo möglich, auf REST migriert.

Das Ergebnis: Weniger Schnittstellen, die dafür besser abgesichert sind. Eine kleinere Angriffsfläche ist leichter zu verteidigen als eine große.

Fazit

Sicherheitsoptimierung in KRITIS-Systemen ist kein einmaliges Projekt, sondern ein fortlaufender Prozess. Die initiale Bestandsaufnahme durch Security Code Reviews und Dependency-Scans schafft Transparenz. Die Umsetzung der Maßnahmen, DB Hardening, OIDC-Integration, Schnittstellen-Konsolidierung, reduziert die Angriffsfläche. Entscheidend ist, dass Sicherheit nicht als separates Thema behandelt wird, sondern als integraler Bestandteil jeder architektonischen Entscheidung. In kritischer Infrastruktur ist das keine Option, sondern eine Pflicht.