sims718718/unifiedthreathuntingDocumenta uma metodologia de caça a ameaças estruturada e repetível, abrangendo gatilhos, hipóteses SMART, critérios de viabilidade, definição de escopo, planos de caça e relatórios de resultados para equipes de segurança.
Como Caçador de Ameaças Líder, fui encarregado de construir um Programa de Caça a Ameaças do zero. Isso envolveu muita reflexão sobre o que a caça a ameaças realmente é e como traduzi-la em resultados significativos. Muitas horas foram dedicadas à leitura de diversas metodologias sobre caça a ameaças, engenharia de detecção, Inteligência de Ameaças Cibernéticas (CTI), forense e até mesmo experiência do meu tempo na Força Aérea dos Estados Unidos. No entanto, ao construir um programa, percebi que precisava de um processo, um Processo Unificado de Caça a Ameaças. Desenvolvi este processo para fornecer uma maneira estruturada e definida de caçar e, em última análise, entregar resultados significativos para a organização.
graph LR
Z[Step 0: Environment Context] --> A[Triggering Event]
A --> B[Hypothesis Development]
B --> C[Initial Assessment]
C --> D[Feasibility Assessment]
D --> E[Define Scope & Objectives]
E --> F[Formalize Hunt Plan]
F --> G[Execute Hunt]
G --> H[Document Outcomes]
H --> I[Report & Iterate]
I --> A
A caça a ameaças é a busca proativa por ameaças que contornaram os seus controlos. Essa definição está estabelecida; como executá-la como programa é que não está. Este processo é uma síntese, e a tabela é o registo honesto da mesma:
| Fonte | O que contribui aqui |
|---|---|
| Sqrrl / Hunting Maturity Model (Bianco) | O ciclo central e a escada de maturidade usada em Maturity & Metrics |
| TaHiTI | O trigger como o verdadeiro ponto de partida, e a passagem para processos adjacentes no fecho |
| PEAK | A tipificação da caça (hipótese / baseline / assistida por modelo) e o fecho orientado a resultados "agir com conhecimento" |
| AIMOD2 | A premissa de assumed breach e as categorias tipificadas de resultados |
| OTHF | O enquadramento operacional para executar caças como uma função de equipa repetível |
| Este processo acrescenta | Passo 0 Contexto do Ambiente · um gate rígido de viabilidade GO / NO-GO / CONDITIONAL · Jira Epic/Story/Task com resultados tipificados · uma hipótese validada por rubrica e uma passagem de deteção especificada |
Os diferenciadores são a última linha. Todo o resto assenta no trabalho de outras pessoas, citado em References.
Existem vários métodos descritos para conduzir operações de caça: estruturado, não estruturado, focado em TTPs, focado em intel, orientado por dados, e por aí adiante. Embora este Processo Unificado de Caça a Ameaças possa parecer estruturado, isso não significa que a sua hipótese não possa ser orientada por dados de forma não estruturada. Este processo procura incorporar vários tipos de caça a ameaças, permitindo uma abordagem modular. Utilizaríamos todas estas técnicas para garantir que testamos a nossa hipótese de forma rigorosa.
O objetivo é uma abordagem modular à caça a ameaças, onde não existe uma solução única para todos. Use todas as técnicas ao seu dispor.
Na prática, o tipo de caça que escolhe depende de onde está a começar na cadeia DAIKI (Data → Information → Knowledge → Insight):
| Tipo de Caça | Ponto de Partida | Características |
|---|---|---|
| Exploratória (EDA) | Dados em bruto | Estabelecer baseline, compreender a forma dos dados, sem hipótese prévia |
| Baseada em Hipótese (HBO) | Consciência situacional | Testar cenários de ataque credíveis com base no conhecimento da equipa |
| Informada por Ameaças (TIO) | CTI acionável | Orientada por inteligência, foco em ator ou TTP conhecido |
| Operações Purple (DPO) | Perceção da red team | Validação conjunta ofensiva/defensiva |
Seguindo princípios de ciência de dados, independentemente do tipo de caça, deve procurar explorar e compreender as fontes de dados relevantes para a sua caça. A pasta /Data_Analysis neste repositório contém técnicas de apoio e notebooks para essa fase de exploração.
Adicionalmente, a Threat Intelligence, quer seja um ponto de partida ou não, está enraizada em todo o processo para ajudar a orientar as operações.Threat Intelligence
Nota: Embora normalmente queira focar-se em comportamentos ou TTPs, os IoCs têm o seu mérito se forem verdadeiramente acionáveis e oportunos. Embora caçar IoCs por todo um ambiente não seja propriamente caça a ameaças, ainda podem fornecer informação útil e outro ponto de partida. Podem fazer parte do ciclo de caça, mas não a caça inteira em si.
Antes de qualquer caça começar, capture o ambiente para que cada artefacto a jusante (queries, nomes de campos, decisões de âmbito) seja adaptado ao local onde realmente trabalha, em vez de ser escrito de forma genérica. Adicionei isto como um passo explícito porque continuava a ver planos de caça que referenciavam fontes de dados que ninguém tinha, ou queries escritas no dialeto errado. Alguns minutos aqui poupam horas mais tarde.
No mínimo, documente:
| Contexto | Porque Importa |
|---|---|
| SIEM / Plataforma de Dados | Splunk SPL, KQL, Elastic DSL e Chronicle moldam cada query que escreve |
| Plataforma EDR | CrowdStrike, SentinelOne, Defender for Endpoint usam cada um nomes de campos de telemetria diferentes |
| Tipo de Ambiente | On-prem, cloud-native (AWS/Azure/GCP) ou híbrido altera quais logs sequer existem |
| Setor de Indústria | Determina quais atores de ameaça são realisticamente relevantes |
| Janelas de Retenção de Logs | Determina quais intervalos temporais são realmente viáveis de consultar |
| Nível de Maturidade de Caça | Caçadores de primeira viagem precisam de andaimes; equipas experientes querem um esqueleto |
Documente isto como um bloco Environment Profile no topo do Epic. Se estiver com pressa, o mínimo absoluto é plataforma SIEM e tipo de ambiente, qualquer coisa menos do que isso e as suas queries serão genéricas.
Caçar em múltiplas organizações? (MSSP/MDR, subsidiárias federadas, ou uma plataforma SIEM partilhada.) Mantenha um perfil por tenant num registo
tenants/<id>/profile.yamle faça cada Epic referenciartenant: <id>em vez de incorporar o perfil. Antes da viabilidade, verifique a autorização: um tenant sem cobertura de RoE/contrato, ou uma ação planeada fora das suasallowed_actions, está NOT AUTHORIZED e para aí. Equipas de organização única podem ignorar isto. Ver Multi-Tenant Operation.
Tomando emprestado do framework TaHiTI, a caça a ameaças começa com um evento desencadeador. Estes eventos justificam o início de uma caça. De acordo com o TaHiTI, os triggers podem incluir:
Para a nossa organização, usamos estes juntamente com alguns triggers adicionais, como requisitos diretos de stakeholders e divulgações de vulnerabilidades que afetam o ambiente.
Alguns frameworks começam a caça a ameaças com a Hipótese inicial (passo 2 aqui), mas eu pergunto: como chega a essa hipótese em primeiro lugar?
Há provavelmente um evento desencadeador que leva à hipótese inicial. Tal como Isaac Newton observou uma maçã a cair antes de se questionar que força a puxava para baixo, essa maçã foi o evento desencadeador que levou a uma hipótese sobre a gravidade. Da mesma forma, devemos ter um trigger antes mesmo de chegarmos a uma hipótese.