Enriquecimento Automático de Incidentes com Dados EASM

Nota 01 da subseção 04 do capítulo 21, que conecta a gestão de exposição ao ciclo operacional de resposta a incidentes.
O foco é injetar contexto de EASM na triagem: o analista precisa saber, no primeiro minuto, se o host do alerta está exposto, de quem ele é e como está configurado.
Dialoga com a nota de Correlação com CSPM desta subseção, com o controle RES de triagem da seção 15 e com a automação de coleta do capítulo 02.

1. Contexto e Posicionamento na Biblioteca

A triagem é o momento de maior escassez de contexto e de maior custo do erro. O analista recebe um alerta sobre um host identificado por nome curto ou endereço IP, e começa a responder perguntas cujas respostas já existem em outro sistema: o host aparece no EASM como exposto à internet, pertence à conta de qual time, tem qual serviço publicado, foi encontrado com qual configuração no último ciclo de correlação. Quando essa recuperação é manual, ela acontece em metade das triagens e consome minutos preciosos; quando é automatizada, todo incidente nasce com o contexto de exposição anexado, e a fila inteira ganha qualidade de decisão.

Esta nota é a primeira metade da subseção de integração EASM-SIEM-SOAR: ela desenha a arquitetura de enriquecimento na triagem, define o conjunto mínimo de campos de contexto e apresenta um incidente enriquecido como exemplo completo. A nota seguinte assume o contexto entregue e descreve os workflows de remediação que agem sobre ele. O objetivo prático é que o leitor saia daqui com o desenho técnico de um serviço de enriquecimento, incluindo cache, limites e degradação graciosa, pronto para ser implementado sobre qualquer plataforma de resposta a incidentes.

2. O Que o Contexto EASM Muda na Triagem

O enriquecimento com EASM responde a quatro perguntas que determinam a rota do incidente. A primeira é alcance: o ativo afetado é alcançável da internet, o que altera a hipótese de entrada e a urgência de contenção. A segunda é propriedade: a quem o ativo pertence, qual time responde e qual contrato de nível de serviço se aplica, o que evita os minutos perdidos caçando dono. A terceira é configuração: o ativo tem desvios de configuração vigentes, e quais deles participam do escore de exposição, o que antecipa a hipótese de caminho do adversário. A quarta é histórico: o ativo já teve exposições corrigidas recentemente, padrão que indica regressão ou esforço deliberado de reconquista.

O efeito agregado aparece na distribuição de prioridades da fila. Um incidente de força bruta em servidor interno isolado e um incidente de força bruta em servidor de borda exposto têm o mesmo evento bruto, mas pesos de risco muito diferentes, e a triagem sem contexto os trata igual. Com o contexto, a mesma telemetria produz ordens de serviço distintas, e a métrica de dwell time se beneficia porque os incidentes de maior risco sobem na fila sem depender do acerto aleatório do analista de plantão.

Há também o efeito silencioso, medido em tempo de analista. Em filas sem contexto, parcela significativa do primeiro minuto de cada triagem é gasta em recuperação de informação que existe em outro sistema: quem é o dono, o que roda naquele host, se já houve exposição ali. Multiplicado pela fila diária, esse custo soma horas por semana, e a automação devolve exatamente esse tempo para análise. O enriquecimento é, por isso, uma das automações de melhor retorno no SOC, porque não exige mudança de telemetria nem de processo, apenas a publicação do contexto que já existe na junção de EASM, CSPM e inventário.

3. Arquitetura de Enriquecimento na Triagem

A arquitetura recomendada é um serviço de enriquecimento intermediário, e não consultas diretas da plataforma de incidentes a cada fonte. O serviço expõe uma interface única de consulta por identificador de ativo, nome de host, endereço IP ou identificador de nuvem, e é responsável por resolver o identificador no inventário unificado, agregar os dados de EASM e CSPM, aplicar cache com janela curta e devolver o bloco de contexto em formato estável. Essa camada intermediária existe por três razões: isola a plataforma de incidentes das mudanças de schema das fontes, controla o volume de consultas contra as APIs de EASM e centraliza a política de dados, incluindo o que é entregue em triagem e o que só é entregue em investigação aprofundada.

Plataforma de incidentes: alerta criado
   |
   | (webhook ou automacao na criacao)
   v
Servico de enriquecimento: resolve ativo no inventario unificado
   |
   +-- EASM: exposicao, servico publicado, ultima varredura
   +-- CSPM: desvios de configuracao vigentes no ativo
   +-- CTI: reputacao de origem e ator associado ao padrao
   |
   v
Bloco de contexto anexado ao incidente (campos minimos)
   |
   v
