Security Architecture: Threat Modeling, Identity & Compliance Design

Security architecture defines how systems protect data, verify identity, enforce access, and maintain compliance across the entire technology stack. The skill produces comprehensive security designs covering threat modeling, zero trust implementation, identity management, data protection, application security pipelines, and compliance mapping.

Principio Rector

La seguridad que depende de un perímetro ya fue comprometida. Zero Trust no es un producto — es una filosofía de diseño. Threat modeling antes de diseñar, compliance como piso mínimo no techo máximo, y cada decisión de seguridad documentada antes de implementar.

Filosofía de Security Architecture

1. Zero Trust everywhere. No hay red confiable, no hay usuario confiable, no hay servicio confiable. Cada request se autentica, autoriza y cifra — sin excepciones.
2. Threat modeling before design. Modelar amenazas DESPUÉS del diseño es auditoría. Modelarlas ANTES es arquitectura. STRIDE/PASTA en la fase de diseño reduce 100x el costo de remediación.
3. Compliance is minimum bar, not maximum goal. Pasar un audit no significa ser seguro. Los frameworks (SOC2, PCI-DSS, ISO 27001) definen el piso — la arquitectura de seguridad define el techo.

Inputs

The user provides a system or organization name as $ARGUMENTS. Parse $1 as the system/organization name used throughout all output artifacts.

Parameters:

• {MODO}: piloto-auto (default) | desatendido | supervisado | paso-a-paso
  • piloto-auto: Auto para threat enumeration y control mapping, HITL para Zero Trust maturity y compliance scope decisions.
  • desatendido: Cero interrupciones. Security architecture documentada automáticamente. Supuestos documentados.
  • supervisado: Autónomo con checkpoint en threat model review y IAM design.
  • paso-a-paso: Confirma cada threat, mitigation, encryption decision, y compliance mapping.
• {FORMATO}: markdown (default) | html | dual
• {VARIANTE}: ejecutiva (~40% — S1 threat model + S2 zero trust + S6 compliance) | técnica (full 6 sections, default)

NIST CSF 2.0 Alignment

All deliverables map to the six NIST CSF 2.0 functions:

Use the Govern function to ensure security architecture has executive sponsorship and integrates into enterprise risk management. CSF 2.0 explicitly addresses supply chain security, zero trust, and AI-related risks.

Before generating architecture, detect the technology context:

!find . -name "*.tf" -o -name "Dockerfile" -o -name "*.yaml" -o -name "auth*" -o -name "security*" | head -20

If reference materials exist, load them:

Read ${CLAUDE_SKILL_DIR}/references/security-frameworks.md

When to Use

• Designing security architecture for new systems or major platform changes
• Conducting threat modeling for applications, APIs, or infrastructure
• Implementing zero trust architecture
• Designing identity and access management systems
• Planning encryption and data protection strategies
• Mapping compliance requirements to technical controls

When NOT to Use

• CI/CD pipeline security (SAST/DAST integration only) — use devsecops-architecture
• Infrastructure provisioning and network design — use infrastructure-architecture
• Application code patterns and module design — use software-architecture
• Penetration testing execution — requires specialized security team

Delivery Structure: 6 Sections

S1: Threat Modeling

Systematically identify threats using structured methodologies applied to the system's architecture.

Methodology selection:

• STRIDE (per-element): Spoofing, Tampering, Repudiation, Information Disclosure, DoS, Elevation of Privilege. Best for component-level analysis.
• PASTA (risk-centric, 7-stage): Business objective -> tech scope -> decomposition -> threat analysis -> vulnerability mapping -> attack modeling -> risk/impact. Best for business-aligned threat assessment.

Process:

1. Draw data flow diagrams (DFDs): processes, data stores, data flows, external entities, trust boundaries
2. Identify attack surface: entry points (APIs, UIs, file uploads), external dependencies, admin interfaces
3. Enumerate threats per element using STRIDE categories
4. Score risks: likelihood x impact matrix (5x5), prioritize for mitigation
5. Map threats to mitigations and residual risk acceptance

Attacker profiles: External anonymous, authenticated user, malicious insider, supply chain compromise

S2: Zero Trust Architecture

Design identity-centric security that assumes no implicit trust regardless of network location.

Core principles: Verify explicitly, least privilege access, assume breach.

NIST SP 800-207 + SP 1800-35 Implementation Patterns:

• Identity as perimeter: every request authenticated and authorized, regardless of source network
• Micro-segmentation: network policies restricting lateral movement between services
• Continuous verification: session validation, device posture checks, risk-based step-up auth
• Service-to-service: mutual TLS (mTLS), service mesh authorization policies (Istio, Linkerd)
• Software-defined perimeter: encrypted overlay networks, private endpoints

Zero Trust Maturity Model:

Key decisions:

• Greenfield (designed-in) vs. brownfield (progressive adoption per maturity model)
• Service mesh overhead: sidecar proxy adds 1-3ms latency per hop — justify against security benefit
• Device trust: managed-only, BYOD with posture assessment, or device-agnostic

S3: Identity & Access Management

Design authentication, authorization, and secret management for human and machine identities.

Authentication: OAuth 2.0 / OIDC for user flows, client credentials for S2S, WebAuthn/FIDO2 for passwordless MFA: TOTP/WebAuthn for users, certificate-based for services, risk-based triggers SSO: Centralized IdP, federation with external IdPs (SAML, OIDC) Service identity: Workload identity (SPIFFE/SPIRE), short-lived certificates, zero long-lived secrets Secret management: HashiCorp Vault, AWS Secrets Manager. Rotation: 90 days for credentials, on-demand for incident.

Authorization Model Selection:

Token decisions: JWT (stateless, verifiable, larger) vs. opaque (requires introspection, revocable). Use JWT for S2S, opaque for user sessions needing immediate revocation.

S4: Data Protection

Design encryption, key management, and data loss prevention across the data lifecycle.

Encryption at rest: Database TDE, filesystem encryption, backup encryption — AES-256 minimum Encryption in transit: TLS 1.3 everywhere, certificate management (ACME/Let's Encrypt), certificate pinning for mobile Key management: Cloud KMS or HSM-backed. Key hierarchy: master key -> data encryption keys. Rotation: annual for master, monthly for DEKs. Tokenization: Replace sensitive data with non-reversible tokens for analytics and testing Data masking: Dynamic masking in non-prod environments, role-based visibility

Data Classification and Handling:

S5: Application Security

Integrate security testing into the development lifecycle.

Shift-Left Cost Multiplier:

Security pipeline:

• SAST: Code scanning in IDE and CI (SonarQube, Semgrep, CodeQL). Fail PR on critical findings.
• DAST: Runtime scanning against staging (ZAP, Burp Suite). Run weekly or pre-release.
• SCA: Dependency vulnerability scanning + license compliance (Snyk, Dependabot, Renovate). Vulnerability SLA: critical <24h, high <7d, medium <30d.

Supply Chain Security (SLSA + SBOM):

SBOM format choice:

• CycloneDX: Security-focused, VEX support, OWASP-backed. Pick for application security.
• SPDX: License/legal detail, ISO standard (ISO/IEC 5962:2021). Pick for compliance/legal.
• Tools: Syft (generation), Dependency-Track (analysis), cosign/Sigstore (signing)
• EU Cyber Resilience Act (2027) makes SBOMs mandatory for software sold in EU.

RASP (Runtime Application Self-Protection): Instrument runtime to detect/block SQL injection, deserialization, path traversal from inside the application. Complement WAF with runtime visibility for high-value applications.

Security Champions Program:

• Embed 1 trained champion per dev team (10-20% time allocation)
• Champions conduct first-pass threat models, triage SAST findings, escalate to central security
• Scales security knowledge without growing security team linearly
• Training: OWASP Top 10, secure coding, threat modeling basics (40h initial, 8h/quarter ongoing)

S6: Compliance & Audit

Map regulatory frameworks to technical controls with evidence collection and continuous compliance.

Compliance Framework Mapping Table:

Control matrix: Framework requirement -> technical control -> evidence source -> testing frequency Continuous compliance: Automated policy checks (OPA, Cloud Custodian), drift detection Tooling: Vanta, Drata for automated evidence collection; manual for complex controls Audit readiness: Evidence repository, control owner assignments, pre-audit checklists

Trade-off Matrix

Assumptions

• System has defined data flows and component boundaries (or they can be established)
• Organization has identified applicable regulatory frameworks
• Security tooling budget is available or can be justified
• Executive sponsorship exists for security architecture initiatives

Limits

• Does not perform penetration testing or vulnerability exploitation
• Does not replace legal counsel for regulatory interpretation
• Threat models require periodic refresh as systems evolve (quarterly recommended)
• Zero trust full maturity takes 18-36 months

Edge Cases

Greenfield System: Design security from day one. Embed threat modeling in architecture review. Choose IdP and encryption strategy before first deployment.

Legacy System with No Security Architecture: Start with threat model of current state. Prioritize: auth/authz gaps, data encryption, dependency vulnerabilities. Phase improvements aligned with existing roadmap.

Multi-Tenant SaaS: Tenant isolation is paramount. Data-level access control, tenant-scoped encryption keys, per-tenant audit logging. Test for cross-tenant data leakage explicitly.

Regulated Industry (Finance, Health): Compliance drives architecture. Map every control to framework requirement. Budget for audit prep and external assessments. Encryption and access logging are non-negotiable.

Acquisitions / Mergers: Multiple identity systems, inconsistent security postures. Prioritize identity federation, network segmentation between entities, unified compliance reporting.

Validation Gate

Before finalizing delivery, verify:

• Threat model covers all trust boundaries and data flows with STRIDE/PASTA
• Zero trust maturity level realistic with phased roadmap
• Identity architecture covers human, service, and machine identities
• Encryption covers data at rest and in transit with key management defined
• Application security pipeline includes SAST, DAST, SCA with vulnerability SLAs
• SLSA level and SBOM format selected with generation integrated into CI
• Compliance frameworks mapped to specific technical controls (mapping table)
• Evidence collection automated where possible
• Secret management eliminates long-lived credentials
• Security champions program structured with training plan

Knowledge Graph

graph TD
    subgraph Core
        SA[Security Architecture]
    end

    subgraph Inputs
        I1[System Architecture / DFDs] --> SA
        I2[Regulatory Requirements] --> SA
        I3[Existing Security Controls] --> SA
        I4[Identity Infrastructure] --> SA
    end

    subgraph Outputs
        SA --> O1[Threat Model - STRIDE/PASTA]
        SA --> O2[Zero Trust Design]
        SA --> O3[IAM Architecture]
        SA --> O4[Data Protection Strategy]
        SA --> O5[AppSec Pipeline]
        SA --> O6[Compliance Control Matrix]
    end

    subgraph Related Skills
        RS1[devsecops-architecture] -.-> SA
        RS2[infrastructure-architecture] -.-> SA
        RS3[software-architecture] -.-> SA
        RS4[cloud-native-architecture] -.-> SA
        RS5[data-governance] -.-> SA
    end

Output Templates

Formato MD (default):

# Security Architecture: {system_name}
## S1: Threat Modeling
### DFDs | Attack Surface | STRIDE Enumeration | Risk Scoring | Mitigations

## S2: Zero Trust Architecture
### NIST 800-207 | Micro-Segmentation | mTLS | Maturity Model

## S3: Identity & Access Management
### AuthN (OAuth/OIDC/FIDO2) | AuthZ (RBAC/ABAC/ReBAC) | Secret Management

## S4: Data Protection
### Encryption at Rest/Transit | Key Management | Classification | Masking

## S5: Application Security
### SAST/DAST/SCA | SLSA/SBOM | RASP | Security Champions

## S6: Compliance & Audit
### Framework Mapping (SOC2/ISO27001/PCI-DSS/HIPAA/GDPR) | Evidence | Continuous Compliance

Formato XLSX: Matriz de controles de seguridad: filas por framework regulatorio (SOC2, ISO27001, PCI-DSS, HIPAA, GDPR), columnas por area de control, con estado de implementacion, evidencia requerida, owner, y frecuencia de testing. Incluye hoja de threat model con scoring de riesgo.

DOCX (bajo demanda)

• Filename: {fase}_security_architecture_{cliente}_{WIP}.docx
• Generado con python-docx y MetodologIA Design System v5. Portada con nombre del sistema y fecha, TOC automático, encabezados Poppins navy, cuerpo Montserrat, acentos dorados, tablas zebra. Secciones: Threat Model (STRIDE/PASTA), Zero Trust Design, IAM Architecture, Data Protection, AppSec Pipeline, Compliance Control Matrix.

HTML (bajo demanda)

• Filename: {fase}_security_architecture_{cliente}_{WIP}.html
• Estructura: HTML self-contained branded (Design System MetodologIA v5). Light-First Technical. Threat model con DFD visual, zero trust maturity gauge (Crawl/Walk/Run), compliance control matrix con estado por framework. WCAG AA, responsive, print-ready.

PPTX (bajo demanda)

• Filename: {fase}_security_architecture_{cliente}_{WIP}.pptx
• Generado via python-pptx con MetodologIA Design System v5. Slide master con gradiente navy, títulos en Poppins, cuerpo en Montserrat, acentos en gold. Máx 20 slides ejecutivo / 30 técnico. Notas del presentador con referencias de evidencia. Slides: Threat Model (STRIDE/PASTA), Zero Trust Maturity Model, IAM Architecture, Data Protection Strategy, AppSec Pipeline, Compliance Control Matrix (SOC2/ISO27001/PCI-DSS/HIPAA/GDPR).

Evaluacion

Umbral minimo: 7/10 en cada dimension. Composite ponderado >= 7.0 para considerar el output aceptable.

Output Format Protocol

Default output is Markdown with embedded Mermaid diagrams. HTML generation requires explicit {FORMATO}=html parameter.

Output Artifact

Primary: A-01_Security_Architecture.html — Executive summary, threat model, zero trust design, IAM architecture, data protection strategy, application security pipeline, compliance control matrix.

Secondary: Threat model diagrams (DFD), control matrix spreadsheet, compliance gap analysis, secret rotation runbook.

Autor: Javier Montaño | Última actualización: 12 de marzo de 2026