Bäume sind keine Graphen.

John Lambert hat 2015 einen treffenden Text geschrieben. Der Titel lautet: "Defenders think in lists. Attackers think in graphs. As long as this is true, attackers win." Nun sind mehr als 10 Jahre vergangen und fast alle Frameworks haben eine Revision bekommen. Dazu zählen das IT-Grundschutz-Kompendium in der Edition 2023, NIST CSF 2.0 kam 2024, die VDA ISA in Version 6. Zusätzlich haben die Five-Eyes-Behörden 2024 ein gemeinsames Papier zu Active-Directory-Kompromittierung veröffentlicht. Die Frage ist: Haben die Frameworks Lamberts Lektion aufgenommen? Meine Antwort: manche nein, weil sie es strukturell nicht können, manche ja, weil sie anders gebaut sind. Und das Problem sind nicht mehr Listen. Es sind jetzt Bäume.

Es ist eine Standardfrage in jedem Audit: "Ist eine Netzwerksegmentierung vorhanden?" Antwort: "Ja." Haken dran, alle zufrieden.

Dies ist aber nur die eine Hälfte der Segmentierung. Denn Segmentierung hat zwei Ebenen: das Netzwerk und die Identität. Die Frage "Ist eine Netzwerk-Segmentierung vorhanden?" prüft nur die erste.

Warum das nicht reicht? Weil auch geprüft werden muss, ob Büro und Produktion in derselben Active-Directory-Gesamtstruktur sitzen. Wenn dem so ist, ist die Zonengrenze auf Netzwerkebene sauber, aber nicht auf Identitätsebene. Eine Identität könnte sich dann auf Produktionsclients und Büroclients anmelden.

Im besten Fall steht ein Pentester mit dem Golden Ticket im Büro und hat vollen Zugriff auf jedes Windows-Gerät, auch in der Produktion. Im schlechtesten Fall liegt die Produktion still, wegen Ransomware.

Segmentierung hat einen Zweck: Verkleinerung des Blast-Radius (Schadensbegrenzung). Wenn im Büro ein Client kompromittiert wird, soll die Produktion weiterlaufen. Das ist die ganze Idee. Eine Zone ist die Menge an Systemen, die gemeinsam fallen dürfen, und die Grenze dazwischen ist das, was den Rest schützt.

Eine Firewall zwischen zwei Subnetzen liefert genau das, sie kontrolliert den Verkehr zwischen Netzwerksegmenten anhand von Regeln. Die Regeln können aus IP-Adressen, Ports und Protokollen bestehen, manche sogar anhand von Zeiten. Das Problem beginnt, wenn beide Seiten der Grenze demselben Verzeichnisdienst vertrauen.

Damit ein Produktionsrechner überhaupt Domänenmitglied sein kann, muss die Firewall vom Produktionssegment zum Domain Controller einiges durchlassen: Kerberos (88), LDAP (389/636), SMB (445), RPC (135 plus dynamischer Bereich 49152 bis 65535) und DNS (53). Es gibt keine Anmeldung oder Gruppenrichtlinien, wenn diese Ports geblockt werden.

Der Angreifer braucht genau das, nicht mehr und nicht weniger. Mit einem Ticket-Granting-Ticket holt er sich ein Service-Ticket für den Produktionsrechner, geht über SMB 445 (PsExec) oder WinRM 5985 auf die Maschine und ... "Game Over".

Kein einziges Paket verletzt eine Firewall-Regel. Das Firewall-Log ist sauber. Nur leider legt der Angreifer damit die Produktion lahm.

Falls Sie denken, betrifft mich nicht. Ich nutze Entra ID und Hybrid Join. Es wird nicht besser, nur anders: Ein Global Admin oder Intune Admin verteilt ein Skript über die Management-Cloud auf alle Clients, denn per Definition muss die Management-Cloud von überall erreichbar sein. Die Netzwerkzone ist hier komplett irrelevant.

Ein paar Beispiele, wo es bestimmt eine Netzwerksegmentierung gab, aber ein gemeinsamer Verzeichnisdienst genutzt wurde. Oder es wurde ein Client genutzt, um sich auf Büroclients und Produktionsclients zu verbinden, auch wenn zwei unterschiedliche Accounts genutzt wurden. Das ist ein Teil vom lateral movement. Schauen welche Identitäten und Kennwörter werden auf dem Client genutzt und wo funktionieren sie noch.

Norsk Hydro, März 2019: LockerGoga wurde konzernweit verteilt und erreichte Produktionsstandorte weltweit, Werke liefen auf Handbetrieb, Gesamtkosten laut Geschäftsbericht 2019 NOK 650 bis 750 Millionen.

NotPetya 2017: Credential-Diebstahl im Speicher, dann PsExec und WMI über genau die Kanäle, die für die Administration ohnehin offen sind. Bei Merck stand die Produktion wochenlang.

Jetzt der Teil, der mir wichtiger ist als die Firewallregeln.

Die Auditierenden haben alles richtig gemacht. Sie haben den Fragenkatalog befolgt. Auch der Katalog ist korrekt. Jede einzelne Anforderung darin stimmt. Wie kann es dann passieren, dass diese Lücke entsteht? Der Grund dafür ist ein struktureller.

Ein Control-Katalog ist eine Taxonomie. Jedes Thema braucht seinen Bereich: Netzwerkarchitektur auf dem einen Ast (Kapitel), Verzeichnisdienst auf einem anderen. Damit ein Katalog prüfbar sein kann, werden eindeutige Anforderungen mit Zuordnung benötigt. Somit ist jede Anforderung einzeln abhakbar. Diese Struktur hat einen Namen. Baum.

Ein Baum hat nun aber keine Querkanten. Die Aussage "der Produktionsrechner vertraut dem Büro-Domain Controller" verbindet ein Objekt aus dem Netzwerk-Ast mit einem Objekt aus dem Verzeichnis-Ast. Für diese Querverbindung gibt es im Baum keinen Ort, und deshalb auch keine passende Anforderung. Nicht, weil die Autorinnen und Autoren des Katalogs Active Directory nicht verstanden hätten. Sondern weil die Struktur die Frage nicht darstellen kann.

Der Angreifer hat dieses Problem nicht. Er sieht Knoten (Konten, Rechner, Gruppen, Sessions) und Kanten (ist Mitglied von, ist Admin auf, hat Session auf, darf schreiben in) und sucht einen Pfad vom Büro-Client zum Produktionsrechner. Das ist BloodHound. BloodHound findet den Pfad über den Domain Controller, weil der Weg über den Domain Controller aus normalen Kanten besteht. Die Firewall taucht in dem Graphen nur als Filter auf einigen Kanten auf, und die Kanten, die er braucht, sind offen.

Ich möchte die Aussage von Lambert verschärfen: Listen sind nicht das Problem. Eine Liste kann jede Frage enthalten, auch die nach dem Verzeichnisdienst. Das Problem ist, die Listen werden aus Katalogen erstellt, die Bäume sind, und Bäume kennen keine Querkanten.

Ich habe das Kompendium (Edition 2023) durchforstet. Das Ergebnis: Es steht alles drin, aber nur für hohen Schutzbedarf. Bei normalem Schutzbedarf wird die Frage aber nicht gestellt.

Im Detail:

Netzwerk-Seite, NET.1.1 Netzarchitektur und -design. A4 verlangt mindestens drei Zonen (intern, DMZ, extern) mit Firewall an den Zonenübergängen. A5 trennt Clients von Servern. A6 sagt: "Es DÜRFEN NUR Endgeräte in einem Netzsegment positioniert werden, die einem ähnlichen Sicherheitsniveau entsprechen." Das ist die einzige Stelle, aus der sich eine Segmentierung zwischen Büro und Produktion ableiten lässt. A21 sagt, dass die Systeme, die administrative Kommunikation authentisieren und autorisieren, in ein eigenes Management-Segment gehören.

OT-Seite, IND.1 Prozessleit- und Automatisierungstechnik. Der Baustein sagt selbst, dass die physische Trennung der OT "heute aufgrund zunehmender Integrationsanforderungen nur in Ausnahmefällen bei erhöhtem Schutzbedarf anwendbar" ist. Air Gap ist vorbei, Segmentierung ist die Antwort. A4 will Zonen und Conduits, A5 will, dass Steuerungszonen beim Ausfall anderer Zonen weiterlaufen und "die Abkopplung nach einem Angriff weiter funktionieren" soll. Genau das ist mit einem gemeinsamen Domain Controller nicht erfüllbar. Wer das Büro abkoppelt, kappt die Anmeldung am Produktionsrechner gleich mit. A14 (nur für hohen Schutzbedarf) empfiehlt einen zentralen Verzeichnisdienst für privilegierte OT-Nutzende, mit dem Hinweis, dass "daraus entstehende Abhängigkeiten in der Authentisierung bekannt sind". Welcher Verzeichnisdienst, welche Gesamtstruktur: offen.

OT-Seite, IND.3.2 Fernwartung. Die Büro-IT ist aus OT-Sicht eine "nur eingeschränkt vertrauenswürdige Zone", und A7 erwartet, dass jeder Zugriff in eine OT-Zone über einen Jump-Server in einer eigenen DMZ gemacht wird. Sie gilt aber nur für Fernwartung.

Identitäts-Seite, APP.2.2 Active Directory Domain Services. Hier steht der entscheidende Satz, gleich in der Gefährdungslage: "Die Gesamtstruktur stellt also systembedingt die Sicherheitsgrenze dar, innerhalb derer Informationen standardmäßig im AD DS weitergegeben werden. Eine Domäne bildet dabei nur eine Verwaltungsgrenze." Und A20, erst im Bereich für hohen Schutzbedarf: "Organisationseinheiten, die aus IT-Sicherheitsgründen oder sonstigen Gründen Unabhängigkeit voneinander gewährleisten müssen, SOLLTEN sich nicht in der gleichen Gesamtstruktur befinden." Büro und Produktion getrennt, ohne dass das Wort "Produktion" fällt, und nur als SOLLTE für hohen Schutzbedarf. APP.2.2 kennt dafür das Wort "Zone" nicht.

Drei Bausteine, jeder für sich korrekt. NET.1.1 kennt keine Gesamtstruktur. IND.1 kennt keine Gesamtstruktur. IND.3.2 gilt nur für Fernwartung und APP.2.2 kennt keine Zone. Die Audit-Checkliste fragt NET.1.1.A4 (Basis, MUSS) und bekommt ein "Ja". APP.2.2.A20 wird bei normalem Schutzbedarf gar nicht gefragt. Drei Äste, keine Querkante.

Dieselbe Dualität, jedes Mal an einer anderen Stelle versteckt.

ISO 27001. Das Loch sitzt in der Risikobewertung. Annex A unter 8.22 "Segregation of networks" (2013: A.13.1.3) beschreibt die Netzwerksegmentierung. Die Identitätsseite liegt in 8.2 "Privileged access rights" sowie 5.15, 5.16 und 5.18. ISO kennt keine Stufen. Ob 8.22 wirkt, entscheidet die eigene Risikobewertung. Wurde die Frage dort nie gestellt, ist die gemeinsame Gesamtstruktur konform. Haken bei 8.22, Zertifikat an der Wand.

NIST CSF 2.0. Das Loch sitzt im Profil. Segmentierung ist PR.IR-01 (1.1: PR.AC-5). Die "Implementation Examples" sind sehr genau: Netze nach Vertrauensgrenzen und Plattformtypen segmentieren, nur benötigte Kommunikation erlauben, Zero Trust als Option. "Vertrauensgrenze" ist das Wort, das anderen Frameworks fehlt. Was eine ist, sagt der CSF nicht. Identität liegt in PR.AA. Der CSF benennt Ergebnisse, die Tiefe legt die Organisation im eigenen Target Profile fest. Wer dort "VLANs plus Firewall" einträgt, hat das Outcome erreicht. Zusammengeführt werden beide Ebenen erst in SP 800-207, Zero Trust Architecture. Das Beispiel im CSF nennt Zero Trust nur als Option, verlinkt aber nicht auf das Dokument. Einfordern tut es der CSF nicht.

