CTI.3 - Papéis e Responsabilidades

Nota integrante do grupo GOV (Governança e Modelo de Maturidade) da seção "15 - Framework CTH - Controles".
Deriva do Capítulo 4 do Framework CTH, controle CTI.3, e define quem faz o quê no programa de CTI e Threat Hunting.
A clareza de papéis evita duplicidade de esforço, lacunas de cobertura e dependência excessiva de indivíduos específicos.

1. Contexto e Posicionamento no Framework CTH

O controle CTI.3 do Capítulo 4 do Framework CTH estabelece que a definição clara de papéis e responsabilidades evita ambiguidade, duplicação de esforços e lacunas na cobertura das atividades de CTI e Threat Hunting. Cada membro da equipe deve compreender suas atribuições, suas entregas esperadas e como seu trabalho contribui para os objetivos gerais do programa. Em programas reais, a maior parte dos conflitos entre SOC, IR e CTI não nasce de má vontade, e sim de papéis implicitamente negociados no dia a dia, que mudam conforme a pressão do momento.

Este controle opera sobre a estrutura criada por CTI.1 e CTI.2: o patrocínio fornece as pessoas e o posicionamento define onde elas vivem, e CTI.3 define o que cada uma delas faz. O documento de referência apresenta uma tabela de papéis com responsabilidades, competências-chave e nível de senioridade, que esta nota expande com matriz RACI, critérios de distinção entre funções vizinhas e estratégias para equipes pequenas. O objetivo final é que qualquer atividade de inteligência tenha um dono inequívoco, mesmo quando executada por alguém que acumula outros papéis.

2. Por Que Papéis Definidos São Pré-Condição de Escala

Programas informais funcionam com três ou quatro pessoas, porque todos sabem de tudo e conversam o tempo todo. O problema aparece exatamente no momento em que o programa cresce: atividades começam a ser executadas duas vezes por pessoas diferentes, ou não executadas porque cada um assumia que era responsabilidade do outro. A falta de definição formal também impede contratação consciente, já que sem descrição de papel não se sabe qual lacuna a nova contratação fecha.

Há ainda um risco menos visível, mas severo, apontado pelo próprio controle CTI.4 do framework: a concentração de conhecimento em poucos indivíduos cria vulnerabilidade operacional quando um membro-chave sai. Papéis documentados, com entregas associadas e competências mapeadas na matriz de competências, permitem identificar essa concentração e distribuí-la deliberadamente. Por fim, papéis claros sustentam as métricas do programa, pois número de caças, relatórios produzidos e IOC disseminados só podem ser gerenciados quando existe um dono para cada tipo de entrega.

3. Papéis Típicos do Programa de CTI e Threat Hunting

A tabela a seguir consolida os papéis típicos, incluindo os descritos no Framework CTH e variações comuns de mercado. Os papéis de produtor e de consumidor de inteligência também fazem parte do sistema: o programa falha quando trata consumidores, como IR e diretoria, como público passivo em vez de parte do ciclo.

Duas observações ajudam a aplicar a tabela na prática. Primeiro, os papéis de analista júnior, pleno e sênior descrevem estágios de maturidade profissional dentro da mesma trilha, e não cargos diferentes; a matriz de competências do controle CTI.4 é o instrumento que mede a progressão. Segundo, o papel de consumidor precisa de gestão ativa: designar consumidores oficiais para cada tipo de produto, com compromisso de retroalimentação, é o que evita a produção de relatórios que ninguém lê.

4. Responsabilidades Essenciais por Papel

Além das responsabilidades gerais, cada papel carrega obrigações que, se não forem atribuídas explicitamente, viram lacunas operacionais. As listas a seguir destacam as responsabilidades que mais geram disputa ou esquecimento em programas reais.

• Gestor de CTI e TH: garantir que cada PIR tenha dono e prazo, arbitrar conflitos de prioridade com SOC e IR, defender orçamento junto ao patrocinador, aprovar a qualidade dos produtos antes da disseminação e manter o programa alinhado à estratégia do controle CTI.5.
• Analista de CTI Pleno e Sênior: manter os perfis de atores atualizados, validar IOC antes da disseminação, documentar a cadeia analítica que sustenta cada conclusão e responder a solicitações de análise do IR dentro do prazo acordado.
• Threat Hunter: documentar hipótese, escopo e resultado de toda caça, converter achados em propostas de detecção para a engenharia, reportar lacunas de telemetria encontradas durante as caças e retroalimentar a CTI com TTPs observados.
• Analista SOC: aplicar o contexto de inteligência recebido durante a triagem, escalar com informação suficiente para análise e reportar falsos positivos dos IOC para que a lista de indicadores seja refinada.
• Engenheiro de Detecção: implementar as detecções propostas dentro do ciclo acordado, reportar cobertura alcançada e sinalizar técnicas para as quais a telemetria disponível é insuficiente.
• Responsável por automação: manter os pipelines de coleta e enriquecimento operando, garantir rastreabilidade das fontes e automatizar a disseminação de IOC para os controles, reduzindo o esforço manual dos analistas.

