Mis notas sobre AWS Detective: AWS Certified Security - Specialty

Amazon Detective elimina la recopilación y análisis manual de datos. Permite a los equipos de seguridad comprender rápidamente un contexto determinado y realizar investigaciones eficientes sobre hallazgos de seguridad permitiendo identificar y comprender la causa raíz del incidente. 

Amazon Detective es capaz de analizar eventos desde múltiples orígenes de datos (VPC Flow Logs, CloudTrail, GuardDuty, Security Hub, EKS Audit Logs ... ) e implementa ML, análisis estadistico y teoria grafica para generar una vista unificada e interactiva de los recursos y las iteracciones sobre estos durante el tiempo (gráfico de comportamiento de Detective). 

Una investigación en Detective se centra en la actividad relacionada con los recursos de AWS implicados en un hallazgo.

El gráfico de comportamiento se compone de un conjunto de datos vinculados a partir de la información recopilada desde los orígenes de datos, ofreciendo:

• Imagen general de usuarios y servicios, así como la interacciones entre ellos a lo largo del tiempo. 

• Análisis detallados de las actividades realizadas sobre las cuentas, correlacionando los eventos que pudieran estar involucrados en un hallazgo de seguridad. 

• Adicionalmente, puede integrarse con Amazon Macie y otras herramientas de terceros.

Ofrece visión general sobre: 

• Roles y usuarios con el mayor número de llamadas a las API.

• EC2 con mayor tráfico.

• EKS con mayor número de pods.

• Nuevas localizaciones que acceden a los servicios. (last 24 hours).

La cuenta designada como administrador de Detective puede invitar a cuentas miembros a un gráfico de comportamiento. Cuando una cuenta miembro acepta la invitación y se habilita, Detective empieza a ingerir y extraer datos de la cuenta miembro para el gráfico de comportamiento. 

Desde Detective se puede invitar a cuentas externas a la Organización al gráfico de comportamiento.

El volumen máximo de datos a inspeccionar por Detective es de 10TB diarios por cuenta (si es superado, no se podrá activa Detective).

Si el volumen de datos del gráfico de comportamiento supera los 15TB diarios, Detective detiene la ingesta. Si se suspende la ingesta de datos, hay que tratarlo con AWS Support para solicituar su reactivación.

Orígenes de datos

Amazon Detective ofrece la posibilidad de configurar diferentes paquetes de orígenes de datos. La retención máxima de cada paquete es de 1 año.

• Paquete básico: 

• Hallazgos de GuardDuty 
• Tráfico de red desde CloudTrail y FlowLogs, siendo los flujos independientes de la configuración particular de cada cuenta, y por lo tanto, no supone un aumento de coste a este nivel ni afectan a las configuraciones de registro de flujo de CloudTrail y VPC existentes ni hacen uso de ellas.

• Paquete auditoría EKS:

• Este paquete de orígenes de datos opcionales permite a Detective ingerir información detallada sobre los clústeres de EKS  y añade esos datos al gráfico de comportamiento.

• Este origen de datos mejora la información proporcionada sobre los siguientes tipos de entidades: clústeres de EKS, pods de Kubernetes, imágenes de contenedor y sujetos de Kubernetes.

• Paquete resultados de seguridad de AWS:
• Este paquete de orígenes de datos opcionales permite a Detective ingerir datos de Security Hub, y añade esos datos a su gráfico de comportamiento. 

En caso de utilizar Detective junto con GuardDuty:

• Es recomendable usar Detective en la misma cuenta sobre la que se ha centralizado la gestión de GuardDuty a nivel de Organización de AWS. 

• Reducir a 15 minutos (defecto 6 horas) el tiempo que tarda Detective en recibir las nuevas notificaciones para hallazgos ya existentes en GuardDuty (no afecta al coste de usar GuardDuty).

En GuardDuty tengo un hallazo, lo resuelvo (automática o manualmente).
En Detective se revisan que más actividades sospechosas están relacionadas con dicho hallazgo. 

Finding Groups:

Nos permiten analizar múltiples actividades en relación con un único evento donde se ha visto comprometida la seguridad. 

• Análisis gráfico que muestra relación entre los diferentes hallazgos.

• Deberían ser el punto de inicio de una investigación. 

