Identify: Asset-, Risiko- und Kontexttransparenz schaffen

Problem in der Praxis

Die häufigste Schwachstelle ist nicht ein offener Port, sondern ein unbekanntes System. Organisationen betreiben mehr Assets, als sie inventarisiert haben: vergessene Server, nicht erfasste SaaS-Dienste, privat beschaffte Cloud-Tenants, Schatten-IT in Fachbereichen, OT-Komponenten ohne Eigentümer. Was nicht im Inventar steht, wird nicht gepatcht, nicht überwacht und im Ernstfall nicht wiederhergestellt.

Selbst dort, wo Inventare existieren, sind sie oft auf Hardware reduziert. Es fehlt das Wesentliche: Welche Daten verarbeitet ein System, wohin fließen sie, von welchen anderen Systemen und Dienstleistern hängt es ab? Ein Asset-Inventar ohne Datenfluss- und Abhängigkeitssicht beantwortet nicht die Frage, was der Ausfall einer Komponente für das Geschäft bedeutet. Parallel laufen Schwachstellenscans, deren Befunde in die Tausende gehen, ohne Bezug zur Kritikalität der betroffenen Assets. Das Ergebnis ist eine Liste, keine Priorisierung. Und die Bedrohungslage wird selten systematisch mit dem eigenen Asset-Bestand verschnitten, sodass relevante Angriffsmuster nicht von irrelevanten getrennt werden.

CISO-Einordnung

Identify ist die Erkenntnis-Function des Frameworks. Laut NIST CSF 2.0 (NIST.CSWP.29, veröffentlicht am 26.02.2024) gliedert sie sich in drei Categories. Wichtig für die Abgrenzung: Mit CSF 2.0 wanderten die strategischen Themen, die in früheren Fassungen unter Identify lagen, in die neue Function Govern. Risikostrategie, Risikoappetit, Rollen und Lieferkettensteuerung sind heute Govern (GV); Identify konzentriert sich auf das Verstehen von Assets, Risiken und Verbesserungspotenzial.

Daraus folgt eine klare Arbeitsteilung: Govern entscheidet, welche Risiken die Organisation eingeht und wer sie verantwortet; Identify liefert die Fakten, auf deren Grundlage diese Entscheidungen überhaupt erst möglich sind. Wer beides vermischt, produziert entweder Strategie ohne Datenbasis oder Inventare ohne Entscheidungsbezug.

Die outcome-orientierten Identify-Ergebnisse lassen sich mit Controls aus SP 800-53 Rev. 5 (20 Familien, 324 Basis-Controls, 872 Enhancements) unterlegen. Das Asset-Inventar findet seine Tiefe in CM-8 (System Component Inventory) aus der Configuration-Management-Familie. Der Risiko- und Bedrohungskontext liegt in der Risk-Assessment-Familie (RA): RA-3 (Risk Assessment), RA-5 (Vulnerability Monitoring and Scanning), RA-9 (Criticality Analysis), RA-7 (Risk Response) und RA-10 (Threat Hunting). Diese Controls sind das operative Pendant zu den abstrakten Identify-Outcomes.

Umsetzungsperspektive

Identify entsteht nicht durch ein einmaliges Inventarprojekt, sondern durch dauerhaft gepflegte Transparenz. Bewährt hat sich, die drei Categories als zusammenhängende Fähigkeiten aufzubauen.

• Asset Management (ID.AM): Ein autoritatives Inventar über Hardware, Software, Dienste und Daten, mit Eigentümer, Kritikalität und Standort je Eintrag. CM-8 verlangt ein Inventar in der nötigen Granularität, frei von Doppel- und Lücken, regelmäßig aktualisiert. Erweitern Sie es um Datenflüsse und Abhängigkeiten, auch zu externen Systemen und Dienstleistern, damit die Geschäftswirkung eines Ausfalls sichtbar wird.
• Risk Assessment (ID.RA): Schwachstellen kontinuierlich erfassen (RA-5), kritische Komponenten über eine Kritikalitätsanalyse herausarbeiten (RA-9) und Schwachstellen- mit Bedrohungswissen verschneiden. Eine Threat-Hunting-Fähigkeit (RA-10) und strukturierte Risikobewertung (RA-3) heben den Kontext von der Liste zur priorisierten Risikosicht.
• Improvement (ID.IM): Erkenntnisse aus Tests, Übungen, Vorfällen und Audits systematisch in Verbesserungen überführen. RA-7 (Risk Response) verbindet Befunde mit der Risikotoleranz und macht aus Erkenntnis Handlung.

Der Einstieg muss nicht perfekt sein. Ein verlässliches Kern-Inventar der kritischsten Systeme, ergänzt um deren Datenflüsse und Abhängigkeiten, schlägt ein vollständiges, aber veraltetes Verzeichnis. Automatisierte Erfassung und ein klarer Pflegeprozess sind wichtiger als ein hoher Anfangsstand.

Typische Fehler

1. Das Inventar erfasst nur Hardware. Software, Daten, Dienste, Cloud-Tenants und externe Abhängigkeiten fehlen, und damit fehlt der Geschäftsbezug.
2. Schwachstellenscans erzeugen Befundlisten ohne Kritikalitätsbezug. Es wird nach CVSS sortiert statt nach Wirkung auf kritische Assets.
3. Bedrohungswissen und Asset-Bestand bleiben getrennt. Threat Intelligence wird konsumiert, aber nie mit dem eigenen Inventar verschnitten.
4. Das Inventar wird einmal erstellt und veraltet sofort, weil kein kontinuierlicher Pflege- und Aktualisierungsprozess existiert.
5. Identify wird mit Govern vermischt: Es entstehen Risikostrategien ohne Datenbasis oder Inventare, die nie in Entscheidungen münden.

Risiken und Trade-offs

Transparenz hat Grenzkosten. Ein Inventar in maximaler Granularität ist teuer in der Pflege und veraltet schnell; ein zu grobes verfehlt seinen Zweck. CM-8 fordert bewusst die für Steuerung und Nachverfolgung nötige Granularität, nicht die maximale. Detailtiefe wird an Kritikalität gekoppelt: kritische Systeme tief, unkritische schlank.

Ein zweiter Trade-off betrifft Vollständigkeit gegen Aktualität. Wer auf ein vollständiges Inventar wartet, bevor er handelt, verliert Zeit; wer Aktualität über Vollständigkeit stellt, beginnt mit dem Kritischen und wächst. Automatisierte Discovery reduziert den Konflikt, schafft ihn aber nicht ab, weil OT, Schatten-IT und Drittsysteme sich der Automatik oft entziehen. Schließlich erzeugt umfassende Transparenz selbst ein schützenswertes Gut: Ein vollständiges Inventar mit Datenflüssen und Schwachstellen ist für Angreifer hochattraktiv und muss entsprechend geschützt werden.

Entscheidungspunkte

• Welche Assetklassen erfassen wir verbindlich: Hardware, Software, Daten, Dienste, Cloud, OT, externe Abhängigkeiten?
• In welcher Granularität inventarisieren wir, und wie koppeln wir Detailtiefe an Kritikalität?
• Wie verschneiden wir Schwachstellen- und Bedrohungskontext mit dem Asset-Bestand, um echte Priorisierung statt Befundlisten zu erhalten?
• Wer ist Eigentümer des Inventars, und in welchem Zyklus wird es aktualisiert und auf Vollständigkeit geprüft?
• Wie führen wir Erkenntnisse aus Vorfällen, Tests und Audits in messbare Verbesserung (ID.IM) zurück?

Praktische Empfehlungen

1. Bauen Sie ein autoritatives Asset-Inventar (CM-8) über alle Assetklassen auf, je Eintrag mit Eigentümer und Kritikalität, und ergänzen Sie es um Datenflüsse und Abhängigkeiten.
2. Koppeln Sie Schwachstellenmanagement (RA-5) an die Kritikalitätsanalyse (RA-9), damit Priorisierung der Geschäftswirkung folgt, nicht nur der Scoring-Zahl.
3. Verschneiden Sie Bedrohungswissen mit dem Inventar und entwickeln Sie bei entsprechender Reife eine Threat-Hunting-Fähigkeit (RA-10).
4. Etablieren Sie einen kontinuierlichen Pflegeprozess statt eines Inventarprojekts; Aktualität im Kritischen schlägt Vollständigkeit im Veralteten.
5. Schließen Sie den Kreis über Improvement (ID.IM) und Risk Response (RA-7): Erkenntnisse aus Tests, Übungen und Vorfällen werden in priorisierte Maßnahmen überführt und an Govern zurückgespiegelt.

Relevante Normreferenzen

• NIST CSF 2.0 (NIST.CSWP.29, 26.02.2024): Function Identify (ID) mit den Categories Asset Management (ID.AM), Risk Assessment (ID.RA) und Improvement (ID.IM). Public Domain.
• NIST SP 800-53 Rev. 5: Kontrollkatalog, insbesondere CM-8 (System Component Inventory) sowie die Risk-Assessment-Familie (RA), darunter RA-3, RA-5, RA-7, RA-9 und RA-10. Public Domain.
• NIST SP 800-37 (RMF), SP 800-30 (Risikobewertung), SP 800-137 (ISCM): unterstützende Prozesse für Risikobewertung, Kritikalitätsanalyse und kontinuierliche Überwachung. Public Domain.
• Abgrenzung: NIST CSF 2.0 Function Govern (GV) trägt Risikostrategie, Rollen und Lieferkettensteuerung; Identify liefert hierfür die Faktenbasis.