Die Basisversion, die niemand aktualisiert hat.
ISO 27001:2022 A.8.9 (Konfigurationsmanagement) verlangt, dass Sicherheitskonfigurationen für Hardware, Software, Dienste und Netzwerke festgelegt, dokumentiert, implementiert, überwacht und überprüft werden und dass die tatsächlich ausgeführte Konfiguration mit dieser Basisversion übereinstimmt. In der Praxis existiert die Basisversion meist als Code: ein gemeinsames Manifest, Modul oder eine Vorlage, von der jeder Dienst oder jede Ressource ausgehen soll. Die Kontrolle wird geschwächt, wenn die bereitgestellte Konfiguration ohne Autorisierung, Dokumentation oder Überwachung von der Basisversion abweicht, nicht jedoch, wenn eine überprüfte Ausnahme absichtlich vorgenommen wird.
The shapes the same control failure takes.
A.8.9 wird geschwächt, wenn die ausgeführte Konfiguration und die dokumentierte Basisversion auseinanderlaufen. Die wiederkehrenden Muster:
Eine Härtungsvorgabe wird lokal überschrieben
Ein Dienstmanifest setzt eine sicherheitsrelevante Einstellung gegen die gemeinsame Basisversion, um etwas Spezifisches zu ermöglichen, anstatt das zugrunde liegende Problem zu beheben oder die Basisversion zu aktualisieren.
Eine kopierte Vorlage weicht stillschweigend ab
Ein neuer Dienst startet von der gemeinsamen Konfigurationsvorlage, wird ad hoc angepasst, und die beiden Versionen weichen auseinander, ohne dass nachverfolgt wird, dass sie nicht mehr übereinstimmen.
Eine Ausnahme wird ohne Ablaufdatum bereitgestellt
Eine einmalige Überschreibung (eine gelockerte Einstellung, ein aktivierter Debug-Flag) ist als vorübergehend gedacht, hat aber kein Überprüfungsdatum und bleibt daher bestehen.
Eine aktive Ressource wird manuell geändert
Jemand bearbeitet eine laufende Ressource direkt (ein Klick in der Konsole, ein ad-hoc-CLI-Befehl), anstatt über die versionierte Konfiguration, die als Single Source of Truth dienen soll, sodass die beiden nicht mehr übereinstimmen.
Ein neuer Ressourcentyp wird ohne Basisversion bereitgestellt
Ein neuer Ressourcentyp (eine Warteschlange, eine Datenbank-Engine) wird eingeführt, ohne dass eine sichere Konfiguration dafür definiert ist, sodass jede Instanz ad hoc konfiguriert wird.
Eine Härtungsvorgabe wird überschrieben, um eine Bereitstellung zu ermöglichen.
Das gemeinsame Kubernetes-Basismanifest der Organisation führt jeden Dienst als Nicht-Root-Benutzer mit einem schreibgeschützten Root-Dateisystem aus, die dokumentierte Basisversion. Ein neuer Worker muss beim Start eine temporäre Datei schreiben, und das Ausführen als Root ist der schnellste Weg, um die Bereitstellung zu ermöglichen. Daher überschreibt sein Manifest die Basisversion direkt, anstatt ein beschreibbares Volume zu mounten oder die gemeinsame Basis zu aktualisieren. Der Dienst läuft nun mit mehr Berechtigungen als die dokumentierte Basisversion zulässt, und die Basisversion selbst wurde nicht geändert, sodass niemand bei deren Überprüfung die Abweichung erkennen würde.
containers: - name: worker- securityContext:- runAsNonRoot: true+ securityContext:+ runAsNonRoot: false # needs to write a temp file at startupDies schaltet einen Dienst direkt in seinem eigenen Manifest von der gemeinsamen Härtungsbasisversion (`runAsNonRoot: true`) aus, anstatt dies über die überprüfte Basisversion zu tun. A.8.9 erwartet, dass die bereitgestellte Konfiguration mit der festgelegten und dokumentierten Version übereinstimmt, und dies weicht davon ab, ohne dass jemand die Basisversion selbst ändert. Beheben Sie den tatsächlichen Schreibpfad (mounten Sie ein beschreibbares Volume für die temporäre Datei) oder dokumentieren und genehmigen Sie eine zeitlich begrenzte Ausnahme über den Konfigurationsmanagement-Prozess, anstatt einen Dienst lokal auszuschließen.
Die Konfiguration wird gegen das tatsächlich Ausgeführte geprüft, nicht nur gegen das Dokument.
Ein Prüfer überprüft, ob Ihre ausgeführte Konfiguration mit Ihrer dokumentierten sicheren Basisversion übereinstimmt, nicht nur, ob das Basisversion-Dokument existiert. Ein Dienst, der stillschweigend eine Härtungsvorgabe umgangen hat, eine manuell bearbeitete Ressource, die von ihrer nachverfolgten Konfiguration abweicht, oder ein neuer Ressourcentyp ohne Basisversion sind die Arten von Abweichungen, die zu einem Befund führen. Dies lässt sich meist auf eine Änderung zurückverfolgen, die einen lokalen Umweg gewählt hat, anstatt die Basisversion zu aktualisieren oder eine Ausnahme dafür zu definieren.
Eine Überprüfung, nicht Ihre Konfigurationsbasisversion.
heygrc markiert Änderungen, die A.8.9 betreffen, und verweist auf die Kontrolle, sodass die Korrektur im Pull Request erfolgt. Es definiert nicht Ihre Basisversion oder verwaltet Ihre Infrastruktur. Es erkennt den Moment, in dem eine Änderung stillschweigend von der dokumentierten Konfiguration abweicht, direkt im Diff.