O estado do ML para detecção de anomalias de rede em nível SOC (2022–2026)

ML para detecção de anomalias de rede em nível SOC melhorou entre 2022 e 2026 - mas não porque “o Modelo X venceu o Modelo Y” em um benchmark.

Os avanços práticos estão em representações, estrutura de interação e decisão operacional (calibração, orçamentos de alertas, monitoramento de drift), sob restrições de taxa-base e pressão adversária.

Resumo executivo

Nota de leitura: “O que funciona / falha / hype” são heurísticas de praticantes sob as restrições típicas de um SOC (baixa prevalência, drift, adaptação adversária). Trate-as como priors padrão, não verdades universais - valide no seu ambiente e modelo de ameaça.

O que funciona (na realidade de produção):

Tratar ML como infraestrutura de representação (embeddings) que alimenta vários detectores e fluxos de triagem.
Usar grafos de interação para detectar “anomalias de coordenação” que a pontuação por fluxo não capta.
Projetar uma política explícita de alertas (calibração + limiarização + orçamentos), não enviar scores brutos.

O que falha (de forma consistente):

Avaliação de mundo fechado (splits aleatórios, um único dataset, sem testes entre ambientes).
Limiares globais sem controle de drift (tempestade de alertas + irrelevância gradual).
Pontuação “caixa‑preta” sem ganchos de investigação (a confiança do analista colapsa).

O que é hype (a menos que você prove o contrário):

Alegações de “generalização de modelos fundacionais” sem avaliação realista de implantação.
Alegações de “não supervisionado = sem rótulos” sem calibração, validação e loop de feedback.
Automação SOC agêntica sem sandboxing e auditabilidade rigorosos.

Um modelo mental visual (ciclo SOC-grade)

Ciclo de detecção ML em nível SOC: telemetria → representações → pontuação → política de alertas → triagem → feedback → monitoramento.

1) Por que a detecção de anomalias em nível SOC é diferente

Se você levar apenas uma ideia deste post, que seja esta:

A detecção em segurança é um problema de mundo aberto, adversarial, com drift e baixa prevalência.

Realidade da taxa-base (por que um “bom ROC” ainda pode ser inútil)

Quando incidentes reais são raros, mesmo classificadores “ótimos” afogam um SOC em falsos alertas. A métrica operacional é precisão (PPV) e carga de trabalho, não uma curva ROC bonita.

Seja a prevalência $\pi$, a taxa de verdadeiros positivos $TPR$ e a taxa de falsos positivos $FPR$:

\[PPV = \frac{TPR \cdot \pi}{TPR \cdot \pi + FPR \cdot (1-\pi)}\]

Nota operacional: $\pi$, $TPR$ e $FPR$ são definidos em relação à unidade de pontuação do seu detector (fluxo, sessão, janela, grupo de alertas, etc.). Mudar essa unidade altera a prevalência e o que “$FPR$” significa na prática.

Intuição concreta: quando $\pi$ é muito pequeno, você precisa de um $FPR$ extremamente baixo para manter o $PPV$ utilizável.

Exemplo	$\pi$ (prevalência)	$TPR$	$FPR$	$PPV$ (precisão)
“Parece bom no ROC”	$10^{-4}$	0.90	$10^{-3}$	~8%
“SOC‑grade‑ish”	$10^{-4}$	0.90	$10^{-4}$	~47%

A precisão colapsa sob baixa prevalência a menos que o FPR seja extremamente baixo.

Nota matemática: por que “acurácia” não se traduz em valor para o SOC

Para detecção de eventos raros, você pode ter alta “acurácia” mesmo com um detector inútil, porque $TN \gg TP$ por padrão. As perguntas do SOC são mais próximas de: - “Quantos minutos de analista por incidente verdadeiro encontrado?” - “Quantos alertas/dia isso gera sob taxas-base realistas?”

Avaliação de mundo fechado é um modo de falha padrão

Sommer & Paxson - “Outside the Closed World” continua sendo o melhor alerta de praticante: sua rede de produção não é seu dataset curado, e o “normal” muda o tempo todo.

O adversário faz parte do ambiente

Atacantes observam suas detecções (ou pelo menos seus efeitos) e se adaptam: eles miram pontos cegos em features, limiares e fluxos de rotulagem. Trate a detecção com ML como um sistema sociotécnico: dados + modelo + pessoas + processo.

Principais pontos (contexto do problema)

Precisão e carga de trabalho são restrições de primeira ordem.

Drift é inevitável; adaptação adversária é esperada.

“Não supervisionado” ainda precisa de governança, calibração e sinais de validação.

2) O que realmente mudou em 2022–2026

Três mudanças importam mais para defensores:

Aprendizado de representações amadureceu para telemetria de segurança (fluxos, pacotes, logs, grafos).
A cultura de avaliação melhorou (pelo menos nas melhores pesquisas): mais explícita sobre vazamento e realismo.
A decisão operacional amadureceu: calibração, incerteza e controle de taxa de alertas viraram temas de primeira classe.

3) Telemetria é uma escolha de design (especialmente sob criptografia)

A criptografia deslocou a visibilidade do payload para uma pilha de sinais em camadas:

Camada	Sinais de exemplo	Uso típico	Falha comum
Metadados de protocolo	versões TLS/QUIC, ALPN, SNI, cipher suites	baselines, agrupamento	churn de protocolo
Impressões digitais	famílias JA3/JA4	clustering + triagem	não são identidade; colisões
Estatísticas de fluxo	bytes/pacotes/duração, burstiness	baseline barato	satura rápido
Sequências	tamanhos/tempo de pacotes, sequências de fluxo	modelagem comportamental	atalhos do pipeline de captura
Estrutura de interação	grafos host↔serviço/domínio	comportamento de campanha	erros de resolução de entidades

Impressões digitais são “compressão interpretável”

JA4/JA4+ (famílias mais recentes que JA3) comprimem configurações de protocolo em identificadores relativamente estáveis. Não são indicadores mágicos - mas são features de alto impacto para clustering e baselining quando combinadas com tempo, destino e contexto de endpoint.

Quando fingerprinting não basta: representações aprendidas

ET-BERT é um bom exemplo da ideia de que, mesmo quando o payload está oculto, estrutura de sequência e padrões de nível de datagrama podem carregar sinal discriminativo.

As perguntas SOC‑grade não são “classifica o dataset X?”, mas:

Generaliza entre redes e pipelines de captura?
Como se comporta sob evolução de protocolo e aplicação?
Conseguimos monitorar drift e correlações espúrias?

4) Aprendizado de representações: de features a encoders

Em produção, “detecção com ML” raramente é sobre o head de classificação. É sobre representações:

quais sinais existem,
como você os tokeniza/agrega,
quais invariâncias você quer (independência de site, evolução de protocolo, robustez).

4.1 Objetivos auto-supervisionados que você vê em telemetria de segurança

Duas famílias comuns:

Predição mascarada (estilo BERT):

\[\mathcal{L}_{MLM} = -\sum_{i \in M}\log p(x_i \mid x_{\setminus M})\]

Aprendizado contrastivo (estilo InfoNCE):

\[\mathcal{L}_{NCE} = -\log \frac{\exp(\text{sim}(z,z^+)/\tau)}{\exp(\text{sim}(z,z^+)/\tau) + \sum_j \exp(\text{sim}(z,z_j^-)/\tau)}\]

Essas perdas importam porque permitem aprender um encoder a partir de telemetria abundante não rotulada e, depois, adaptar cabeças menores para:

agrupamento/deduplicação de alertas,
enriquecimento de triagem,
tarefas supervisionadas downstream onde há rótulos.

4.2 Autoencoders: baselines úteis, detectores pouco confiáveis

Autoencoders são populares porque rótulos são caros - mas a perda de reconstrução não garante que anomalias reconstruam mal. Trate-os como geradores de hipóteses (surfacing de outliers), não detectores autônomos.

Trabalho recente (por exemplo, Autoencoders for Anomaly Detection are Unreliable) detalha por que o erro de reconstrução é um sinal frágil de anomalia: modelos podem reconstruir anomalias bem, e podem aprender atalhos ligados a artefatos de coleta em vez de comportamento.

4.3 Transformers para tráfego: a interface importa mais do que o head

Transformers são valiosos quando se tornam encoders reutilizáveis de tráfego. Mas sua “mágica” está principalmente na interface de representação.

Autoatenção (operação central):

\[\text{Attention}(Q,K,V) = \text{softmax}\left(\frac{QK^T}{\sqrt{d_k}}\right)V\]

Autoatenção transforma sequências em representações contextuais.

Realidade de engenharia: você precisa decidir o que é um “token” (pacote, fluxo, sessão, evento) e quais campos embutir (direção, buckets de porta, deltas de tempo, JA4, categorias de domínio etc.).

Unidade de token	Exemplo de “token”	Melhor para	Principal risco
Fluxo	5‑tupla + estatísticas + JA4	baselines escaláveis	perde forma intra‑fluxo
Burst de pacotes	tamanhos + deltas de inter‑chegada	comportamento fino	caro + sensível ao pipeline
Eventos multi‑fonte	auth + DNS + netflow	narrativas SOC	normalização difícil

Deep dive: padrões comuns de tokenização (e trade-offs)

- **Fluxo como token:** escalável, mas perde detalhes de sequência intra‑fluxo. - **Bursts de pacotes:** captura timing/forma, mas pode ser caro e sensível ao pipeline de captura. - **Sequências de eventos (multi‑fonte):** maior valor para SOC, mas exige normalização + resolução de entidades.

4.4 Modelos fundacionais para segurança de rede: promissores, mas a avaliação é o gargalo

Esforços de pré‑treino em larga escala (por exemplo, netFound) sugerem um caminho para encoders reutilizáveis entre tarefas. Dois alertas dominam: 1) Acesso a dados e privacidade: corpora amplos de pré‑treino são difíceis de compartilhar. 2) Realismo de generalização: “funciona em benchmarks” não é “funciona entre redes”.

Principais pontos (representações)

Encoders melhores reduzem engenharia manual de features, mas não removem taxa‑base ou drift.

Escolhas de tokenização/agregação fazem parte do modelo (e muitas vezes são o verdadeiro ponto de falha).

Embeddings fortes sem ganchos de investigação aumentam MTTR e a desconfiança do analista.

5) Grafos de interação: a representação mais nativa ao SOC

Muitas perguntas do SOC são relacionais:

quais hosts autenticam em quais serviços,
quais domínios co‑ocorrem entre hosts,
quais processos conectam a quais destinos.

Aprendizado em grafos importa porque detecta anomalias de coordenação.

Direções representativas:

grafos de interação de fluxo para ameaças criptografadas desconhecidas (por exemplo, HyperVision),
GNNs indutivas que lidam com novos nós/arestas continuamente (padrões estilo E-GraphSAGE),
aprendizado contrastivo temporal em grafos para aprender invariâncias entre janelas (por exemplo, padrões estilo TCG-IDS).

Exemplo de grafo de interação: arestas raras e novas vizinhanças se destacam.

5.1 Construindo um grafo de interação de fluxo (padrão prático)

Defina nós como entidades (host, usuário, domínio, serviço) e arestas como interações em uma janela de tempo.

Pseudocódigo: construir um grafo de interação por janela

```text for each time window W: nodes := hosts ∪ domains ∪ services for each flow f in W: u := src_host(f) v := dst_service_or_domain(f) edge(u, v).count += 1 edge(u, v).bytes += bytes(f) edge(u, v).ja4_set.add(ja4(f)) ```

