See the Attack Surface – Threat Modeling & Control Mapping
Duration: ~20 minutes
Overview
You will turn a fuzzy “we should be secure” notion into a concise, living threat model and translate it directly into an ordered mitigation backlog that maps to concrete OpenShift / Red Hat controls.
Sketch a compact threat model for an OpenShift app, map higher-value threats to platform controls, and leave with a short prioritized backlog.
Why it matters
Designing security without a threat model is like installing locks, cameras, and safes randomly in a new office tower—expensive and still full of blind spots. A compact model acts as the floor plan: you know where valuables sit, which doors are public, and which hallways connect sensitive rooms. Business outcome: money and time focus on the riskiest failure paths first; audit narratives become “why” stories, not scattered spreadsheets; incident responders already know likely pivot routes. Most high‑impact improvements are ordinary: remove a wildcard Role, add default‑deny NetworkPolicy, enforce image signatures. Ordinary, but chosen with intent.
What does it solve
Without modeling, teams drift into: * Reactive, ticket‑whack hardening (“fix whatever the scanner yells at today”) * Lateral movement oversight (frontend quietly reaches database pods) * Everything labeled “critical,” so nothing truly is * Re‑litigated design debates (no shared artifact of prior reasoning)
With a model: * Shared vocabulary: assets, boundaries, flows, threats * Traceability: every control defends an identified path * Faster audits: reviewers see risk rationale, not guesswork * Focused backlog: sequence of high leverage, low regret steps
Your Mission
Map trust boundaries to concrete OpenShift controls. Click each step only if you need a hint.
Create visual-aid namespaces for the trust boundaries you will map
oc new-project app-frontend
oc new-project app-backend
oc new-project app-dbList assets
List assets: code, images, secrets, database, CI system, cluster API.
Sketch a textual data flow
Write a textual data flow (sample below) and adjust it to your reality—frontends, APIs, databases, CI, and the registry.
Mark trust boundaries
Mark trust boundaries: Internet ingress, CI → cluster, app → db, registry ↔ kubelet.
Apply STRIDE sampling
Apply STRIDE sampling to 5–10 flows (avoid the exhaustiveness trap).
Build a Threat → Control table
Build a Threat → Control table (start with a short excerpt; extend locally).
Score and sort
Qualitatively score (High/Med/Low impact and likelihood) plus effort (S/M/L); sort by leverage.
Turn findings into backlog tickets
Turn the top ranked 5–7 items into backlog tickets with acceptance criteria.
Commit and schedule review
Commit the artifact (threat-model-app.md) and schedule a quarterly review.
Debrief
Threat modeling turns controls into a blueprint: you map data flows and privileges to concrete OpenShift defenses instead of stacking tools at random.
What breaks without this:
-
Defenses without a model → locked side doors and an open front door
-
Stale models → architecture drift leaves new paths unguarded
Controls that matter: map registry, service-to-service, CI→cluster, SA tokens, syscalls, and privileged RBAC to scan/sign, NetworkPolicy, secrets/RBAC, admission, SPO, and custom roles; revisit when architecture changes.
Quick facts: start at tier (app/platform) detail enough to prioritize; re-run when you add a trust boundary or on a fixed cadence.
