Zero to Hero: Cybersecurity Architecture Masterclass, Module 2
← Module 1: Core Mental Models · Module 2: Proactive Design · Module 3: Cloud-Native Hardening →

11 min read

TL;DR

• STRIDE threat modeling is a checklist for finding design-level vulnerabilities before code exists: Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege
• Run it against a data-flow diagram, not against code — every process, data store, and trust boundary gets checked against all six categories
• DREAD risk scoring turns “this is a threat” into a number, so you can prioritize which findings become engineering tickets first
• Trust boundaries — anywhere data crosses from one privilege level to another — are where most real threats concentrate
• Free, code-based tools (pytm, OWASP Threat Dragon) let you version-control your threat model the same way you version-control infrastructure
• STRIDE run once at design time catches classes of bugs that a penetration test only catches after the system already shipped

The Big Picture: STRIDE Threat Modeling in One Checklist

Every element in a system — a process, a data store, a data flow, an external entity — can fail in up to six ways. STRIDE threat modeling names them so you check for all six instead of whichever one happened to occur to you.

STRIDE THREAT MODEL — APPLIED PER SYSTEM ELEMENT
──────────────────────────────────────────────────────────────
 Threat Category          Security Property Violated
──────────────────────────────────────────────────────────────
 S  Spoofing               Authenticity   — are you who you say?
 T  Tampering              Integrity      — was this modified?
 R  Repudiation            Non-Repudiation— can this be denied?
 I  Information Disclosure Confidentiality— who else can read this?
 D  Denial of Service      Availability   — can this be starved?
 E  Elevation of Privilege Authorization  — can this reach more than it should?
──────────────────────────────────────────────────────────────
       ↑ maps directly onto the Extended CIA Triad from Module 1

STRIDE threat modeling is a systematic way to find design flaws before a single line of code exists, by checking every element of a system against these six failure modes instead of relying on whoever’s reviewing the design to think of them unprompted.

Why “Shift Left” Needs a Checklist, Not Good Intentions

Module 1 closed by naming the “Shift Left Myth” — teams that call a CI security scanner “shifting left” when the actual architecture was never reviewed at the design phase at all. A CI scan finds vulnerabilities in code that already exists. STRIDE finds the ones that don’t need code to exist yet, because they’re baked into the design: a service that trusts an internal network by IP address, a queue with no message-origin verification, an admin API reachable from the same trust zone as public traffic.

A team building a new internal billing service skips a design review — “it’s internal, it’s fine” — and ships it trusting any caller on the VPC. Eight months later, a compromised marketing-analytics pod (unrelated team, unrelated purpose, same VPC) calls the billing API directly and issues refunds. Nothing was “hacked” in the traditional sense. The design simply never asked: what happens if something on this network isn’t who we assumed?

That’s a Spoofing failure, and STRIDE would have surfaced it in an hour-long design review, months before the analytics pod existed.

Running STRIDE Against a Data-Flow Diagram

STRIDE is applied to a Data-Flow Diagram (DFD) — not to source code, and not to infrastructure diagrams showing subnets and security groups. A DFD has four element types, and each type is only vulnerable to a subset of STRIDE:

 Element Type        Vulnerable To
 ──────────────────  ─────────────────────────────────
 External Entity     Spoofing, Repudiation
 Process              Spoofing, Tampering, Repudiation,
                       Info Disclosure, DoS, Elevation
 Data Store           Tampering, Info Disclosure, DoS,
                       (Repudiation if no access logging)
 Data Flow            Tampering, Info Disclosure, DoS

Processes are checked against all six categories because they’re where identity, logic, and privilege all live. Data stores can’t “spoof” anything — but they can absolutely be read or written by someone who shouldn’t, or overwhelmed.

