Seguridad en operación: logging, detección y respuesta

La seguridad no termina en el despliegue

Las secciones anteriores de este capítulo buscan prevenir los ataques. Ninguna prevención es perfecta, así que las organizaciones maduras también diseñan partiendo de que se producirá una brecha: quieren detectarla rápido, limitar sus daños, recuperarse limpiamente y aprender de ella. El Capítulo 2 describió las tácticas de seguridad como resistir los ataques, detectarlos, reaccionar ante ellos y recuperarse de ellos, y mostró cómo escribir escenarios de seguridad con respuestas medibles como una credencial filtrada se detecta y se revoca en un plazo de 15 minutos. Esta sección trata de la arquitectura y las prácticas que hacen posibles esas respuestas.

Gran parte de ello se apoya en los fundamentos operativos de la observabilidad y la gestión de incidentes del Capítulo 9. La diferencia es el adversario: un disco que falla no borra su rastro, no elimina sus logs ni vuelve la semana siguiente por una puerta que dejó abierta.

Logging de seguridad: qué registrar y qué no registrar nunca

Los logs de seguridad existen para responder, a posteriori, quién hizo qué, sobre qué recurso, cuándo, desde dónde y con qué resultado. La OWASP Logging Cheat Sheet es la referencia estándar para los profesionales. Recomienda registrar eventos como los inicios de sesión correctos y fallidos, los fallos de autorización, los fallos de gestión de sesiones, los fallos de validación de entradas, los errores de la aplicación, las funciones de alto riesgo, como las acciones administrativas y las exportaciones de datos, y el uso de los propios controles de seguridad. Cada evento debería incluir cuándo (una marca de tiempo sincronizada), dónde (aplicación, servicio, host, entorno), quién (la identidad autenticada, la dirección de origen) y qué (la acción, el objeto, el resultado y el motivo).

Igual de importante es lo que debe quedar fuera. Los logs se copian mucho, se conservan durante mucho tiempo y los leen muchas personas y herramientas, así que son un lugar predilecto por el que se filtran secretos y datos personales. Nunca registres contraseñas, identificadores de sesión ni tokens de acceso (registra un hash o un ID de clave si necesitas correlacionar), claves de cifrado ni cadenas de conexión, datos de tarjetas de pago ni datos personales de categorías especiales. Trata los datos de los logs como datos personales cuando identifiquen a personas, y aplica las reglas de minimización y conservación de la Sección 8.7. La ocultación de datos sensibles se aplica mejor de forma centralizada en el pipeline de logs además de en el código, porque una sola instrucción de depuración olvidada puede deshacerla.

{
  "ts": "2026-10-21T19:42:07.318Z",
  "event": "authz.denied",
  "service": "orders",
  "env": "prod",
  "actor": {"type": "user", "id": "cust_4411", "session": "sha256:7c1e..."},
  "client": {"ip": "203.0.113.24", "ua_family": "iOS app 7.3"},
  "action": "GET /orders/81723",
  "resource_owner": "cust_9902",
  "reason": "not_owner",
  "trace_id": "4bf92f3577b34da6a3ce929d0e0e4736"
}

Los logs también deben protegerse de los atacantes, cuyo primer paso tras conseguir acceso suele ser borrar las pruebas. Envía los logs de seguridad sin demora a una cuenta o servicio separado que las propias credenciales de la aplicación no puedan modificar; almacénalos con conservación de escritura única; restringe y registra el acceso a ellos; y mantén los relojes sincronizados para que los eventos de distintos sistemas cuadren. Trata el contenido de los logs como una entrada no confiable: un atacante que pueda introducir un salto de línea en un campo registrado puede falsificar entradas (inyección en logs, log injection), así que codifica o rechaza los caracteres de control, y recuerda que Log4Shell se desencadenaba al registrar texto controlado por el atacante.

Pistas de auditoría

Una pista de auditoría es un tipo de log más acotado y más sólido: un registro completo, cronológico y a prueba de manipulaciones de acciones definidas, que se conserva para establecer la rendición de cuentas. Los logs de depuración se muestrean, se rotan y se cambian cuando les parece a los desarrolladores; una pista de auditoría debe ser completa dentro de su alcance (cada reembolso, cada cambio de rol, cada acceso al expediente de soporte de un cliente), inmutable, atribuible a una identidad autenticada y conservada durante un periodo definido. Las normativas y los estándares a menudo la exigen; PCI DSS, por ejemplo, exige conservar el historial de logs de auditoría durante al menos doce meses, con los tres meses más recientes disponibles de inmediato para su análisis.

Desde el punto de vista arquitectónico, diseña la pista de auditoría como un producto del dominio, no como un subproducto del logging. Emite los eventos de auditoría desde el servicio propietario de la acción, en el momento en que la acción se confirma (la bandeja de salida transaccional garantiza que ocurran ambas cosas o ninguna), hacia un almacén de solo anexión con acceso de escritura restringido. La evidencia de manipulación puede añadirse mediante el encadenamiento de hashes, en el que cada registro incluye un hash del anterior, o anclando periódicamente un resumen firmado en otro lugar. Los sistemas con event sourcing obtienen gran parte de esto gratis, como mostró la Sección 7.5. Los logs de auditoría del plano de control de los proveedores de nube, que registran cada llamada a la API hecha sobre la cuenta en la nube, forman parte del mismo panorama y deben activarse en todas las cuentas y regiones.

Detección: SIEM, reglas y automatización de la respuesta

Un sistema de gestión de información y eventos de seguridad (SIEM) recoge la telemetría de seguridad de toda la infraestructura, la normaliza, correlaciona los eventos y genera alertas cuando se cumplen los patrones de las reglas de detección: muchos inicios de sesión fallidos seguidos de uno correcto, una cuenta de servicio usada desde un país nuevo, un rol al que se conceden derechos de administrador fuera de una ventana de cambios, una exportación grande a las tres de la madrugada. Las fuentes típicas son el API gateway, los eventos de seguridad de las aplicaciones, el proveedor de identidad, los logs de auditoría de la nube, los logs de auditoría de Kubernetes y los agentes de detección y respuesta en endpoints (EDR) de los portátiles y servidores del personal.

Una buena detección se diseña, no se compra. Deriva las reglas del modelo de amenazas y de MITRE ATT&CK, una base de conocimiento pública de las tácticas y técnicas de atacantes reales que MITRE mantiene desde 2015; escríbelas como código en un formato compartido como Sigma, versiónalas y pruébalas simulando el ataque que deben detectar. Mide la calidad de las alertas: una regla que salta cincuenta veces al día y siempre resulta inofensiva enseña a la gente a ignorarla, y la fatiga de alertas es la forma en que se pasan por alto los ataques reales. Ayudan las trampas baratas y de señal alta: los honeytokens, como una clave de acceso falsa o un registro de cliente falso que ningún proceso legítimo toca nunca, casi no producen falsas alarmas. Después, las herramientas de orquestación, automatización y respuesta de seguridad (SOAR) ejecutan playbooks para las alertas bien conocidas, como deshabilitar un usuario, revocar una clave o aislar un contenedor, para que las personas se ocupen de las decisiones que requieren criterio.

La ingesta del SIEM suele cobrarse por volumen, lo que tienta a los equipos a descartar logs. Un diseño por niveles ayuda: los eventos de seguridad de alto valor van al SIEM para la detección en tiempo real; los logs voluminosos van a un almacenamiento de escritura única más barato, donde pueden consultarse durante una investigación.

Gestión de vulnerabilidades

Cada día se publican nuevas vulnerabilidades en el software que ejecutas. Un identificador CVE (Common Vulnerabilities and Exposures), como CVE-2021-44228, da a cada vulnerabilidad conocida públicamente un nombre único; el programa, que MITRE inició en 1999, asigna identificadores a través de cientos de autoridades de numeración CVE (CVE Numbering Authorities), entre ellas grandes fabricantes y fundaciones de código abierto. La National Vulnerability Database de EE. UU. añade análisis como los identificadores de los productos afectados y las puntuaciones, aunque un retraso acumulado en ese enriquecimiento desde 2024, y un breve susto en abril de 2025, cuando estuvo a punto de vencer el contrato que financia el programa CVE, mostraron el riesgo de depender de una sola fuente; la mayoría de las organizaciones combinan ahora varias fuentes, entre ellas la base de datos de avisos de GitHub y la base de datos de código abierto OSV.

CVSS (el Common Vulnerability Scoring System, mantenido por FIRST; la versión 4.0 se publicó en noviembre de 2023) califica la gravedad de 0 a 10, con los niveles baja (0.1 a 3.9), media (4.0 a 6.9), alta (7.0 a 8.9) y crítica (9.0 a 10.0). La puntuación base publicada describe la vulnerabilidad en general; las métricas de amenaza y de entorno de la versión 4.0 la ajustan según la actividad de explotación y según tu propio entorno. Una puntuación base no es una medida de tu riesgo. Dos señales mejoran considerablemente la priorización: el Exploit Prediction Scoring System (EPSS, también de FIRST), que estima la probabilidad de que una vulnerabilidad se explote en los próximos 30 días, y el catálogo Known Exploited Vulnerabilities (KEV) de la Cybersecurity and Infrastructure Security Agency de EE. UU., que enumera las vulnerabilidades con pruebas de explotación real. Combínalas con la alcanzabilidad (¿se usa la función vulnerable?) y la exposición (¿el servicio está expuesto a internet?), y la mayoría de los cientos de hallazgos de un escáner pasan a la cola rutinaria, mientras que un puñado exige actuar hoy.

