Efficient mechanism for rule pruning

[p-harrison]

We've been using Santa on about 50 Macs for a few months now. Our rule database contains about 500 rules, a mix of binary/certificate/signingID. Of that 500, about half are duplicates where new versions of binaries have been released and an additional binary hash rule has been added. For example, we have 9 hashes for the alamofire-manifest binary, 5 for appt2 etc and a year from now these may all have doubled again.

Shrinking our ruleset from 500 to 250 rules would make it more manageable and I assume the problem is more significant for those using Santa in larger environments for a longer period of time.

Firstly I'm curious how others deal with this, and secondly I wonder if there is a feature enhancement that might help. Options that jump out to me -

1. Delete binary rules once they have been in our database for say 12 months. We would catch some rules that are still required but they could be re-added on-request, or automatically (on arrival of a BLOCK_UNKNOWN event) if they were just tombstoned for a further period of time instead of being deleted
2. Enable EnableAllEventUpload on all devices and track rule matches in our database so we know what not to prune. This would require no changes to Santa but would increase the load on endpoints and would significantly increase the load on Santa servers, to an impractical degree in larger deployments
3. Have the Santa client record rule matches and send this information to the server in summary form at each sync. This way the Santa server does need to process every execution of a binary, just the fact that a given rule was used at least once since the last sync. I guess this could be achieved in many ways, perhaps a last_rule_match_timestamp column in the rules database on the client? The existing EventUpload stage of the Sync protocol could probably be used as-is to get the information to the server with perhaps one new key like a boolean is_rule_match_event. A new configuration key could leave this feature disabled by default so existing server implementations are not impacted until they support it

Thoughts?

[russellhancox]

I assume the problem is more significant for those using Santa in larger environments for a longer period of time.
Firstly I'm curious how others deal with this

We don't. My machine has over 70k rules and we have tested Santa with well over 10M rules and saw no discernible performance penalty.

A full sync takes a little while but these are very rare and the protocol was designed to break up a full sync into multiple requests to make it more reliable.

Of that 500, about half are duplicates where new versions of binaries have been released and an additional binary hash rule has been added. For example, we have 9 hashes for the alamofire-manifest binary, 5 for appt2 etc and a year from now these may all have doubled again.

One option to reduce the number of rules you currently have would be to switch to replace binary rules with signing ID rules wherever possible. This will reduce the number of rules now and prevent the constant growth you're seeing.

[p-harrison]

My machine has over 70k rules and we have tested Santa with well over 10M rules and saw no discernible performance penalty.

That's incredible! Do you think most of those 70k rules are for binaries that are still in-use or do you have any process in-place to prune them?

We only have a tiny team of developers, but between homebrew, XCode, Android Studio etc we see 100-200 unsigned binaries which cannot be covered with signingID/certificate rules and which are updated every few months leading to new rules being required.

[russellhancox]

I think a lot of those rules are unused and there is no process to prune them, though there are several processes to remove or block binaries in certain circumstances. I probably have a larger number of rules than most as I've been running Santa on my machines longer than anyone but it was always a design goal that a huge rule database should work without issue.

[pmarkowsky]

I run with about 64,000+ rules as well. Most of the rules are for binaries that aren't on my machine.

Out of the options above the following makes the most sense to me.

3. Have the Santa client record rule matches and send this information to the server in summary form at each sync. This way the Santa server does need to process every execution of a binary, just the fact that a given rule was used at least once since the last sync.

One thought is that this could be an extension to the PostFlight step. Since we're already sending counters re:rules as of #1156.