ML for SOC-grade network anomaly detection improved between 2022 and 2026 - but not because “Model X beat Model Y” on a benchmark.

The practical leaps are about representations, interaction structure, and operational decisioning (calibration, alert budgets, drift monitoring), under base-rate constraints and adversarial pressure.

Executive summary

Reading note: “What works / fails / hype” are practitioner heuristics under typical SOC constraints (low prevalence, drift, adversarial adaptation). Treat them as default priors, not universal truths - validate in your environment and threat model.

What works (in production reality):

  • Treating ML as representation infrastructure (embeddings) that feed multiple downstream detectors and triage workflows.
  • Using interaction graphs to detect “coordination anomalies” that per-flow scoring misses.
  • Designing an explicit alerting policy (calibration + thresholding + budgets), not shipping raw anomaly scores.

What fails (reliably):

  • Closed-world evaluation (random splits, single dataset, no cross-environment tests).
  • Global thresholds without drift control (alert storms + gradual irrelevance).
  • “Black-box” scoring without investigation hooks (analyst trust collapses).

What’s hype (unless you can prove otherwise):

  • “Foundation model generalization” claims without realistic deployment evaluation.
  • “Unsupervised = no labels needed” claims without calibration, validation, and a feedback loop.
  • Agentic SOC automation without strict sandboxing and auditability.

A visual mental model (SOC-grade loop)

SOC-grade ML detection loop: telemetry → representations → scoring → alert policy → triage → feedback → monitoring.

1) Why SOC-grade anomaly detection is different

If you take only one idea from this post, make it this:

Security detection is an open-world, adversarial, drifting, low-prevalence problem.

Base-rate reality (why “good ROC” can still be useless)

When true incidents are rare, even “great” classifiers drown a SOC in false alarms. The operational metric is precision (PPV) and workload, not a pretty ROC curve.

Let prevalence be $\pi$, true positive rate be $TPR$, and false positive rate be $FPR$:

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

Operational note: $\pi$, $TPR$, and $FPR$ are defined relative to your detector’s scoring unit (flow, session, window, alert-group, etc.). Changing that unit changes prevalence and what “$FPR$” means in practice.

Concrete intuition: when $\pi$ is tiny, you need extremely low $FPR$ to keep $PPV$ usable.

Example $\pi$ (prevalence) $TPR$ $FPR$ $PPV$ (precision)
“Looks good on ROC” $10^{-4}$ 0.90 $10^{-3}$ ~8%
“SOC-grade-ish” $10^{-4}$ 0.90 $10^{-4}$ ~47%

Precision collapses under low prevalence unless FPR is extremely low.

Math note: why “accuracy” doesn’t translate to SOC value For rare-event detection, you can have high “accuracy” even with a useless detector, because $TN \gg TP$ by default. SOC questions are closer to: - “How many analyst-minutes per true incident found?” - “How many alerts/day does this generate under realistic base rates?”

Closed-world evaluation is a default failure mode

Sommer & Paxson’s “Outside the Closed World” remains the best practitioner warning label: your production network is not your curated dataset, and “normal” keeps changing.

The adversary is part of the environment

Attackers observe your detections (or at least their effects), then adapt: they target blind spots in features, thresholds, and labeling workflows. Treat ML detection as a socio-technical system: data + model + people + process.

Key takeaways (problem framing)

  • Precision and workload are first-order constraints.
  • Drift is inevitable; adversarial adaptation is expected.
  • “Unsupervised” still needs governance, calibration, and validation signals.

2) What actually changed in 2022–2026

Three shifts matter most for defenders:

  1. Representation learning matured for security telemetry (flows, packets, logs, graphs).
  2. Evaluation culture improved (at least in the best research): more explicit about leakage and realism.
  3. Decisioning matured: calibration, uncertainty, and alert-rate control became first-class topics.

3) Telemetry is a design choice (especially under encryption)

Encryption moved visibility away from payload into a layered signal stack:

Layer Example signals Typical use Common failure
Protocol metadata TLS/QUIC versions, ALPN, SNI, cipher suites Baselines, grouping Protocol churn
Fingerprints JA3/JA4 families Clustering + triage Not identity; collisions
Flow statistics bytes/packets/duration, burstiness Cheap baseline Saturates quickly
Sequences packet sizes/timing, flow sequences Behavior modeling Capture-pipeline shortcuts
Interaction structure host↔service/domain graphs Campaign behavior Entity resolution errors

