Sicherheitsfehlkonfiguration: Was sie ist und wie man sie erkennt, wenn sie zurückkehrt

Teams härten ihre Systeme anhand eines Benchmarks ab, schließen ungenutzte Ports, aktivieren das Logging und bestehen die Überprüfung. Dann setzt ein Patch eine Einstellung zurück, ein Techniker öffnet um 2 Uhr morgens eine Firewall-Regel, um einen Ausfall zu beheben, und schließt sie nie wieder, und ein neuer Server wird aus einem älteren Image erstellt. Einige Monate später sieht die Umgebung ganz anders aus als die genehmigte.

Das ist eine Fehlkonfiguration der Sicherheit. OWASP bewertete sie als fünftwichtigstes Problem im Jahr 2021 und als zweitwichtigstes im Jahr 2025, und sie steigt weiter, weil man jede bekannte Schwachstelle beheben kann und trotzdem die Tür offen lässt, wenn eine Einstellung vergessen wurde zu ändern.

Sicherheitsfehlkonfiguration: Eine Einstellung, die falsch, fehlend oder auf Standard belassen wurde

Sicherheitsfehlkonfiguration ist eine Schwachstelle, die durch fehlende, falsche oder unsichere Standardeinstellungen verursacht wird. Die Software funktioniert wie vorgesehen. Die Art der Einrichtung macht sie angreifbar.

Eine Schwachstelle ist ein Fehler im Code, den der Anbieter mit einem Patch behebt. Eine Fehlkonfiguration entsteht durch eine Entscheidung oder deren Fehlen bei der Bereitstellung oder Änderung eines Systems. Die Lösung ist eine Änderung der Einstellungen, die Ihr Team vornehmen und beibehalten muss.

Fehlkonfigurationen können in Betriebssystemen, Datenbanken, Webservern, Cloud-Plattformen, Netzwerkgeräten und Anwendungen auftreten. Sie bleiben oft unbemerkt, weil nichts ausfällt und das System weiterläuft.

Beispiele für Sicherheitsfehlkonfigurationen auf Servern, in der Cloud und an Netzwerkgeräten

Viele davon lassen sich auf eine einzelne Zeile in einer Konfigurationsdatei zurückführen. So sieht Drift in zwei gängigen Dateien aus.

      # /etc/ssh/sshd_config 

 

# Drifted 

PermitRootLogin yes 

PasswordAuthentication yes 

 

# Hardened 

PermitRootLogin no 

PasswordAuthentication no 
      

      # nginx.conf 

 

# Drifted 

autoindex on;        # directory listings exposed 

server_tokens on;    # version number in every response 

 

# Hardened 

autoindex off; 

server_tokens off; 
      

Beide abweichenden Versionen laufen einwandfrei, weshalb sie niemand bemerkt. Change Tracker kann Konfigurationsdateien wie diese überwachen und den Moment melden, in dem sich ein Wert ändert.

Die meisten davon lassen sich nur durch eine Änderung der Einstellungen beheben. Sie in einer großen Umgebung zu finden, ist der langsame Teil.

Fehlkonfigurationen kehren nach der Härtung immer wieder zurück

Fehler bei der Einrichtung passieren, ebenso wie Änderungen nach der Einrichtung. Der technische Begriff für Letzteres ist Konfigurationsabweichung: die allmähliche Abweichung eines Systems von seinem genehmigten, gehärteten Zustand.

Patches und Updates ändern Einstellungen als Nebeneffekt. Notfallreparaturen werden außerhalb des normalen Prozesses durchgeführt, weil das Geschäft nicht warten kann. Systeme, die identisch sein sollten, werden zu unterschiedlichen Zeiten von verschiedenen Personen gebaut. Wenn sich etwas ändert, gibt es oft keinen klaren Nachweis darüber, wer wann und warum geändert hat.

Deshalb reicht eine einmalige Prüfung nicht aus. Sie zeigt Ihre Systeme so, wie sie am Tag der Überprüfung waren, und Abweichungen können bereits am nächsten Tag beginnen. Teams, die vierteljährlich oder jährlich prüfen, arbeiten immer mit einem bereits veralteten Schnappschuss.

Was ein falsch konfiguriertes System Sie kostet

Ein falsch konfiguriertes System erleichtert einem Angreifer den Zugang und führt bei einem Prüfer zu einem Befund. Beides kostet Zeit und Geld.

Fehlkonfigurationen können Daten offenlegen, den Zugriff erweitern, den ein Angreifer einmal im System erhält, und eine Eindringung schwerer erkennbar machen, da das Logging nicht darauf ausgelegt war, sie zu erfassen. Eine falsche Einstellung kann auch einen Ausfall verursachen, und die Ursache zu finden kostet Stunden, wenn niemand sagen kann, was sich geändert hat. Rahmenwerke wie PCI DSS, NIST 800-53 und HIPAA erwarten von Organisationen, dass sie sichere Konfigurationsstandards einhalten und nachweisen, dass Systeme diesen noch entsprechen. Ein abgewichenes System fällt diesen Test durch, auch wenn noch nichts Schlimmes passiert ist.

