Die Protect-Function: Schutzmaßnahmen, Zugriff und Awareness steuern

Problem in der Praxis

In vielen Organisationen ist Protect technisch breit aufgestellt und trotzdem löchrig. Firewalls, Verschlüsselung, MFA und Schulungsplattformen sind vorhanden, aber nicht konsistent gesteuert. Typische Symptome: Berechtigungen wachsen historisch und werden nie zurückgebaut, sodass Mitarbeitende über Jahre Zugriffe ansammeln; privilegierte Konten sind unzureichend von Standardkonten getrennt; Awareness-Training läuft als jährliche Pflichtübung ohne messbare Verhaltenswirkung; Datenklassifizierung existiert auf Papier, aber nicht in den Systemen, die sie durchsetzen sollen; und Plattform-Härtung hängt am Wissen einzelner Administratoren statt an verbindlichen Baselines.

Die gemeinsame Ursache ist selten fehlende Technik, sondern fehlende Verknüpfung. Protect-Maßnahmen werden projekt- und werkzeugweise eingeführt, nicht als Ergebnisse, die zu Risiken und Assets passen. Genau das adressiert CSF 2.0, indem es Protect outcome-orientiert beschreibt: nicht welches Produkt, sondern welches Schutzergebnis erreicht sein muss.

CISO-Einordnung

Laut NIST CSF 2.0 (NIST.CSWP.29, veröffentlicht am 26.02.2024) ist Protect eine der sechs Functions des Frameworks (6 Functions, 22 Categories, 106 Subcategories) und umfasst fünf Categories. Diese fünf Categories bilden die Schutzachsen, die ein CISO steuern muss:

• PR.AA (Identity Management, Authentication, and Access Control): Identitäten verwalten, authentifizieren und Zugriff nach Berechtigung steuern.
• PR.AT (Awareness and Training): Personal und relevante Dritte für ihre Sicherheitsaufgaben befähigen.
• PR.DS (Data Security): Vertraulichkeit, Integrität und Verfügbarkeit von Daten über ihren Lebenszyklus schützen.
• PR.PS (Platform Security): Hardware, Software und Dienste sicher konfigurieren, härten und betreiben.
• PR.IR (Technology Infrastructure Resilience): die Infrastruktur so auslegen, dass sie Schutz aufrechterhält und Störungen widersteht.

CSF 2.0 beschreibt diese Ergebnisse, nicht die Kontrollen im Detail, und ist nicht im ISO-Sinn zertifizierbar. Wer Protect-Ergebnisse mit Maßnahmen unterlegen will, findet die Tiefe in SP 800-53 Rev. 5 (20 Familien, 324 Basis-Controls, 872 Enhancements): für PR.AA vor allem Access Control (AC, 25 Basis-Controls) und Identification and Authentication (IA, 13); für PR.AT die Familie Awareness and Training (AT, 6); für PR.DS die breite Familie System and Communications Protection (SC, 51) und für PR.PS vor allem Configuration Management (CM, 14). Die passende Maßnahmentiefe je System ergibt sich aus den Baselines in SP 800-53B (Low, Moderate, High plus Privacy). Für PR.AA liefert zudem SP 800-207 (Zero Trust Architecture) ein Leitbild: kein impliziter Trust nach Netzstandort, Zugriff pro Session und über dynamische Policy aus Identität, Gerätezustand und Kontext.

Umsetzungsperspektive

Protect lässt sich am besten als fünf parallele Arbeitsstränge mit je eigenem Eigentümer und Reviewzyklus führen.

• PR.AA / Zugriff: Identitäten an einen zentralen Lebenszyklus binden (Joiner-Mover-Leaver), Least Privilege durchsetzen, privilegierte Zugriffe gesondert verwalten, MFA für kritische Zugänge zur Pflicht machen und Berechtigungen regelmäßig rezertifizieren. Zero Trust (SP 800-207) gibt die Richtung vor: pro Zugriff entscheiden, nicht pro Netzgrenze.
• PR.AT / Awareness: Training rollenspezifisch ausrichten statt als Einheitsmodul, Verhaltenswirkung messen und Privilegierte sowie Entwickler gesondert adressieren.
• PR.DS / Daten: Daten nach Schutzbedarf klassifizieren und die Klassifizierung technisch durchsetzen; Verschlüsselung at rest und in transit, Schlüsselmanagement und kontrollierte Löschung am Lebenszyklusende.
• PR.PS / Plattform: verbindliche Härtungs-Baselines, gesteuertes Konfigurations- und Patchmanagement und Reduktion der Angriffsfläche statt impliziter Defaults.
• PR.IR / Resilienz: Segmentierung, Redundanz und Schutzarchitektur so auslegen, dass Schutzwirkung auch unter Last und bei Teilstörungen erhalten bleibt.

Der Einstieg muss kein Großprojekt sein: ein verlässlicher Identity-Lebenszyklus mit MFA für kritische Zugänge, eine durchgesetzte Härtungs-Baseline und eine wirksame Datenklassifizierung decken die wichtigsten Protect-Ergebnisse bereits weitgehend ab.

