Excepciones acotadas: afinar sin cegar

Una excepción dice «cuando se cumpla esto, no alertes», y lo que la hace segura es lo estrecho que sea ese «esto». Hay tres ejes para acotarla: quién (la cuenta o el grupo de cuentas), dónde (el equipo o el grupo de equipos) y cuándo (la ventana horaria o la fecha hasta la que vale). Y hay un objeto: qué es exactamente lo que se deja pasar, descrito por lo que cuesta falsificar —la firma y su editor, la ruta completa, el hash— y no por lo que cualquiera elige libremente.

La excepción ancha es la que suelta uno de esos ejes por comodidad: «cualquier ejecutable firmado», «toda la carpeta de descargas de finanzas», «la cuenta de soporte en cualquier equipo». Borra el ruido de golpe, y con él cualquier incidente que caiga dentro de lo que se soltó. La regla sigue activa y la capa de cobertura la sigue pintando de verde, pero en ese hueco ya no mira.

Antes de aprobar una excepción se hace una comprobación que cuesta un minuto: pasar por ella las alertas que la regla escaló en el último mes. Si una sola de esas alertas habría quedado dentro de la excepción, la excepción no está acotada, porque en ese mes habría borrado un incidente que se encontró precisamente gracias a esta regla.

La comprobación no demuestra que una excepción sea segura —el incidente del mes que viene puede llegar con otra forma—, pero descubre en el acto las que ya fallan con los datos que hay.

De todo lo que describe a un ejecutable, el nombre es lo único que elige libremente quien lo deja en el equipo. Llamar setup.exe, update.exe o igual que el actualizador de la casa a un programa malicioso no cuesta nada, y es justo lo que se hace para parecer normal. Una excepción escrita solo sobre el nombre le dice al atacante qué nombre ponerle a su archivo para que esta regla no lo vea nunca.

Lo que sí cuesta falsificar es otra cosa: la firma de un editor concreto, que exige su clave privada; la ruta completa en una carpeta que el usuario no puede escribir; el hash exacto. Una excepción buena puede usar el nombre como ayuda, pero nunca como único criterio: lo que la sostiene es la firma, la ruta o el hash, más los tres ejes.

Una excepción se aprueba con dos números a la vista: cuántas alertas quita y cuántos verdaderos positivos conserva. Se miden igual que en la tarea 2, reproduciendo el mes pasado con las excepciones puestas. Si las alertas escaladas que siguen saltando son las mismas que sin excepciones, el ruido se fue y la detección no.

Una excepción es una decisión, y las decisiones caducan. El fabricante de las impresoras termina su despliegue, el actualizador del ERP cambia de editor, la persona que la pidió se va de la empresa. Una excepción sin dueño ni fecha sigue aplicándose años después de que nadie recuerde por qué existe, y ese es exactamente el tipo de hueco que alguien de fuera puede encontrar y aprovechar.

Por eso se registra con su dueño (quién responde de ella), su motivo (el ticket o el cambio que la justifica) y su fecha de revisión o de caducidad, y cuando llega esa fecha se vuelve a medir.