Trust boundaries are drawn as dashed lines across the diagram anywhere a data flow crosses from one privilege or trust level to another: public internet → load balancer, application tier → database tier, one team’s service → another team’s service, on-prem → cloud. Every element sitting directly on a trust boundary gets checked first, because that’s structurally where real threats concentrate — an internal-only process that never sees a trust boundary is a much lower priority than an internet-facing one processing untrusted input.

The billing-service incident above is a trust-boundary failure by definition: the design never drew a boundary between “our service” and “anything else on the VPC,” so nothing on that (missing) boundary was ever checked.

Working the Six Categories

Spoofing — Can an entity convincingly pretend to be something it isn’t? Mitigations: mutual TLS, signed service tokens, SPIFFE/SPIRE identities instead of IP-based trust (Module 1’s Zero Trust principle, applied concretely).

Tampering — Can data be modified in transit or at rest without detection? Mitigations: TLS in transit, checksums/signatures on artifacts, database-level integrity constraints, immutable audit logs.

Repudiation — Can an actor perform an action and later credibly deny it? Mitigations: signed, centrally-shipped audit logs (CloudTrail, Kubernetes audit logs) that the actor cannot modify after the fact — this is why Module 1 called non-repudiation an architectural requirement, not a compliance checkbox.

Information Disclosure — Can data reach an entity that shouldn’t see it? Mitigations: encryption at rest and in transit, least-privilege IAM, field-level access control for sensitive data classes.

Denial of Service — Can an entity be starved of resources it needs to function? Mitigations: rate limiting, autoscaling with sane ceilings, circuit breakers, resource quotas per tenant.

Elevation of Privilege — Can an entity reach capabilities beyond what it was granted? Mitigations: strict RBAC, no ambient authority, explicit privilege boundaries between services — this is the category both the iam:PassRole privilege-escalation pattern (covered in the IAM series) and misconfigured S3 buckets escalating to admin access belong to.

Scoring What You Find: DREAD

STRIDE tells you what kind of threat exists. It says nothing about how bad it is. A dozen findings with no prioritization is not actionable — DREAD converts each finding into a 0–10 score across five dimensions so engineering can triage like any other backlog:

 D  Damage Potential     — how bad is the worst case if exploited?
 R  Reproducibility      — how reliably can it be triggered?
 E  Exploitability       — how much skill/access does it require?
 A  Affected Users       — how much of the system/user base is exposed?
 D  Discoverability      — how easy is it to find unassisted?

 DREAD score = average of the five (0–10 scale)

The billing-service Spoofing finding above scores high on Damage (financial loss), high on Reproducibility (any pod on the VPC, repeatably), moderate on Exploitability (requires being on the VPC — not zero-effort, but not hard either), high on Affected Users (the entire billing system), and low-to-moderate on Discoverability (not obvious without VPC access, but not hidden either). That combination — high damage, high reproducibility — is exactly the profile that goes to the top of the backlog, above findings that are theoretically worse but require nation-state-level access to trigger.

Doing This as Code, Not a Whiteboard Session

A whiteboard threat model is useful for a workshop and useless six months later when the architecture has changed and nobody updates the photo. pytm and OWASP Threat Dragon let you define the data-flow diagram and its trust boundaries as a file, review it in a pull request, and regenerate the DFD and a STRIDE finding report on every change.

# threatmodel.py (pytm)
from pytm import TM, Server, Datastore, Dataflow, Boundary

tm = TM("Billing Service")
internet = Boundary("Public Internet")
internal = Boundary("Internal VPC")

api = Server("Billing API")
api.inBoundary = internal
db = Datastore("Billing DB")
db.inBoundary = internal

caller = Dataflow(api, db, "Query balance")
caller.protocol = "PostgreSQL"
caller.isEncrypted = True

tm.process()

# Generate the DFD and run the STRIDE analysis
$ python3 threatmodel.py --dfd | dot -Tpng -o dfd.png
$ python3 threatmodel.py --report json > findings.json

# Findings surface automatically per element/boundary, e.g.:
# [ELEVATION OF PRIVILEGE] Billing API -> Billing DB crosses no
# authentication boundary check; caller identity is not verified
# before query execution.

The model lives next to the code it describes, diffs like any other file, and a reviewer sees exactly what trust boundary changed when a new dependency gets added — instead of discovering it in production eight months later.

Production Gotchas

A threat model with no owner goes stale in one sprint. Assign the DFD file the same ownership as the service’s Terraform or Helm chart — whoever changes the architecture updates the model in the same PR.

STRIDE without trust boundaries drawn is just a vocabulary exercise. Teams sometimes run through all six letters against a whole system at once with no boundaries marked, producing a vague list nobody acts on. Draw the boundaries first; findings should cluster around them.

DREAD scores drift toward “everything is a 7” without calibration. Anchor each dimension with 2–3 concrete example findings from your own systems before scoring new ones, or every finding regresses to the mean and the prioritization signal disappears.

A code-based threat model is not a substitute for a design review conversation. pytm output is a starting point for discussion between the architect and the team, not a report to file away unread.

Framework Alignment

Key Takeaways

• STRIDE checks every system element against six named failure modes so nothing gets skipped because no one thought of it
• Run it against a data-flow diagram with trust boundaries explicitly drawn — findings cluster where boundaries are
• DREAD turns qualitative findings into a prioritized, comparable backlog
• Code-based threat modeling (pytm, Threat Dragon) keeps the model current instead of a stale whiteboard photo
• A threat model needs an owner tied to the architecture it describes, or it goes stale in one sprint

What’s Next

Module 2 gave you the process for finding design flaws before code exists. Module 3 takes one specific, high-stakes trust boundary — the AWS identity perimeter — and shows exactly how IMDSv2, IAM policy design, and infrastructure-as-code scanning close the Elevation of Privilege and Spoofing findings that STRIDE surfaces most often in cloud-native systems.

Next: Module 3: Cloud-Native Hardening — Securing the AWS Identity Perimeter

Get the full masterclass in your inbox → linuxcent.com/subscribe

The post STRIDE Threat Modeling: Proactive Security Design for Architects appeared first on Linuxcent.

Zero to Hero: Cybersecurity Architecture Masterclass, Module 1
← All Masterclass Modules · Module 1: Core Mental Models · Module 2: Proactive Design →

12 min read

Introduction

Modern cybersecurity architecture principles trace back to a single admission: in 2010, Google published the “BeyondCorp” whitepaper, the first high-profile confession from a tech giant that the corporate network — the “internal” network everyone trusted by default — was no longer safe. For decades, security was built on the Castle-and-Moat model: a hardened perimeter (the firewall) protecting a soft, trusted interior.

If you were inside the moat, you were trusted. If you were outside, you were a threat.

The rise of cloud, mobile, and sophisticated lateral-movement attacks has rendered this model obsolete. If an attacker compromises a single developer’s laptop or a single vulnerable Jenkins server, they are “inside the castle.” In a legacy architecture, the game is over.

Module 1 of the Masterclass establishes the core cybersecurity architecture principles required to move beyond the perimeter. We redefine the CIA Triad for the cloud era and establish the foundational shift to Zero Trust.

TL;DR

• The CIA Triad is no longer enough: Modern architecture requires the Extended CIA Triad, adding Authenticity and Non-Repudiation to Confidentiality, Integrity, and Availability.
• Defense-in-Depth is about redundant layers: A single failure (e.g., a leaked IAM key) should not lead to a total breach.
• Zero Trust rejects implicit trust: No network location is trusted. Every request is verified explicitly based on identity, device posture, and context.
• Security is a Product Requirement: Architectural security must be integrated into the SDLC (Software Development Lifecycle) from the “Definition” phase, not bolted on at “Deployment.”

The Big Picture: From Castle-and-Moat to Zero Trust

