DEV Community: oliverbeenthere

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.