Compliance-Checks automatisieren: CIS Benchmarks & Audit-Ready Configs

Compliance für Netzwerkgeräte scheitert selten an fehlenden Sicherheitsfunktionen, sondern an fehlender Wiederholbarkeit: Konfigurationen driften, Ausnahmen werden nicht dokumentiert, und Audits basieren auf „Screenshots“ statt nachvollziehbaren Checks. Automatisierte Compliance-Checks lösen genau dieses Problem: Du definierst eine Baseline (z. B. CIS-orientiert), prüfst sie regelmäßig gegen die reale Running-Config und erzeugst auditfähige Nachweise (wer/was/waswo/ wann). Der praxisfeste Ansatz kombiniert Golden Configs, Drift Detection, kontinuierliche Prüfungen (CI für Netz) und eine saubere Exception-Policy. Dieser Artikel zeigt, wie du CIS-Benchmarks in eine automatisierbare Check-Pipeline übersetzt und „audit-ready“ Router-Konfigurationen aufbaust.

CIS Benchmarks im Netzkontext: Was du wirklich brauchst

CIS Benchmarks liefern Best-Practice-Kontrollen (z. B. SSH-Hardening, AAA, Logging, SNMPv3). Für Automatisierung ist wichtig: Benchmarks sind Text – du musst sie in maschinenprüfbare Regeln übersetzen (Presence, Values, Negatives, Kontext).

• Presence Checks: „Befehl vorhanden?“ (z. B. aaa new-model)
• Value Checks: „Wert korrekt?“ (z. B. ip ssh version 2)
• Negative Checks: „Befehl darf nicht existieren“ (z. B. Telnet)
• Context Checks: „nur in bestimmten Bereichen“ (z. B. VTY Lines)

Regeltypen (vereinfacht)

$\text{Compliance}=\text{Presence}+\text{Value}+\text{Negative}+\text{Context}$

Audit-Ready bedeutet: Evidence statt Behauptung

Für Audits brauchst du reproduzierbare Nachweise: Welche Version der Regel galt? Welche Geräte wurden geprüft? Was war das Ergebnis? Welche Exceptions sind genehmigt? „Audit-ready“ entsteht durch saubere Artefakte (Reports) und eine Change-Historie.

• Evidence: Zeitstempel, Device-ID, Config-Snapshot, Prüfergebnis
• Versionierung: Regelwerk und Templates sind versioniert (Git)
• Nachvollziehbarkeit: Exceptions mit Ticket/Owner/Expiry

Golden Config + Drift Detection: Die Grundlage jeder Compliance

Golden Config bedeutet nicht „eine Config für alle“, sondern ein standardisiertes Baseline-Template mit Variablen (Hostname, IPs, Sites). Drift Detection vergleicht Ist vs. Soll – und macht Abweichungen sichtbar, bevor sie zum Audit-Fail werden.

• Baseline-Template: Security + Management + Logging + AAA
• Device Facts: Standort, Rollenmodell, VRFs, Interfaces
• Drift: unautorisierte Änderungen oder „vergessene“ Fixes

Automatisierungsarchitektur: Von „show run“ zu Compliance Report

Ein pragmatischer Workflow ist: Konfigurationen einsammeln (CLI/API), normalisieren (Whitespace/Order), Regeln prüfen, Report erzeugen, Tickets/Alerts triggern. Wichtig ist, dass du Running- und Startup-Config bewusst behandelst.

• Collect: show running-config, optional show startup-config
• Normalize: stabile Darstellung (Parser/Canon)
• Evaluate: Regeln gegen Config-Model
• Report: PASS/FAIL + Evidence + Remediation Hint

Collection Commands (Pattern)

show running-config
show startup-config
show version
show inventory

Regeln modellieren: Prüflogik, die in der Praxis funktioniert

Netzkonfiguration ist nicht „key=value“. Viele Kontrollen sind kontextabhängig (VTY Lines, Interface-Blöcke, VRFs). Ein robustes Regelmodell arbeitet daher blockbasiert und erlaubt Ausnahmen pro Rolle (Edge vs. Core).

• Block-Parser: z. B. line vty, interface, router bgp
• Role Awareness: Core-Router haben andere Ausnahmen als Branch
• Severity: High/Medium/Low zur Priorisierung

Beispiel-Regelsets: CIS-orientierte „High Impact“ Checks

Diese Kontrollen bringen im Audit und in der Security-Praxis meist den größten Nutzen. Sie sind außerdem gut automatisierbar, weil sie klar in der Config erkennbar sind.

• SSH v2, Telnet off, VTY auf SSH-only
• AAA new-model, TACACS+/RADIUS, Accounting aktiv
• SNMP nur v3 (authPriv), keine v2c Communities
• Logging mit Zeitstempeln, zentraler Syslog, config-change logging
• NTP redundant, Timezone gesetzt, Drift monitorbar

Config-Beispiele für „Expected State“ (Pattern)

