Trazabilidad entre regla, ticket y técnica

Cada versión de una regla debería poder contestar cuatro preguntas: por qué existe (el ticket que la pidió), quién y cómo la cambió (la solicitud de cambio), qué conducta cubre (la técnica de ATT&CK con la que se etiqueta) y cómo se comprueba (sus casos de prueba). Esa cadena se llama trazabilidad. La rellena el proceso, no la memoria: el ticket se enlaza en la solicitud, la solicitud nombra la versión, y la etiqueta de la técnica va en el archivo de la regla.

Sirve para auditorías, para heredar el trabajo y para decidir. Cuando un directivo pide «qué cubrimos de la técnica X y por qué», se contesta con una consulta, no con una reunión.

La tabla trazabilidad tiene una fila por cada versión publicada. La v1.3 de FZQ-021 es justo la que revisaste en la sala 3. Para saber por qué se pidió ese cambio no hace falta llamar a nadie: se mira el ticket enlazado y, en la tabla tickets, su resumen.

Una versión publicada sin ticket enlazado rompe la cadena: se sabe qué cambió (la solicitud) pero no por qué. Es un hallazgo de proceso, no de la regla, y se arregla enlazando, no reescribiendo. En la tabla, una «—» en ticket significa que la solicitud no enlaza ninguno.

La técnica de ATT&CK aparece dos veces: en el catálogo del equipo (qué técnica se quiere cubrir) y en la etiqueta del archivo de la regla. Si no coinciden, el informe de cobertura cuenta una cosa y la regla dice otra. Las dos hay que revisarlas contra la fuente: se decide con la descripción de la técnica, no con la costumbre.

Un responsable ve que la regla del vaciado del registro de Seguridad no enlaza ningún ticket, que nadie recuerda quién la pidió y propone retirarla para reducir el catálogo. Antes de decidir, se busca el origen en el tracker de tickets: la unión puede haberse perdido en la solicitud, no en la historia. En la tabla tickets hay un posincidente cuyo resumen describe justo lo que la regla vigila.