DEV Community: oliverbeenthere

Eyes On The Road - How Attackers Navigate Through Your Organization

oliverbeenthere — Thu, 09 Jul 2026 18:35:00 +0000

From Doors to Roads

For years, security discussions revolved around a simple question:

Where is the vulnerability?

A missing patch, a weak password, an exposed service or a misconfigured system.
The assumption was that an attack began with a single weakness and ended once it was exploited.
Modern attacks rarely work that way.
A vulnerability alone doesn't determine the impact.
The real danger lies in what that vulnerability connects to.
A compromised workstation may hold a little value by itself, but the identity using it may have access to another system.
That system may trust an application, which in turn may have permissions to sensitive resources.
A vulnerability matters less on its own than the connections it creates.
Modern attacks are no longer about isolated weaknesses.
They are about navigating connected environments.
Attackers don't simply break into organizations.
They navigate them.
The first authentication event is only the beginning of that journey.
A stolen credential becomes a token.
A token becomes access to an API.
An API permission becomes an opportunity for privilege escalation, eventually leading to the organization's most valuable assets.
The question is no longer:

"How did the attacker get in?"

The better question is:

"Where can the attacker go from here?"

That is where Attack Paths begin.

Every Road Starts Somewhere

A vulnerability tells us that something is weak.
An attack path tells us why that weakness matters.
Imagine two identical vulnerabilities.
One exists on an isolated server with no sensitive data, no privileged accounts and no trusted connections.
The other exists on a server used by a privileged administrator with access to critical infrastructure.
The vulnerability is exactly the same.
But the risk isn't.
The difference is where that path leads.
This is the context traditional vulnerability management often misses.
Security teams prioritize findings by severity, but attackers don't think in CVSS scores.
They think in opportunities for movement.
A low risk permission that eventually leads to privileged access may be far more valuable than a critical vulnerability sitting on an isolated machine.
An attack rarely ends where it begins.
Initial access leads to an identity, that identity inherits permissions, those permissions reach additional resources and eventually the attacker reaches a privileged system or a "Crown Jewel" (High Value Assets).
The weakness is only where the journey begins.
The real risk depends on where that journey can lead.
Modern security therefore focuses less on simply fixing vulnerabilities and more on understanding exposure, privilege relationships and the routes an attacker can follow.
Because attackers don't need every door to be open.
They only need one road that leads somewhere valuable.

Identifying The Intersections

When people think about identity, they usually think about users.
In reality, modern environments contain many kinds of identities.
Applications, service principals, managed identities, automation accounts and cloud workloads all authenticate, receive permissions and interact with other systems.
To an attacker, every one of them is another intersection on the map.
A regular employee account may appear harmless because it has no administrative privileges and no direct access to sensitive systems.
But attackers aren't interested only in what that identity can access today.
They want to know what it can lead to.
That account may belong to a security group.
The group may grant access to an internal application.
That application may hold permissions in Microsoft Graph or another cloud service.
A seemingly ordinary identity can become the first step toward privileged access.
Modern organizations are built on relationships.
Users belong to groups, groups receive roles, applications access resources and services trust one another.
Each relationship creates another possible route through the environment.
This changes the questions defenders should ask.
Instead of asking:

"Who is this identity?"

They should ask:

"Where can this identity lead?"

Every new application, integration, service account or permission adds another connection.
Individually these decisions make perfect sense, but together they create a network that attackers only need to understand well enough to find the next turn.
Every identity becomes another intersection.
Whether the attacker turns left or right depends on the roads that identity is connected to.

The Shortest Path Is Rarely Straight

People often imagine attacks as direct routes: compromise a system, escalate privileges and reach the target.
Real attacks are rarely that simple.
Modern organizations are complex networks of identities, applications, permissions and trust relationships.
Reaching a valuable asset is less about moving in a straight line and more about discovering the route that already exists.
Like a driver using GPS, attackers look for the next available road.
A forgotten permission, an overlooked trust relationship or an application with excessive access may become the shortcut that moves them forward.
They don't need to know the entire map.
They only need to discover one viable route.
This is why attack paths fundamentally change how we view security.
Instead of seeing isolated systems, attackers see a connected map.
Identities, applications and resources become destinations, while permissions, group memberships and trust relationships become the roads between them.
Some roads lead nowhere.
Others quietly lead to the organization's most valuable assets.
The challenge is that these paths are often invisible to defenders.
One team understands the application, another manages the cloud permissions and another owns the sensitive resources.
Each connection appears reasonable in isolation, but together they may create a route that nobody realized existed.
This is exactly what attack graph tools were built to visualize.
Tools such as BloodHound became valuable because they reveal the relationships that make privilege reachable, rather than simply highlighting privileged accounts.
The same principle applies beyond Active Directory.
In cloud environments, application permissions, managed identities and trusted integrations create similar navigation opportunities.
A permission granted for convenience months ago may become the bridge an attacker uses today.
Good navigation requires a good map.
Without visibility into relationships, defenders protect individual streets while attackers navigate the entire city.
And the most dangerous roads are often the ones nobody realized had been built.

The Roads We Build Ourselves

Attack paths don't appear by accident.
They exist because organizations create connections that allow people, applications and services to work together.
Every role assignment, API permission, service account and trust relationship adds another possible route through the environment.
Individually, these decisions are perfectly legitimate.
An application needs access to Microsoft Graph.
An automation account deploys cloud resources.
A service principal retrieves secrets from a Key Vault.
Each permission solves a business problem.
The challenge is that attackers evaluate permissions by the opportunities they create, not in isolation.
Consider a cloud application with broad API permissions that may operate safely for years.
But if an attacker compromises that application or the identity behind it, they immediately inherit every permission that was granted to make that automation possible.
The application itself isn't the vulnerability.
Its permissions define the attacker's next move.
The concept also applies to** Role Based Access Control (RBAC).
Roles simplify administration by grouping permissions together, but they also create predictable routes through an environment.
An ordinary user may appear unprivileged, yet group memberships, inherited roles or delegated permissions can quietly extend their reach far beyond what is immediately visible.
Even temporary privileges deserve attention.
Solutions such as **Privileged Identity Management (PIM) reduce standing access, but temporary permissions are still permissions. If an attacker compromises an identity while those privileges are active, the available attack paths change accordingly.
This is why security teams should ask more than:

"Who has this permission?"

They should ask:

"What new path does this permission create?"

Most permissions are harmless on their own.
As Murphy's Law reminds us: Anything that can go wrong, will go wrong.
In security, the challenge isn't that individual decisions are wrong.
In fact, most of them are reasonable.
The challenge is that thousands of reasonable decisions can slowly transform into an outcome nobody expected.
The danger appears when those decisions create roads no one intended to build.
Attackers rarely create those roads.
They simply learn how to navigate them.

Think Like a GPS, Not a Gatekeeper

Traditional security focused on keeping attackers out.
Firewalls protected the perimeter.
Authentication verified identities.
Access controls decided who could enter.
The goal was to build stronger gates.
Modern attacks have changed that assumption.
Attackers often begin with legitimate access such as a compromised user, a stolen token, a trusted application or a third party integration.
Once they get inside, the question is no longer whether they can enter.
The question is where they can go next.
This requires a different mindset.
A gatekeeper asks:

"Who should be allowed in?"

But a GPS doesn't ask how someone arrived.
It asks:

"Where can they go next?"

That shift changes how defenders evaluate risk.
Instead of prioritizing isolated findings, they begin asking which paths actually lead to critical assets.
A critical vulnerability on an isolated system may present little practical risk, while a single permission may create a direct route to the organization's most valuable assets.
Risk isn't defined by severity alone.
It's defined by where the path leads.
This concept also applies to remediation.
Traditional vulnerability management asks:

"Which vulnerability should we fix first?"

Attack path analysis asks:

"Which connection should we remove first?"

Sometimes removing a single unnecessary permission, reducing an application's privileges or breaking an unnecessary trust relationship can eliminate multiple attack paths at once.
Rather than fixing weaknesses one by one, defenders remove the routes that connect them.
The goal isn't to eliminate every vulnerability.
It's to make navigation difficult.
Every organization has critical assets.
The objective isn't to protect every road equally, but to understand which roads eventually lead to those destinations.
Once those routes become visible, defenders can identify choke points where one security improvement disrupts multiple attack paths at the same time.
Attackers succeed because they understand how to move.
Defenders become more effective when they understand the roads that make that movement possible.
Security teams spend years watching the gates while attackers spend their time studying the roads.
Maybe it's time we did the same.

The Afterlife of Authentication - Following What Lives On

oliverbeenthere — Mon, 06 Jul 2026 05:35:00 +0000

For years, authentication felt like the finish line.

A user entered a password, approved MFA, received access and the story was supposed to be over.

Identity had been verified.

Trust had been established.

Everyone moved on.

But modern identity attacks tell a different story.

And authentication is no longer at the end of it.

It’s simply where a different one begins.

Once trust is established, attackers stop caring about the password.

_They care about what survives after authentication succeeds.
_

Nothing Truly Dies

Authentication answers one simple question:

“Who are you?”

Once that question is answered, the system tries not to ask it again.

After all, constantly asking users to prove their identity would make modern cloud services almost unusable.

That’s where OAuth and OpenID Connect (OIDC) come in.

Instead of authenticating every request, they allow applications to reuse trust that has already been established.

So Microsoft Entra ID verifies the user once, then issues the artifacts that allow trust to continue long after authentication ends.

Access Tokens.

Refresh Tokens.

Session Cookies.

Trust relationships.

The password was only the entrance ticket.

The real value is everything that keeps working after the login window closes.

Authentication lasts only a moment.

Trust is expected to outlive it.

_And that’s where the afterlife begins.
_

The Death of the Password

If trust became the valuable asset, it was only a matter of time before attackers started targeting it instead.

For a long time, stealing passwords was enough.

Then organizations introduced Multi-Factor Authentication (MFA).

Conditional Access became common.

Passwordless authentication followed shortly after.

Breaking into the front door became increasingly difficult.

So attackers stopped trying.

Instead of stealing credentials, they began stealing what credentials create.

This is the shift from credential theft to trust theft.