TISAX (VDA ISA 6). Das Loch sitzt im Reifegrad. Ein 27002-Derivat mit Reifegradbewertung: Netzwerk in Kapitel 5, Identitäten und privilegierte Konten in Kapitel 4. Bewertet wird, ob ein Prozess existiert, dokumentiert ist und gelebt wird. Segmentierungskonzept, VLAN-Diagramm, Firewall-Regeln, jährlicher Review: Reifegrad 3. Ob das Konzept die Vertrauensgrenze richtig gezogen hat, ist keine Reifegradfrage. Die Fertigung kommt in Control 5.2.7 sogar vor. Sie dient als Beispiel für Netze mit unterschiedlichem Betriebszweck und die getrennt gehören: Test, Büro, Fertigung. Aber mal wieder als Netzsegment. Die Referenzen des Controls zeigen ausschließlich auf Netzwerk-Controls anderer Kataloge. Welche Identitäten auf beiden Seiten genutzt werden, fragt weder 5.2.7 noch Kapitel 4. TISAX-Label an der Wand, Werk und Büro in einem Forest, alles regelkonform.

IEC 62443. Das Loch sitzt im Conduit, und das ist der interessanteste Fall. 62443 ist kein Baum. Zonen sind Knoten, Conduits sind Kanten. Damit haben wir ein Graphmodell. Büro- und Anlagensysteme gehören in getrennte Zonen (62443-3-2, ZCR 3.2). Trotzdem: Kerberos, LDAP und SMB vom Produktionssegment zum Büro-Domain Controller sind ein dokumentierter, bewerteter, am Zonenrand gefilterter Conduit. Formal alles richtig. Dass dieser Conduit die Identität über die Grenze transportiert und damit die Zonengrenze auflöst, erkennt das Modell nicht, weil seine Kanten Netzwerkverbindungen sind. Ein Graph allein reicht also auch nicht.

Die Gegenbeispiele sind das Schönste an der Recherche. Sie zeigen, dass es möglich ist.

PCI DSS: der Graph steht vor der Liste. Es hat zwölf Requirements und ist ein klassischer Katalog. Aber der Scope wird über Verbindungen bestimmt: Systeme, die dem Cardholder Data Environment Sicherheitsdienste liefern, allen voran Authentisierung, sind "connected-to" und damit tadaa im Scope. Wer seinen Büro Domain Controller für die Kassensysteme nutzt, hat den Domain Controller im Scope, und mit ihm praktisch die Domäne. "Liefert Authentisierung für" ist dort eine Kante. Dazu Requirement 11.4.5: Segmentierung wird per Penetrationstest validiert, nicht per Diagramm. Die Liste ist dieselbe Datenstruktur wie überall. Angewendet wird sie auf das Ergebnis einer Erreichbarkeitsabfrage.

ANSSI: die Kante heißt "chemin de contrôle". Die französische Behörde definiert in ihrem AD-Guide (ANSSI-PA-099, 2023) den Kontrollpfad als Kette logischer Beziehungen zwischen AD-Objekten und sagt, dass Kontrollpfade zwischen Objekten verschiedener Vertrauenszonen potenzielle Angriffspfade sind. Der Forest ist dort der minimale Sicherheitsperimeter, Domänen als Vertrauenszonen zu nutzen ist explizit schlechte Praxis. Das ist der Angreifergraph, von der verteidigenden Seite gezeichnet, inklusive der Querkante.

