ConfigurationManagement.
Security Configuration Management definiert technische Sollzustände, setzt sie wiederholbar um und erkennt Abweichungen. Es ergänzt Hardening und Compliance. CMDB, Patch Management und Cloud Posture Management lösen jeweils andere Teile des Problems.
Marktbild: hoch, aber auf Betriebssysteme, Cloud-Dienste und Endpoint-Plattformen verteilt. Zwölf Ansätze reichen von deklarativer Automation bis zur kontinuierlichen Endpoint-Kontrolle.
Sollzustand und Änderung gehören zusammen.
Ein Baseline-Scan zeigt eine Abweichung. Configuration Management muss zusätzlich erklären, welche Definition gilt, wer sie geändert hat, wie sie ausgerollt wird und wie ein fehlgeschlagener Eingriff zurückgenommen wird.
Prüfe unterstützte Plattformen, agentenlos oder Agent, deklaratives Modell, Drift Detection, Freigaben, Secret Handling, Rollback, Offline-Systeme, API, Git-Integration, Audit-Trail und Trennung von Entwicklung und Produktion.
Gehärtet heisst gehärtet bleiben.
Security Configuration Management beginnt mit einer Baseline: einer dokumentierten Soll-Konfiguration je Systemtyp, etwa welche Dienste laufen dürfen, welche Protokolle erlaubt sind, wie Passwort- und Protokollierungsregeln gesetzt sind. Grundlage sind meist öffentliche Benchmarks wie die CIS Benchmarks, die STIGs der US-Verteidigungsbehörde DISA oder Vorgaben des BSI, ergänzt um eigene Ausnahmen. Die CIS Benchmarks decken heute Betriebssysteme, Netzwerkgeräte, Kubernetes-Dienste und SaaS-Mandanten wie Microsoft 365 ab.[1,2]
Die zweite Aufgabe ist die Prüfung. Ein Scanner liest die tatsächliche Konfiguration aus und vergleicht sie Regel für Regel mit der Baseline. Dafür gibt es offene Standards: SCAP beschreibt Prüfregeln maschinenlesbar in XCCDF und OVAL, das Open-Source-Werkzeug OpenSCAP wertet sie aus und erzeugt Berichte. Prüfungen laufen mit Agent auf dem System, agentenlos über eine Fernverbindung oder offline auf exportierten Konfigurationsdateien, was vor allem bei Routern, Switches und Firewalls verbreitet ist. Das Ergebnis ist ein Erfüllungsgrad je System und Regel, der zeigt, wo die Härtung lückenhaft ist und welche Systeme zuerst nachgebessert werden sollten.[3,4,5]
Die dritte Aufgabe ist die Durchsetzung. Automationswerkzeuge beschreiben den Sollzustand als Code und wenden ihn wiederholt an. Deklarative Systeme vergleichen bei jedem Lauf Ist und Soll und korrigieren Abweichungen selbständig; prozedurale Werkzeuge führen Schritte in Playbooks aus. Viele Plattformen kennen zwei Modi: Audit meldet nur, Enforce oder Autocorrect setzt die Vorgabe durch. Die grossen Clouds bieten dafür eigene Dienste, die Einstellungen in Cloud-Maschinen und in angebundenen On-Premises-Servern prüfen und bei Drift zurücksetzen.[6,7,8]
Der vierte Teil ist der Nachweis. Für Revision und Aufsicht zählt, welche Baseline zu welchem Zeitpunkt galt, welche Systeme sie erfüllten, welche Ausnahmen genehmigt waren und wann Abweichungen behoben wurden. Gute Werkzeuge ordnen jedes Ergebnis einer Kontrolle zu, etwa den CIS Controls, und halten die Historie fest. Wichtig ist die Trennung von Durchsetzung und Kontrolle: Ein erfolgreich gelaufener Automationsjob belegt noch nicht, dass der Zielzustand erreicht ist; das zeigt erst eine unabhängige Prüfung.[3,9]
Typische Probleme
| Problem | Wie man es löst |
|---|---|
| Benchmark eins zu eins übernommen | Einzelne Regeln brechen Anwendungen, etwa wenn alte Protokolle noch gebraucht werden. Lösung: Baseline im Testbetrieb im Audit-Modus prüfen und Ausnahmen begründet dokumentieren. |
| Automatik überschreibt Ausnahmen | Ein Enforce-Lauf setzt eine bewusst genehmigte Abweichung zurück. Lösung: Ausnahmen im selben Regelwerk als Code führen und mit Ablaufdatum versehen. |
| Job erfolgreich, Zustand falsch | Ein grüner Automationslauf gilt als Nachweis. Lösung: Zustand mit einem unabhängigen Scanner prüfen und beide Ergebnisse abgleichen. |
| Netzwerkgeräte vergessen | Server sind gehärtet, Router und Firewalls laufen mit Werkseinstellungen. Lösung: exportierte Gerätekonfigurationen regelmässig gegen Benchmarks prüfen.[5] |
| Nicht versionierte Baseline | Niemand weiss, welche Vorgabe im letzten Audit galt. Lösung: Baselines in der Versionsverwaltung führen, Änderungen über den Change-Prozess freigeben. |
| Veraltete Systeme ausserhalb der Abdeckung | Werkzeuge schliessen Betriebssysteme ohne Herstellersupport aus. Lösung: Altsysteme separat inventarisieren und mit kompensierenden Massnahmen absichern.[8] |
Auswahlfragen
| Frage | Worauf die Antwort hinweisen sollte |
|---|---|
| Welche Benchmarks liefert das Werkzeug mit, und wie aktuell sind sie? | Die Antwort sollte Benchmark-Versionen je Betriebssystem, Netzwerkgerät und Cloud-Dienst nennen. |
| Prüft das Werkzeug nur, oder setzt es auch durch? | Erwartet wird eine klare Aussage zu Audit- und Enforce-Modus und zum Rückweg bei Fehlern. |
| Wie werden Ausnahmen verwaltet? | Hinweis auf Ausnahmen je Regel und System, mit Begründung, Verantwortlichem und Ablaufdatum. |
| Welche Plattformen sind abgedeckt, auch offline? | Die Antwort sollte Windows, Linux, Netzwerkgeräte, Cloud und Air-Gapped-Systeme getrennt beantworten. |
| Wie unabhängig ist die Prüfung von der Durchsetzung? | Erwartet wird, dass Ergebnisse auch von einem zweiten Werkzeug oder Prüfpfad bestätigt werden können. |
| Welche Nachweise entstehen für Audit und Aufsicht? | Die Antwort sollte Berichte mit Kontrollbezug, Historie und Export nennen. |
| Gibt es Inhalte für BSI- oder branchenspezifische Vorgaben? | Hinweis auf vorhandene oder anpassbare Prüfprofile. |
Betrieb und Verantwortung
Die Security-Architektur legt die Baselines fest und genehmigt Ausnahmen, die Betriebsteams für Server, Clients, Netzwerk und Cloud setzen sie um. Die Prüfung sollte organisatorisch von der Durchsetzung getrennt sein, etwa durch die zweite Linie oder ein eigenes Compliance-Team. Sinnvolle Kennzahlen sind Anteil der Systeme mit zugewiesener Baseline, Erfüllungsgrad je Systemklasse, Zahl und Alter der Ausnahmen und Zeit bis zur Korrektur kritischer Abweichungen.
Regulatorischer Bezug
ISO/IEC 27001:2022 adressiert das Thema in Annex A vor allem über 8.9 «Configuration management» und 8.32 «Change management». NIS2 nennt in Art. 21 Abs. 2 die Sicherheit bei Erwerb, Entwicklung und Wartung von Systemen (Bst. e) sowie Verfahren zur Bewertung der Wirksamkeit der Massnahmen (Bst. f); DORA verlangt in Art. 9 Abs. 4 Bst. e ein Änderungsmanagement, das ausdrücklich auch Sicherheitsparameter umfasst. Im IT-Grundschutz sind die Bausteine SYS.1.1 «Allgemeiner Server» und OPS.1.1.3 «Patch- und Änderungsmanagement» einschlägig.[10,11,12,13,14]
Quellen: [1] cisecurity.org · [2] mondoo.com · [3] cisecurity.org · [4] open-scap.org · [5] titania.com · [6] puppet.com · [7] docs.rudder.io · [8] learn.microsoft.com · [9] hcl-software.com · [10] isms.online · [11] isms.online · [12] nis-2-directive.com · [13] digital-operational-resilience-act.com · [14] bsi.bund.de · [15] docs.aws.amazon.com
Zwölf Werkzeuge im Vergleich.
Security Configuration Management legt technische Sollzustände fest, prüft Systeme dagegen und setzt die Vorgaben wiederholbar durch. Prüfwerkzeuge bewerten Systeme gegen Benchmarks wie CIS, DISA STIG oder BSI-Anforderungen und liefern Nachweise; Automationsplattformen beschreiben den Sollzustand als Code und korrigieren Abweichungen, teils über Agenten auf jedem System, teils über zentral ausgeführte Playbooks. Die grossen Clouds bieten eigene Dienste, die Betriebssystem-Einstellungen in Cloud- und hybriden Maschinen prüfen und automatisch zurücksetzen. Für Netzwerkgeräte gibt es spezialisierte Werkzeuge, die exportierte Konfigurationen offline auswerten. Open Source ist verbreitet: OpenSCAP (LGPL 2.1) mit dem SCAP Security Guide und Rudder (GPLv3) stehen neben kommerziellen Plattformen, Mondoo verbindet Benchmark-Prüfung mit einer GmbH in Berlin.
CIS: CIS-Benchmarks · Windows: Windows · Linux: Linux · Netzwerk: Netzwerkgeräte · Cloud: Cloud · Behebung: automatische Behebung · On-Prem: On-Prem. ● = auf offizieller Hersteller- oder Projektseite beschrieben, – = nicht belegt (nicht zwingend nicht vorhanden). Auswahl nicht abschliessend, keine Rangliste. Stand: Oktober 2026.
CIS-CAT Pro Assessor
Center for Internet Security (CIS)
Unterstützte CIS Benchmarks reichen von Windows 11 und Windows Server über zahlreiche Linux-Distributionen und macOS bis zu Cisco IOS, FortiGate, Aruba-Switches, Kubernetes-Diensten wie EKS, AKS und GKE sowie Microsoft 365.
Der Assessor setzt die Empfehlungen der CIS Benchmarks und CIS Controls in automatisierte Prüfungen um, scannt Systeme und berichtet ihren Erfüllungsgrad.
Ergebnisse werden den CIS Controls zugeordnet und helfen, die Reaktion auf Abweichungen zu priorisieren; angepasste Benchmarks aus CIS WorkBench lassen sich als automatisierter Inhalt exportieren.
Das CIS-CAT Pro Dashboard zeigt den Erfüllungsgrad über die Zeit; seit Version 4 prüft der Assessor entfernte Windows-Systeme per WinRM und Unix/Linux-Systeme per SSH.
Zugang über die CIS-SecureSuite-Mitgliedschaft; das Backend wurde für den Betrieb auf Java 21 modernisiert.
Nachweis der Härtung gegen CIS Benchmarks für Audit, Revision und Kunden.
Prüfinhalte stammen direkt vom Herausgeber der CIS Benchmarks und decken Betriebssysteme, Netzwerkgeräte, Kubernetes-Dienste der Cloud-Anbieter und Microsoft 365 ab.
Das Werkzeug prüft und berichtet; Korrekturen müssen mit anderen Mitteln umgesetzt werden.
OpenSCAP mit SCAP Security Guide
OpenSCAP-Projekt / ComplianceAsCode
Der SCAP Security Guide liefert Baselines für Linux-Distributionen wie RHEL, Fedora und Ubuntu sowie für Anwendungen; der Scanner oscap steht auch als Windows-Installer bereit.
OpenSCAP setzt den SCAP-Standard um und wertet XCCDF-Benchmarks und OVAL-Definitionen aus; das Projekt wurde 2014 von NIST für SCAP 1.2 zertifiziert.
Der SCAP Security Guide setzt Vorgaben wie PCI DSS, DISA STIG und USGCB in maschinenlesbare Regeln um und enthält erprobte Korrekturskripte.
Linux-Verwaltungsplattformen wie SUSE Multi-Linux Manager nutzen OpenSCAP für Audits ihrer Clients.
Läuft lokal und offline; alle Projekte unter dem OpenSCAP-Dach sind laut Projekt vollständig Open Source.
Prüfung von Linux-Servern gegen STIG- oder PCI-Profile, etwa in regulierten Umgebungen ohne Cloud-Anbindung.
Offener Standard und offene Inhalte, die sich prüfen, anpassen und weitergeben lassen.
Die Inhalte sind auf Linux ausgerichtet; Korrekturskripte müssen bewusst ausgeführt werden.
Mondoo Platform (CIS-Benchmarks und cnspec)
Mondoo (Mondoo, Inc., Berkeley; Mondoo GmbH, Berlin)
Richtlinien für Windows Server, Red Hat Enterprise Linux, Cisco IOS-XE, AWS, Azure, Google Cloud, Kubernetes und Microsoft 365, dazu BSI-Anforderungen wie SYS.1.3 und SYS.1.2.
Die Engine cnspec bewertet Systeme mit Richtlinien in der Abfragesprache MQL; die Plattform ergänzt zertifizierte CIS-, NIST- und BSI-Benchmarks.
Laufende Compliance-Überwachung mit Korrekturhinweisen; Mondoo ist laut Hersteller CIS-SecureSuite-zertifiziert für Cloud- und Kubernetes-Sicherheit.
Dieselben Richtlinien gelten für IaC-Vorlagen, laufende Systeme und Cloud-Konten.
cnspec steht unter der Business Source License 1.1; Mondoo hat neben dem US-Sitz eine GmbH in Berlin.
Nachweis gegen CIS und BSI über Server, Cloud und Netzwerkgeräte mit einer Abfragesprache.
BSI-Bausteine als Prüfinhalt neben CIS, mit einer Engine für Server, Cloud, Kubernetes und Netzwerkgeräte.
Die Seite beschreibt Korrekturhinweise und einen Managed Service; eine automatische Durchsetzung auf den Systemen ist dort nicht dokumentiert.
Nipper InfraSight (ehemals Nipper)
Titania
Router, Switches, Firewalls und WLAN-Access-Points, deren Konfigurationen exportiert und ausgewertet werden.
Nipper InfraSight analysiert exportierte Gerätekonfigurationen, ohne Live-Systeme zu scannen oder zu berühren.
Prüft Gerätehärtung gegen Leitfäden und Audits, wo unterstützt auch gegen CIS Benchmarks, und findet schwache Zugriffskontrollen, unsichere Dienste und zu offene Regeln.
Erzeugt kontrollbezogene Bestanden/Nicht-bestanden-Nachweise für Audit-, GRC- und Security-Teams sowie gerätespezifische Korrekturhinweise.
Stufen Essentials, Compliance und Air Gapped; eignet sich für regulierte und Air-Gapped-Umgebungen ohne direkten Gerätezugriff.
Periodischer Nachweis der Härtung von Netzwerkgeräten für Revision und Aufsicht.
Netzwerkgeräte werden offline geprüft, ohne Last oder Risiko auf den Live-Systemen.
Die Auswertung ist eine Momentaufnahme der exportierten Konfiguration; Korrekturen erfolgen auf den Geräten selbst.
HCL BigFix Compliance
HCL Software
Endpunkte On-Premises, virtuell oder in der Cloud; die Plattform nennt Windows, UNIX, Linux und macOS.
Über 50000 mitgelieferte Sicherheitsprüfungen setzen Endpunkt-Compliance laufend durch, verbunden mit automatischer Korrektur und Quarantäne.
Vorgefertigte Benchmarks wie CIS, DISA STIG, NIS2, HIPAA und PCI DSS 4.0; Konfigurationsdrift wird in Echtzeit erkannt und korrigiert.
Historische Compliance-Berichte zeigen die Entwicklung des Sicherheitsniveaus; Patch-Management läuft auf derselben Plattform.
Compliance ist ein Modul der BigFix-Plattform neben Patch-, Lifecycle- und Inventarfunktionen.
Grosse, heterogene Endpunktbestände, in denen Härtung und Patching über eine Plattform laufen sollen.
Über 50000 mitgelieferte Prüfungen mit automatischer Korrektur von Drift über viele Betriebssysteme.
Die Prüfung von Netzwerkgeräten beschreibt die Produktseite nicht.
Puppet Enterprise
Perforce (Puppet)
Automationsabläufe für Linux- und Windows-Server, Netzwerkperipherie und Edge-Geräte aus einer Steuerungsebene.
Deklaratives Modell: Puppet beschreibt den gewünschten Zustand, erkennt Drift und korrigiert sie automatisch.
Richtlinien bewerten Konfigurationen anhand gängiger Sicherheitsrahmenwerke und setzen konforme Einstellungen laufend durch.
Sichere Baselines gelten für neue und bestehende Ressourcen im Rechenzentrum, in der Cloud und hybrid.
Wird im eigenen Betrieb eingesetzt; Puppet erscheint auf der Produktseite unter der Marke Perforce.
Grosse Serverlandschaften, deren Härtung dauerhaft und nachvollziehbar durchgesetzt werden soll.
Kontinuierliche Durchsetzung des Sollzustands mit automatischer Drift-Korrektur.
Welche Benchmarks fertig mitgeliefert werden, nennt die Produktseite nicht konkret; CIS ist dort nicht genannt.
Chef Compliance
Progress (Chef)
Scan-Ziele sind Linux, Windows, Container, Cloud-Konten in AWS, Azure und Google Cloud sowie Offline- und Air-Gapped-Knoten.
Vorgefertigte, anpassbare Sicherheits- und Compliance-Profile wie CIS Benchmarks, DISA STIGs und von Chef kuratierte Leitfäden.
Verfolgt Drift sowie Fortschritt der Behebung und die Einhaltung der Richtlinien über die gesamte Flotte.
Probleme werden automatisch an der Quelle behoben, statt auf eine nachträgliche Wiederherstellung zu warten.
Chef gehört zum Produktportfolio von Progress; die Produktseite verlinkt eine SaaS-Bereitstellung der Chef-Produkte, beschreibt die Bereitstellungsform von Chef Compliance aber nicht.
DevOps-orientierte Infrastrukturteams, die Prüfung und Korrektur als Code im selben Werkzeug pflegen.
CIS- und STIG-Profile als Code, kombiniert mit automatischer Korrektur und Drift-Verfolgung.
Netzwerkgeräte nennt die Produktseite nicht; die Bereitstellungsform ist dort nicht beschrieben.
Red Hat Ansible Automation Platform
Red Hat (IBM)
Automatisierung von Betriebssystemen, Microsoft Windows und Active Directory, Multi-Vendor-Netzwerken über Campus, Filialen, Cloud und Edge sowie Cloud-Umgebungen.
Lesbare Playbooks beschreiben die gewünschten Schritte; Policy as Code ist als Anwendungsfall ausgewiesen.
Ereignisgesteuerte Erkennung, Quarantäne und Behebung sowie konsistente Sicherheitsleitplanken vom einzelnen Server bis zur ganzen Umgebung.
Integrationen mit Monitoring- und Sicherheitswerkzeugen lösen automatische Behebung aus.
Automatisierung in Produktionsumgebungen unter Einhaltung von Sicherheits- und Compliance-Vorgaben.
Hybride Umgebungen, in denen Härtung für Linux, Windows und Netzwerkgeräte über dieselben Playbooks läuft.
Breite Abdeckung von Servern, Windows und Netzwerkgeräten mit einer Automationssprache.
Fertige CIS-Inhalte und Drift-Berichte nennen die geprüften Seiten nicht; Prüflogik und Nachweis müssen ergänzt werden.
Rudder
Rudder (Normation)
Linux- und Windows-Systeme in der Cloud oder On-Premises; Agenten für Debian, Ubuntu, RHEL, Amazon Linux, SLES und Windows.
Ein zentraler Server verteilt Regeln an Agenten; je Regel lässt sich zwischen Audit- und Enforce-Modus wählen.
Compliance- und Drift-Bewertung zeigt den tatsächlichen Zustand gegenüber der Vorgabe, auch gemessen an Branchen-Benchmarks wie CIS, NIST und ISO 27001.
Web-Oberfläche und API zur Verwaltung von Knoten, Techniken, Direktiven und Regeln.
Selbst betriebener Server mit eigener Datenbank; Kern unter GPLv3.
Linux- und Windows-Umgebungen, die Prüfung und Durchsetzung im eigenen Rechenzentrum halten wollen.
Audit- und Enforce-Modus pro Regel verbinden Nachweis und Korrektur, mit offenem Kern.
Netzwerkgeräte sind auf den geprüften Seiten nicht abgedeckt.
SUSE Multi-Linux Manager
SUSE
SLES 12 und 15, openSUSE, RHEL-Familie 7 bis 10, Debian 12 und Ubuntu 22.04; Debian 13 und Ubuntu 24.04 nur mit Upstream-Inhalten ohne SUSE-Support.
Nutzt OpenSCAP, um die Sicherheitskonfiguration der Clients zu prüfen; Scans laufen bei der nächsten geplanten Synchronisation.
Offiziell unterstützte Profile umfassen DISA STIG und PCI-DSS für SLES 12 und 15; Profile für andere Distributionen stammen aus der Community.
Korrekturskripte in Bash und Ansible-Playbooks aus dem SCAP Security Guide lassen sich als Remote-Befehl oder über Ansible ausführen.
Selbst betriebene Verwaltungsplattform auf Salt-Basis; OpenSCAP-Audits sind auf Salt-Clients mit SSH-Kontaktmethode nicht verfügbar.
Heterogene Linux-Bestände, die Patching, Konfiguration und Compliance-Prüfung zentral verwalten.
Compliance-Prüfung für viele Linux-Distributionen in einer selbst betriebenen Verwaltungsplattform.
Korrekturen müssen manuell oder per Ansible angestossen werden; Windows liegt ausserhalb.
Azure Machine Configuration (Azure Policy)
Microsoft
Betriebssystem-Einstellungen von Maschinen in Azure und von hybriden, über Azure Arc angebundenen Maschinen mit Windows Server und verbreiteten Linux-Distributionen.
Azure Policy prüft oder konfiguriert Einstellungen als Code; der Guest-Configuration-Client auf der Maschine wertet die Vorgaben aus.
Drei Modi: Audit meldet nur, Apply and Monitor setzt und überwacht, Apply and Autocorrect bringt die Maschine bei Drift wieder in den Sollzustand.
Vorgaben lassen sich reaktiv auf bestehende und proaktiv auf neue Maschinen anwenden, etwa die Pflicht zu TLS 1.2.
Teil von Azure Policy; On-Premises-Server werden über Azure Arc eingebunden.
Azure- und Arc-Umgebungen, die Härtungsvorgaben mit denselben Richtlinien wie die übrige Cloud-Governance führen.
Automatische Korrektur von Drift direkt aus Azure Policy, auch für hybride Server.
Unterstützt sind nur Betriebssysteme der Support-Matrix; nicht mehr unterstützte Linux-Versionen sind ausgeschlossen.
AWS Systems Manager State Manager
Amazon Web Services
Verwaltete Knoten mit Linux, macOS und Windows Server sowie weitere AWS-Ressourcen.
Eine State-Manager-Zuordnung (Association) definiert den Zustand, der auf den zugewiesenen Ressourcen gehalten werden soll; Grundlage sind SSM-Dokumente.
Hält Konfigurationen dauerhaft im definierten Zustand und reduziert so Konfigurationsdrift.
Kann Agenten aktualisieren, Netzwerkeinstellungen setzen, Knoten in Active Directory aufnehmen und Automation-Runbooks planen.
Teil von AWS Systems Manager; benötigt den SSM Agent auf den Knoten.
AWS-zentrierte Teams, die Grundkonfiguration und Härtung ihrer EC2-Flotte im AWS-Betriebsmodell steuern.
Sollzustände im AWS-Betriebsmodell ohne zusätzliche Plattform.
Benchmark-Inhalte wie CIS liefert State Manager nicht selbst mit; sie müssen als Dokumente bereitgestellt werden.
Weitere Anbieter
Kurz eingeordnet, ausserhalb der Vergleichsmatrix.
- CFEngine Enterprise, Canonical Landscape, Tanium Automate, Google VM Manager: Konfigurations- und Patch-Verwaltung (CFEngine, Landscape, Google VM Manager für Compute-Engine-VMs) sowie Endpoint-Orchestrierung (Tanium Automate)
- Qualys Policy Compliance, Tenable (Konfigurations-Audits): Prüfung gegen Benchmarks als Teil von Schwachstellenplattformen
- Microsoft Intune Security Baselines, Microsoft Security Compliance Toolkit: Microsoft-eigene Baselines für Windows
- Netwrix Change Tracker, Fortra Tripwire Enterprise: Änderungs- und Konfigurationsüberwachung mit Benchmark-Inhalten
- Lynis (CISOfy), Wazuh SCA: Open-Source-Prüfungen für Linux bzw. als Modul einer XDR/SIEM-Plattform
- Die gewünschte Baseline ist nicht versioniert oder widerspricht dem Applikationsbetrieb.
- Automatische Korrektur überschreibt eine legitime Ausnahme.
- Ein erfolgreicher Job gilt als Nachweis, obwohl der Zielzustand nicht unabhängig geprüft wurde.
Versioniere eine konkrete Hardening-Regel, rolle sie auf Linux, Windows und einem Cloud-System aus, provoziere Drift und prüfe Freigabe, Ausnahme, Rollback und unabhängige Zustandskontrolle.
Für Sicherheitslücken dient Patch Management, für Cloud-Fehlkonfigurationen CSPM. Eine CMDB beschreibt Servicebeziehungen, nicht den technischen Sollzustand.
Security Tool Navigator · Gebiet 06
Im Gebiet Cloud und Infrastructure Security einordnen.
Diese Werkzeugklasse gehört zum Gebiet Cloud und Infrastructure Security. Der Gebietshub zeigt, wie die Werkzeugklassen zusammenwirken, wo sie sich abgrenzen und welche Fragen CIO und CISO jeweils klären.