Threat Modeling y control de riesgos

1) Principios

1. Architectural First. Comenzamos con contextos, límites de confianza y flujos de datos.
2. Risk ≈ Likelihood × Impact. Nos medimos, no nos sentimos.
3. Defense in Depth. Controles en cada capa: código → protocolo → plataforma → personas.
4. Shift Left/Right. Gates tempranos en PR + monitoreo y respuesta en la venta.
5. Privacy by Design. Simulamos no solo amenazas a la seguridad, sino también riesgos de privacidad.
6. Automate Where Possible. Políticas como código, verificaciones automáticas, «líneas rojas».

2) Inventario: activos, entidades, límites de confianza

Activos: datos (PII, finanzas, secretos), recursos informáticos, claves, accesos, procesos empresariales.
Entidades: usuarios, servicios, almirantes, socios, proveedores externos.
Límites de confianza: usuarios ↔ frente, frente ↔ puerta de enlace API, servicios ↔ DB/caché/cola, regiones/nubes.
Superficie de ataque: puntos de entrada (API, webhooks, UI, redes, CI/CD, cadena de suministro).

mermaid flowchart LR
U[Пользователь] -- TLS --> WAF[WAF/CDN]
WAF --> GW[API Gateway]
GW --> Svc[Service A]
Svc --> DB[(Postgres)]
Svc --> MQ[[Kafka]]
MQ --> SvcB[Service B]
subgraph Trust Boundary
GW; Svc; SvcB end

3) Framework de amenazas

STRIDE (безопасность): Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege.
LINDDUN (приватность): Linkability, Identifiability, Non-repudiation, Detectability, Disclosure, Unawareness, Non-compliance.
PASTA (proceso): desde objetivos comerciales y actores de amenazas → detalles técnicos → escenarios de prueba.

4) Evaluación de riesgos

DREAD/OWASP Risk Rating o CVSS para vulnerabilidades.
Probabilidad (L): motivo/posibilidades del atacante, complejidad, exposición de la superficie.
Impacto (I): finanzas, yurrises, tiempo de inactividad, fugas de PD.
Riesgo (R = L × I) → Prioridad y Tritment: Avoid/Reducir/Transferir/Aceptar.

Impact
Low Med High Critical
Lik Low  L  L  M   H
Med  L  M  H   H
High M  H  High  Crit

Registro de riesgos (mínimo de campos): 'id, script, STRIDE, activo, L, I, R, propietarios, controles, estado, fecha de revisión'.

5) Controles: Prevent/Nat/Respond

• Autenticación/autorización: OIDC/OAuth2, PoLP, RBAC/ABAC, préstamos de servicio de corto plazo.
• Secretos/claves: KMS/HSM, rotación, principio de «no saber», FPE/cifrado de campos.
• Protocolos seguros: TLS1. 2 +, mTLS, firmas de webhooks, idempotencia y anti-replay.
• Validación/saneamiento: esquemas (JSON Schema/Proto), límites, normalización.
• Aislamiento: políticas de red, segmentación, sandbox, namespaces, bulkheads.

• Los registros de auditoría (no recargables), corelación en SIEM, alertas a las anomalías.
• Supervisión de la firma y la integridad (exportación de artefactos hash, attestation).
• Honeytokens/canarios para el bebé temprano de la fuga de claves.

• Runbook IR: clasificación, aislamiento, revocación de claves, alertas, forenzika.
• Automático kill-switch/feature-flag, «listas negras» de tokens.
• Notificaciones a usuarios/reguladores en incidentes de PD.

6) SDL y getas de seguridad

En idea/diseño: threat model (RFC/ADR), check-list de controles.
En desarrollo: SAST/secret-scan, scans de dependencia (SCA), política de dependencia.
En el conjunto: SBOM, firma de artefactos, política de vulnerabilidades (umbrales CVSS).
En deploe: OPA/Kyverno - política de IaC/manifiestos (securityContext, políticas de red, prueba de secretos).
En venta: IDS/WAF, anomaly detection, canary-check, caos-security (por ejemplo, certificado caducado).

rego package policy.cicd deny[msg] {
some v input.sbom.vulns[v].cvss >= 7.0 msg:= sprintf("High vuln blocked: %s %s", [v.package, v.id])
}
deny[msg] {
input.k8s.pod.spec.securityContext.runAsRoot == true msg:= "RunAsRoot forbidden"
}

7) Supply Chain y confianza en los artefactos

SBOM por imagen/paquete; actualizaciones de dependencias - a través del bot/política.
SLSA/Provenance: conjuntos reproducibles, firmas, attestations.
Contenedores: imágenes mínimas, rootless, drop capabilities, read-only FS.
Escáneres IaC: Terraform/Helm - Política de encriptación, puertos abiertos, reglas de red.

8) Privacidad y cumplimiento

LINDDUN-mapa de amenazas de privacidad, minimización de datos, seudonimización/anonimización.
Políticas de retención: TTL/retiro, «derecho de eliminación», auditoría de acceso a PD.
Localización: geo-restricciones, «los datos permanecen en la región».
Transparencia: registros de procesamiento, notificaciones y consentimiento.

9) Nubes y perímetros

Confianza cero: autenticación de cada solicitud, mTLS/OPA entre servicios.
Segmentación: VPC/subredes/SG, endpoints privados, control egress.
Claves/secretos: KMS, rotación, créditos cortos en CI (Federación OIDC).
Reserva/DR: backups encriptados, llaves por separado, ensayos de recuperación.

10) Equipos rojos/morados y ejercicios de tabletop

Equipo Rojo: verificación de hipótesis de amenazas, ingeniería social, operación de cadenas.
Purple Team: depuración conjunta de detalles/alertas, mejora del playbook's IR.
Tabletop: scripts «certificado caducado», «clave filtrada», «compromiso de cadena de suministro». Resultado: controles y métricas actualizados.

11) Métricas de madurez y control

Coverage:% de los servicios con threat model y DFD actuales.
MTTD/MTTR de seguridad, porcentaje de incidentes capturados por los controles.
Política pass-rate en CI, tiempo de cierre de vulnerabilidades por criticidad.
Privacidad:% de los datasets con TTL/ILM, porcentaje de accesos con justificación.
Auditoría: regularidad de la revisión del registro de riesgos (trimestral).

12) Patrones de artefactos

12. 1 Tarjeta de riesgo (ejemplo)

Risk ID: SEC-API-012
Сценарий: SSRF через изображение в профиле
STRIDE: Tampering/Info Disclosure
Актив: API / файловый прокси
Likelihood: High  Impact: High  Risk: Critical
Контроли: denylist схем, egress-прокси, URL-fetcher в изолированном рантайме,
DNS-resolv только через прокси, время/размер-лимиты, allowlist.
Владелец: team-accounts  Статус: Reduce (в работе)
Дата пересмотра: 2025-12-01

12. 2 Lista de verificación de diseño

¿Se identificaron los activos y los PII? ¿Los límites de confianza están marcados?
¿Los contornos de datos/DFD están compilados y enlazados a ADR?
¿STRIDE/LINDDUN recorridos por cada flecha DFD?
Tritment de riesgo seleccionado; ¿Hay propietarios/plazos/DoD?
¿Cómo se agregan las políticas (OPA/Kyverno/CI-gates)?
¿Se actualiza el plan de monitoreo/alertas e IR-runbook?
Privacidad: minimización, encriptación, TTL/retoque, localización?

12. 3 Política de webhooks (pseudocódigo)

python def verify_webhook(req, keys):
ts = int(req.h["X-Timestamp"])
if abs(now_utc()-ts) > 300: return 401 if not hmac_ok(req.body, ts, keys.active_or_prev(), req.h["X-Signature"]):
return 401 if replay_cache.seen(req.h["X-Event-ID"]): return 200
PoLP: в обработчике — только нужные скоупы handle(json.loads(req.body))
replay_cache.mark(req.h["X-Event-ID"])
return 200

13) Anti-patrones

Threat model «para marcar» sin DFD/invariantes.
«Super-perímetro» sin autenticación interna de servicio a servicio.
Secretos de larga vida en variables ambiente/repo.
Las políticas que no se implementan como código → se «olvidan» manualmente.
Logs con PD sin camuflaje y sin retén/TTL.
Ignora la cadena de suministro (no hay SBOM/firmas/escáneres).
Aceptación del riesgo (Accept) sin propietario y fecha de revisión.

14) Integración en procesos

RFC/ADR: cada solución significativa contiene una sección «Amenazas y controles».
Docs-as-Code: threat model, DFD, registro de riesgos en la versión junto al código.
Release gates: la liberación se bloquea cuando las políticas SAST/SCA/SBOM fallan o faltan controles de alta crítica.
Formación: playbucks para desarrolladores (secretos, firmas, PoLP), tabletop regular.

Conclusión

Threat Modeling es una práctica de ingeniería de gestión de riesgos, no un documento de un solo uso. Identificar los activos y los límites de confianza, aplicar STRIDE/LINDDUN, medir el riesgo, fijarlo en el registro e implementar los controles como código integrándolos en CI/CD y operación. Con métricas de madurez y revisiones regulares, usted convertirá la seguridad en una capacidad de arquitectura predecible - con un precio, efecto y velocidad comprensibles.