De la amenaza al registro que la delataría

Un registro por sí solo no detecta nada: es la materia prima. Lo que detecta es un caso de uso de detección, que une cuatro cosas: la amenaza que se quiere ver, el evento concreto que la delataría, la fuente que debe registrar ese evento y los campos que ese registro necesita traer para que la regla pueda decidir.

Quien diseña la arquitectura no escribe las reglas del SIEM, pero sí decide si esas reglas serán posibles. Si el diseño no produce el evento, o lo produce sin el campo que la regla necesita, el mejor analista del mundo no podrá hacer nada. Esa es la lectura de este módulo: la detección se diseña igual que la autenticación o el cifrado.

El marco NIST CSF 2.0 agrupa esto en su función Detectar, con las categorías de monitoreo continuo (DE.CM) y de análisis de eventos adversos (DE.AE). Es vocabulario de trabajo, no una lista de casillas.

Abre la tabla amenazas. La última columna dice qué caso de uso cubre cada amenaza del modelo. Una fila con «ninguno» no es un descuido menor: es una amenaza que la empresa decidió modelar y que, tal como está el diseño, ocurriría sin que nadie lo notara.

Antes de proponer nada, mira también el impacto. Una amenaza sin caso de uso puede ser aceptable si su impacto es bajo; una amenaza con impacto de fuga de datos personales no lo es.

Cada caso de uso lista los campos que necesita y cada fuente lista los campos que trae. Cuando la lista de la fuente es más corta, el caso existe en el papel y no funciona. Es el fallo más común y el más barato de arreglar: añadir un campo al registro, en el diseño, cuesta mucho menos que descubrir su ausencia en mitad de un incidente.

Compara, para el caso de uso de la consulta masiva con un token de la API, los campos que pide con los que trae la fuente que nombra.

Un atacante con una credencial válida no produce errores: produce eventos que parecen normales. Por eso el caso de uso de la sesión de soporte no busca contraseñas fallidas. Busca una contradicción: la misma sesión usada desde dos orígenes que no pueden ser la misma persona en el tiempo transcurrido.

Diseñar para detectar significa preguntarse qué cosa, que ya es verdad en el sistema, dejaría de serlo si la amenaza ocurriera. Esa contradicción necesita que el registro traiga el identificador de la sesión y el origen, no solo el nombre de usuario.

Hay una última comprobación, la más dura: que la fuente exista. Un caso de uso bien escrito sobre una fuente que la arquitectura no produce es una promesa vacía. Abre la tabla fuentes y busca la que algún caso nombra y el diseño no genera.

Cuando la fuente no existe, el cambio se mide en el diseño, no en el SIEM: hay que activar el registro de acceso en el componente que decide quién lee, o ponerlo en el que sí puede registrarlo.