Curso completo ciberseguridad gratis Controles CIS. Control 8.3

Estimados amigos de Inseguros !!!

Seguimos con el control 8 de los CIS, gestión de logs, y hoy toca el 8.3: garantizar un almacenamiento adecuado de los registros de auditoría. Este control parece “de infraestructura”, pero en realidad es de supervivencia. Porque cuando pasa un incidente, lo primero que desaparece no es el atacante… es tu evidencia.

Y aquí viene el error típico: “los logs están en el servidor”. Ya. Y el servidor es justo lo primero que te van a tocar. Si el atacante compromete un host, puede borrar eventos, puede limpiar rastros, puede parar servicios de logging, puede truncar archivos, puede cambiar timestamps… y cuando tú llegas, ya no hay película.

Por eso el 8.3 va de esto: los logs tienen que almacenarse de forma que sean difíciles de manipular, y con capacidad suficiente para no perderlos por volumen.

Qué significa “almacenamiento adecuado” en la práctica

Primero: centralizado. Los logs no pueden depender solo del host origen. Eso ya lo veníamos viendo en el 8.2.

Segundo: con retención y capacidad calculada. Si tú recoges logs y en 7 días se te llena el disco, o el SIEM empieza a dropear eventos, estás ciego sin saberlo. Esto se calcula. Volumen por fuente, picos, y margen.

Tercero: con integridad. Lo ideal es que los logs estén protegidos contra modificación. En muchos entornos esto se aterriza como WORM (Write Once Read Many) o como almacenamiento inmutable, o al menos como controles de permisos y separación de roles para que el atacante no lo pueda borrar “con el mismo usuario” que comprometió.

Cuarto: con separación de privilegios. Si el mismo admin que administra sistemas administra también el almacenamiento de logs, y esa cuenta cae, pierdes todo. Esto enlaza con el capítulo 5 (cuentas), porque al final todo está conectado: identidad, privilegios y evidencia.

Quinto: con copias y redundancia. Porque no solo hay atacante. También hay fallos. Si tu SIEM se cae o tu collector se rompe, y no tienes buffer, pierdes eventos. En logs, perder eventos es perder historia.

Dónde se suele romper esto

En dos sitios.

Uno: en la arquitectura de collectors. Mucha gente manda syslog a un servidor sin redundancia, sin disco, sin colas, sin control. El día que hay un pico o un fallo, se pierden paquetes. Y tú ni te enteras.

Dos: en cloud y SaaS. Porque “como está en la nube, ya está”. No. En la nube también hay retención limitada, y muchos audit logs tienen ventanas cortas si no los exportas. Si no los llevas a un almacenamiento tuyo (o a tu SIEM con retención), luego llega el día de la investigación y te faltan días clave.

Un detalle que siempre repito: logs sin retención son como cámaras sin grabación. Te dan sensación de seguridad, pero cuando pasa algo no hay nada.

Y aquí entra el factor negocio

¿Cuánto tiempo necesitas retener? Depende de regulación, de contratos, de riesgo, de tu capacidad, y de tu estrategia. Pero tiene que estar definido. No vale “lo que venga por defecto”.

En empresas, lo normal es tener retención operativa (para detección diaria) y retención forense/archivo (para investigación y cumplimiento). Y ahí es donde el almacenamiento adecuado marca la diferencia: puedes tener hot storage para búsqueda rápida y cold storage para histórico. Lo importante es que exista el plan y que no pierdas evidencia.

Si quieres aprender a montar esto con enfoque real (arquitectura de logging, collectors, retención, integridad y operación de SIEM/SOC, especialmente en entornos Microsoft con Sentinel), pásate por www.seguridadsi.com y mira los cursos de ciberseguridad online para profesionales que tenemos en la academia.

Gracias por leerme !!!