TL;DR: Don’t start with access lists, start with attacker movement. Your new baseline: “Be the best at predicting how an attacker would reach identities that control critical assets”. Lead with an Attack Graph First approach. Add context and clear narrative to attack paths. Expose real risk and prioritize the most impactful fixes.

Quick What Is: An Attack Graph is a map of control relationships, direct and transitive, that shows how an attacker could move from initial access to organizational takeover.

Credits

Huge thanks to Jared Atkinson, Justin Kohler, Andy Robbins, Elad Shamir, and the many brilliant minds at SpecterOps who have helped shape how I see the world of Identity Security over the past 18 months. I don’t claim to have discovered anything than a different way to explain a problem space that has kept some of the smartest people in #infosec busy for years. I’m grateful to stand on the shoulders of giants and occasionally shout from up there in cartoon panels.

Special Thanks to Justin Kohler, Pete McKernan, CISSP and Hope Walker for their extensive reviews and constructive feedback.

Images crafted with the assistance of ChatGPT o4-mini-high.

Growing from IAM → Identity Security: A Typical Maturity Path

Milestone #1: How It Starts

Let’s assume you are working in #Entra. 

You carry out a permission analysis to find out who your admins are.

Helpful (?) -> You now have a #list. (Yay. Another one. Add it to the pile.)

If you have a #plan to act on this knowledge, (or you can outright see something standing out that shouldn’t be there) it may start turning ***useful***.

The problem is that many admins (or analysts) would stop and admire the data – gazing lovingly at their spreadsheet of names and taking the information at face value.

Data has to be accurate – right?

So as this stage we (think) we know🤞who the admins are.

Milestone #2: How It Goes From There

Months later, someone finally initiates a project to address “Attack Surface Management”,
based entirely on a static, outdated asset list.

By then, the surface has already shifted. What was relevant when the list was compiled is now legacy context.

The usual suspects:

Typical Step #1: “Remove admin rights from Steve in Accounts Payable – he left three months ago.”

A remedial task that should have been handled operationally, not retrofitted into an initiative.

Probably something that we should call out as deferred maintenance.

Typical Step #2: We begin organizing users into PIM-eligible, role-assignable groups to implement Just-In-Time (JIT) elevation.

On the surface, it’s a strong move. We are shifting from persistent privilege to time-bound access, and introducing structure around privilege management.

We are no longer simply removing access. We engineer intentionality into it.

Great! Is that enough? I guess not.

Typical Step #3: Roll out JIT access packages to further reduce standing privilege and, inevitably, introduce another operational refrain:

“Why can’t I access this today?”

In theory, it’s a tighter coupling between access and intent. But there’s a catch.

Without clear alignment between business function, role context, and entitlement design, JIT packages risk becoming operational friction masquerading as control.

Access becomes a helpdesk issue, not a security value.

Is this helpful?

Yes, we are reducing attack surface area.

But if users don’t understand the logic behind the friction – if the system lacks transparency or responsiveness – it erodes trust and drives workarounds.

> Digital desire lines are carved as an unintended consequence of our efforts to dictate behaviour.

Misaligned access control does not reduce risk.
It displaces it into tickets, shared credentials, shadow IT.

But anyway…

Now the Identity team has an improved structure to base its operations.

Let’s take the win. It’s worth – at least – taking a moment to celebrate.

These actions are certainly good foundations, and they may feel all-encompassing and complete, especially when wrapped in polished policies, compliance reports, and role-based rationality.

But comfort is not the same as coverage.
And structure isn’t the same as security.

In other words; The structure is improving. But the signal behind that structure still depends on the quality of the modeling underneath.

Milestone #3: What Are We Missing?

Asking this question comes next in any maturity journey and means stepping away from familiar assumptions.

For years as an Identity Architect, I advocated identity management best practices as a foundational path to securing organizations; pruning dormant privileged accounts, managing group memberships, implementing JIT access, rotating credentials, putting structure and order.

Makes sense to everyone.
|
Is straightforward.
|
Fits neatly into technical roadmaps.
|
Justifies budget, work and resource allocation.
|
And for all those reasons, I always STARTED FROM THERE.

Maybe it’s time we start thinking about what happens if we don’t.

Hygiene is necessary but should it really be the starting point?

