Trees are not graphs.

John Lambert wrote an apt text in 2015. The title is "Defenders think in lists. Attackers think in graphs. As long as this is true, attackers win." Now more than 10 years have passed and almost all frameworks have received revisions. These include the IT-Grundschutz Compendium in edition 2023, NIST CSF 2.0 came 2024, the VDA ISA in version 6. In addition, the Five Eyes authorities have published a joint paper on Active Directory compromise in 2024. The question is: Did the frameworks include Lambert's lesson? My Answer: some no, because they cannot do it structurally, some yes, because they are built differently. And the problem is no longer lists. They are now trees.

It's a standard question in any audit: "Is there network segmentation?" Answer: "Yes." Check the box, move on, everyone's happy.

This is only one half of the segmentation. Segmentation has two levels: the network and identity. The question "Is there network segmentation?" only checks the first one.

Why is that not enough? Because it must also be checked whether office and production are in the same Active Directory forest. If so, the zone boundary is clean at the network level, but not at the identity level. An identity could then log on to production clients and office clients.

In the best case, a pentester with the Golden Ticket is in the office and has full access to any Windows device, even in production. In the worst case, production is at a standstill, because of ransomware.

Segmentation has a purpose: reduction of the blast radius (damage limitation). If a client is compromised in the office, production should continue. That's the whole idea. A zone is the amount of systems that are allowed to fall together, and the boundary in between is what protects the rest.

A firewall between two subnets delivers just that, it controls traffic between network segments based on rules. The rules can consist of IP addresses, ports and protocols, some even based on times. The problem starts when both sides of the boundary trust the same directory service.

For a production computer to be a domain member at all, the firewall has to let through a lot from the production segment to the domain controller: Kerberos (88), LDAP (389/636), SMB (445), RPC (135 plus dynamic range 49152 to 65535) and DNS (53). There is no logon or group policy when these ports are blocked.

The attacker needs just that, no more and no less. With a ticket granting ticket he gets a service ticket for the production computer, goes via SMB 445 (PsExec) or WinRM 5985 on the machine and ... "Game Over".

Not a single packet violates a firewall rule. The firewall log is clean. Unfortunately, the attacker paralyzes production.

If you think, it does not concern me. I use Entra ID and Hybrid Join. It does not get better, only differently: A Global Admin or Intune Admin distributes a script via the management cloud to all clients, because by definition the management cloud must be accessible from anywhere. The network zone is completely irrelevant here.

Following are two examples where there was network segmentation, but probably a common directory service. Perhaps a client or jump server was also used to manage office clients and production clients. A separate account for each zone, but one device. This is lateral movement. Look at which identities are on the client and where do they still work?

Norsk Hydro, March 2019: LockerGoga was distributed throughout the Group and reached production sites worldwide, plants operated by hand, total cost according to the 2019 Annual Report NOK 650 to 750 million.

NotPetya 2017: Credential theft in memory, then PsExec and WMI via the very channels that are open to administration anyway. At Merck, production stood for weeks.

Now the part that is more important to me than the firewall rules.

The auditors did everything right. They followed the questionnaire. The catalog is also correct. Every single requirement is right. How can it happen then that this gap arises. The reason for this is structural.

A control catalog is a taxonomy. Every topic needs its area: network architecture on one branch (chapter), directory service on another. For a catalog to be testable, a clear requirement with assignment is required. Thus, each request can be ticked off individually. This structure has a name. Tree.

A tree does not have cross edges. The statement "the production computer trusts the office domain controller" connects an object from the network branch to an object from the directory branch. For this cross connection there is no place in the tree, and therefore no suitable requirement. Not because the authors of the catalog did not understand Active Directory. But because the structure cannot represent the question.

The attacker does not have this problem. He sees nodes (accounts, computers, groups, sessions) and edges (is a member of, is admin on, has session on, is allowed to write in) and looks for a path from the office client to the production computer. This is BloodHound. BloodHound finds the path via the domain controller because the path via the domain controller consists of normal edges. The firewall appears in the graph only as a filter on some edges, and the edges it needs are open.

I want to tighten up Lambert's statement: lists are not the problem. A list can contain any question, including that about the directory service. The problem is, the lists are made from catalogs that are trees, and trees do not know cross edges.

I scoured the compendium (edition 2023). The result: Everything is in it, but only for high protection requirements. In the case of normal protection, however, the question is not asked.

In detail:

Network side, NET.1.1 network architecture and design. A4 requires at least three zones (internal, DMZ, external) with firewall at the zone transitions. A5 separates clients from servers. A6 says: "The end devices positioned in a given network segment MUST correspond to a similar security level." This is the only place from which a segmentation between office and production can be derived. A21 says that the systems that authenticate and authorize administrative communications belong in their own management segment.

OT-side, IND.1 process control and automation technology. The module itself says that the physical separation of the OT "can only be applied in exceptional cases involving elevated protection needs today". Air Gap is over, segmentation is the answer. A4 wants zones and conduits, A5 wants control zones to continue when other zones fail and "Decoupling SHOULD also continue to function after an attack". This is exactly what cannot be achieved with a common domain controller. Anyone who decouples the office immediately closes the logon on the production computer. A14 (only for high protection needs) recommends a central directory service for privileged OT users, with the note that "any resulting dependencies in user authentication are known". Which directory service, which forest: open.

OT-side, IND.3.2 Remote maintenance Office IT is a zone "that can only be trusted to a limited extent" from an OT perspective, and A7 expects any access to an OT zone to be made via a jump server in its own DMZ. It only applies to remote maintenance.

Identity side, APP.2.2 Active Directory Domain Services. Here is the decisive sentence, right in the threat landscape: "The forest therefore represents the security boundary, due to the system, within which information is passed on as standard in the AD DS. A domain only forms an administrative boundary." (translation mine) And A20, only in the area for high protection requirements: "Organizational units that have to guarantee independence from each other for IT security reasons or other reasons SHOULD NOT be in the same forest." (translation mine) Office and production separately, without mentioning the word "production", and only as SHOULD for high protection needs. APP.2.2 does not know the word "zone".

Three modules, each one correct for itself. NET.1.1 does not contain forest. IND.1 also contains no forest. IND.3.2 applies only to remote maintenance and APP.2.2 does not know any zone. The audit checklist asks NET.1.1.A4 (base, MUST) and gets a "Yes". APP.2.2.A20 is not requested at all for normal protection requirements. Three branches, no cross edge.

The same duality, hidden in a different place each time.

ISO 27001. The hole is in the risk assessment. Annex A under 8.22 "Segregation of networks" (2013: A.13.1.3) describes the network segmentation. The identity side is in 8.2 "Privileged access rights" as well as 5.15, 5.16 and 5.18. ISO knows no tiers. Whether 8.22 is effective, decides the own risk assessment. If the question was never asked there, the common forest is in conformity. Check mark at 8.22, certificate on the wall.

NIST CSF 2.0. The hole is in profile. Segmentation is PR.IR-01 (1.1: PR.AC-5). The "Implementation Examples" are very precise: segment networks by trust boundaries and platform types, allow only required communication, zero trust as an option. "Trust Boundary" is the word that other frameworks lack. What is one, the CSF does not say. Identity is in PR.AA. The CSF specifies results, the depth is defined by the organization in its own target profile. Anyone who enters "VLANs plus firewall" there has reached the outcome. Both levels will only be merged in SP 800-207, Zero Trust Architecture. The example in the CSF mentions Zero Trust only as an option, but does not link to the document. The CSF does not demand it.

TISAX (VDA ISA 6). The hole is in maturity. A 27002 derivative with maturity assessment: network in chapter 5, identities and privileged accounts in chapter 4. It evaluates whether a process exists, is documented and lived. Segmentation concept, VLAN chart, firewall rules, annual review: maturity level 3. Whether the concept has drawn the trust boundary correctly is not a question of maturity. Manufacturing even appears in Control 5.2.7. It serves as an example of networks with different operational purposes and belonging separately: test, office, manufacturing. But again as a network segment. The references of the control point exclusively to network controls of other catalogs. Which identities are used on both sides asks neither 5.2.7 nor chapter 4. TISAX label on the wall, factory and office in a forest, all in accordance with the rules.

IEC 62443. The hole is in the conduit, and this is the most interesting case. 62443 is not a tree. Zones are nodes, conduits are edges. So we have a graph model. Office and plant systems belong in separate zones (62443-3-2, ZCR 3.2). Nevertheless: Kerberos, LDAP and SMB from the production segment to the office domain controller are a documented, rated, zone-side filtered conduit. Formally all right. The model does not recognize that this conduit transports identity across the boundary and thus resolves the zone boundary, because its edges are network connections. A graph alone is not enough.

The counterexamples are the most beautiful thing about research. They show that it is possible.

PCI DSS: the graph is in front of the list. There are twelve requirements and is a classic catalog. But the scope is determined by connections: systems that provide security services to the cardholder data environment, especially authentication, are "connected-to" and thus tadaa in the scope. Anyone who uses his office domain controller for the POS systems has the domain controller in the scope, and with it practically the domain. "Supplies authentication for" is an edge there. Requirement 11.4.5: Segmentation is validated by penetration test, not by diagram. The list is the same data structure as everywhere. It is applied to the result of a reachability query.

ANSSI: the edge is called "chemin de contrôle". In its AD Guide (ANSSI-PA-099, 2023), the French authority defines the control path as a chain of logical relationships between AD objects and says that control paths between objects of different trust zones are potential attack paths. The forest is the minimum security perimeter there, using domains as trust zones is explicitly bad practice. This is the attacker graph drawn from the defending side, including the cross edge.