The fundamental shift in architecture is the transition from Network-Centric Trust to Identity-Centric Trust.

┌─────────────────────────────────────────────────────────────────────────────┐
│                   THE ARCHITECTURAL SHIFT: PERIMETER TO IDENTITY            │
├─────────────────────────────────────────────────────────────────────────────┤
│                                                                             │
│  LEGACY: CASTLE-AND-MOAT                  MODERN: ZERO TRUST ARCHITECTURE   │
│  (Implicit Trust)                         (Explicit Verification)           │
│                                                                             │
│  [ External ]                             [ External ]                      │
│       │                                        │                            │
│  ┌────▼────┐                              ┌────▼────────┐                   │
│  │ FIREWALL│ (The Moat)                   │ IDENTITY    │                   │
│  └────┬────┘                              │ PROVIDER    │                   │
│       │                                   └────┬────────┘                   │
│  ┌────▼──────────────┐                         │                            │
│  │ TRUSTED INTERIOR  │                    ┌────▼────────┐                   │
│  │ (soft center)     │                    │ POLICY      │                   │
│  │ [App] [DB] [Log]  │                    │ ENGINE      │                   │
│  └───────────────────┘                    └────┬────────┘                   │
│                                                │ (Always Verify)            │
│       FAILURE MODE:                       ┌────▼────────┐                   │
│       Compromised VPN =                   │ RESOURCE    │                   │
│       Full Access                         │ [App] [DB]  │                   │
│                                           └─────────────┘                   │
│                                                                             │
└─────────────────────────────────────────────────────────────────────────────┘

1. The Extended CIA Triad Deep-Dive

Every security decision you make as an architect eventually maps back to the CIA Triad. But for modern systems, the “Classic CIA” (Confidentiality, Integrity, Availability) is missing the two pillars that handle identity and accountability.

Confidentiality (Protecting the Data)

• At Rest: AES-256 encryption for S3 buckets or RDS instances.
• In Transit: TLS 1.3 for every internal and external API call.
• In Execution: Using Trusted Execution Environments (TEEs) or eBPF-based visibility to ensure memory isn’t being scraped.

Integrity (Trusting the Data)

• Hashing: Using SHA-256/512 to verify that the container image you pulled is the exact one you built.
• Digital Signatures: Signing your CI/CD artifacts so the production cluster only runs code signed by your build system.
• FIM (File Integrity Monitoring): Detecting when a binary in /usr/bin is modified on a live node.

Availability (Ensuring Access)

• Resilience: Multi-AZ deployments and automated failover.
• Protection: AWS Shield or Cloudflare to absorb L3/L4 and L7 DDoS attacks.
• Immutable Backups: Protecting data from ransomware using WORM (Write Once, Read Many) storage.

Authenticity & Non-Repudiation (The “Extended” Pillars)

• Authenticity: Proving the caller is who they say they are (MFA, Client Certificates).
• Non-Repudiation: Ensuring an action cannot be denied later. This is where Secure Audit Logs (CloudTrail, Kubernetes Audit) become architectural requirements, not just compliance checkboxes.

2. Core Architecture Principles: Defense-in-Depth

Defense-in-Depth is often misunderstood as “buying more tools.” In architecture, it means Functional Redundancy of Controls.

Think of it as a series of checks where no single check is the “God Gate.”

1. Policy Layer: SCPs (Service Control Policies) that disable entire AWS regions.
2. Perimeter Layer: WAF rules blocking SQL injection at the edge.
3. Identity Layer: MFA required for every console and CLI session.
4. Network Layer: Security Groups and Micro-segmentation (Cilium/Istio).
5. Endpoint Layer: EDR (CrowdStrike/Tetragon) monitoring for anomalous process execution.
6. Data Layer: Encryption with KMS keys that the application role must explicitly be granted access to.