Sicherheitsfehlkonfiguration in vier Schritten finden und beheben

1. Beginnen Sie mit einem Standard. Ohne eine Messgrundlage finden Sie keine Fehlkonfiguration. Die meisten Organisationen starten mit einem Branchenbenchmark wie den CIS Benchmarks oder DISA STIG und passen diesen an ihre Umgebung an. Manche erstellen ihren eigenen Standard aus einem bereits gehärteten und vertrauenswürdigen System.
2. Bewerten Sie jedes System daran. Prüfen Sie Server, Datenbanken, Cloud-Konten und Netzwerkgeräte anhand des Benchmarks und bewerten Sie die Ergebnisse. Sie erhalten eine Liste der Abweichungen, sortiert nach Relevanz.
3. Beheben Sie, was Sie finden. Beginnen Sie mit dem höchsten Risiko. Wenn eine Abweichung beabsichtigt ist, dokumentieren Sie sie als genehmigte Ausnahme, damit sie nicht als Fehlalarm zurückkommt.
4. Änderungen überwachen. Nach der Behebung ändert sich die Umgebung weiterhin. Die kontinuierliche Überwachung zeigt Ihnen, wann ein System vom genehmigten Zustand abweicht, sodass Sie eine abweichende Einstellung innerhalb von Stunden beheben können, statt sie beim nächsten Audit zu entdecken.

Erkennung ohne Kontext wird zu Alarmrauschen

Nachdem Teams die Überwachung hinzugefügt haben, beginnen die Warnmeldungen einzutreffen. Jeder Patch, Wartungszeitraum und genehmigte Update kann Änderungsereignisse erzeugen, und bei Hunderten von Geräten kann ein Team die routinemäßigen Änderungen nicht von den riskanten unterscheiden.

Eine Änderung an einer Konfigurationsdatei ist nur dann ein Problem, wenn sie nicht hätte passieren dürfen. Den Unterschied zu erkennen bedeutet, das Geänderte mit dem Genehmigten zu vergleichen.

Die Closed-Loop-Change-Control führt diesen Vergleich durch. Genehmigte Änderungen werden als geplante Änderungen erfasst, entweder durch Verbindung mit dem IT-Service-Management-System, in dem die Anfragen bereits vorhanden sind, oder durch direkte Definition. Wenn eine Änderung in einem System auftaucht, wird sie mit dem Plan abgeglichen. Eine Übereinstimmung wird als geplant eingestuft und bleibt unauffällig. Alles andere wird als ungeplant markiert, und diese kurze Liste wird vom Team untersucht.

Lernen Sie Netwrix Change Tracker kennen

Netwrix Change Tracker vergleicht Systeme mit einem bekannten Standard, erkennt Abweichungen in Echtzeit und trennt geplante von ungeplanten Änderungen.

Für die Bewertung enthält Change Tracker Compliance-Berichte basierend auf den CIS Benchmarks, und Netwrix ist ein CIS-zertifizierter Anbieter. Die Berichte decken Windows, Linux, Unix, Datenbanken, Netzgeräte, VMware ESXi und Cloud-Plattformen wie Azure, AWS, GCP und Microsoft 365 ab. Wenn Ihre Organisation einen eigenen Build-Standard hat, kann jedes Gerät als Baseline-Quelle dienen, sodass Sie einen Gold-Build von einem vertrauenswürdigen System definieren und die anderen daran messen können.

Zur Überwachung verfolgt es Dateien, Ordner und Dateiinhalte sowie Prozesse, Dienste und offene Netzwerkports. Unter Windows verfolgt es außerdem Registrierungseinstellungen, installierte Software, lokale Konten sowie Sicherheits- und Prüfungsrichtlinien. Die Erfassung funktioniert mit oder ohne Agent, was in Umgebungen wichtig ist, die Server, Appliances und Geräte mischen, auf denen keine Software installiert werden kann. Jede Änderung wird mit dem Was und Wann aufgezeichnet, sodass Sie eine durchsuchbare Historie erstellen, falls etwas schiefgeht.

Für die Änderungssteuerung vergleicht es erkannte Änderungen mit geplanten. Es integriert sich in ITSM-Plattformen wie ServiceNow, BMC Remedy, Cherwell, ManageEngine ServiceDesk Plus und OpenText Service Management, sodass genehmigte Anfragen automatisch zu geplanten Änderungen werden. Ungeplante Änderungen können in ServiceNow einen Vorfall auslösen, der die Untersuchung vor die verantwortliche Person für das System stellt.

Sie erhalten eine Sicherheitskonfiguration, die Sie jederzeit überprüfen können, und eine klare Antwort, wenn jemand fragt, was sich geändert hat.