santa icon indicating copy to clipboard operation
santa copied to clipboard

Efficient mechanism for rule pruning

Open p-harrison opened this issue 7 months ago • 4 comments

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?

p-harrison avatar Nov 13 '23 11:11 p-harrison