Subscribe to the Non-Human & AI Identity Journal

Notifications
Clear all

Lateral movement probability models: what practitioners should do


(@nhi-mgmt-group)
Member Moderator
Joined: 1 year ago
Posts: 11631
Topic starter  

TL;DR: A simple complement-rule probability model shows how lateral movement becomes easier to estimate when defenders treat each pivot path as a graph, then combine sequential hops and alternate routes mathematically, according to ColorTokens. The lesson is that microsegmentation decisions should focus on reducing the highest-probability pivot paths, not just shrinking the number of possible connections.

NHIMG editorial — based on content published by ColorTokens: License Plates to Lateral Movement: How a School Probability Trick Helps Model It

By the numbers:

Questions worth separating out

Q: How should security teams model lateral movement in complex environments?

A: Security teams should model lateral movement as a graph of reachable paths, not as isolated vulnerabilities or ports.

Q: Why do service accounts increase lateral movement risk in enterprise environments?

A: Service accounts often connect multiple systems, so they sit at the center of trust relationships that humans never see directly.

Q: How do organisations know which segmentation controls matter most?

A: The best signal is whether a control change reduces the probability of reaching high-value systems through common pivot paths.

Practitioner guidance

  • Map pivot paths as probability chains Represent critical workloads, identity flows, and remote administration channels as directed paths, then score sequential hops and alternate routes separately to identify the most dangerous reachability patterns.
  • Reduce the highest-probability administrative routes Prioritise controls on protocols and flows that repeatedly appear in successful chains, especially RDP, SSH, WinRM, SMB, and service-account-mediated access.
  • Tie microsegmentation to identity governance Review whether service account trust, delegated access, and workload permissions preserve pivot options even where network controls exist, and remove unnecessary traversal rights.

What's in the full article

ColorTokens's full article covers the mathematical details this post intentionally leaves at the modelling level:

  • The step-by-step derivation of the complement-rule operators used to combine alternate attack paths.
  • The full two-path numeric example showing how sequential hops and alternate routes are composed.
  • The deeper discussion of how reducing an RDP pivot probability changes overall reachability.
  • The article’s graph-theory framing for interpreting lateral movement as an attack path model.

👉 Read ColorTokens's analysis of probabilistic lateral movement modelling →

Lateral movement probability models: what practitioners should do?

Explore further

View Full Forum →  |  NHI Foundation Course →



   
Quote
(@mr-nhi)
Member Moderator
Joined: 2 months ago
Posts: 11186
 

Lateral movement is best understood as a reachability problem, not a tooling problem. The article’s graph-and-probability framing is valuable because it captures how attackers actually move through environments with multiple identity and protocol paths. In identity-heavy estates, service accounts, delegated flows, and remote administration channels all become edges in the same attack graph. Practitioners should therefore measure exposure by path quality, not just by the presence of controls.

A question worth separating out:

Q: How should teams balance network controls and identity controls against lateral movement?

A: They should treat them as complementary parts of the same exposure problem. Network controls reduce where an attacker can go, while identity controls reduce what they can do once they arrive. If identity trust still permits traversal through service accounts or delegated access, segmentation alone will not fully constrain lateral movement.

👉 Read our full editorial: License plate probability shows why lateral movement is hard to model



   
ReplyQuote
Share: