Euer IIS-Server verhandelt noch TLS 1.1. Wann wurde das zuletzt geprüft?
IIS konfiguriert TLS nicht per Konfig-Datei, sondern über Registry-Keys unter HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL. Diese Keys werden selten dokumentiert, selten geprüft und oft nie explizit gesetzt. Kein Browser bricht, keine Fehlermeldung erscheint, aber der PCI-DSS-Prüfer oder NIS2-Auditor findet es.
Was Auditoren in Standard-IIS-Umgebungen finden
Diese Schwachstellen tauchen in PCI-DSS- und NIS2-Audits regelmäßig auf. Keiner davon braucht einen Exploit. Es reicht, dass niemand die TLS-Konfiguration in den letzten drei Jahren angefasst hat.
SchChannel-Registry-Keys für TLS 1.0 und TLS 1.1 sind nicht auf Disabled gesetzt. Verbindungen kommen zustande. Kein Browser zeigt eine Fehlermeldung. PCI-DSS verlangt mindestens TLS 1.2.
RC4, 3DES und NULL-Cipher sind im Windows-Standard nicht deaktiviert. Cipher-Suite-Reihenfolge per GPO oder Registry fehlt in den meisten Umgebungen vollständig.
X-Powered-By: ASP.NET und Server: Microsoft-IIS/10.0 stehen standardmäßig in jeder HTTP-Response. Version-Disclosure ist ein eigenständiger Audit-Befund.
X-Frame-Options, X-Content-Type-Options, Strict-Transport-Security und Content-Security-Policy sind in der IIS-Standardkonfiguration nicht vorhanden. Keine davon wird automatisch gesetzt.
Mehrere Anwendungen laufen unter derselben App-Pool-Identity oder Service-Account. Ein kompromittiertes Anwendungsverzeichnis hat Zugriff auf alle anderen unter demselben Account.
HTTP-Methoden wie TRACE und CONNECT sind nicht eingeschränkt. URL-Längen, Dateiendungen und doppelt kodierte Requests werden nicht gefiltert.
Directory-Browsing ist in vielen IIS-Instanzen standardmäßig aktiv und wurde nie explizit deaktiviert. Verzeichnislistings sind kein Feature, das nach außen stehen sollte.
HTTP TRACE ist per Default aktiv und ermöglicht Cross-Site-Tracing-Angriffe. Ein einzelner web.config-Eintrag oder Request-Filter schließt das. Er wird selten gesetzt.
Warum IIS anders ist als Apache oder Nginx
Der entscheidende Unterschied liegt nicht im Feature-Set, sondern im Konfigurationsmodell für TLS. Das hat direkte Konsequenzen dafür, warum Legacy-Protokolle so lange unbemerkt aktiv bleiben.
TLS-Protokolle und Cipher-Suites stehen in einer Textdatei. Ein Paket-Update kann neue sicherere Defaults setzen. Änderungen sind diffbar, versionierbar, und der Konfigurationsstand ist ohne Systemzugriff lesbar.
SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1 SSLCipherSuite HIGH:!RC4:!3DES:!NULL
TLS-Konfiguration liegt im SchChannel-Registry-Hive. Kein Paket-Update setzt diese Keys automatisch. Wer sie nicht explizit setzt, hat Legacy-Protokolle aktiv. Der Zustand ist nur aus der Registry lesbar, nicht aus Logs oder Konfig-Files.
HKLM\...\SCHANNEL\Protocols\TLS 1.0\Server Enabled = 0x00000000 DisabledByDefault = 0x00000001
Dasselbe Muster gilt für Cipher-Suite-Reihenfolge (GPO oder Registry), Security-Header (web.config oder IIS-Manager) und App-Pool-Identities (IIS-Konfiguration, kein Betriebssystem-Paket). Alles IIS-spezifisch, alles muss explizit gesetzt werden, nichts kommt durch ein Update.
Was dieses Modul adressieren wird
Vier technische Bereiche, die in gewachsenen IIS-Umgebungen konsistent offen sind und die dieses Modul als automatisierten, dokumentierten Sollzustand abdecken wird.
TLS und Cipher Hardening
SchChannel-Registry-Keys für TLS 1.0, 1.1, 1.2 und 1.3 explizit konfiguriert. Cipher-Suite-Reihenfolge per GPO oder Registry gesetzt. RC4, 3DES und NULL-Cipher deaktiviert. Dokumentierter Konfigurationsstand als Nachweis für PCI-DSS-Anforderungen an TLS-Mindeststandard.
Security-Header via web.config
Strict-Transport-Security, Content-Security-Policy, X-Frame-Options, X-Content-Type-Options und Referrer-Policy als versionierter web.config-Standard. Server-Version aus Response-Headers entfernt. Konsistent über alle IIS-Sites, kein manueller Eingriff pro Instanz.
App-Pool-Isolation
Jede Anwendung bekommt eine dedizierte App-Pool-Identity. Zugriffstrennung auf Betriebssystemebene. App-Pool-Konfiguration als versionierter Sollzustand, nicht als manuell gewachsene Struktur ohne Übersicht über Berechtigungen und Abhängigkeiten.
Request-Filtering und HTTP-Methoden
Erlaubte HTTP-Methoden auf GET, POST und HEAD eingeschränkt. TRACE blockiert. URL-Längen begrenzt. Dateiendungen gefiltert. Directory-Browsing deaktiviert. Request-Filtering als deklarativer Konfigurationsstand mit Compliance-Nachweis.
IIS-Härtung setzt OS-Härtung voraus
IIS ist keine eigenständige Plattform. Es läuft auf Windows, wird durch Windows-Mechanismen konfiguriert (Registry, GPO, Active Directory) und seine Sicherheit hängt direkt von der darunterliegenden OS-Basis ab.
Ein sorgfältig konfiguriertes IIS auf einem ungepflegten Windows Server schließt nur einen Teil der Angriffsfläche. Veraltete Windows-Versionen, fehlende OS-Härtung und GPO-Wildwuchs untergraben IIS-spezifische Absicherungen auf Systemebene. OS-Härtung und IIS-Härtung werden als eine gemeinsame Automatisierungslogik eingesetzt.
Secure Windows Platform Automation
Das korrespondierende Modul für die OS-Schicht. CIS-Windows-Benchmark-Baselines, Ansible for Windows, Lifecycle-Management. IIS-Härtung und OS-Härtung werden gemeinsam eingesetzt, nicht als getrennte Silos.
Wann dieses Modul relevant wird
PCI-DSS-Audit legt TLS-Problem frei
Der Prüfer findet TLS 1.0 oder 1.1 aktiv. Niemand weiß, seit wann das so ist. Kein Konfig-File zu prüfen, keine Diff-History. SchChannel-Registry-Keys wurden nie explizit gesetzt. Die Folgefrage ist, wie viele weitere IIS-Instanzen im Unternehmen im gleichen Zustand sind.
Security-Header fehlen in der Standard-Konfiguration
Kein HSTS, kein Content-Security-Policy, kein X-Frame-Options. Jede neue IIS-Instanz startet ohne diese Header, weil kein organisatorischer Sollzustand für web.config-Konfiguration definiert ist. Jede Instanz ist eine Abweichung.
App-Pool-Wildwuchs mit einem Service-Account für alle
Fünf Anwendungen, ein App-Pool, eine Identity. Anwendungen, die eigentlich getrennte Daten verarbeiten, laufen unter demselben Account. Isolation ist nicht implementiert, weil kein Prozess dafür existiert und niemand einen Überblick hat.
Was heute möglich ist, was in Entwicklung ist
IIS-Härtung über Engineering as a Service
SchChannel-Konfiguration, Security-Header, App-Pool-Isolation, Request-Filtering: das ist umsetzbare Implementierungsarbeit, kein Produkt-Release-Gate. IIS-Härtungsprojekte werden heute über Engineering as a Service (EaaS) durchgeführt.
Plattform-Check (15 min.)Automatisiertes IIS-Modul als Teil von SPAS
Automatisierte Prüfung des SchChannel-Konfigurationsstands, Cipher-Suite-Analyse, App-Pool-Isolation-Report, Security-Header-Compliance-Nachweis. Als reproduzierbares Modul mit versioniertem Sollzustand, nicht als Einzel-Audit.
IIS im Scope eines Audits? Wir können schnell einordnen, was in SchChannel und web.config tatsächlich konfiguriert ist.
Unverbindlich · Keine Verkaufsveranstaltung · Vertraulich