Die Strukturanalyse mit ihren Abhängigkeiten und die Schutzbedarfsvererbung (Maximumprinzip, Kumulationseffekt) sind eine Vererbung entlang eines Abhängigkeitsgraphen: Anwendung braucht System braucht Netzwerk. Wenn in der Strukturanalyse steht "Produktions-HMI ist abhängig von der Anmeldung am Büro Domain Controller", erbt der Büro Domain Controller per Maximumprinzip den Schutzbedarf der Produktion, wird "hoch", und damit werden für APP.2.2 die Anforderungen für hohen Schutzbedarf fällig. Inklusive A20. Das Loch im Katalog schließt sich von selbst, sobald die Kante eingetragen ist. Es fehlt kein Baustein. Es fehlt eine Zeile in der Strukturanalyse. Diese fehlt fast immer, weil Authentisierung "nur" ein Dienst (etwas virtuelles) ist und kein Server (etwas physisches), den jemand anfasst.

Statt "Ist eine Netzwerksegmentierung vorhanden?" schlage ich vor:

"Kann sich eine Identität aus einem Verzeichnisdienst einer unsicheren Zone an einem Client in einer sicheren Zone anmelden?"

Das ist eine Checklistenfrage, und das ist auch eine Erreichbarkeitsabfrage auf dem Vertrauensgraphen: Gibt es einen Pfad von einem Büro-Konto zu einem Produktionssystem, der keine Firewall-Regel verletzt? Wenn die Antwort "Nein" lautet, gibt es eine Produktionszone. Wenn die Antwort "Ja" lautet, gibt es zwei Subnetze mit einer Firewall dazwischen, die den Angreifer durchlässt, weil er die Regeln befolgt.

Die Frage lässt sich mit einem externen Pentest beantworten, oder mit BloodHound (intern, mit Erfahrung). Das ist am Ende derselbe Graph.

• Die Kante modellieren. Für jede Zonengrenze im Netzwerkplan: Welche Identitäten gelten auf beiden Seiten? Wer Grundschutz macht: Die Authentisierungsabhängigkeit in die Strukturanalyse eintragen und die Vererbung laufen lassen. Der Rest der Liste folgt dann von selbst.
• Eigene Gesamtstruktur für die Produktion. Bei kleinen Anlagen: gar kein AD in der OT, lokale Konten mit Passwort-Tresor. Bei großen: eigener Forest, höchstens One-Way-Trust in Richtung Büro mit Selective Authentication und aktivem SID-Filtering (APP.2.2.A6).
• OT-DMZ mit Jump-Host für jeden administrativen Zugriff (IND.3.2.A7), mit expliziter Freigabe pro Sitzung (A8). Kein direktes RDP, SMB oder WinRM vom Büro in die Produktion.
• Tier-Modell konsequent (APP.2.2.A21): Wer die Produktion administriert, meldet sich nie mit demselben Konto im Büro an.
• Entra ID: Eigener Tenant für die OT oder mindestens kein Hybrid Join für Produktionssysteme. Ein Intune-Admin darf keine Skripte auf Produktionssysteme schieben können.
• Testen, nicht glauben. Pentest-Szenario: Start als Domain Admin der Büro-Domäne, Ziel: ein Produktionssystem. Wenn das gelingt, haben Sie den Beweis.
• Audit-Katalog ergänzen. Neben der VLAN-Frage die Erreichbarkeitsfrage stellen, und bei Grundschutz APP.2.2.A20 auch bei normalem Schutzbedarf. Der Haken für "Segmentierung" gilt erst, wenn beide Ebenen getrennt sind.

Segmentierung ist kein reines Netzwerk-Thema. Sie ist ein Vertrauens-Thema. Eine Zone ist nur so real wie die Vertrauensgrenze, die deckungsgleich mit ihr ist. In der Windows-Welt heißt diese Grenze Gesamtstruktur. Alles darunter ist Verwaltung, keine Sicherheit. Sagt das BSI selbst.

Die Kataloge werden Bäume bleiben, weil nur Bäume prüfbar sind. Das ist in Ordnung. Solange vor dem Baum ein Graph steht: im Scoping, im Tiering, in der Strukturanalyse. Lamberts Satz stimmt also weiter, nur anders, als er gemeint war: Verteidigende denken jetzt in Bäumen. Angreifer denken weiter in Graphen. Der Haken im Audit war richtig. Die Datenstruktur war falsch.

Wenn Sie Fragen zu dem Thema haben, schreiben Sie mir unverbindlich.

