Cloudtrail – El hoyito del diablo



Bueno, si alguna vez trabajaron con cloudtrail tal vez entiendan la analogia, si no lo hicieron es muy probable que lo hagan en algun futuro. Las tecnologias cambian, las empresas se re-inventan por lo que hay que estar en el camino. Cuando nos toca protejer nuestro ambiente cloud y estamos hablando del gigante AWS tenemos que saber que cloudtrail es la medida fundamental.


Que es?

Bueno, AWS CloudTrail es un servicio de AWS que le ayuda a habilitar el gobierno, el cumplimiento, el funcionamiento y el análisis de operaciones y riesgo de su cuenta de AWS. Las medidas que adopta un usuario, la función o un servicio de AWS se registran como eventos en CloudTrail.


Los eventos incluyen las acciones llevadas a cabo en la Consola de administración de AWS y AWS Command Line Interface así como las API y los SDK de AWS.CloudTrail se habilita en su cuenta de AWS cuando la crea. Cuando se produce actividad en su cuenta de AWS, esta se registra en un evento de CloudTrail. Puede ver fácilmente los eventos recientes en la consola de CloudTrail, solo tiene que dirigirse al historial de eventos.Osea, basicamente cloudtral es el registro de todo lo que se hace dentro de nuestra nube. Por lo que debe estar contemplada como una fuente de datos fundamental para nuestro SIEM.Que debemos monitorear?

Aca, tal vez lo mas interesante del articulo, entender que es cloudtrail es super interesante y necesario pero a veces lo mas dificil no es entender que es lo que significa sino entender, desde un punto de vista de #ThreatDetection que debo monitorear sobre esta funte de datos, pues aqui les dejo algunos ejemplos basicos de lo que pueden controlar:


- CloudTrail detuvo el envio de eventos. (detectar cuando cloudtrail deja de enviar eventos o alguien detiene el servicio de cloudtrail).

- Un “security group” (el security group es como decimos que puede entrar y que no a la red de una VPC) tiene habilitado un 0.0.0.0/0 para X puerto.

- Actividad del usuario ROOT de la cuenta. (siempre hay una cuenta root/administrador no deberia tener mucha actividad).

- Creacion de instancias “caras” (large) cuando se crean estas instancias es comun, si el negocio no las usa, que sea para minar criptomonedas.

- No llegan eventos. (Algo que vi mucho que faltaba, deberian tener una alerta cuando los eventos no estan llegando al SIEM).

- Bucket S3 se cambio a publico. (los bucket s3 son como carpetas/directorios para almacenar info, en su mayoria no deberian ser publicos).

- Multiple instancias EC2 creadas al mismo tiempo. (Si bien pueden tener varios FP “falsos positivos” con esta, pueden llegar a detectar posibles intrusos en su cloud).

- Multiples autenticaciones fallidas. (Esta alerta puede ayudarlos a detectar si alguien esta intentando vulnerar su cloud).

- Multiples intentos de leer/read desde el mismo usuario. (Como sabemos cloudtrail es un log de las llamadas a la api de AWS, por lo tanto tambien tenemos cuando alguien intenta acceder a recursos/servicios que no tiene acceso. Esa actividad a veces puede ser signo de compromiso).

- Multiples cambio de passwords de cuentas administradoras. (Este tipo de alerta tambien puede darles algun indicador de compromiso).

- Instancia EC2 lanzada con una AMI no conocida. (cuando creamos instancias en muchos casos ya tenemos identificadas las AMI “imagenes” que se puedenmusar, tener una alerta por uso de alguna no autorizada sirve).



Como estos ejemplos pueden existir muchos mas, vamos a estar creando un repositorio con varias alertas, su fuente y como seria la query/busqueda para que todos puedan aportar sus casos.