Triagem com severidade recalculada e roteamento por fila

Três requisitos não funcionais decidem se o enriquecimento é adotado ou sabotado pela operação. Latência: a chamada deve responder em centenas de milissegundos com cache e em poucos segundos sem ele, porque enriquecimento que atrasa a triagem é contornado manualmente. Disponibilidade: a falha do serviço de enriquecimento não pode falhar a criação do incidente, e a degradação grácil devolve o incidente sem contexto com marcação explícita de gap. Rastreabilidade: toda consulta e todo bloco entregue ficam registrados com carimbo, porque o contexto influenciou a decisão de triagem e a resposta posterior a incidentes precisa poder reconstruir o que o analista sabia naquele minuto.

O momento da chamada também tem desenho. O gatilho padrão é a criação do incidente, via webhook ou automação nativa da plataforma, com reenriquecimento nas transições de estado relevantes, como reabertura e escalonamento. O gatilho complementar é a mudança de dados: quando o escore de exposição do ativo muda enquanto o incidente está aberto, o serviço empurra atualização do bloco, porque a exposição criada às três da tarde altera a triagem do incidente aberto desde a manhã. Esses dois gatilhos juntos cobrem o ciclo de vida do incidente sem spam de atualizações.

4. Campos Mínimos de Contexto

O bloco de contexto mínimo cabe em uma tela de triagem e segue a regra de ouro do enriquecimento: cada campo precisa mudar alguma decisão, e campo que não muda decisão sai. A tabela abaixo define o conjunto mínimo com sua finalidade operacional explícita.

O campo de telemetria disponível merece justificativa, porque parece metadado e é instrumental. Saber na triagem que o ativo tem EDR, mas não tem logs de fluxo, ou tem log de acesso web, mas não tem autenticação centralizada, define o que o analista pode buscar na primeira hora e o que precisará ser pedido a outra equipe. Esse campo conecta o enriquecimento ao controle de coleta da seção 15, e sua presença sistemática nos incidentes transforma gaps de telemetria em itens de trabalho para o grupo de dados, fechando outro ciclo entre resposta e melhoria de coleta.

O conjunto mínimo é extensível por tipo de incidente, e a extensão segue o mesmo critério de decisão. Incidentes com origem externa ganham campos de reputação e infraestrutura da origem; incidentes de identidade ganham mapeamento de permissões da identidade afetada; incidentes em nuvem ganham a conta e a região com a política de acesso vigente. O serviço mantém os campos mínimos fixos para todas as classes e anexa os blocos extensivos por tipo, e o controle de evolução é a mesma disciplina de qualquer API: adicionar campo é barato, renomear ou remover exige deprecação anunciada, porque outros workflows já consomem o bloco.

5. Exemplo de Incidente Enriquecido

O exemplo a seguir mostra um incidente antes e depois do enriquecimento, com o bloco de dados que o serviço devolve para uma autenticação suspeita em servidor de aplicação.

{
  "incidente": "INC-2026-04218",
  "alerta_origem": "anomalia de autenticacao em app-prod-03",
  "enriquecimento_easm": {
    "identidade_do_ativo": {
      "id_global": "aws-123456789012-us-east-1-i-0abc123",
      "nome": "app-prod-03",
      "ip": "203.0.113.44",
      "provedor": "aws",
      "conta": "producao-relatorios"
    },
    "exposicao_externa": {
      "alcançavel": true,
      "servico_publicado": "HTTPS 443 via balanceador",
      "porta_direta": "22 aberto em 0.0.0.0/0",
      "evidencia": "varredura de 2026-02-04T03:00Z"
    },
    "escore_de_exposicao": {"valor": 85, "calculado_em": "2026-02-04T03:00Z"},
    "proprietario": {"time": "plataforma-relatorios", "canal": "#sre-relatorios"},
    "desvios_vigentes": [
      "grupo de segurança com 22 aberto em 0.0.0.0/0",
      "agente de coleta de autenticação desativado"
    ],
    "exposicoes_recentes": [
      {"id": "IOE-2026-0210", "classe": "porta de gerência exposta", "corrigido_em": "2026-01-28"}
    ],
    "criticidade": "alta",
    "telemetria_disponivel": ["EDR", "log de acesso web", "trilha de nuvem"]
  },
  "severidade_recalculada": "critica",
  "rota": "fila de contenção imediata"
}

A implantação do enriquecimento segue uma sequência que reduz risco e constrói confiança na operação:

• Mapear os identificadores: garantir que alerta e inventário compartilham chave de junção, com tabela de resolução para nome curto, FQDN, IP e identificador de nuvem.
• Construir o serviço com cache e degradação: entregar o bloco em centenas de milissegundos com cache e nunca bloquear a criação do incidente por falha de fonte.
• Operar em modo espelho: anexar o contexto sem alterar severidade nem roteamento por duas semanas, medindo o que mudaria, para calibrar pesos com a operação.
• Ativar o efeito na fila: recalcular severidade e roteamento com os pesos calibrados, publicando o critério de mudança para o time de triagem.
• Revisar o conjunto de campos: remover os campos que nunca mudaram decisão nos primeiros ciclos e avaliar extensões por tipo de incidente.

A leitura do bloco mostra por que a severidade subiu para crítica e a rota mudou para contenção imediata. O alerta bruto de autenticação anômala seria médio num servidor qualquer; o contexto revela que o servidor tem SSH aberto ao mundo, que já teve IOE de porta de gerência corrigido há uma semana e que a coleta de autenticação local está desativada, o que significa tanto que o sinal vem de fonte indireta quanto que o adversário pode ter apagado a fonte. Cada campo mudou uma decisão, cumprindo a regra de ouro do conjunto mínimo, e a nota de workflows da subseção descreve o que acontece em seguida: a tarefa de fechamento da porta 22 entra na fila de remediação com dono e prazo.

O mesmo exemplo ilustra o histórico de exposição como hipótese investigativa. A porta 22 fechada na correção do IOE-2026-0210 reapareceu aberta em menos de uma semana, e regressão com essa velocidade raramente é acidente: ou a infraestrutura como código recria a regra a cada deploy, ou alguém reabre a porta por necessidade operacional não formalizada, ou há movimento de adversário no canal de mudanças. A triagem enriquecida registra essa hipótese desde o primeiro minuto e direciona a investigação para o histórico de mudanças do grupo de segurança, exatamente o tipo de direcionamento que a caça dirigida por exposição da biblioteca incentiva.

6. Erros Comuns e Pontos de Atenção

• Enriquecer com tudo e sobrecarregar a triagem: bloco de contexto com dezenas de campos compete com o alerta e é ignorado; o conjunto mínimo que muda decisão vence o dicionário completo.
• Consultar fontes na hora sem cache: API lenta na criação de incidente atrasa a fila inteira e descredita a automação; cache com janela curta e degradação grácil são parte do desenho, não otimização posterior.
• Usar contexto vencido sem marcar a idade: exposição de três dias atrás pode ter mudado, e o bloco precisa carregar o carimbo de cálculo; contexto sem data é pior que ausência de contexto.
• Deixar o enriquecimento apenas informativo: contexto que não recalcula severidade nem muda roteamento é decoração; a integração precisa alterar a fila, senão o time para de olhar.
• Enriquecer só na criação do incidente: incidentes longos atravessam mudanças de exposição, e o reenriquecimento em cada mudança de estado mantém o contexto honesto ao longo do ciclo.
• Ignorar a política de acesso ao contexto: o bloco descreve como atacar o ativo, e sua visibilidade dentro da plataforma de incidentes segue o mesmo controle aplicado a inteligência sensível.
• Construir o enriquecimento acoplado a uma plataforma: o serviço precisa ser um componente independente consumível por webhook e por API, porque a plataforma de incidentes muda de fornecedor e o contexto de exposição deve sobreviver a essa mudança.

7. Integração com o Restante da Biblioteca

As conexões estruturais desta nota com o restante da biblioteca seguem quatro caminhos:

• Capítulo 02: a automação de coleta e o enriquecimento de indicadores são o precedente metodológico do serviço aqui desenhado, com as mesmas preocupações de latência e proveniência.
• Capítulo 21: a descoberta multi-cloud e a correlação com CSPM são as fontes de dados do enriquecimento, e a nota de workflows de remediação é o consumidor natural do bloco.
• Seção 15: o controle RES.2 de triagem é o ponto de inserção, o grupo DAT explica o campo de telemetria disponível e o grupo MET mede o efeito do contexto na priorização.
• Capítulo 11: a métrica de redução de dwell time por priorização com contexto é a prova de valor do enriquecimento no reporte executivo.

A métrica que fecha o ciclo mede o efeito do contexto na fila: proporção de incidentes cuja severidade mudou após o enriquecimento e tempo médio economizado na recuperação manual de dono e configuração. A expectativa operacional é que a maioria das mudanças de severidade seja para cima nos ativos expostos e para baixo nos ativos internos isolados, e a presença das duas direções é o sinal de que o contexto está calibrado; enriquecimento que só aumenta severidade para todo mundo é ruído com formato de automação.