Grundschutz-Konfigurationsmanagement in der Praxis: Sollkonfiguration, Bestand und Drift

Eigene Auszählung im Anwenderkatalog Grundschutz++, Build 2026-10-29, rekursiv über alle Verschachtelungsebenen:

Vier KONF-Anforderungen sind zwei Kategorien zugeordnet und hier bei beiden gezählt.

Die beiden Praktiken verhalten sich gegensätzlich. KONF hängt fast vollständig an Zielobjektkategorien: Nur 8 der 157 Anforderungen gelten ohne Zuordnung, der Rest kommt erst über die Modellierung ins Paket (Kapitel 3.4.1 und 3.4.2 von BSI-Standard 300-1). Welche Konfigurationsanforderungen Sie erfüllen müssen, entscheidet also die Frage, welche Assets Sie als IT-Systeme, Anwendungen, Webbrowser oder E-Mail modelliert haben. Und 146 der 157 KONF-Anforderungen haben im Feld documentation den Wert „Konfigurationshistorie“. Der Nachweis für KONF ist damit fast immer derselbe: die versionierte Grundkonfiguration und die Ergebnisse der Prüfungen dagegen.

KONF.2.1 (SOLLTE, IT-Systeme) und KONF.10.1 (SOLLTE, Anwendungen) verlangen je eine dokumentierte Grundkonfiguration. Nach der Katalogerläuterung zu KONF.2.1 ist das ein dokumentierter Ausgangszustand, der „als verbindlicher Referenzpunkt für den Betrieb und die Härtung dient“. KONF.2.1.1 und KONF.10.1.1 (SOLLTE) verlangen, vorherige Konfigurationen zu versionieren. Die TPN legt fest (fiktiv):

Drei Anforderungen ohne Zielobjektkategorie gehören dazu: KONF.1.3 verlangt, die Konfigurationswerkzeuge mit Verwendungszweck und Herkunft zu dokumentieren, KONF.1.4 den Zugriff auf dokumentierte Konfigurationen einzuschränken und KONF.1.5 Konfigurationsgeheimnisse zu verschlüsseln. Für die TPN heißt das konkret: Die beiden Werkzeuge stehen mit Zweck und Bezugsquelle im IT-Betriebskonzept, das Repository ist nur für die Administrierenden der Linux-Server lesbar, und Passwörter in Skripten werden durch Verweise auf einen Tresor ersetzt.

Ohne Bestand ist der Abgleich lückenhaft: Ein System, das nicht im Inventar steht, prüft auch niemand gegen seine Grundkonfiguration. ASST liefert dafür die Anforderungen (alle SOLLTE):

• ASST.2.2 (ohne Zielobjektkategorie): Inventar der IT-Systeme einschließlich Identifikationsbezeichnung und letztem bekannten Verbleib. Die TPN führt dafür in der CMDB je System Inventarnummer, DNS-Name, Standort oder Virtualisierungshost und die zuständige Person.
• ASST.2.3 (ohne Zielobjektkategorie): Inventar der Anwendungen einschließlich Produktname, Versionsstand, Herkunft und Lizenzierung; ASST.2.3.1 (IT-Systeme): die Nutzung von Anwendungen auf IT-Systemen durch [eine zuständige Person oder Rolle] autorisieren. Die TPN legt den Parameter auf die Leitung des IT-Betriebs fest.
• ASST.2.3.2 (Anwendungen): die Software Bill of Materials (SBOM) dokumentieren. Für die 41 Fachanwendungen liegen bisher 12 SBOMs vor, alle aus Beschaffungen der letzten zwei Jahre.
• ASST.2.2.1 (Netze): das Aufdecken unautorisierter IT-Systeme verankern. Die Erläuterung nennt aktive Netzscans und passive Analysen des Netzwerkverkehrs als Mittel und als Behandlung, dass gefundene Systeme „aus dem Netz entfernt, in eine Quarantäne verschoben oder nach Überprüfung autorisiert werden“.

