In relation to ETW events, recent windows process PR. Does ETW have any concept of filtering? Is there any possibility of defining a capture filter ie

exclude processes that look like svchost.exe -k

@Marcos Oviedo et al.

Yes, there could be filtering happening on the event properties (i.e. process_name in this case). The ETW tracing engine (POTE) could support that filtering in its post-processing stage. @zwass and I briefly talked about the idea of having filtering support but didn't decide on how to move this fwd. Should filtering be configured through a file-based configuration (similar to an FIM-like configuration) ?

Ya, @zwass and I have talked about this a few times over the years... I've even tried auto-generating a query to filter against the current non-evented win process events table - uses SwiftOnSecurity sysmon filter as a source - https://github.com/defensivedepth/osquery-filters I think any kind of functionality that we can build into it that allows some type of filtering like sysmon.

cc @alessandrogario have you thought about filtering on ingestion for the BPF tables you are working on?

Would this be pre- or post-capture filtering in the context of BPF?

I suppose this would be pre-capture. I wonder if we could find a good approach to unifying this kind of configuration across tables/platforms.

We are kind of limited on what we can do in BPF land. With the current core BPF tables we are generating the probe logic at runtime (based on the syscall prototypes/tracepoint descriptors on the system). With the new PR, the logic is written in a .c file that gets embedded within osquery and is read on startup.

| I've even tried auto-generating a query to filter against the current non-evented win process events table @defensivedepth that looks really cool! Did you manage to translate all the sysmon filtering primitives to SQL? We can either go this way and provide a tool to convert sysmon configuration into SQL sentences so they can be used on osquery, OR we can think of supporting a common filtering language through configuration. I explored the idea of building an open-source drop-in replacement of sysmon in the past (sysmonx), where I implemented all of the sysmon filtering primitives. Most of these primitives were already provided by boost (see here and here for examples), so the mimicking sysmon filtering shouldn't be complicated. Another filtering language to consider would be the Event Query Language (EQL) from Elastic. This filtering/threat-hunting language gained a lot of adoption in the security space as it was designed for security use cases. EQL syntax reference is here. One significant difference between these two filtering languages is that Sysmon filtering allows you to filter atomic events, and EQL allows you to express relationships between events. This is key if you want to capture suspicious behaviors rather than isolated events. An example of suspicious behavior will be winword.exe launching cmd.exe, and this cmd.exe instance is later running whoami.exe. If we see that filtering through configuration is something we would like to support, I think it will be important to have a standard filtering mechanism that can be used across all of the evented tables.

No, I didnt get them all done, but was still able to reduce rows returned by 30%+ just with known good stuff.

I agree. We can think of handling this as a separate feature. We can start by implementing a sysmon-like filtering approach and keep it simple for the time being.

Would love to be involved in discussions around this if it moves forward

Definitively! Something that would be good to define at this point will be the new evented tables to add on top of POTE. This framework will simplify the process of adding new ETW-based Osquery Event Publishers, so having a list of areas we might want to provide visibility into would be great to prioritize this work For example, from the top of my head, the new event tables I'd love to see going live are: • DNS monitoring • DLL Loading • Network Connections • Registry Monitoring • File Monitoring • Code Integrity

Drop it in the Blueprint issue?

good point, I'm going to create a different issue to capture and prioritize these tables