5.2 Intuição de GNN (message passing)

Muitas GNNs práticas podem ser vistas como agregação de vizinhança:

\[h_v^{(k)} = \sigma\Big(W^{(k)} \cdot \text{AGG}\big(\{h_u^{(k-1)} : u \in N(v)\}\big)\Big)\]

Isso se alinha a workflows de investigação: “o que mudou nesta vizinhança?”

Principais pontos (grafos)

Contexto de grafo transforma “score de anomalia” em narrativa investigativa.

Construção de grafos e resolução de entidades são frequentemente os verdadeiros gargalos.

6) Explicabilidade não é luxo: é requisito operacional

Uma detecção é uma decisão operacional: ela aciona workflow, contenção e trilhas de auditoria. Um “score de anomalia = 0,93” não é um motivo.

Explicabilidade de alto valor no SOC tende a ser:

em nível de entidade: qual host/usuário/serviço gerou o score?
localizada no tempo: o que mudou nesta janela?
contrastiva: diferente de qual baseline / vizinhos mais próximos?
acionável: que evidências coletar em seguida?

Artefato de explicabilidade	O que responde	Saída “boa o suficiente”
Deltas esparsos de features	“o que impulsionou isso?”	top‑$k$ features com valores
Exemplos / vizinhos	“parecido com o quê?”	3–5 casos históricos comparáveis
Diferença de vizinhança em grafos	“o que mudou nas relações?”	novas/raras arestas com timestamps
Incerteza / abstenção	“quão confiante está?”	prob. calibrada ou sinal de abstenção

Modos de falha - explicabilidade

Alertas só com score: sem narrativa → sem confiança.

Explicações globais: irrelevantes para a entidade/janela analisada.

Confiança não calibrada: “parece certo” sob drift e colapsa depois.

7) Pontuar é fácil; alertar é difícil (calibração + orçamentos)

Você não implanta um score de anomalia; você implanta uma política de alertas.

7.1 Calibração probabilística: tornar confiáveis as probabilidades previstas

Calibração probabilística pergunta se desfechos que recebem probabilidade $p$ ocorrem aproximadamente à taxa $p$ na população relevante. Ela se aplica quando a saída pretende ser uma probabilidade; um ranking ou score de anomalia não precisa ser.

Mapear scores para probabilidades requer desfechos rotulados (ou proxies atrasados confiáveis) de uma população representativa da implantação. Calibração não estabiliza limiares nem revela drift por si só; seleção de limiar, controle da taxa de alertas e monitoramento de drift continuam sendo controles operacionais distintos.

Ferramentas comuns de calibração probabilística incluem:

Platt scaling (calibração logística)
regressão isotônica

Quando há rótulos (ou proxies confiáveis), o Brier score é uma regra de pontuação própria útil para previsões probabilísticas:

\[\text{Brier} = \frac{1}{n}\sum_{i=1}^n (p_i - y_i)^2\]

Ele reflete calibração e resolução; portanto, avalie a calibração em si com diagramas de confiabilidade ou uma análise explícita de erro de calibração, em vez de tratar o Brier como uma métrica pura de calibração.

7.2 Predição conformal: cobertura, não calibração probabilística

Predição conformal envolve um modelo para produzir conjuntos ou intervalos de predição. Sob permutabilidade entre os exemplos de calibração e um novo exemplo, um procedimento conformal padrão busca cobertura marginal:

\[\Pr\!\left\{Y_{\mathrm{novo}} \in C_\alpha(X_{\mathrm{novo}})\right\} \ge 1-\alpha\]

Conjuntos vazios ou com múltiplos rótulos podem sustentar uma política de abstenção, mas essa garantia não transforma os scores de um classificador em probabilidades de classe calibradas. Em telemetria com drift ou dependência temporal, a permutabilidade é especialmente frágil; a cobertura precisa ser monitorada e o método conformal, adaptado ao fluxo.

