The just released Falco v0.31.0 is the result of several months of hard work and includes many exciting new features. One of them, however, is particularly strategic for Falco as a project: the general availability of the plugins framework. I would like to use this blog post to explain why plugins are exciting and what they mean for the future of Falco. Let’s start by explaining what this new technology is.
Plugins are shared libraries that can be loaded by Falco to extend its functionality. Plugins come in two flavors:
The combination of Source and Extractor plugins allows users to feed arbitrary data into Falco, parse it in useful ways and create rules and policies from it. Let me give you an example: the Cloudtrail plugin extends Falco to understand Cloudtrail logs (either local or stored on S3) and allows you to write rules like this one:
- rule: Console Login Without MFA
desc: Detect a console login without MFA.
condition: ct.name="ConsoleLogin" and ct.error=""
and ct.user.identitytype!="AssumedRole" and json.value[/responseElements/ConsoleLogin]="Success"
and json.value[/additionalEventData/MFAUsed]="No"
output: Detected a console login without MFA (requesting user=%ct.user, requesting IP=%ct.srcip, AWS region=%ct.region)
priority: CRITICAL
source: aws_cloudtrail
A rule like the one above is validated and evaluated by your out-of-the-box Falco. But with plugins, rules can now be applied to almost any data source where you can write a plugin for it. And you can add new data sources without even having to rebuild Falco.
Falco’s “runtime security” philosophy is based on some key concepts:
This philosophy has proved to be very effective with system calls, and is the reason why Falco has thrived as a runtime security solution for containers.
Plugins extend the applicability of this philosophy to an endless number of new domains. One of these domains is cloud security.
Cloud security is a fertile and constantly evolving space. When implementing cloud security you can choose among many different options. However, architecturally, most options fall in one of the following categories:
To detect threats in cloud-based software, Category 1 is not very useful. Polling is great to detect gaps and validate compliance, but lacks the real-time nature required to detect threats and respond quickly. Category 2 is powerful, but it’s also tremendously expensive (especially in environments like the public cloud where tons of logs are produced) and not friendly to deploy and use.
I argue that the Falco runtime security approach is the ideal one. Falco consumes few resources and, most importantly, it analyzes the data in a streaming way. No need to perform expensive copies, no need to wait until the data is indexed. Falco looks at your data in real-time and notifies you in seconds.
Getting up and running with Falco takes only a few minutes, and adopting it for both cloud logs and system calls allows a unified approach to threat detection.
V0.31.0 comes with one plugin, Cloudtrail, but expect many more to come in the future. Our vision is to make Falco the runtime policy engine for, well, everything. :-) We want to support all the clouds, and include more services from each of them.
Stay tuned for announcements in the near future, and at the same time, please let us know if there is an area where you would like to see Falco in action in the future. Also, writing your own plugin is easy and, as a community, we would love to consider your creative contribution.
You can find us in the Falco community. Please feel free to reach out to us for any questions, suggestions, or even for a friendly chat!
If you would like to find out more about Falco: