Versionar y retirar reglas

Tres campos de Sigma sostienen el mantenimiento. El id es un identificador único: la especificación recomienda uno nuevo cuando la lógica cambia de forma mayor, porque ya no es la misma regla. El modified es la fecha del último cambio y se actualiza al cambiar título, detección, nivel o logsource, o al pasar la regla a deprecated. El status dice su madurez: experimental, test, stable, y al final deprecated (reemplazada o cubierta por otra, enlazada en related) o unsupported (no se puede usar tal como está).

Para inteligencia, esos tres campos son la trazabilidad: permiten responder qué regla vio qué, con qué lógica y desde cuándo, cuando alguien pregunte meses después por una alerta o por un silencio.

Abre la consola. historial_lru_s04 trae las cuatro versiones de la regla local con su id, su status, su fecha de modificación y el cambio. politica_de_ciclo_de_vida es la política de la célula.

Añadir un programa a una lista o un filtro estrecho son ajustes: la regla sigue buscando lo mismo. Pero una de las versiones cambió la conducta que se busca y se quedó con el identificador de antes; además, no actualizó su fecha de modificación.

catalogo_reglas_cti lista las siete reglas de la célula con la fecha de su última revisión. La política fija un plazo máximo entre revisiones y dice desde cuándo una regla está vencida. Hoy es 2026-12-07.

Cuenta los días reales de cada mes. Una regla que llega justo al plazo todavía no está vencida.

Retirar una regla también es inteligencia: una campaña que ya no se ve y una regla que nunca da alertas verdaderas ocupan tiempo de revisión y de cómputo. Pero se retira con criterio, no por antigüedad. La política exige tres condiciones a la vez.

Hay varias reglas de campañas inactivas. Solo una cumple las tres condiciones.

La regla elegida lleva meses sin alertas verdaderas y otra activa cubre su conducta. Alguien propone borrar el archivo hoy «para limpiar el repositorio».