Cada vez más empresas alojan sus servicios de IT en la nube. Una de las principales preocupaciones, cuando se está valorando la posibilidad de migrar las cargas de trabajo al cloud, es la seguridad.

Si bien es cierto que AWS es responsable de proteger la infraestructura que ejecuta los servicios provistos por la nube, las redes y las instalaciones, el usuario es el encargado de proteger los datos, redes, sistemas operativos, aplicaciones, identidades, etc.

En la actualidad, AWS dispone de varios servicios encargados de gestionar la seguridad de las cargas de trabajo, entre los cuales se encuentran:

  • AWS Identity and access Management (IAM)
  • Amazon GuardDuty
  • Amazon inspector
  • AWS Config
  • Amazon CloudWatch
  • AWS CloudTrail
  • AWS Shield
  • AWS Macie

Pero, ¿cómo gestionar los hallazgos que producen todos estos servicios?

AWS Security Hub es el servicio encargado de administrar la posición de seguridad en la nube, realizando comprobaciones de las prácticas recomendadas de seguridad, agregando alertas y permitiendo la corrección automática de los findings producidos por estos servicios.

Cuando se accede a la consola de Security Hub, de inmediato se observa que el número de hallazgos es muy grande, pudiendo llegarse a producir miles a lo largo de un mismo día.

Es en este punto donde identificamos la necesidad de filtrar estos hallazgos, priorizarlos y notificar a los equipos encargados de resolver las vulnerabilidades.

¿Por qué es necesaria esta solución?

Observamos que estos findings, hasta que se resuelven, son notificados de forma duplicada por Security Hub, llegando a registrarse incluso varias veces en el mismo día, generando un problema en la identificación, categorización y alertado de los incidentes, pudiendo saturar al equipo encargado de la resolución y provocando así una gestión poco eficiente de los riesgos de seguridad.

Es por esto que se ha diseñado una solución capaz de alertar de los findings que nos interesen, esto es, filtrando por la criticidad y tipo de servicio de origen (GuardDuty, Inspector y los Benchmarks de CIS y AWS), evitando también que los eventos generados se dupliquen, durante un periodo de tiempo personalizable.

Por ejemplo puedo elegir que sólo se notifiquen los eventos critical que lleven más de 5 días sin ser resueltos, o los eventos critical y high, que no se resuelvan en 15 días.

¿Cómo funciona?

  1. Una Event Rule monitoriza los hallazgos de Security Hub. Los Findings son filtrados por el servicio de origen. Actualmente esta solución soporta findings originados en Security Hub (CIS and Foundational benchmarks), GuardDuty e Inspector.
  2. Cuando la Event Rule detecta un evento, lanza una ejecución del flujo de trabajo de la State Machine de Step Function.
  3. Si el finding es nuevo o ha estado activo por más de 15 días, envía un correo al equipo encargado de revisar las incidencias de seguridad, informando de los detalles del hallazgo. El evento original está en formato JSON por lo que previamente se formatea en HTML, para que sea más sencillo identificar las partes importantes del finding a simple vista, cuando se recibe el correo.
  4. Adicionalmente, una lambda se ejecuta diariamente, comprobando si cada registro de la base de datos está activo o no en Security Hub. En caso de no estar activo, se elimina el registro para que, en caso de que vuelva a ocurrir más adelante, se vuelva a procesar correctamente.

¿Qué elementos componen esta solución?

  • EventBridge Event Rule –> Dos Events Rules. Una para monitorizar los findings producidos en Security Hub y la otra para que diariamente se comnpruebe qué findings están resueltos y eliminar la alerta.
  • Step Function –> Flujo de trabajo Serverless para procesar los findings registrados en Security Hub.
  • Lambda Function –> Cuatro funciones Lambda encargadas de gestionar las acciones necesarias durante el flujo de trabajo alojado en Step Functions.
  • DynamoDB Table –> Tabla que guarda los registros con la información de todos los findings activos.
  • Cloudwatch Log Group –> Log Groups que contienen los logs de las ejecuciones de Lambda.
  • IAM Role –> Seis IAM Roles encargados de aprovisionar a Lambda, DynamoDB y Step Functions de los permisos necesarios para el procesado, análisis y notificación de los hallazgos.
  • SES Identity –> Servicio encargado del envío de los correos con los findings.

 

Arquitectura de alto nivel

 

Flujo de trabajo en Step Function

Descripción del flujo de trabajo:

  1. La primera función Lambda comprueba si el registro se encuentra en la base de datos de Dynamo. Si no está allí, significa que es un finding nuevo así que lo añade a la tabla, envía el evento a la siguiente Lambda que formateará el evento en HTML y lo envía por correo al equipo de soporte, vía SES.
  2. Si el item existe en la base de datos, significa que el finding se ha duplicado y está activo todavía así que otra función Lambda se ejecuta para comprobar si el finding ha estado activo por más de 15 días. Si es así, ejecuta la Lambda que parsea el evento en HTML para notificar al equipo de soporte. Si el finding lleva menos de 15 días activo, no se realiza ninguna acción.

A continuación se observa un gráfico con el flujo de trabajo utilizado para analizar los eventos de seguridad:

 

 

Uso

1. Clonar el repositorio

$ git clone https://github.com/lorenzocampo/alerting-securityhub-findings.git

2. Inicializar el directorio de trabajo que contienen los ficheros de terraform:

$ terraform init

3. Crear un plan de ejecución, que permite previsualizar los recursos que se van a desplegar:

$ terraform plan

4. Ejecutar las acciones propuestas en el plan de Terraform:

$ terraform apply

 

Conclusión

La seguridad es uno de los principales pilares sobre los que sustenta cualquier servicio de TI. Con la ayuda de esta solución, facilitamos la detección y resolución temprana de los incidentes que se registren, agilizando y optimizando el proceso de notificación al equipo de soporte, consiguiendo así que los equipos que gestionan estos incidentes se centren en lo más importante, resolver los problemas.

 

Imagen: Unsplash | @fakurian

+ posts

Cloud Architect at Keepler. "I am a Cloud Architect specialized in DevOps and Security. I love designing solutions, fixing problems, learning every day and facing challenges that make me go out of my comfort zone. In my free time I'm a very family oriented person, a lover of rock and almost any kind of sport."

A %d blogueros les gusta esto:
This site is registered on wpml.org as a development site.