AWS Builder Center

Builder Center

Amazon GuardDuty Custom Detection Rules: definir que actividad es sospechosa en tus cuentas

Tercera entrada de la serie sobre deteccion y respuesta en AWS.

vtjean

Cada cuenta AWS tiene un perfil de actividad distinto. Lo que en una cuenta de desarrollo es una operacion habitual puede ser, en produccion, la primera senal de un incidente. Amazon GuardDuty ya genera hallazgos para patrones de amenaza conocidos, pero hasta ahora no habia forma de indicarle al servicio: "esta accion especifica, en esta cuenta, necesita atencion".
El 1 de septiembre de 2026, AWS lanzo Custom Detection Rules para Amazon GuardDuty. Esta funcionalidad permite activar reglas de deteccion preconfiguradas que evaluan eventos de AWS CloudTrail y generan hallazgos cuando la actividad coincide con patrones que el equipo de seguridad considera relevantes para una cuenta concreta. La logica encaja con el hilo conductor de esta serie: la regla define la senal, el modo de prueba permite medir antes de comprometerse, y el hallazgo en modo en vivo dispara el runbook de respuesta.
Este blog complementa las dos entradas anteriores sobre el agente de investigacion de GuardDuty y las secuencias de ataque. Aquellos se centran en que hacer despues de un hallazgo; este se centra en el paso previo: decidir que actividad merece convertirse en hallazgo.

Que son las Custom Detection Rules

Custom Detection Rules es una biblioteca de reglas predefinidas que el equipo de Amazon GuardDuty construye y mantiene. Cada regla esta descrita con vocabulario de MITRE ATT&CK y del AWS Threat Technique Catalog, lo que facilita mapear las detecciones al marco de amenazas que ya uses en tu organizacion.
Las reglas no se crean desde cero. El operador selecciona las reglas relevantes de la biblioteca y las habilita en cada cuenta, eligiendo entre dos modos de operacion:
  • Dry run (prueba): La regla evalua eventos de AWS CloudTrail y, cuando hay coincidencia, emite metricas en Amazon CloudWatch. No genera hallazgos. La asociacion en modo dry run expira automaticamente a los 14 dias.
  • Live (en vivo): La regla genera hallazgos de GuardDuty cuando detecta actividad coincidente. No tiene fecha de expiracion.
Esta separacion entre modos permite medir el volumen de coincidencias antes de comprometerse con hallazgos que entren en la cola de triaje del equipo de seguridad.

El modelo de reglas: condiciones SQL sobre eventos de CloudTrail

Cada regla define condiciones SQL que evaluan campos de eventos de gestion de AWS CloudTrail. Actualmente, Custom Detection Rules solo soporta eventos de gestion de CloudTrail; los eventos de datos (como operaciones sobre objetos de Amazon S3) no estan cubiertos.
Las condiciones pueden evaluar campos estandar del evento (eventName, eventSource, sourceIPAddress) y tambien campos anidados dentro de requestParameters y responseElements, usando funciones disenadas para navegar estructuras JSON complejas.
Un ejemplo simplificado de lo que una regla evalua internamente:
1
2
3
eventName = 'ModifyImageAttribute'
AND json_extract(requestParameters,
'launchPermission.add.items[0].group') = 'all'
Este patron detectaria cuando alguien comparte una AMI de forma publica. La regla viene predefinida en la biblioteca; el operador solo decide si habilitarla y en que modo.

Conceptos clave

Antes de entrar en la configuracion, conviene alinear vocabulario:
  • Rule (Regla): La definicion de la deteccion, mantenida por GuardDuty. Incluye la condicion SQL, la descripcion y el mapeo a MITRE ATT&CK.
  • Association (Asociacion): La relacion entre una regla y una cuenta. Al habilitar una regla se crea una asociacion con el modo elegido (dry run o live).
  • Mode (Modo): Dry run o live. Determina si la coincidencia genera metricas o hallazgos.
  • Signal (Senal): Cuando la actividad de AWS CloudTrail coincide con una regla en modo live, GuardDuty genera una senal. Una senal representa una ocurrencia observada.
  • Finding (Hallazgo): Las senales que comparten tactica, servicio y tecnica se agregan en un solo hallazgo. El formato sigue la convencion Tactic:Service/Technique.
Un ejemplo de formato de hallazgo:
1
Persistence:IAM/AccountManipulation
Si la misma tecnica se observa tres veces en cinco minutos, el equipo de seguridad recibe un hallazgo con tres senales, no tres hallazgos separados. Esta agregacion reduce el ruido sin perder la granularidad de cada ocurrencia individual.

De dry run a live: el flujo de trabajo practico

El flujo recomendado tiene tres fases:

1. Seleccion de reglas

Revisa la biblioteca de reglas disponibles y selecciona las que son relevantes para el perfil de riesgo de cada cuenta. Algunos ejemplos de actividad que las reglas pueden detectar:
  • Compartir una AMI con cuentas externas o de forma publica
  • Eliminar VPC Flow Logs en Amazon VPC
  • Iniciar sesion en la consola de AWS sin MFA habilitado
  • Modificar politicas de bucket de Amazon S3 para permitir acceso no autorizado
  • Desactivar el registro de eventos en AWS CloudTrail
No todas las reglas seran relevantes en todas las cuentas. Una cuenta de sandbox donde los desarrolladores experimentan con AMIs tiene un contexto de riesgo diferente al de una cuenta de produccion que procesa datos regulados.