Rather than defeating MFA, they simply let the legitimate user complete it for them.

The password is no longer the prize.

The authenticated session is.

Life After Login

Modern cloud environments don’t run on passwords.

They run on trust.

Every request now carries something far more valuable than a password.

A token.

Microsoft Graph accepts it.

Cloud applications accept it.

APIs accept it.

As long as the token remains valid, the system continues acting as if the user is present.

Authentication slowly becomes history.

Trust keeps doing the work.

_As Murphy’s Law reminds us: Anything that can go wrong, will go wrong.
_
The longer trust remains alive, the more opportunities attackers have to abuse it.

The Ghost Between The Two Worlds

Adversary-in-the-Middle (AiTM) attacks exploit exactly that trust.

Instead of presenting a fake login page, the attacker places a reverse proxy between the victim and Microsoft Entra ID.

The victim signs in successfully.

Microsoft verifies the sign-in successfully.

MFA succeeds exactly as expected.

Nothing appears compromised.

But while authentication is taking place, the attacker quietly captures the session artifacts it leaves behind.

Authentication succeeds exactly as designed.

_The only question is who gets to keep what survives.
_

Living Someone Else’s Afterlife

Device Code phishing pushes the same idea even further.

There is no fake Microsoft website.

No fake login page.

The victim authenticates directly against Microsoft’s legitimate device login portal.

Everything looks correct.

Because it is.

The attacker generated the Device Code first.

The victim simply completes the authentication process on the attacker’s behalf.

Authentication succeeds exactly as designed.

But someone else walks away with everything authentication left behind.

_Its afterlife included.
_

The Identities That Were Never Alive

Then comes the realization that changes the way we think about identity entirely.

Not every identity has a password.

Not every identity performs MFA.

Some identities never authenticate the way people do.

Service Principals.

Managed Identities.

Workload Identities.

They exist to allow applications and services to communicate with each other without human interaction.

Many of them hold powerful Microsoft Graph permissions and access to critical cloud resources.

Compromising one of them can be far more valuable than compromising a user.

Some identities never enter the afterlife.

_They are born into it.
_

When Trust Outlives Authentication

Many organizations respond to an identity compromise by resetting the user’s password.

Sometimes that’s enough.

Sometimes it isn’t.

Refresh Tokens may continue issuing new Access Tokens.

Existing sessions may continue working.

Applications may continue trusting an identity long after the original password has changed.

The attacker isn’t resurrecting the password.

They’re reusing the trust authentication already created.

This is exactly why modern identity security is shifting its focus.

Not toward protecting passwords.

But toward deciding when trust should finally expire.

Protecting What Lives On

Modern identity defences no longer focus only on making authentication stronger.

They focus on controlling everything that happens after authentication succeeds.

Some technologies, like Passkeys and FIDO2, strengthen the authentication process itself.

Others, such as Conditional Access, Token Protection, Continuous Access Evaluation (CAE) and Identity Threat Detection, continuously evaluate whether that trust should still exist.

The goal is no longer simply protecting the login.

It’s protecting the entire chain of trust that follows it.

Because in modern identity systems, authentication is only the beginning.

Trust Is the New Attack Surface

We often say that identity is the new perimeter.

After spending time studying modern Entra ID attacks, I’d take that one step further.

Trust has become the new attack surface.

Attackers rarely spend their time defeating authentication anymore.

They simply abuse what authentication leaves behind.

Perhaps we were looking at the wrong finish line all along.

Authentication was simply the moment a second life began.

And in today’s cloud-first world, the most important security question is no longer:

“Did the user authenticate successfully?”

It’s:

“What is still trusted after they did?”

Because authentication eventually dies.

But trust lives on.

And attackers are always looking for what still has a pulse.

Back to Babel — Yearning For a Common Language The Purpose of GRC In Modern Systems

oliverbeenthere — Fri, 03 Jul 2026 13:35:00 +0000

_The thing is, we never actually spoke the same language.
_
The myth of engineering organizations is that everyone is building the same tower and sharing the same understanding of what “moving up” even means.

But in reality, each group is standing on a different floor of that tower.

Developers focus on how it is built — the structure, the materials, the movement of code and systems.

Security focuses on where it might collapse — weak points, blind spots, places where trust is assumed but not proven.

Legal focuses on accountability — rules, obligations and consequences.

Business focuses on purpose — speed, growth, value and direction.

They are all looking at the same tower.

Yet none of them can see the whole structure.

And somehow, they are all expected to keep building it together.

Languages Don’t Collapse, Alignment Does

The story of Babel is usually told as the moment communication broke.

But Babel didn’t fail because people stopped talking.

It failed because they stopped building from the same blueprint.

People don’t need to stop speaking to drift apart.

They only need to start making decisions based on different assumptions.

One team reinforces the tower for safety.

Another extends it for growth.

Another adjusts it to satisfy external requirements.

Each decision makes sense on its own.

The problem appears when nobody is looking at how those decisions affect the structure as a whole.

_Murphy’s Law reminds us: Anything that can go wrong, will go wrong.
_
And in complex systems, failure rarely appears where people are paying attention.

It appears where assumptions collide.

Everyone Is Still Building, Just Not The Same Tower