7.3 Limiarização EVT (modelagem de cauda para controle da taxa de alertas)

Métodos EVT como SPOT modelam a cauda de um fluxo de scores para posicionar limiares com parâmetros explícitos de risco.

Se excedências acima de um limiar alto $u$ seguem uma Distribuição de Pareto Generalizada (GPD), probabilidades de cauda podem ser controladas via parâmetros ajustados $(\xi, \beta)$.

Operacionalmente, EVT/SPOT é uma ferramenta de controle de taxa de alertas / excedência de cauda sob suposições de estacionariedade; por si só, não garante $PPV$ útil. Na prática, você ainda precisa de backtesting, re‑ajustes e tratamento de sazonalidade/não‑estacionariedade.

7.4 Controle FDR online (tratar alertas como múltiplos testes)

Controle de false discovery rate online reformula “alertar ou não” como teste de hipóteses sequenciais - útil quando você quer controle explícito da “fração de alertas que é ruído” ao longo do tempo.

Isso depende de um mapeamento defensável de score→p‑value e de suposições sobre dependência; trate como camada de governança, não como garantia de qualidade.

Método de decisão	O que controla	Por que ajuda no SOC	Quando quebra
EVT/SPOT‑style	risco de cauda / taxa de alertas	estabilidade do orçamento de alertas	caudas não‑estacionárias
Conformal	cobertura marginal de conjuntos / intervalos	conjuntos explícitos de incerteza e abstenção	permutabilidade falha; conjuntos podem ser pouco informativos
FDR online	falsas descobertas ao longo do tempo	governança de carga	modelagem fraca de p‑values

Principais pontos (decisão)

Um único limiar global falha sob drift e prevalência variável.

Calibração probabilística e cobertura conformal são entregáveis distintos, com suposições diferentes.

Alertas devem ser governáveis com suposições explícitas e monitoramento.

8) Drift: decadência de acurácia e de significado

Drift não é exceção - é o padrão.

Dois tipos de drift importam operacionalmente:

drift de acurácia: o poder preditivo do modelo se degrada
drift de significado: a “história” por trás dos alertas muda (novo SaaS, novo comportamento de usuário)

Guardrails geralmente se parecem com: detecção de drift + monitores de volume de alertas + proxies de precisão (por exemplo, taxa confirmada por analistas, taxas de supressão).

Deep dive: teste de drift Page‑Hinkley (um padrão comum)

Uma forma unilateral comum para detectar aumentos sustentados atualiza a média e o desvio acumulado recursivamente. Inicialize $\hat{\mu}_0=S_0=M_0=0$; para $t\ge1$: $$ \begin{aligned} \hat{\mu}_t &= \hat{\mu}_{t-1} + \frac{x_t-\hat{\mu}_{t-1}}{t},\\ S_t &= S_{t-1} + \left(x_t-\hat{\mu}_t-\delta\right),\\ M_t &= \min(M_{t-1},S_t). \end{aligned} $$ Defina $PH_t=S_t-M_t$ e sinalize uma mudança quando $PH_t>\lambda$. A média corrente é usada uma vez no incremento do instante $t$; ela não é substituída retroativamente em todas as parcelas anteriores. Aqui, $\delta$ é a mudança tolerada e $\lambda$, o limiar de alarme. Para quedas sustentadas, inicialize $S^-_0=M^-_0=0$ e use a estatística espelhada explícita: $$ S^-_t = S^-_{t-1} + \left(x_t-\hat{\mu}_t+\delta\right), \qquad M^-_t = \max(M^-_{t-1},S^-_t), \qquad \text{sinalize se } M^-_t-S^-_t>\lambda. $$ De forma equivalente, aplique o detector de aumento acima a $-x_t$.

9) Pressão adversária: modele ameaças do detector e do pipeline

