Objetivos de seguridad y modelos de amenaza en criptografía aplicada

Qué problema estás resolviendo (y qué NO) con criptografía aplicada

La criptografía aplicada no es “poner TLS” o “cifrar una base de datos”; es seleccionar propiedades de seguridad concretas para un flujo de datos y un adversario concreto. Antes de elegir algoritmos o librerías, define el objetivo de seguridad en términos verificables.

Propiedades típicas (definiciones operativas)

• Confidencialidad: un tercero no autorizado no puede leer el contenido. Se aplica a datos en tránsito (red) y en reposo (disco/backup).

• Integridad: un tercero no puede modificar datos sin ser detectado. Incluye protección contra cambios accidentales y maliciosos.

• Autenticación: puedes verificar quién es la otra parte (usuario, servicio, dispositivo) o el origen de un mensaje.

• No repudio: una parte no puede negar haber realizado una acción (normalmente asociado a firmas digitales y a requisitos legales/procesales).

  Continúa en nuestra aplicación.

  • Escuche el audio con la pantalla apagada.
  • Obtenga un certificado al finalizar.
  • ¡Más de 5000 cursos para que explores!

  O continúa leyendo más abajo...

  

  Descargar la aplicación

• Secreto hacia adelante (Forward Secrecy): si se compromete una clave a largo plazo en el futuro, no se descifran sesiones pasadas capturadas.

• Protección contra replay: un atacante no puede reutilizar mensajes válidos antiguos para repetir una operación (p. ej., “cobrar 100€” dos veces).

• Protección en tránsito: evita lectura/modificación durante el transporte (red, proxies, Wi‑Fi, ISP).

• Protección en reposo: evita lectura/modificación cuando el dato está almacenado (discos, snapshots, backups, logs, colas persistentes).

Ejemplos rápidos de “objetivo” vs “medida”

Traducir requisitos de negocio y regulatorios a objetivos técnicos medibles

Los requisitos suelen venir como frases ambiguas: “datos seguros”, “cumplir normativa”, “evitar fraude”. El trabajo práctico es convertirlos en objetivos técnicos con alcance, métricas y criterios de aceptación.

Plantilla de traducción (útil para tickets y revisiones)

• Activo: ¿qué dato o acción protegemos? (p. ej., “token de sesión”, “número de tarjeta”, “orden de transferencia”, “modelo ML”).

• Flujo: ¿de dónde a dónde viaja? (móvil → API → microservicio → DB → cola → analítica).

• Propiedad: confidencialidad/integridad/autenticación/no repudio/FS/anti-replay.

• Adversario: ¿quién ataca y con qué capacidades?

• Control criptográfico: mecanismo concreto (p. ej., “mTLS entre servicios”, “firma de webhook”, “cifrado de campo”).

• Métrica/criterio: ¿cómo se prueba? (tests, auditoría, escaneo, evidencias).

• Alcance y exclusiones: qué queda fuera (p. ej., “si el endpoint está comprometido, no se garantiza confidencialidad”).

Ejemplo: requisito regulatorio → objetivo técnico

Requisito: “Los datos personales deben estar protegidos contra acceso no autorizado y alteración.”

• Activo: PII en perfiles y eventos.

• Flujos: navegador/móvil → API; API → DB; DB → backups; API → logs/observabilidad.

• Objetivos técnicos:

  • Confidencialidad en tránsito: todo tráfico externo e interno sensible usa TLS; no se permite HTTP plano.

  • Confidencialidad en reposo: cifrado en DB/backups; cifrado de campos para PII de alto impacto.

  • Integridad: eventos críticos firmados o con MAC; controles de integridad en colas.

• Criterios de aceptación:

  • Escaneo automatizado: no hay endpoints HTTP; TLS con suites modernas; certificados rotados.

  • Pruebas de caja negra: modificar payload de evento produce rechazo verificable.

  • Evidencia operativa: rotación de claves, control de acceso a KMS, auditoría de accesos.

Marco práctico de modelado de amenazas para criptografía aplicada

El objetivo es identificar qué adversarios pueden interactuar con tus datos y qué pueden hacer (leer, modificar, reinyectar, interponerse, comprometer endpoints). Con eso eliges propiedades criptográficas y dónde aplicarlas.

Paso a paso (rápido y repetible)

1. Dibuja el flujo de datos: componentes (cliente, CDN/WAF, API gateway, servicios, colas, DB, terceros) y límites de confianza (internet, VPC, cuenta cloud, dispositivo del usuario).

2. Lista activos y acciones: datos (PII, credenciales, tokens, claves, secretos) y acciones (pago, cambio de email, alta de beneficiario).

3. Define adversarios: externo en red, usuario malicioso autenticado, insider, proveedor tercero, malware en endpoint, atacante con acceso a nube.

4. Asigna capacidades (por flujo): lectura, modificación, replay, MITM, compromiso de endpoint.

5. Identifica superficies de ataque: puntos donde el adversario puede tocar el dato (headers, parámetros, storage local, logs, colas, webhooks).

