Enhancement ~ spitball~ idea: better feedback/freeform data entry (like a crash report?) at time of e.g. rejected FAA

[arubdesu]

According to the docs, the details visible when file access is blocked could be characterized as somewhat 'surface-level' about WHAT just tried to access the target configured in the policy at the 'tip of the spear'/highest level. Pardon I'm unaware of the other telemtry-type events may already be presently writing to logs in that situation. If not present, I'd propose including, if not expandable in the GUI itself, details like the process ID (which, sure, every end user is not a forensic engineer ready to jump down a rabbit-hole, but), and/or a step or so up (if not the entire process tree). It may be obvious but worth note that especially alarming/relevant events are when what tried to perform the access has persistence/was spawned via launchd/login items/via ye olde rusty cron/unix periodic stuffs. Not trying to replicate other security agents behavior exactly, or saying ALL processes should get recorded/flushed to disk at that time, but additionally spitballing, what if the GUI could perhaps assist at gathering a better understanding of behavior from the end user themselves, as they may have the wherewithal to observe/record what just (unwittingly) initiated the policy violation, like a crash report having a text input field asking what might have been going on around the time they could potentially provide correlate-able info?

[arubdesu]

Whoops, I got too excited (it's always on the next slide!) while watching your macsysadmin.se preso 😅 I see process groups/session IDs are in the telemetry (via metrics service?), but maybe the idea of freeform data collection/a note to security folks would be worthy of inclusion. I don't know what's most actionable/valuable besides what's already in the GUI to make visible but I feel like there's more of some sort of a 'there' there?

[pmarkowsky]

The link you reference is mostly for the information we'd want to send to a sync service / UI when you click the open button. So it's not everything that's collected.

In the past we've gotten a lot of requests for what the content was before and after accesses which can be tricky as it significantly increases the processing requirements.

That said as @mlw presented on the Roadmap slide in the Way Later sections we want to be able to identify certain files of value e.g. API tokens automatically. This can be accomplished using a Trufflehog like approach where you only read a tiny amount of data (say the first 64 bytes of a file) in a background thread / process and check it against a set of regular expressions then match that.

The idea would be to create FAA rules based on that match.

[pmarkowsky]

The process ID (which, sure, every end user is not a forensic engineer ready to jump down a rabbit-hole, but), and/or a step or so up (if not the entire process tree). It may be obvious but worth note that especially alarming/relevant events are when what tried to perform the access has persistence/was spawned via launchd/login items/via ye olde rusty cron/unix periodic stuffs.

So another thing to call out here is that the logs especially the protobuf / json logs have a lot more detail here. They're currently exported to /var/db/santa by default.

Admittedly we need to document the spool format so other tools can more easily read them when using the protobuf format.