5. Produtos e Entregas por Papel

Responsabilidade sem entrega nomeada é inatingível, e por isso cada papel precisa estar amarrado a produtos verificáveis. A tabela a seguir lista as entregas típicas que servem de base para metas, métricas do grupo MET e avaliação de desempenho. Em equipes pequenas, as entregas permanecem as mesmas, e o que muda é a pessoa que as executa.

O registro dessas entregas em sistema rastreável, mesmo que uma simples planilha compartilhada ou o sistema de tickets, é o que permite calcular a maior parte das métricas do programa. Onde não há registro de entrega, não há métrica, e onde não há métrica o programa não consegue demonstrar valor nem evoluir de maturidade.

6. Matriz RACI para Atividades-Chave

A matriz RACI define, para cada atividade, quem é Responsável pela execução (R), quem tem Autoridade sobre o resultado e aprova (A), quem é Consultado (C) e quem é Informado (I). O exemplo a seguir cobre quatro atividades-chave citadas pelo controle e três complementares de alto impacto em programas reais.

Três regras de uso da matriz evitam que ela vire documento decorativo. Primeiro, cada linha deve ter exatamente um A, pois atividades com dois donos não têm dono nenhum; a resposta a incidente é a exceção aparente que se resolve atribuindo R e A ao IR, com a CTI em papel de suporte consultado. Segundo, revise a matriz sempre que uma atividade gerar atrito recorrente entre equipes, pois o atrito quase sempre revela indefinição. Terceiro, publique a matriz onde as equipes operam, por exemplo no wiki do SOC, e não apenas no documento de governança que ninguém abre.

7. Sobreposição com Detecção e Resposta: Como Evitar Duplicidade

A zona de fronteira entre CTI, Threat Hunting, engenharia de detecção e resposta a incidentes é onde mais se perde energia em programas jovens. A duplicidade típica ocorre quando o SOC cria detecções ad hoc a partir de feeds, a engenharia de detecção cria as mesmas detecções a partir de relatórios e o hunter investiga o mesmo comportamento em uma caça, sem que ninguém saiba das outras duas frentes. O antídoto não é criar regras rígidas de exclusividade, e sim definir dono por tipo de atividade e um ponto de coordenação único.

As distinções funcionais a seguir resolvem as sobreposições mais comuns.

• IOC versus detecção: o analista de CTI valida e dissemina o indicador, mas quem cria e mantém a regra no SIEM é a engenharia de detecção; nunca deve existir caminho paralelo de inserção de IOC direto na detecção sem passagem pelo processo acordado.
• Hunt versus resposta: o hunter investiga hipóteses sem alvo específico e sem poder de contenção; quando a caça encontra evidência de comprometimento real, o caso transita para o IR, que assume a condução conforme a matriz RACI.
• Análise de malware no SOC versus na CTI: o SOC realiza desmontagem inicial e triagem para responder ao alerta; a CTI realiza análise aprofundada para extrair TTPs, infraestrutura e atribuição quando o caso tem relevância para os PIRs.
• Ameaça versus vulnerabilidade: a gestão de vulnerabilidades lista e corrige exposições; a CTI define quais delas estão sendo exploradas ativamente e, portanto, qual fila ganha prioridade.
• Relatório de alerta versus relatório de inteligência: o SOC documenta eventos; a CTI produz conclusões com juízo analítico sobre quem, como e por quê, com nível de confiança declarado.

Um mecanismo simples de coordenação fecha o sistema: uma reunião curta e semanal entre CTI, engenharia de detecção e representante do IR, com pauta de detecções em andamento, caças planejadas e solicitações pendentes. Essa cadência elimina a maior parte da duplicidade antes que ela aconteça, e cria o hábito de trânsito de trabalhos entre as funções.

