Last reviewed 8 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.

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.