2.5 — Architecture Security Assessment

1. Distinction from Threat Modeling

Architecture security assessment and threat modeling are related but distinct activities. Confusing them leads to either duplicated effort or critical gaps.

Threat Modeling (Module 2.3)

• Focus: Identifying potential threats against a system design
• Timing: Primarily during design phase, before implementation
• Input: Design documents, data flow diagrams, system descriptions
• Output: Threat catalog, mitigation plan, risk ratings
• Question: “What could go wrong?”
• Methodology: STRIDE, PASTA, Attack Trees

Architecture Security Assessment (This Module)

• Focus: Evaluating an existing architecture for security weaknesses, misconfigurations, and deviations from security standards
• Timing: After architecture is defined or implemented — during review, before major releases, periodically
• Input: Deployed architecture, configuration, network topology, actual data flows, security requirements
• Output: Assessment report, deviation analysis, remediation plan, severity ratings
• Question: “Is what we built actually secure?”
• Methodology: Structured review against security requirements, design principles, and known good patterns

When They Overlap

Threat modeling and architecture assessment should feed each other:

• Threat model findings inform what the architecture assessment should look for
• Architecture assessment findings reveal threats that the threat model missed
• Both update the same risk register and mitigation tracking

When to Use Which

Situation	Use Threat Modeling	Use Architecture Assessment
Designing a new system	Primary activity	Not applicable (nothing to assess)
Adding a major feature	Yes, for the new feature	Yes, assess impact on existing architecture
Pre-release review	Verify threat model is current	Primary activity — assess the built system
Post-incident	Update threat model with new threat data	Assess whether architecture contributed to the incident
Annual review	Update threat model	Primary activity — assess architectural drift
New integration with external system	Yes, model threats from integration	Assess existing architecture’s readiness for integration
Compliance audit preparation	Verify threat model documentation	Primary activity — demonstrate architectural controls

---

2. OWASP SAMM — Architecture Assessment Practice

SAMM Overview

The OWASP Software Assurance Maturity Model (SAMM) is a framework for measuring and improving software security practices. It defines five business functions, each with three security practices.

Architecture Assessment falls under the Verification business function.

Verification Business Function

The SAMM Verification function contains three practices:

1. Architecture Assessment: Review software architecture for security flaws
2. Requirements-driven Testing: Test against security requirements
3. Security Testing: General security testing (SAST, DAST, penetration testing)

Architecture Assessment Maturity Levels

Maturity Level 1 — Ad Hoc:

• Architecture reviews happen informally, driven by individual initiative
• No standard process or checklist
• Results are not consistently documented
• Coverage is incomplete and inconsistent

Maturity Level 2 — Structured:

• Defined architecture review process with checklists
• Reviews triggered by defined events (major releases, new integrations)
• Findings documented and tracked
• Trained reviewers perform assessments
• Coverage of critical applications

Maturity Level 3 — Systematic:

• Architecture reviews are mandatory and integrated into SDLC gates
• Automated tools supplement manual review
• Results feed into risk management and security metrics
• Continuous improvement based on findings trends
• Full portfolio coverage with risk-based prioritization

Progression Path

Most organizations should target Maturity Level 2 within the first year and Level 3 within two years. Level 1 is not a target — it is the “we haven’t started yet” baseline.

---

3. BSIMM — Architecture Analysis

BSIMM Overview

The Building Security In Maturity Model (BSIMM) is a descriptive (not prescriptive) model based on observed practices across hundreds of organizations. It reports what organizations actually do, providing a benchmark.

SSDL Touchpoints — Architecture Analysis

BSIMM’s Architecture Analysis (AA) activities progress through three levels:

AA Level 1:

• AA1.1: Perform security feature review — review the security mechanisms in the architecture (authentication, authorization, cryptography, logging)
• AA1.2: Perform design review for high-risk applications — structured review targeting the most critical applications

AA Level 2:

• AA2.1: Define and use an architecture assessment process — standardized process applied consistently
• AA2.2: Require architecture assessment for all high-risk applications — mandatory gate, not optional review

AA Level 3:

• AA3.1: Have software architects lead design review — security-aware architects (not just security team) conduct reviews
• AA3.2: Drive analysis results into architecture patterns — findings improve reusable architecture patterns

Key BSIMM Insight

The most mature organizations embed architecture analysis into the development team’s workflow rather than treating it as an external security review. When architects understand security, assessment is continuous, not periodic.

---

4. When to Conduct Architecture Assessments

Mandatory Triggers

Trigger	Scope	Rationale
Major release	Full architecture	Comprehensive pre-release security validation
Significant architectural change	Changed components and interfaces	New data flows, services, or trust boundaries may introduce vulnerabilities
New external integration	Integration points and data flows	Trust boundary crossing with external system
Post-security-incident	Affected subsystem and related components	Determine whether architecture contributed to the incident
Compliance audit preparation	Full portfolio or targeted systems	Demonstrate architectural security controls

Recommended Triggers

Trigger	Scope	Rationale
Annual review	Full architecture of critical systems	Detect architectural drift, apply new threat intelligence
Technology migration	Migrating components	New technology may have different security characteristics
Team change	Systems owned by new team	New team may not understand security architecture decisions
Dependency major version upgrade	Components using the dependency	Major versions may change security behavior

---

5. Assessment Methodology — Ten Steps

Step 1: Document Current Architecture

Before you can assess an architecture, you must understand it. Document:

• Component inventory: All services, databases, message queues, caches, CDNs, API gateways, load balancers, WAFs
• Data flow diagrams: How data moves between components, including protocols, authentication mechanisms, and encryption
• Trust boundaries: Where trust levels change (internet → DMZ → application tier → database tier, user → admin, service A → service B)
• Deployment topology: Where components run (cloud provider, region, VPC, subnet, container orchestrator, server)
• External dependencies: Third-party APIs, SaaS services, DNS providers, certificate authorities, identity providers
• Technology stack: Frameworks, languages, operating systems, container images, infrastructure-as-code tools

Common problem: The documented architecture does not match the deployed architecture. Architecture drift is real. Verify documentation against actual deployment (infrastructure-as-code scanning, network scanning, service discovery).

Step 2: Review Against Security Requirements

Map the architecture to the security requirements defined in Module 2.1:

• For each security requirement, identify the architectural component(s) that implement it
• Verify implementation is present and correctly positioned
• Identify requirements with no corresponding architectural control
• Identify architectural controls with no corresponding requirement (may indicate unnecessary complexity or may reveal missing requirements)

Step 3: Identify Deviations from Secure Design Principles

Review the architecture against the secure design principles from Module 2.2:

• Least privilege: Are services running with minimum necessary permissions? Are database connections appropriately scoped? Are API tokens narrowly granted?
• Defense in depth: Are there multiple layers of security controls? If one layer fails, what prevents compromise?
• Fail secure: What happens when each component fails? Does the system default to deny or allow?
• Complete mediation: Is every request authenticated and authorized? Are there any bypass paths?
• Attack surface: What is the total exposed surface? Can any of it be reduced?

Step 4: Assess Attack Surface and Exposure

Systematically catalog the attack surface:

• External attack surface: Internet-facing endpoints, DNS records, exposed services, public cloud resources
• Internal attack surface: Inter-service communication, internal APIs, administrative interfaces
• Data attack surface: Databases, file storage, caches, message queues — how is data accessed and protected?
• Supply chain attack surface: Third-party dependencies, container base images, CI/CD pipeline components
• Human attack surface: Administrative access, developer access, support access — credential management and access controls

For each element, assess:

• Is it necessary? (Can it be removed?)
• Is it authenticated? (Who can access it?)
• Is it monitored? (Would we detect abuse?)
• Is it hardened? (Are unnecessary features disabled?)

Step 5: Review Authentication and Authorization Architecture

This step deserves dedicated attention because authentication and authorization flaws are among the most exploited vulnerabilities.

Authentication assessment:

• How do users authenticate? (Password, MFA, SSO, certificate, biometric)
• How do services authenticate to each other? (mTLS, JWT, API key, shared secret)
• Is authentication centralized (IdP) or distributed (per-service)?
• What happens when the authentication service is unavailable?
• Are credentials stored securely? (Module 2.4 — cryptography standards)
• Are session/token lifetimes appropriate?

