[rst13]

Intrigued by your "real-time kernel-level enforcement" (like freezing suspicious processes). Sounds powerful, but also risky—how do you prevent false positives from bringing down legitimate workloads? Is there a built-in policy tuning mechanism, or are users expected to rely on predefined MITRE detections as-is?

[rafaeldavidtin]

I agree it’s risky and, IMO, it would be as good as the policy that drives it. Same happens with seccomp, lsm hooks (bpf or apparmor:selinux:smack:tomoyo), nft or netfilter, or any other policy driven mechanism.

Now, the enforcement feature, will never be unanimous (although runtime tools try to provide it). Of course there are straight forward cases like never execute a binary from procfs, or never allow x vídeos.com (that is a no brain automatic enforcement for almost everyone, let’s put this way).

It also depends on what kind of enforcement we talk: we apply synchronous network policies and dynamic ones after DNS answers for example (and that is enforced if the policy says so). This is an action (to something currently going on), different than a re-action (which happens after something has already happened but allows me to enforce a cluster policy, for example). We have synchronous actions (like our network policy update, and, soon, execution and file access policies) and mitigation reactions (try to kill, pause, introspect, etc) jittered from original trigger (search the whole tetragone discussion).

In our case we have actions for the network policy, actions for detections (in some detection methods), reactions to detection events and integration with external tools as detections occur.

To your answer: yes you will be able to define the actions, reactions and drive enforcement for reactions (3rd party integrations for example). For now we are only distributing the network policy and we are about to include more (we just need good feedback on things people want and use cases). We will also be providing soon a way for users to create their detection recipes (but we will probably have a big list of recipes made for the biggest use cases so users don’t have to worry).

Thanks for asking, I do agree with your concern (and I think most of sec people also share the same concern on that).

[rst13]

Thanks for the detailed reply! I see custom policy/assertions on kernel behavior as powerful. As a current osquery user managing a fleet of 10k+ hosts (mostly Linux boxes) I find the query model resonates in terms of ux. We have a set of SQL pipelines that run on top of it at my org. osq works well for monitoring but not detections. So this direction is interesting, I'll forward to my detection eng folks

[rafaeldavidtin]

I'm looking forward to talking them. Let them know we have a free of charge partnering program right now (where they can be design partners for the tool, get integrations and features that attend their needs and support). This is meant for medium/big sized companies with specific needs so we can better shape the tool. Ping me if you have any doubts. Cheers!