Practitioner Depth: A classic failure is relying on a VPN for access control. If the VPN is breached, the “Depth” is revealed to be zero. A true Defense-in-Depth architecture assumes the VPN is breached and relies on the subsequent layers (Identity and Data encryption) to stop the attacker.

3. Dismantling the Castle-and-Moat (Zero Trust)

Zero Trust is the architectural implementation of the principle: “Never Trust, Always Verify.”

The Three Pillars of ZTA (NIST SP 800-207)

1. Continuous Verification: You don’t just verify at login. You verify every single request.
2. Limit Blast Radius (Micro-segmentation): If a web server is compromised, it should have no network path to the database except on the specific port required for the application.
3. Automate Context-Aware Response: If a user logs in from a new country and immediately tries to delete an S3 bucket, the architecture should automatically step up to MFA or revoke the session.

Zero Trust for IAM: We covered this extensively in IAM Episode 12. In architecture, this means moving the “Trust Boundary” from the edge of the VPC to the edge of the individual service or container.

4. Integration with the Software Lifecycle (SDLC)

Security architecture that exists only on a whiteboard is a liability. It must be integrated into the product management and development workflow.

The “Shift Left” Myth

Many teams talk about “shifting left” (moving security earlier in the cycle) but only implement it as a “pre-commit hook” or a “CI scan.”

True Shift Left is Architectural:
– Module 2 of this series covers Threat Modeling. This happens during the Design phase, before code exists.
– Module 3 covers Hardening. This happens during the Infrastructure-as-Code phase.

If you are catching architectural flaws during a “Penetration Test” (Shift Right), you have already failed Module 1.

Quick Check: Is Your Architecture “Leaky”?

Run these three checks on your environment to see if you are still relying on implicit trust:

# 1. Check for wide-open S3 buckets (Network-level trust check)
aws s3api get-public-access-block --bucket <your-bucket>
# Success: BlockPublicAcls/Policy/RestrictPublicBuckets should all be TRUE.

# 2. Check if your nodes can reach the IMDSv1 endpoint (Metadata spoofing check)
# Run this from INSIDE a pod:
curl -s http://169.254.169.254/latest/meta-data/iam/security-credentials/
# Success: Should return a 403 or hang if IMDSv2 is enforced (Module 3).

# 3. Check for "God Roles" in your K8s cluster
kubectl get clusterrolebindings -o json | jq '.items[] | select(.roleRef.name=="cluster-admin")'
# Success: Only your cluster management tool (e.g., ArgoCD) should be listed.

Production Gotchas

• Latency vs. Security: Deep Packet Inspection (DPI) in a WAF or a Service Mesh (Istio) adds latency. You must architect for this by using Fast-Path hooks like XDP (covered in eBPF Episode 07) where possible.
• The “Admin” Trap: Most breaches don’t happen because of a complex exploit; they happen because an administrator turned off MFA to “debug” a problem and never turned it back on. Architecture must enforce Non-Bypassable Controls.
• Audit Logs are a DDoS Vector: If you log every packet at the kernel level without sampling, you will crash your logging pipeline before the attacker even finishes their scan.

Framework Alignment

Key Takeaways

• The Perimeter is a myth: Assume the attacker is already in your network.
• Extended CIA: Authenticity and Non-Repudiation are the modern requirements for identity-based architecture.
• Defense-in-Depth: Functional redundancy means no single control failure leads to a total breach.
• Zero Trust: Move the trust boundary to the resource level, not the network level.

What’s Next

Foundational models are the “Why.” Module 2 covers the “How”—specifically, how to systematically identify threats using the STRIDE framework and calculate risk using DREAD.

Threat modeling is the single most important skill for a Security Architect. It’s how you stop vulnerabilities before they are even typed into an IDE.

Next: Module 2: Proactive Design — Threat Modeling with STRIDE

Get the full masterclass in your inbox → linuxcent.com/subscribe

The post Cybersecurity Architecture Principles: Beyond the Castle-and-Moat appeared first on Linuxcent.