2. Dry run durante 14 dias

Habilita las reglas seleccionadas en modo dry run. Durante los 14 dias que dura la asociacion en este modo, observa las metricas en Amazon CloudWatch para evaluar:
  • Cuantas coincidencias genera cada regla por dia
  • Si hay falsos positivos recurrentes (actividad legitima que coincide con la regla)
  • Si el volumen resultante es manejable para el equipo de triaje
Si una regla genera demasiadas coincidencias por actividad legitima, la decision puede ser no activarla en modo live para esa cuenta especifica, o investigar por que esa actividad ocurre con tanta frecuencia.

3. Activacion en modo live

Cuando el volumen y la relevancia son aceptables, cambia la asociacion a modo live. A partir de ese momento, cada coincidencia genera una senal que se agrega en hallazgos de Amazon GuardDuty. Estos hallazgos entran en el flujo habitual: aparecen en la consola de GuardDuty, se envian a Amazon EventBridge y pueden activar automatizaciones en AWS Lambda o AWS Step Functions.
El hallazgo es el punto de entrada al runbook. Si ya tienes runbooks para hallazgos de GuardDuty (como los descritos en las entradas anteriores de esta serie), los hallazgos de Custom Detection Rules se integran en el mismo flujo sin modificaciones.

Configuracion a nivel de organizacion

Para cuentas gestionadas con AWS Organizations, el administrador delegado de GuardDuty puede gestionar las reglas de forma centralizada. Cuando el administrador habilita una regla, la configuracion se aplica automaticamente a todas las cuentas miembro existentes y a las que se incorporen en el futuro.
Esto simplifica la gobernanza: el equipo central de seguridad define el conjunto base de reglas activas, y los equipos de cada cuenta pueden complementar con reglas adicionales segun el perfil de riesgo especifico.
La configuracion de organizacion tambien respeta los modos. El administrador puede desplegar una regla en modo dry run en todas las cuentas, evaluar las metricas agregadas y luego promover a modo live cuando el equipo tiene confianza en que el volumen de hallazgos sera manejable.

Donde encaja Custom Detection Rules en la estrategia de deteccion

Los hallazgos estandar de GuardDuty cubren patrones de amenaza conocidos: comunicacion con servidores de comando y control, acceso anomalo a credenciales, actividad de mineria de criptomonedas. Las secuencias de ataque (tema del segundo blog de esta serie) correlacionan multiples senales para detectar campanas que avanzan por varias fases de la cadena de ataque.
Custom Detection Rules complementa ambas capacidades con un enfoque diferente: actividad que no es maliciosa por definicion, pero que resulta sospechosa en el contexto de una cuenta concreta.
Eliminar VPC Flow Logs es una operacion legitima de la API de Amazon VPC. Pero en una cuenta de produccion donde los Flow Logs son obligatorios para cumplimiento normativo, esa accion merece investigacion inmediata. Compartir una AMI con una cuenta externa es una operacion comun en entornos de desarrollo compartido; en una cuenta que maneja datos de clientes, es una anomalia que el equipo de seguridad necesita revisar.
La regla convierte una operacion de API neutral en una senal contextualizada. Ese contexto es lo que el operador aporta al seleccionar las reglas relevantes para cada cuenta.

Consideraciones de implementacion

Algunos puntos practicos para planificar el despliegue:
  • Prioriza cuentas de produccion: Comienza el despliegue por las cuentas con datos sensibles o requisitos de cumplimiento. Las cuentas de sandbox y desarrollo pueden habilitarse en una fase posterior.
  • Documenta las decisiones: Registra por que cada regla se habilita o no en cada cuenta. Esta documentacion es util para auditorias y para nuevos miembros del equipo.
  • Coordina con dry run: Si despliegas diez reglas de golpe en modo dry run, el volumen de metricas puede dificultar el analisis individual. Considera desplegar en grupos de tres a cinco reglas por ciclo de evaluacion.
  • Integra con el flujo existente: Los hallazgos de Custom Detection Rules usan el mismo formato y canal que los hallazgos estandar. No necesitas crear un flujo de respuesta separado, pero si conviene actualizar los runbooks existentes para cubrir los nuevos tipos de hallazgo.

Limitaciones

  • Solo soporta eventos de gestion de AWS CloudTrail. Los eventos de datos (operaciones sobre objetos de Amazon S3, invocaciones de AWS Lambda) no estan cubiertos.
  • Las reglas son predefinidas por el equipo de GuardDuty. No es posible escribir reglas personalizadas con SQL arbitrario. Si la biblioteca no incluye una regla para la actividad que te interesa, no puedes crearla.
  • El modo dry run expira a los 14 dias. Si necesitas un periodo de evaluacion mas largo, debes crear una nueva asociacion cuando la anterior expire.
  • La agregacion de senales en hallazgos sigue la logica interna de GuardDuty. No es configurable por el operador.
  • Las reglas evaluan eventos individuales. No detectan secuencias de eventos ni correlaciones temporales. Para deteccion de secuencias, las attack sequences de GuardDuty son la funcionalidad adecuada.
  • La biblioteca de reglas depende de las actualizaciones del equipo de GuardDuty. El ritmo de incorporacion de nuevas reglas no esta bajo el control del operador.

Recursos

# amazon-guardduty# threat-detection# security# incident-response# compliance
Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.
Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article