STRIDE in Infra

STRIDE isn't just for developers — it belongs in every system an IT admin touches

Most people who've heard of STRIDE picture it in a very specific room: a whiteboard, a data-flow diagram, a team of application developers arguing about whether an attacker could forge a JWT. It gets filed under "AppSec practice" and left there.

That's a mistake. STRIDE isn't a framework for code — it's a framework for systems, and infrastructure is a system. Every time an IT admin stands up a new service, grants an access policy, configures a cloud resource, or automates a workflow, they're making the exact same category of decisions a developer makes when they design an API. The only difference is nobody's asking the STRIDE questions out loud.

A two-minute refresher

STRIDE, developed at Microsoft, breaks threats into six categories. For any component in a system, you ask:

• Spoofing — can something impersonate a legitimate identity here?
• Tampering — can data or configuration be modified by someone who shouldn't be able to?
• Repudiation — if something goes wrong, is there proof of who did what?
• Information Disclosure — can something leak that shouldn't be visible?
• Denial of Service — can this be knocked offline or made unusable?
• Elevation of Privilege — can access here be used to gain access somewhere else?

Six questions. That's the whole framework. The power isn't in complexity — it's in the discipline of asking all six, every time, instead of the two or three that happen to occur to you in the moment.

Why IT admins skip this (and why that's backwards)

Developers get threat modeling drilled into them because their output is code that ships to end users — it feels like a product with a security surface. Infrastructure work feels different: you're granting a role, opening a port, standing up a bucket, writing an automation script. It doesn't feel like "building a system." But it is one. A Vault policy is an access-control system. A cross-workspace user sync is an identity system. A CI/CD pipeline is a system that can push code to production. Every one of these has a Spoofing question, a Tampering question, an Elevation of Privilege question — whether or not anyone asks them.

The result of skipping this isn't usually a dramatic breach. It's the slow accumulation of exactly the things a credential audit eventually finds: a service account with more scope than it needs, an API key with no rotation and no owner, a bucket policy that's technically "temporary" and has been that way for two years, a script running with admin rights because it was faster to set up that way at 5pm on a Friday. None of these were malicious decisions. They were just decisions made without the six questions attached.

Walking STRIDE across ordinary infra work

Spoofing shows up any time you're deciding how something proves its identity. A service account authenticating to an API, a new node joining a domain, an app calling into a secrets manager — in each case, ask what stops something else from successfully claiming to be that identity. If the answer is "nothing, really, if you have the shared key," that's the finding.

Tampering is about who can change state, not just who can read it. A config file, an IAM policy, a DNS record, a deployed script — anyone with write access can tamper with it, intentionally or by mistake. The question isn't "is this encrypted," it's "who can modify this, and would I know if they did."

Repudiation is the one infra teams skip most often, because it doesn't stop anything from working — it only matters after something's gone wrong. No access logging, no audit trail, no versioning: everything runs fine right up until you need to answer "who did this and when," and you can't. This is usually the cheapest gap to close and the one most often left open, because it has zero effect on day-to-day operation.

Information Disclosure isn't only about attackers — it's about defaults. A storage bucket that's public because that was the path of least resistance during setup. A documentation file with architecture details sitting somewhere a link could reach it. A verbose error message returning a stack trace to an unauthenticated caller. Ask, for every resource: who can see this today, and is that intentional or incidental?

Denial of Service in infra terms is rarely about traffic floods — it's more often about single points of failure and unthrottled dependencies. One admin's credentials gating access to everything. One script with no timeout that can hang a pipeline. One API with no rate limit that a runaway internal process can hammer into unavailability without any attacker involved at all.

Elevation of Privilege is the one that compounds. Access reviews exist because scope creeps by default, not by exception — a role granted for one task quietly becomes the role used for everything, because revoking access is more friction than keeping it. The question to ask on every new grant: what's the blast radius if this specific credential is the one that leaks?

Making it a habit, not a ceremony

The failure mode with any framework is treating it as a document you fill out once and file away. STRIDE earns its keep as a five-minute mental pass before you implement anything — not a retrospective audit exercise.

A workable version of this, for infra work specifically:

1. Attach it to the change request, not a separate process. If your team already uses a structured change template — description, scope, impact, implementation, validation — add one line per STRIDE category as a required field, even if most of the time the answer is "N/A, here's why." The discipline is in being forced to consider each one, not in every category always mattering.
2. Ask it at design time, not review time. By the time something's built, the STRIDE conversation becomes "should we redo this," which nobody wants to hear. Asked before implementation, it's just part of picking the approach.
3. Scope it to the actual component, not the whole system. You don't need to threat-model your entire cloud environment every time you add one IAM role. Threat-model the role. Six questions, five minutes, move on.
4. Write down the gaps you're accepting, not just the ones you close. Sometimes the honest answer to a STRIDE question is "we're accepting this risk for now" — logging isn't set up yet, or a WAF is deferred to stay within a budget. That's a legitimate outcome, as long as it's a decision someone made on purpose, not a gap nobody noticed.

The point isn't the framework

STRIDE isn't valuable because it's clever — it's valuable because it's a forcing function. Left to instinct, most people ask the security questions that are top of mind for whatever they most recently read about or got burned by, and skip the rest. STRIDE's only real job is making sure all six get asked, every time, on things that don't feel like "security work" until the day they are.

The infrastructure you stand up rarely announces itself as a system with an attack surface. It just looks like a bucket, a policy, a script, a role. Treating it like a system anyway — one worth six quick questions before it goes live — is the difference between security being something you bolt on after an incident, and something that was just how you built it in the first place.