OTHF (Outsourced Threat Hunting Framework)

Nota do Capítulo 23, Frameworks e Metodologias Emergentes.
Apresenta o OTHF, framework para threat hunting executado por MSSP, com as fases contracts, data, hypotheses, execution e feedback, os desafios de acesso a dados, contexto de negócio e transferência de conhecimento, modelo de contrato e SLA e ciclo exemplar.
Dialoga com a TaHiTI e o PEAK desta pasta, com os controles HNT do capítulo 15 e com as métricas de hunting do capítulo 11.

1. Contexto e Posicionamento na Biblioteca

A maior parte das organizações não tem time de hunting interno, e a resposta do mercado é o hunting como serviço oferecido por MSSPs e provedores de MDR. O problema é que hunting terceirizado não é hunting interno com outra marca: o provedor chega sem contexto de negócio, com acesso parcial aos dados, sob contrato que definiu mal o que é um achado, e a prática comum de definir hunting como mais uma linha de vigilância destrói o valor da atividade. O OTHF é a resposta estruturada a esse problema, um framework específico para conduzir hunting em modelo terceirizado, com cinco fases que vão do contrato à realimentação, e é o único da biblioteca desenhado para uma relação contratual entre organizações distintas.

O posicionamento na biblioteca é o de ponte entre o programa de hunting dos capítulos 6 e 7 e a realidade de compra de serviço. As notas anteriores desta pasta assumem execução interna; o OTHF assume que o conhecimento do ambiente vive no cliente e a habilidade de caça vive no provedor, e trata a conexão desses dois mundos como o problema central a resolver. A leitura junto com o capítulo 12, de desafios e boas práticas, mostra os mesmos riscos vistos da perspectiva contratual.

2. Por que Hunting Terceirizado é um Problema Diferente

Hunting interno caça no próprio ambiente com contexto acumulado: o hunter sabe quais servidores importam, quais ferramentas são legítimas e qual telemetria existe, e essa inteligência tácita é metade da eficácia de qualquer caça. Quando a caça migra para um provedor, esse contexto desaparece e precisa ser transferido de forma explícita, porque nenhum contrato cria compreensão de ambiente. Ao mesmo tempo, o provedor traz o que o cliente não tem, técnicas de caça acumuladas em dezenas de ambientes, inteligência de ameaça ampla e maturidade de processo, e o design do relacionamento precisa preservar os dois lados da troca.

A terceira diferença é estrutural: hunting é investigação iterativa e de propósito aberto, enquanto contratos de serviço são desenhados para entregas previsíveis. Sem desenho cuidadoso, a relação degrada para um dos dois defeitos clássicos, ou o contrato vira vigilância de alertas disfarçada, com o provedor executando regras e chamando de hunting, ou o escopo abre tanto que o cliente paga horas de consultoria sem produto definido. O OTHF existe para desenhar esse meio termo, com fases que transformam ambiguidade em responsabilidade explícita.

A tabela a seguir contrasta as duas modalidades nas dimensões que o contrato precisa considerar, e serve de base para a matriz de responsabilidade que a fase contracts produz.

A leitura da tabela mostra que a terceirização compra maturidade e amplitude de inteligência, pagando com restrição de acesso e risco de transferência fraca, e o desenho do OTHF maximiza a troca nas duas direções. Nenhuma modalidade é superior em absoluto, e a decisão é de portfólio: parte da caça interna com contexto denso, parte terceirizada com técnica madura, e a fronteira entre as partes é definida no contrato.

3. As Cinco Fases do OTHF

O framework organiza o ciclo de hunting terceirizado em cinco fases, e a força do modelo está na ordem: nada começa antes do contrato definir o que é sucesso, e nada termina sem o conhecimento voltar para o cliente. A tabela a seguir apresenta cada fase com seu propósito e seus produtos mínimos.

A fase de contracts merece o peso que o OTHF lhe dá, porque é onde o valor se perde ou se preserva. O contrato precisa distinguir hunting de vigilância, definir que o provedor terá tempo para investigação iterativa, estabelecer o que constitui achado reportável e como os achados são entregues, e cobrir o tratamento de dados com o mesmo rigor das políticas de compartilhamento do capítulo 22, já que o provedor passa a processar telemetria sensível. A fase de data reconhece a realidade de que o acesso nunca é total: a matriz de dados compartilháveis define o que sai do ambiente, o que é consultado in place e o que nunca é tocado, e essa matriz é insumo direto para o backlog de hipóteses, porque hipótese sem dado acessível é trabalho morto.

