Security architecture review

pudiation, Information Disclosure, Denial of Service, Elevation of Privilege) to each element in the DFD. 4. Control Verification: Map identified threats to specific security controls. Validate control efficacy using code-as-configuration or policy-as-code checks. 5. Risk Assessment & Remediation: Quantify risk based on likelihood and impact. Generate a remediation backlog with architectural recommendations.

Code Implementation: Security Review Artifact Generator

Integrate security reviews into the CI/CD pipeline by treating the threat model and review artifacts as code. The following TypeScript example defines a schema for a security review configuration and a validation engine that checks architectural constraints.

// security-review.types.ts

export interface TrustBoundary {
    id: string;
    name: string;
    securityLevel: 'public' | 'internal' | 'restricted' | 'confidential';
    controls: string[];
}

export interface DataFlow {
    source: string;
    destination: string;
    dataClassification: 'PII' | 'Financial' | 'Public' | 'Internal';
    protocol: string;
    encrypted: boolean;
}

export interface SecurityReviewConfig {
    systemName: string;
    version: string;
    trustBoundaries: TrustBoundary[];
    dataFlows: DataFlow[];
    requirements: {
        mandatoryEncryption: boolean;
        mfaRequiredForAdmin: boolean;
        auditLoggingEnabled: boolean;
    };
}

// security-review.engine.ts

export class SecurityReviewEngine {
    private config: SecurityReviewConfig;

    constructor(config: SecurityReviewConfig) {
        this.config = config;
    }

    public validate(): ValidationResult {
        const issues: Issue[] = [];

        // Check 1: Encryption enforcement on sensitive data flows
        if (this.config.requirements.mandatoryEncryption) {
            const unencryptedSensitiveFlows = this.config.dataFlows.filter(
                flow => 
                    ['PII', 'Financial'].includes(flow.dataClassification) && 
                    !flow.encrypted
            );

            if (unencryptedSensitiveFlows.length > 0) {
                issues.push({
                    severity: 'CRITICAL',
                    category: 'ENCRYPTION',
                    message: `Sensitive data flows detected without encryption: ${unencryptedSensitiveFlows.map(f => `${f.source} -> ${f.destination}`).join(', ')}`,
                    recommendation: 'Enable TLS 1.3 or application-layer encryption for all PII/Financial flows.'
                });
            }
        }

        // Check 2: Trust boundary crossing validation
        this.config.dataFlows.forEach(flow => {
            const sourceBoundary = this.config.trustBoundaries.find(t => t.id === flow.source);
            const destBoundary = this.config.trustBoundaries.find(t => t.id === flow.destination);

            if (sourceBoundary && destBoundary && sourceBoundary.id !== destBoundary.id) {
                // Verify authentication mechanism exists for cross-boundary flow
                if (!flow.protocol.includes('auth')) {
                    issues.push({
                        severity: 'HIGH',
                        category: 'AUTHENTICATION',
                        message: `Cross-boundary flow ${flow.source} -> ${flow.destination} lacks explicit authentication mechanism.`,
                        recommendation: 'Implement mutual TLS or OAuth2 client credentials for cross-boundary communication.'
                    });
                }
            }
        });

        return { issues, passed: issues.length === 0 };
    }
}

export interface ValidationResult {
    issues: Issue[];
    passed: boolean;
}

export interface Issue {
    severity: 'CRITICAL' | 'HIGH' | 'MEDIUM' | 'LOW';
    category: string;
    message: string;
    recommendation: string;
}

Architecture Decisions and Rationale

• Zero Trust Network Architecture: Assume breach. Verify explicitly. Use the review to enforce least-privilege access between microservices, eliminating implicit trust based on network location.
• Defense in Depth: The review should validate multiple layers of controls. If a WAF fails, application-level input validation must catch the attack. If IAM fails, data encryption at rest must protect the asset.
• Separation of Duties: Ensure architectural components responsible for authentication, authorization, and auditing are distinct to prevent single points of failure and reduce insider risk.
• Secure Defaults: Architectures should default to deny. Access control lists and security groups must explicitly allow traffic rather than allowing all by default.

Pitfall Guide

Common Mistakes in Security Architecture Reviews

1. Reviewing Code Instead of Architecture:

   • Mistake: Focusing on line-of-code vulnerabilities, library versions, or configuration typos during the architecture review.
   • Correction: Architecture reviews must focus on design patterns, data flows, and trust boundaries. Code-level issues belong in SAST and peer review processes.

2. Ignoring Third-Party and Supply Chain Risks:

   • Mistake: Treating external APIs, SaaS integrations, and open-source libraries as trusted black boxes.
   • Correction: Map all external dependencies. Evaluate the security posture of third parties and define mitigation strategies for supply chain compromises, such as sandboxing or strict egress filtering.

3. Static Threat Models:

   • Mistake: Creating a threat model once and never updating it.
   • Correction: Threat models must be living artifacts. Integrate them into the PR process. Trigger a review update whenever the DFD changes or new components are introduced.

4. Focusing Only on External Threats:

   • Mistake: Designing defenses solely against external attackers while neglecting insider threats or compromised credentials.
   • Correction: Include scenarios for malicious insiders, compromised admin accounts, and lateral movement within the threat model.

5. Lack of Remediation Tracking:

   • Mistake: Identifying risks but failing to assign owners or deadlines for remediation.
   • Correction: Integrate review findings into the project management tool. Risks must have an owner, a due date, and a status. Unmitigated risks require formal risk acceptance by a designated authority.

