La lección anterior terminó con una frase incómoda: el análisis de vulnerabilidades encuentra puertas mal cerradas, pero no ve a nadie entrando por ellas. Si mañana alguien usa la credencial de la consultora a las 22:14, ningún escáner se enterará: el acceso es legítimo y la credencial es válida. Esta lección construye lo que falta y cumple la promesa pendiente desde 04-03, donde el análisis del incidente de 02-06 reveló que el ransomware de Nimbus no encontró ningún control detectivo en cinco de las seis funciones. Vamos a montar la telemetría, centralizarla, escribir detecciones que se disparen con lo que importa y callen con lo que no, y medir si funcionan.

1. Por qué la detección importa más que la prevención perfecta
2. La pirámide de la telemetría: qué fuentes tiene Nimbus
3. Higiene del registro: qué se guarda, cómo y durante cuánto
4. Protección de los propios registros
5. Centralización: SIEM y observabilidad
6. Detección por reglas frente a detección por comportamiento
7. El catálogo mínimo de detecciones de Nimbus
8. Escribir detecciones: Sigma, SQL y umbrales
9. La calidad de la alerta y la fatiga
10. Detección en red y en el endpoint
11. Respuesta automatizada: qué sí y qué nunca
12. Caza de amenazas y métricas de detección

La prevención falla siempre en algún punto, y no por incompetencia: falla porque el atacante elige dónde probar y tú tienes que acertar en todos los sitios a la vez. Un parche llega tarde, un empleado hace clic, un tercero sufre una brecha, una credencial se filtra. Un modelo de seguridad que solo previene es un modelo que apuesta a no fallar nunca.

La métrica que resume el fracaso o el éxito de la detección es el tiempo de permanencia (dwell time): el intervalo entre el primer acceso del atacante y el momento en que alguien se entera. Es la variable que más determina el daño, como concluyó 02-06.

Dos lecturas importan más que el resto. La primera: había siete oportunidades de detección y ninguna estaba instrumentada. La segunda, más sutil: la del día 16 sí existió y falló igualmente, porque llegó como un correo entre otros doscientos. Una señal sin destinatario, sin prioridad y sin procedimiento no es una detección: es ruido con buena intención. Reducir el dwell time de 20 días a un día no requiere un SOC de 24 horas; requiere las doce detecciones del apartado 7 y un canal donde alguien las mire.

No se detecta lo que no se registra. Antes de escribir una sola regla hay que saber qué datos existen ya —casi siempre más de los que el equipo cree— y qué permite ver cada uno.

La observación decisiva: nueve de las once fuentes ya existen o cuestan casi nada. Lo que le faltaba a Nimbus el día del incidente no era presupuesto de telemetría; era recogerla en un sitio y mirarla. Y las dos ausencias que más pesaron —logs de acceso al bucket y registro de actividad cloud revisado— son casillas de configuración, no productos.

Retomando 02-04: un log es un activo con datos personales (A-18, clasificado confidencial). Registrar de más crea una segunda base de datos sensible, peor protegida que la primera.

Un log en texto libre obliga a escribir expresiones regulares frágiles. Un log en JSON se consulta como datos:

Tres decisiones importan más que el código: el nombre del evento es estable (reserva.exportada, no una frase que cambia con cada refactorización, porque las reglas se rompen si el texto cambia); tenant_id está siempre presente, lo que permite detectar que un usuario de un cliente tocó datos de otro; y el contenido nunca entra, solo su recuento (n_registros).

Sin relojes sincronizados, la correlación es imposible. Si el servidor de la API va 40 segundos adelantado respecto al de base de datos, la secuencia «primero la petición, después la consulta» aparece invertida y la investigación construye una historia falsa. Todos los sistemas de Nimbus sincronizan por NTP, registran en UTC y añaden la zona solo en la presentación. Es gratis y es el prerrequisito de todo lo demás.

La retención se decide por coste y por obligación: Nimbus guarda 90 días en caliente (consultable en segundos, ~2 TB) y 12 meses en frío (almacenamiento barato, restaurable en horas), alineado con la retención de 12 meses de la tabla de auditoría de C-07. El criterio de fondo: si el dwell time típico ronda los 20 días, una retención de 7 días garantiza que la investigación empiece ciega.

El primer objetivo del atacante con privilegios no son los datos: es el registro que demuestra qué hizo. Es la fase de la Kill Chain que 02-06 documentó como borrado de rastros, y por eso los logs necesitan tres propiedades:

• Salir del host de inmediato. Un log que solo vive en la máquina comprometida se borra con un comando. El agente envía cada evento al colector en segundos, no por lotes nocturnos.
• Almacenarse de forma inmutable. Bucket con retención bloqueada y versionado (05-07), en cuenta separada de producción y con credenciales distintas. Es la misma lección de las copias de 04-06: si las mismas credenciales que administran producción pueden borrar el registro, no hay registro.
• Escribirse en un solo sentido. El servicio que genera logs tiene permiso de escritura, nunca de borrado ni de modificación.

Y un indicador que muchos olvidan: la ausencia de logs es una alerta. Si una fuente que emite 400 MB al día deja de emitir durante una hora, eso es una detección (D-09 del catálogo), no un fallo de monitorización que se revisa al día siguiente.

El paso que decide si el sistema sirve es la normalización en el colector: convertir usuario, user, account_name y principalId en un único campo actor.id. Sin eso, cada regla hay que escribirla cinco veces y la correlación entre fuentes no existe.

Decisión de Nimbus: Wazuh autoalojado. Cubre las once fuentes, incluye agente para los 40 portátiles y deja presupuesto. La honestidad obliga a decir lo que no cubre: nadie mirará las alertas a las 3 de la madrugada. Con 440 h/año de Lucía, el objetivo realista no es un SOC: es que las alertas críticas lleguen a un canal con guardia y que el resto se revise cada mañana.

La regla práctica: empieza por umbrales y listas, que son baratos y explicables; añade firmas para lo conocido; deja la anomalía para cuando tengas línea base y tiempo de afinado. Una detección de anomalía sin tres meses de datos limpios genera tanto ruido que se desactiva sola. Y una advertencia de fondo: las reglas detectan lo que alguien ya imaginó; por eso el apartado 12 introduce la caza de amenazas, que busca lo que no se imaginó.

Estas doce detecciones cubren las siete oportunidades perdidas del apartado 1 y se construyen sobre fuentes que ya existen. Es el entregable central de la lección.

Tres observaciones. Primera: seis son de severidad S1 y todas ellas indican compromiso en curso, no sospecha. Segunda: D-03, D-04 y D-10 habrían detectado el incidente en los días 0, 6 y 20 respectivamente —la primera lo habría cortado antes de que empezara—. Tercera: ninguna requiere comprar nada. Son consultas sobre datos que Nimbus ya genera o que se activan con una casilla.

Sigma es el formato abierto para escribir reglas de detección de forma independiente del SIEM: se escribe una vez y se convierte a Wazuh, OpenSearch o Loki. Esta es D-03, campo a campo:

Cinco campos hacen el trabajo. logsource acota dónde se aplica, y equivocarlo es la causa número uno de reglas que nunca disparan. detection define bloques con nombre que después se combinan en condition, y el patrón seleccion and not excepcion es el más útil de todos: describe lo sospechoso y resta lo legítimo. falsepositives documenta lo que ya sabes que va a saltar, para que quien reciba la alerta a las 3 de la mañana no tenga que descubrirlo solo. Y tags con la técnica ATT&CK permite medir cobertura (§12).

D-05 no es una regla de log: es una consulta sobre la tabla de auditoría append-only de C-07.

La consulta expresa una idea de negocio, no técnica: un agente de soporte legítimo atiende a un cliente cada vez. Tocar cuatro tenants en una hora no es ilegal en el modelo de permisos —el WHERE tenant_id sigue aplicándose— pero es raro, y lo raro es lo que se investiga. Es también el único tipo de detección que habría visto a un empleado descontento, un escenario que ninguna firma cubre.

Y D-04 como umbral declarativo, tal y como se define en el motor de alertas:

Fíjate en excepciones: sin ella, la copia nocturna dispararía la alerta cada noche y en dos semanas nadie miraría el canal. La excepción está acotada por ventana horaria, de modo que si svc-backup descarga 40.000 objetos a las 15:00 la alerta salta igual. Una excepción sin condición es un agujero permanente; con condición, es afinado.

La fatiga de alertas es la causa más común de fracaso de un sistema de detección, y no es un problema de las personas: es un problema de diseño. Con 200 alertas diarias de las que 195 son ruido, el cerebro aprende —correctamente— que la probabilidad de que la siguiente importe es del 2,5 %. Eso es exactamente lo que pasó el día 16 del incidente.

Cómo se afina, en orden:

1. Establecer línea base antes de alertar. Toda detección nueva arranca en modo silencioso durante dos semanas: se registra cuántas veces habría disparado y contra qué. Si son 90 al día, la regla no está lista.
2. Documentar excepciones acotadas, nunca globales: por servicio y ventana, con dueño y revisión (el svc-backup de arriba).
3. Agregar en lugar de repetir. Cien fallos de autenticación del mismo origen son una alerta con contador, no cien.
4. Enriquecer con contexto en la propia alerta: quién es el usuario, qué activo es, si hay ticket de cambio abierto. Una alerta que obliga a abrir cinco pestañas para entenderla se pospone.
5. Revisar mensualmente las que nunca disparan. Una regla que lleva un año en silencio o está perfectamente afinada o está rota, y hay que saber cuál de las dos.

Alerta y ticket no son lo mismo, y confundirlos satura el proceso: la alerta es la señal automática y puede haber cientos; el ticket es el compromiso de que una persona la investiga y la cierra con una conclusión. Nimbus abre ticket para toda S1 y S2, y agrega S3 y S4 en una revisión diaria de diez minutos. Objetivo declarado: no más de cinco alertas accionables al día, porque es lo que cabe en 440 horas anuales.

En la red, dos herramientas libres con filosofías distintas: Suricata es un IDS/IPS de firmas que inspecciona el tráfico y alerta (o bloquea, en modo IPS) ante patrones conocidos; Zeek no alerta, sino que convierte el tráfico en registros ricos —conexiones, DNS, TLS, ficheros transferidos— que alimentan detecciones propias. Para Nimbus, Zeek aporta más: el conn.log y el dns.log habrían mostrado 1,2 TB saliendo hacia un destino desconocido durante siete días. Dónde se colocan físicamente y qué se pierde cuando todo el tráfico va cifrado es materia de 05-04.

En el endpoint y en los contenedores:

La diferencia conceptual entre antivirus y EDR —firma frente a comportamiento con capacidad de respuesta— se trata en 05-06; aquí basta con la consecuencia para la detección: sin agente en el endpoint hay un punto ciego en la mitad de la plantilla que trabaja en remoto, fuera de cualquier sensor de red.

El SOAR (orquestación y respuesta automatizada) suena a producto caro, pero en una PYME empieza con tres o cuatro automatismos bien elegidos. El criterio para decidir es sencillo: ¿qué pasa si la acción se ejecuta sobre un falso positivo?

Regla de oro: automatiza lo reversible y barato de deshacer; deja a una persona lo que destruye, apaga o borra. Y toda acción automática se registra en la misma bitácora del incidente, porque el post mortem de 04-05 necesita saber qué hizo la máquina y no solo qué hizo el equipo.

La caza de amenazas (threat hunting) parte de una idea distinta a la alerta: en lugar de esperar a que salte una regla, se asume que el atacante ya está dentro y se busca activamente. No requiere herramientas nuevas, solo los datos del apartado 5 y una hipótesis concreta.

Ejemplo completo sobre Nimbus. Hipótesis, formulada a partir de ATT&CK: «Si un atacante hubiera comprometido una cuenta de la consultora (T1078.003, cuentas válidas), habría usado el acceso administrativo para enumerar la base de datos desde un origen distinto del habitual».

1. Dato a consultar: conexiones a PostgreSQL de los últimos 90 días, agrupadas por usuario, IP de origen y hora.
2. Qué se busca: pares (usuario, IP) que aparezcan pocas veces. No los más frecuentes: lo raro es la señal, porque lo habitual es, por definición, lo legítimo.
3. Resultado real de la primera caza de Lucía: tres orígenes con una sola conexión cada uno. Dos eran de Iván depurando desde casa —anotados y añadidos como excepción—. El tercero era un contenedor de preproducción (A-22) conectándose a la base de datos de producción, algo que nadie sabía que ocurría.
4. Qué se hace con el hallazgo: se corrige (separar credenciales por entorno), se convierte en detección permanente (conexión a A-01 desde una subred que no sea 10.30.10.0/24 → S2) y se registra el riesgo en 04-01.

Ese cuarto paso es el que hace rentable la caza: cada hallazgo se convierte en una detección automática, para no tener que volver a buscarlo a mano. Con dos horas al mes, Lucía puede ejecutar una hipótesis mensual.

La última es la que enlaza con 04-03 y cierra el círculo: una detección que nunca se ha probado está en estado «planificada», por muy bien escrita que esté —igual que C-08, con su ultima_verificacion: null—. Probar D-04 consiste en descargar 600 objetos de prueba del bucket y comprobar que la alerta llega al móvil de guardia en menos de cinco minutos. Cuando llegue, ese es el momento en que el runbook RB-01 de 04-05 deja de ser un documento y se convierte en un procedimiento vivo.

• Recoger todo «por si acaso». Multiplica el coste, entierra la señal y crea una segunda base de datos con información personal. Se recoge lo que responde a una detección concreta o a una obligación.
• Alertar sin línea base. Toda regla nueva pasa dos semanas en modo silencioso. Publicarla directamente es la vía rápida a que nadie mire el canal.
• Dejar los logs solo en el host que los genera. El atacante los borra en el minuto uno. Salida inmediata, cuenta separada y solo escritura.
• No sincronizar los relojes. Sin NTP y UTC, la línea de tiempo del incidente es ficción y la correlación entre fuentes no funciona.
• Confundir alerta con ticket. Cientos de alertas y cero tickets significa que nadie ha concluido nada.
• Excepciones globales y permanentes. «Excluir la cuenta de servicio» es un agujero; «excluirla solo entre las 02:00 y las 04:00» es afinado.
• Automatizar acciones destructivas. Apagar, borrar o restaurar sin persona convierte un falso positivo en un incidente propio y destruye evidencia.
• Consejo: empieza por seis detecciones, no por doce. D-03, D-04, D-06, D-08, D-10 y D-01 cubren el incidente completo de 02-06 y se montan en una semana de trabajo.
• Consejo: prueba cada S1 antes de confiar en ella. Una regla sin prueba deliberada no es un control implantado, y la prueba tarda diez minutos.

En el incidente de 02-06 hubo exfiltración de 1,2 TB durante siete días (días 6-15) sin que nada saltara. Diseña la detección que lo habría visto:

1. Indica fuente, lógica y umbral concreto, justificando el número elegido.
2. Escribe la regla en formato Sigma con al menos un bloque de excepción.
3. Explica cómo la probarías sin exfiltrar datos reales y qué evidencia guardarías.

Nimbus lleva tres meses con Wazuh y este es el resumen del último mes:

Identifica al menos cinco problemas y propón una corrección concreta para cada uno.

Rubén, de soporte, va a dejar la empresa dentro de un mes y ha pedido acceso a informes que no usaba antes. Marta quiere saber si hay motivo de preocupación, sin acusar a nadie y sin vulnerar sus derechos.

1. Formula la hipótesis de caza y la técnica ATT&CK asociada.
2. Indica qué datos consultarías y con qué consulta, usando la tabla de auditoría de C-07.
3. Explica qué harías con tres resultados posibles: nada anómalo, actividad anómala explicable y actividad claramente indebida. Menciona qué límites legales y laborales tiene esta investigación.

Ejercicio 1

(1) Fuente y lógica. La exfiltración de 1,2 TB tocó dos fuentes: los logs de acceso al bucket A-02 (descargas de adjuntos) y el volumen de salida de la cuenta cloud. La mejor detección combina ambas, pero la más barata y precisa es la primera. Lógica: número de objetos distintos descargados por un mismo principal en una ventana corta. Por qué objetos y no bytes: el volumen en bytes lo distorsiona un solo adjunto grande legítimo, mientras que descargar 500 ficheros distintos de clientes distintos no tiene explicación operativa.

Umbral: 500 objetos en 10 minutos. Justificación con datos, no con intuición: el mayor uso legítimo observado es la copia nocturna (svc-backup, ~40.000 objetos entre las 02:00 y las 04:00) y, tras ella, un usuario de soporte llega como mucho a 30 objetos en diez minutos. Un umbral de 500 deja un factor 16 de margen sobre el uso humano máximo y aun así habría disparado el día 6, en las primeras horas de la exfiltración.

(2) Regla Sigma:

(3) Prueba sin datos reales. Se genera un tenant de prueba con 600 adjuntos ficticios y se descargan en bloque con una credencial de prueba, en horario laboral y avisando a la guardia de que es un simulacro. Se cronometra el tiempo desde la primera descarga hasta la llegada al móvil. Evidencia a guardar: la marca temporal del inicio, la de la alerta, la captura de la notificación y el ultima_verificacion actualizado en la ficha del control, que es exactamente lo que 04-03 exige y lo que a C-08 le faltaba.

Ejercicio 2

Ejercicio 3

(1) Hipótesis: «Si Rubén estuviera preparando la salida con datos de clientes, su patrón de acceso mostraría amplitud inusual (muchos tenants) y volumen inusual (exportaciones grandes) respecto a su propia línea base de los últimos seis meses». Técnica ATT&CK: T1213 / T1530, recolección desde repositorios de información. Nótese que la hipótesis se formula contra el comportamiento, no contra la persona, y compara a Rubén consigo mismo: es lo que la hace defendible.

(2) Consulta sobre la tabla append-only de C-07, comparando dos ventanas:

Se busca un cambio de tendencia en las últimas semanas frente a su media histórica, no un valor absoluto. Conviene comparar además con la línea base del resto del equipo de soporte en el mismo periodo, porque un pico general puede deberse a una campaña o a una migración.

(3) Los tres desenlaces. Si no hay nada anómalo, el ejercicio termina, se documenta que se revisó y se cierra sin dejar rastro en el expediente de la persona; el resultado negativo es tan valioso como el positivo. Si hay actividad anómala explicable —los informes nuevos coinciden con una tarea que Marta le asignó—, se documenta la explicación y, si el acceso ya no es necesario, se retira: es un hallazgo de gestión de accesos (04-02), no un incidente. Si la actividad es claramente indebida (exportaciones masivas fuera de horario de clientes que no atiende), se activa el plan de 04-05 como incidente de seguridad, se preservan evidencias con su cadena de custodia y la conversación pasa a RRHH y a asesoría legal antes que a la técnica.

Límites que hay que respetar en los tres casos. La monitorización debe estar previamente informada en la política de uso aceptable (POL-04) y en la información laboral al empleado; debe ser proporcionada —revisar registros de acceso a datos de clientes es proporcionado; leer su correo personal o instalar vigilancia encubierta, no—; y debe limitarse a datos de actividad profesional. En España, el Estatuto de los Trabajadores y la normativa de protección de datos exigen información previa y proporcionalidad, y una investigación bien fundada puede quedar invalidada si el control no estaba comunicado. Se desarrolla en 06-03 y 06-06. (Nota: ante una investigación con consecuencias disciplinarias, la validación jurídica previa no es opcional.)

Has construido los controles detectivos que a Nimbus le faltaban y que 04-03 señaló como su mayor hueco. Sabes por qué la prevención falla siempre en algún punto y por qué el tiempo de permanencia es la métrica que determina el daño: en el incidente de 02-06 hubo siete oportunidades de detección sin instrumentar y una octava —la alerta de coste del día 16— que existió y falló igualmente porque llegó como un correo entre doscientos. Una señal sin destinatario, sin prioridad y sin procedimiento no es una detección.

Conoces las once fuentes de telemetría de Nimbus y el dato que cambia la conversación: nueve ya existen o cuestan casi nada, así que lo que faltaba no era presupuesto sino recogerlas y mirarlas. Sabes qué registrar y qué no registrar jamás, cómo emitir logs estructurados en JSON con request_id, tenant_id y nombres de evento estables, por qué sin NTP y UTC la correlación es ficción, y cómo fijar retención (90 días en caliente, 12 meses en frío) sabiendo que una retención de 7 días garantiza investigaciones ciegas. Sabes proteger los propios registros —salida inmediata del host, almacenamiento inmutable en cuenta separada, solo escritura— y que la ausencia de logs es en sí misma una alerta.

Distingues SIEM de observabilidad, conoces la arquitectura agente → colector → almacén → detección → alerta con la normalización como paso que decide si el sistema sirve, y has elegido Wazuh autoalojado para Nimbus con una limitación declarada: nadie mirará a las 3 de la madrugada. Sabes cuándo usar firmas, umbrales, listas o anomalía, y por qué empezar por lo barato y explicable. Te llevas el entregable central: el catálogo de doce detecciones con fuente, lógica, severidad y acción, del que seis son S1 y tres habrían detectado el incidente en los días 0, 6 y 20. Sabes escribirlas en Sigma campo a campo con el patrón seleccion and not excepcion, en SQL sobre la auditoría append-only para capturar el abuso interno que ninguna firma ve, y como umbral declarativo con excepciones acotadas por ventana horaria. Sabes combatir la fatiga de alertas con línea base silenciosa, agregación, enriquecimiento y revisión de las reglas mudas, distinguir alerta de ticket, qué aportan Zeek, Suricata, Wazuh, osquery y Falco, qué automatizar (lo reversible) y qué nunca (lo que apaga, borra o destruye evidencia). Y sabes cazar amenazas partiendo de una hipótesis ATT&CK, con el hallazgo real de un contenedor de preproducción conectado a la base de datos de producción y la regla que hace rentable el ejercicio: cada hallazgo se convierte en detección permanente.

Ahora Nimbus encuentra sus vulnerabilidades (05-01) y ve al atacante moverse (05-02). Queda la pregunta que ninguna de las dos responde: ¿aguantaría de verdad? Un escáner comprueba versiones y una detección observa lo que ocurre, pero ninguno intenta encadenar tres debilidades pequeñas hasta convertirlas en un compromiso real, que es exactamente lo que hace un atacante. En Pruebas de Penetración (05-03) entra en escena esa figura, con la autorización escrita por delante: qué es un pentest y en qué se diferencia de un escaneo, cómo se acuerdan el alcance y las reglas de enfrentamiento, qué ocurre en cada fase, qué encontró una prueba autorizada sobre el entorno de preproducción de Nimbus y cómo se corrigió cada hallazgo.