What makes modern Babel dangerous is not silence.

Everyone is still communicating.

Everyone is still working.

Everyone is still building.

But slowly, something changes.

Each part of the organization starts to believe it is building the tower on its own.

Not just a floor or a part of it.

And from that moment, the shared picture starts to break.

Decisions stop connecting to each other.

Each team keeps improving what it can see.

Yes, the tower can survive different perspectives.

But what it cannot survive is each floor following its own blueprint.

And this is where GRC becomes necessary.

Not because people stop building together.

But because they stop seeing the same tower.

Deciding How The Tower Should Grow

GRC is often described as Governance, Risk and Compliance.

Technically, that’s correct.

But in the context of Babel, that definition is too narrow.

GRC exists because a single tower can no longer rely on a single interpretation of what “correct construction” means.

It doesn’t restore a lost language.

Instead, it provides a framework for decisions.

One that helps decide which changes strengthen the structure and which start to pull it in the wrong direction.

Not by removing disagreement, but rather by making it manageable.

There Are Many Ways To Build A Tower

One of the easiest traps to fall into is believing there’s a perfect version of the tower somewhere.

A design that everyone would support if they just had enough information.

Babel challenges that idea.

Add a control and something slows down.

Remove a step and something becomes more exposed.

Improve one part of the structure and another part must adapt.

That’s the nature of building complex systems.

There is no final version where every goal is achieved at the same time.

Only a continuous balance between competing priorities.

The tower doesn’t become perfect.

It becomes stable enough to keep growing.

So What’s GRC Role In The Build?

Not safety.

Not compliance.

Not control.

Those are outcomes.

At its core, GRC exists to keep the tower standing while different people continue building it with different assumptions.

Not by forcing agreement.

But by providing enough structure for decisions to move forward.

GRC is not the architect of the tower.

It simply helps ensure that everyone is still building the same one.

Babel Never Goes Away

This is the part people usually get wrong.

GRC doesn’t fix Babel.

It doesn’t bring back a single language.

It doesn’t make everyone see the same tower again.

Because that was never the real problem.

Different teams will always see different things.

Different priorities will always exist.

And that will not disappear.

So instead of trying to remove the difference, GRC works inside it.

It makes sure that even with different views, people can still build without pulling the tower apart.

Not by removing divergence.

But by preventing it from breaking the structure.

Final Thoughts

Perhaps the lesson of Babel was never that people stopped speaking.

Perhaps it was that no one could see the whole tower anymore.

Modern organizations face the same challenge.

Each team sees a different part of the structure.

Each one protects a different concern.

And each believes it understands the tower.

GRC doesn’t give anyone a complete view of it.

It simply ensures that despite that limitation, everyone keeps building the same one.

Building the Human Body: How Design Reviews Shape Secure Systems

oliverbeenthere — Fri, 03 Jul 2026 13:25:00 +0000

A Walk Through SDLC, SSDLC and System Design

When I think about the root causes of major system failures, I realize that most of these problems didn’t appear out of thin air during production.

No.

They existed long before the system ever went live.

And yet, somehow, most teams still discover them only when it’s too late — when the system has already entered the real world.

I find that rather odd.

As Murphy’s Law reminds us: Anything that can go wrong, will go wrong.

And when dealing with complex systems, it usually does.

So why do we continue treating security as something that can be added easily after a system is already “born”?

After all, if we were building a human, we wouldn’t wait until adulthood to design its immune system.

What If Our System Were a Human Body?

A useful way to understand secure system design is to stop thinking about systems as software components.

Instead, imagine something far more complex: the human body.

A living organism where every part is connected — from the brain and organs to the blood and immune systems.

Each organ depends on another.

The heart cannot function without the lungs.

The brain cannot function without oxygen.

And the immune system protects the entire body.

A failure in one area can quickly affect the entire organism.

Secure systems are no different.

This is where SDLC, SSDLC and Design Reviews come into play.

SDLC: How Systems Grow

The human body develops through distinct phases, just like systems evolve through a lifecycle of their own.

This growth unfolds in clear stages:

**Requirements **define the genetic blueprint (such as a DNA) — the foundation of what the system becomes.

**Design **defines how internal systems connect and interact — showing how the “organs” work together.

**Development **is where those parts form into a functioning organism.

**Testing **validates that everything works together as expected.

**Deployment **is when that system begins operating under real conditions.

This is known as the Software Development Life Cycle (SDLC).

But even in this structured process, there is a key limitation:

Security is often introduced too late.

So by the time the system is built, architectural decisions are already in place, dependencies are formed and changing the structure becomes more difficult.

In many ways, it’s like trying to influence how a human body develops after its form has already been defined.

SSDLC: Let Security Grow With the System

Security in modern systems should not be treated as a final layer added at the end.

Instead, it must be part of how the system is shaped from day one.

Much like an immune system that develops alongside the body rather than being attached later in life.

**Secure Software Development Life Cycle (SSDLC) **ensures that security is embedded while the system is still being designed.

That way, security requirements are defined alongside functional requirements.

Threat modeling becomes part of design, allowing risks to be identified before decisions are locked in.

Security considerations influence architecture early rather than being applied later as “fixes”.

