Plattform-Automatisierung für Versicherungen
Das Versicherungsportal lief 7 Jahre ohne Unterbrechung. TLS 1.1 noch aktiv. Application Pools auf einem einzigen Service-Account. Das war nicht Nachlässigkeit, das war die Standard-IIS-Konfiguration. Windows-Umgebungen in Versicherungen sind selten absichtlich unsicher. Sie sind so, wie IIS ausgeliefert wird, und so bleiben sie, solange nichts bricht.
Was Versicherungs-IT tatsächlich bedeutet
Versicherungen betreiben typischerweise eine dichte Windows-Server-Landschaft: Broker-Portale für Vertriebspartner, Schaden-Management-Systeme, Kunden-Self-Service-Portale und Dokumenten-Management-Lösungen. IIS ist der Standard-Webserver. Nicht weil er explizit evaluiert und gewählt wurde, sondern weil er mit Windows Server kommt und funktioniert.
Das Betriebsmodell ist charakteristisch für die Branche: Ein kleines Team verwaltet Dutzende von Servern. Konfiguration entsteht manuell, auf dem ersten Server, der irgendwann funktionierte, und wird dann kopiert. Härtung findet nicht statt, weil alles läuft und niemand Zeit hat, anzufassen, was keinen Fehler zeigt. Jahre später ist das der Ausgangszustand für einen NIS2-Audit.
In manchen Versicherungen laufen neben IIS auch JBoss EAP oder andere Java-Middleware-Stacks für Kernberechnungen und Produktkataloge. Diese Systeme haben ihre eigene Komplexität, aber das primäre Prüfungsszenario beginnt beim IIS-Frontend, weil das die öffentlich erreichbare Angriffsfläche ist.
Windows Server / IIS, Vertriebspartner-Zugang, Tarifrechner, Antragsstrecken
Interne Anwendung, oft ältere IIS-Version, hoher Datenschutz-Scope
Kunden-facing, TLS-Konfiguration öffentlich prüfbar, PCI-DSS-Scope möglich
DMS-Systeme, App-Pool-Isolation relevant, Zugangskontrolle unter Audit-Druck
Was PCI-DSS, NIS2 und ISO in Versicherungs-IT finden
Diese Befunde tauchen in Prüfungen von Versicherungsunternehmen regelmäßig auf. Keiner davon ist Ergebnis eines Angriffs oder einer Fehlbedienung. Es ist die Standardkonfiguration, die niemand verändert hat.
TLS-Konfiguration
TLS 1.0 und 1.1 noch aktiv. Kein Browser bricht ab. Kein Fehler erscheint. Aber PCI-DSS 4.0 erfordert TLS 1.2 als Minimum. Es ist ein Registry-Key unter HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL, der nie explizit auf Disabled gesetzt wurde.
Security-Header-Vakuum
IIS liefert keine Security-Header. X-Frame-Options fehlt. HSTS fehlt. Content-Security-Policy fehlt. Das ist kein Administrationsfehler, das ist der IIS-Installationsstandard. Alle Header müssen explizit via web.config gesetzt werden. Sie werden es selten.
App-Pool-Wildwuchs
20 Application Pools, ein Service-Account. PCI-DSS erfordert Isolation: jede Anwendung braucht eine eigene Account-Identity. Im Wildwuchs-Betrieb hat ein kompromittiertes Verzeichnis Zugriff auf alle Anwendungen unter demselben Account.
Request-Filtering
HTTP-Methoden TRACE und DEBUG sind aktiv. Request-Filtering ist nicht konfiguriert. Nicht weil jemand das absichtlich so gelassen hat, sondern weil es nie konfiguriert werden musste. Für Auditoren ist es ein eigenständiger Befund.
Welche Anforderungen für Versicherungen gelten
NIS2-Richtlinie
Versicherungen fallen als wesentliche Einrichtungen unter die NIS2-Richtlinie. Article 21 fordert technische Sicherheitsmaßnahmen, Meldepflichten innerhalb von 24 Stunden bei erheblichen Sicherheitsvorfällen und nachweisbare Incident-Response-Fähigkeiten. Technische Maßnahmen müssen dokumentiert und prüfbar sein.
ISO 27001 Annex A
Technische Sicherheitsmaßnahmen, Zugangskontrolle, Konfigurationsmanagement: Annex A liefert konkrete Kontrollziele, die auf Windows-Server- und IIS-Härtung direkt anwendbar sind. Ohne dokumentierten Konfigurationsstand keine nachweisbare Konformität gegenüber Zertifizierern und internen Revisoren.
CIS Windows Benchmark
Level 1 und Level 2 für Windows Server liefern konkrete Härtungsvorgaben, die IIS-Portale in Versicherungen direkt abdecken. Registry-Keys, Security-Policies, Update-Management: definierte Baseline statt individueller Interpretation. CIS Benchmarks sind anerkannte Referenz für Auditoren.
PCI-DSS (Zahlungsverarbeitung)
Soweit Versicherungen Zahlungsverarbeitung betreiben, gelten TLS-Mindeststandards, Netzwerksegmentierung und Zugangskontrolle nach PCI-DSS. Version 4.0 macht TLS 1.2 als Mindestprotokoll verbindlich. SchChannel-Registry-Konfiguration ist der technische Hebel dafür.
VAIT (BaFin)
Die Versicherungsaufsichtlichen Anforderungen an die IT verlangen Härtung, Dokumentation und Änderungskontrolle, analog zu BAIT für Banken. Konfigurationsstand muss nachvollziehbar und auditierbar vorliegen. Funktioniert ist nicht dasselbe wie dokumentiert gehärtet.
Was lennlay für Versicherungen liefert
Windows-Härtung nach CIS
CIS Windows Benchmark als definierte Baseline. Registry-Keys, Security-Policies, Update-Management automatisiert und reproduzierbar umgesetzt. Benjamin Strebel (RHCE, Windows-Spezialist, Vollzeit) bringt das Fachwissen für Windows-Härtungsprojekte in Versicherungsumgebungen.
IIS-Konfigurationsstandard
TLS-Protokolle via SchChannel, Security-Header via web.config, App-Pool-Isolation, Request-Filtering: als auditierbare Policy, nicht als manuelle Checkliste. Jede Instanz im definierten Sollzustand, nicht im historisch gewachsenen.
Automatisierter Compliance-Scan
PowerShell-basierter Scanner prüft Windows und IIS gegen definierte Policies. Strukturierter Report mit Befunden, Schweregrad und Remediation-Hinweisen. Auditoren erhalten lesbare Evidenz, keinen rohen Registry-Export.
Änderungshistorie als Nachweis
Konfiguration als Code. Jede Änderung ist ein dokumentierter Change mit Timestamp, Author und Begründung. Kein manuell gepflegtes Änderungsprotokoll, das beim nächsten Teamwechsel veraltet ist.
Lifecycle-Management
Windows Server 2012, 2016, 2019: EOL-Status, Patch-Stand, Support-Ende strukturiert erfasst. Kein reaktiver Betrieb wenn ein Server das Patch-Datum überschreitet, sondern ein geplanter Migrationspfad inklusive Härtungsstandard für die neue Plattform.
EaaS für die Umsetzung
Engineering as a Service mit Benjamin Strebel (RHCE, Windows-Spezialist, Vollzeit) für Härtungsprojekte, die heute starten müssen. Ansible for Windows, PowerShell DSC, IIS-Härtung, App-Pool-Isolation, TLS-Konfiguration direkt im Kundensystem.
Die Secure Windows Platform Automation und Secure IIS Platform Automation befinden sich in der Konzeptphase. Eine Lieferzusage gibt es noch nicht. So wird der Einsatz aussehen, wenn er verfügbar ist. Über EaaS mit Benjamin Strebel stehen Windows- und IIS-Härtungsprojekte heute zur Verfügung. Sprechen Sie uns an.
Drei Situationen, in denen das relevant wird
NIS2-Readiness
Das NIS2UmsuCG gilt. Die Versicherung ist als wesentliche Einrichtung eingestuft. Technische Maßnahmen nach Article 21 müssen nachweisbar sein. Portale und Broker-Systeme stehen unter Prüfungsdruck, ohne dass ein definierter Konfigurationsstandard existiert.
IIS-Audit-Befunde
Ein externer Pentest oder eine interne Revision legt TLS-Konfigurationsmängel, fehlende Security-Header oder App-Pool-Probleme frei. Remediation ist gefordert. Die Herausforderung: kein Konfigurationsstandard, kein definierter Sollzustand, kein reproduzierbarer Prozess für die Umsetzung.
Windows Server EOL
Windows Server 2012 R2 hat seinen End-of-Life im Oktober 2023 erreicht. Noch aktive Server im Netz. Ein Migrationspfad ist nötig, inklusive Härtungsstandard für die neue Plattform. Migration ohne Härtungsstandard reproduziert dasselbe Problem auf neuer Hardware.
Versicherungsportale unter Audit-Druck? Wir können einordnen, was in SchChannel, web.config und App-Pool-Konfiguration tatsächlich steht.
Unverbindlich · Keine Verkaufsveranstaltung · Vertraulich