Acuerda de antemano los plazos de corrección, para que cada hallazgo no se convierta en una negociación, y mide el tiempo de corrección. Las cifras siguientes son ilustraciones típicas, no un estándar; los entornos regulados pueden imponer las suyas; por ejemplo, PCI DSS exige instalar los parches de seguridad críticos en el plazo de un mes desde su publicación.

Pruebas de penetración, bug bounties y divulgación

Una prueba de penetración es un intento autorizado y acotado en el tiempo, realizado por especialistas, de entrar en un sistema, idealmente conociendo su arquitectura y con un alcance acordado por escrito. Encuentra tipos de problemas que los escáneres no detectan, como la autorización a nivel de objeto rota o el abuso de la lógica de negocio (canjear el mismo vale dos veces mediante una condición de carrera). Encarga una antes de un lanzamiento importante, después de un cambio arquitectónico significativo y de forma periódica; un ejercicio de red team va más allá y pone a prueba la detección y la respuesta simulando a un adversario real durante semanas.

Los investigadores externos también encontrarán problemas, y necesitan una forma segura de comunicarlos. Una política de divulgación de vulnerabilidades indica cómo informar, qué pruebas están permitidas y que la investigación de buena fe no recibirá amenazas legales; un archivo security.txt en /.well-known/security.txt (RFC 9116, 2022) indica a los investigadores adónde enviar los informes. Un bug bounty añade un pago por los hallazgos válidos, a menudo a través de una plataforma que clasifica los envíos. ISO/IEC 29147 (divulgación) e ISO/IEC 30111 (gestión) describen los procesos, y el Reglamento de Ciberresiliencia (Cyber Resilience Act) exige a los fabricantes de productos incluidos en su ámbito tener una política de divulgación coordinada de vulnerabilidades. Un bug bounty no sustituye al trabajo interno de seguridad: si se lanza sobre un sistema sin probar, suele producir una avalancha de informes que el equipo no puede gestionar.

Respuesta a incidentes

La respuesta a incidentes es la gestión organizada de un incidente de seguridad, desde la detección hasta la recuperación y el aprendizaje. Durante más de una década, la referencia estándar fue NIST SP 800-61 Revisión 2 (2012), con su ciclo de vida de cuatro fases: preparación; detección y análisis; contención, erradicación y recuperación; y actividad posterior al incidente. La Revisión 3, publicada en abril de 2025 como Incident Response Recommendations and Considerations for Cybersecurity Risk Management: A CSF 2.0 Community Profile, sustituye ese ciclo de vida por las seis funciones del NIST Cybersecurity Framework 2.0. Gobernar, Identificar y Proteger son una preparación continua que hace los incidentes menos probables y la respuesta más eficaz; Detectar, Responder y Recuperar son la respuesta propiamente dicha; y las lecciones aprendidas alimentan la mejora de todas ellas en lugar de ser una fase final.

En la práctica, una buena respuesta necesita roles con nombre (un coordinador del incidente que coordina y decide, responsables técnicos que investigan y actúan, un responsable de comunicación, un escriba que lleva la cronología, y acceso rápido a la asesoría jurídica y al delegado de protección de datos), niveles de gravedad que determinen a quién se despierta y un canal fuera de banda, porque un atacante que esté dentro de tu sistema de correo electrónico o de chat puede leer la respuesta. La contención es un compromiso: cortar el paso a un atacante rápidamente limita los daños, pero puede destruir pruebas y alertarlo, así que conserva las pruebas (snapshots, logs, capturas de memoria) antes de reconstruir, y asegúrate de haber encontrado todos sus puntos de apoyo antes de anunciar que se ha ido. Después, una revisión sin culpas se pregunta cómo permitieron el incidente el sistema y sus procesos, y produce acciones arquitectónicas.

Resiliencia frente al ransomware

El ransomware cifra los sistemas de una organización y exige un pago a cambio de la clave; la mayoría de los grupos ahora también roban antes los datos y amenazan con publicarlos. Las defensas arquitectónicas son las de todo este capítulo (MFA, mínimo privilegio, segmentación, parches, detección), pero la recuperación depende sobre todo de una cosa: copias de seguridad que el atacante no pueda alcanzar. Los atacantes con derechos de administrador buscan primero las copias de seguridad y las eliminan o las cifran.

Conserva al menos una copia de los datos críticos inmutable o fuera de línea: almacenamiento de objetos con bloqueos de conservación de escritura única que ni siquiera un administrador puede acortar, o soportes desconectados físicamente de la red. Pon las copias de seguridad en una cuenta o tenencia separada, con credenciales y MFA propias, para que comprometer las identidades de producción no llegue hasta ellas. La regla tradicional 3-2-1 (tres copias, en dos tipos de soporte, una fuera de las instalaciones) es una base razonable. Sobre todo, prueba las restauraciones con regularidad frente al RTO y el RPO que haya acordado el negocio, incluido el orden de recuperación: los servicios de identidad y el DNS van primero, porque sin ellos no se puede reconstruir nada más. En 2017, la naviera Maersk reconstruyó su red global después de que el malware NotPetya destruyera sus controladores de dominio de Windows; la recuperación dependió del único controlador de dominio que sobrevivió, en Ghana, porque un corte de electricidad lo había dejado desconectado durante el ataque.

Violaciones de datos personales y plazos de notificación

Una violación de datos personales es, según el artículo 4(12) del RGPD, una violación de la seguridad que ocasione la destrucción, pérdida o alteración accidental o ilícita de datos personales, o la comunicación o el acceso no autorizados a ellos. Es más amplia que el robo: un ataque de ransomware que deja los datos indisponibles, o un correo electrónico enviado a los destinatarios equivocados, puede serlo. Según el artículo 33, el responsable debe notificarla a la autoridad de control sin dilación indebida y, si es posible, en un plazo de 72 horas desde que tenga constancia de ella, a menos que sea improbable que constituya un riesgo para los derechos y libertades de las personas; las notificaciones posteriores deben indicar los motivos del retraso. Según el artículo 34, el responsable también debe comunicarla sin dilación indebida a las personas afectadas si es probable que entrañe un alto riesgo para ellas. El artículo 33(5) exige documentar todas las violaciones, se notifiquen o no. El UK GDPR tiene las mismas normas, con las notificaciones dirigidas a la Information Commissioner's Office.

Puede haber otros regímenes en paralelo, con sus propios plazos, destinatarios y umbrales, y los contratos suelen añadir obligaciones frente a clientes y socios. La tabla resume los principales plazos de la UE y del Reino Unido. La propuesta Digital Omnibus de la Comisión Europea de noviembre de 2025 ampliaría el plazo del RGPD a 96 horas y limitaría la notificación a la autoridad a las violaciones de alto riesgo, pero en el momento de redactar esto no se ha adoptado y se aplica la regla de las 72 horas.

La lección arquitectónica es que un plazo contado en horas solo puede cumplirse si los sistemas pueden responder, rápido y con pruebas, qué datos se vieron afectados, de quién eran y si realmente se accedió a ellos. Eso requiere el mapa de datos de la Sección 8.7, logs de acceso a datos en los almacenes de datos personales y un cifrado que pueda hacer ininteligible una copia filtrada. Como en el resto de este capítulo, esto es información sobre cómo afecta la ley a los sistemas, no asesoramiento jurídico; la decisión de notificar corresponde al responsable, asesorado por su delegado de protección de datos (DPD) y sus abogados.

Runbooks

Un runbook (manual de operaciones) es un procedimiento escrito y probado para una situación concreta: revocar y rotar una credencial filtrada, aislar un contenedor comprometido, restaurar la base de datos de pedidos a partir de una copia de seguridad inmutable, responder a una sospecha de violación de datos personales. Un buen runbook indica su desencadenante, las personas a las que hay que implicar, los pasos y comandos exactos, cómo verificar que cada paso ha funcionado, cómo deshacerlo y qué pruebas conservar. Los runbooks son código en espíritu: guárdalos en el control de versiones junto a los sistemas que describen, automatiza las partes mecánicas y ensáyalos en game days y en ejercicios de simulación de mesa (tabletop), porque un procedimiento que nunca se ha ejecutado suele fallar en el tercer paso. Cada regla de detección debería enlazar con el runbook de su alerta.

La cronología muestra por qué la operación forma parte de la arquitectura. Cada paso que salió bien dependió de una decisión de diseño tomada meses antes: la detección de secretos y los logs de auditoría alimentando el SIEM, los logs de acceso a nivel de objeto en el bucket de exportaciones, un mapa de datos que indicó al DPD de quién eran los datos que contenía, y un diseño de identidades que permitió reconstruir el rol de despliegue sin claves de larga duración. Cada paso que salió mal (que existiera siquiera una clave de larga duración, un bucket de exportaciones de clientes que ya nadie necesitaba) fue también una decisión arquitectónica.