Skip to content

feat(eventsource): Smart filtering with approvers#676

Merged
rabbitstack merged 15 commits into
masterfrom
rule-approvers
Jun 8, 2026
Merged

feat(eventsource): Smart filtering with approvers#676
rabbitstack merged 15 commits into
masterfrom
rule-approvers

Conversation

@rabbitstack

Copy link
Copy Markdown
Owner

What is the purpose of this PR / why it is needed?

CreateFile and RegOpenKey are among the most voluminous events in the system. We pay for the allocation cost because the raw event record is transformed into a typed Event structure. Additionally, there is also a processing penalty at the rule evaluation time.
With approvers, we can accept or reject events at the early stage of event processing, reducing both the pressure on the allocator and the rule engine as well.

What type of change does this PR introduce?


Uncomment one or more /kind <> lines:

/kind feature (non-breaking change which adds functionality)

/kind bug-fix (non-breaking change which fixes an issue)

/kind refactor (non-breaking change that restructures the code, while not changing the original functionality)

/kind breaking (fix or feature that would cause existing functionality to not work as expected

/kind cleanup

/kind improvement

/kind design

/kind documentation

/kind other (change that doesn't pertain to any of the above categories)

Any specific area of the project related to this PR?


Uncomment one or more /area <> lines:

/area instrumentation

/area telemetry

/area rule-engine

/area filters

/area yara

/area event

/area captures

/area alertsenders

/area outputs

/area rules

/area filaments

/area config

/area cli

/area tests

/area ci

/area build

/area docs

/area deps

/area evasion

/area other

Special notes for the reviewer


Does this PR introduce a user-facing change?


CreateFile and RegOpenKey are amongst most voluminous
events in the system. We pay for the allocation cost because the raw event record is transformed into typed Event structure. Additionally, there is also a processing penalty at the rule evaluation time.
With approvers we can accept or reject events at the early
stage of event processing, reducing both the pressure on the allocator and the rule engine as well.
As the approvers are now responsible for this task, we can offload IRP correlation via FileOpEnd events and get the CreateFile event with the create disposition.
With approvers many CreateFile events with OPEN disposition mask are rejected early. This allows us to
dispatch all CreateFile events to the evasion scanners
regardless of the file operation.
At rule compilation time, the compiler traverses the
AST tree and attempts to find event types for which
approver predicates can be derived.
Most notably, file and registry paths, file extensions, file base names and process executable paths are all candidates for approver predicates.
The new fs approver keeps in-flight CreateFile event
records and attributes them to FileOpEnd events via
IRP link.
When the respective FileOpEnd event record arrives,
we extract the create disposition and the system status
attributes and attach them to the CreateFile event record
by pushing synthethic extended items to the event record.
By leveraging the string builder and establishing the
capacity of the underlying slice, we can reduce a few
unnecessary allocations per event.
@rabbitstack rabbitstack merged commit 5e83361 into master Jun 8, 2026
11 checks passed
@rabbitstack rabbitstack deleted the rule-approvers branch June 8, 2026 21:37
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant