name: sofka-security-architecture
description: >
Security architecture design — threat modeling, zero trust, identity, encryption, compliance.
Use when the user asks to "design security architecture", "model threats", "implement zero trust", "design IAM",
"plan encryption strategy", "map compliance requirements", or mentions STRIDE, OWASP, OAuth, RBAC, SOC2, ISO27001, PCI-DSS.
model: opus
context: fork
allowed-tools:
- Read
- Write
- Edit
- Glob
- Grep
- Bash

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

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