Authorization assessment:

• What authorization model is used? (RBAC, ABAC, ReBAC, ACL)
• Is authorization enforced at every access point? (API gateway, service level, database level)
• Is object-level authorization implemented? (Can user A access user B’s resources by changing an ID?)
• How are permissions managed and updated?
• Is there separation of duties for critical operations?
• Are there any implicit trust relationships? (Service A trusts everything from Service B without verification)

Step 6: Evaluate Data Protection Mechanisms

• Data classification: Is data classified by sensitivity? Does the architecture enforce different controls for different classifications?
• Encryption at rest: Is all sensitive data encrypted? What algorithms and key sizes? How are keys managed?
• Encryption in transit: Is all communication encrypted? TLS version? Certificate management?
• Data lifecycle: How is data created, processed, stored, archived, and destroyed? Are controls consistent across the lifecycle?
• Data access controls: Who can access which data? Are access controls enforced at the database level, application level, or both?
• Backup security: Are backups encrypted? Are backup access controls as strong as production?

Step 7: Check Network Segmentation and Isolation

• Network zones: Is the architecture properly segmented into trust zones (DMZ, application tier, data tier, management)?
• Inter-zone communication: Are firewalls or security groups controlling traffic between zones? Is traffic limited to necessary flows?
• East-west traffic: Is traffic between services in the same zone controlled? (Microsegmentation for zero trust)
• Egress filtering: Is outbound traffic restricted? (Prevents data exfiltration and C2 communication)
• DNS security: Is DNS resolution controlled? (Prevents DNS-based attacks and data exfiltration)
• Container isolation: Are container network policies enforced? Can containers communicate with arbitrary services?

Step 8: Assess Logging and Monitoring Architecture

• Coverage: Are all security-relevant events logged? (Authentication, authorization, data access, configuration changes, errors)
• Completeness: Do log entries contain sufficient detail? (Who, what, when, where, outcome)
• Integrity: Are logs tamper-evident? Can they be modified or deleted?
• Centralization: Are logs aggregated centrally for correlation and analysis?
• Retention: Do log retention periods meet compliance requirements?
• Alerting: Are alerts defined for security events? Are they tuned to minimize false positives?
• Response: Are alert response procedures defined and tested?
• Sensitive data: Is PII or other sensitive data excluded from logs?

Step 9: Review Resilience and Availability Design

• Single points of failure: Are there any components whose failure causes complete system outage?
• Redundancy: Are critical components redundant? (Active-active, active-passive, multi-region)
• Failover: Is failover automated? What is the failover time?
• Degraded mode: Can the system operate in degraded mode if a non-critical dependency fails?
• Rate limiting and throttling: Is the system protected against volumetric abuse?
• Circuit breakers: Do services have circuit breakers to prevent cascading failure?
• Disaster recovery: Is there a DR plan? Has it been tested?

Step 10: Document Findings with Severity Ratings

Every finding must be documented with:

Field	Description
ID	Unique finding identifier
Title	Short descriptive name
Severity	Critical / High / Medium / Low / Informational
Component	Which architectural component is affected
Description	What was found and why it is a concern
Evidence	How the finding was identified (configuration review, diagram analysis, testing)
Risk	What could happen if this is exploited (impact and likelihood)
Recommendation	Specific remediation steps
CIS Reference	Which CIS control is violated
Status	Open / In Progress / Remediated / Accepted
Owner	Who is responsible for remediation

---

6. Common Architectural Security Flaws

6.1 Missing Authentication Between Services

The flaw: Internal services communicate without authentication. Any service (or attacker who gains internal network access) can call any other service.

The risk: Lateral movement. An attacker who compromises one service can access all others.

The fix: mTLS between all services. Service mesh (Istio, Linkerd) automates mTLS provisioning. Zero trust — no implicit trust based on network position.

6.2 Excessive Trust Between Components

The flaw: Service A trusts all input from Service B without validation. “It’s an internal service, so the data is safe.”

The risk: If Service B is compromised, the attacker can send arbitrary data to Service A with full trust.

The fix: Validate input from internal services the same as external input. Never trust, always verify. Apply the same input validation patterns regardless of source.

6.3 Improper Network Segmentation

The flaw: All services run in the same network segment. Database servers are accessible from the web tier. Management interfaces are on the same network as user traffic.

The risk: An attacker who compromises any component has direct network access to all other components, including databases and management interfaces.

The fix: Network zones with security groups or firewalls enforcing least-privilege communication. Web tier can reach application tier. Application tier can reach database tier. Web tier cannot reach database tier directly. Management interfaces on separate networks with separate authentication.

6.4 Centralized Secrets Without Rotation

The flaw: All services use the same database password, stored in a shared configuration file, never rotated.

The risk: One credential leak compromises all services. No rotation means the compromise window is indefinite.

The fix: Per-service credentials with minimal privileges. Secret management (HashiCorp Vault, AWS Secrets Manager). Automated rotation. Short-lived credentials where possible (IAM roles, temporary tokens).

6.5 Missing Rate Limiting

The flaw: API endpoints have no rate limiting. Authentication endpoints are particularly vulnerable — unlimited login attempts enable credential stuffing.

The risk: Brute-force attacks, credential stuffing, resource exhaustion, API abuse.

The fix: Rate limiting at API gateway level (per-user, per-IP, per-endpoint). Adaptive rate limiting that increases restrictions under attack. CAPTCHA or proof-of-work challenges for authentication endpoints after threshold.

6.6 Over-Privileged Service Accounts

The flaw: Service accounts have admin-level permissions. “We gave it full access because it was easier to configure.”

The risk: If the service is compromised, the attacker inherits admin-level access. The blast radius is the entire system.

The fix: Scope every service account to the minimum necessary permissions. Use IAM policies with explicit allow, default deny. Regular access reviews. Principle of least privilege applied to every credential.

6.7 Inconsistent Security Controls Across Microservices

The flaw: Service A validates input, Service B does not. Service C uses parameterized queries, Service D concatenates SQL strings. Service E logs security events, Service F does not.

The risk: The overall security posture is determined by the weakest service. Inconsistency means security is unpredictable.

The fix: Shared security libraries or service mesh enforcement. Standard security middleware that all services use. Security templates for new services. Automated compliance scanning across all services.

---

7. Microservices Security Assessment

Service Mesh Assessment

• mTLS enforcement: Is mTLS enabled for all service-to-service communication? Are there exceptions? Are exceptions documented and justified?
• Certificate management: How are service certificates provisioned, rotated, and revoked? Automated or manual?
• Traffic policies: Are traffic policies (authorization, rate limiting) defined per service? Are they enforced consistently?
• Observability: Can all inter-service traffic be monitored? Are anomalies detected?

API Gateway Security

• Authentication: Is the API gateway enforcing authentication for all external requests?
• Rate limiting: Is rate limiting applied per client, per endpoint?
• Input validation: Is schema validation performed at the gateway level?
• TLS termination: Is TLS terminated at the gateway and re-encrypted (mTLS) to backend services?
• CORS: Are Cross-Origin Resource Sharing policies correctly configured?
• Security headers: Are security headers (CSP, X-Frame-Options, X-Content-Type-Options) applied consistently?

Sidecar Pattern Assessment

In sidecar-based architectures (Envoy, Istio proxy), assess:

• Sidecar bypass: Can services communicate directly, bypassing the sidecar proxy? Are network policies preventing bypass?
• Sidecar configuration: Is the sidecar configuration consistent across services? Are there misconfigurations?
• Sidecar updates: How are sidecar versions managed? Are security patches applied uniformly?

---

8. Cloud Architecture Assessment

Shared Responsibility Model

Cloud security assessment must account for the shared responsibility model:

Responsibility	IaaS	PaaS	SaaS
Physical infrastructure	Provider	Provider	Provider
Network infrastructure	Provider	Provider	Provider
Virtualization	Provider	Provider	Provider
Operating system	Customer	Provider	Provider
Middleware/Runtime	Customer	Provider	Provider
Application	Customer	Customer	Provider
Data	Customer	Customer	Customer
Identity/Access	Customer	Customer	Customer

The customer is always responsible for data and identity. The assessment must focus on what the customer controls.