**Validation **happens continuously throughout development.

In this model, security is not added to a finished system.

It evolves together with the system itself.

Design Reviews: The Health Checkpoints

If SDLC represents system growth, Design Reviews act as health checkpoints along the way.

Just as physicians monitor development through stages of life, architects use Design Reviews to ensure systems evolve correctly.

These reviews turn security from a reactive step into a built-in part of design.

At SRR (System Requirements Review), the focus is understanding what is being built before it takes shape.

If requirements are the genetic blueprint, SRR validates it.

We clarify purpose, assumptions, limitations and risks.

We start asking: What is the system meant to do? What exactly are we protecting? What risks are already present?

At PDR (Preliminary Design Review), the system begins to take form.

Components start emerging, data flows become clearer and trust boundaries start to surface.

We reach a point where security naturally shifts into an architectural perspective.

Now, we can start asking how things actually connect by gathering the right information: How do components communicate with each other? How is identity represented throughout the system? Where are the trust boundaries and how they might be challenged?

Last, but certainly not least, we have CDR.

In CDR (Critical Design Review), the system is getting close to production.

At this point, the architecture should already feel complete and consistent.

Security controls are no longer theoretical — they are expected to already be in place.

Open risks should be clearly understood and not still being uncovered.

This is no longer about exploring design options, but about validating that the system is ready to move forward.

After this stage, changes become significantly harder to absorb.

FYI, Across all these stages, Security Architecture helps surface risks, challenge assumptions and keep security embedded as the system evolves.

This article doesn’t include the full list of Design Reviews, but feel free to explore them and read more online!

When Growth Happens Without Guidance

As you can see, without SDLC, SSDLC and Design Reviews working together, problems tend to surface much later in the process.

Risks that could have been identified during planning are only discovered during implementation.

Security controls are added unevenly across different parts of the system.

Design assumptions remain unquestioned until they become real constraints.

From the outside, the system may appear healthy.

But underneath, weaknesses have already started to form.

Much like the human body, individual parts may function perfectly well on their own.

The problem begins when those parts were never designed to work together as a complete organism.

By the time these weaknesses become visible, fixing them is often far more expensive than preventing them in the first place.

And we all know how high hospital bills can be.

A Reality Check…

On a personal note, I can’t count the number of gaps I’ve encountered in projects where security involvement came too late in the process.

At that stage, systems are already highly defined and decisions are deeply embedded in implementation.

Changes are no longer theoretical — they require real engineering effort, budget adjustments or even architectural redesigns.

Sometimes it means adding new features that were never part of the original scope, just to align the product with security requirements.

Other times, it means revisiting parts of the design and making adaptations just so it will fit the secure environment.

All of this translates into additional time, resources and effort.

This is exactly the point where influence is still possible, but every decision comes with a very real cost.

Just Remember

A system, much like the human body, carries the consequences of how it was allowed to develop.

Every decision leaves a mark.

Some become strengths. Others become weaknesses.

By the time a system enters production, much of its character has already been formed.

At that point, security is not introduced, it’s simply revealed.

Threat Modeling - But First, Let’s Talk About Space

oliverbeenthere — Fri, 03 Jul 2026 07:45:00 +0000

As an astronomy nerd, I can’t explain a technical concept without somehow dragging space into the conversation. So, to explain threat modeling, let’s look at our solar system.

Every planet is different. Each follows a different orbit, exists in a different environment, and is exposed to different risks. If we want the system to remain stable, we need to understand all of those moving parts — not only how they interact with each other, but also what external threats could suddenly appear and disrupt them.

After all, you cannot protect something if you don’t understand the universe it lives in.

Let’s take a journey through the sky and follow the STAR:

(S)cope
(T)hreats
(A)ssessment
(R)eview

Scope

Before anything else, we need to understand where we are.

Imagine you’re drawing a map of our solar system: which celestial bodies exist, how they move through space, and how they influence one another. In threat modeling, the professional term for this map is a Data Flow Diagram (DFD).

A DFD helps us build a complete picture of the environment by identifying its key components:

**Processes **are the active resources within the system — the planets and stars that keep everything moving.
Data Stores are the space stations, observatories, or satellite systems that hold valuable information about our universe.
External Entities are the objects that exist outside our system, such as spacecraft, asteroids, or anything else that can interact with our environment.
Trust Boundaries are the atmospheric borders we choose to monitor and protect, separating one level of trust from another.

By mapping these elements, we can better understand the potential path of an incoming object.

Where is it coming from?
Where is it likely to go?
What could it impact?
How significant would that impact be?

These are the same questions we ask when analyzing potential attack paths within a system.

Things become even more interesting in cloud environments.

There, we also need to account for the Shared Responsibility Model, managed services, IAM roles, and serverless architectures.

Suddenly, our solar system becomes much more dynamic — stars can appear and disappear without a warning, moons can be attached to planets overnight, and parts of the universe can change shape faster than we can draw the map.

Threats

Great. We have a map, and we know what we’re trying to protect.

The next question is: what exactly are we protecting it from?

This is where **STRIDE **comes in — a threat categorization model that helps us systematically identify what could go wrong.

