Skip to content

Profile size and performance

Wildcards and compaction aren't cosmetic. A profile is evaluated on every exec and every file open in the workload, and the matcher is a linear scan — so the size of the profile is a direct, per-event CPU cost. Abstracting a verbose profile into an abstracted SBOB isn't just tidier; it is measurably cheaper, often by two to three orders of magnitude.

Where profiles get big - they burden human and machine

A wildcard is justified, if an average analyst needs more time to verify each False Positive than implementing an independent filter

A learned profile records everything and often the install phase can be extremely verbose.

  • Exec arguments. A process launched many times with different command-lines becomes one entry per command-line.
    IRL Example: 1445 exec entries — from just 72 binaries (bash alone appeared 329 times, ps 305×)
  • File Opens. A workload that writes a file per session/request learns one Opens entry per path — grouped by [FLAGS].
    IRL Example: 120000 entries in Opens, mostly autogenerated JIT code

Wildcards and globs collapse the cardinality: {bash, ["bash", "⋯⋯"]} or /srv/svc/cache/* can make a huge difference. This is of course only admissible if those files are security irrelevant. This choice can only be made by a human, who thereby declares intent.

Why size is a per-event cost: the matcher is O(N)

  • ExecsMatchExecArgs is called per entry until one matches (or all are exhausted).
  • OpensCompareDynamic is called per entry, the same way.

Execs have a memory cost, whereas Opens (with exception of pathological cases) do not scale in memory.

Measured — Execs

The real learned agent profile above (1445 exec entries) vs. its wildcard form (72 entries, one ⋯⋯ per binary):

profile entries CPU / event memory / event on-disk (etcd)
verbose (learned) 1445 900 µs 3.6 MB allocated ~250 KB
wildcard (⋯⋯) 72 25 µs 50 KB allocated ~11 KB

Measured — Opens

Opens dominate count in most profiles, so they matter even more. 50 000 literal opens (100 directories × 500 per-request files) vs. the 100-entry wildcard equivalent that covers exactly the same files (/srv/svcN/cache/*):

profile entries CPU / event on-disk / resident
verbose (50 000 literal paths) 50 000 1.38 ms 1.38 MB
wildcard (100 * entries) 100 2.65 µs 1.79 KB