← Voltar ao feed
low

Kaspersky details automated SOC alert filter generation using FP-Growth and LLMs, cutting false positives by 99%

1 fonte(s) · 1 atualização(ões) · publicado 30/10/2026 07:00 · coletado há 2 dias

Securelist (Kaspersky) published a research/engineering post by Artemy Obukhov on automating the creation of filters that suppress false-positive security alerts in SOC workflows. The article compares three approaches: a deterministic algorithmic pipeline based on the FP-Growth frequent pattern algorithm, a single-prompt LLM generator, and a multi-agent LLM chain (Selector, Generator, Validator, Commentator). Results are measured with an approval rate metric and a false-positive reduction rate. The team reports choosing the simpler single-prompt LLM option, claiming a 99% reduction in false positives, 28% more filters generated per day, and 17% more efficient alert handling by analysts. This is defensive tooling research with no threat activity, vulnerabilities or indicators involved.

Detalhes técnicos

  • Events average ~400 fields; only a handful are useful for filtering, so field selection and string normalization (drive letters, user folders, case) are key preprocessing steps.
  • The algorithmic approach builds candidate field combinations from the rule's context using FP-Growth, ranks them, and proposes the top three to the analyst. It is deterministic, interpretable and dependency-free, but fails when no context exists (e.g. first-ever rule trigger) and struggles with atypical normalization cases.
  • The LLM approach removes the context dependency and handles non-standard normalization, but lacks output validation and concentrates all logic in one system prompt.
  • The agent-based chain adds validation and regeneration loops and modular tuning, at the cost of more model calls, latency and dependency on model availability in isolated environments.
  • A filter must avoid mirroring the detection rule query, otherwise it disables the rule; the recommendation is to use fields not referenced by the rule, or a portion of the path the rule does not match on.

Linha do tempo

  1. securelist.com ↗ · pub. 30/10/2026 07:00 · coletado 30/10 08:00 primeiro registro

    Kaspersky details automated SOC alert filter generation using FP-Growth and LLMs, cutting false positives by 99%

    ler a análise desta fonte

    Securelist (Kaspersky) published a research/engineering post by Artemy Obukhov on automating the creation of filters that suppress false-positive security alerts in SOC workflows. The article compares three approaches: a deterministic algorithmic pipeline based on the FP-Growth frequent pattern algorithm, a single-prompt LLM generator, and a multi-agent LLM chain (Selector, Generator, Validator, Commentator). Results are measured with an approval rate metric and a false-positive reduction rate. The team reports choosing the simpler single-prompt LLM option, claiming a 99% reduction in false positives, 28% more filters generated per day, and 17% more efficient alert handling by analysts. This is defensive tooling research with no threat activity, vulnerabilities or indicators involved.

    Technical Details

    • Events average ~400 fields; only a handful are useful for filtering, so field selection and string normalization (drive letters, user folders, case) are key preprocessing steps.
    • The algorithmic approach builds candidate field combinations from the rule's context using FP-Growth, ranks them, and proposes the top three to the analyst. It is deterministic, interpretable and dependency-free, but fails when no context exists (e.g. first-ever rule trigger) and struggles with atypical normalization cases.
    • The LLM approach removes the context dependency and handles non-standard normalization, but lacks output validation and concentrates all logic in one system prompt.
    • The agent-based chain adds validation and regeneration loops and modular tuning, at the cost of more model calls, latency and dependency on model availability in isolated environments.
    • A filter must avoid mirroring the detection rule query, otherwise it disables the rule; the recommendation is to use fields not referenced by the rule, or a portion of the path the rule does not match on.