> What if starting there gives us a false sense of completeness and narrows visibility?

> Hygiene matters. It brings order and clarity. But what if starting there blinds us to the threats that aren’t messy, but invisible?

While busy persuading Klaus to adopt MFA, attackers are navigating identity paths, chaining trust violations that hygiene alone won’t detect.

Violations of the Clean Source Principle.

Attackers don’t care how tidy our directory looks, they care about control. And control whilst sometimes can be helped from mess; most times is supported by misplaced confidence. 

So, maybe the pressing question isn’t “Is our environment clean?” but “are our privilege boundaries defensible right now”?

One of the most costly missteps at this stage is misaligned action, or as Jim Sykora has framed it to me:

“The entropy of an environment combined with ignorance can result in taking counterproductive actions”.

Investing effort where there is no material threat not only wastes limited resources, it creates a dangerous illusion of progress.

Meanwhile, the areas of the business that do require focused defense remain exposed, not because they were invisible, but because we didn’t look far enough ahead or wide enough across the landscape.

If your house has structural mold compromising the foundation, it doesn’t matter how clean your kitchen sink is.

Addressing low-risk, high-visibility issues while deferring systemic ones leads to a fragile security posture.

One that looks active but isn’t resilient.

Strategic security is a fine balance between how much effort you apply, and where and why you apply it.

The goal is not to do more, but to do the right things at the right time, using data-drive, threat modeling, measured business impact, and forward-looking risk intelligence.

So how do we decide what to secure first?

Not by guessing, or tidying at random, but by understanding the real attack paths, the high-value pieces, and how an adversary might checkmate us in four moves while we’re still reorganizing our knights, then using that information to drive our decision making in what will need our attention first.

Call it evolution, or organic humility that comes from seeing theory meeting reality, I’m now reconsidering many beliefs I held firmly.

Milestone #4: Who Truly Benefits?

For the avoidance of ambiguity allow me to clarify:

Any effort toward security is better than apathy.

But effort alone isn’t a virtue.

If our energy is misdirected, we may end up reinforcing the very weaknesses we meant to protect against.

Do you know who is counting on that?

Controls ≠ control.

⚠️We can implement a multitude of security “controls,” but still lack true “control.”

It’s like having a very expensive and complex alarm system for your house (the controls) but leaving the back door unlocked (no actual control over who enters). The presence of security measures doesn’t automatically equate to being secure.

Controls offer the feeling of safety. Control delivers the reality of it.

⚠️Lists ≠ visibility.

Compiling lists of assets, users, or vulnerabilities doesn’t mean we understand our environment.

It’s like having a phone book (a list of names and numbers) versus knowing who is actually talking to whom, what they are discussing, and if any of those conversations are planning something malicious. Lists are raw data; visibility is actionable intelligence derived from that data.

Lists are data. Visibility is context, clarity, and consequence.

⚠️Work ≠ outcome.

A security team can be flat-out busy and still not be effective.

Think: rowing hard in the wrong direction, or worse, in a leaking boat. Effort is necessary. But only aligned, intentional effort drives outcomes. 

Work that doesn’t produce impact is effectively motion: of the costly, exhausting and unsustainable kind.

Milestone #5: But We Are Not Ready Yet…

You’ve probably heard it.
You’ve maybe said it:
“But we are not ready yet.”

The thing is, that is hardly a roadmap problem.
It is an #AccessGraph one.

Because the very next step on that journey to “maturity” is what I call the art of stalling with structure.

It usually shows up as a flurry of well-intentioned complexity.

Deep dives into the access narratives of every individual user or persona. Questions like:

Why did they get that access in the first place.
|
When did they last logon to X system.
|
What do they have in common with Y user.

Each question expensive, thoughtful and circling the same quiet, subconscious goal:

“Know the attack surface as much as possible… before we fight our Battle of Alesia.”

Getting a life cover is always easier than changing how you live.

Preparing for disaster feels strategic – but sometimes, it is but an acceptable face of surrender.

On the other hand, building habits that help you live longer,
or in our case, help the business actually operate more securely day-to-day….those are harder.

So when I hear:

“We need to crawl before we run,”

I am thinking:

You’re not preparing to run.
You’re getting comfortable crawling.

> Let me explain (before the pitchforks come out.)

