Curso completo ciberseguridad gratis Controles CIS. Control 8.4

 Estimados amigos de Inseguros !!!

Seguimos con el control 8 de los CIS, gestión de logs, y hoy toca el 8.4: estandarizar el formato y el contenido de los registros de auditoría. Y esto es de esos controles que, si no lo haces, puedes tener “millones de logs”… y aun así estar ciego.

Porque el problema no suele ser “falta de logs”. El problema suele ser “cada log habla un idioma distinto”.

Un firewall te manda syslog con un formato.

Windows tiene su propio formato y sus IDs.
Linux te manda cosas por syslog/journal.
Un SaaS te manda JSON por API.
Cloud te manda activity logs con estructuras diferentes.
Y al final, si no estandarizas, no puedes correlacionar.

Y si no puedes correlacionar, no puedes detectar bien.

Qué significa estandarizar en la práctica

Significa que tú decides un modelo de datos común. Un esquema. Una forma de nombrar campos.

Por ejemplo:
usuario, host, IP origen, IP destino, acción, resultado, timestamp, dispositivo, severidad, evento, etc.

Y luego haces que todas las fuentes, de una manera u otra, acaben representadas con esos campos. No siempre al 100%, pero lo suficiente para poder buscar y correlacionar.

Esto, en el mundo real, se hace con normalización. Con parsers. Con conectores que ya te traen el log “bien” o con pipelines de ingestión que lo transforman. En SIEMs modernos esto es el día a día. Y en Microsoft Sentinel, por ejemplo, gran parte del juego es precisamente conseguir que lo que entra sea “usable” para luego tirar KQL y sacar detecciones.

Qué pasa cuando no lo haces

Pasa lo típico: te llega una alerta, y para entenderla necesitas abrir 5 logs distintos, con 5 campos distintos, y no sabes si “src”, “source”, “client_ip” y “ipOrigen” son lo mismo. Y ahí pierdes tiempo. Y en incidentes, perder tiempo es perder ventaja.

Y otra cosa peor: tus reglas de detección se vuelven frágiles. Funcionan para un fabricante, se rompen para otro. Funcionan para un equipo, no para el resto. Y entonces acabas sin confianza en tu detección, que es lo peor que te puede pasar.

Lo mínimo que deberías normalizar

Hora (timestamp) bien, con zona horaria clara.
Usuario (y si es posible, normalizado: UPN, sAMAccountName, etc.).
Host o recurso (nombre, ID, lo que aplique).
IP origen y destino cuando exista.
Acción (login, fail, allow, deny, create, delete, etc.).
Resultado (éxito, fallo).
Y un ID de evento o tipo de evento que te permita clasificar.

Si no tienes eso, no puedes construir casos de uso serios.

Y esto conecta con el resto del control 8

8.1 proceso.
8.2 recopilación.
8.3 almacenamiento.
Y ahora 8.4: hacer que los datos sirvan para algo.

Porque si no estandarizas, luego no puedes hacer lo siguiente: alertas, dashboards, hunting, correlación y automatización. Estás metiendo basura en una caja, y luego te sorprende que no salga inteligencia.

Si quieres aprender a montar esto con enfoque real de empresa (normalización, modelos de datos, conectores, KQL en Sentinel, casos de uso y operación SOC), pásate por www.seguridadsi.com y mira los cursos de ciberseguridad online para profesionales que tenemos en la academia.

Gracias por leerme !!!