Mit dem Inventar der Strukturanalyse ist dieser Bestand nicht dasselbe. Die Strukturanalyse erfasst Assets und Abhängigkeiten, damit ein Anforderungspaket entsteht; ASST.2.2 verlangt ein Inventar als laufende Betriebsunterlage. In der Praxis ist es sinnvoll, beides aus derselben Quelle zu speisen. Wie Bestandsdaten in die Strukturaufnahme kommen, zeigt die Strukturanalyse.

KONF.2.5 (SOLLTE, IT-Systeme) und KONF.10.5 (SOLLTE, Anwendungen) verlangen, die Übereinstimmung der tatsächlichen Konfiguration mit dem Referenzzustand [regelmäßig] zu überprüfen; die TPN hat den Parameter auf monatlich festgelegt. Die Erläuterung nennt als Zweck die Vermeidung von Configuration Drift, also „dass Systeme schleichend von der definierten Soll-Konfiguration abweichen“. Die automatische Überprüfung durch [einen automatisierten Mechanismus] ist mit KONF.2.5.1 eine KANN-Anforderung (Sicherheitsniveau erhöht); die TPN nutzt ihre Konfigurationsverwaltung trotzdem dafür, weil sie vorhanden ist.

Abgleichprotokoll der TPN für einen Monat, fiktive Zahlen:

Aus dem Protokoll lassen sich drei Arten von Drift ablesen, die unterschiedlich behandelt werden. Das Ist ist abgewichen: zurücksetzen und die Ursache klären, bei fehlender Autorisierung auch als sicherheitsrelevantes Ereignis bewerten. Das Soll ist veraltet: Die Änderung war autorisiert, aber die Grundkonfiguration wurde nicht nachgezogen; dann wird eine neue Version der Grundkonfiguration angelegt, über das Änderungsverfahren der Praktik TEST (Änderungen und Tests). Der Bestand ist unvollständig: Ein System fehlt im Inventar oder ist nicht mehr auffindbar; dann wird es nach Prüfung autorisiert und eingetragen, isoliert oder als abhandengekommen behandelt.

Der Abgleich selbst ist eine Maßnahme zu KONF.2.5 und KONF.10.5. Nach unserer Lesart sind diese beiden Anforderungen erfüllt, wenn der Abgleich im festgelegten Turnus stattfindet und protokolliert ist, auch wenn er Abweichungen findet. Die Abweichungen zeigen sich im Status der Anforderungen, deren Inhalt abweicht. Nach Kapitel 4.1.1 von 300-1 wird der Status je Anforderung vergeben; die TPN nennt in der Begründung, welche Systeme betroffen sind. Statusentscheidungen im Fall (fiktiv):

Die Gateways. Nach Kapitel 4.1.1 kann eine Anforderung als „nicht anwendbar“ gelten, „wenn die Anforderung funktional nicht erfüllt werden kann oder die zugrunde liegende Komponente nicht im Informationsverbund existiert“. Man könnte argumentieren, KONF.2.3 sei für die drei Gateways funktional nicht erfüllbar. Der Status wird aber je Anforderung vergeben, und für alle anderen IT-Systeme ist KONF.2.3 erfüllbar und erfüllt. Den Fall einer Anforderung, die nur für einen Teil der zugeordneten Assets funktional nicht erfüllbar ist, regelt 300-1 nicht ausdrücklich. Die TPN wählt die vorsichtige Wertung: dauerhafte Nichterfüllung einer SOLLTE-Anforderung, die nach Kapitel 2.11 und 4.1.2 eine Risikobetrachtung auslöst. Behandlung: Die Gateways stehen in einem eigenen Netzsegment, das Wartungskonto ist nur über einen Sprungserver erreichbar, Anmeldungen am Wartungskonto werden protokolliert und alarmiert. Das Restrisiko geht der Institutionsleitung zur Freigabe zu (Kapitel 4.2.3). Bei der nächsten Beschaffung wird die Änderbarkeit aller Zugangsdaten Beschaffungskriterium; wie das aussieht, zeigt Beschaffung und Dienstleister.