In our little galaxy, it might look something like this:

*Spoofing *— Impersonation. Is this actually a planet that belongs in our system, or an unknown object pretending to be one?
*Tampering *— Integrity violations. Has someone altered the official orbital records of a planet?
*Repudiation *— Lack of accountability. Were observation logs manipulated to hide what really happened?
Information Disclosure — Exposure of sensitive information. Has confidential data from the Sun been leaked to the rest of the system?
Denial of Service — Disruption of availability. Did the loss of a moon destabilize a planet and disrupt life as it knows it?
*Elevation of Privilege *— Unauthorized gain of authority. An asteroid becomes a planet. A planet attempts to become the Sun.

The goal isn’t to predict the future perfectly. The goal is to make sure we’re looking at the problem from every possible angle.

As Murphy’s Law reminds us: Anything that can go wrong, will go wrong.

Can something enter our solar system without being detected?
Are there planets with weak atmospheric protection?
Do we have dark regions that nobody has observed, documented, or monitored?
If an asteroid were to collide with a planet, how severe would the impact be?

Threat modeling is the process of asking these questions before reality asks them for us.

Assessment

What comes next?

After mapping out all the potential threat scenarios, the next step is deciding what we actually do about each of them.

In threat modeling, there are four primary strategies:

Mitigate — Reduce the risk. We need to harden the environment: adjust orbital paths, limit exposure to vulnerable atmospheric layers, and define clear responsibilities between celestial bodies to minimize collision risks.
Eliminate — Remove the threat entirely. For example, destroying an incoming asteroid or eliminating an orbital path that could lead to a collision in the first place.
Transfer — Shift responsibility. This could mean making each planet responsible for its own protection decisions, or delegating risk ownership to a central governing body like the Sun.
Accept — Acknowledge the risk and live with it. If no viable mitigation exists, the system may have to absorb the impact. But even then, acceptance is rarely passive: we might redirect the object toward a less critical impact zone, prepare controlled “honey pots”, strengthen atmospheric defenses to reduce damage, or closely track the object to learn its origin and prevent similar future events.

To support this stage, practitioners often rely on frameworks such as the OWASP Application Security Verification Standard (ASVS), the NIST vulnerability catalog (including the MITRE CWE database), and security control frameworks like NIST SP 800–53.

The key principle here is practicality.

Decisions must be concrete, precise, and practical. A vague mitigation like “encrypt the data” is not enough. Instead, we define exactly what that means in practice — for example: “Apply AES-256 encryption to all data in transit between system components.”

We also define strict communication rules. For instance, Mars may only communicate with Venus through a designated communication channel, while Venus receives information from the Sun only via a specific frequency band.

If an action cannot be implemented in a clear, enforceable way, it is unlikely to be executed — and ultimately, the entire purpose of threat modeling is lost.

Review

Time to pause and take a step back.

Did we do this properly?

Are all the Data Flow Diagrams (DFDs) we created accurate?
Did we identify all possible threats?
Did we define a response for each one of them?
Did we validate the strength and reliability of the defenses we put in place?
And finally, is all the documentation accessible and shared with the relevant stakeholders?

It’s important to remember that threat modeling is not a one-night exercise where we look through a telescope, take a snapshot of the sky, and assume we’ve captured the entire universe.

It’s an ongoing observation.

The universe is constantly changing — and so is our system.

New planets may be added, moons may appear, and spacecraft may enter entirely new trajectories. Each of these changes can shift the entire map we’ve built.

A new addition to the data flow can introduce new threats, which require new responses, updated defences, and continuous reflection on whether we’ve missed anything.

In other words, threat modeling is not just a process — it’s a mindset.

When we start viewing a system as a collection of celestial bodies, we fundamentally change how we approach it. We stop assuming stability and start assuming change. Because in space — as in security — we cannot afford to ignore small cracks.

Every small crack is a potential point of failure.

And when it’s done right, this approach gives us better visibility, stronger awareness, more resilient defences, and far fewer surprises in production.

So, fellow astronauts — I think it’s time to navigate the stars safely!

The Orchard of Trust: Hardware Security Foundations It all comes down to soil, seeds, and greenhouses.

oliverbeenthere — Fri, 03 Jul 2026 07:25:00 +0000

The world of Hardware Security often looks massive and intimidating from the outside. A dense mix of technical concepts around components, protocols, layers, and diagrams.

It makes you a bit paranoid, so you ask:

Why should I trust anything in a world where everything could potentially be fake?

This is not an architecture of protection. It’s an architecture of trust.

Systems are not primarily built around “how things work,” but around “who is allowed to be trusted in the first place.”

So let’s step away from servers and processors for a moment, and move somewhere completely different:

An orchard.

The Soil — Root of Trust

Just like in agriculture, we go back to the basics.

Before there are seeds, trees or any kind of harvest — there is soil.

Is every type of soil trustworthy?

No. Some soils are fertile, while others are contaminated — by nature, by environment or by human intervention.

This is why we need a defined starting point: a baseline layer in the soil that we can rely on without needing to verify it every time, and from which the entire chain of trust begins. This is the Root of Trust.