Você não precisa de “ataques de IA” hollywoodianos para entrar em território de ML adversarial - ataques ao pipeline e manipulação de workflow são mais realistas.

Superfície de risco	Pergunta do defensor	Controle típico (alto nível)
Workflow de rótulos	“Um atacante pode influenciar rótulos?”	separação de funções, gates de revisão
Pipeline de dados	“A coleta pode ser falsificada?”	checagens de integridade, anomalias na qualidade da telemetria
Saídas do modelo	“Scores podem ser sondados/exfiltrados?”	rate limits, controle de acesso, endurecimento de saída
Drift/adaptação	“A adaptação pode travar um envenenamento?”	gates de retreino, planos de rollback, canários

Use linguagem comum para revisões (NIST AML taxonomy; MITRE ATLAS) e trate artefatos de ML como qualquer outra dependência de produção.

10) Governança e segurança do pipeline

Se você implanta ML em detecção, está implantando um sistema sociotécnico: dados + modelo + pessoas + processo.

Uma lente prática de governança é o AI RMF da NIST (GOVERN, MAP, MEASURE, MANAGE). Em termos de SOC:

MAP: definir ameaças, ativos, raio de impacto e restrições operacionais (orçamento de alertas, SLAs).
MEASURE: monitorar desempenho, drift, calibração e saúde de rótulos.
MANAGE: gates de retreino, rollbacks e resposta a incidentes para o próprio pipeline de ML.

Controles de segurança (checklist conceitual):

linhagem e integridade de dados (coleta → armazenamento → features),
separação de funções (quem pode mudar features/limiares/modelos),
artefatos de avaliação imutáveis (experimentos reproduzíveis),
monitoramento de drift e volume de alertas,
logs de auditoria para qualquer automação (especialmente LLMs/agentes).

Modos de falha - governança

Sem rollback: o modelo vira uma dependência irremovível.

Drift sem dono: ninguém é responsável por “quando retreinar / quando congelar”.

Automação sombra: copilots sem auditabilidade viram risco de compliance.

11) Avaliação sem autoengano

Barra mínima para avaliação SOC‑grade:

splits temporais (sem vazamento do futuro)
testes entre ambientes (sites/segmentos/pipelines distintos)
unidades operacionais (alertas/dia, minutos de analista/incidente), não apenas AUC
reporte explícito sob taxas‑base realistas (precisão depende da prevalência)

Deep dive: por que PR vence ROC sob desbalanceamento extremo

Precisão e recall: $$ \text{Precision} = \frac{TP}{TP+FP}, \quad \text{Recall} = \frac{TP}{TP+FN} $$ ROC pode parecer ótimo mesmo quando o volume de $FP$ torna o detector inutilizável. PR explicita essa realidade operacional.

Matemática operacional: de FPR a alertas/dia

Se seu sistema avalia $N$ eventos majoritariamente benignos por dia, o número esperado de falsos alertas/dia é aproximadamente: Aqui, “eventos” significa o que quer que você pontue e possa alertar (fluxos, sessões, janelas, host‑days, grupos de alertas, …). $$ FP/day \approx FPR \cdot N $$ Com $N=50{,}000{,}000$ eventos/dia: - $FPR=10^{-4}$ → ~5.000 falsos alertas/dia - $FPR=10^{-5}$ → ~500 falsos alertas/dia É por isso que valores “pequenos” de $FPR$ ainda importam enormemente em escala.

12) Fronteiras: o que parece promissor (e o que é só hype)

12.1 Detecção multimodal (a camada de integração que falta)

Em segurança, “multimodal” significa rede + endpoint + identidade + contexto de grafo. Os melhores sistemas são híbridos:

ML para representação + pontuação
regras/assinaturas para restrições duras e conhecidos‑maliciosos
grafos para contexto
LLMs para sumarização e apoio ao workflow (não o detector primário)

12.2 LLMs e agentes no SOC

LLMs tendem a gerar mais valor na camada humana:

sumarização e anotações de casos
normalização de vocabulários de fornecedores
investigação com recuperação aumentada (RAG)

Automação agêntica deve ser tratada como código privilegiado: sandbox de ferramentas, permissões mínimas e auditoria de tudo.

13) Uma arquitetura de referência prática (SOC‑grade)

Arquitetura híbrida SOC‑grade: regras + embeddings + contexto de grafo + alertas calibrados + governança.

Um padrão durável:

Construir telemetria estável + resolução de entidades.
Treinar ou adotar encoders reutilizáveis (fluxo/sequência/grafo).
Tornar alertas controláveis (calibração + limiares + orçamentos).
Adicionar ganchos de investigação (contexto, vizinhos, protótipos).
Rodar monitoramento de drift + gates de retreino com rollback.

14) Uma perspectiva crítica (o que ainda erramos)

Três armadilhas persistentes

1) “Ataques desconhecidos” não são uma única categoria. Desconhecido pode significar:

nova família de malware em infraestrutura conhecida,
técnica conhecida em nova pilha de protocolo,
mudança benigna porém rara no seu ambiente,
campanha lenta escondida na variabilidade normal.

2) Reprodutibilidade e operacionalização são gargalos. Produção exige:

pipelines estáveis e disponibilidade de features,
monitoramento e mecânica de retreino,
governança, auditabilidade e gestão de mudanças,
integração com gestão de casos e ferramentas de resposta.

3) Acurácia não é a métrica que você pensa. Um norte prático é:

minutos de analista por incidente verdadeiro encontrado,
com orçamentos explícitos de alertas e rastreamento de drift.

Glossário

Orçamento de alertas: limite alvo de alertas por unidade de tempo (e/ou por analista), usado para manter a detecção governável sob drift.
Calibração probabilística: mapear scores destinados a ser probabilidades para que as probabilidades previstas concordem com as frequências observadas, geralmente requer rótulos ou proxies confiáveis.
Predição conformal: construir conjuntos ou intervalos de predição com garantia de cobertura sob suposições como permutabilidade; não calibra, por si só, probabilidades de classe.
Encoder / embeddings: modelo que mapeia telemetria bruta em vetores usados por várias tarefas downstream (clustering, retrieval, classificação).
Resolução de entidades: casar IDs entre telemetrias para que “host/usuário/serviço/domínio” se refiram a entidades consistentes.
EVT / SPOT: limiarização via modelagem de cauda para controlar taxa de excedência/alerta sob suposições de estacionariedade.
FDR (false discovery rate): fração esperada de falsas descobertas entre as descobertas; “FDR online” controla isso sequencialmente sob suposições.
FPR: probabilidade de marcar itens benignos como suspeitos (depende da unidade de pontuação e da política de decisão).
Grafo de interação: grafo em que nós são entidades e arestas são interações observadas dentro de uma janela de tempo.
JA3/JA4: JA3 é um fingerprint de TLS (ClientHello); JA4/JA4+ é a família sucessora de fingerprints que cobre TLS, QUIC e outros protocolos. Ambos são usados como features para clustering/baselining (não identidades).
PPV / precisão: probabilidade de um alerta ser verdadeiro dado que disparou (depende da taxa‑base).
Unidade de pontuação: o que você pontua (fluxo, sessão, janela, host‑day, grupo de alertas, …); define prevalência e volume de alertas.
Tokenização (neste post): como a telemetria é transformada em entradas do modelo (“tokens”), por exemplo, fluxos, bursts de pacotes ou eventos multi‑fonte.
TPR / recall: probabilidade de capturar um verdadeiro positivo quando ele ocorre, relativa a uma definição escolhida de “positivo”.

Referências

Checagens de realidade e avaliação

Representações (Transformers, grafos, robustez)

Limiarização, drift e controle estatístico

ML adversarial, governança e riscos de GenAI

Sinais de tráfego criptografado (fingerprints)