In Through the Looking Glass, the Red Queen tells Alice, “It takes all the running you can do, to stay in the same place.” That’s the paradox: staying still (or crawling) feels like progress because you’re moving. But in reality, the world around us is sprinting. What feels like momentum is our falling further behind.

“Crawling” isn’t bad in itself. It’s a vital phase, deliberate, thoughtful, foundational.

But it becomes dangerous when we mistake it for strategic patience, when really it’s inertia dressed up as intention. The comfort of crawling can quietly sabotage the momentum we need to actually move forward, especially from the patterns or pitfalls we keep finding ourselves in.

Pacing up doesn’t mean putting the team under pressure or pushing toward burnout. Quite the opposite. Businesses lose brilliant people when they mistake pace for pressure.

But we do need to keep a healthy state of alertness.

Settling deeply into the idea that perfection is a myth – while momentum is a muscle – might be the shift we need.

Milestone #6: What Is The Narrative?

Usefulness lies in the #context and narratives we create.

What is the right context?
Enough to tell you what you should be focusing on right now?

Imagine turning that phonebook of admins into a page-turner. Working title:

“Chapter 1: How Dave from Marketing Could Accidentally Nuke the Company.”

People understand stories. 

They love them.

Especially when the ending does not involve a breach and a very awkward board meeting, all whilst scrambling to keep the lights on.

Typical questions at this stage involve:

> Can we detect adversaries moving through identity pathways – not just the network?

> Who’s watching for behavior that abuses trust, rather than breaks rules? Like the service account that was supposed to read logs – but was quietly granted write permissions to a sensitive storage bucket because “it needed to run reports.”

> Which control relationships are being exploited right now, silently and without resistance?

> Where are the Clean Source Principle violations hiding in plain sight?

> Are we tracing movement through our environment or logging presence?

> Does an attacker really need access to Tier-0 to exercise control? Do they need to win the domain or are our crown jewels already left unattended in a SharePoint Library?

> What’s being accessed because of where trust was placed, not because of where credentials were stolen?

More importantly, how can we know what we don’t know?

What Matters to the Company?

Before we can learn to anticipate attacks or model risk, we have to pause and ask a deceptively simple question. I was reminded of this from Hope Walker (who by the way has some excellent write-ups on my other favourite topic: Conditional Access).

“What’s actually important to this business?”

See the most damaging breaches are neither technical marvels, nor path-to-Tier-Zero blitzes. Sometimes, they are low-noise, high-impact intrusions that bypass traditional privilege escalation paths entirely.

This is why the question “What is most important to the business?” must sit at the heart of identity and access governance as operationally essential.

If you are thinking of answering this question with specific servers and databases please don’t.

The questions we ask need to be far broader and more encompassing before we start surfacing tactical responses:

> What part of our business, if disrupted, would cause real chaos, not only tickets, but headlines and shareholder calls? That’s your Tier-Critical, whether or not it’s Tier-0. Identity attacks don’t have to aim high – they can just aim smart.

> If we were breached tomorrow, what would make us say, “We should have seen that coming”? That’s the identity path you already suspect but haven’t mapped. It’s not hidden, it’s unexamined. A forgotten group membership, a “temporary” access grant, a service account with quiet power. Regret follows wherever trust goes unchecked.

> Are we investing security resources where the company actually creates value, or where it’s easiest to get approval? Attackers follow value, like water moving the path of least resistance. If we focus on what’s visible or politically safe, we’re misaligned.

> What assumptions are we making about so-called “low privilege” users that an attacker would love to exploit? Low-privilege isn’t low-risk, it’s often step one in a very short attack path.

> Do we really understand how trust, delegation, and access actually work here, or do we trust the org chart? Attackers don’t follow reporting lines. They follow control relationships – and those don’t show up in PowerPoint.

> Are we securing what would actually hurt our company, or copying what worked for someone else and hoping it fits? Every identity story is unique. Copy-paste controls won’t protect what makes your business valuable.

When security programmes align with business-critical outcomes, rather than focusing solely on technical exposure, they establish a narrative that is context-aware, defensible, and strategically prioritized. That narrative is strong enough to go beyond supporting governance and in turn provide direction that helps teams navigate complexity and focus on what truly needs to be protected.