6. Over-Engineering Controls:

   • Mistake: Applying enterprise-grade controls to low-risk internal tools, creating unnecessary complexity and operational overhead.
   • Correction: Apply risk-based security. The rigor of the review and the strength of controls should be proportional to the data sensitivity and business impact.

7. Assuming Cloud Provider Security Covers Everything:

   • Mistake: Relying solely on the cloud provider's shared responsibility model without validating customer-side configurations.
   • Correction: Explicitly review IAM policies, bucket permissions, security group rules, and encryption key management. The provider secures the cloud; you secure what's in the cloud.

Best Practices from Production

• Automate Constraint Checking: Use policy-as-code (e.g., OPA, Checkov) to enforce architectural decisions automatically. If the architecture requires encryption, the pipeline should fail if a resource is deployed without it.
• Focus on High-Value Data: Prioritize the review on components handling sensitive data. This maximizes risk reduction per unit of effort.
• Continuous Review Cycle: Shift security left by embedding lightweight architecture reviews in design documents and RFCs. Reserve deep-dive reviews for major releases or architectural changes.
• Cross-Functional Collaboration: Involve developers, operations, and security engineers in the review. Developers provide implementation context; operations provide runtime insights; security provides threat expertise.

Production Bundle

Action Checklist

• Define Trust Boundaries: Identify and document all trust zones and boundaries within the system architecture.
• Map Data Flows: Create a comprehensive Data Flow Diagram showing all data movements, storage locations, and classifications.
• Apply STRIDE Analysis: Perform threat modeling using STRIDE for every component and data flow in the DFD.
• Verify IAM Policies: Audit identity and access management configurations for least privilege and separation of duties.
• Check Cryptographic Standards: Validate encryption algorithms, key management practices, and certificate rotation policies.
• Review Incident Response: Ensure architectural design supports detection and response, including logging, tracing, and isolation capabilities.
• Validate Third-Party Risks: Assess security controls and data handling for all external dependencies and integrations.
• Generate Remediation Plan: Document all identified risks with severity, owners, and remediation deadlines.

Decision Matrix

Scenario	Recommended Approach	Why	Cost Impact
Microservices Architecture	Service Mesh + mTLS + Centralized Policy Engine	Manages complex inter-service communication and enforces zero trust at scale.	High initial setup, low operational risk.
Legacy Monolith Modernization	Strangler Fig Pattern with Security Gateways	Allows incremental security improvements without full rewrite; isolates legacy risks.	Medium cost, reduces migration risk significantly.
Public-Facing API	API Gateway + WAF + Rate Limiting + OAuth2	Protects against OWASP Top 10, DDoS, and ensures strict client authentication.	Medium cost, prevents high-impact breaches.
Internal Data Analytics	Role-Based Access Control + Data Masking + Audit Logging	Focuses on data privacy and insider threat mitigation.	Low cost, ensures compliance with minimal overhead.
Regulated Industry (FinTech/Health)	Formal Threat Modeling + Penetration Testing + Immutable Audit Trails	Meets strict compliance requirements and reduces liability.	High cost, mandatory for market entry.

Configuration Template

Use this JSON template to define a security review artifact. This can be stored in version control and parsed by CI/CD pipelines.

{
  "schemaVersion": "1.0",
  "system": {
    "name": "payment-gateway",
    "owner": "payments-team",
    "criticality": "HIGH",
    "dataClassification": ["PII", "Financial"]
  },
  "trustBoundaries": [
    {
      "id": "tb-external",
      "name": "Internet",
      "securityLevel": "public"
    },
    {
      "id": "tb-internal",
      "name": "VPC Private",
      "securityLevel": "restricted"
    }
  ],
  "dataFlows": [
    {
      "id": "df-01",
      "source": "tb-external",
      "destination": "api-gateway",
      "dataClassification": "Financial",
      "protocol": "HTTPS/TLS1.3",
      "encrypted": true
    }
  ],
  "controls": {
    "encryptionAtRest": "AES-256",
    "encryptionInTransit": "TLS1.3",
    "authentication": "OAuth2/OIDC",
    "authorization": "RBAC with ABAC extensions",
    "logging": "Centralized SIEM with PII redaction"
  },
  "threatModel": {
    "methodology": "STRIDE",
    "lastReviewed": "2024-05-20",
    "risks": [
      {
        "id": "R-001",
        "threat": "Spoofing via compromised API keys",
        "mitigation": "Short-lived tokens with rotation",
        "status": "MITIGATED"
      }
    ]
  }
}

Quick Start Guide

1. Initialize Review Artifact: Run the initialization command to generate the baseline configuration file.

   npx security-review init --name my-service --criticality HIGH
   

2. Generate Data Flow Diagram: Use the CLI to auto-generate a DFD from your infrastructure-as-code templates or manually populate the dataFlows section in the JSON config.

   npx security-review generate-dfd --input ./infra/terraform
   

3. Run Validation Engine: Execute the validation engine to check for architectural constraints and control gaps.

   npx security-review validate --config ./security-review.json
   

4. Review and Commit: Address any CRITICAL or HIGH issues reported by the engine. Commit the updated configuration and threat model to the repository.

   git add security-review.json threat-model.md
   git commit -m "feat(security): complete architecture review for v1.2"
   

5. Integrate with CI/CD: Add a pipeline step to run the validation engine on every pull request. Block merges if critical architectural violations are detected.

   # .github/workflows/security-review.yml
   steps:
     - name: Security Architecture Review
       run: npx security-review validate --config security-review.json --fail-on-critical