Fingerprints are “interpretable compression”

JA4/JA4+ (newer fingerprint families than JA3) compress protocol configurations into stable-ish identifiers. They’re not magic indicators - but they are high-leverage features for clustering and baselining when combined with time, destination, and endpoint context.

When fingerprinting is not enough: learned representations

ET-BERT is a useful example of the idea that even when payload is hidden, sequence structure and datagram-level patterns can carry discriminative signal.

SOC-grade questions to ask are not “does it classify dataset X?” but:

  • Does it generalize across networks and capture pipelines?
  • How does it behave under protocol and application evolution?
  • Can we monitor it for drift and spurious correlations?

4) Representation learning: from features to encoders

In production, “ML detection” is rarely about the classifier head. It’s about representations:

  • what signals exist,
  • how you tokenize/aggregate them,
  • which invariances you want (site independence, protocol evolution, robustness).

4.1 Self-supervised objectives you actually see in security telemetry

Two common families:

Masked prediction (BERT-style):

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

Contrastive learning (InfoNCE-style):

\[\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)}\]

These losses matter because they let you learn an encoder from abundant unlabeled telemetry, then adapt small heads for:

  • alert grouping / deduplication,
  • triage enrichment,
  • downstream supervised tasks where labels exist.

4.2 Autoencoders: useful baselines, unreliable detectors

Autoencoders are popular because labels are expensive - but reconstruction loss does not guarantee anomalies reconstruct poorly. Treat them as hypothesis generators (outlier surfacing), not autonomous detectors.

Recent work (e.g., Autoencoders for Anomaly Detection are Unreliable) details why reconstruction error is a fragile anomaly signal: models can reconstruct anomalies well, and they can learn shortcuts tied to collection artifacts rather than behavior.

4.3 Transformers for traffic: the interface matters more than the label head

Transformers are valuable when they become reusable traffic encoders. But their “magic” is mostly in the representation interface.

Self-attention (core operation):

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

Self-attention turns sequences into contextual representations.

Engineering reality: you must decide what a “token” is (packet, flow, session, event), and which fields to embed (direction, port buckets, timing deltas, JA4, domain categories, etc.).

Token unit Example “token” Best for Main risk
Flow 5-tuple + stats + JA4 scalable baselines loses within-flow shape
Packet burst sizes + inter-arrival deltas fine-grained behavior expensive + pipeline-sensitive
Multi-source event auth + DNS + netflow SOC narratives hard normalization
Deep dive: common tokenization patterns (and trade-offs) - **Flow-as-token:** scalable, but loses within-flow sequence detail. - **Packet bursts:** captures timing/shape, but can be expensive and capture-pipeline sensitive. - **Event sequences (multi-source):** highest SOC value, but requires normalization + entity resolution.

4.4 Foundation models for network security: promising, but evaluation is the bottleneck

Large pretraining efforts (e.g., netFound) suggest a path to reusable encoders across tasks. Two caveats dominate: 1) Data access and privacy: broad pretraining corpora are hard to share. 2) Generalization realism: “works on benchmarks” is not “works across networks.”

Key takeaways (representations)

  • Better encoders reduce feature handcrafting, but do not remove base-rate or drift.
  • Tokenization/aggregation choices are part of the model (and often the real failure point).
  • Strong embeddings without investigation hooks increase MTTR and analyst distrust.

5) Interaction graphs: the most SOC-native representation

Many SOC questions are relational:

  • which hosts authenticate to which services,
  • which domains co-occur across hosts,
  • which processes connect to which destinations.

Graph learning matters because it detects coordination anomalies.

Representative directions:

  • flow interaction graphs for unknown encrypted threats (e.g., HyperVision),
  • inductive GNNs that handle new nodes/edges continuously (e.g., E-GraphSAGE-style patterns),
  • temporal contrastive graph learning to learn invariances across windows (e.g., TCG-IDS-style patterns).

Example interaction graph: rare edges and new neighborhoods stand out.

5.1 Building a flow interaction graph (practical pattern)

Define nodes as entities (host, user, domain, service) and edges as interactions in a time window.

Pseudocode: build a windowed interaction graph ```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 GNN intuition (message passing)

Many practical GNNs can be seen as neighborhood aggregation:

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

This aligns with investigation workflows: “what changed in this neighborhood?”

Key takeaways (graphs)

  • Graph context turns “anomaly score” into an investigation narrative.
  • Graph construction and entity resolution are often the real bottlenecks.

6) Explainability is not a luxury: it’s an operational requirement

A detection is an operational decision: it triggers workflow, containment, and audit trails. An “anomaly score = 0.93” is not a reason.

High-value explainability in SOC tends to be:

  • entity-level: which host/user/service drove the score?
  • time-localized: what changed in this window?
  • contrastive: different from what baseline / nearest neighbors?
  • actionable: what evidence should be collected next?
Explainability artifact What it answers “Good enough” output
Sparse feature deltas “what drove this?” top-$k$ features with values
Exemplars / neighbors “similar to what?” 3–5 comparable historical cases
Graph neighborhood diff “what changed in relationships?” new/rare edges with timestamps
Uncertainty / abstention “how confident is this?” calibrated prob. or abstain signal

Failure modes - explainability

  • Score-only alerts: no narrative → no trust.
  • Global explanations: irrelevant to the entity/window the analyst is triaging.
  • Uncalibrated confidence: “looks certain” under drift, then collapses.

7) Scoring is easy; alerting is hard (calibration + budgets)

You don’t deploy an anomaly score; you deploy an alerting policy.

7.1 Calibration: making scores behave like probabilities

If your “risk score” is uncalibrated, thresholds are unstable and drift becomes invisible.

Strictly, mapping scores to probabilities requires labeled outcomes (or strong delayed proxies). In many anomaly-detection deployments, “calibration” is often about stable thresholds, abstention, and alert-rate governance - not literal “probability of incident.”

Common tools (typically need labels or reliable proxies):

  • Platt scaling (logistic calibration)
  • isotonic regression
  • conformal prediction (set-valued / abstaining decisions)

When you have labels (or reliable proxies), a simple “calibration-as-metric” example is the Brier score:

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

7.2 EVT thresholding (tail modeling for alert-rate control)

EVT methods like SPOT model the tail of a score stream to place thresholds with explicit risk parameters.

If exceedances over a high threshold $u$ follow a Generalized Pareto Distribution (GPD), tail probabilities can be controlled via fitted parameters $(\xi, \beta)$.

Operationally, EVT/SPOT is an alert-rate / tail exceedance control tool under stationarity assumptions; it does not, by itself, guarantee usable $PPV$. In practice you still need backtesting, refitting, and seasonality/non-stationarity handling.

7.3 Online FDR control (treat alerts as multiple testing)

Online false discovery rate control reframes “alert or not” as sequential hypothesis testing - useful when you want explicit control of “fraction of alerts that are noise” over time.

This relies on a defensible score→p-value mapping and assumptions about dependence; treat it as a governance layer, not a quality guarantee.

Decisioning method What it controls Why it helps SOC When it breaks
EVT/SPOT-style tail risk / alert rate alert budget stability non-stationary tails
Conformal coverage / abstention “only alert when confident” drift breaks calibration
Online FDR false discoveries over time workload governance weak p-value modeling

Key takeaways (decisioning)

  • Single global thresholds fail under drift and changing prevalence.
  • Calibration is a deliverable, not a nice-to-have.
  • Alerting should be governable with explicit assumptions and monitoring.

8) Drift: accuracy decay and meaning decay

Drift is not an edge case - it’s the default.

Two kinds of drift matter operationally:

  • accuracy drift: the model’s predictive power degrades
  • meaning drift: the “story” behind alerts changes (new SaaS rollout, new user behavior)

Guardrails often look like: drift detection + alert-volume monitors + precision proxies (e.g., analyst-confirmed rate, suppression rates).

Deep dive: Page-Hinkley drift test (one common pattern) One simplified form tracks cumulative deviation from a mean estimate: $$ PH_t = \sum_{i=1}^t (x_i - \hat{\mu}_t - \delta), \quad \text{signal drift if } PH_t - \min_{j\le t}PH_j > \lambda $$

9) Adversarial pressure: threat model the detector and the pipeline

You don’t need Hollywood “AI attacks” to be in adversarial ML territory - pipeline attacks and workflow manipulation are more realistic.

Risk surface Defender question Typical control (high-level)
Label workflow “Can an attacker influence labels?” separation of duties, review gates
Data pipeline “Can collection be spoofed?” integrity checks, anomaly on telemetry quality
Model outputs “Can scores be probed/extracted?” rate limits, access control, output hardening
Drift/adaptation “Can adaptation lock in poison?” retrain gates, rollback plans, canaries

Use shared language for reviews (NIST AML taxonomy; MITRE ATLAS) and treat ML artifacts like any other production dependency.

10) Governance and pipeline security

If you deploy ML in detection, you’re deploying a socio-technical system: data + model + people + process.

A practical governance lens is NIST’s AI RMF (GOVERN, MAP, MEASURE, MANAGE). In SOC terms:

  • MAP: define threats, assets, blast radius, and operational constraints (alert budget, SLAs).
  • MEASURE: monitor performance, drift, calibration, and label health.
  • MANAGE: retrain gates, rollbacks, and incident response for the ML pipeline itself.

Security controls (conceptual checklist):

  • data lineage & integrity (collection → storage → features),
  • separation of duties (who can change features/thresholds/models),
  • immutable evaluation artifacts (reproducible experiments),
  • drift monitoring and alert-volume monitors,
  • audit logs for any automation (especially LLM/agent tools).

Failure modes - governance

  • No rollback: the model becomes an unpatchable dependency.
  • Unowned drift: nobody is accountable for “when to retrain / when to freeze.”
  • Shadow automation: copilots without auditability become compliance risk.

11) Evaluation without self-deception

Minimum bar for SOC-grade evaluation:

  • temporal splits (no future leakage)
  • cross-environment tests (different sites/segments/capture pipelines)
  • operational units (alerts/day, analyst-minutes/incident), not just AUC
  • explicit reporting under realistic base rates (precision is prevalence-dependent)
Deep dive: why PR beats ROC under extreme imbalance Precision and recall: $$ \text{Precision} = \frac{TP}{TP+FP}, \quad \text{Recall} = \frac{TP}{TP+FN} $$ ROC can look great even when $FP$ volume makes the detector unusable. PR surfaces that operational reality.
Operational math: from FPR to alerts/day If your system evaluates $N$ mostly-benign events/day, expected false alerts/day is roughly: Here, “events” means whatever items you score and could alert on (flows, sessions, windows, host-days, alert-groups, …). $$ FP/day \approx FPR \cdot N $$ With $N=50{,}000{,}000$ events/day: - $FPR=10^{-4}$ → ~5,000 false alerts/day - $FPR=10^{-5}$ → ~500 false alerts/day That’s why “small” $FPR$ values still matter massively at scale.

12) Frontiers: what looks promising (and what’s just hype)

12.1 Multimodal detection (the missing integration layer)

In security, “multimodal” means network + endpoint + identity + graph context. The best systems are hybrid:

  • ML for representation + scoring
  • rules/signatures for hard constraints and known-bad
  • graphs for context
  • LLMs for summarization and workflow support (not the primary detector)

12.2 LLMs and agents in SOC

LLMs tend to add the most value in the human layer:

  • summarization and case notes
  • normalizing vendor vocabularies
  • retrieval-augmented investigation

Agentic automation should be treated as privileged code: sandbox tools, minimize permissions, and audit everything.

13) A practical reference architecture (SOC-grade)

Hybrid SOC-grade architecture: rules + embeddings + graph context + calibrated alerting + governance.

A durable pattern:

  1. Build stable telemetry + entity resolution.
  2. Train or adopt reusable encoders (flow/sequence/graph).
  3. Make alerting controllable (calibration + thresholds + budgets).
  4. Add investigation hooks (context, neighbors, prototypes).
  5. Run drift monitoring + retraining gates with rollback.

14) A critical perspective (what we still get wrong)

Three persistent traps

1) “Unknown attacks” is not one category. Unknown could mean:

  • novel malware family on known infrastructure,
  • known technique on a new protocol stack,
  • benign-but-rare change in your environment,
  • a slow campaign hiding in normal variability.

2) Reproducibility and operationalization are bottlenecks. Production needs:

  • stable pipelines and feature availability,
  • monitoring and retraining mechanics,
  • governance, auditability, and change management,
  • integration with case management and response tooling.

3) Accuracy is not the metric you think it is. A practical north star is:

  • analyst-minutes per true incident found,
  • with explicit alert budgets and drift tracking.

Glossary

  • Alert budget: a target cap on alerts per unit time (and/or per analyst), used to keep detection governable under drift.
  • Calibration: mapping scores to meaningful decision outputs (probabilities or controlled alert rates), usually requiring labels or reliable proxies.
  • Encoder / embeddings: a model that maps raw telemetry into vectors used by multiple downstream tasks (clustering, retrieval, classification).
  • Entity resolution: matching IDs across telemetry so “host/user/service/domain” refer to consistent entities.
  • EVT / SPOT: thresholding via tail modeling to control exceedance/alert rates under stationarity assumptions.
  • FDR (false discovery rate): expected fraction of false discoveries among discoveries; “online FDR” controls this sequentially under assumptions.
  • FPR: probability of flagging benign items as suspicious (depends on the scoring unit and decision policy).
  • Interaction graph: a graph where nodes are entities and edges are observed interactions within a time window.
  • JA3/JA4: TLS/QUIC fingerprint families used as features for clustering/baselining (not identities).
  • PPV / precision: probability an alert is truly positive given it fired (depends on base rate).
  • Scoring unit: what you assign a score to (flow, session, window, host-day, alert-group, …); it defines prevalence and alert volume.
  • Tokenization (in this post): how telemetry is turned into model inputs (“tokens”), e.g., flows, packet bursts, or multi-source events.
  • TPR / recall: probability of catching a true positive when it occurs, relative to a chosen definition of “positive.”

References

Reality checks & evaluation

Representations (Transformers, graphs, robustness)

Thresholding, drift, and statistical control

Adversarial ML, governance, and GenAI risks

Encrypted traffic signals (fingerprints)

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 agentica 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:

  1. Aprendizado de representações amadureceu para telemetria de segurança (fluxos, pacotes, logs, grafos).
  2. A cultura de avaliação melhorou (pelo menos nas melhores pesquisas): mais explícita sobre vazamento e realismo.
  3. 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: fazer scores se comportarem como probabilidades

Se seu “score de risco” não é calibrado, limiares ficam instáveis e o drift se torna invisível.

Estritamente, mapear scores para probabilidades requer desfechos rotulados (ou fortes proxies atrasados). Em muitas implantações de detecção de anomalias, “calibração” costuma ser sobre limiares estáveis, abstenção e governança de taxa de alertas - não sobre “probabilidade literal de incidente”.

Ferramentas comuns (geralmente exigem rótulos ou proxies confiáveis):

  • Platt scaling (calibração logística)
  • regressão isotônica
  • predição conformal (decisões set‑valued / com abstenção)

Quando você tem rótulos (ou proxies confiáveis), um exemplo simples de “calibração como métrica” é o Brier score:

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

7.2 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.3 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 / abstenção “alertar só quando confiante” drift quebra calibração
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 é um entregável, não um “nice‑to‑have”.
  • 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 simplificada rastreia o desvio acumulado em torno de uma média estimada: $$ PH_t = \sum_{i=1}^t (x_i - \hat{\mu}_t - \delta), \quad \text{sinalize drift se } PH_t - \min_{j\le t}PH_j > \lambda $$

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 agentica 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:

  1. Construir telemetria estável + resolução de entidades.
  2. Treinar ou adotar encoders reutilizáveis (fluxo/sequência/grafo).
  3. Tornar alertas controláveis (calibração + limiares + orçamentos).
  4. Adicionar ganchos de investigação (contexto, vizinhos, protótipos).
  5. 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: mapear scores para saídas decisórias significativas (probabilidades ou taxas de alerta controladas), geralmente requer rótulos ou proxies confiáveis.
  • 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: famílias de fingerprints TLS/QUIC usadas 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)

Tags Tags

#cybersecurity #network_security #machine_learning #anomaly_detection #detection_engineering #soc #adversarial_ml #governance