• Die Five-Eyes-Behörden wissen es. ASD, NSA, CISA, NCSC-UK, Kanada und Neuseeland haben im September 2024 gemeinsam "Detecting and Mitigating Active Directory Compromises" veröffentlicht (Stand Januar 2025). Golden Ticket, Kerberoasting, DCSync, das ganze Programm. Die Behörden, die die Frameworks herausgeben, haben das Problem längst beschrieben. Nur eben in einem Guidance-Papier, nicht im Katalog.
• Wenn Sie keine Produktion haben, aber (oder auch und) Entwicklung haben, sollte diese auch getrennt von der Bürozone sein. Dies gilt für alle Zonen, die weiterlaufen müssen, während die Bürozone nicht zur Verfügung steht.
• ORP.4 (Identitäts- und Berechtigungsmanagement) hilft nicht weiter: verlangt Funktionstrennung über Rollen, sagt nichts zu getrennten Identitätsdomänen. IND.1.A14 verweist auf ORP.4, und ORP.4 verweist zurück auf die Produkt-Bausteine.
• Domäne ist nicht Gesamtstruktur. Eine eigene Child-Domain für die Produktion bringt nichts, das steht in APP.2.2.A1 wörtlich. Die Grenze ist der Forest.
• Linux-Produktion mit zentralem LDAP oder FreeIPA hat dasselbe Problem in anderer Verpackung: Wer den Identitätsprovider hält, hält die Zone.
• Lambert, 2015: "Defender's Mindset", damals Microsoft Threat Intelligence Center.

• John Lambert: "Defenders think in lists. Attackers think in graphs. As long as this is true, attackers win." 26. April 2015 (später als "Defender's Mindset" wiederveröffentlicht). Damals Microsoft Threat Intelligence Center.

• BSI: IT-Grundschutz-Kompendium, Edition 2023. Bausteine NET.1.1 Netzarchitektur und -design, IND.1 Prozessleit- und Automatisierungstechnik, IND.3.2 Fernwartung im industriellen Umfeld, APP.2.2 Active Directory Domain Services, ORP.4 Identitäts- und Berechtigungsmanagement.
• BSI: BSI-Standard 200-2, IT-Grundschutz-Methodik (Strukturanalyse, Schutzbedarfsfeststellung, Maximumprinzip, Kumulationseffekt).
• ISO/IEC 27001:2022, Annex A (Controls 5.15, 5.16, 5.18, 8.2, 8.22); ISO/IEC 27001:2013, Annex A.13.1.3.
• NIST: Cybersecurity Framework 2.0 (NIST CSWP 29), Februar 2024; NIST CSF 2.0 Implementation Examples, Februar 2024; Cybersecurity Framework 1.1, April 2018.
• NIST: Special Publication 800-207, Zero Trust Architecture, August 2020.
• VDA (ENX Association): VDA ISA, Version 6 (Controls 4.1.2, 4.2.1, 5.2.7).
• IEC 62443-3-2:2020, Security risk assessment for system design (Zone and Conduit Requirements, ZCR 3.2).
• PCI Security Standards Council: PCI DSS v4.0.1, Requirements and Testing Procedures, Juni 2024 (Scope-Definition, Requirement 11.4.5).

• ANSSI: Recommandations pour l'administration sécurisée des SI reposant sur AD, ANSSI-PA-099, Version 1.0, 2. Oktober 2023.
• ASD, CISA, NSA, CCCS, NCSC-NZ, NCSC-UK: Detecting and Mitigating Active Directory Compromises, September 2024, Stand Januar 2025.

• Norsk Hydro ASA: Annual Report 2019 (Cyberangriff März 2019, LockerGoga, Gesamtkosten NOK 650 bis 750 Millionen).
• Merck & Co., Inc.: Form 10-K for the fiscal year ended December 31, 2017 (NotPetya, Juni 2017, Unterbrechung von Produktion, Forschung und Vertrieb).

• BloodHound (SpecterOps), Analyse von Angriffspfaden in Active Directory.