Curso completo ciberseguridad gratis Controles CIS. Control 8.8

Estimados amigos de Inseguros !!!

Seguimos con el control 8 de los CIS, gestión de logs, y hoy toca el 8.8: recopilar y alertar sobre eventos relevantes. Y aquí es donde el logging deja de ser “almacenamiento” y se convierte en “detección”.

Porque puedes tener un data lake precioso, petabytes de logs, retención infinita… y si no tienes alertas útiles, no te enteras de nada. O peor: te enteras tarde.

El 8.8 va de una idea muy concreta: define qué eventos son relevantes, recógelos bien, y dispara alertas cuando ocurran. No “cuando te apetezca”. En tiempo razonable. Con responsable. Con respuesta.

El problema típico: o no alertas de nada, o alertas de todo

Si no alertas, estás ciego.

Si alertas de todo, te ahogas.
Y cuando te ahogas, apagas el sistema.
Y cuando apagas el sistema, estás otra vez ciego.

Así que aquí la clave es seleccionar eventos que realmente importan, y convertirlos en casos de uso operables. Y esto, si lo estás haciendo con controles CIS, encaja perfecto con un SOC, con SIEM, con Sentinel, con Splunk, con Elastic… con lo que uses.

Qué eventos suelen ser relevantes en empresas

Identidad:
logins desde ubicaciones raras,
impossible travel,
MFA fallido repetido (fatigue),
cambios de roles,
creación de cuentas,
reseteos de contraseña,
invitaciones externas.

Privilegios:
alta en grupos admin,
cambios en permisos,
creación de service principals,
consentimientos de aplicaciones,
cambios en políticas de acceso.

Endpoint:
ejecución de herramientas típicas de atacante,
PowerShell raro,
persistencias,
credenciales en memoria,
desactivación del antivirus/EDR,
creación de tareas programadas sospechosas.

Red/perímetro:
VPN desde países no habituales,
picos de denegaciones,
cambios de reglas de firewall,
tráfico anómalo a destinos raros,
DNS sospechoso,
exfiltración.

Cloud:
creación de recursos inesperados,
cambios en storage público,
nuevas keys,
cambios en RBAC,
actividades fuera de horario.

Esto es solo una base. Cada empresa tiene sus joyas y sus patrones.

Y aquí entra el tema bonito: tunear y mantener

Una alerta no se crea y se olvida.
Se crea, se prueba, se ajusta.
Se mira si genera falsos positivos.
Se mira si se queda corta.
Se cambia el umbral.
Se añade contexto.

Y lo más importante: se conecta a una respuesta.

Si salta una alerta, ¿qué pasa?
¿Quién la recibe?
¿Se abre ticket?
¿Se ejecuta playbook?
¿Se escala?
¿Se documenta?

Porque si una alerta termina en un email que nadie lee, no es una alerta. Es spam.

Si quieres aprender a montar esto de forma práctica (casos de uso, reglas, correlación, alertas que no ahogan, automatización con playbooks y operación SOC), pásate por www.seguridadsi.com y mira los cursos de ciberseguridad online para profesionales que tenemos en la academia. Especialmente si trabajas con Microsoft Sentinel, aquí es donde empieza la magia de verdad.

Gracias por leerme !!!