IR.2 - Triagem e Classificação de Incidentes

Nota do grupo RES (Resposta a Incidentes Integrada) da seção 15 do Framework CTH.
Deriva do Capítulo 16 do PDF de referência, controle IR.2, com os subcontroles IR.2.1 a IR.2.5.
Define a triagem como o filtro que decide onde o tempo do time é gasto, com critérios objetivos de severidade, matriz de quatro níveis, classificação por tipo de incidente, enriquecimento automático e métricas de precisão.

1. Contexto e Posicionamento no Framework CTH

Toda fila de segurança tem mais sinais do que gente, e a triagem é o ponto onde essa assimetria é resolvida para bem ou para mal. Incidentes críticos classificados como baixos dão ao adversário horas ou dias de vantagem; incidentes triviais inflados a críticos consomem o time em ruído e produzem fadiga de alerta. A classificação consistente é ainda a base das métricas confiáveis do MET.x, do reporte executivo do GOV e da melhoria contínua do programa de resposta.

No framework, o IR.2 ocupa o lugar entre a detecção e a ação: recebe alertas do DET, achados de hunt do HNT e reportes externos, decide prioridade e encaminha para o IR.1, que estrutura o caso, e para o IR.3, que executa contenção. A automação de triagem conversa com o AUT.3 e o AUT.2, que aplicam regras de classificação e enriquecimento em escala, sempre com critérios documentados e auditáveis, porque triagem sem critério explícito é opinião disfarçada de processo.

2. A Triagem como Filtro que Decide Onde o Tempo é Gasto

A pergunta operacional da triagem não é se o alerta é interessante, e sim se ele merece o próximo par de mãos disponível agora. Cada minuto gasto investigando varredura genérica é um minuto não gasto numa comunicação C2 num servidor de produção, e o adversário só precisa que o time erre uma vez nessa alocação. Por isso a triagem profissional se apoia em três pilares: critérios de severidade objetivos, enriquecimento automático que chega antes do humano e registro do raciocínio no caso.

O filtro precisa ser rápido sem ser raso. A triagem inicial de incidente crítico deve ocorrer em no máximo 15 minutos, e de incidente alto em até 1 hora, conforme o IR.2, e nesse tempo o analista não produz relatório: ele confirma que o sinal é real, estima impacto e dispara o caminho de escalada. O registro do porquê da classificação é parte da tarefa, e não burocracia, pois é ele que permite auditar precisão semanas depois e recalibrar critérios com dados reais.

3. Critérios de Severidade Objetivos

Severidade decidida por manchete de notícia ou pela voz mais alta do plantão é receita de instabilidade. O critério deve ser escrito, acordado com a alta direção, como pede o IR.2.1, e aplicar as cinco dimensões abaixo em ordem de peso negociado pela organização.

A combinação dos critérios evita os dois erros espelhados: subestimar um beacon silencioso num ativo crítico e superestimar um phishing em massa com zero cliques confirmados. Recomenda-se tabela de decisão por combinação, com exemplos reais da casa, aprovada pela direção, porque o dia do incidente não é o dia de negociar o que é crítico.

4. Matriz de Severidade com Quatro Níveis

O framework define quatro níveis com critérios claros e tempos de resposta obrigatórios. A matriz abaixo é um modelo preenchido para adaptação, com SLA de triagem, contenção e resolução por nível e o caminho de escalada correspondente.

A matriz vale apenas se for viva: cada reclassificação durante a investigação deve ser documentada com justificativa no caso, conforme o IR.2, e a taxa de reclassificação vira insumo do IR.2.5 para recalibrar critérios. Matriz que nunca muda é matriz que ninguém lê, e matriz que muda toda semana é matriz que nunca teve dono.

Dois detalhes operacionais protegem a matriz no dia a dia. O primeiro é o teto de prioridades simultâneas: definir quantos casos Críticos e Altos o plantão consegue conduzir de verdade, porque matriz que admite vinte críticos ao mesmo tempo não classifica nada, apenas redistribui o caos. O segundo é a severidade provisória na abertura: casos sem enriquecimento completo entram com severidade conservadora e revisão obrigatória em 30 minutos, evitando tanto o crítico fantasma quanto o alto esquecido.

5. Classificação por Tipo de Incidente

Além da severidade, o tipo de incidente orienta playbook, especialista e contenção esperada, e é um dos campos obrigatórios do template do IR.1.2. A tabela abaixo resume os tipos essenciais com seus sinais de abertura e o enfoque inicial típico.

O mesmo sinal pode mudar de tipo conforme a investigação avança: um phishing com clique pode virar conta comprometida, e uma conta comprometida pode ser a face visível de exfiltração. O tipo é um campo vivo, atualizado com justificativa, e a dupla tipo mais severidade determina qual playbook do AUT.1 é acionado.

6. Enriquecimento Automático na Abertura

A decisão em minutos só é possível quando o contexto chega junto com o alerta, e não depois de dez abas abertas manualmente. O enriquecimento automático na abertura do caso consulta o TIP para o IOC em questão, serviços de reputação, o CMDB para o ativo e o histórico do usuário envolvido, anexando o dossiê à página do caso antes do primeiro olhar humano. A automação aplica regras pré-definidas de classificação com base em IOC conhecidos, tipo de alerta, criticidade do ativo e contexto histórico de alertas similares, como define o IR.2.3.

Checklist de enriquecimento na abertura do caso
IOC do alerta:
  |__ Está no TIP? confiança, fonte, TLP, data de última vista
  |__ Reputação externa? DNS, WHOIS, idade do domínio, categoria no proxy
Ativo envolvido:
  |__ Existe no CMDB? criticidade, dono, ambiente, exposição externa
  |__ Tem EDR? versão do agente, última telemetria recebida
Usuário envolvido:
  |__ Cargo e privilégios? administrador, acesso a dados sensíveis
  |__ Histórico 30 dias? alertas anteriores, mudança recente de função
Contexto temporal:
  |__ Alertas similares nas últimas 72 horas? quantos, com que desfecho
Regra de decisão:
  |__ IOC de fonte primária E ativo crítico: elevar para Crítico
  |__ IOC desconhecido E ativo comum: Médio com recomendação de análise
  |__ Zero cliques confirmados em campanha em massa: Médio, processo em lote

O exemplo de fluxo automatizado da plataforma SOAR ilustra o ganho de escala: um alerta do SIEM chega, o workflow consulta o IP de destino no repositório de IOC e em serviços de reputação, e em menos de 30 segundos o caso nasce classificado com prioridade elevada ou com recomendação de investigação rápida. O humano entra para julgar o que a regra não cobre, e o registro da decisão automática fica auditável no caso.

Playbook de triagem automatizada: phishing em massa
Gatilho:  gateway de e-mail detecta campanha com mais de 50 destinatários
Passo 1:  extrair remetente, domínio, URL e hash do anexo como observables
Passo 2:  enriquecer contra TIP, reputação e veredito de sandbox
Passo 3:  classificar automaticamente:
          |__ Anexo confirmado malicioso: Alto, abrir caso único consolidado
          |__ URL confirmada de phishing: Alto, abrir caso único consolidado
          |__ Sem confirmação e zero cliques: Médio, processar em lote
          |__ Anexo limpo e domínio legítimo: Baixo, registrar e fechar
Passo 4:  no caso consolidado, listar destinatários que clicaram ou
          abriram anexo, com carimbo de cada evento
Passo 5:  se credencial digitada em página falsa, elevar para conta
          comprometida e acionar playbook de revogação de sessão
Passo 6:  recolher mensagem das caixas restantes conforme política,
          preservando amostra antes do recolhimento
Saída:    caso único com lista de afetados, severidade justificada e
          recomendação de bloqueio do domínio no proxy

