Notifications
Clear all
Topic starter
11/08/2026 3:20 pm
TL;DR: Cirro argues that cloud risk lives in relationships rather than isolated objects, and shows how identity, RBAC, scopes, managed identities, secrets, and data-plane permissions combine into attack paths, according to Bishop Fox. The governing gap is that access reviews still reason about objects one at a time while attackers reason over the chain.
NHIMG editorial — based on content published by Bishop Fox: Cirro and Azure attack-path modelling
By the numbers:
- NHIs outnumber human identities by 25x to 50x in modern enterprises.
- Only 5.7% of organisations have full visibility into their service accounts.
- 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
Questions worth separating out
Q: How should security teams map Azure attack paths across identity and RBAC relationships?
A: Start with the full chain, not the permission list.
Q: Why do managed identities and secrets complicate cloud access reviews?
A: Because the review boundary is usually too narrow.
Q: What breaks when cloud traffic lacks context?
A: When cloud traffic lacks context, teams lose the ability to distinguish normal behaviour from malicious movement.
Practitioner guidance
- Map attack paths as chains, not assets Build review workflows that trace from user or managed identity to group membership, RBAC scope, resource, secret, and downstream application permission in one query.
- Bring data-plane objects into identity review Include Key Vault secrets, certificates, and application credentials in the same analysis model as management-plane permissions.
- Standardise declarative resource schemas Use a shared constants layer and declarative templates for new cloud resource types so expansion does not create one-off parsing logic.
What's in the full article
Bishop Fox's full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step Cirro ingestion and schema extension workflow for additional Azure resource families
- Examples of the templated YAML and Tera structure used to render graph relationships
- Practical use of the CirroDash layer for exploring Neo4j attack-path data
- Details of the cirro-azcli-ext extension for passive API capture during Azure CLI use
👉 Read Bishop Fox's analysis of Cirro and Azure attack-path modelling →
Azure attack paths and data-plane context: what IAM teams miss?
Explore further
11/08/2026 3:31 pm
Cloud attack-path governance fails when teams review entitlements as objects instead of relationships. The article is right to treat identity, scope, resource, and secret as a single graph because abuse rarely begins with one dramatic permission. It begins when individually acceptable assignments compose into a reachable path. For IAM and cloud security teams, the operational unit of control is the chain, not the record.
A few things that frame the scale:
- NHIs outnumber human identities by 25x to 50x in modern enterprises, according to Ultimate Guide to NHIs.
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
A question worth separating out:
Q: How should teams govern environment identities across dev, QA, staging, and prod?
A: Treat shared identities across environments as a blast-radius problem. If one secret or token works across multiple stages, a compromise in the weakest environment can reach the strongest one. Separate identities by environment and review any bridge that allows the same credential to authenticate everywhere.
👉 Read our full editorial: Cirro shows why Azure attack paths are a graph problem
