05 - Maturidade em CTI (Modelos e Níveis)

1. Contexto e Posicionamento na Biblioteca

Todo programa de CTI tem um nível de maturidade real, mesmo quando ninguém o declarou. A equipe pode operar em modo ad hoc, com alguém coletando IOCs nas horas vagas, ou em modo institucionalizado, com requisitos priorizados, produção por cadência e métricas de uso, e a diferença entre esses estados determina quanto valor o programa entrega e quanto patrocínio ele sobrevive a conseguir. Modelos de maturidade existem para transformar essa diferença implícita em diagnóstico explícito, comparável entre áreas e ao longo do tempo.

Esta nota cobre três questões práticas: quais modelos usar como referência, como ler os níveis de 0 a 5 sem cair em rótulos vãos, e como converter a avaliação em plano de evolução priorizado por dimensão. O capítulo 15 fornece o complemento operacional: o modelo de maturidade do Framework CTH, no grupo GOV, define cinco níveis com salvaguardas associadas, e o grupo MET conecta maturidade a métricas auditáveis. A nota 11 deste capítulo cuida da parte que costuma faltar nos modelos, que é medir se a inteligência produzida é realmente útil.

2. Por Que Medir Maturidade

Medir maturidade serve a três públicos com necessidades distintas. Para o patrocinador executivo, o modelo traduz investimento em trajetória: mostra onde estamos, onde precisamos chegar e o que falta para lá, em linguagem de planejamento que sobrevive à troca de gestores. Para a própria equipe, a avaliação expõe gargalos escondidos, como coleta madura com análise imatura, e evita que a expectativa do negócio avance mais rápido que a capacidade instalada. Para auditoria e compliance, o modelo oferece evidência de melhoria contínua exigida por frameworks como NIST CSF 2.0 e ISO 27001.

O ganho menos óbvio é o efeito da medição sobre as conversas de priorização. Quando o diagnóstico mostra que o gargalo está na análise e não na ferramenta, o orçamento deixa de ser gasto em licenças e passa a ser investido em capacitação e processo. Avaliações anuais repetidas criam ainda um histórico valioso, porque progresso declarado em pitch e progresso demonstrado em evidência têm pesos completamente diferentes na confiança que o patrocinador deposita no programa.

3. Modelos de Referência

Não existe um único modelo obrigatório, e a boa prática é usar um modelo como esqueleto e adaptar a taxonomia à realidade da organização. As referências mais úteis para CTI são:

• Modelo de maturidade do Framework CTH, no grupo GOV do capítulo 15, com cinco níveis e salvaguardas por controle, desenhado para este ecossistema de estudo.
• CTI-CMM, o Cyber Threat Intelligence Capability Maturity Model, modelo comunitário e vendor-neutral que avalia a capacidade de CTI em dimensões como direção, pessoas, processo, tecnologia e serviços.
• Modelo genérico de cinco níveis herdado de CMM, com a escala inicial, repetível, definido, gerenciado e otimizado, útil como vocabulário padrão que qualquer auditor entende.
• Funções Govern, Identify e Detect do NIST CSF 2.0, que fornecem o contexto de governança e risco no qual a maturidade de CTI se insere.

Os modelos divergem em detalhe, mas convergem na espinha dorsal: capacidade crescente, de reativa e informal a preditiva e institucionalizada, avaliada em múltiplas dimensões e sustentada por evidência. A recomendação prática é escolher o modelo do Framework CTH quando o objetivo é evoluir junto com esta biblioteca, citando o CTI-CMM como referência de profundidade, e manter a escala numérica de 0 a 5 como linguagem comum para relatórios executivos.

4. Níveis Típicos de 0 a 5

A escala abaixo consolida as práticas típicas de cada nível. Ela descreve padrões de mercado, e não uma norma rígida, e o nível declarado deve sempre vir com evidência por dimensão, porque programas reais raramente são uniformes em todas as frentes.

Dois cuidados evitam os usos errados da escala. O primeiro é o salto declaratório: organizações se autodeclaram nível 3 ou 4 com base em ferramentas implantadas, e a evidência por dimensão corrige isso, porque ferramenta boa em processo imaturo ainda é nível 1 ou 2. O segundo é a leitura de superioridade: níveis altos não são obrigatórios para todos, e uma organização de médio porte pode operar com excelência no nível 3 e extrair todo o valor de que precisa, sem justificar o custo do nível 5.

Vale ainda registrar que a escala mede capacidade de produzir e consumir inteligência, e não qualidade individual de qualquer produto isolado. Um programa de nível 2 pode produzir um alerta excelente por sorte, e um programa de nível 4 pode publicar um produto medíocre em um trimestre ruim, e nenhum dos dois fatos muda o nível. O que muda é a probabilidade de repetição do desempenho, que é exatamente o que maturidade promete medir.

5. Sinais de Maturidade por Dimensão

Avaliar por dimensão evita as médias enganosas e mostra exatamente onde investir. As quatro dimensões abaixo cobrem o essencial, e cada uma tem sinais observáveis por faixa de maturidade:

5.1 Pessoas

• Nível 1 a 2: um entusiasta acumula CTI sem tempo alocado; competência depende de indivíduo, não da equipe.
• Nível 3: tempo alocado formalmente, competências mapeadas em matriz, treinamento mínimo anual por papel.
• Nível 4 a 5: papéis especializados por nível de inteligência, revisão por pares, plano de sucessão e comunidade de prática interna.

5.2 Processo

• Nível 1 a 2: trabalho por demanda e por manchete, sem cadência nem critérios de saída por fase.
• Nível 3: ciclo de inteligência operando com requisitos priorizados, calendário editorial e playbooks por produto.
• Nível 4 a 5: processos auditáveis, modo de incidente definido, melhoria de processo guiada por métricas de uso.

5.3 Tecnologia

• Nível 1 a 2: ferramentas usadas de forma isolada, planilhas de IOC, sem TIP nem automação de enriquecimento.
• Nível 3: TIP em operação, integração com SIEM e EDR, normalização mínima para STIX 2.1, expiração de indicadores.
• Nível 4 a 5: automação ponta a ponta de coleta a detecção, enriquecimento automático em triagem e orquestração com SOAR.

5.4 Dados

• Nível 1 a 2: fontes não catalogadas, sem avaliação de confiabilidade nem política de qualidade.
• Nível 3: catálogo de fontes com dono, confiabilidade avaliada e cobertura mapeada contra os EEIs dos requisitos.
• Nível 4 a 5: qualidade medida por taxa de falso positivo e acionamento, fontes descontinuadas por evidência e contribuição recíproca em comunidades de compartilhamento.

5.5 Cliente e relacionamento

• Nível 1 a 2: produtos enviados para listas de e-mail genéricas, sem dono de consumo nem conversa regular de feedback.
• Nível 3: matriz de públicos com cadência e canal definidos, com revisão de requisitos a cada trimestre.
• Nível 4 a 5: feedback estruturado por produto, clientes participam da priorização e a produção é ajustada com evidência de uso.

A leitura por dimensão costuma revelar o padrão mais comum em programas reais: tecnologia à frente do processo, e processo à frente das pessoas. Esse desalinhamento explica por que implantações de plataforma caras frequentemente não mudam o resultado, e é a razão pela qual o plano de evolução da seção 7 prioriza processo e pessoas antes de mais tecnologia.

6. Como Avaliar: Método e Checklist

A avaliação séria combina três evidências: artefatos observados, entrevistas curtas com consumidores e métricas existentes. O método recomendado leva um dia de trabalho para uma equipe pequena e segue o checklist abaixo, em YAML, que a equipe pode preencher e arquivar como registro anual do programa:

avaliacao_maturidade:
  data: 2025-06-10
  avaliador: lider-cti com revisao do CISO
  pessoas:
    tempo_alocado_formal: [1-5, "nao", "CTI acumulada com SOC"]
    matriz_competencias: [1-5, "parcial", "planilha sem revisao anual"]
    treinamento_ultimos_12m: [1-5, "sim", "2 cursos por analista"]
  processo:
    pirs_formalizados: [1-5, "sim", "4 PIRs priorizados e revisados"]
    cadencia_producao: [1-5, "parcial", "boletim mensal sem calendário editorial"]
    criterios_de_saida_por_fase: [1-5, "nao", "nao documentados"]
  tecnologia:
    tip_em_operacao: [1-5, "sim", "MISP com 2 feeds e expiração ativa"]
    integracao_siem_edr: [1-5, "sim", "ingestão automática de IOCs no SIEM"]
    automacao_enriquecimento: [1-5, "nao", "triagem manual de enriquecimento"]
  dados:
    catalogo_de_fontes_com_dono: [1-5, "sim", "12 fontes catalogadas"]
    confiabilidade_avaliada: [1-5, "parcial", "aplicada em 6 de 12 fontes"]
    cobertura_de_eeis_mapeada: [1-5, "nao", "mapeamento incompleto"]
  resultado:
    nivel_conservador: 2
    justificativa: processo presente mas instavel; dados e automacao parciais
    gargalos: [criterios_de_saida, cobertura_de_eeis, automacao_de_enriquecimento]

Três regras de honestidade protegem a avaliação de viés. Primeiro, pior caso por dimensão: quando a evidência for mista, o nível declarado é o menor compatível, e não a média das esperanças. Segundo, entrevistar consumidores, porque a percepção de quem recebe os produtos corrige a visão de quem os produz. Terceiro, arquivar a avaliação com data e avaliador, porque comparação anual exige registros comparáveis, e memória institucional não é evidência.

7. Plano de Evolução

O plano de evolução converte gargalos em passos sequenciais, com regra de ouro clara: processo antes de tecnologia, e tecnologia antes de sofisticação. O passo típico do nível 2 para o 3 não é comprar plataforma, e sim estabilizar requisitos, cadência e critérios de saída; o passo do 3 para o 4 é instrumentar métricas de uso e ajustar a produção com elas; o passo do 4 para o 5 é automatizar o ciclo com as garantias que as métricas permitem auditar. Cada passo deve ter evidência de conclusão verificável, no mesmo padrão das salvaguardas do capítulo 15.

A sequência de execução recomendada, ajustável ao diagnóstico, é a seguinte:

• Formalizar três a cinco PIRs com dono de decisão, usando as notas 07 e 08 deste capítulo.
• Definir o calendário editorial por nível de inteligência e os critérios de saída por fase do ciclo.
• Catalogar fontes e mapear cobertura contra os EEIs, descontinuando fontes sem dono nem uso.
• Automatizar enriquecimento e expiração de indicadores, com taxa de falso positivo monitorada.
• Instrumentar métricas de utilidade da nota 11 e instalar a revisão mensal de ajuste da produção.
• Somente então avaliar plataformas e automação de maior custo, que passam a ter requisitos estáveis para atender.

O plano também deve declarar explicitamente o que o programa NÃO fará no ciclo, porque capacidade finita é a regra. Uma equipe de dois analistas que resolve estabilizar requisitos e cadência deve registrar formalmente que monitoramento de fóruns profundos e contribuição em ISAC ficam para o ciclo seguinte, e comunicar essa fronteira ao patrocinador. Planos sem renúncia declarada viram listas de desejo, e listas de desejo não sobrevivem ao primeiro trimestre de operação cheia.

8. Erros Comuns e Pontos de Atenção

Os erros abaixo distorcem avaliações e planos de maturidade em programas reais:

• Autoavaliação inflada: declarar nível com base em ferramenta e não em prática; correção: evidência por dimensão e regra do pior caso.
• Plano de compra disfarçado de plano de maturidade: todo passo termina em licença; correção: exigir pelo menos um passo de processo e um de competência antes de qualquer aquisição.
• Copiar metas de nível de outra organização: porte, setor e apetite de risco definem o nível alvo, e não o medidor do concorrente.
• Avaliação anual sem plano: diagnóstico que não vira portfólio com donos e prazos; correção: cada gargalo avaliado vira item com responsável e evidência de conclusão.
• Medir maturidade de CTI isolada do resto da operação: sem detecção e resposta maduras a jusante, inteligência boa envelhece sem uso; correção: avaliar a esteira completa com o capítulo 15.
• Trocar de modelo a cada ciclo: mudar de taxonomia anualmente destrói a comparabilidade; correção: fixar o modelo por pelo menos três ciclos.
• Avaliar somente a equipe de CTI e esquecer os consumidores: maturidade é binômio de produção e consumo; correção: incluir SOC, detecção e risco na entrevista da avaliação.

Um ponto final de atenção é a relação entre maturidade declarada e dwell time, o indicador de resultado que a biblioteca segue no capítulo 15. Maturidade é medida de capacidade, e não de resultado, e programas maduros podem conviver com dwell time ruim se a telemetria for cega, exatamente como programas imaturos podem ter sorte com um adversário barulhento. Por isso o relatório executivo anual deve apresentar maturidade e resultado lado a lado, com a evolução do dwell time como prova final de que a capacidade construída está entregando efeito no ambiente.

9. Integração com o Restante da Biblioteca

Esta nota fecha a parte conceitual do capítulo 01 e prepara a parte de requisitos, das notas 07 a 10, e a parte de avaliação, na nota 11. No capítulo 15, o grupo GOV trata o modelo de maturidade como salvaguarda formal, com avaliação inicial, plano progressivo e evidência por nível, e o grupo MET cobre as métricas que sustentam os níveis 4 e 5. A nota 11 deste capítulo é o complemento obrigatório, porque mede utilidade da produção, enquanto maturidade mede capacidade de produzir.

Para o estudante, o exercício recomendado é aplicar o checklist da seção 6 à própria organização, real ou de estudo, e escrever o plano de evolução de três passos com evidências de conclusão. Esse artefato, de meia página, é o tipo de entrega que um CISO aprova em reunião única, e serve de exercício capstone para o capítulo inteiro, amarrando definição, níveis, ciclo, perfis e requisitos em um plano verificável.