GuardDuty ganha mais de 50 regras opcionais de detecção para o Runtime Monitoring

A Amazon anunciou em 19 de outubro de 2026 um conjunto de mais de 50 regras opcionais de detecção para o Runtime Monitoring do Amazon GuardDuty. São regras configuráveis que olham para atividade de processo, arquivo e rede dentro da carga de trabalho em execução, não apenas para os sinais que o GuardDuty já correlaciona por conta própria.

Para quem administra GuardDuty em produção, a mudança resolve um incômodo conhecido: comportamento que é rotina num ambiente (um script que lê /etc/shadow para auditoria interna, por exemplo) pode ser exatamente o sinal de comprometimento em outro. Até aqui, o Runtime Monitoring detectava esse tipo de atividade com uma lógica fixa, sem espaço para o analista dizer "isso aqui, no meu ambiente, é esperado" ou "isso aqui nunca deveria acontecer".

O que as novas regras cobrem

As regras opcionais detectam atividade como modificação do arquivo sudoers, desativação de log de auditoria e outras ações que tocam diretamente em persistência e evasão de defesa. A cobertura alcança três superfícies de computação:

• Instâncias Amazon EC2
• Amazon EKS
• Amazon ECS, tanto em EC2 quanto em AWS Fargate

Ao todo, são 13 tipos de finding mapeados para táticas do MITRE ATT&CK®, incluindo persistência, escalonamento de privilégio, execução, evasão de defesa, descoberta, exfiltração e comando e controle. Esse mapeamento para o MITRE ATT&CK é o mesmo vocabulário que times de resposta a incidentes já usam em playbook e em relatório para liderança, o que facilita encaixar o alerta do GuardDuty direto no processo existente.

Quatro tipos de alerta novos

O lançamento também introduz quatro finding types que não existiam antes no GuardDuty:

• CommandAndControl:Runtime/SuspiciousCommand
• CredentialAccess:Runtime/SensitiveFileRead
• Discovery:Runtime/SensitiveFileRead
• Exfiltration:Runtime/SuspiciousCommand

Os nomes já indicam a intenção: dois giram em torno de leitura de arquivo sensível (um visto como acesso a credencial, outro como reconhecimento do ambiente) e dois giram em torno de comando suspeito executado no host (um como exfiltração, outro como comunicação com infraestrutura de comando e controle). É a mesma atividade técnica interpretada por ângulos diferentes, o que ajuda o analista a priorizar: um comando suspeito que também bate com padrão de exfiltração pesa mais do que um alerta isolado de descoberta.

Como ativar, e por que o modo dry-run importa

As regras ficam disponíveis no console do GuardDuty, dentro do recurso que a AWS chama de Custom Detection Rules para Runtime Monitoring. O ponto prático para quem opera isso no dia a dia é a opção de ligar uma regra em modo dry-run antes de deixá-la gerando alerta de verdade.

A AWS descreve o dry-run como uma forma de avaliar a eficácia de detecção da regra antes de ativar a detecção ao vivo. Na prática, isso dá ao time de segurança uma janela para medir taxa de falso positivo contra o tráfego real do ambiente antes de comprometer a fila de triagem do SOC. Só depois de validar que a regra não está gerando ruído desproporcional é que faz sentido promovê-la para detecção ao vivo.

Esse fluxo de teste controlado importa especialmente em ambiente com cargas heterogêneas: um cluster EKS que roda ferramentas de observabilidade com acesso amplo a arquivo do sistema pode disparar uma regra de leitura sensível que seria, em outro cluster, sinal claro de ataque. O dry-run é o espaço para calibrar isso regra por regra, carga por carga, sem arriscar alert fatigue logo na largada.

Onde está disponível e o que fica em aberto

As Custom Detection Rules para Runtime Monitoring estão disponíveis em todas as regiões comerciais da AWS e nas regiões AWS GovCloud (US). Isso inclui a região São Paulo (sa-east-1), então quem já roda Runtime Monitoring habilitado por aqui pode ir direto ao console e começar a testar as regras sem esperar expansão regional.

O anúncio da AWS não traz detalhe de custo adicional associado às novas regras, nem lista de exemplo completa das mais de 50 regras disponíveis além das quatro citadas. Para o detalhamento técnico de cada regra e da sintaxe de customização, a própria AWS remete à documentação de Amazon GuardDuty Custom Detection Rules, que é o ponto de partida recomendado antes de sair habilitando regra em produção.

Para quem quer acompanhar próximos lançamentos do GuardDuty sem depender de buscar o What's New manualmente, a AWS mantém um tópico SNS dedicado a atualizações programáticas do serviço, que vale assinar se a rotina do time já envolve automação de alertas de segurança.

Fonte: AWS What's New