# Remediation plans no Security Hub: remediação por causa raiz, dissecada

Em 1º de outubro de 2026 o Security Hub ganhou remediation plans: em vez de uma fila de findings, um plano por causa raiz, com impacto estimado e instruções em CLI, Terraform, CloudFormation, Python e CDK. Disseco o padrão de remediação por causa raiz, o problema que ele resolve, a anatomia, quando usar e quando não, e o detalhe que merece mais atenção: agentes de IA consumindo planos via API.

- URL: https://fernando.moretes.com/blog/remediation-plans-no-security-hub-remediacao-por-causa-raiz-dissecada

- Markdown: https://fernando.moretes.com/blog/remediation-plans-no-security-hub-remediacao-por-causa-raiz-dissecada/article.md?lang=pt

- Published: 2026-10-02T10:14:55.810Z

- Category: Segurança & Resiliência

- Tags: security-hub, exposure-management, remediation, root-cause, iam, ai-agents, governance, finops

- Reading time: 6 min

- Source: [AWS Security Hub introduces remediation plans to prioritize and fix security exposures](https://aws.amazon.com/about-aws/whats-new/2026/10/aws-security-hub-remediation-plans/)

---

A pergunta perigosa num programa de exposure management não é "quantos findings fechamos esta semana?", é "quantos findings um único fix fecha?". Depois de 16 anos operando plataformas financeiras sobre AWS, vi times inteiros medindo a primeira e ignorando a segunda. Em 1º de outubro de 2026 o AWS Security Hub lançou remediation plans, que agrupam exposure findings pela causa raiz compartilhada, e com isso transformou um recurso de console no que me interessa aqui: um padrão de arquitetura de remediação que vale dissecar.

## O problema: a esteira de findings

Durante anos o modelo operacional de segurança na AWS foi o finding individual: cada controle do CSPM, cada CVE do Inspector, cada detecção do GuardDuty vira um item na fila, e o time mede o que a fila deixa medir, findings fechados por semana. O padrão que a AWS publicou em janeiro de 2020, resposta automatizada via custom actions, EventBridge e Lambda, automatizou exatamente isso: uma função por tipo de finding, mais de 20 remediações do CIS Benchmark, cada uma tratando um sintoma. Funciona, e a fila volta a crescer na segunda seguinte, porque a causa continua lá.

A matemática joga contra o modelo por sintoma. Uma policy IAM que permite `kms:Decrypt` com `Resource: "*"` não é um problema: é um trait que aparece em cada exposure finding de cada principal que a carrega. Trocar a policy é uma mudança; fechar os findings um a um são dezenas de tickets que descrevem a mesma mudança com palavras diferentes.

Os exposure findings, que o Security Hub já gerava antes deste anúncio, faziam metade do caminho: correlacionam sinais de GuardDuty, Inspector, Security Hub CSPM e Macie num finding por recurso, um recurso é primário em no máximo um exposure finding, com attack path e blast radius visualizados. Os remediation plans fecham a outra metade: invertem o índice. Em vez de indexar o trabalho pelo que foi detectado, indexam pelo que você precisa consertar. É a diferença entre uma lista de sintomas e um diagnóstico.

## Anatomia: o que vem dentro de um plano

Cada remediation plan carrega quatro coisas: a prioridade (Critical, High, Medium ou Low), uma avaliação de impacto da mudança, o conjunto de exposições que ele resolve ou rebaixa, e instruções passo a passo em cinco formatos: AWS CLI, Terraform, CloudFormation, Python e CDK. O Security Hub ordena os planos automaticamente: o que reduz mais risco aparece primeiro. E o dado que muda o desenho de automação: agentes de IA podem consumir os planos programaticamente via API.

Por baixo, a matéria-prima são os traits dos exposure findings. Traits de misconfiguração são os conhecidos: usuário IAM sem MFA, access keys sem rotação há mais de 90 dias, `kms:Decrypt` irrestrito. Traits de impacto são o catálogo de caminhos de escalação que o Security Hub calcula sobre as permissões efetivas: *trust policy hijack path*, *credential minting path*, *data ransomware path*, *disable audit trail path*. Traits contextuais vêm do IAM Access Analyzer: a documentação usa o exemplo de uma instância EC2 vulnerável cuja role tem 47 permissões não usadas em 5 serviços, é o blast radius dizendo que aquele CVE vale mais do que o CVSS sugere.

Programaticamente, os recursos de um finding saem via `GetFindingsV2`. Custo: os planos entram sem cobrança adicional no plano Essentials, que é pay-as-you-go por unidade de recurso, uma instância EC2 vale 1 unidade, uma função Lambda 1/12, um recurso IAM 1/125, com trial de 30 dias por conta e região.

## O padrão: de N sintomas para 1 correção

Sinais correlacionados viram exposições; exposições com a mesma causa raiz viram um plano; o plano vira uma mudança no pipeline de IaC, e uma mudança resolve N exposições.

### 📥 AWS: Sinais de segurança

- GuardDuty threat findings (security)
- Inspector CVEs + reachability (security)
- Security Hub CSPM control checks (security)
- Macie sensitive data (security)

### 🧠 AWS: Security Hub (Essentials)

- Correlation engine traits + attack paths (ai)
- Exposure findings 1 por recurso / 1 per resource (data)
- Remediation plan agrupado por causa raiz (security)

### 🔧 Operação: Consumo do plano

- Time de segurança impact assessment + ticket (user)
- Agente de IA consome plano via API (ai)
- Pipeline IaC PR Terraform / CDK (ci)

### 🎯 Alvo: Causa raiz

- Recurso único ex.: IAM policy permissiva (compute)

### Fluxos

- gd -> corr: sinais
- insp -> corr
- cspm -> corr
- macie -> corr
- corr -> expo: correlaciona traits
- expo -> plan: agrupa por causa raiz
- plan -> human: ordenado por risco reduzido
- plan -> agent: API
- human -> iac: PR com snippet do plano
- agent -> iac: PR + aprovação humana
- iac -> root: apply na janela de mudança
- root -> expo: N exposições resolvidas de uma vez

## Quando usar, e quando não

Use remediação por causa raiz quando: você opera dezenas de contas com estado gerenciado por IaC, o backlog de findings cresce mais rápido do que o time fecha, e existe processo formal de mudança: PCI-DSS, BACEN 4.893, que torna cada correção cara o bastante para valer o agrupamento. Nesse cenário o plano vira a unidade natural de trabalho: um ticket, um PR, uma janela, N exposições a menos.

**A armadilha do passo a passo:** o plano traz instruções de console e CLI, e é aí que mora o drift. Se o recurso é gerenciado por Terraform e alguém aplica o fix pelo console, o próximo `terraform apply` reverte a correção em silêncio, a exposição volta sem ninguém tocar em nada. Dos cinco formatos que o plano oferece, o único que vale para recurso gerenciado é o que entra no seu pipeline: Terraform, CloudFormation ou CDK, via PR.

Não use como substituto do padrão por finding em tudo. Correções estreitas, reversíveis e urgentes, bloquear acesso público num bucket S3, por exemplo, continuam melhores no modelo 2020: EventBridge, Lambda, segundos de latência. E se o seu acervo é pequeno, meia dúzia de contas sem IaC consistente, o custo de montar a esteira de consumo supera o ganho: nesse caso a lista priorizada do console, lida por um humano toda semana, já entrega a maior parte do valor.

## Três modos de consumir remediação
| Critério | Automação por finding (2020) | Plano via pipeline IaC | Agente de IA via API |
| --- | --- | --- | --- |
| Unidade de correção | 1 finding → 1 Lambda | 1 causa raiz → 1 PR | 1 plano → 1 mudança proposta |
| Melhor para | Fixes estreitos e reversíveis, latência de segundos | Acervo gerenciado por IaC com change management formal | Volume alto com revisão humana no PR |
| Modo de falha típico | Trata o sintoma; a fila regenera | Lento demais para exposição ativa crítica | Agente privilegiado vira o novo caminho de escalação |

## Agentes de IA consumindo planos: o detalhe que exige desconfiança

O anúncio diz, de passagem, que agentes de IA podem consumir os planos via API para automatizar correções. Lido junto com o Well-Architected Agent em preview, o movimento é claro: a AWS está transformando orientação operacional em artefato legível por máquina. Para quem desenha plataformas, isso é bom, plano estruturado com impacto estimado é um contrato muito melhor para um agente do que texto de runbook.

Mas o agente que aplica remediação é, por definição, um principal privilegiado que modifica IAM, KMS e rede. O catálogo de impact traits do próprio Security Hub: *credential minting path*, *disable audit trail path*, *remove restriction path*, lê-se como a lista do que um agente de remediação comprometido ou apenas confuso conseguiria fazer. O custo aqui não é o de construir a automação, é o de manter, auditar e conter um principal poderoso por anos.

Minha regra para ambiente financeiro: o agente propõe, o pipeline dispõe. O agente lê o plano via API, gera o PR com o snippet Terraform e a avaliação de impacto no corpo, e para ali. A role dele leva permission boundary sem `iam:*` nem `kms:PutKeyPolicy`, e toda ação sai com rastro em CloudTrail num trilho que ele não pode desligar. Aplicação automática sem humano no circuito, só para a classe de mudança que você já aprovou por categoria, e nunca para mudança de policy IAM.

## Anti-padrões de remediação por causa raiz

- **Corrigir pelo console o que o Terraform gerencia**: o próximo `terraform apply` reverte o fix em silêncio e a exposição reaparece sem mudança visível, use o snippet Terraform/CDK do plano, via PR.
- **Agente remediador com permissão ampla**: dar `iam:*` ao agente que consome planos cria exatamente o *credential minting path* que o Security Hub existe para detectar.
- **Medir findings fechados em vez de risco reduzido**: o KPI por finding premia fechar 40 sintomas um a um e pune a única mudança que resolveria todos, o plano já traz a ordenação por risco; use-a como métrica.
- **Aplicar plano Critical fora de janela por ser "só segurança"**: restringir um security group ou uma policy em produção derruba integração legítima, a avaliação de impacto do plano existe para ser lida antes do apply, não depois do incidente.
- **Manter a automação por finding competindo com os planos**: o Lambda de 2020 corrigindo o sintoma enquanto o PR do plano corrige a causa produz duas mudanças concorrentes no mesmo recurso, escolha o trilho por classe de recurso e desligue o outro.

> **Trate o plano como entrada de PR, não como checklist de console:** Dos cinco formatos de instrução, padronize um: Terraform ou CDK, o que o seu pipeline já fala, e faça do plano o corpo do PR: snippet, avaliação de impacto e a lista de exposições que ele resolve. O console fica para break-glass. Assim a correção herda de graça o que o seu change management já tem: revisão, histórico, rollback e auditoria.

> **Nota do curador:** Eu começaria numa conta de não-produção com o trial de 30 dias do Essentials, roteando só os planos Critical para tickets com o snippet Terraform anexado, e mediria uma coisa: exposições resolvidas por mudança aplicada. No primeiro mês esse número conta se o agrupamento por causa raiz funciona no seu acervo ou se vira só mais uma lista. A lição dura por trás da minha desconfiança com o consumo por agente: em ambiente financeiro, a correção que contorna o change management custa mais caro que a exposição que ela corrige, já vi um "fix rápido" de security group derrubar a integração de liquidação que a exposição nunca ameaçou. Agente propõe PR; humano aprova mudança de IAM; sempre.

## Veredito

Adote o padrão de remediação por causa raiz se você já roda Security Hub Essentials: o plano vem sem custo adicional e a inversão do índice, de sintoma para correção, é o que faltava para o backlog de exposições virar fila de mudanças de verdade. Condições: correção entra pelo pipeline de IaC (Terraform/CDK do plano, nunca o passo a passo de console em recurso gerenciado), a métrica vira risco reduzido por mudança, e o consumo por agente de IA fica limitado a propor PRs, com permission boundary, sem `iam:*`, com humano aprovando mudança de identidade. Mantenha a automação por finding só para a classe estreita e reversível. O que decide não é a feature, é se a sua esteira de mudança consegue absorver o que o plano propõe.

**Rating:** adopt-with-guardrails

## Referências

- [AWS What's New: Security Hub introduces remediation plans (Oct 1, 2026)](https://aws.amazon.com/about-aws/whats-new/2026/10/aws-security-hub-remediation-plans/)
- [AWS Security Hub User Guide: Exposure findings](https://docs.aws.amazon.com/securityhub/latest/userguide/exposure-findings.html)
- [AWS Security Hub User Guide: Remediating exposures for IAM users](https://docs.aws.amazon.com/securityhub/latest/userguide/exposure-iam-user.html)
- [AWS Security Hub: Pricing (Essentials, resource units, 30-day trial)](https://aws.amazon.com/security-hub/pricing/)
- [AWS What's New: GuardDuty Runtime Monitoring included in Security Hub Threat Analytics (Oct 2, 2026)](https://aws.amazon.com/about-aws/whats-new/2026/10/aws-security-hub-runtime-monitoring/)
- [AWS Security Blog: Automated response and remediation with AWS Security Hub (2020)](https://aws.amazon.com/blogs/security/automated-response-and-remediation-with-aws-security-hub/)