 Bon blindness. Welcome, everyone, to the Valco Mountain Truck. If you have joined us today, you likely wanted to explore falco evolution in cloud- nadanim whispering security. Our journey started in 2016, when falco, created by Syria, set a new standard in Linux security. In 2018 falco became the first ever And thanks to strong adoption contribution, two years later it was elevated to the incubation level. But there is more. In 2021 the plug-in system was introduced, allowing monitoring cloud logs and enabling threat detection in cloud platform. Shortly after that, Falchokottle, our ecosystem tool, In ime vse prezettavno, da počkaj je ovo počkaj, prihodljaj se vzetne vrštjega pridah. V 2020-jih vstajno in v moderni VPC, skupanjejega na kompajilu, vse začetne v tem teknologiju, je zrečeno, srečen spravil na vsega pravda. Vsrednosti sem imeli nekaj vzetr, prihodljali se vzetr, prihodljali zrečen, in vsega glasba in trener, vsega testa, vsega vsega začočnega FALCO kompatibilitetne. To so početne inicijove, ki inštrat FALCO in inovacije in zeločnje in zeločnje psih nekaj Zato pogledajte in vse boje zašliši za vse, da se zašliši za njih. Zelo, naša njiha je odliša moment. Što je, da se vse naprejšal, da se prišli v njiha njiha na klubo. Češče, kako se njiha njiha, Emilie Fox, In Justin Kormax, češče, da nekaj, nekaj ne nezajši za njiha, da se nekaj nezajši za vse, nekaj nezajši za njiha, Zelo, ki ti do vsem, ležimo do zelo vanilje v CNCF. Falko je vzgladno vse projekte. Čuto, ki ti do vse. Počakaj. Počakaj, Leo. Zelo, si tko vse vse izgledaj, kako noseli vse z CNCF In vse je včinjela, da da vse falco kakva načinu gerši, to je vse neselj, da se prišli všeč imeli, zelo neselj. Zelo nekaj falco programov, da se prišli nekaj nekaj nekaj dobrogačov, prišli nekaj dobrogačov, da bi nekaj dobrogačov všeč všeč nekaj dobrogačov. Po našim sekundi, nekaj se, Jason, Carlos in Melissa, nekaj se prišli način o toga, nekaj nekaj o čom, apart from making Falko graduate. So, where are, which are the areas where we are improving Falko? So, you are probably familiar with Falko, but if you are not, basically Falko acts as a security camera for the cloud, which means that we have a kernel module or any BPF probe that takes events and we have rules that you can use to be alerted when any of those events happens. Also, we have a plugin system to allow broad compatibility with lots of data sources. And what we do is that we have improved the project in five, essentially five areas. So, rules, maturity and language, if you have used Falko rules, we are making them better by the day, by each release. Plugins and integration with the ecosystem, newer detections and also, of course, taking care of the community and all the ecosystem projects that are around Falko. And, last but not least, we care a lot about the performance and security of the Falko project itself, the Falko system. So, I would like to start with detection improvements, because if you have used Falko, you know that we detect a lot of things. And if you are a security professional or if you are educating security in any way, you know that every detection can be bypassed. It's a fact of life. So, what do we do? We improve upon our existing detection and we also add new ones. So, last time when we were in Chicago, we were talking about the fact that we improved our symbolic link resolution a lot, because that's what was asked. And so, you probably have a question, what is the Falko bypass of the day and how we are making it and how we are making Falko better. And, for the latest release, we have fixed a bypass that is just this very tiny, innocent looking program that only runs once in school, which usually is detected by Falko, but if you are on a 64-bit architecture and you try to compile that on 32 bits, then you get 32-bit syscolemulation that used to be silent in the EBPF version of Falko, and you had to use the kernel model. We know that many adopters really care about using EBPF and core EBPF, and so we added this support for this latest release. Also, I think for this one, we had an issue open for probably a couple years. So, what people want to do is, and a lot of people here at KubeCon tell us that they want to use our rules that we distribute and modify them just a little bit. So, basically, instead of having to rewrite your own rules or copy-paste them, you want to be able to take the existing rule that is loaded by Falko and then apply your override and your modifications to it. So, for example, in this rule, you might want to add something to the condition, and you want to replace the output, because it conforms with what you want to do. And it was very awkward to do it before, and we know. So, we have introduced a new override section, so you can basically create a rule that has the same name as an existing rule, and tell that you only want to modify certain fields and you want to append to certain fields. Of course, not all fields can be appended or replaced. Well, all fields can be replaced, but not everything can be appended. If you try to append true to false, probably not going to work, but still. And this pairs very well with another rules announcement that we did in the last version, which is the fact that we now can match an arbitrary number of rules for each event. So, this gives much more flexibility for any adopter that wants to customize the ruleset, which is something that you are going to do if you are serious with your use of Falko. And, of course, that's something that I'm personally passionate about. We have improved a lot our testing infrastructure. We improve it every time, and we are now very proud to have both kernel testing for all our drivers with a massive test matrix, and we have some repos that maybe got a little bit out of hand with 47 different checks for each PR, but 47 is much better than 2, so we are very happy about that. And also, there is always this annoying security person that suggests and lightly forces security checking tools on each PRs to the other, and the annoying security person is me. I'm sure that the other maintainers love me for that. And, of course, we are always very happy to improve stability and security of the Falko project. There's a lot to improve insecurity with Falko, but we have people that care a lot about Falko's performance, and I think most of the user of Falko do. And who else is the most expert in Falko performance than our maintainer Melissa? Would you like to tell us a bit more about how we are improving performance? Thanks, Luca. Next. The busy persons tour of Falko performance. It's a very tough topic, but we've only got five minutes. Suppose you have a very beefy server, let's say, with 128 CPUs and 21 million syscall events per second that you're interested in monitoring. At the same time, you have to balance the overheads and the capabilities, and let's go over to the next slide. So, for the kernel drive-up portion, there are three options available. If you are going strong with a kernel 2.6, your choice is the kernel module. It has been around for a very long time. This is why there isn't even a mascot for it. Downsides are that you can crash the kernel, and measuring the kernel-side performance overhead is very difficult, but it is still the most performant driver. A safer alternative is EBPF, and Falko supports it starting with kernel 4.14. Starting with kernel 5.8, you can use Falko's modern EBPF driver. Powered by the rocket drive, compile once, run everywhere. It's very beautiful from a DevOps perspective, because now we can bundle the kernel driver within the user space binary, and it works for every kernel and every distribution just out of the box. Sending events from kernel space up to user space happens over buffers. The traditional EBPF driver allocates one buffer per CPU. For a very long time, the kernel buffer size was hardcoded in Falko, making this kernel buffer size configurable and marked a significant milestone for Falko. Because if any of these buffers is full, rien ne va plus, and the events are lost forever. For the modern EBPF driver, you can even share the buffers among multiple CPUs. Since Falko is 0.35, or last year, May, you have precise control over the syscall's Falko monitors. In order to function properly, Falko requires a few additional syscalls than just the ones you define in the rules. We then collect all of these syscalls of interest and inject them into the kernel over a map. Looking at the left side of the diagram, whenever a non-interesting syscall triggers, we immediately exit the monitoring logic without interfering. Everything is passive and Falko. Looking at the right side of the diagram in user space, we have to create a nice movie where Falko, the hero, wins. This involves time ordering the events when scanning the buffers, which is currently our biggest bottleneck. Falko's state engine in user space is what makes Falko so powerful. It allows you to correlate events across different syscalls. For example, if you have a process that opens a file, you know the command line argument, something that is not available at the same time in the kernel. A recent trend and under consideration for Falko is wanting to push rules matching into the kernel. However, if you are not very careful, you may end up creating a horror movie instead. This is because you are in the kernel, in the application context, and you can slow down everything. In severe cases, the SREs may even ask you to turn off the tool altogether. How to win? How to find the right balance and the right tradeoff? Benchmarking and never stop improving. Falko's participation in the CNCF Environmental Sustainability Tag is a great first step towards that goal. Switching gears. If you ever found yourself overwhelmed by navigating the upstream Falko rules, the new rules maturity framework may come in handy. Please be aware that it is the best effort on the part of the community and ultimately you have to decide which rules, if any, are interesting or useful to you. Jason, please take it away and share the pride, plug and play future of Falko with us. Thank you. Happy graduation, everyone. So, we're going to discuss right now about the newest developments of the plugin ecosystem. First of all, it has been very active over the past year and very prolific with new plugins as well and integrations. And I think this acts as a testament of how the plugin initiative is enabling new contributions and driving diverse contributions in the project. So, I'm just going to focus on the past eight months because we discussed a bit of this also in KubeCon.na last year. We have a new plugin that basically turns Falko into a syslog server so you can just dumps your logs to Falko and then do runtime detection on them. We have integrations for box and Salesforce, so you can basically have activity and security logs from those platforms piped into Falko for monitoring and detection purposes. We have a new integration with GKE. So, this is actually a flavor of the already existing Kubernetes audit logs plugin, but instead of receiving webbooks from the API server directly, which is harder to deploy and a lot of adopters complain about it, we just grab the logs right from the platform so it's much easier to deploy and use. The GCP audit plugin, instead, has been there already since before KubeCon.na, but has been growing a lot and we have went through a couple of releases very recently. So, please check that out. And there's also the anomaly detection plugin which Melissa over here is working on which will basically try to make Falko adaptive based on the host, you know, the workload you're seeing and try to make rules as less noisy as possible. This is a plugin that doesn't deal with cloud logs, but with system calls specifically. So, host use cases like the traditional Falko ones. And last but not least, which we're very excited about, we also have a brand-new plugin that provides Kubernetes cluster metadata, which we're gonna cover in a second. I want to stress that Falko nowadays is capable of digesting all this information also in the same instance. So, you have a lot of flexibility deployment wise. Speaking about Kubernetes, like most of you know, Falko supported that natively since always. And besides the deployment scenarios, one interesting thing that we do is we also communicate with the API server and we collect as much metadata as we can in order to enrich the security events emitted by Falko. So, for example, if you receive a security event because someone is opening a shell in your container, we can say what was the host, what was the container image, the name, but also the pod name, what deployment that pod was for, you know, and so on and so forth. This piece of functionality was super valuable for adopters, but also one of the things that was harder to maintain for us because of issues, scalability problems. For some key reasons, first is that we started, you know, integrating this so early on that we had to develop our own client for the API server, which of course is a maintenance cost. Second, the communication model we had with the API server had scalability issues in larger clusters, which our adopters presents, you know, as a complain of, you know, more and more. And third, consuming all this information on the Falko instance had a big, you know, performance toll that, you know, put the tool under stress. So, basically, this new feature has been re-implemented and re-thinked entirely as a plugin using the newest features of the plugin API. The good thing is that this has massively improved scalability and performance of the solution. So, please make sure you check it out. We were able to remove the previous legacy implementation. We was about 30,000 lines of code, and people don't usually brag about removing code instead of adding new ones, but we're really happy about it because it was a big obstacle in contributions and also bug resolutions for us. There's also written in Go, so it's much easier to contribute to and it's a standalone component that we release and develop separately from the Falko core code base. Given the fact that it's written in Go, we also have available out of the box all the packages, you know, of the Kubernetes ecosystem in the most modern way. This is out since Falko 0.37, this January. So, please make sure testing and let us know what you think. For whoever was used to the older support in Kubernetes metadata, I wanted to give a brief summary. So, on the left, you can see the fields that Falko had available before and I want to provide everyone reassurance that we didn't remove them. There's no breaking change whatsoever. What we did is part of them was still supported. So, all the fields that we can basically extract from the container runtime or for the host information that Falko has available without communicating with the BI server, it's still there. All the other fields are deprecated and will just return at, you know, a non-available value if you use the rules, but at least you don't have your rules being rejected if you still use that stuff. Instead, on the right, you see the new fields that we provide with the plugin, probably new ones that will be added in the future. We named this field class KS meta for this aggregation as as you see, there's a lot more, like pod, information, namespace, deployment, services, and so on. So, the plugin API is effectively becoming slowly and slowly the technical backbone on which we do innovation in Falko, both in refactoring what's already there and also bringing new features. And, you know, a big effort happened over the past year specifically to make it more and more powerful and basically hook into most, if not all, the execution points of Falko. And it's becoming, you know, it's this close to becoming powerful enough to basically do what Falko does. So, we're basically refactoring also the Falko code to comply to it. Looking back before, you know, I think around March last year, we started releasing the ability of sharing state between plugins, so like plugins right now can access the thread and actually, the thread information that Falko collects from the system. And we recently add support to injecting asynchronous events with time-sensitive priority. We have a native logger. We have the ability of doing dynamic reconfiguration of the plugins around time. Plus, we updated the C++ and go SDKs to, you know, be in sync with all the newest features. What's coming next? Accessing also the file descriptor information, which will be useful for the anomaly detection plugin, which is in the Roarking. Supporting non-trivial data types, because right now we just support for developers, you know, integers and strings and, you know, few others. A native metric support, potentially, you know, being exported through a Prometheus endpoint in the future. And we're also looking forward to new SDKs in new languages and stay tuned, because we may have something to reveal about that in the near future. Before finishing, this is another initiative totally unrelated, which I'm still part of, which is the Google Summer of Code. So, we participated as a project through the CNCF organization last year. It was an amazing experience and it turned out that it has gained a new contributor and a new maintainer, you know, having the FALCO playground for rules development to light. And we also set our presence in the WebAssembly day at lastCubeCon.na. So, we are also candidateing a new project for Summer of Code 2024, where I think at this point in the application process, we look forward to work with a new student. So, please check it out for wherever you is interested. This year, we are proposing working on systematic performance testing of FALCO. We would like to have this kind of checks in our CI-CD pipelines. And we want to also revamp the event generator, which is a very valuable project that kind of enables this stuff, but didn't receive much love over the past two years. So, yeah, we're gonna work on that. Aleksandar, in the slide. Carlos. Thank you. We're gonna do a quick tour about the FALCO ecosystem, like FALCO itself already explained here. We're gonna do, like, the tools around FALCO to help you to extract the best of FALCO itself. The first one is FALCO Sidekick, which is, we add more outputs. FALCO Sidekick is a tool that receives information alerts and everything that you set in FALCO, and it exports to whatever output you want. Like, for example, we add the hotel traces, diner traces, it's homologic for the previous one, but we have outputs for a lot of applications and systems that you can use. For example, Slack, matter most, or other systems. This tool was created initially by... In that time, he was just a contributor, Thomas, and it's written in Go. Everybody, like, it's easy to understand and contribute for that. The QR code here is for another tool that we are working, called the FALCO TALOM, that's gonna help you to integrate with FALCO and do the engine for automated, like, engine response. Like, you're gonna create your rules in FALCO, as soon as we get, like, detected a threat on an issue, we can, like, have this FALCO TALOM that can act and resolve and act in the issue back, automatically, that you can create the things. You can scan the QR code and go straight to the project page for that. It's a brand new thing that we are working on. Second one, it's FALCO CTL, FALCO CUTTO, whatever you guys want to call that. Like, I call FALCO CTL. It got, like, brand new features. Now, you can download drivers and replacing the... Not using batch scripts anymore. We also can... You can, like, push and download the rules and plugins and drivers, everything using FALCO CTL. And now we also... We have the signatures for the rules and plugins using cosign, sigstore cosign. And now we add more features, like, you can use a key MS stand of your own key or the keyless approach. The other one is the Sharta V4 that we've been working, like, to make it easier for install and maintain. Now that Jason explained the metacolator, it's much easier now to install out of the box this compatibility. And it's also installed automatic rules and plugins using the Helm chart for that. And you can use the FALCO CTL together with the Helm to detect and use your driver. Last one is the... I think this is pretty cool, like, the FALCO playground that you can try out your rules and test. The QR code here goes straight to that page. I hope you guys try out and give us any feedback about the issues. Leo? Thank you, Carlos. Okay. Immediately after the graduation, we asked ourselves a question. And now what? After a while, we found a very simple answer and basically is make FALCO even better and our user even happier. To ačiv this, we crafted a special roadmap that we are thrilled to announce today. The FALCO 1.0 was published this morning on our website. And while 1.0 might seem just like a number, it actually represents a promise to... a promise to maturity and stability to our users. To give you just a quick overview of the roadmap, this roadmap aims to introduce things like standard designs, start making more standardization of future adoption and application, introducing advanced metrics for FALCO and making the modern BPF the default driver. We are also working on our distribution system to make it more aligned with Linux best practice and make the FALCO deployment even more user friendly and secure. This roadmap also set a vision for the FALCO future. We indeed are working to integrate FALCO in third party distribution like the cloud marketplace. We are working also to improve our integration with cloud providers and we are pioneering new innovation. If you are curious, check out our roadmap at falco.org. We are near the end of the presentation and you can find us on Slack or meet us during our weekly community call. You will find all the link on our website on falco.org. If you join us, you will shape the future of cloud native runtime security with us. Thank you all. I want to say also thank you to Jason, Carlos, Melissa and Luca. Thank you.