Different Tracee Experience: Everything is an event

[josedonizetti]

Hey, on this release we are experimenting with an improved way of using Tracee, and we would like to know what users of the project think. 🙂

In a nutshell, we want to unify tracee-ebpf and tracee-rules into a single binary that has a single output. That single output shows everything that Tracee might find in a common event format (hence the name “everything is an event”).

The way that Tracee is now designed can be broken down into two components: Monitoring, and Detecting.

Monitoring is the part where we collect as much information as possible from the operating system, with as much context as possible. This information is used to make detections later. For this collection part, we're using the executable called tracee-ebpf.

Those events coming from the operating system are feeding into the other component which is the detection engine. The detection engine tries to find suspicious patterns on the events based on rules (either built-in with Tracee or custom rules you add). This detection part is done using the executable tracee-rules.

The mechanics of operating tracee-ebpf and tracee-rules is handled for you by the container entrypoint. For example, to use the rule “anti_debugging” with Tracee today we need to start the collector (tracee-ebpf) and let it know which events it should collect from the kernel.

tracee-ebpf –-trace event=ptrace  

This command is then piped into the rules engine (tracee-rules) where we load the rule for anti_debugging.

tracee-ebpf –-trace event=ptrace | tracee-rules -–rules=TRC-102  

The current design assumes that the output of Tracee is detections, or in other words the output of tracee-rules. The output of the collector (tracee-ebpf) is considered internal raw data that is not exposed to the user.

This design means that our collector is limited to pass the information to the rule engine. But perhaps we wanted to collect and record other event. For instance, for interesting events that don’t have a rule or for events that complement an existing rule. Another example, if you wanted to collect execve in addition to the anti_debugging signature, to know what has been running inside containers, you would want to use the following command:

tracee-ebpf –-trace event=ptrace,execve| tracee-rules –-rules=TRC-102  

In this case tracee-ebpf will collect execve but tracee-rules just ignores it because it doesn’t have any rule for it. However, for events that don’t have a rule, we might still want to collect and store them for future analysis. For example, we can send it to bigquery and create some metrics on top of it.

This is the reason we started to draft this experiment for Tracee, which we are calling "Everything is an event". We joined both tracee-ebpf (collector) and tracee-rules (rules engine) into one single binary and exposed both the collector data and the rules detection as events. This allows users to not only have the rules, but also to access any of the 450+ events that Tracee can collect from the kernel.

In line with this emphasis on events, we will also add more meaningful and actionable events on top of the low-level events. For example, today we have many ways to trace execution of a program, based on different attach points in the kernel (to name a few: execve, execveat, security_bprm_check, sched_process_exec), each with its own nuances. Simplifying things, we can create a “higher level event” called “process_execution” that is a generic way to trace with a stable API. You can expect to see more events added to Tracee after we set the stage for it using this “everything is an event” infrastructure.

Compared with the example above, we want to start the rules for anti_debugging and dropped_executable but we also want to collect the events for execve, and dns. This can be done through the new experience with the following command:

tracee –trace event=anti_debugging,dropped_executable,execve,net_packet_dns   

As a result, now we can have the rules and the events. 😊

We would love to hear your feedback on the new experience. There is also a tutorial showing how to use the experiment in Kubernetes. Everything is an event

Please share any comments, suggestions or thoughts on the new experience with us here in the comments.