ip ssh version 2
no ip http server
no ip http secure-server
aaa new-model
logging host 10.99.20.10
service timestamps log datetime msec localtime show-timezone
ntp server 10.99.0.10 prefer
ntp server 10.99.0.11

Negative Checks: Was in audit-ready Configs nicht stehen darf

Negativlisten sind im Netzwerk extrem effektiv, weil sie schnell Drift erkennen: Telnet, unsichere HTTP Server, SNMPv2c Communities, alte Crypto-Algorithmen. Für diese Checks brauchst du klare „deny patterns“.

• Telnet: transport input telnet
• SNMPv2c: snmp-server community
• Legacy Web: ip http server (je nach Policy)

Kontext-Negativcheck (VTY Pattern)

line vty 0 4
 transport input ssh
 ! FAIL, wenn hier "telnet" erlaubt ist

Exception Handling: Ohne Ausnahmeprozess ist jede Compliance unrealistisch

Produktionsnetze haben legitime Ausnahmen (Legacy Systems, Provider-Anforderungen). Ein professionelles System behandelt das nicht als „ignorieren“, sondern als steuerbaren Prozess: Ausnahme dokumentiert, begründet, befristet, owner-basiert.

• Exception Objekt: Device/Scope, Regel-ID, Begründung
• Owner: Team/Person
• Expiry: Ablaufdatum (sonst „permanent non-compliance“)
• Compensating Controls: z. B. iACL/CoPP statt Feature-Change

Automatisierung in der Praxis: CI für Netzkonfigs

Der skalierbare Ansatz ist, Compliance nicht nur periodisch zu prüfen, sondern bei Changes: Jede Konfigänderung wird als Pull Request behandelt, Regeln laufen in CI, und erst dann wird deployt. Das verhindert Drift, bevor sie entsteht.

• PR-Workflow: Review + automatisierte Checks
• Pre-Deployment: Lint + Compliance + Diff
• Post-Deployment: Verify Commands + erneuter Compliance-Lauf

Reports: Audit-Artefakte, die wirklich zählen

Auditoren wollen keine „Tool-UI“, sondern Evidence. Ein guter Report enthält: Zeitpunkt, Gerät, Regelversion, Ergebnis, Abweichung und Remediation. Zusätzlich: Verweis auf genehmigte Exceptions.

• Device-ID, OS-Version, Timestamp
• Regel-ID und Regelversion (Git Commit)
• PASS/FAIL, betroffene Config-Zeilen/Blöcke
• Exception-Referenz (Ticket, Owner, Expiry)

Operational Best Practices: Audit-ready bleibt nur mit Betrieb

Compliance ist kein Projekt, sondern Betrieb. Diese Best Practices verhindern, dass du jedes Jahr „neu aufräumen“ musst.

• Golden Configs als Templates mit Variablen
• Regelwerk versionieren und changen wie Code
• Regel-Owner pro Domäne (AAA, SSH, SNMP, Logging)
• Regelmäßige Scans (täglich/wöchentlich) + Alerts auf Drift

Quick-Runbook: Minimaler Compliance-Check per CLI

Wenn du ohne Tool schnell eine Stichprobe brauchst, liefern diese Befehle die wichtigsten Security-Signale. Für Audits ersetzt das kein automatisiertes Evidence-System, ist aber ein guter Pre-Check.

show running-config | include aaa new-model|ip ssh|snmp-server|logging|ntp server
show running-config | section line vty
show running-config | include transport input
show logging
show ntp status

Konfiguration speichern

Router# copy running-config startup-config

Konfiguriere Cisco Router & Switches und liefere ein Packet-Tracer-Lab (CCNA)

Hallo! Ich bin ein CCNA-Network Engineer und unterstütze Sie bei Cisco Router- und Switch-Konfigurationen – inklusive eines vollständigen Cisco Packet-Tracer-Labs (.pkt). Ideal für Lern-/Übungsszenarien, Validierung oder eine saubere Demo-Topologie.

Was ich (je nach Paket) umsetze

• Switching: VLANs, Trunking (802.1Q), Port-Zuweisung, STP-Basics (PortFast/BPDU Guard wo sinnvoll)

• Routing: Default/Static Routing oder OSPF, Inter-VLAN Routing (Router-on-a-Stick)

• Services: DHCP (Pools/Scopes), NAT/PAT für Internet-Simulation

• Optional Security: Basic ACLs und SSH-Hardening

• Test & Verifikation: Ping/Traceroute + wichtige Show-Commands (mit erwarteten Ergebnissen)

Sie erhalten

• ✅ Packet Tracer .pkt Datei

• ✅ Saubere Konfigurations-Notizen pro Gerät

• ✅ Verifikations-Checkliste + erwartete Outputs

• ✅ Kurze Dokumentation (wie die Topologie funktioniert)

Bitte schreiben Sie mir vor der Bestellung, damit wir Scope, Packet-Tracer-Version, Geräteanzahl und Deadline klären.

Konfiguriere Cisco Router & Switches | Cisco Packet-Tracer-Labs. Finden Sie mich auf Fiverr.