Sie kann in Anwendungen, Frameworks, Identitäten, Cloud-Diensten, Netzwerken, Hosts, Containern, Datenbanken, Geräten oder Managementsystemen auftreten und Daten oder Funktionen exponieren, eine andere Kontrolle schwächen oder einen Zustand schaffen, den eine Bedrohung ausnutzen kann.
Beispiele sind unveränderte Default-Credentials, öffentlicher Speicher, übermäßige Berechtigungen, aktivierte Beispiel- oder Debug-Funktionen, ausführliche Fehlermeldungen, fehlende Sicherheitsdirektiven, exponierte Management-Schnittstellen, deaktiviertes Logging und inkonsistente Einstellungen zwischen Umgebungen. Die korrekte Konfiguration hängt von Architektur, Zweck, Daten, Bedrohungen und betrieblichen Rahmenbedingungen ab.
Wichtigste Punkte
Absicht festlegenGetestete, versionsspezifische Baselines und Richtlinien für jede Umgebung definieren, einschließlich erforderlicher Dienste, Schnittstellen, Berechtigungen, Logging, Verschlüsselung, Fehlerbehandlung und freigegebener Ausnahmen.
Änderung kontrollierenVerantwortliche Prüfung, wiederholbares Deployment, Least-Privilege-Administration, geschützte Konfigurationsspeicher und Trennung zwischen Entwicklungs-, Test- und Produktions-Credentials einsetzen.
Zustand verifizierenEffektive Einstellungen und Ressourcenbeziehungen bewerten, mit beabsichtigten Baselines vergleichen, Drift erkennen, nach Exposition und Auswirkung priorisieren, sicher beheben und bestätigen, dass die Korrektur bestehen bleibt.
Wichtige EinschränkungNicht jede Schwachstelle ist eine Fehlkonfiguration; korrekt konfigurierte Software kann Design- oder Implementierungsschwächen enthalten. Ein fehlgeschlagener Konfigurationscheck ist auch kein Beweis für Ausnutzbarkeit, und unvollständige Sichtbarkeit oder eine ungeeignete Baseline kann wesentliches Risiko übersehen.