Milestone #7: From Detection to Anticipation

At this stage, the conversation finally shifts to risk-based IAM.

The decisions about where to focus and what to fix become strategic:
From detecting to anticipating.

Here’s the twist (or disappointment):

This should have been Milestone #1 all along.

You can’t launch any meaningful security programme without understanding risk.

> Not technically.
> Not culturally.
> Not sustainably.

From here, the mindset evolves:

> From patching to prevention

> From reacting to reclaiming

> From protection to (cyber) sovereignty

This is where the organisation begins to fight for something better than survival: winning. To be safe and fully in control of its digital destiny.

But to do that, we need to know which path could be taken before it is. Because once it is, it’s already too late.

⚠️Countermeasures ≠ Safeguards (and playing catch-up is a terrible place to operate from.)

Countermeasures are reactive by design. They exist to reduce impact after a threat has manifested. Safeguards are anticipatory. If our architecture leans too heavily on countermeasures, we are modeling risk based on what has already gone wrong.

True resilience is forward-facing. It goes beyond measuring how well we respond it shapes what we will never need to respond to in the first place.

From a risk perspective, this means moving beyond probability-impact matrices and incident response playbooks and onwards to understanding how safeguards reduce risk surface, preserve business continuity, and avoid unacceptable outcomes – before they materialize.

This is where resiliency meets mature risk modeling, beginning:

Not with the question, “What will we do if this breaks?”
But with, “What have we done to ensure it doesn’t?”

Strategic defense means looking beyond what’s been exploited already and building controls that shape the attacker’s path.

Milestone #8: How Do We Model Risk?

I’ll be honest;
This stage is both fun and terrifying.

Unless risk is communicated clearly there is no way you can talk about modelling risk.

On a personal note, the very mention of risk in conversations personally gives me the creeps as the last thing you can talk about is something that can be as contextual as its interpretation.

Take something like:

“You have X stale accounts, so your identity risk is… 50%.”
“You have Y GPO objects with passwords in them therefore your identity risk is… 76%”

That’s not risk.
That’s astrology on a spreadsheet.

And that is why I appreciate how BloodHound Enterprise frames the conversation differently. by using exposure indicators, a quantitative metric designed to answer a far more grounded question:

“What is the post-breach likelihood of an attacker riding this attack path resulting in organizational takeover?”

Measured in the analysis of the traversable paths for every single identity and resource.

It’s about understanding the structural paths an adversary could take – and how reachable your crown jewels really are.

This is where tools can help.

If they remove the fog that surrounds uncertainty and illuminate the real objective: adversary pathways, dependencies, and blast radius.

And your security programme is the one that benefits.

The Coffee Trail To Tier Zero

As we are naturally entering more complex topics I owe you (the reader) at least an explanation of how to read the below:

Firstly, let’s get this out of the way:

This is not a real risk model and SpecterOps did not just suggest a coffee-based one. It would have been a strong and very aromatic blend but…

To fully align with where I am coming from with the above, I highly recommend reading Jared Atkinson’s brilliant On Detection series. Jared’s metaphor about function chains, thinking like a baker assembling subroutines to make a meringue, stuck with me.

Instead of thinking in identities and entitlements, I started asking:

> What are the raw ingredients required to assemble privilege?

> How do attackers chain those together – deliberately, tactically, patiently?

Eventually, I started visualizing attacker progress the same way I visualize my own late-night work marathons:

In coffees.

Because that’s what effort looks like.

Not as exposure, but as energy needed to exploit, compose, and weaponize it.

It started with a simple question: “Who are my Entra Admins?” The more I learned, the more that question felt… limited.

> Can an attacker with control over a random user in my environment get to my Entra Admins? In other words, is there a path to Tier Zero?

> What is the minimum functional composition needed to reach a principal with Tier-0 access? Or simply put; what’s the shortest path to Tier Zero?

> What are all the viable function chains to get there – especially the ones that violate the Clean Source Principle? Can they get there with a different set of steps, even if not in the same order? What are ALL the paths?

How many ☕️ does it take to reach Tier-0 before anyone blinks?

In this imaginary state, we’re counting the attacker’s effort in units of time it takes to sip a cup of coffee (roughly 5–10 minutes).

Each ☕️ = one tactical action, one privilege pivot, one quiet little sidestep through your overly trusting architecture.