Temporäre Nichterfüllung. Für KONF.2.4, ASST.2.2 und ASST.2.3.2 gilt dieselbe offene Auslegungsfrage wie überall in Grundschutz++: Kapitel 4.1.2 sagt, eine temporäre Nichterfüllung löse keine Risikobetrachtung aus; Kapitel 2.11 verlangt für SOLLTE-Anforderungen in der Umsetzungsplanung eine Restrisikobetrachtung und die Freigabe durch die Institutionsleitung, Kapitel 4.1.1 das Identifizieren des Risikos und die Mitteilung an die Leitung. Die TPN beschreibt das Restrisiko je Anforderung kurz, teilt es mit und lässt es bis zur Frist freigeben.

1. Hat jede Systemgruppe und jede Anwendung im Bestand eine dokumentierte und versionierte Grundkonfiguration (KONF.2.1, KONF.2.1.1, KONF.10.1, KONF.10.1.1)?
2. Steht in der Grundkonfiguration, zu welcher Anforderung eine Einstellung gehört, damit der Abgleich den Status der richtigen Anforderung trifft?
3. Sind Konfigurationswerkzeuge mit Zweck und Herkunft dokumentiert, der Zugriff auf Konfigurationen eingeschränkt und Konfigurationsgeheimnisse verschlüsselt (KONF.1.3 bis KONF.1.5)?
4. Führt das Inventar Identifikationsbezeichnung und letzten bekannten Verbleib, und das Anwendungsinventar Produktname, Version, Herkunft und Lizenz (ASST.2.2, ASST.2.3)?
5. Ist der Parameter „regelmäßig“ in KONF.2.5 und KONF.10.5 festgelegt, und liegt für jeden Turnus ein Protokoll vor?
6. Wird auch in die andere Richtung geprüft, also Netz gegen Bestand (ASST.2.2.1)?
7. Ist für jede Abweichung entschieden, ob das Ist abgewichen, das Soll veraltet oder der Bestand unvollständig ist?
8. Gehen unautorisierte Abweichungen als Ereignis an die Detektion, und autorisierte Änderungen über das Änderungsverfahren in eine neue Version der Grundkonfiguration?
9. Schließt die Außerbetriebnahme mit einem Bestandseintrag, damit ausgesonderte Systeme nicht als vermisst gelten (ASST.6.4, ASST.7.6)?

Blackfort Technology unterstützt Sie dabei mit Paket C der Umsetzung nach Grundschutz++: Statusermittlung je Anforderung, darunter KONF und ASST, und ein Nachweisplan, der Grundkonfigurationen, Inventar und die Berichte Ihrer vorhandenen Werkzeuge den Anforderungen zuordnet.

• An die Detektion: unbekannte Geräte und unautorisierte Abweichungen. Wie aus einem solchen Ereignis ein bewerteter Vorfall wird, zeigt Detektion und Vorfallsbearbeitung.
• An die Berechtigungsverwaltung: lokale Administrationsrechte, die Abweichungen erst möglich machen; siehe Berechtigungen und Personal.
• An die Beschaffung: Herstellerkonfiguration (BES.7.4.3), Komponentenbeschreibung (BES.7.4.4) und SBOM (BES.7.4.4.1) als Abnahmeunterlagen, damit Grundkonfiguration und Anwendungsinventar von Anfang an stimmen.
• An den Nachweisplan: Ein Abgleich aus der Konfigurationsverwaltung ist ein automatisierter Nachweis. Nach Kapitel 4.3 gehören Werkzeug, Prüfzeitpunkt und Ergebnis dazu; was ein solcher Nachweis nicht abdeckt, etwa Systeme ohne Agent, steht unter Automatisierte Nachweise. Die Zuordnung zu Maßnahme und Anforderung zeigt der Nachweisplan.
• An das Änderungsverfahren: autorisierte Änderungen, die eine neue Version der Grundkonfiguration brauchen; den Ablauf eines Changes zeigt Architektur, Änderungen und Entwicklung.
• Welche KONF-Anforderungen überhaupt ins Paket kommen, entscheidet die Zuordnung der Assets; siehe Modellierung und Zielobjektkategorien.