Security: CIS

Siehe auch

Verwandte Artikel
Offizielle Dokumentation

CIS (Center for Internet Security) ist eine 2000 gegründete US-Non-Profit-Organisation, die zwei für Linux-Admins relevante Produktlinien pflegt: die allgemeinen CIS Controls und die technologie-spezifischen CIS Benchmarks. Beide werden regelmässig gegen aktuelle Bedrohungen überarbeitet.

Die CIS Controls (aktuell v8.1) sind ein High-Level-Framework mit 18 Control-Gruppen - eher Governance als konkrete Kommandos. Die CIS Benchmarks dagegen sind stark präskriptive Hardening-Guides pro Produkt (RHEL, Debian, Ubuntu, Kubernetes, Apache httpd, Tomcat, MariaDB und viele mehr) mit konkreten Konfigurationsregeln. Dieser Artikel behandelt primär die Benchmarks; mit „CIS-Controls“ ist im Alltag fast immer eine konkrete Regel aus einem Benchmark gemeint, nicht das Control-Framework.

Begriffe

AAC (Automated Assessment Content)

Die maschinenlesbare Fassung eines Benchmarks, die CIS-CAT Pro einliest, um den Compliance-Stand eines Systems zu ermitteln. AAC-Änderungen erzeugen eine vierte Versionskomponente (x.x.x.x), die nur die Automatisierung korrigiert und nicht das PDF.

Benchmark

Konkretes Hardening-Dokument pro Zielsystem. Ein Benchmark enthält pro Abschnitt mehrere Recommendations, die zusammen das Profil (Level 1 oder 2) ergeben.

CIS Controls

Oberbegriff für das Framework (v8.1) mit 18 abstrakten Control-Gruppen wie „Inventory and Control of Enterprise Assets“. Nicht zu verwechseln mit den Recommendations innerhalb eines Benchmarks.

CIS-CAT

CIS Configuration Assessment Tool. Die kommerzielle Pro-Variante scannt ein System gegen das AAC und liefert einen Compliance-Report. Die kostenlose Lite-Variante deckt nur eine begrenzte Auswahl an Benchmarks ab.

Level 1 / Level 2

Profile innerhalb eines Benchmarks. Level 1 bündelt grundlegende Härtungsmassnahmen, die in den meisten Umgebungen nebenwirkungsfrei greifen. Level 2 ergänzt strengere Regeln für höhere Sicherheitsanforderungen; diese können die Funktionalität einschränken. Level 2 schliesst Level 1 ein.

Recommendation

Einzelne Regel in einem Benchmark, z.B. „1.1.1.1 Ensure cramfs kernel module is not available“. Jede Recommendation hat Profile-Applicability, Description, Rationale, Impact, Audit, Remediation und References.

Server / Workstation

Zwei orthogonale Profile, die pro Recommendation festlegen, ob sie für Server- oder Workstation-Installationen gilt. Ein Benchmark hat typisch vier Profile: Level 1 Server, Level 2 Server, Level 1 Workstation, Level 2 Workstation.

Benchmarks beziehen

Drei Wege:

  • Aktuelle PDFs (x.x.x): https://downloads.cisecurity.org - erfordert nur eine E-Mail-Bestätigung.

  • Detaillierte Arbeitsfassung inklusive Kommentarverlauf: https://workbench.cisecurity.org (Account erforderlich; auch die Fehler-Tickets und Änderungsanträge liegen hier).

  • Vierte Versionskomponente (x.x.x.x): nur über die Workbench oder das CIS-CAT-Produkt erreichbar; korrigiert ausschliesslich AAC-Bugs, keine Inhalte des PDFs.

Struktur eines Benchmarks

Der Aufbau ist über alle Linux-Benchmarks hinweg ähnlich. Am Beispiel des CIS Red Hat Enterprise Linux 10 Benchmark v1.0.1:

  1. Initial Setup - Filesystems und Kernel-Module (cramfs, squashfs, usb-storage, …), Partitionierungs-Optionen (nodev, nosuid, noexec), Paketmanagement, Mandatory Access Control (SELinux), Bootloader, Process-Hardening, systemweite Crypto-Policy, Login-Banner, GDM.

  2. Services - Server- und Client-Dienste (inetd/xinetd, autofs, nis, rsh, talk etc.), Zeit-Sync, Job-Scheduler (cron, at).

  3. Network - Netzwerk-Devices, Kernel-Module, sysctl-Parameter (z.B. net.ipv4.conf.all.accept_source_route).

  4. Host Based Firewall - firewalld (bzw. nftables, iptables).

  5. Access Control - SSH-Server, Privilege Escalation (sudo), PAM, Benutzerkonten und Umgebung.

  6. Logging and Auditing - rsyslog/journald und auditd-Regelsatz.

  7. System Maintenance - Berechtigungen auf Systemdateien und -verzeichnissen.