Landing Zone Review

• Account structure: Are workloads separated into appropriate accounts/subscriptions? (Production vs. development vs. staging)
• VPC/VNet design: Are network boundaries properly defined? Are security groups/NSGs appropriately restrictive?
• IAM baseline: Are organizational policies enforced? Are there SCPs (AWS) or Azure Policies preventing dangerous configurations?
• Logging: Is CloudTrail/Activity Log/Audit Log enabled for all accounts? Are logs centralized?
• Guardrails: Are preventive guardrails in place? (Can a developer accidentally expose an S3 bucket publicly?)

IAM Assessment

• Root/owner account protection: Is MFA enforced? Is the root account used for daily operations? (It should not be)
• Principle of least privilege: Are IAM policies narrowly scoped? Any wildcard actions or resources?
• Service account management: Are service accounts rotated? Are there unused service accounts?
• Cross-account access: Are trust relationships documented and justified?
• Temporary credentials: Are temporary credentials (STS, managed identity) preferred over long-lived access keys?
• Permission boundaries: Are permission boundaries used to limit the maximum permissions any role can have?

---

9. AI-Assisted Architecture Review

9.1 Current Tools and Accuracy

AI-assisted architecture review tools are emerging but remain in early maturity. Current accuracy levels hover around 50-55%, meaning roughly half of findings are actionable and the other half are false positives or irrelevant observations.

Tool Category	Examples	Accuracy Range	Best Use
IaC scanning with AI	Checkov (with AI rules), Bridgecrew, Prisma Cloud	60-70% for known patterns	Detecting misconfigurations in Terraform, CloudFormation, Kubernetes manifests
LLM-based review	Claude, GPT-4 (manual review of architecture docs)	50-55%	Initial analysis, generating questions, identifying common anti-patterns
Cloud security posture	AWS Security Hub, Azure Defender, GCP Security Command Center	70-80% for their platform	Platform-specific misconfiguration detection
Diagram analysis	Emerging tools that analyze architecture diagrams	30-40%	Very early stage, limited accuracy

9.2 Limitations

• Context blindness: AI does not understand your business context, threat profile, or risk tolerance. It cannot assess whether a finding is relevant to your specific situation.
• Configuration gaps: AI reviews documentation and code, but may not see runtime configuration, environment-specific settings, or dynamic behavior.
• False equivalence: AI may flag a pattern as insecure that is appropriate in context (e.g., a public endpoint that is intentionally public).
• Novel architectures: AI performs well on standard patterns (three-tier web app, microservices on Kubernetes) but poorly on custom or unusual architectures.
• Integration understanding: AI struggles to assess the security implications of how two specific systems integrate in your environment.

9.3 Effective AI-Assisted Review Workflow

1. Prepare documentation: Export architecture diagrams, IaC code, network topology, IAM policies, and service configurations.
2. AI initial scan: Feed documentation to AI tools for initial analysis. Prompt specifically for security assessment against CIS controls, OWASP principles, and your security requirements.
3. Human triage: Security engineer reviews each AI finding. Classify as:
   • True positive: Genuine security concern. Document and add to findings.
   • False positive: Not applicable to this context. Dismiss with rationale.
   • Needs investigation: Unclear — requires deeper analysis.
4. Human augmentation: Security engineer adds context-specific findings that AI missed. Domain expertise fills the gaps.
5. Synthesize: Combine AI-detected and human-detected findings into the final assessment report.

9.4 Prompt Patterns for Architecture Review

Effective prompt:

Review this architecture diagram description against CIS Control 16.10 secure design
principles (least privilege, complete mediation, never trust user input, explicit error
checking, attack surface minimization). For each principle, assess compliance and
identify specific gaps. Rate each finding as Critical/High/Medium/Low with
justification.

Architecture: [description]

Ineffective prompt:

Is this architecture secure?

The more specific the prompt, the more useful the AI output. Provide frameworks, standards, and specific areas of concern.

---

10. Architecture Decision Records (ADRs)

What Are ADRs

Architecture Decision Records document significant architectural decisions, including security decisions. They capture the context, decision, and consequences — creating a traceable record of why the architecture is the way it is.

