Last reviewed 11 min read

Section 02

Architecture Risk Analysis

Architecture Risk Analysis (ARA) is a systematic approach to identifying, analyzing, and prioritizing security risks in software and system architectures before they become vulnerabilities.

Page 01 produced a threat model: the assets, trust boundaries, and a STRIDE threat register for a target system. This page turns that model into ranked, owned risk — scoring each threat with likelihood and impact, grounding the high-priority ones in concrete abuse cases, and capturing the outcome as a risk register and design-review checklist. Where page 01 asks "what can go wrong?", this page asks "how likely, how bad, and who owns the fix?".

Attack Surface Analysis

The attack surface is the sum of all points where an attacker can try to enter or extract data. Reducing the attack surface is a fundamental security principle.

Network Attack Surface

  • • Open ports and services
  • • API endpoints
  • • Network protocols
  • • Load balancers
  • • DNS configuration

Software Attack Surface

  • • User input fields
  • • File upload mechanisms
  • • Authentication endpoints
  • • Third-party libraries
  • • Configuration files

Physical Attack Surface

  • • Physical access points
  • • USB ports
  • • IoT devices
  • • Removable media
  • • Physical security controls

Attack Surface Reduction Techniques

1. Minimize Entry Points

Close unnecessary ports, disable unused services, remove debug endpoints in production.

2. Reduce Code Complexity

Remove dead code, minimize third-party dependencies, use proven libraries.

3. Enforce Least Privilege

Services run with minimum permissions, users have only necessary access rights.

4. Segment Networks

Isolate sensitive systems, use firewalls between zones, implement micro-segmentation.

Trust Boundaries

Trust boundaries are lines in an architecture where the level of trust changes. Data crossing trust boundaries must be validated, sanitized, and authenticated.

Common Trust Boundaries

External → Internal
  • • Internet → DMZ
  • • User browser → Web server
  • • Mobile app → API gateway
  • • Partner systems → Integration layer
Internal Boundaries
  • • DMZ → Internal network
  • • Application tier → Database tier
  • • User zone → Admin zone
  • • Container → Host system

Trust Boundary Rule

Never trust data that crosses a trust boundary. Always validate, sanitize, and authorize before processing. This includes data from your own frontend—treat it as untrusted.

Abuse Cases

Abuse cases describe how a specific actor pursues a hostile goal through the architecture. They keep risk analysis honest: each one names the path taken and the control that stops it, so the mitigation is testable rather than aspirational.

AC-01 · Forged token on the banking API

  • Actor: external attacker with a captured or self-minted bearer token.
  • Goal: read another customer's balance and move money.
  • Path: call GET /api/v1/accounts/{id} and POST /api/v1/transfers at the API gateway, relying on the service trusting the token's sub claim without binding it to the requested account.
  • Control that stops it: RS256 signature verification with a short TTL, plus object-level authorization that binds the token subject to the resource before any query, backed by immutable audit logging.

AC-02 · Cross-account export via IDOR

  • Actor: authenticated low-privilege customer.
  • Goal: download another customer's transaction history.
  • Path: change the account ID in /api/v1/accounts/{accountId}/transactions from their own to a victim's, exploiting authorization that is enforced at the gateway route but not per object.
  • Control that stops it: server-side per-object authorization on every query (Complete Mediation), a 404 on mismatch rather than a 403, and monitoring for sequential-ID enumeration.

Risk Assessment Methods

Quantitative vs Qualitative

Quantitative Analysis

Uses numerical values and formulas to calculate risk.

  • • ALE = SLE × ARO
  • • Annualized Loss Expectancy
  • • Single Loss Expectancy
  • • Annual Rate of Occurrence

Best for: Business justification, ROI calculations

Qualitative Analysis

Uses ratings and categories to assess risk.

  • • High/Medium/Low ratings
  • • Risk matrices
  • • Expert judgment
  • • DREAD scoring

Best for: Quick assessments, prioritization

Risk Matrix

Low Impact Medium Impact High Impact
High Likelihood Medium High Critical
Medium Likelihood Low Medium High
Low Likelihood Low Low Medium

Data Flow Diagrams (DFDs)

DFDs are essential for architecture risk analysis. They visualize how data moves through a system and help identify where security controls are needed.

Level 1 DFD — E-Commerce Application

A Level 1 data flow for an e-commerce application: the browser crosses the DMZ web tier and API gateway to reach the auth, order and payment services, each writing to its own data store.