• Muestran información sobre entidades internas y externas. 

• Se habilitan automáticamente en las regiones por defecto que admiten Detective, sin existir cargo adicional por su utilización.

GuardDuty: Bloqueando host sospechosos automáticamente.

Esta entrada no se tratan las bondades de GuardDuty, para conocerlas puedes acceder a la siguiente entrada: AWS GuardDuty, donde detallo las principales características del servicio y en que puede ayudarnos a la hora de reforzar nuestra postura de seguridad dentro de AWS. 

De lo que si hablaré es de generar flujos automatizados que utilicen controles de detección y de respuesta, e incluso de controles preventivos, que ayuden a minimizar y mitigar las amenazas actuales y futuras. 

En función de determinados eventos de origen, podremos automatizar acciones especificas que nos ayuden a remediar los hallazgos, que en este caso nos ofrecerá GuardDuty, como primera línea de acción antes de entrar en un análisis exhaustivo. 

El objetivo de esta entrada es presentar una solución basada en CloudWatch Events que actúe como disparador de funciones Lambda en respuesta a los hallazgos de GuardDuty con objeto de actualizar las WebACLs de AWS WAF y las NACL (a nivel de subnet) en una determinada VPC y bloquear el acceso a las IPs que estén realizando acciones sospechosas o inusuales sobre los servicios desplegados en AWS. 

1. Se genera un hallazgo en GuardDuty con una posible actividad maliciosa.
2. EventBridge Events filtra los eventos de GuardDuty en busqueda del tipo de patrón de evento configurado. 
3. El evento EventBridge invoca una función Lambda la cual analiza el hallazgo de GuardDuty.. 
4. Lambda comprueba la tabla de estado de DynamoDB en busca de una entrada existente que coincida con el host identificado en el tipo de hallazgo configurado en EventBridge. Si no se encuentran datos del host, se crea una nueva entrada en la tabla de estado de DynamoDB.
5. Si no se encontró el host en DynamoDB, Lamdba genera una regla WebACL en el WAF.
6. Lambda actualiza la NACL asociada a la subnet donde reside el elemento objeto del hallazgo. 
7. Se envía una notificación a través de SNS. 

Las plantillas para el despliegue están disponibles en el siguiente repositorio: GitHub - aws-samples/amazon-guardduty-waf-acl: AWS GD2ACL

Mis notas sobre AWS GuardDuty: AWS Certified Security - Specialty

GuardDuty supervisa continuamente nuestras cuentas de AWS en busca de actividad maliciosa, ofreciendo visibilidad sobre las posibles amenazas y los mecanismos para una remediación rápida. Todo ello apoyado con aprendizaje automático (ML) en base al modelado de comportamiento y a fuentes sobre amenazas líderes en el sector. 

GuardDuty trabaja a nivel de cuenta analizando los logs:

• AWS CloudTrail

• VPC FlowLogs

• AWS DNS Logs

• EKS Audit Logs

Agentless: no es necesario el uso de agentes. 

Reconoce: 

• Actividad maliciosa:

• Conducta anómala y actividad inusual.

• Escaneo de puertos intra-VPC

• Inicios de sesión fallidos e inusuales.

• Instancias EC2 comprometidas:

• Mineria de criptomonedas.

• Malware y backdoors.

• Volumen de red alto inusual.

• Uso de protocolos de red inusuales.

• Comunicaciones con IP maliciosas conocidas.

• Credenciales temporales de EC2 utilizadas desde IPs externas.

• Exfiltración de datos mediante DNS.

• Cuentas comprometidas:

• Llamadas API desde localización inusual o proxy anónimo.

• Intentos de deshabilitar AWS CloudTrail.

• Cambios que debilitan la política de contraseñas de la cuenta. 

• Lanzamiento y activación de infraestructura inusual en la cuenta.

• Despliegues de infraestructura de la región no habitual.

• Llamadas a la API desde IPs maliciosas.

Adicionalmente, se puede activar protección específica para S3, EKS, Lambda, RDS y Malware.

• Protección de S3:

• Análisis de logs de CloudTrail en busca de eventos de S3. 

• Patrones sospechosos de acceso.

• Actividad inusual en API.

• Intentos de acceso desde IPs maliciosas.

• Llamadas API para recuperar datos como un usuario sin historial previo.

• Llamadas API desde una ubicación inusual.

• Protección de EKS:

• Análisis de EKS Audit logs Monitoring y EKS Runtime Monitoring.

• Detección de actividades potencialmente peligrosas (EKS Audit Logs).

• Análisis cronológico de actividades de usuarios, aplicaciones utilizando la API y del control plane, ayudando a detectar amenazas potenciales en nodos y contenedores. 

• Protección de Malware:

• Detecta la potencial presencia de malware escaneando volúmenes EBS (en instancias de EC2 y contenedores). 

• Se puede especificar la protección sobre una instancia de EC2 concreta.

• Proporciona opción para mantener los snapshots de los volúmenes EBS cuando se generar resultados de GuardDuty sobre dichos volúmenes.

• Disponible dos tipos de escanes:

• Bajo demanda.

• Iniciados por GuardDuty.

• Protección RDS:

• Identifica intentos de acceso sospechosos o una actividad inusual sobre motores de base de datos: Amazon Aurora MySQL-Compatible Edition and Aurora PostgreSQL-Compatible Edition.

• Protección Lambda:

• Monitoriza los logs de actividad de Lambda (FlowLogs y registros que no utilizan redes VPC cuando se invoca la función).

• GuardDuty monitoriza todos los logs de la actividad de red generados con la invocación de una función Lambda.

Niveles se severidad

Amazon GuardDuty proporciona tres niveles de severidad (bajo, medio y alto) para ayudar a priorizar la respuesta ante posibles amenazas:

• Bajo: indica actividad sospechosa o maliciosa que se bloqueó antes de que comprometiera su recurso

• Medio: indica actividad sospechosa que se desvía del patrón habitual.

• Alto: indica que el recursos pudiera estar comprometido y se estaría utilizando de forma activa con un fin no autorizado.

Remediación

Amazon GuardDuty ofrece HTTPS APIs, CLI tools y eventos de Amazon CloudWatch para respaldar respuestas de seguridad automatizadas a los hallazgos de seguridad.

Las casuísticas son varias en función del servicio y del nivel de automatización que se considere, como ejemplo, se puede automatizar una respuesta mediante el uso de CloudWatch Events como origen de eventos para activar una función Lambda.

Configuración multi-account:

Se puede seleccionar una cuenta dentro de la organización en AWS para centralizar la gobernanza de GuardDuty (GuardDuty administrator account).
El resto de cuentas que necesitemos que sean inspeccionadas desde la cuenta de administración de GuardDuty pueden ser asociadas mediante: 

• Desde AWS Organizations.

• Mediante invitación a través de GuardDuty.

Suppressing findings

Es probable que no necesitemos ser informados de determinados hallazgos y recomendaciones de GuardDuty por diferentes motivos (hallazgos de bajo valor, falsos positivos conocidos, amenazas que no se consideran relevantes ...). Para ello, dentro de GuardDuty contamos con las "Suppression Rules", un conjunto de criterios compuestos por un filtro y un valor que permiten archivar automáticamente nuevos hallazgos que coincidan con dichos criterios. 

Cuando un nuevo hallazgo coincide con los criterios de las "Suppression Rules", dichos hallazgos son marcados como archivados y no son enviados a:

• AWS Security Hub

• Amazon S3

• AWS Detective

• CloudWatch

Los "Suppersing findings" son de especial ayuda para aliviar el nivel de ruido cuando se consume GuardDuty vía Security Hub, SIEM de terceros o cualquier herramienta de alertado y ticketing.

Los hallazgos son automáticamente archivados por 90 días, tras este periodo son eliminados. Se puede utilizar Eventbridge para enviar automáticamente dichos hallazgos a un bucket de S3 y mantenerlos por periodos de tiempo superior a los 90 días por defecto. 

Threat Lists

Las "Threat Lists" contienen información sobre direcciones IP maliciosas, dominios sospechosos, URLs dañinas y otros indicadores de compromiso.

Son mantenidas por expertos en seguridad, proveedores de inteligencia de amenazas y organizaciones de seguridad cibernética. Estas listas se actualizan regularmente para incluir nuevas amenazas conocidas y eliminar aquellas que ya no representan un riesgo significativo.

• Estas listas son solo aplicables a direcciones IP enrutables públicamente.

