AWS Security Hub es el servicio de AWS donde podemos administrar todas nuestras incidencias de seguridad desde un único punto. En Security Hub se engloban, catalogan y priorizan las alertas que generen Amazon GuardDuty, Amazon Inspector y Amazon Macie, entre otros.  

En esta entrada vamos a explicar cómo realizar remediations de forma desasistida de los findings de seguridad.

¿Cómo habilitamos Security Hub?

Inicialmente, Security Hub (SH) ha de ser activado en todas las cuentas y regiones donde se quieran analizar eventos de seguridad. SH depende de AWS Config, que tiene que ser también habilitado en todas las regiones donde se quiera utilizar SH.

Si estamos usando Organizations, como es el caso de este ejemplo, tendremos que declarar una cuenta como “Delegated Administrator” para este servicio en concreto de AWS. Si estamos utilizando Landing Zone o AWS Control Tower, será la cuenta designada como “Security”.

Para habilitar la cuenta de Security como Delegated Administrator, nos iremos a la cuenta Master de nuestra organización – Security Hub – Settings, y desde la consola podremos configurar en qué cuenta se agruparán todos los eventos de seguridad de todas las cuentas de nuestra organización.

 

Una vez realizado este proceso, nos vamos a la cuenta de Security, y podemos observar que se han añadido todas las cuentas de nuestra organización:

En nuestro caso, hemos habilitado 2 “Security Standards”, que no son más que conjuntos de reglas que aplicar a nuestra infraestructura.

¿Cómo resolvemos los problemas de seguridad que encontremos?

Bien, este es el punto, quizás, más decisivo a la hora de definir la metodología de resolución de problemas. Si bien muchos problemas se pueden resolver de forma desasistida, la recomendación es que sea algún miembro del equipo de SecOps el que debería realizar esta labor de forma manual. Dependiendo del grado de criticidad del evento de seguridad, podemos tomar acciones que mitiguen el problema, para notificar posteriormente. Este es el caso que vamos a utilizar en este post. 

Concretamente, utilizaremos la regla “4.1 Ensure no security groups allow ingress from 0.0.0.0/0 to port 22” del grupo de reglas CIS AWS Foundation Benchmark, una remediación automática.

Todos estos eventos que vemos en el Security Hub, disparan un evento que recibimos en EventBridge, por lo que, mediante reglas de filtrado de eventos, podremos gestionar qué hacer cuando recibamos este evento.

 

 

Los pasos para remediar este problema que sigue este flujo son:

  1. EventBridge recibe el evento de Security Hub
  2. Se lanza una Step Function que:
    • Borrará la regla que permite el tráfico desde 0.0.0.0/0 al puerto 22
    • Notificará al responsable definido para que, mediante API GW, apruebe o deniegue ese cambio.
      • En caso de aprobación, se volverá a crear la regla ingress en el security group
      • En caso de denegación, la regla se mantendrá borrada.

En este caso, se ha decidido remediar antes de preguntar, debido a la criticidad del problema.  Este mismo flujo nos servirá para otras reglas, como pueden ser:

  • Borrar una ingress rule que permite el puerto 3389 desde 0.0.0.0/0
  • Borrar IAM policies que contengan algún tipo de acción no permitida
  • Bloquear accesos a buckets s3 que tengan una policy demasiado abierta

Este tipo de acercamiento permite actuar de forma reactiva a los eventos de seguridad, enfoque que está alineado con las buenas prácticas propuestas por AWS en el pilar de seguridad de su Well-Architected Framework.

En las siguientes entradas explicaremos cómo crear Custom Rules en Security Hub para poder adaptar el servicio a nuestras necesidades.

Imagen: Rawpixel