Security architecture review

st 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.

```json
{
  "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