Estimados amigos de Inseguros !!!
Hoy toca el Tema 3, control CIS 3.4, y aquí hablamos de una palabra que todo el mundo menciona pero casi nadie gobierna bien: retención.
El 3.4 es “sencillo” de entender, pero de los más complicados de ejecutar. Porque no es una acción puntual: es una política viva que mezcla operativa y legal. Puede que por negocio baste con guardar facturas un año, pero por obligación legal necesites cinco. Y al revés también pasa: sectores donde se exige tener histórico mínimo, pero también un máximo, porque no puedes guardar indefinidamente.
Aquí está la trampa típica: “si nunca borro, cumplo retención”. No necesariamente. La retención tiene dos vertientes: conservar lo mínimo que toca y purgar lo que ya no debería existir. El ejemplo rápido: un hospital puede necesitar mantener el historial de los últimos X años, pero no guardar más allá de Y. Eso es retención real: mínimo y máximo, con reglas claras.
Y ojo, porque los logs de ciberseguridad también son datos. En un SIEM se vive esto todos los días: retención “caliente” para buscar rápido y retención “fría” para archivo. En Microsoft Sentinel, Splunk o similares, suele existir esa separación: meses en almacenamiento rápido y luego histórico en almacenamiento más barato/lento (data lake / archive). Esta parte se trabaja muchísimo en entornos cloud y de monitorización.
Cuando la organización crece, el problema no es solo “guardar”. Es el arrastre: si metes diez años en un lago de datos sin criterio, acabas procesando, pagando y gestionando volumen sin valor. Por eso el 3.4 pide que esto se aterrice como política: definir qué se guarda, cuánto tiempo, y cuándo se purga.
La forma práctica de bajarlo a tierra es tener una matriz de retención. Una tabla donde cada tipo de dato tenga: mínimo, máximo, base legal, método de borrado, y si aplica, estrategia de hot/cold. Y no solo datos “bonitos”: también backups. Los backups son datos. Si se tratan como datos, también deben entrar en el documento.
Y esto no se documenta “por pasar una auditoría”. Se documenta para identificar mejoras y aplicarlas. En CIS no hay un examen externo: hay autoauditoría. El objetivo es ver dónde está la empresa, y subir un escalón.
En cloud hay mecanismos que ayudan mucho a que la retención sea automatizable y demostrable. En Microsoft Purview existen políticas de retención para que los datos hagan su ciclo de vida de forma controlada. En Azure existe Lifecycle Management, precisamente para mover datos entre caliente/frío/archivo y purgar cuando toca.
Incluso en algo tan cotidiano como OneDrive se ve el matiz: borrar no es “desaparecer”. Hay papelera, hay segundo nivel, y luego hay que purgar. Si no se conoce ese flujo, se cree que se borra… y el dato sigue ahí. El 3.4 va de convertir todo esto en procedimiento: borrado automático, retención demostrable y estrategia clara.
En www.seguridadsi.com hay formaciones de todo tipo.
Gracias por leerme !!!