Scroll sideways to see the whole diagram

View full size

The element types and decomposition levels that make up a DFD are primed on page 01 in DFD Elements and Levels; this page assumes that vocabulary and uses DFDs as the input to risk scoring.

FAIR Quantitative Risk Analysis

Factor Analysis of Information Risk (FAIR) provides a quantitative model for understanding, analyzing, and measuring risk in financial terms — essential for executive communication.

FAIR Calculation — SQL Injection on Customer Database

Loss Event Frequency (LEF)
  • Threat Event Frequency: 12/year (monthly attempt)
  • Vulnerability (probability): 0.15 (15% chance of success)
  • LEF = 12 × 0.15 = 1.8 events/year
Loss Magnitude (LM)
  • Productivity loss: $50,000
  • Response cost: $200,000
  • Fines/legal: $500,000
  • Reputation: $250,000
  • LM = $1,000,000

Annualized Loss Expectancy (ALE) = LEF × LM = 1.8 × $1,000,000 = $1,800,000/year

If a WAF + SAST tool costs $100K/year and reduces vulnerability to 0.02 → New ALE = $240K/year. Net annual risk reduction = $1.46M/year.

Risk Analysis Tools

OWASP Threat Dragon

Open-source DFD editor with STRIDE threat generation

Free • Cross-platform

IriusRisk

Automated threat modeling with questionnaire-driven analysis

Commercial • Enterprise

RiskLens, a SAFE Company

FAIR-based quantitative risk analysis platform (part of Safe Security)

Commercial • FAIR certified

draw.io / diagrams.net

Free diagramming with DFD shapes, trust boundary templates

Free • Browser-based

Risk Register / Findings

The threat register from page 01 becomes a risk register once every finding carries a score from the matrix above, a treatment decision, and a named owner. This is the artifact a design review signs off and an engineering team tracks to closure.

ID Asset Threat Likelihood Impact Risk Rating Treatment Owner
RR-01 API Gateway Forged JWT bypasses authentication Medium High High Mitigate — RS256 verification, short TTL, token revocation list Platform Security
RR-02 Customer Database Missing object-level authorization (IDOR) Medium High High Mitigate — per-object authorization bound to the token subject App Security
RR-03 Auth Service Credential stuffing at customer login High Medium High Mitigate — MFA, rate limiting, breached-password checks IAM Team
RR-04 Payment Integration Replay of a fund-transfer request Low High Medium Mitigate — idempotency keys and request signing Payments Team
RR-05 Audit Log Pipeline Tampering with or deletion of transaction logs Low Medium Low Mitigate — append-only storage and integrity monitoring Cloud Ops
RR-06 Customer PII Store Error responses leak internal paths and schema Medium Medium Medium Mitigate — generic errors and log redaction App Security
RR-07 Public Edge Misconfiguration exposes an unauthenticated admin route High High Critical Mitigate — deny-by-default ingress and admin-plane isolation Platform Security

Architecture Review Checklist

Authentication & Identity

  • ☐ How are users authenticated?
  • ☐ How are service-to-service calls authenticated?
  • ☐ Where are credentials stored?
  • ☐ Is MFA implemented for sensitive operations?

Authorization & Access Control

  • ☐ What authorization model is used (RBAC, ABAC, etc.)?
  • ☐ Where are authorization decisions made?
  • ☐ How is privilege escalation prevented?
  • ☐ Are there admin backdoors?

Data Protection

  • ☐ Is sensitive data encrypted at rest?
  • ☐ Is data encrypted in transit (TLS 1.2+)?
  • ☐ How are encryption keys managed?
  • ☐ What data classification levels exist?

Logging & Monitoring

  • ☐ What security events are logged?
  • ☐ Are logs protected from tampering?
  • ☐ Is there real-time alerting for security events?
  • ☐ How long are logs retained?

This checklist is deliberately a starting point: the worked, end-to-end template lives on page 10, Real-World Case Studies, so that example is maintained in one place rather than duplicated here.

Framework Alignment

NIST CSF: ID.RA (Risk Assessment), ID.AM (Asset Management) | ISO 27002: A.5.7 (Threat Intelligence), A.8.8 (Vulnerability Management) | CIS Controls: CIS 1, 2 (Asset Inventory), CIS 7 (Vuln Management) | NIST 800-53: RA-3 (Risk Assessment), RA-5 (Vulnerability Monitoring)