As fases também têm ritmo diferente entre si, e essa é uma das razões para tratá-las como ciclo e não como projeto único. Contracts e data mudam pouco entre ciclos e são revisadas a cada renovação; hypotheses e execution giram na cadência principal, mensal ou trimestral conforme o contrato; e feedback fecha cada giro alimentando o próximo. O erro de desenho comum é tratar as cinco fases como evento único de implantação, e a partir daí executar apenas execution, que é exatamente o modo como a relação degrada para vigilância rebrandeada.

4. Desafios Específicos: Acesso a Dados, Contexto e Conhecimento

Três desafios atravessam todas as fases e merecem tratamento separado, porque são os que mais matam programas de hunting terceirizado na prática. O primeiro é o acesso a dados, com soluções que vão de cópia para ambiente do provedor a consulta remota controlada, e a decisão depende de regulamentação, volume e sensibilidade; o erro comum é escolher por preço, e não por viabilidade de caça, porque acesso deficiente produz caças genéricas de valor duvidoso.

O segundo desafio é o contexto de negócio, e a solução do OTHF é transferi-lo de forma estruturada nas fases contracts e data: mapa de ativos críticos, lista de processos de negócio que sustentam a empresa, inventário de ferramentas administrativas legítimas e histórico de incidentes resumido. Sem esse material, o provedor pontua hipóteses por ameaça genérica do mercado, e não por risco real do cliente, reproduzindo na terceirização o vício que o THRIVE desta pasta elimina no interno. O terceiro desafio é a transferência de conhecimento, o risco conhecido de o provedor aprender o ambiente e o cliente não aprender nada, ficando cativo. A fase de feedback existe contra isso: cada ciclo exige sessões de transferência em que o provedor mostra hipóteses, consultas e raciocínio, o cliente documenta para o próprio time, e o contrato prevê a entrega de ativos, consultas, analytics e regras, em formato reutilizável, e não apenas relatórios.

A matriz de dados compartilháveis, que resolve o primeiro desafio, é um artefato com entradas nomeadas, e não uma cláusula genérica de sigilo. O formato mínimo que funciona na prática define para cada classe de dado o modo de acesso e a restrição, como exemplifica a lista a seguir:

• Logs de autenticação: cópia mensal para ambiente do provedor, com pseudonimização de usuários finais.
• Telemetria de EDR: consulta in place por túnel criptografado, sem cópia, com sessões registradas.
• Logs de proxy e de DNS: consulta in place, com exportação pontual autorizada caso a caso.
• Dados de negócio e de clientes: nunca acessíveis, e o contexto entra por descrição, e não por dado.
• Material de incidente em andamento: compartilhado conforme a política de TLP do capítulo 22, com rótulo obrigatório.

A matriz é revisada a cada ciclo de contrato, porque telemetria nova muda o que é possível caçar, e o provedor tem direito de abrir requisito de acesso com justificativa de hipótese, decisão que o cliente toma com jurídico quando o dado é sensível. Esse fluxo formal de negociação de acesso é o que impede que a restrição inicial vire limite permanente de inteligência.

5. Modelo de Contrato e SLA

O contrato de hunting difere do contrato de monitoramento nos pontos que a tabela seguinte organiza, e a ausência de qualquer linha é o indicador precoce de que o serviço comprado não é hunting.

O extrato de cláusulas abaixo exemplifica o nível de especificidade que a fase contracts deve alcançar, redigido no formato que o jurídico do cliente e o comercial do provedor conseguem negociar direto.

CLAUSULA 4. ESCOPO DE THREAT HUNTING
4.1 O Provedor dedicara no minimo 2 (dois) dias uteis por mes de
    investigacao dedicada (hunting) ao ambiente do Cliente, registrada
    em tickets com hipotese, dados utilizados e resultado.
4.2 O backlog de hipoteses sera mantido em ferramenta compartilhada,
    com pontuacao conjunta e aprovacao do Cliente a cada ciclo.
4.3 Achados indicativos de comprometimento em curso serao comunicados
    em ate 2 (duas) horas uteis pelo canal de resposta a incidentes,
    com evidencia e severidade justificada.
4.4 Consultas, analytics e regras derivados das cacas serao entregues
    ao Cliente em formato estruturado (Sigma, KQL, SPL), licenciados
    para uso interno perpetuo.
4.5 Serao realizadas sessoes bimestrais de transferencia de
    conhecimento, com participacao minima de 2 analistas do Cliente,
    registradas em ata com material anexo.

Cláusulas nesse nível de detalhe não eliminam a necessidade de gestão do contrato, e sim a tornam possível, porque cada item é verificável sem interpretação: contam-se tickets, mede-se o prazo de comunicação, conferem-se os formatos entregues. A revisão trimestral prevista na tabela usa exatamente esses registros, e a renovação sem evidência de caça executada é a ocasião em que o cliente renegocia escopo ou encerra a relação.

O SLA de escalonamento de achado é o ponto mais sensível, porque achado de caça é, na maioria das vezes, evidência de comprometimento em curso, e tratar esse achado como item de relatório mensal transforma hunting caro em resposta tardia. A prática recomendada é o mesmo canal e prazos do serviço de resposta a incidentes, com o protocolo de contenção pré-acordado entre as partes, conexão direta com o capítulo 13 da biblioteca.

6. Exemplo de Ciclo com MSSP

Considere uma indústria de médio porte sem time de hunting, contratando um MSSP para o ciclo trimestral. Na fase contracts, as partes definiram dois dias de investigação dedicada por mês, matriz de dados com logs de EDR e proxy consultados in place e logs de autenticação copiados, e cláusula de entrega de consultas em formato Sigma. Na fase data, o provedor recebeu o mapa de ativos críticos, descobriu que o NetFlow da planta industrial não está centralizado e registrou a lacuna como risco conhecido do ciclo. Na fase hypotheses, o backlog somou oito hipóteses, quatro do provedor por inteligência de setor, quatro do cliente por contexto de negócio, priorizadas em conjunto com pontuação inspirada no LLMR, e a hipótese de uso de ferramenta de acesso remoto legítima da TI para movimento lateral ficou no topo.

Na fase execution, a caça combinou telemetria do EDR com a lista de ferramentas administrativas do cliente, encontrou uma conta de serviço usando a ferramenta fora da janela de manutenção, e escalonou em duas horas pelo canal de incidentes, com a resposta confirmando uso indevido por funcionário desligado cuja conta não foi revogada. Na fase feedback, o provedor entregou a consulta Sigma do padrão abusado, conduziu sessão de transferência com o time interno de dois analistas, e a revisão trimestral registrou a lacuna de NetFlow como investimento aprovado para o próximo ciclo. O ciclo ilustra a mecânica completa: contexto do cliente transformou uma hipótese genérica de mercado no achado concreto que a vigilância do SOC não teria produzido, porque nenhum alerta existe para uso legítimo de ferramenta legítima em horário errado.

A linha do tempo abaixo resume o ciclo trimestral descrito, no formato que o dono interno da relação mantém como registro de acompanhamento do contrato.

7. Erros Comuns e Pontos de Atenção

Os desvios mais frequentes na contratação de hunting seguem padrões claros, e a lista a seguir serve de checklist para revisão de contrato e de operação:

• Comprar vigilância com nome de hunting, sem tempo de investigação dedicada no contrato, e descobrir o defeito apenas no primeiro relatório genérico.
• Matriz de dados definida por medo jurídico sem negociação técnica, deixando o provedor com acesso insuficiente para qualquer caça relevante.
• Backlog unilateral, ou só o provedor propõe hipóteses por ameaça de mercado, ou só o cliente propõe por contexto local, perdendo a síntese que é o valor da relação.
• Transferência de conhecimento omitida do contrato, com o cliente ficando cativo do provedor e repetindo o ciclo sem acúmulo interno.
• Achados de caça tratados como relatório, e não como incidente, consumindo a janela de contenção que o SLA de IR preservaria.
• Métricas de horas e tickets aplicadas ao hunting, incentivando volume de caças rasas em vez de profundidade onde importa.

O ponto de atenção estrutural é que o cliente precisa de um dono interno da relação, com competência para avaliar hipóteses e achados, porque a fase de feedback sem contraparte técnica no cliente não transfere nada. Esse dono não precisa ser um hunter pleno, mas precisa ler backlog, questionar priorização e reconhecer achado válido.

8. Integração com o Restante da Biblioteca

O backlog de hipóteses da fase do OTHF consome o método de geração do capítulo 7 e a priorização do THRIVE desta pasta, e os tickets TaHiTI funcionam como unidade de demanda e de entrega entre cliente e provedor, mantendo o processo padronizado dos dois lados. Os controles HNT do capítulo 15 definem o que o provedor encontra de estrutura no cliente, inventário de dados, ambiente de caça e baseline, e as métricas do capítulo 11, adaptadas na seção 5, são a régua de valor da relação.

No contexto de resposta, o escalonamento de achado conecta o OTHF ao capítulo 13 e aos controles RES do capítulo 15, e o exercício integrado do capítulo 16 pode simular um ciclo cliente e MSSP completo, com um grupo fazendo o papel de provedor, o que treina tanto a formulação de hipóteses quanto a avaliação de achados sob contrato. O capítulo 22 complementa o quadro legal, porque a matriz de dados compartilháveis é filha direta das políticas de compartilhamento e da LGPD tratadas naquele capítulo.