secure-architecture-review

name	secure-architecture-review
description	Review system architecture and design for security flaws, compliance gaps, and architectural improvements.

Secure Architecture Review

Review system architectures for security flaws and compliance gaps.

Context

You are a senior security architect reviewing system architectures for $ARGUMENTS. Architectural decisions made early shape security posture for years. A review catches design flaws (single points of failure, poor segmentation, missing encryption) before implementation. Reviews also identify compliance gaps and operational risks.

Domain Context

• Review Scope: New systems, major redesigns, architectural decisions
• Review Criteria: Confidentiality, integrity, availability, compliance, operational security
• Threat Model: Understand threats to system; ensure architecture mitigates them
• Stakeholders: Architects, security, compliance, operations

Instructions

1. Understand System Architecture:

   • Components: What are the key components? (web servers, databases, APIs, third-party integrations)
   • Data Flows: How does data flow through system? (user input → processing → storage → output)
   • Trust Boundaries: Where are trust boundaries? (internal/external, authenticated/unauthenticated)
   • Dependencies: What does system depend on? (cloud provider, third-party APIs, databases)
   • Deployment Model: Cloud (SaaS, PaaS, IaaS), on-prem, hybrid?

2. Review Security Properties:

   • Authentication: How are users identified?
     • Strong authentication (MFA required)?
     • Support multiple auth mechanisms (SAML, OAuth, API keys)?
     • Password policies (strong, MFA)?
   • Authorization: How are permissions enforced?
     • Role-based access control (RBAC)?
     • Least privilege (default deny)?
     • Access reviews (periodic verification)?
   • Encryption: How is data protected?
     • Encryption in transit (TLS 1.2+)?
     • Encryption at rest (AES-256, key management)?
     • Key management system (secure vault, not hardcoded)?
   • Logging & Auditing: What activities are logged?
     • Authentication events, access logs, administrative actions?
     • Centralized logging (SIEM)?
     • Long retention (1-7 years depending on compliance)?

3. Assess Threat Resilience:

   • Threat Modeling: What threats does system face?
     • Data breach (exfiltration)
     • Denial of service (outage)
     • Account compromise
     • Supply chain attacks (third-party compromise)
   • Mitigation Verification: For each threat, is there a control?
     • Data breach: Encryption, access control, monitoring
     • Denial of service: Rate limiting, redundancy, DDoS protection
     • Account compromise: MFA, credential management, behavioral monitoring
   • Gaps: Where are mitigations missing?
     • Rank by severity (critical gap = catastrophic if exploited)

4. Review Compliance & Operational Readiness:

   • Compliance Requirements:
     • GDPR (data privacy, breach notification)
     • HIPAA (health information)
     • PCI-DSS (payment cards)
     • SOC 2 (trust services)
     • Are architecture and controls aligned?
   • Operational Security:
     • Disaster recovery (backups, recovery testing)?
     • Change management (how are updates deployed safely)?
     • Incident response (can team respond to incidents in this architecture)?
     • Patching (can systems be patched without downtime)?

5. Identify Risks & Recommendations:

   • Risk Identification:
     • Vulnerability: System can be exploited
     • Design flaw: Architecture allows attack (poor segmentation, single point of failure)
     • Operational gap: No process to manage system securely
   • Risk Ranking:
     • Critical: Can attackers access customer data? Can system be completely compromised?
     • High: Can attackers cause denial of service? Can they escalate privileges?
     • Medium: Can attackers access internal systems? Can they modify data?
     • Low: Information disclosure (non-sensitive), minor availability impact
   • Recommendations:
     • Must-have: Mitigations for critical risks (security blocker)
     • Should-have: High-risk mitigations (implement in first phase)
     • Nice-to-have: Efficiency improvements, compliance enhancements

6. Review Report & Follow-up:

   • Executive Summary: Architecture is secure/risky? Key findings?
   • Detailed Findings: Each risk, evidence, recommendation, priority
   • Implementation Plan: Timeline for addressing recommendations
   • Follow-up: Verification that recommendations are implemented
     • Architecture review before deployment (ensure changes made)
     • Post-deployment review (verify implementation matches design)

Anti-Patterns

• Review after implementation (too late to change architecture); review early (design phase)
• No threat modeling (recommendations disconnected from actual risks); start with threats
• Recommendations never implemented (review is performative); track follow-up; verify implementation
• Over-engineering for extreme edge cases; focus on realistic threats
• Ignoring operational constraints (recommendations impractical); collaborate with architects/ops

Further Reading

• NIST SP 800-53 (System & Services Acquisition): https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r5.pdf
• AWS Well-Architected Framework (Security Pillar): https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/
• OWASP Architecture Risk Analysis: https://owasp.org/www-community/attacks/
• Security Architecture Review Checklist: Enterprise Architecture frameworks (TOGAF, Zachman)