Why? Because everyone knows coffee is a great currency of quiet, focused persistence.

So… Attackers think in coffees?

No attackers think in edges, abuse chains, and control surfaces.
|
They don’t care who your admins are.
|
They care how far they are from someone who can act like one.

With that in mind…

> How many cups of coffee would it take them to walk that attack path undetected?

> Is there any minimum amount we would consider unacceptable? If it took them 2 cups to reach our crown jewels, would that be considered reason enough to pace up our efforts or should we go down to 1 sip of the 1st cup before we start our “run”?

Once we detach ourselves from the number of paths an “attacker can walk” and start focusing on the time it would take them to ruin the business out of a single attack path I think it becomes clear what we should care about first.

Next time, instead of asking “Who are my Entra Admins?”, ask: “How could an insider assemble the ingredients to become one?“

Risk isn’t about who has access. It’s about how that access can be abused, composed, and weaponized.

You may have heard that before as: “Not all exposure is risk – unless it’s demonstrably exploitable.” but here are a few more questions for you:

> Is it demonstrably exploitable by your team with current tools and knowledge, or by a determined attacker with more time, novel techniques, or inside information? The bar for “demonstrably” can be subjective and often underestimates attacker capability.

> An exposure not “demonstrably exploitable” today could become so tomorrow with a new vulnerability disclosure, a change in your environment, or an attacker chaining it with other, seemingly minor, exposures. Relying on current demonstrability can create a dangerous blind spot.

> While an individual exposure might not be directly exploitable for a critical impact on its own, could it be a crucial link in a longer attack chain? An “Attack Graph” perspective would in this case highlight how such exposures contribute to overall risk by enabling lateral movement or privilege escalation.

> If you wait until an exposure is “demonstrably exploitable,” are you already a step behind? A proactive approach might ask: “Does this exposure weaken our defenses or provide an attacker with an unnecessary foothold, even if we can’t immediately script an exploit for it?”

> Does risk only begin when a full exploit is obvious? Or does an exposure represent a latent risk, a potential future problem, or an unnecessary widening of the attack surface that, in aggregate with other exposures, significantly elevates the likelihood of a successful attack?

So, while the desire to focus on the clearly exploitable is understandable for resource allocation, it might lead to overlooking systemic weaknesses or underestimating the creativity and evolving tactics of adversaries. 

A deeper question might be: “How does this exposure contribute to potential attack paths, now or in the future?”

That’s the shift from an operationally limited #AccessGraph to a dynamic, attacker-centric actionable #AttackGraph.

Final (?) Milestone: What Maturing in Identity Security Really Means…

Maturity isn’t a straight line. 

It’s a zigzag through buzzwords, acronyms, and the occasional IAM spiritual crisis. But if you’re still building identity strategies without understanding how attackers move… …you’re playing tag in the dark.

You can’t model identity risk in a vacuum.

All problems are interpersonal relationship problems, quoted Alfred Adler.

> How those identities can be abused

Identity risk doesn’t live only in objects. It also lives in relationships called attack paths, an almost Adlerian, twisted version of them.

So unless we have mapped:

> What systems they can control

> And how those control relationships chain together

…we are not modeling risk.
we are listing objects.

That’s why every meaningful model of identity risk is, by definition, an Attack Graph.

And at least this has been an ever-present part of the equation. From the time we were doing tabletop attack trees, to continuous analysis with BloodHound, to a future of “sentient entitlement meshes” (or however else we decide to name our efforts helping us cope with complexity).

Interested to hear more? Perhaps join my webinar on May 27th!

The topics discussed below will be touched upon (amongst many others) over my version of the Monthly webinar on #AttackPathManagement by SpecterOps -> [Sign Up Here] (ps. If you are reading this line being suspicious of a casual vendor webinar that wouldn’t be it. Thankfully SO isn’t either your casual software vendor which kind of aligns with why).

POST SCRIPTUM TECH TIP:

Since it’s still relevant to know who your “current / well known / obvious Entra admins are” for quick point-in-time #Entra checks when not firing up #BloodHound, I would always resolve to Merill Fernando‘s #LokkaMCP since it takes the onus of querying the graph for you and is the #ShortestRouteToGatheringThisInformation.