Control de versiones para detecciones

Un repositorio con control de versiones guarda cada cambio como un commit: una foto del archivo con el autor, la fecha y un mensaje. Entre dos commits se puede pedir la diferencia (el diff), que lista exactamente qué líneas cambiaron.

Dos cosas importan al leerlo. La primera es que el mensaje lo escribe quien hace el cambio y dice lo que cree haber hecho, no necesariamente lo que hizo. La segunda es que el diff no opina: si el mensaje dice «formato» y el diff toca un número de la lógica, manda el diff. Una etiqueta o un registro de despliegues añade la pieza que falta, qué commit está publicado en cada entorno.

DAC-102 se calla desde el 19 de abril. El archivo tuvo cuatro commits y solo uno de ellos puede explicar el silencio. Conviene empezar por el historial para tener la lista y seguir por el diff de cada commit, que es donde se ve qué campos de la lógica se tocaron.

Ya está el culpable y la tentación es deshacerlo a toda prisa. Hay tres caminos y solo uno respeta lo que el control de versiones está para proteger. Reescribir el historial para borrar el commit deja a quien lo mire dentro de un año sin saber que existió el error. Cambiar el número en la interfaz web del SIEM se salta el repositorio: la regla publicada y la regla guardada dejan de ser la misma.

El camino normal es un commit de reversión: un commit nuevo que deshace los cambios del anterior, con su propio mensaje, su revisor y su despliegue. El historial queda completo y cuenta lo que pasó.

Producción no tiene el último commit del repositorio: tiene el que alguien desplegó. El registro de despliegues dice cuál. Antes de revertir hay que saber cuál fue la última versión de producción que se comportaba como se esperaba, para comprobar al final que la restaurada se parece a ella.

El jefe del SOC preguntará cuánto tiempo estuvo la regla sin ver. Se cuenta en días completos desde que la versión con el umbral alto entró en producción hasta hoy, miércoles 5 de mayo.