Jede Recommendation folgt einer festen Vorlage:

1.1.1.1 Ensure cramfs kernel module is not available (Automated)
    Profile Applicability:
      * Level 1 - Server
      * Level 1 - Workstation
    Description:   What exactly is being controlled, in plain prose.
    Rationale:     Why the setting matters from a security perspective.
    Impact:        What breaks or changes for the user.
    Audit:         Exact command(s) to verify compliance.
    Remediation:   Exact command(s) to reach compliance.
    Default Value: What ships by default in a base install.
    References:    CVEs, NIST mappings (SP 800-53), MITRE, vendor docs.
    CIS Controls:  Mapping to the high-level CIS Controls v8.1.

Zwei Labels pro Recommendation sind besonders relevant:

(Automated) bedeutet, dass die Regel sich per AAC automatisch prüfen und in vielen Fällen auch durchsetzen lässt. (Manual) heisst, dass die Regel einen menschlichen Entscheid erfordert - etwa, ob ein Paket im Bestand wirklich nicht gebraucht wird.

Level 1 vs. Level 2

Die Profile unterscheiden sich in Strenge und Nebenwirkungen:

Level 1

Grundabsicherung, die in praktisch jeder Umgebung anwendbar sein sollte, ohne die Funktionalität spürbar einzuschränken. Deckt die häufigsten Angriffswege ab und ist der Minimalstandard für einen produktiven Server.

Level 2

Baut auf Level 1 auf und fügt strengere Kontrollen hinzu, die die System-Funktionalität beeinträchtigen können: weitergehende Modul-Blacklists, strikte umask-Werte, Audit-Regeln mit messbarer Performance-Wirkung, zwingende Trennung von Partitionen. Sinnvoll in regulierten Branchen (Finanz, Gesundheit) oder bei sensitiven Workloads.

Die Auswahl ist keine Technik-, sondern eine Governance-Entscheidung: welche Kontrollen akzeptiert die Organisation mit welchen Betriebseinschränkungen?

Umsetzungs-Werkzeuge

Die Regeln manuell umzusetzen ist möglich, aber fehleranfällig. Drei etablierte Tool-Wege:

CIS-CAT Pro Assessor

Das kommerzielle Scan-Tool von CIS selbst. Liest die AAC-XCCDF/OVAL-Dateien und liefert einen Compliance-Report (HTML/CSV/XML). Keine Remediation, nur Audit. Lizenzierung über CIS SecureSuite Membership.

OpenSCAP mit SCAP Security Guide (SSG)

Der Open-Source-Scanner aus dem Red-Hat-Umfeld. scap-security-guide liefert CIS-Profile (xccdf_org.ssgproject.content_profile_cis_server_l1, ..._l2, ..._workstation_l1, ..._workstation_l2). Auswertung per oscap xccdf eval oder während der Anaconda-Installation direkt als Security-Policy. Remediation per oscap xccdf remediate oder oscap xccdf generate fix.

Ansible

Die SSG-Profile erzeugen auch Ansible-Playbooks zur Remediation. Für gezielte Teil-Härtung gibt es zusätzlich die Rollen in openstack/ansible-hardening und DISA-STIG-Sammlungen.

Die Linuxfabrik setzt Remediation-Schritte in weiten Teilen über LFOps um. Rollen mit CIS-relevanten Settings sind unter anderem crypto_policy, firewall, sshd, audit, selinux, mount und kernel_settings.

Aufwand der Umsetzung

Ein durchgängig gehärtetes RHEL-10-System nach CIS L2 kostet spürbar Betriebszeit:

  • Umfang: ein aktueller RHEL-Benchmark umfasst weit über 200 Recommendations. Etwa zwei Drittel lassen sich automatisiert anwenden; der Rest verlangt manuelle Entscheidungen.

  • Software-Kompatibilität: manche Regeln brechen Anwendungen (z.B. noexec auf /var, strenge SELinux-Booleans, deaktivierte Module). Vor dem Rollout gegen ein Test-Image fahren und Exceptions dokumentieren.

  • Drift: jede Major-Version des Benchmarks bringt neue Regeln und zieht alte zurück. Gehärtete Systeme brauchen ein Re-Scan-Intervall und ein dokumentiertes Delta zum Vorstand.

  • Audit-Last: auditd mit vollem CIS-Regelsatz erzeugt pro Tag gerne hunderte MByte Logs. Log-Rotation und zentrale Aggregation sind Pflicht.

Bemerkung

Installation von RHEL 8+ und kompatible: Das Partitionierungsschema wird von der Anaconda-Security-Policy „CIS“ nicht automatisch angepasst. Entweder Handarbeit oder ein passendes Kickstart-File einsetzen.