Como reduzir o alert fatigue personalizando as detecções do Amazon GuardDuty

O ponto central do post da AWS é que a detecção gerenciada do GuardDuty funciona igual para todos os clientes, mas o ambiente de cada um não. Compartilhar uma AMI publicamente é rotina numa conta que distribui imagens e um possível incidente em qualquer outra. O mesmo vale para desativar VPC Flow Logs ou entrar sem MFA numa conta de serviço legada. Até as Custom Detection Rules, não havia como refletir essa diferença no serviço.

As Custom Detection Rules são uma biblioteca de regras prontas e opcionais, mantida pela AWS. No lançamento, são 90 regras sobre eventos de gerenciamento do CloudTrail e do Runtime Monitoring, que geram 38 tipos de finding mapeados para 13 táticas do MITRE ATT&CK. Cada regra roda em dry run (só publica métricas no CloudWatch, sem findings, e expira em 14 dias) ou em modo live, sem expiração. A métrica a observar é a CustomRuleDryRunSignalsMatched. Volume sozinho não diz se a atividade é benigna: se alguém explica o processo que causa os matches, a conta é má candidata a live; se ninguém explica, vale investigar.

Outros pontos: as listas de entidades aceitam IPs, CIDRs e domínios num só arquivo, com cobertura de DNS que as listas de IP não têm, e agora também hashes SHA-256. Um hash que bate com uma lista ativa gera o finding de severidade alta Execution:Runtime/MaliciousFileExecuted.Custom. Se a lista mudar, é preciso reativá-la. Na triagem, suppression rules arquivam o finding (retido por 90 dias, mas sem envio a Security Hub, S3, Detective ou EventBridge). Os filtros ganharam os operadores Matches e NotMatches e mais de 1.000 campos de critério, o que permite restringir a regra, por exemplo, a um namespace Kubernetes.

Em 23 de julho de 2026, o CEVIU noticiou "Amazon GuardDuty: a evolução da detecção de ameaças na AWS", sobre a ampliação do serviço para S3, EKS, RDS e EC2. O post atual mostra o passo seguinte: além de ampliar a cobertura, a AWS entrega ferramentas para ajustar a detecção ao contexto de cada conta. Em 20 de fevereiro de 2026, o CEVIU também tratou de fadiga de alertas no CloudWatch, com as regras de silenciamento de alarme, um problema parecido em outro serviço.

Para quem opera SOC ou gerencia contas AWS em escala, a leitura é prática: o dry run permite medir o ruído antes de uma regra encher a fila, e suppression rules com padrões evitam listas que envelhecem a cada deploy. Cuidado com o escopo: suprimir amplo demais esconde o mesmo comportamento onde ele seria anormal.