Architecture Risk Analysis Labs

Turn an architecture into ranked, owned risk using the frameworks and artifacts covered above.

Score and Triage the Threat Register Custom Lab medium
Take the STRIDE threat register from page 01 (or build a small one for a service you own)Rate every threat Low, Medium, or High for likelihood and impact using the risk matrixQuantify the three highest risks with FAIR: estimate loss event frequency and loss magnitude to get an ALEAssign a treatment (mitigate, transfer, or accept) and a named owner to each rowWrite two abuse cases for the top risk, each naming the control that stops it
Attack Surface and Trust Boundary Review Custom Lab easy
List every entry point for a system you own: open ports, API endpoints, upload paths, and third-party integrationsClassify each as network, software, or physical attack surfaceDraw the trust boundaries and mark where data changes trust levelFor each boundary, write what validates, sanitizes, and authorizes the crossing dataIdentify three entry points you can close or remove and note the change
Need help setting up? Check our Lab Setup Guide →

Go deeper → Learn FAIR quantification and Monte Carlo simulation for risk scoring in the Risk Quantification section, or read the source frameworks: NIST SP 800-30, ISO/IEC 27005, and OCTAVE.

Evidence to Capture

A risk finding survives review only when it points at an artefact, not at a feeling about the diagram.

Boundary crossing: The DFD boundary, the two elements it separates, and the inventory entry for the control that inspects the crossing. If no inventory entry exists, that absence is the finding.

Surface row: One row per entry point: type (network, software, physical), exposure (internet, partner, internal), protocol, owner, and the authentication it requires.

Abuse case: An identifier such as AC-01, the precondition, the step-by-step path, and the control that stops it. An abuse case with no stopping control is an unmitigated path.

Risk register row: Likelihood and impact with the source of each estimate, the treatment (mitigate, transfer, accept), the named owner, and the review date.

FAIR inputs: A range for loss magnitude and a frequency estimate with its source. A single-point figure presented as quantified risk is not a FAIR output.

Likely False Positives

Entries that look like unowned risk but are controlled by something the DFD does not draw.

  • Control at the platform layer: A boundary with no application control is frequently covered by the network policy, the service mesh, or the cloud IAM policy. Read the policy, not the diagram.
  • Reachable but not traversable: An exposed port behind mutual TLS or behind an authenticated gateway is an accepted surface, not an open one. The peer-authentication config rules it out.
  • Duplicate scoring of one weakness: The same defect on two replicas of one component is one risk with two instances. Merging changes the register total, not the exposure.
  • Uncalibrated severity: A high score produced by a rubric applied to one row and not the others is a consistency problem. Re-score the sample before escalating.
  • Out-of-scope feature misuse: An abuse case built on a capability the deployment disables has no path. The feature flag or build configuration is the evidence.

Review Checklist

Surface

  • ☐ Enumerate entry points from the deployed configuration and reconcile them against the inventory, not the other way round.
  • ☐ Check each entry point has an authentication requirement stated, including internal-only ones.
  • ☐ Confirm removed or decommissioned entry points are closed at the edge, not only deleted from the document.
  • ☐ Verify third-party integrations are listed with their trust direction.

Boundaries

  • ☐ Walk each boundary and read the control that inspects it in the actual policy or code.
  • ☐ Check that a boundary reserved for a compensating control has that control on every path through it.
  • ☐ Confirm the boundary matches the trust level change: a data flow between two same-trust elements has no boundary to defend.
  • ☐ Check logging exists at the boundary; a control that cannot be observed is not verifiable.

Risk record

  • ☐ Confirm every row has an owner and a treatment, and that accepted rows carry a review date.
  • ☐ Check the likelihood and impact inputs name their source.
  • ☐ Look for rows that describe a control gap rather than a risk, and rewrite or close them.
  • ☐ Confirm the register is re-derived after an architecture change, not appended to.

Remediation

Where the fix belongs

Structural

  • • Put the control at the boundary that the DFD shows. A validation added in the calling service does not protect the second caller of the same resource.
  • • Reduce the surface by removing the entry point rather than guarding it, where the function is unused.
  • • Make the register a build artefact of the model, so a new boundary without a control appears as an open row automatically.

Compensating

  • • Where a boundary control cannot be added yet, record the compensating detection rule and the date it is validated against a real attempt.
  • • For accepted risk, name the acceptance owner and the condition that would reopen it.