Cualquier organización con datos sensibles puede ser objeto de un ciberataque, independientemente de su tamaño o sector industrial. A medida que más y más empresas se trasladan a la cloud, el panorama de las amenazas evoluciona a un ritmo acelerado en el que los adversarios despliegan tácticas avanzadas para alcanzar su objetivo final. La respuesta a incidentes desempeña un papel fundamental a la hora de proteger sus datos y evitar que un ataque cause estragos en su organización.
La base de un programa eficaz de respuesta a incidentes cloud se centra en la preparación, las operaciones y la actividad posterior al incidente. NIST y SANS , ambas organizaciones de confianza, han desarrollado marcos de IR con pasos de respuesta a incidentes que se alinean estrechamente con estas fases. Vectra AI CDR para AWS Incident Response se desarrolló basándose en estas fases, por necesidad de alinearse con el ciclo de vida de NIST Incident Response, junto con las operaciones que abarcan la detección impulsada por IA, el análisis con contención, la erradicación y la recuperación. La guía de respuesta a incidentes de seguridad de AWS describe muchos métodos para automatizar las técnicas de respuesta a incidentes.
La guía de respuesta a incidentes de seguridad de AWS indica que es esencial prepararse para un incidente. Tras detectar un evento en la fase de detección de una respuesta a incidentes y analizarlo en la fase de análisis, puede utilizar la solución automatizada para la contención de los cuatro servicios de AWS compatibles. La contención del incidente es fundamental para hacer frente a las amenazas en tiempo real. ¿Qué aspecto tiene una instancia de contención automatizada?
Por qué Vectra bloqueo de entidades de AWS
La seguridad es la máxima prioridad en Vectra. AWS tiene un modelo de responsabilidad compartida: AWS gestiona la seguridad de la cloud, y los clientes son responsables de la seguridad en la cloud. Tal modelo deja al cliente en control total de su implementación de seguridad, sin embargo, la respuesta a incidentes de seguridad puede ser compleja. Adoptar las capacidades de automatización de bloqueo de entidades de Vectra CDR para AWS mejora la velocidad de respuesta de sus equipos de SecOps y simplifica las operaciones de respuesta a incidentes, por lo que su organización está mejor preparada para cuando se produzca un evento y puede minimizar la amenaza antes de que pueda causar estragos en su organización.
Así es como lo hacemos:
SecOps debe responder e investigar cuando se produce una desviación de la línea de base, como por ejemplo por una mala configuración o un cambio en factores externos. Vectra La solución CDR for AWS Entity Lockdown prepara mejor a su equipo para los eventos de seguridad proporcionando lo siguiente:
- Principio del menor privilegio de AWS: Solo es necesario exponer un permiso de publicación SNS. Acceso fuertemente controlado.
- Flujo de trabajo automatizado: La solución puede integrarse limpiamente en los flujos de trabajo existentes y activarse automáticamente para garantizar un control fuera de banda que impida que los ataques escalen hasta tener impacto.
- Pista de auditoría automatizada: La solución permite auditar y registrar el cumplimiento.
- Entre regiones y cuentas: Trabaje desde una única ubicación en todo su entorno de AWS para simplificar el uso.
- Específicos y dirigidos: Garantiza el bloqueo completo de las credenciales comprometidas, de modo que el atacante no pueda aprovechar una ruta de ataque diferente. Esto garantiza que solo se bloqueen las credenciales comprometidas para evitar que las actividades habituales se vean afectadas.
Arquitectura y diseño de la contención de AWS
Vectra CDR para AWS utiliza un mensaje de tema de AWS SNS para activar una función de Lambda. En primer lugar, el mensaje de AWS SNS se publica manualmente o a través de una herramienta de terceros, por ejemplo, Amazon Security Hub o SOAR. A continuación, el código Lambda desencadena otras acciones basadas en el contenido del mensaje. El mensaje SNS requiere dos atributos de mensaje. Un ARN de la entidad a aislar y un ExtranalId. El usuario establece el ExtranalId durante el despliegue de la plantilla de CloudFormation. Este campo es estático y se utiliza para validar el mensaje SNS mediante la función Lambda de Respuesta a Incidentes.
De este modo se llevarán a cabo las siguientes tareas, tal y como se ilustra en la Figura 1:
- Un mensaje AWS SNS se publica con un ARN de entidad AWS para la contención y ExternalId.
- El mensaje SNS invoca una función de AWS Lambda. La función de Lambda ejecuta la lógica empresarial de respuesta a incidentes en función del tipo de entidad.
- Se enviará un correo electrónico de auditoría de AWS SNS al usuario durante todo el proceso. Un correo electrónico para el inicio del proceso, otro para el éxito o el fracaso y otro si el mensaje cae en la cola de mensajes muertos.
Cuando se invoca la función Lambda, se ejecuta la siguiente lógica de negocio: La lógica de negocio de respuesta a incidentes se ilustra en la Figura 2.
Determinar el tipo de entidad AWS. Entidades compatibles: Lambda, Usuario IAM, Rol IAM y EC2.
La funciónLambda adjuntará una política gestionada por AWS DenyAll si el tipo de entidad es IAM Role o User.
Si el tipo de entidad es una función de AWS Lambda, se aplica la siguiente lógica:
- Adjunte la política gestionada DenyAll de AWS a la función de ejecución de Lambda.
- Establezca la propiedad function_currency de la función Lambda en 0. Esto evitará que se active la función.
La siguiente lógica se aplica si el tipo de entidad es una instancia AWS EC2.
Las reglas de los grupos de seguridad comienzan como una denegación implícita de todo el tráfico. Cuando no hay reglas, se crean reglas que permiten tráfico específico. El tráfico entrante se permite independientemente de las reglas salientes y viceversa; así es como AWS implementa las conexiones con estado dentro de los grupos de seguridad. Puede añadir o eliminar reglas en cualquier momento, y los cambios se aplican inmediatamente a las instancias asociadas con el grupo de seguridad. Pero, el efecto de algunos cambios de reglas puede depender de cómo se rastrea el tráfico. Entender cómo funcionan las conexiones rastreadas es vital para implementar una contención eficaz del grupo de seguridad. Si una conexión es rastreada, puede mantener la conectividad a Internet, a pesar de adjuntar un grupo de seguridad sin reglas. Los grupos de seguridad utilizan el rastreo de conexiones para rastrear información sobre el tráfico hacia y desde la instancia - así es como implementan conexiones con estado aunque no todos los flujos de tráfico son rastreados. Hay una excepción... El tráfico ICMP siempre es rastreado.
Las conexiones sin seguimiento se aplican a cualquier tipo de tráfico con una regla cuádruple cero para todos los puertos en cualquier dirección. Puedes ver ejemplos de conexiones rastreadas y no rastreadas.
- Flujos TCP o UDP para todo el tráfico (0.0.0.0/0 Rastreado. :/0) y hay una regla correspondiente en la otra dirección que permite todo el tráfico de respuesta (0.0.0.0/0 o :/0) para todos los puertos (0-65535), entonces ese flujo de tráfico no es rastreado - No rastreado.
- Se rastrea el tráfico TCP entrante y saliente en el puerto 22 (SSH), porque la regla de entrada sólo permite el tráfico desde 203.0.113.1/32, y no todas las direcciones IP (0.0.0.0/0) - Rastreado.
- El tráfico TCP entrante y saliente en el puerto 80 (HTTP) no se rastrea, porque las reglas de entrada y salida permiten el tráfico desde todas las direcciones IP - No se rastrea.
- El tráfico ICMP siempre es rastreado - Rastreado.
Si elimina la regla de salida para el tráfico IPv4, se rastrea todo el tráfico IPv4 entrante y saliente, incluido el tráfico en el puerto 80 (HTTP). Lo mismo ocurre con el tráfico IPv6 si elimina la regla de salida para tráfico IPv6. - Rastreado.
Los grupos de seguridad son muy eficaces y tienen como objetivo la contención de una única instancia de Ec2. La terminación de conexiones rastreadas y no rastreadas requiere un proceso de varios pasos para terminar las conexiones activas y prevenir una futura. Todas las conexiones sin seguimiento se terminan inmediatamente al aplicar la solución de bloqueo de entidades de Vectra . Sin embargo, sólo se terminan las conexiones rastreadas activas, lo que es muy importante entender. En nuestra solución, las conexiones activas son cualquier conexión que tenga tráfico de red fluyendo continuamente o no más de intervalos de 1 minuto.
La siguiente solución funcionará para conexiones continuamente activas. Por ejemplo, si la instancia EC2 comprometida se utiliza para la minería de criptomonedas o forma parte de un ataque de ransomware.
Cuando se invoca la función Lambda de Respuesta a Incidentes y el tipo de entidad a aislar es una instancia EC2 de AWS, se realizan las siguientes acciones.
- Adjunte una política condicional para denegar todas las acciones al perfil de instancia para una instancia EC2 comprometida. Muchas soluciones sugieren desvincular el rol de perfil de instancia de la instancia. Sin embargo, aunque esta acción impediría a la instancia iniciar nuevas sesiones, no revocaría las sesiones existentes. Por ejemplo, si el atacante explotara una aplicación mal configurada y obtuviera credenciales de seguridad de los metadatos de la instancia, estas credenciales permanecerían activas durante un máximo de 12 horas.
- Comprueba la VPC en la que residen las instancias EC2 para ver si existe un grupo de seguridad de conexiones sin seguimiento; si no es así, crea uno y, a continuación, aplica el grupo de seguridad a la instancia. Este grupo de seguridad tiene una única regla de entrada y salida de 0.0.0.0/0, que convierte las conexiones rastreadas en no rastreadas.
- Compruebe si existe un grupo de seguridad de aislamiento en la VPC. Si no existe, cree uno y, a continuación, aplique el grupo de seguridad a la instancia. Este grupo de seguridad no tiene reglas de entrada ni de salida. La asignación de este grupo de seguridad aislará completamente la instancia EC2.
Implementación de Vectra CDR para AWS
Para implementar Vectra CDR para AWS, primero debe acceder a las plantillas de CloudFormation. Si utiliza una cuenta de AWS, solo necesitará la plantilla de despliegue de recursos de respuesta a incidentes. Sin embargo, necesitará implementar dos plantillas si tiene una configuración multicuenta y desea una solución de respuesta a incidentes entre cuentas. La implementación de la primera plantilla en su cuenta de seguridad de AWS alojará los recursos de respuesta a incidentes. La segunda plantilla creará una función IAM en las demás cuentas que desee que cubra la solución. El README de la solución documenta completamente las plantillas de AWS CloudFormation y los detalles de la pila. Puede encontrar recursos adicionales en el repositorio de GitHub.
Vectra CDR para la automatización de AWS
Para iniciar su automatización, primero tendrá que implementar Vectra CDR para la pila de AWS CloudFormation. A continuación, si está utilizando la consola de AWS, puede publicar un mensaje SNS desde la pantalla de recursos de servicio. Si desea utilizar la CLI de AWS o el SDK de AWS, puede encontrar el ARN SNS de Respuesta a Incidentes en la pestaña de salida de la pila de AWS CloudFormation. Puede encontrar un tutorial detallado para cada enfoque en el README del repositorio de GitHub.
Contención de incidentes de AWS
Como se mencionó anteriormente, siguiendo CloudFormation, su analista SOC solo necesitará privilegios de publicación SNS para responder a un incidente de AWS. Un servicio de seguridad como Amazon Security Hub o SOAR también puede publicar un mensaje como parte del flujo de trabajo del equipo de SecOps. Por lo tanto, el analista SOC no necesitaría privilegios administrativos sobre los servicios sospechosos de AWS. Siguiendo los pasos descritos, su equipo de SecOps podrá crear respuestas a incidentes utilizando herramientas nativas de AWS. Esta metodología también admite la contención entre cuentas y regiones. Si elimina la pila en cada cuenta, será necesaria una limpieza manual para eliminar estos grupos de seguridad creados para el aislamiento de EC2.
La respuesta ante incidentes es una parte integral de una estrategia de ciberseguridad para todas las empresas. Mediante la contención de incidentes de AWS, su equipo de SecOps tendrá la seguridad de saber cómo automatizar el aislamiento de una instancia EC2, un usuario y rol de IAM y una función de Lambda para responder a cualquier entidad sospechosa en su entorno de AWS.
¿Y ahora qué?
Experimente la potencia de Vectra CDR para AWS de primera mano con nuestra prueba gratuita.