STRIDE · DREAD · Attack Trees · DFDs · Zero Trust · Security Architecture · OAuth 2.0
Study with Practice Tests →Domain 3 (~14%) of the CSSLP CBK. Security architecture and threat modeling decisions made during design phase are the most cost-effective — far cheaper to address than post-deployment fixes.
| Domain | Weight | Key Topics |
|---|---|---|
| 1. Secure Software Concepts | 10% | CIA, AAA, security principles, risk |
| 2. Secure Software Requirements | 14% | Requirements, privacy, compliance, abuse cases |
| 3. Secure Software Design | 14% | Threat modeling, STRIDE, security architecture, auth design |
| 4. Secure Software Implementation | 14% | Secure coding, injection, crypto, code review |
| 5. Secure Software Testing | 14% | SAST, DAST, IAST, fuzzing, pen testing |
| 6. Secure Software Lifecycle Management | 11% | DevSecOps, SDLC integration, metrics |
| 7. Secure Software Deployment & Ops | 11% | Deployment, configuration, patch management |
| 8. Secure Software Supply Chain | 12% | Third-party risk, SBOM, CI/CD security |
6 threat categories: Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege. Each maps to a security property it violates. Applied to every component and data flow in the system.
Rates each identified threat on 5 dimensions (1–3 each, max 15): Damage, Reproducibility, Exploitability, Affected Users, Discoverability. Higher score = higher priority threat to mitigate.
Root = attacker's goal. Child nodes = attack methods (AND = all must succeed; OR = any one suffices). Used to enumerate all paths to a goal and identify highest-leverage defensive chokepoints.
DFDs decompose the system into: external entities, processes, data stores, and data flows. Dashed lines show trust boundaries — every flow crossing a boundary is a threat modeling candidate.
"Never trust, always verify." No implicit trust from network location. Identity-based access, microsegmentation, continuous verification, assume breach posture. Replaces perimeter-based "castle and moat" model.
OAuth 2.0: authorization framework with multiple grant types (Authorization Code + PKCE preferred for users; Client Credentials for services). JWT: Header.Payload.Signature — always validate algorithm, reject alg=none, set expiry.
Threat modeling is a DESIGN phase activity — not implementation. The output of threat modeling feeds back into security requirements and design decisions. Update threat models when architecture changes significantly.
Spoofing=Authentication, Tampering=Integrity, Repudiation=Non-repudiation, Info Disclosure=Confidentiality, DoS=Availability, EoP=Authorization. Know these mappings cold — exam uses them frequently.
Three common exam traps: alg=none attack (always reject), weak HMAC secret (use asymmetric RS256 for production), missing exp claim (tokens never expire). Store in HttpOnly cookies, not localStorage.
Threat modeling is a structured process to identify, rate, and mitigate security threats during the design phase. STRIDE is the most common framework applied in software threat modeling.
| Threat | Violates | Example | Countermeasures |
|---|---|---|---|
| Spoofing | Authentication | Attacker impersonates a legitimate user or service | MFA, mutual TLS, digital signatures, Kerberos |
| Tampering | Integrity | Attacker modifies data in transit or at rest | HMAC, TLS, digital signatures, input validation |
| Repudiation | Non-repudiation | User denies having performed an action | Tamper-evident audit logs, digital signatures, NTP-synced timestamps |
| Information Disclosure | Confidentiality | Unauthorized exposure of sensitive data | Encryption at rest/transit, access controls, data masking |
| Denial of Service | Availability | Overwhelming resources to prevent legitimate use | Rate limiting, WAF, load balancing, circuit breakers |
| Elevation of Privilege | Authorization | Gaining higher rights than granted (e.g., user → admin) | Least privilege, RBAC, input validation, sandboxing |
Create a DFD of the application. Identify: external entities (users, third-party services), processes (app components), data stores (databases, files), and data flows between them. Draw trust boundaries around components with different security levels.
Apply STRIDE to each element and data flow in the DFD. Ask: "How could an attacker exploit this component or flow?" Focus especially on data flows that cross trust boundaries — these are the highest-risk points.
Score each identified threat using DREAD (1–3 per dimension, max 15) or CVSS. Prioritize mitigation by risk score. High-score threats with low mitigation cost should be addressed first.
For each threat, define a specific security control: accept (document residual risk), mitigate (add control), transfer (contract/insurance), or avoid (remove the risky feature). Document the decision.
Verify that defined countermeasures actually address the identified threats. Update threat model when architecture changes. The threat model is a living document — not a one-time activity.
Damage · Reproducibility · Exploitability · Affected Users · Discoverability
Each 1–3, max total = 15. Use to rank threats by severity and prioritize remediation roadmap.
| Element | Symbol | Description | Threat Modeling Focus |
|---|---|---|---|
| External Entity | Rectangle | Outside system boundary (user, external service, browser) | Source of untrusted input — apply Spoofing and Tampering |
| Process | Circle/Oval | Transforms or acts on data (application component, API) | All STRIDE threats apply — EoP, DoS especially relevant |
| Data Store | Parallel lines | Where data is persisted (DB, file, cache, secret store) | Information Disclosure, Tampering, Repudiation |
| Data Flow | Arrow | Data moving between elements | Tampering, Information Disclosure — especially cross-boundary flows |
| Trust Boundary | Dashed line | Where security level changes (internet→DMZ→internal) | Every flow crossing boundary must be validated and authenticated |
Attacker must succeed at ALL child sub-goals to achieve the parent goal. AND nodes = harder to exploit (multiple conditions). Focus defenses here — blocking any one child blocks the entire path.
Attacker needs to succeed at only ONE child sub-goal. OR nodes = more attack paths (easier to find a way in). Defenses must cover ALL branches, not just one.
OR: Phish user | Brute-force password | Exploit password reset
Each is an independent path to the goal. Defenses must address all three: MFA, lockout, secure reset token.
Security architecture translates security requirements and threat model outputs into concrete design decisions that are embedded into the system structure.
Multiple overlapping security layers — no single point of failure. Layers: Network (firewall, IDS) → Host (EDR, patching) → Application (WAF, input validation) → Data (encryption, access control). Attacker must bypass all layers.
Three tenets: Verify identity explicitly (MFA, device health). Use least privilege access (just-in-time, just-enough access). Assume breach (microsegmentation, encrypt east-west traffic, full telemetry). No implicit trust from network location.
Product ships with the most secure configuration: no default passwords, minimal open ports, TLS enforced, logging enabled. Users must explicitly opt out of security — not opt in. Reduces risk from misconfiguration at deployment.
Minimize shared resources between users and processes. Example: separate database schemas or connections per tenant prevents data leakage. Shared caches, temp files, and session stores can all be vectors for cross-user data exposure.
On failure, the system defaults to denying access — not granting it. Circuit breaker pattern: if downstream service is unavailable, return an error rather than partial/unsafe data. Firewall default deny on rule engine failure.
Divide the network into small zones with tightly controlled east-west traffic between them. Limits blast radius of a breach — attacker cannot freely move laterally. Enforced via software-defined networking (SDN) or host-based firewalls.
| Concern | Design Pattern | Example |
|---|---|---|
| Service-to-service auth | Mutual TLS (mTLS), JWT with service identity | Each service has its own certificate; mTLS enforced on all internal calls |
| API access control | API Gateway: centralized auth, rate limiting, routing | Kong, AWS API Gateway validates tokens before routing to services |
| Secrets management | Never hardcode; use dedicated secrets manager | HashiCorp Vault, AWS Secrets Manager, injected via environment at runtime |
| Container security | Minimal images, non-root user, read-only FS | Alpine base image, USER nonroot, resource limits, no privileged mode |
| Logging & observability | Structured logs with correlation IDs, centralized SIEM | Every request tagged with trace ID; logs shipped to ELK or Splunk |
| Data isolation | Separate DB per service, no direct cross-service DB access | Each microservice owns its schema; cross-service reads via API only |
| Principle | Architectural Decision | Example |
|---|---|---|
| Least Privilege | Service accounts scoped to exact needs | Payment service can only read/write payments table — no other DB access |
| Complete Mediation | Re-validate permissions on every API call | Session token + RBAC check on every request, no cached decisions |
| Separation of Duties | Deploy pipeline requires multiple approvals | Developer → PR Review → Security Gate → Ops Approval → Deploy |
| Defense in Depth | WAF + input validation + DB constraints | WAF blocks obvious attacks; app validates semantics; DB enforces types and constraints |
| Psychological Acceptability | SSO reduces friction while maintaining security | One login for all internal tools; MFA prompted only for sensitive actions |
Authentication and authorization design decisions made early in the SDLC have outsized security impact. Choosing the right protocols and avoiding known pitfalls is critical for the CSSLP exam.
| Grant Type | Use Case | Security Notes | Status |
|---|---|---|---|
| Authorization Code + PKCE | Web apps, mobile apps with user login | Most secure for user flows; PKCE prevents code interception in public clients | ✅ Recommended |
| Client Credentials | Machine-to-machine (no user) | Client ID + secret; use short-lived tokens; rotate secrets regularly | ✅ Recommended |
| Device Code | Limited-input devices (TV, CLI) | User completes auth on separate device; polling for token | ✅ Situational |
| Implicit | Originally for SPAs | Token in URL fragment — logged in browser history, referer headers | ❌ Deprecated |
| Resource Owner Password | Trusted first-party apps only | Password sent to authorization server — bypasses consent; avoid | ⚠️ Avoid |
Identity layer on top of OAuth 2.0. Adds ID Token (JWT) containing user claims (sub, email, name). REST/JSON based — modern and mobile-friendly. Discovery endpoint: /.well-known/openid-configuration. Use for new web and mobile applications.
XML-based federated identity protocol. Identity Provider (IdP) issues XML assertions to Service Provider (SP). Enterprise SSO standard — widely deployed in legacy enterprise. More verbose but deeply integrated in corporate environments (Okta, ADFS, Ping).
Always: validate alg (reject none), validate iss (issuer), aud (audience), exp (expiry). Use RS256 (asymmetric) over HS256 (shared secret) for distributed systems. Store in HttpOnly Secure cookies — not localStorage (XSS vulnerable).
| Principle | Why It Matters | Implementation |
|---|---|---|
| Input validation on all inputs | Prevents injection, overflow, logic bypass | Type, length, format, range checks server-side; allowlist approach |
| HTTPS only | Tokens and data exposed in plaintext over HTTP | HSTS header, redirect HTTP → HTTPS, TLS 1.2 minimum |
| Rate limiting | Prevents brute force, credential stuffing, DoS | Per-IP and per-user limits; exponential backoff on failures |
| Principle of Least Disclosure | Reduces information leakage | Return only necessary fields; no debug info in responses |
| CORS allowlist | Wildcard * with credentials not allowed by browsers | Explicit Access-Control-Allow-Origin list; Vary header |
| Versioning | Deprecate insecure endpoints cleanly | /api/v1/ routing; sunset headers for deprecated versions |
API endpoint uses user-supplied ID without verifying the user has access to that resource. GET /api/orders/12345 — does this user own order 12345? Fix: object-level authorization check on every request. Also called Broken Object Level Authorization (BOLA) in OWASP API Top 10.
Framework auto-binds all user-supplied JSON fields to a model object. Attacker adds "isAdmin": true. Fix: use explicit allowlist (DTO pattern) — only bind fields that should be user-controllable. Common in Rails, Laravel, Node.js frameworks.
Attacker modifies JWT header to "alg": "none", removes the signature, and the server accepts it. Fix: always validate the algorithm explicitly — reject any token where alg is not in your approved list. Never trust the algorithm from the token header without validation.
10 questions covering STRIDE, threat modeling, security architecture, and authentication design.
Six sticky anchors for the highest-yield Design & Threat Modeling concepts.
Click any card to flip it. 8 high-yield concept cards for rapid review.
👆 Click a card to reveal the answer
Select a topic for targeted exam-day guidance.