Los detectores y lo que leen

GuardDuty analiza tres fuentes de base: los eventos de gestión de CloudTrail, los registros de flujo de VPC y los registros de consultas DNS. Las consume por flujos independientes y duplicados, sin que el cliente tenga que crear ni configurar nada: no depende de que exista un trail ni de que haya registros de flujo propios. De cada fuente extrae campos para perfilar el comportamiento y después descarta los registros.

Esa última frase es la que cambia el trabajo de investigación. El detector avisa, pero no entrega los registros: para investigar un hallazgo de red hacen falta los registros de flujo creados por el cliente, y para investigar uno de identidad, el trail. Detector y registro se complementan; uno no sustituye al otro.

Además de las tres fuentes de base, GuardDuty tiene funciones opcionales que se activan una por una y abren una fuente más: la lectura de los eventos de datos de S3, los registros de auditoría de Kubernetes, la actividad de inicio de sesión de las bases de datos, entre otras. Cada función tiene un nombre en la configuración del detector y un estado, activada o desactivada.

Esto tiene una consecuencia directa para la cobertura. Un tipo de hallazgo que depende de una fuente solo puede aparecer si la función que la abre está activada: sin ella, el detector no ve esa actividad, y el silencio no significa que no ocurra. Revisa el estado del detector de Arrayán y busca la función que le permitiría ver las descargas anómalas de objetos del almacenamiento.

El hallazgo de ejemplo del laboratorio nace de una llamada que ya viste en la sala de integridad: la que detenía el trail. Que GuardDuty lo vea no es una contradicción, porque consume los eventos por su propio flujo y no depende del trail que se acaba de apagar. Es incluso lo que le permite avisar de un registro apagado.

Dentro del hallazgo hay dos relojes que conviene no confundir. Uno, eventFirstSeen, dice cuándo ocurrió la actividad. Otro, createdAt, dice cuándo GuardDuty generó el hallazgo. La resta es el retraso con el que el aviso llegó al equipo, y es un dato que se anota cuando se evalúa si una detección es suficientemente rápida.

GuardDuty conserva los hallazgos 90 días. Para guardarlos más tiempo, se exportan a un bucket de S3 y se archivan allí. Es la misma lógica de los registros de la sala anterior: si no se exporta, el hallazgo de hace cuatro meses ya no existe en el servicio, y con él se va la prueba de que el detector lo vio.

La lista de hallazgos-exportados.csv recoge lo que Arrayán exportó desde enero. Con la fecha de la revisión en el encargo, se puede contar cuántos de esos hallazgos ya habrían salido del servicio y solo existen gracias a la exportación.

En Azure, el equivalente a un servicio de detección de amenazas es Microsoft Defender for Cloud, que se activa por planes según el tipo de recurso. Sus alertas no se quedan solo en su propio panel: aparecen también en el registro de actividad de la suscripción, en una categoría específica.

Eso significa que quien exporta el registro de actividad a un SIEM o a un espacio de trabajo recibe, en el mismo flujo, las operaciones sobre los recursos y las alertas del servicio de detección. Para filtrarlas hay que conocer la categoría.