6. Mapea capacidades → propiedades: por cada riesgo, decide qué propiedad criptográfica lo mitiga y dónde se verifica (cliente, gateway, servicio, DB).

7. Define pruebas: casos de ataque reproducibles (replay, manipulación, downgrade, token theft) y evidencias (logs, métricas, auditoría).

Adversarios y capacidades: guía de clasificación

Superficies de ataque típicas por tipo de sistema

Aplicaciones web

• Cookies/sesiones: robo o fijación de sesión; replay de requests sensibles.

• Formularios y APIs: modificación de parámetros (p. ej., cambiar importe); reenvío de POST.

• Integraciones: webhooks falsos; callbacks sin firma.

• Logs: PII/secretos en logs; correlación de identificadores.

Aplicaciones móviles

• Almacenamiento local: tokens en almacenamiento inseguro; backups del dispositivo.

• Redes hostiles: MITM con certificados instalados por el usuario/MDM.

• Ingeniería inversa: extracción de claves embebidas; manipulación de lógica cliente.

APIs públicas y B2B

• Autenticación de cliente: credenciales filtradas; suplantación.

• Integridad del mensaje: proxies que alteran contenido; necesidad de firma a nivel aplicación.

• Replay: reenvío de llamadas con efectos (pagos, altas, cambios).

Microservicios

• Tráfico este-oeste: MITM interno, movimiento lateral.

• Colas/eventos: manipulación de mensajes; reordenamiento; duplicados.

• Secretos: proliferación de claves; rotación difícil.

Nube (IaaS/PaaS/SaaS)

• IAM: credenciales de máquina filtradas; permisos excesivos.

• Snapshots/backups: exfiltración de volúmenes; restauraciones no controladas.

• Servicios gestionados: límites de control sobre claves; necesidad de BYOK/HYOK según riesgo.

Guía de toma de decisiones: propiedades necesarias según el flujo de datos

Usa esta guía como checklist por cada flujo. La idea es decidir qué propiedad necesitas y dónde se aplica/valida (cliente, gateway, servicio, almacenamiento), en función de las capacidades del adversario.

1) Clasifica el flujo

• Tipo A: lectura sin efectos (p. ej., consultar perfil).

• Tipo B: escritura con efectos (p. ej., cambiar email, crear orden).

• Tipo C: transacción crítica (p. ej., pago, transferencia, alta de beneficiario).

• Tipo D: integración asíncrona (eventos, colas, webhooks).

2) Decide propiedades mínimas por tipo

3) Mapa rápido de capacidades del adversario → propiedad

• Puede leer tráfico → confidencialidad en tránsito (y a veces en reposo si captura en puntos intermedios).

• Puede modificar tráfico → integridad (MAC/firma) y autenticación del origen; valida en el componente que toma la decisión.

• Puede hacer replay → nonces, timestamps, idempotency keys, números de secuencia; deduplicación en el punto de efecto.

• Puede hacer MITM → autenticación del canal (validación estricta de certificados, mTLS) y, si hay proxies/terminación intermedia, integridad end-to-end a nivel aplicación.

• Puede comprometer un endpoint → asume pérdida de confidencialidad en ese extremo; reduce impacto con mínimos privilegios, rotación, tokens de corta vida, segmentación y controles de detección.

4) Checklist de implementación verificable (por flujo)

• ¿Dónde termina la confianza del canal? Si TLS termina en un proxy/gateway, ¿necesitas integridad end-to-end hasta el servicio final?

• ¿Qué dato exacto se firma o protege? Define un “canonical form” del mensaje (campos, orden, encoding) para evitar ambigüedades.

• ¿Qué evita el replay? Define ventana temporal, almacenamiento de nonces, o idempotencia por clave y recurso.

• ¿Qué pasa con logs y trazas? Decide qué se redacta/hashea; evita que secretos aparezcan en observabilidad.

• ¿Cómo se gestionan claves? Propietario, rotación, permisos, auditoría; evita claves compartidas entre entornos.

• ¿Cómo lo pruebas? Casos: MITM simulado, modificación de payload, replay de requests, restauración de backup, acceso a snapshot.

Ejemplo aplicado: webhook de proveedor (Tipo D)

Flujo: proveedor → tu endpoint /webhook → procesamiento interno.

• Adversario: atacante externo que puede enviar requests falsos o reinyectar requests capturados.

• Objetivos: autenticación del emisor + integridad del payload + anti-replay.

• Decisiones técnicas:

  • Verificar firma del webhook con clave pública/secret compartido del proveedor.

  • Incluir y validar timestamp y nonce (o event_id) para deduplicación.

  • Rechazar si el timestamp está fuera de ventana o si el event_id ya fue procesado.

Checklist de validación del webhook (orden recomendado): 1) Validar esquema y tamaño del body 2) Validar timestamp (ventana) 3) Verificar firma sobre el body canónico 4) Validar deduplicación por event_id/nonce 5) Procesar con idempotencia en la operación final