Necessidades do Cliente e Decisões a Apoiar

Nota 08 do capítulo 01 - Fundamentos de Cyber Threat Intelligence (CTI). Mapeia os clientes internos da inteligência, suas decisões e as técnicas para elicitar necessidades reais.
É a nota que coloca o consumidor no centro do ciclo, transformando a direção da nota 07 em um processo de escuta estruturada.
Dialoga com a nota 02 (níveis e públicos), com a nota 09 (EEIs derivados das necessidades) e com o controle CTI.8 do capítulo 15, disseminação segmentada.

1. Contexto e Posicionamento na Biblioteca

Inteligência não tem valor intrínseco: seu valor é o da decisão que ela melhora. Por isso, a pergunta mais importante do programa não é sobre ferramenta, feed ou técnica analítica, e sim sobre quem decide o quê com o material que a equipe pode produzir. O mapeamento de clientes internos e de suas decisões é a metade da demanda do ciclo de inteligência, e sem ele a direção da nota 07 formula PIRs no vazio, com donos presumidos e decisões inventadas.

Esta nota organiza o trabalho de demanda em três passos: mapear os stakeholders que consomem inteligência, elicitar suas necessidades com técnicas estruturadas e consolidar tudo em uma matriz decisão x inteligência que governa a produção. A nota também cataloga os erros de comunicação mais comuns por público, porque necessidade mal entendida vira produto errado mesmo quando a análise é excelente. No capítulo 15, o CTI.8 exige disseminação segmentada, e essa segmentação só existe sobre a matriz construída aqui.

2. Quem É o Cliente da CTI

O cliente da CTI é qualquer pessoa ou sistema que toma uma decisão melhor porque recebeu o produto certo. A tabela abaixo mapeia os stakeholders típicos de uma organização de médio porte, com as decisões que cada um precisa apoiar e o produto de inteligência correspondente:

Fora dessa lista habitual, quatro clientes menos óbvios merecem atenção deliberada, porque costumam aparecer apenas depois de um incidente:

• Jurídico e privacidade, que decide notificação e comunicação a partir do contexto de ameaça e do que foi acessado.
• Comunicação institucional, que precisa de linguagem correta sobre incidentes sem confirmar detalhes indevidos.
• Áreas de negócio, como fraudes em bancos ou segurança patrimonial em indústria, que compartilham adversários com a CTI.
• Sistemas automatizados, os clientes silenciosos que consomem feeds técnicos e cuja "decisão" é bloquear ou alertar sem humano.

Duas disciplinas de mapeamento evitam distorções comuns desde a origem. A primeira é não confundir cliente com canal: a lista de distribuição de e-mail não é stakeholder, e o dono da decisão precisa ser nomeado, porque canal não defende requisito nem dá feedback. A segunda é incluir os fornecedores e terceiros críticos quando a organização tem responsabilidade sobre a cadeia, porque decisões de gerenciamento de fornecedor também consomem inteligência, ainda que a produção seja compartilhada com o parceiro.

3. Técnicas de Elicitação de Necessidades

Necessidade declarada é raramente necessidade real, porque consumidores descrevem soluções desejadas, e não decisões a apoiar. "Quero feeds de dark web" quase sempre significa alguma decisão latente sobre credenciais vazadas ou marca monitorada, e cabe ao analista traduzir. As técnicas abaixo cobrem o repertório essencial de elicitação, e a tabela a seguir indica quando usar cada uma:

A entrevista estruturada merece detalhe, porque é a técnica de maior rendimento. O roteiro abaixo, no formato de referência usado pela equipe, guia a sessão e garante que o registro saia pronto para o formato de PIR da nota 07:

roteiro_elicitacao:
  stakeholder: <nome e papel>
  data: <data da sessão>
  perguntas:
    - Quais decisões que envolveram ameaças este papel tomou nos ultimos 6 meses?
    - O que teria feito cada decisão sair diferente, com informação melhor?
    - Que informação faltou exatamente no momento da decisão?
    - Com que antecedência essa informação teria precisado chegar?
    - Como prefere receber: formato, canal e frequência?
  armadilha_a_evitar: registrar a solução pedida em vez da decisão a apoiar
  saida: minuta de linha da matriz e rascunho de PIR, validada na sessão

A disciplina central da entrevista é sempre trazer a conversa de volta da solução para a decisão, registrando no formato do PIR da nota 07 enquanto a conversa acontece, e não depois.

4. A Matriz Decisão x Inteligência

A matriz decisão x inteligência é o artefato que consolida o mapeamento: cada linha é uma decisão real, com o stakeholder que decide, o produto que apoia a decisão, o nível de inteligência, a cadência e o canal. Ela vira contrato de nível de serviço interno do programa, e o esqueleto abaixo, em YAML, é o formato de referência das notas 09 e 10:

matriz_decisao_inteligencia:
  - id: DEC-001
    decisao: aprovar hardening emergencial de VPN e MFA geral
    stakeholder: CISO
    nivel: estrategico
    produto: avaliação trimestral com cenário de risco de acesso inicial
    cadencia: trimestral
    canal: reunião executiva e documento de uma página
    pirs: [PIR-2025-003]
  - id: DEC-002
    decisao: priorizar regras de detecção do próximo sprint
    stakeholder: engenharia de detecção
    nivel: tatico
    produto: TTPs de atores prioritários com regras candidatas Sigma
    cadencia: mensal
    canal: TIP e reunião de detecção
    pirs: [PIR-2025-007, PIR-2025-011]
  - id: DEC-003
    decisao: acionar remoção de domínios de phishing da marca
    stakeholder: resposta a incidentes
    nivel: operacional
    produto: alerta de campanha com evidência e takedown recomendado
    cadencia: por evento, dentro de 24h do gatilho
    canal: canal de alerta com confirmação de leitura
    pirs: [PIR-2025-014]

Três regras mantêm a matriz viva. Primeiro, nenhuma linha sem decisão real: se não existe decisão, não existe linha, e o pedido volta para elicitação. Segundo, todo PIR aponta para ao menos uma linha, e toda linha aponta para pelo menos um PIR, e a checagem de bidirecionalidade é rápida e revela órfãos de ambos os lados. Terceiro, a matriz é revisada no mesmo ritmo do portfólio de PIRs, na cadência trimestral da nota 07, porque decisões mudam quando a organização muda.

A matriz também resolve disputas de prioridade com argumento, e não com volume de voz: quando dois consumidores brigam por capacidade, a conversa compara decisões, não pessoas. Qual decisão tem maior impacto financeiro ou operacional, qual tem janela mais curta e qual risco corre o negócio se a resposta atrasar. A nota 10 formaliza esses critérios na matriz de priorização, e a matriz de decisão é justamente a matéria-prima desse exercício.

5. Erros de Comunicação por Público

Comunicar inteligência com o mesmo formato para todos os públicos é o erro mais dispendioso do programa, porque destrói o consumo de produtos bons. Os padrões de erro mais frequentes, por público, são:

• Para o conselho: jargão técnico, como códigos ATT&CK e nomes de malware, onde deveria haver risco e impacto em linguagem de negócio; e ausência de recomendação decisional, deixando o relatório sem chamada à ação.
• Para o CISO: relatórios só de técnica, sem cenário de probabilidade nem custo de mitigação, impedindo a decisão de investimento que ele precisa tomar.
• Para o SOC: boletins narrativos longos, sem consulta pronta nem critério de confiança, obrigando o analista a converter texto em busca sob pressão.
• Para resposta a incidentes: atribuição especulativa apresentada como fato, distorcendo decisões de contenção e comunicação.
• Para engenharia: TTPs sem detalhe de evidência suficiente para construir regra, produzindo falsa sensação de cobertura.
• Para gestão de risco: avaliações sem grau de confiança declarado, impossibilitando o registro honesto do risco.

O antídoto comum a todos os públicos é o mesmo princípio de redação: abrir com a recomendação, sustentar com evidência e guardar o detalhe técnico em anexo. Cada público lê a primeira página, e só o que precisa desce ao anexo; quando a primeira página é jargão, a leitura para ali. A nota 02 define os formatos por nível, e o CTI.8 do capítulo 15 cobra essa segmentação como salvaguarda, com TLP adequado a cada canal.

6. Erros Comuns e Pontos de Atenção

Os erros abaixo aparecem em programas de todos os tamanhos e têm correção direta:

• Elicitar uma vez e nunca mais: necessidades colhidas no primeiro ano de programa servem ao primeiro ano, e não ao terceiro; correção: revisão trimestral da matriz junto com o portfólio de PIRs.
• Aceitar soluções como requisitos: "quero intel de dark web" registrado como PIR produz compra sem decisão; correção: perguntar sempre qual decisão a informação apoiaria.
• Stakeholder fantasma: lista de públicos sem conversa real com nenhum deles; correção: entrevistas efetivas com os decisores das linhas da matriz.
• Cliente silencioso esquecido: sistemas que consomem feeds sem dono de qualidade; correção: atribuir responsabilidade pelas métricas de acionamento técnico à engenharia.
• Prometer o que não se pode entregar: aceitar cadência diária de análise profunda com equipe de dois; correção: negociar formato e cadência compatíveis com capacidade real.
• Confundir hierarquia com relevância: atender só o topo e ignorar quem usa o produto todos os dias; correção: medir utilidade por produto, como na nota 11, e não por cargo do solicitante.
• Comunicação unidirecional: relatórios enviados sem canal de resposta; correção: canal de feedback com dono, alimentando o ciclo da nota 03.
• Mapear só o presente: necessidades colhidas apenas com quem hoje consome; correção: incluir stakeholders que deveriam consumir e não consomem, que são os ganhos mais rápidos de valor.
• Documento de necessidades sem revisão: o mapa envelhece e vira peça de arquivo; correção: mesma cadência do portfólio de PIRs, com dono nominal pela atualização.

Um ponto final de atenção é o momento certo de elicitar necessidades novas. Conversas de elicitação rendem muito mais imediatamente após um incidente relevante, uma auditoria ou uma decisão orçamentária, quando as lacunas de informação estão frescas na memória do decisor, e rendem muito menos em agendas administrativas sem contexto. Programas maduros agendam a revisão da matriz de propósito para esses momentos, capturando a necessidade enquanto ela é sentida, e não meses depois, quando o decisor já comprou a própria solução sem passar pelo programa.

7. Integração com o Restante da Biblioteca

A matriz decisão x inteligência é o contracheque da demanda de todo o capítulo: a nota 07 converte cada linha em PIR, a nota 09 decompõe cada PIR em EEIs coletáveis, a nota 10 prioriza linhas quando a capacidade não basta e a nota 11 cobra de cada linha o uso registrado. Nos capítulos seguintes, os formatos de produto por público reaparecem na produção do capítulo 05, na disseminação tática e no pacote de hunting dos capítulos 06 e 07, e no reporte executivo do capítulo 11.

No capítulo 15, o CTI.8 institui a disseminação segmentada como salvaguarda, e o grupo GOV trata o posicionamento organizacional que facilita o acesso da CTI aos decisores. Para aplicar esta nota, comece pelas duas linhas de matriz mais importantes que a organização tem hoje, entreviste os dois decisores com o roteiro da seção 3, registre as decisões no formato YAML da seção 4 e transforme cada linha em um PIR da nota 07. Duas linhas bem feitas em uma semana valem mais do que um mapeamento completo imaginado sem escuta, e o portfólio cresce a partir daí com clientes reais anexados a cada requisito.