Master STRIDE methodology (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege). Learn to systematically apply STRIDE to components, data flows, and trust boundaries in a system.
HardSystem Design
73 practiced
Create a detailed plan to embed STRIDE threat modeling into a secure SDLC at four gates: concept, architecture review, implementation (PRs), and pre-release. Include toolchain integrations (IDE plugins, PR hooks, architecture diagram storage), responsibilities, enforcement vs advisory gating criteria, automation, and training to minimize developer friction.
Sample Answer
**Overview / Goals**Embed STRIDE into four SDLC gates (Concept, Architecture Review, Implementation/PR, Pre-release) so threat modeling is lightweight, automated where possible, and developer-friendly. Balance enforcement for high-risk items and advisory guidance for low-risk.**1) Concept (Design Intent)**- Activities: High-level STRIDE checklist, initial asset and trust-boundary mapping.- Tools: Template-driven survey in product intake system (Jira/ServiceNow) + diagram stub creation in architecture diagram store (Diagrams.net + Confluence).- Responsibility: Product Manager + Lead Engineer create; Cybersecurity Engineer reviews.- Gate: Advisory pass required; enforcement if sensitive data or regulatory scope flagged (block until approved).**2) Architecture Review**- Activities: Full STRIDE walkthrough on architecture diagrams, privilege flows, and control matrix.- Tools: Architecture repo (versioned PNG/SVG/PlantUML) + automated threat extraction (ThreatDragon/ThreatModeler) that emits findings as ticketed items.- Responsibility: Security Architect leads; dev/infra SMEs attend.- Gate: Enforcement for S/ID/DO threats that lack mitigations; other findings generate backlog items.**3) Implementation (PRs)**- Activities: Map PR changes to previously identified threats; run static analysis, secret scanning, and SAST rules aligned to STRIDE categories.- Tools: IDE plugins (CodeQL, SonarLint), pre-commit hooks, CI PR checks that run SAST/IAST and correlate findings to existing model; PR templates require "Threats impacted" section.- Responsibility: Author tags threats; Security team triages failing checks.- Gate: Enforcement for critical SAST/secrets; advisory for low-confidence findings.**4) Pre-release**- Activities: Final STRIDE audit, attack-surface diff vs last release, runtime checks (fuzzing, dependency scanning).- Tools: Release pipeline gate in CI/CD (Jenkins/GitHub Actions) invoking automated model validator and producing sign-off report; store artifacts in architecture repository.- Responsibility: Release manager + Security sign-off.- Gate: Enforcement for unresolved critical STRIDE items.**Automation & Toolchain Integrations**- Sync architecture diagrams (PlantUML repo) with threat tooling to auto-generate STRIDE findings.- CI hooks convert tool output to PR comments and Jira tickets; use SSO for traceability.- IDE plugins suggest mitigations inline and link to playbooks.**Enforcement vs Advisory Criteria**- Define risk matrix: critical = PII/regulatory/exploitability high → enforcement; medium/low → advisory + SLA remediation.- Automatic false-positive suppression and feedback loop to tune rules.**Training & Developer Friction Minimization**- Embedded microlearning: 15-min STRIDE modules in IDE and LMS; example-based playbooks per threat.- Office hours + threat-modeling clinic weekly.- Templates, PR checklist, and automation reduce manual burden.- Metrics: time-to-remediate, false-positive rate, gating friction surveys; iterate.**Trade-offs**- Initial overhead vs long-term reduction in vulnerabilities. Start with high-risk projects and expand.
EasyTechnical
61 practiced
Given the following incidents, map each to the most appropriate STRIDE category and briefly justify your choice: (a) stolen API key used to impersonate a service, (b) attacker modifies a cached JSON response in an edge cache, (c) a user claims they never performed a funds transfer, (d) sensitive customer blob leaked due to misconfigured S3 ACL, (e) application becomes unresponsive during traffic spikes, (f) attacker escalates a service account to admin via a misconfigured role.
Sample Answer
**Answer (mapping + justification)**- (a) Stolen API key used to impersonate a service — **Spoofing (S)** Justification: stolen credentials allow an attacker to assume another service’s identity and authenticate as them.- (b) Attacker modifies a cached JSON response in an edge cache — **Tampering (T)** Justification: unauthorized modification of data in transit/storage breaks integrity of responses.- (c) A user claims they never performed a funds transfer — **Repudiation (R)** Justification: dispute about action/transaction indicates lack of non-repudiation/auditability.- (d) Sensitive customer blob leaked due to misconfigured S3 ACL — **Information Disclosure (I)** Justification: improper access controls exposed confidential data to unauthorized parties.- (e) Application becomes unresponsive during traffic spikes — **Denial of Service (D)** Justification: service availability degraded or unavailable under load, impacting users.- (f) Attacker escalates a service account to admin via a misconfigured role — **Elevation of Privilege (E)** Justification: attacker obtains higher privileges than intended through misconfiguration.As a cybersecurity engineer I’d follow up by identifying controls: strong credential management and rotation, integrity verification (signing), robust logging/immutable audit trails, least-privilege IAM, S3 ACL hardening and monitoring, and autoscaling + rate-limiting and WAF for availability.
HardTechnical
77 practiced
You are responsible for scaling threat modeling across an enterprise with hundreds of microservices. Propose a program that covers: standard threat-model templates, ownership model (who owns and reviews models), automation tooling, continuous discovery of new services, integration with architecture review boards, and metrics for adoption. Explain how to keep models current and avoid stale artifacts.
Sample Answer
**Overview (one-line)** Run a scalable, automated threat-modeling program using standard templates, clear ownership, continuous discovery, CI/CD automation, ARB gating, and adoption metrics — with processes to prevent stale artifacts.**Standard templates & artifacts**- Provide two templates: lightweight STRIDE-based service template (data flows, trust boundaries, assets, mitigations) and a deeper PASTA/attack-tree template for high-risk services.- Machine-readable canonical format (YAML/JSON) plus generated diagrams (C4/Diagrams-as-Code) to drive automation and scanning.**Ownership model**- Service Owner (Dev/Product): creates and updates model; ownership tracked in service metadata.- Security Engineering: reviews, certifies risk classification, and publishes required controls.- ARB / Risk Committee: approves high-risk models and exceptions.**Automation & tooling**- Integrate with Git/GitOps: models live in repos; PR templates enforce model updates.- Use tooling: IriusRisk/OWASP Threat Dragon + custom parsers for YAML models; generate tickets in Jira for missing controls.- CI checks: fail build if model missing for governed services or if critical threats unresolved.**Continuous discovery**- Source-of-truth integrations: Kubernetes API, service registry (Consul), API gateway, IaC (Terraform) to detect new services and auto-create model skeletons assigned to owners.**ARB integration**- ARB dashboard shows certified models; ARB gate enforced in CI/CD for production promotion for services above a risk threshold.**Metrics for adoption**- % services with current model, time-to-first-model, time-to-risk-mitigation, age distribution of models, number of critical findings triaged.- Track trending: reductions in recurring threat categories.**Keeping models current / avoiding staleness**- Model TTL (e.g., 90 days) and auto-reminders; require model update on any IaC/architecture change via pre-merge CI hooks.- Scheduled scans comparing deployed topology vs model; if delta detected, create owner ticket.- Automate evidence collection (control status) and surface stale flag in dashboards; escalate unaddressed staleness to engineering leadership.This program balances developer ownership, centralized security oversight, and automation to scale threat modeling across hundreds of microservices while keeping artifacts fresh and actionable.
EasyTechnical
64 practiced
Explain the STRIDE threat modeling framework. For each category — Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege — describe what it targets, provide one concrete example in a typical web application or microservice architecture, and propose a concise, practical mitigation for that example.
Sample Answer
**Brief intro**STRIDE is a threat-modeling taxonomy mapping threats to system properties: Spoofing identity, Tampering with data, Repudiation, Information disclosure, Denial of service, Elevation of privilege. Below each category: target, concrete web/microservice example, and a concise mitigation.**Spoofing — target:** Identity/authentication- Example: Attacker replays stolen JWT to call a microservice.- Mitigation: Short-lived JWTs + rotating signing keys and audience checks; require mTLS between services.**Tampering — target:** Integrity of data/code- Example: Malicious actor alters config in an unprotected etcd cluster.- Mitigation: Use RBAC, TLS for etcd, enable audit logs, sign configs (HMAC).**Repudiation — target:** Non-repudiation/auditability- Example: User deletes resources; no tamper-evident logs to prove actor.- Mitigation: Centralized immutable audit logs (append-only, signed), correlate with auth tokens.**Information Disclosure — target:** Confidentiality- Example: S3 bucket misconfigured public read exposing PII.- Mitigation: Enforce least-privilege IAM, automated infra-as-code checks, data encryption at rest and in transit.**Denial of Service — target:** Availability- Example: Excessive requests to an auth service exhaust CPU.- Mitigation: Rate-limiting, autoscaling with circuit breakers, WAF and upstream quotas.**Elevation of Privilege — target:** Authorization bypass- Example: Insecure direct object references allow user to access admin API.- Mitigation: Enforce authorization checks server-side, use ACLs/ABAC, automated authorization tests.Each mitigation should be integrated into CI/CD (policy as code), and validated with threat-model reviews and automated tests.
EasyTechnical
73 practiced
List and explain at least six concrete mitigations to reduce Tampering threats in a RESTful API ecosystem. Include measures at the transport/protocol level (TLS), request/response integrity, server-side validation, infrastructure configuration (WAF, CDN), and operational practices (code signing, integrity checks).
Sample Answer
**Answer (as a Cybersecurity Engineer)****1) Strong TLS / HSTS**- Enforce TLS 1.2+ with AEAD ciphers, HTTP Strict Transport Security, and Certificate Pinning where feasible to prevent on-path tampering of API traffic.**2) Message-level integrity (signatures)**- Sign requests/responses (e.g., HMAC-SHA256 with per-client keys or JSON Web Signatures) so recipients can verify payload integrity and authenticity.**3) Server-side validation & canonicalization**- Validate and canonicalize all inputs server-side (type checks, length, allowlists, schema validation), reject malformed or unexpected fields to prevent parameter tampering.**4) Replay protection & nonces**- Use timestamps, nonces, and short-lived tokens; track used nonces to prevent replayed signed requests.**5) Infrastructure controls (WAF, CDN, RBAC)**- Deploy a tuned WAF with OWASP rules and behavioral signatures, use CDN edge filtering and rate limiting, apply strict IAM and least privilege for service accounts.**6) Code signing & integrity checks**- Sign builds and use runtime integrity checks (binary signing, checksums, container image signing) plus SBOMs to detect tampered deployments.**7) Logging, monitoring, and mitigation**- Immutable logs, alerting for signature failures/anomalous modifications, automated blocking, and incident playbooks for tampering events.Each control layers defense—combine transport, application, infra, and operational measures for robust tampering mitigation.
Unlock Full Question Bank
Get access to hundreds of STRIDE Threat Modeling Framework interview questions and detailed answers.