ADR Format for Security Decisions

# ADR-XXX: [Title of Security Decision]

## Status
[Proposed | Accepted | Deprecated | Superseded by ADR-YYY]

## Context
[What security challenge or requirement prompted this decision?
What constraints exist? What alternatives were considered?]

## Decision
[What is the architectural decision? Be specific about what was chosen and why.]

## Consequences

### Positive
- [What security improvements result from this decision?]

### Negative
- [What tradeoffs or limitations result?]

### Risks
- [What residual risks remain?]

## Compliance
- CIS Control: [Which controls does this decision support?]
- OWASP: [Which OWASP guidelines does this align with?]
- NIST SSDF: [Which SSDF practices does this support?]

## Review Date
[When should this decision be re-evaluated?]

Example ADR

# ADR-042: Implement mTLS for All Inter-Service Communication

## Status
Accepted

## Context
Our microservices architecture has 23 services communicating over the internal
network. Currently, inter-service communication uses plain HTTP without
authentication. CIS 16.10 requires complete mediation. A recent architecture
assessment found that any compromised service can call any other service
without restriction (Finding ASA-2024-017, Severity: Critical).

## Decision
Implement mutual TLS (mTLS) for all inter-service communication using
Istio service mesh. All services will present certificates issued by our
internal CA. Communication without valid certificates will be rejected.

## Consequences

### Positive
- All inter-service communication is encrypted and authenticated
- Compromised service cannot impersonate other services
- Certificate-based identity enables fine-grained authorization policies
- Satisfies CIS 16.10 complete mediation requirement

### Negative
- Istio adds operational complexity (sidecar management, certificate rotation)
- Approximately 2-5ms latency increase per inter-service call
- Requires certificate management infrastructure

### Risks
- Certificate rotation failure could cause service disruption (mitigated by
  automated rotation with monitoring)
- Istio misconfiguration could create security gaps (mitigated by configuration
  validation in CI/CD)

## Compliance
- CIS Control: 16.10 (Complete mediation, attack surface minimization)
- OWASP: Secure Design Principles — Defense in depth
- NIST SSDF: PW.1 — Design software to meet security requirements

## Review Date
2025-06-01

---

11. Remediation Planning and Prioritization

Severity-Based Prioritization

Severity	SLA	Action
Critical	1-7 days	Immediate remediation. May require emergency change. Blocks release.
High	30 days	Remediate in current sprint/cycle. Blocks release if not addressed.
Medium	90 days	Remediate in next planned release. Track in backlog.
Low	180 days	Address during regular maintenance. Track in backlog.
Informational	No SLA	Awareness item. No remediation required but documents a consideration.

Risk-Based Prioritization

When multiple findings have the same severity, prioritize by:

1. Exploitability: How easy is it to exploit? Is there a known exploit? Is it exposed to the internet?
2. Impact: What is the blast radius? Does it affect all users or a subset? Is it data loss, service disruption, or both?
3. Data sensitivity: Does the flaw expose PII, financial data, or health data?
4. Compensating controls: Are there other controls that partially mitigate the risk?
5. Remediation effort: Among equal-risk findings, address low-effort fixes first (more risk reduction per engineering hour).

Remediation Tracking

Every finding should be tracked in the project management system (Jira, Azure DevOps, Linear) with:

• Link to the assessment finding
• Assigned owner
• Due date based on severity SLA
• Verification criteria (how will we confirm the fix is effective?)
• Status tracking through remediation lifecycle

Re-Assessment

After remediation is complete:

1. Verify each fix addresses the finding (technical verification)
2. Confirm no regression in other areas (regression testing)
3. Update the assessment report with remediation status
4. Update the threat model if the finding revealed a missed threat
5. Update ADRs if the remediation changed architectural decisions

---

Summary

Architecture security assessment evaluates whether the built system actually meets security requirements. It complements threat modeling (which targets future design) with a focus on current state.

Key takeaways:

1. Architecture assessment is distinct from threat modeling: assessment evaluates what is built, threat modeling evaluates what will be built.
2. OWASP SAMM and BSIMM provide maturity models for progressing architecture assessment practices.
3. The ten-step methodology provides a comprehensive, structured approach covering every layer from authentication to resilience.
4. Common architectural flaws (missing service authentication, excessive trust, improper segmentation) are found in most organizations.
5. Microservices and cloud architectures require specific assessment techniques targeting service mesh, API gateways, and shared responsibility.
6. AI-assisted review operates at 50-55% accuracy and must always be supplemented with human expertise.
7. Architecture Decision Records create auditable, traceable documentation of security decisions.
8. Remediation must be tracked with severity-based SLAs and verified through re-assessment.

---

References

• CIS Controls v8, Control 16.10
• OWASP SAMM v2.0: Verification — Architecture Assessment
• BSIMM: SSDL Touchpoints — Architecture Analysis
• OWASP Secure Architecture Reference
• NIST SP 800-53: Security and Privacy Controls — SA-4, SA-8, SA-11, SA-17
• NIST Secure Software Development Framework (SSDF) v1.1 — PW.1
• NIST SP 800-207: Zero Trust Architecture
• Microsoft SDL Practice 5: Perform Security Architecture and Design Reviews
• Cloud Security Alliance: Cloud Controls Matrix (CCM) v4.0
• ISO 27001:2022, Annex A Control 8.27: Secure System Architecture and Engineering Principles

Study Guide

Key Takeaways

1. Assessment evaluates what is built; threat modeling evaluates what will be built — Both are needed and feed each other, but they serve different purposes at different times.
2. OWASP SAMM places architecture assessment under Verification — Three maturity levels: Ad Hoc, Structured, Systematic; target Level 2 within year one.
3. The ten-step methodology is comprehensive — Document architecture, review against requirements, check design principles, assess attack surface, review auth/authz, evaluate data protection, check network segmentation, assess logging, review resilience, document findings.
4. Architecture drift is a real security risk — When documented architecture does not match deployed architecture, assessments based on documentation miss real vulnerabilities.
5. Common flaws appear in most organizations — Missing service authentication, excessive trust between components, improper segmentation, centralized secrets without rotation.
6. AI-assisted review operates at 50-55% accuracy — IaC scanning with AI (60-70%) and cloud-native posture tools (70-80%) are more accurate for their specific domains.
7. Architecture Decision Records (ADRs) create auditable traceability — Capture context, decision, consequences, and compliance mapping for every significant security decision.

Important Definitions

Term	Definition
Architecture Security Assessment	Evaluating an existing architecture for security weaknesses, misconfigurations, and deviations from standards
Architecture Drift	When documented architecture does not match the actual deployed architecture
ADR	Architecture Decision Record — documents context, decision, and consequences of significant architectural decisions
SAMM Verification	OWASP SAMM business function containing Architecture Assessment, Requirements-driven Testing, and Security Testing
BSIMM AA	Building Security In Maturity Model Architecture Analysis — three levels of observed industry practice
Shared Responsibility Model	Cloud security model where customer always owns data and identity regardless of service type (IaaS/PaaS/SaaS)
mTLS	Mutual TLS — both client and server present certificates; fixes missing service authentication
Microsegmentation	Controlling traffic between services in the same zone; zero trust east-west traffic control

Quick Reference

• Framework/Process: Ten-step assessment methodology; SAMM three maturity levels; BSIMM AA three levels; severity-based remediation SLAs (Critical: 1-7 days, High: 30 days)
• Key Numbers: 50-55% AI review accuracy; 60-70% IaC scanning accuracy; 70-80% cloud posture tool accuracy; 10 assessment steps; Critical SLA 1-7 days
• Common Pitfalls: Confusing threat modeling with architecture assessment; trusting documented architecture without verifying deployment; assessing in isolation without cross-referencing threat model; not tracking remediation with severity-based SLAs

Review Questions

1. When should you use threat modeling versus architecture assessment, and how do they feed each other?
2. How would you verify that documented architecture matches deployed architecture to prevent drift?
3. What makes missing authentication between microservices one of the most common and dangerous architectural flaws?
4. How would you structure an ADR for a decision to implement mTLS across all inter-service communication?
5. At what SAMM maturity level should architecture reviews become mandatory SDLC gates, and what does that require?