GuardDuty suma investigaciones con IA: menos alerta suelta, más contexto para responder

AWS anunció una capacidad nueva para Amazon GuardDuty que apunta a un problema muy concreto de los equipos de seguridad: no alcanza con detectar algo raro, hay que entender rápido si es grave, qué evidencia lo sostiene y qué conviene hacer después. La novedad se llama GuardDuty Investigation y está en preview como AI-powered investigations para Amazon GuardDuty.

El punto interesante no es que GuardDuty “ahora tenga IA” en abstracto. GuardDuty ya usa machine learning, inteligencia de amenazas y análisis de comportamiento para detectar actividad sospechosa en cuentas AWS, workloads, datos y servicios como EC2, EKS, ECS, Lambda, S3 y RDS. Lo nuevo está más cerca del trabajo cotidiano de un SOC: agarrar un finding, mirar el contexto, revisar actividad relacionada, cruzar señales, estimar riesgo y proponer próximos pasos.

Si alguna vez te tocó investigar un finding de GuardDuty en serio, sabés que la parte lenta no siempre es ver el alerta. La parte lenta es reconstruir la historia: qué recurso está afectado, qué principal hizo qué llamada, si hubo actividad parecida en los últimos días, si el comportamiento es esperable para esa cuenta, si hay indicadores conocidos, si conviene contener, suprimir o escalar. Ahí es donde esta capacidad puede sumar.

🔵 Qué anunció AWS

Según el anuncio oficial, las investigaciones con IA analizan findings de GuardDuty y cuentas AWS para ayudar a distinguir amenazas reales de findings benignos. AWS menciona que el análisis mira el contexto del finding, actividad relacionada de los últimos 90 días, recursos afectados e indicadores de amenaza, usando grafos de conocimiento e inteligencia de amenazas.

La documentación de GuardDuty Investigation baja esto a elementos más concretos. Cada investigación puede devolver:

- nivel de riesgo: Info, Low, Medium, High o Critical;
- nivel de confianza: Unknown, Low, Medium o High;
- resumen de la investigación;
- detalles y contexto adicional;
- acciones recomendadas, incluso comandos de CLI;
- clasificación de técnicas de ataque según MITRE ATT&CK, una base de conocimiento usada en seguridad para describir tácticas y técnicas comunes de atacantes.

Eso cambia bastante la experiencia. Un finding tradicional te dice “esto parece sospechoso”. Una investigación estructurada intenta responder “por qué parece sospechoso, cuánto confío en esa lectura, qué evidencia miré y qué haría ahora”. Para un equipo con muchas cuentas, esa diferencia puede ser tiempo real de respuesta.

🔶 Tres formas de investigar

La preview soporta tres tipos de análisis.

Análisis de finding. Sirve para investigar un finding específico. En la API o CLI, el prompt tiene que incluir un ID de finding de 32 caracteres hexadecimales. Durante la preview, AWS dice que soporta todos los findings de Extended Threat Detection y algunos findings de los planes foundational, S3 y Runtime.

Análisis de cuenta. En vez de mirar un finding aislado, analiza la postura de amenaza de una cuenta AWS. Esto puede ser más útil cuando hay varias señales sueltas y necesitás entender si la cuenta está mostrando un patrón de compromiso o solo ruido operativo.

Análisis de organización. Para cuentas administradoras, permite analizar postura a nivel organización. En preview llega hasta 100 cuentas. Para empresas que usan AWS Organizations, esta es probablemente la parte más potente: muchos incidentes no se entienden bien si mirás una sola cuenta.

Hay límites importantes. Durante la preview se pueden iniciar hasta 10 investigaciones por cuenta por día, con un límite total de 100 investigaciones por cuenta. Además, si usás API o CLI, el trigger-prompt puede tener hasta 2.048 caracteres. Las investigaciones fallidas no cuentan contra esas cuotas.

⚙️ Cómo se habilita

Primero necesitás tener un detector activo de GuardDuty en la Región donde quieras crear investigaciones. Después hay que habilitar la feature en ese detector. En consola aparece en Settings → AI powered investigations - Preview.

Por CLI, la documentación muestra que la feature se habilita como AI_ANALYST:

aws guardduty update-detector \
  --detector-id 2cb3d4e5f6a7b8c9d0e1f2a3b4c5d6e7 \
  --features '[{"Name":"AI_ANALYST","Status":"ENABLED"}]'

También necesitás permisos IAM para operar investigaciones:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "guardduty:CreateInvestigation",
        "guardduty:GetInvestigation",
        "guardduty:ListInvestigations"
      ],
      "Resource": "arn:aws:guardduty:us-west-2:123456789012:detector/2cb3d4e5f6a7b8c9d0e1f2a3b4c5d6e7"
    }
  ]
}

Para crear una investigación desde CLI, se usa create-investigation con un prompt que describe qué querés investigar:

aws guardduty create-investigation \
  --detector-id 2cb3d4e5f6a7b8c9d0e1f2a3b4c5d6e7 \
  --trigger-prompt "Investigate finding 1ab2c3d4e5f6a7b8c9d0e1f2a3b4c5d6 in account 123456789012"

La operación corre de forma asincrónica. Primero recibís un InvestigationId y después consultás el resultado con get-investigation.

🛡️ Dónde aporta valor

El caso más directo es triage. Si el equipo recibe muchos findings, no todos merecen la misma energía. Tener un resumen con riesgo, confianza, evidencia y acciones recomendadas ayuda a ordenar prioridades. No elimina la revisión humana, pero evita empezar cada investigación desde cero.

También aporta consistencia. Dos analistas pueden investigar el mismo finding de maneras distintas. Una salida estructurada puede estandarizar la primera lectura: qué se observó, qué técnica de ataque conocida aplica, qué recursos están involucrados y qué comandos conviene ejecutar para validar o contener.

Otro caso fuerte aparece en organizaciones multi-cuenta. Si sos el equipo central de seguridad, no querés mirar findings como si cada cuenta viviera aislada. Querés saber qué cuentas tienen señales relevantes, dónde hay más riesgo y qué merece escalarse. El análisis de cuenta y de organización van en esa dirección.

⚠️ Lo que no conviene hacer

No lo usaría como piloto automático de remediación. La propia documentación aclara que las recomendaciones pueden contener errores o evaluaciones incompletas, y que se recomienda revisión humana. Eso es clave: la IA puede ayudar a juntar contexto y proponer hipótesis, pero no debería borrar recursos, cambiar políticas o aislar workloads productivos sin un gate de aprobación.

También miraría con cuidado el tema de regiones. GuardDuty Investigation usa Cross-Region Inference Service. AWS indica que los datos quedan almacenados solo en la Región donde se origina el pedido, pero los datos de investigación y los resultados del resumen pueden procesarse fuera de esa Región dentro de la geografía soportada. Para muchas empresas esto no será un problema; para industrias reguladas, hay que revisarlo.

La disponibilidad también es limitada en preview: US East (N. Virginia), US East (Ohio), US West (Oregon), Canada (Central), Europe (Frankfurt), Europe (Ireland), Europe (London), Europe (Paris), Europe (Stockholm) y Asia Pacific (Tokyo).

🔍 Qué significa para los equipos de seguridad

Esta novedad encaja con una tendencia clara: AWS está llevando más capacidades de “análisis asistido” a los servicios de seguridad. No alcanza con tener detección; el cuello de botella está en entender, priorizar y responder.

Lo probaría primero en un subconjunto de cuentas, comparando las investigaciones generadas por GuardDuty con el análisis humano. Mediría tres cosas: si reduce tiempo de triage, si mejora la calidad de la evidencia y si las recomendaciones son accionables sin inventar pasos peligrosos. Si funciona bien, el resultado no debería ser “la IA responde sola”, sino algo más realista y valioso: analistas con mejor contexto, menos trabajo repetitivo y decisiones más rápidas.

Fuentes

- AWS What's New: Amazon GuardDuty AI-powered investigations accelerate threat response
- Amazon GuardDuty User Guide: GuardDuty Investigation
- Página de producto de Amazon GuardDuty
- IAMTrail: archivo de anuncios de GuardDuty
- SecureResearch: resumen del anuncio de AWS