In system design, this trust anchor is usually a hardware component or immutable firmware that is extremely difficult to change, such as a Boot ROM or a Secure Element.

The Inspection System — Secure Boot

Alright, we have soil that we’ve defined as trustworthy — but everything we grow depends on it. From roots all the way to fruit.

We can’t verify everything at once.

We need to define a security hierarchy:

So each layer verifies the next one before allowing it to run?

Exactly.

If the roots are healthy — we move to the trunk.
If the trunk is healthy — we move to the branches.
If the branches are healthy — we can proceed to the fruit stage.

But if at any point contamination is detected in the roots, or the trunk is found to be rotten, the entire growth chain stops.

This is where Secure Boot comes in. It’s not a single “one-time check”, but a chained trust model built across multiple layers of execution.

The Seed Bank — TPM and HSM

At the end of the day, the most critical element in achieving healthy and reliable growth is the seeds.

Not just any seeds — these are the most valuable seeds in the entire orchard.

If someone gains access to them, they don’t just steal a harvest. They can:

Create independent replicas of the yield
Forge produce at will
Control the quality and quantity of agricultural output

So what do we do?

We build a dedicated storage mechanism — a secure vault — to protect the seeds.

We don’t rely on a regular storage shed. These are extremely sensitive assets, and we cannot allow them to be taken out or exposed.

This is the TPM: a small hardware-based vault for storing cryptographic keys and other critical data.

Let’s take it one step further:

What if we’re not talking about a single orchard owned by one farmer?

For a broader, national-scale solution, we use an HSM.

Unlike a TPM, which protects the seeds of a single orchard, the HSM protects the assets that an entire country’s agricultural system depends on.

In the agricultural analogy, these are the original seeds of all national crops.

In the digital world, these are the assets that allow a state to prove identity, sign data, and operate critical systems:

Digital signatures
Identity credentials
Government systems
Financial systems

If it is compromised — the entire digital trust of the state collapses.

Proving System Integrity — Attestation

The agricultural system is now stable, secure, and beginning to thrive. A foreign supplier wants to work with the country.

So they ask a simple question:

How do I know your produce is not compromised or contaminated?

The state doesn’t respond with “trust us.”

Instead, it provides evidence:

The so

il is verified as safe
All layers of the trust chain are validated
The seeds are securely stored
The orchard is built and operating according to predefined standards

This process is called attestation — proving system integrity through verifiable evidence rather than claims.

The Greenhouses — TrustZones

So far, we’ve focused on building a healthy and stable growth process:

Protecting the soil
Protecting the growth chain
Protecting the seeds

But as the orchard starts to scale and thrive, new challenges begin to appear:

Workers moving between different fields
Equipment coming in and out
Shipments being sent abroad
Increasing day-to-day operational activity

At this point, not everything happening in the orchard carries the same level of importance.

Some activities are routine. Others — if compromised — could put the entire system at risk.

So we introduce a dedicated greenhouse for the most sensitive parts of the system.

Not every worker is allowed in. Not every tool is allowed inside. Not every crop is allowed to grow there.

In system design, this greenhouse is called the TrustZone.

It separates the system into two worlds:

The Normal World
The Secure World

And inside the secure world, the most sensitive operations take place:

Identity verification
Cryptographic operations
Biometric data handling

The Vault Inside the Greenhouse — Enclaves

The paranoia doesn’t go away. You start wondering:

Is this enough?

Because if there’s one thing we learn in security, it’s that even well-protected systems can still fail.

The greenhouse is meant to protect the most sensitive crops, but what happens if someone eventually finds a way inside it? Maybe one of the workers inside the greenhouse is no longer trustworthy. Or even the greenhouse manager themselves.

So another layer is introduced — an isolated vault inside the greenhouse.

Not everyone inside the greenhouse has permission to open it, and not everyone who sees it is allowed to understand what’s inside.

This vault exists to protect the most critical assets, even when previous security layers have failed. This is called an Enclave.

It is an isolated execution environment where sensitive operations can still run securely, even when other parts of the system are no longer trusted.

Putting It Into Practice

Hardware Security is not just a collection of technologies.

It starts from one simple idea:

My trust cannot depend on a single point of failure.

So we build layers, separate domains, and protect the most critical assets.

We assume from the beginning that parts of the system can be compromised.

Just like in an orchard.

If someone reaches the gate, it doesn’t mean they reached the greenhouses.

If they reached the greenhouses, it doesn’t mean they reached the vaults.

And even if they reached the vaults, it still doesn’t mean they can break the entire chain of trust the system relies on.

And so, as we move deeper into the orchard — from the soil, through the growth chain, to the seeds, the greenhouses, and the inner vaults — we keep adding layers of trust.

Because at the end of the day, Hardware Security is not just about protecting components.

It is about building trust.

Defining who trusts whom, what validates what, and what still remains secure even when something else fails or breaks.

As Murphy’s Law reminds us: Anything that can go wrong, will go wrong.

And that leads to perhaps the most important question in any system:

When something breaks, what can still be trusted?

Is Your LLM Into You? The Red Flags You Miss When Crushing on AI

oliverbeenthere — Fri, 03 Jul 2026 07:10:00 +0000