• Los efectos de una lista se aplican a todos los hallazgos de VPC Flow Log y CloudTrail, pero no se aplican a los hallazgos de DNS.

• Máximo de 250.000 direcciones IPs y rangos CIDR por lista.

Trusted IP List

• IPs de confianza sobre las que GuardDuty no genera hallazgos. 

• Máximo de 2000 direcciones IPs y rangos CIDR por lista. 

• Máximo 1 lista por cuenta y región. 

La "Thusted IP List" se procesa primero, por lo que en caso de existir la misma IP en ambas listas no se generarán hallazgos para esta IP. 

En entornos multi-account, solo los usuarios de cuentas de administrador de GuardDuty pueden cargar y administrar las listas. 

En las cuentas de la organización gestionadas por GuardDuty, se generan hallazgos basados en actividades que involucran direcciones IP maliciosas conocidas de las listas de amenazas ("Threat List") de la cuenta de administración y no se generan hallazgos basados en actividades que involucran direcciones de las listas de IP confiables ("Trusted IP List") de la cuenta de administración de GuardDuty.

Balanceadores de carga en AWS

Dentro de entornos cloud, los balanceadores de carga se han convertido en herramientas esenciales para dar sentido a la distribución del tráfico entrante entre diferentes servicios y servidores, con el objetivo de asegurar la alta disponiblidad, tolerancia a fallos y escalado de aplicaciones. 

Desde AWS se ofrecen diferentes opciones para diferentes casos de uso, y es fundamental alinear los requisitos y necesidades de nuestras cargas de trabajo a las características y funcionalidades de cada una de las alternativas que nos ofrece AWS como soluciones de balanceo. 

Actualmente en AWS disponemos de 4 tipos: 

1. CLB - Classic Load Balancer. Balanceador de carga básico con capacidades de balancear tráfico entre elementos de una misma región. Tiene capacidades de autoescalado en función de la cantidad de tráfico recibida. 

Soporta protocolos HTTP/HTTPS, TCP y SSL. No soporta HTTP/2 ni Websockets.

Ofrece posibilidad de chequeo de salud de los destinos y terminación SSL. También permite sticky-sessions (cookies) ofrecidas por la aplicación. 

No soporta enrutado basado en path ni enrutado a multiple puertos en una única instancia.

Es una solución perfectamente válida para distribuir tráfico entre instancias IaaS (EC2) que alojen servidores web. En el caso de cargas TCP, es válido para distribuir tráfico entre bases de datos. Tambien permite distribuir tráfico entre contenedores. 

2. ALB - Application Load Balancer: balanceo avanzado HTTP/HTTPS (capa 7 modelo OSI). 

Balanceador completo que ofrece gran variedad de funcionalidades permitiendo enrutamiento avanzado basado en contenido (content-based routing), asi como la capacidad de inspeccionar el tráfico entrante en base a las cabeceras HTTP, path o cookies, permitiendo enrutar el tráfico en base a URL path o nombre de máquina a diferentes destinos.

Soporta HTTP/2, websockets y aplicaciones basadas en contenedores.

Soporta sticky-sessions generadas por el balanceador. 

Solución válida para el balanceo de aplicaciones web y distribucion de tráfico entre microservicios.

En general es ideal para aplicaciones web que requieren enrutamiento basado en path y desean conseguir una lógica en el balanceo. 

3. NLB - Network Load Balancer. Trabaja en la capa 4 del modelo OSI.

Elección adecuada en caso de requerir alto rendimiento (millones de peticiones por segundo) con baja latencia en cargas de tipo TCP/UDP.

Por ello, este tipo de balanceador de carga es especialmente recomendado para aplicaciones de juegos, inversión en bolsa, streaming de video  y plataformas de mensajería (chats). 

4. GWLB - Gateway Load Balancer: para balanceo de cargas hacía virtual appliances (firewalls y sistemas de deteción de intrusiones).  Trabaja entre las capas 3 y 7 del modelo OSI. 

Esta diseñado para trabajar con endpoints de tipos gateway load balancer desde los cuales se puede enviar tráfico desde cuentas spoke para ser inspeccionado por la cuenta hub donde se encuentran los sistemas de detección de intrusiones o firewalls. 

Soporta tráfico HTTP y TCP.