O playbook mostra dois princípios que valem para qualquer triagem automatizada. O caso é único e consolidado por campanha, e não um caso por destinatário, porque cinquenta tickets iguais destroem a fila e a métrica. E a regra de elevação por credencial digitada conecta o tipo phishing ao tipo conta comprometida automaticamente, garantindo que o risco real, que é a identidade, receba o tratamento correspondente sem esperar que alguém reabra o processo.

7. SLA por Severidade e Gestão de Estouro

SLA sem consequência operacional é decoração, e estouro recorrente é sintoma de capacidade mal dimensionada. O monitoramento deve medir por nível o percentual de casos dentro do prazo de triagem, contenção e resolução, e o estouro deve acionar um caminho definido, e não apenas um e-mail de desculpa. Quando a fila de críticos ou altos ameaça estourar, o caminho mínimo é: escalar para o coordenador de plantão, reavaliar prioridade de casos abertos com olhar de portfólio, ativar reforço do segundo turno e, se o padrão persistir, acionar o GOV para decisão de capacidade.

O estouro também informa o processo. Quando P2 se acumula além da capacidade e P1 são raros, o problema pode estar na inflação de severidade, e não na falta de gente; quando P1 estoura, o problema é estrutural de playbooks, automação ou escalação. A revisão mensal do IR.2.5, que mede padrões de classificação incorreta, é o fórum que separa um do outro com dados.

8. Erros de Triagem Frequentes

• Severidade inflada por manchete: notícia de ataque no setor empurra a casa para crítico sem qualquer evidência local; o critério é a evidência interna, e a manchete entra como contexto no caso, e não como severidade.
• Fila infinita de P2: tudo é importante, então nada é; sem teto de prioridades e sem downgrading documentado, o time vive no Alto e ignora o Médio de verdade.
• Triagem sem registro do porquê: classificação sem justificativa escrita impede auditoria de precisão, esconde viés do plantão e impede o ajuste de critérios com dados do IR.2.5.
• Enriquecimento manual e tardio: analista caçando reputação em dez abas queima minutos críticos e padroniza mal; a coleta de contexto deve ser automática na abertura.
• Severidade que nunca é rebaixada: medo de reclassificar mantém casos críticos semanas na fila, corroendo a credibilidade da matriz inteira.
• Escalonamento por apelido: notificar a pessoa que conhece em vez de seguir a matriz do IR.2.2 funciona até o dia em que essa pessoa está de férias; matriz e contatos de plantão existem para esse dia.

9. Métricas de Triagem

A precisão de severidade merece leitura cuidadosa, porque taxa de reclassificação alta em um sentido específico conta uma história: se casos Médios sobem para Alto com frequência, o critério está subestimando impactos; se Altos descem para Médio com frequência, o plantão está inflando por prudência ou pela manchete do dia. A meta não é zero reclassificação, que indicaria critério rígido demais para a realidade, e sim reclassificação em faixa estreita e documentada.

10. Implementação e Salvaguardas por Nível

O salto do IR.2.2 para o IR.2.3 é o que transforma a matriz em comportamento em escala, e por isso exige que a matriz esteja madura: automatizar critério mal escrito apenas distribui o erro mais rápido. Já o IR.2.5 pressupõe meses de dados de casos estruturados no IR.1, reforçando a dependência entre os controles do grupo.

11. Integração com Outros Controles do Framework CTH

O IR.2 consome criticidade de ativo do INS.1, confiança de IOC do PLT.1 e contexto de detecção do grupo DET, e devolve prioridade ao IR.1, que estrutura o caso, e ao IR.3, que executa a contenção no ritmo que a severidade determina. A reclassificação automática do IR.2.4 depende do enriquecimento contínuo do AUT.2 e do AUT.3, e as métricas de precisão alimentam o MET.x e a revisão executiva do GOV. Achados que chegam de hunt do HNT passam pela mesma porta, com severidade provisória conservadora até a verificação, o que mantém um só vocabulário de prioridade para toda a esteira.