8. Evolução dos Papéis conforme a Maturidade

O desenho de papéis não é estático, porque as demandas mudam conforme o programa avança nos níveis do Modelo de Maturidade CTH. No nível Inicial, o papel dominante é o generalista que consome feeds e responde demandas; no nível Definido, surgem as especializações tática e de hunting; no nível Gerenciado, a medição e a automação passam a exigir perfis dedicados. Planejar essa evolução evita que a equipe fique travada no perfil do começo, incapaz de sustentar o próximo nível.

9. Perfis Mínimos e Papéis Duplos em Equipes Pequenas

Organizações com duas ou três pessoas na segurança não podem imitar a estrutura de um centro de operações grande, e tentar fazê-lo produz cargos fictícios e frustração. A abordagem correta é mapear quais atividades são insubstituíveis e atribuí-las a papéis duplos com clareza documentada. A tabela a seguir sugere configurações mínimas viáveis.

Duas regras tornam os papéis duplos sustentáveis. Primeiro, o papel duplo precisa constar na descrição de função e na matriz RACI, porque acumulação verbal não sobrevive à pressão operacional. Segundo, as atividades proativas, como caças e relatórios estratégicos, devem ter tempo protegido no calendário, tipicamente um dia fixo por semana, senão o papel reativo do dia a dia consome todo o espaço disponível.

Toda descrição de papel, simples ou dupla, deve caber em uma página e responder às mesmas perguntas. O modelo a seguir padroniza essas descrições e facilita a comparação entre papéis e a evolução para trilhas de carreira.

Descricao de papel (modelo de 1 pagina)
  Papel: analista de CTI tatico
  Missao do papel: converter ameacas relevantes em contexto
    acionavel para deteccao, hunt e resposta
  Entregas: relatorio tatico mensal, perfis de ator atualizados,
    resposta a solicitacoes de analise em ate 3 dias uteis
  Atividades da RACI: producao de IOC e relatorio tatico (R),
    execucao de hunt (C), resposta a incidente (C)
  Competencias exigidas: ver matriz de competencias, nivel
    Intermediario em ATT&CK, malware e analise de logs
  A quem reporta: gestor de CTI e TH
  Metricas do papel: prazo de resposta a solicitacoes, taxa de
    IOC validados sem falso positivo, atualizacao de perfis

10. Erros Comuns e Pontos de Atenção

• Criar papéis sem associar entregas: um papel que não tem produto mensurável vira espaço invisível na equipe, e seu trabalho desaparece no primeiro corte de prioridades.
• Copiar organogramas de grandes fornecedores de serviço: descrições de cargo importadas de mercados com equipes de 50 pessoas não se aplicam a equipes de 5, e criam expectativa de especialização que ninguém consegue cumprir.
• Tratar hunter como analista de CTI com outro nome: as competências se sobrepõem, mas o fluxo de trabalho é distinto, e forçar a mesma pessoa a fazer os dois no mesmo dia degrada a qualidade das caças.
• Deixar a matriz RACI em formato de imagem: documento não pesquisável não é consultado no momento da dúvida; mantenha a matriz em texto e no local onde as equipes trabalham.
• Atribuir a responsabilidade de automação ao analista mais disponível: automação exige competência de engenharia de dados, e improvisar gera pipelines frágeis que quebram na primeira mudança de API.
• Esquecer os consumidores no RACI: sem coluna de consumidores consultados, os PIRs são escritos sem demanda real, e os produtos nascem desconectados do uso previsto.

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

Os papéis definidos em CTI.3 são o suporte humano para todos os grupos técnicos do framework: o grupo COL depende dos analistas que alimentam fontes, o grupo ANA dos que produzem análise, o grupo HNT dos hunters, o grupo DET da engenharia de detecção e o grupo AUT do responsável por automação. O controle CTI.4 complementa este controle ao medir se as pessoas alocadas nos papéis têm as competências que eles exigem, e a nota de Matriz de Competências fornece o instrumento de avaliação.

No plano de governança, a matriz RACI deste controle é a base sobre a qual CTI.5 atribui donos às iniciativas do roadmap estratégico, e o resultado da autoavaliação do Modelo de Maturidade CTH deve citar explicitamente os papéis presentes e ausentes. Em auditorias alinhadas ao NIST CSF 2.0, a definição formal de papéis e responsabilidades atende diretamente à categoria GV.RR da função Govern, o que faz deste controle um item recorrente de evidência documental.