Typische Fehler

1. Berechtigungen werden vergeben, aber nie zurückgebaut; Rezertifizierung fehlt, und Zugriffe akkumulieren über Jahre.
2. Privilegierte Konten werden wie Standardkonten behandelt, ohne gesonderte Verwaltung und Überwachung.
3. Awareness wird als Compliance-Häkchen geführt, nicht als messbare Verhaltensänderung; Privilegierte und Entwickler erhalten kein zugeschnittenes Training.
4. Datenklassifizierung bleibt ein Dokument ohne technische Durchsetzung in den Systemen.
5. Plattform-Härtung hängt an Einzelpersonen statt an verbindlichen, versionierten Baselines.
6. Protect wird als Produktbeschaffung verstanden; Werkzeuge werden eingeführt, ohne sie an Risiken, Assets und definierte Schutzergebnisse zu binden.

Risiken und Trade-offs

Schutz erzeugt Reibung, und zu viel Reibung erzeugt Umgehung. Maximale Zugriffsrestriktion ohne praktikable Prozesse führt zu Schatten-IT und Workarounds; zu lockere Steuerung führt zu unkontrolliertem Zugriff. Die Kunst liegt in risikobasierter Staffelung: starke Kontrollen dort, wo Daten und Plattformen kritisch sind, schlanke Wege für den Rest.

Ein zweiter Trade-off betrifft Zentralisierung versus Autonomie. Zentral durchgesetzte Baselines und Identity-Prozesse schaffen Konsistenz, können aber zum Engpass werden; verteilte Verantwortung mit klaren Leitplanken skaliert besser, verlangt aber belastbare Nachweise. Auch Verschlüsselung und Härtung sind nicht kostenlos: Schlüsselmanagement-Aufwand kann selbst zum Single Point of Failure werden. Awareness schließlich senkt Risiko nur, wenn sie Verhalten ändert; reine Absolvierungsquoten täuschen Wirksamkeit vor.

Entscheidungspunkte

• Welche Zugriffe sind kritisch genug, um MFA, Least Privilege und gesonderte Verwaltung privilegierter Konten verpflichtend zu machen?
• Wie oft und durch wen werden Berechtigungen rezertifiziert, und wer ist Owner des Identity-Lebenszyklus?
• Messen wir Awareness an Verhaltenswirkung oder nur an Teilnahmequoten?
• Welche Datenklassen erzwingen technisch Verschlüsselung, Zugriffstrennung und kontrollierte Löschung?
• Verbindlich oder optional: Gelten Härtungs-Baselines für alle Plattformen, und wie wird Abweichung gesteuert?
• Welche Protect-Ergebnisse steuern wir direkt im CSF, und wo unterlegen wir sie mit Controls aus SP 800-53?

Praktische Empfehlungen

1. Führen Sie Protect als fünf Arbeitsstränge (PR.AA, PR.AT, PR.DS, PR.PS, PR.IR) mit je einem Eigentümer und Reviewzyklus, nicht als Produktportfolio.
2. Verankern Sie einen zentralen Identity-Lebenszyklus mit Least Privilege, MFA für kritische Zugänge, gesonderter Verwaltung privilegierter Konten und regelmäßiger Rezertifizierung; nutzen Sie Zero Trust (SP 800-207) als Leitbild.
3. Richten Sie Awareness rollenspezifisch aus und messen Sie Verhaltenswirkung statt Absolvierungsquoten.
4. Klassifizieren Sie Daten nach Schutzbedarf und setzen Sie die Klassifizierung technisch durch (Verschlüsselung, Zugriffstrennung, kontrollierte Löschung).
5. Machen Sie Härtungs-Baselines und Konfigurations-/Patchmanagement verbindlich und versioniert.
6. Unterlegen Sie kritische Protect-Ergebnisse mit Controls aus SP 800-53 Rev. 5 (AC, IA, AT, SC) und wählen Sie die Tiefe risikobasiert anhand der Baselines in SP 800-53B.

Relevante Normreferenzen

• NIST CSF 2.0 (NIST.CSWP.29, 26.02.2024): Function Protect (PR) mit den Categories PR.AA, PR.AT, PR.DS, PR.PS und PR.IR. Public Domain.
• NIST SP 800-53 Rev. 5: Kontrollkatalog, insbesondere die Familien Access Control (AC), Identification and Authentication (IA), Awareness and Training (AT) und System and Communications Protection (SC). Public Domain.
• NIST SP 800-53B: Control Baselines (Low/Moderate/High plus Privacy) zur risikobasierten Auswahl der Maßnahmentiefe. Public Domain.
• NIST SP 800-207 (Zero Trust Architecture): Leitbild für identitäts- und kontextbasierten Zugriff (PR.AA). Public Domain.
• Ergänzend SP 800-171 (Schutz von CUI in nicht-bundesstaatlichen Systemen) für Datensicherheit in Lieferketten; Anforderungszahlen vor Nutzung an der Originalpublikation prüfen. Public Domain.