The structural analysis with its dependencies and the protection requirement inheritance (maximum principle, accumulation effect) are inheritance along a dependency graph: application needs system needs network. If the structural analysis says "Production HMI is dependent on the logon at the office domain controller", the office domain controller inherits the protection requirement of the production by the maximum principle, becomes "high", and thus the requirements for high protection requirements become due for APP.2.2. Including A20. The hole in the catalog closes itself as soon as the edge is entered. No module is missing. One line in structural analysis is missing. This is almost always missing because authentication is "only" a service (something virtual) and not a server (something physical) that someone touches.

Instead of "Is there network segmentation?" I suggest:

"Can an identity from an insecure zone directory service log on to a client in a secure zone?"

This is a checklist question and also a reachability query on the trust graph: Is there a path from an office account to a production system that does not violate a firewall rule? If the answer is "no", there is a production zone. If the answer is yes, there are two subnets with a firewall in between, which lets the attacker through because he follows the rules.

The question can be answered with an external pentest, or with BloodHound (internal with experience). That's the same graph at the end.

• Model the edge. For each zone boundary in the network plan: Which identities apply on both sides? Whoever does IT-Grundschutz: Enter the authentication dependence in the structural analysis and let the inheritance run. The rest of the list will follow by itself.
• Own forest for production. For small assets: no AD in the OT, local accounts with password vault. For large: own forest, at most one-way trust towards the office with selective authentication and active SID filtering (APP.2.2.A6).
• OT-DMZ with jump host for each administrative access (IND.3.2.A7), with explicit release per session (A8). No direct RDP, SMB or WinRM from office to production.
• Tier model consistent (APP.2.2.A21): Who administers the production, never logs into the office with the same account.
• Entra ID: Own tenant for the OT or at least no hybrid join for production systems. An Intune admin must not be able to push scripts onto production systems.
• Testing, not believing. Pentest scenario: Start as domain admin of the office domain, goal: a production system. If it succeeds, you have the proof.
• Additional audit catalog. In addition to the VLAN question, ask the reachability question, and for IT-Grundschutz APP.2.2.A20 also for normal protection requirements. The check mark for "segmentation" applies only when both levels are separate.

Segmentation is not a pure network issue. It is a trust issue. A zone is only as real as the trust boundary, which is congruent with it. In the Windows world, this boundary is called forest. Everything under it is administration, not security. Says the BSI itself.

The catalogs will remain trees because only trees are testable. That is fine. As long as a graph is in front of the tree: in scoping, in tiering, in structural analysis. Lambert's sentence is therefore still correct, only different from what he meant: defenders now think in trees. Attackers still think in graphs. The check mark in the audit was correct. The data structure was wrong.

If you have any questions on the subject, write to me without obligation.

• The Five Eyes authorities know it. ASD, NSA, CISA, NCSC-UK, Canada and New Zealand jointly published Detecting and Mitigating Active Directory Compromises in September 2024 (as of January 2025). Golden Ticket, Kerberoasting, DCSync, the whole program. The authorities that issue the frameworks have long described the problem. Only in a guidance paper, not in the catalog.
• If you do not have production, but (or also and) development, this should also be separate from the office zone. This applies to all zones that must continue to run while the office zone is not available.
• ORP.4 (Identity and permission management) does not help: requires functional separation over roles, says nothing about separate identity domains. IND.1.A14 refers to ORP.4, and ORP.4 refers back to the product modules.
• Domain is not forest. An own child domain for production does not help, that is literally in APP.2.2.A1. The boundary is the forest.
• Linux production with central LDAP or FreeIPA has the same problem in other packaging: Who holds the identity provider, holds the zone.
• Lambert, 2015: "Defender's Mindset", then Microsoft Threat Intelligence Center.

• John Lambert: "Defenders think in lists. Attackers think in graphs. As long as this is true, attackers win." April 26, 2015, later republished as "Defender's Mindset." At the time Microsoft Threat Intelligence Center.

• BSI: IT-Grundschutz Compendium, 2023 edition. Modules NET.1.1 Network Architecture and Design, IND.1 Process Control and Automation Technology, IND.3.2 Remote Maintenance in Industrial Environments, APP.2.2 Active Directory Domain Services, ORP.4 Identity and Access Management.
• BSI: BSI Standard 200-2, IT-Grundschutz Methodology (structure analysis, determination of protection needs, maximum principle, cumulation effect).
• 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), February 2024; NIST CSF 2.0 Implementation Examples, February 2024; Cybersecurity Framework 1.1, April 2018.
• NIST: Special Publication 800-207, Zero Trust Architecture, August 2020.
• VDA (ENX Association): VDA ISA, version 6.0.3 (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, June 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, October 2, 2023.
• ASD, CISA, NSA, CCCS, NCSC-NZ, NCSC-UK: Detecting and Mitigating Active Directory Compromises, September 2024, last updated January 2025.

• Norsk Hydro ASA: Annual Report 2019 (cyberattack March 2019, LockerGoga, total cost NOK 650 to 750 million).
• Merck & Co., Inc.: Form 10-K for the fiscal year ended December 31, 2017 (NotPetya, June 2017, disruption of manufacturing, research and sales operations).

• BloodHound (SpecterOps), analysis of attack paths in Active Directory.