Oh, the butterflies of a fresh new relationship. It all seems harmless and beautiful.

You open a new chat, ask a question, and the LLM responds instantly.

No getting “left on read”. No “short unpolished answers”.

It’s perfect. Maybe a little too perfect…

And that’s usually the part where things might go wrong.

You see, the more you work with real LLM-based systems in production, especially those that contain RAG, tools and multiple layers, you start to feel slightly uneasy.

Who is this model you built a relationship with?

Are you starting to trust a bit too quickly?

Let’s break down the red flags🚩

For a moment, you notice it starts sounding way too certain.

All your concerns and questions are answered with full confidence, even when there is no reliable ground for the information it gives you.

That’s the first red flag — hallucination.

Speaking in technical terms, a hallucination happens when a model generates output that is not grounded in factual data or external sources.

In production, it doesn’t present itself as a failure.

Instead, a “perfectly formatted answer” gets sent to the user — leading to wrong decisions and directions.

The issue is not that it’s wrong.

It’s how right it sounds.

Then you enter a phase where you feel like someone is watching you. He knows things you didn’t tell him.

That’s where RAG, known as Retrieval-Augmented Generation, enters the picture.

Suddenly, instead of relying solely on internal models, your system pulls in external context while answering your query. It usually comes from external documents or data sources. It feeds it to the model as extra context.

So now he might be less “day dreaming” and feeding you nonsense, but it also shifted how you trust him.

He’s not working alone anymore, he’s relying on external context making it harder to trust him fully. Somebody in the corner is throwing him hints and clues, so you’re no longer sure which thoughts are really his. It all feels like a collaboration you didn’t fully agree to — different voices from the same system. That is the retrieval layer.

Another red flag is raised, he’s repeating things he probably heard from “somewhere else”.

Back to technical details, this introduces you to a risk of data poisoning. There, any malicious or incorrect data can be injected into the knowledge base. You might also face retrieval abuse, information that shouldn’t be accessible is now being used.

Heck, even the documents that are being used can be an attack surface. A prompt injection hiding instructions inside the content in order to follow and influence the model’s behavior without the user realizing it.

Do you really want him to know you are talking to other guys?

Do you want him to give you a cold shoulder out of the blue?

At this point, it stops feeling like a system and starts feeling like a relationship with blurred boundaries.

Murphy’s Law sums it up perfectly: Anything that can go wrong, will go wrong.

So if your bond can break, it will eventually break.

It won’t happen suddenly. Slowly, over time, it will no longer feel safe to put your trust in.

You take the relationship to the next level.

Past the talking stage — he begins to take actions.

Whether he uses function calling or flowers, he starts doing things outside the conversation.

You realize he didn’t ask about your plans or availability before scheduling a dinner reservation.

So you reach the next red flag:

You’re no longer the advisor and you’re no longer fully in control of how things unfold.

At this point, over-permissioning starts to matter.

The model has more access than it should.

There’s no clear line between suggestion and execution.

This can evolve into tool chaining — where one tool call triggers another.

Just a sequence of actions that no one explicitly intended to accomplish.

Suddenly, it becomes unclear what the “true intentions” were behind the behavior you’re witnessing.

He’s no longer the man you used to know, and that’s no longer the system you thought you built.

If you thought that was enough already, you’re mistaken.

There’s another layer underneath everything: agentic systems.

Here, the LLM is no longer just responding or triggering tools. It‘s planning ahead.

Breaking goals into smaller steps, executing them, checking the results and adjusting along the way.

This creates a fourth red flag — emergent behavior.

It’s not a behavior that was explicitly programmed, but one that emerges from interactions between components.

It’s hard to clearly define this behavior, because there is no single place in the system where you can say: “oh, this is why it happened”.

Even though you didn’t agree on it in the terms of your relationship, it just… happens.

We’ve reached a silent killer: fine-tuning and model adaptation.

Unlike runtime behavior, this changes the model itself.

Through training data, fine-tuning pipelines, or updates to embeddings and knowledge bases, the model can gradually change over time.

This introduces risks like data poisoning during training, or model supply chain tampering — where the system is influenced before it even reaches production.

And the most dangerous part? nothing looks broken.

The system still works, it just behaves differently.

Slowly. Subtly. Almost like nothing changed between you.

But something definitely did.

You try to take a step back and glue the pieces back together. Searching for a pattern that explains everything.

The truth is — there’s no single “LLM security problem”. There are only different ways trust breaks inside the system, and it rarely happens where you expect.

He seems to know things on his own.

Then he knows things he shouldn’t.

He starts acting instead of responding, or making decisions you never expected.

And sometimes, he just changes.

Quietly. Over time. Without any clear signal that anything changed at all.

You don’t notice it immediately. After all, nothing actually broke.

It just feels... different.

And maybe that’s what makes it feel like a relationship.

I mean, the system doesn’t usually fail in obvious ways. It doesn’t break. It keeps responding. Keeps acting. Keeps sounding confident — even when something underneath is already wrong.

And the longer you stay in that “crush” phase, the more you rely on how smooth it feels, how confident it sounds, and how much it feels like it understands you.

Making it so easy to miss the red flags.

Not because they are hidden.

But because they feel like trust.