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.

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.

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

graph LR subgraph Internet["🌐 Internet"] Browser["Browser / User"] end subgraph DMZ["🛡️ DMZ"] WAF["WAF / CDN"] --> WebServer["Web Server"] --> APIGateway["API Gateway"] end subgraph App["⚙️ Application"] Auth["Auth Svc"] Order["Order Svc"] Payment["Payment Svc"] end subgraph Data["💾 Data"] UserDB[("User DB")] OrderDB[("Order DB")] TokenDB[("Token DB")] end Browser -->|"HTTPS"| WAF APIGateway --> Auth & Order & Payment Auth --> UserDB Order --> OrderDB Payment --> TokenDB

DFD Elements

  • External Entity - Outside the system boundary
  • Process - Transforms data
  • Data Store - Persists data
  • Data Flow - Movement of data
  • - - Trust Boundary - Security perimeter

DFD Levels

  • Level 0: Context diagram - System as single process
  • Level 1: Major subsystems and data flows
  • Level 2: Detailed view of each subsystem
  • Level 3+: Granular component analysis

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. ROI = $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

FAIR-based quantitative risk analysis platform

Commercial • FAIR certified

draw.io / diagrams.net

Free diagramming with DFD shapes, trust boundary templates

Free • Browser-based

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?

📋 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)