Falco – What is Falco?

About: Incepto Medical Case Study

Thu, 07 Mar 2024 00:00:00 +0000

Protect shared clusters for medical imaging

Incepto Medical provides on-demand medical imaging analysis to healthcare facilities. This analysis is based on AI technology manufactured or distributed by Incepto for mammography, X-ray, emergency, CT, MR and PET scanners. Incepto’s partners can also use shared clusters to host their own medical devices and AI models.

A secure, multi-tenant medical imaging service

Incepto Medical specializes in providing medical images analysis using artificial intelligence. Their models enable hospitals, private institutions and doctors to rapidly detect and diagnose cancer and other pathologies. Incepto shared platform can also be used to host and run their partner’s image analysis models.

Their service processes sensitive medical data in a multi-tenant environment. For these reasons, privacy and security are of utmost importance. Falco has been a good fit for their needs.

GPU-enabled Kubernetes deployments

Incepto deploys Kubernetes clusters in AWS in self-managed EC2 instances, having then full control over the infrastructure. The associated AWS services are managed via Terraform and the clusters are deployed using KOPS. The clusters consist of GPU-enabled Ubuntu instances. Each environment (dev/staging/prod) has its own cluster, and each cluster serves multiple customers. Tenant segmentation is carried out by namespace and by using Cillium CNI to manage the network.

Incepto’s API receives pseudonymized medical images from health institutions to comply with GDPR requirements. Falco is deployed as a DaemonSet in each cluster, monitoring both syscalls and Kubernetes audit logs. Falcosidekick runs alongside Falco to forward alerts to Slack. The alerts are segmented by client/partner namespace.

Empowering custom workloads securely

Incepto’s partners can submit their own container images to customize workloads and models. To provide this flexibility, they must ensure that customer workloads behave safely, and do not interfere with workloads from other tenants. For this reason, Falco runs on every node to alert of any policy violations at the OS level or in the Kubernetes environment by inspecting system calls and Kubernetes audit logs. Any drift that is detected in production is instantly reported.

Falco’s flexible rule engine allows Incepto team to continuously improve their detections by developing new custom Falco rules. They built a process to tune and promote Falco rules: Nothing goes into production without a staging period. The development and staging environments enable the testing of the new rules and ensure only relevant alerts will fire in production. Incepto went beyond Kubernetes, and they also created a custom set of Falco rules to detect suspicious activity in their S3 buckets, such as data exfiltration or corruption.

Choosing a security solution for Kubernetes

Incepto's DevSecOps team had previous experience with Falco, so it was a natural choice to adopt it. Adopting Falco was not without its challenges. Incepto team hit issues related to compatibility between Falco’s drivers and the Linux kernel in their VMs, to detection noise related due to different versions of the Nvidia drivers, and forwarding Kubernetes audit logs to Falco. However, once Falco was operational, they were assured that any security event would be detected.

In the end, Falco’s holistic approach to securing workloads gives Incepto the assurance that their customers’ data and proprietary models are safe. In the coming months, Incepto will be studying the feasibility of updating to the latest Falco version. Currently, they are using version 0.31 and the pre-plugin mechanism to ingest Kubernetes Audit logs.

About: Trendyol Case Study

Wed, 26 Jul 2023 00:00:00 +0000

Threat hunting at scale: auditing hundreds of clusters with Falco

Trendyol is a leading e-commerce platform in Turkey, with a fast-growing customer base of over 30 million people and a dedicated team of 4,000+ employees. With an extensive product selection spanning fashion, electronics, home & furniture, food, mother-child, and cosmetics, Trendyol has over 200 million items on its platform and delivers to 27 European countries. The company's impressive growth and broad range of offerings have solidified its position as one of the region's largest and most successful e-commerce platforms.

To ensure a seamless shopping experience for customers, they operate numerous production-grade Kubernetes clusters spread across nine distinct regions. Given the vast size of their infrastructure, it can be difficult to track each component, resource, user, and team promptly.

Background

On an average workday, Trendyol's production environment produces more than 700,000 Kubernetes audit logs per minute. Handling audits efficiently at this scale while minimizing disruption to the cluster's regular operations can pose a challenge.

Moreover, Trendyol required a reliable and scalable indexing and backend storage system that seamlessly integrates with the chosen solution to manage this substantial amount of data.

Trendyol aimed to create a system capable of identifying three specific anti-patterns: unauthorized privilege escalation, attempts to access Kubernetes secrets without proper authorization, and interactive access to running containers in their production environment. To enhance the security of their systems, Trendyol devised a monitoring system as their primary defense mechanism. This system implemented threat-hunting techniques to proactively identify potential security vulnerabilities and issues before they could be exploited.

Journey to Falco

To tackle tracking activities in its production environment, Trendyol created a monitoring solution by leveraging two open source projects: Falco and Fluent Bit. The team successfully developed an audit observability system and implemented alerting mechanisms by utilizing this architecture. These components work together to efficiently identify recurring patterns, enabling improved threat detection and enhanced visibility within the system.

Learn about the Technology

Fluent Bit is an open source tool that is lightweight and high-speed, serving as a data forwarder. It can collect, process, and forward logs and metrics from diverse sources to different destinations in real time. Unlike other popular open source tools, Fluent Bit is specifically designed to be more efficient and consume fewer resources. It can be used as a standalone tool or as a lightweight substitute for Fluentd in larger logging infrastructures.

Falco is an open source project focused on cloud-native runtime security. Its primary purpose is to monitor and identify unexpected behavior within cloud, host, and container-based environments, particularly in Kubernetes. By leveraging various event sources, such as Kubernetes audit logs and kernel system calls, Falco can promptly detect and raise alerts for potential security threats. It offers in-depth insights into the nature of these threats, empowering security teams to respond swiftly and efficiently to mitigate risks.

Events related to the Kernel tell us most of what happens above. Leveraging syscalls and kernel events is essential for monitoring the system and detecting potential security threats, as they play a crucial role in providing essential information about the activities and behavior of processes within the system.

To illustrate this, imagine a movie where a group of bad guys kidnaps a communication satellite to gain an advantage over the good guys. In this scenario, we assume the role of the good guys, and the kernel represents that communication satellite, which grants control and an advantage to whoever possesses it. This parallels how the good guys would use the information from the satellite to gain an advantage and foil the bad guys' plans.

The Architecture

When designing the architecture, Trendyol emphasized achieving optimal performance and scalability. They carefully aligned the architecture with its intended purpose and identified potential bottlenecks that could arise from integrating various components. Additionally, they prioritized factors such as fault tolerance and aimed to maintain vendor independence whenever feasible.

Because the architecture incorporates Fluent Bit and Falco, both active projects within the Cloud Native Computing Foundation (CNCF), vendor independence was not a significant concern. However, it remains important to consider the potential for future replacements and not overlook the possibility of maintaining vendor independence. This architecture is designed to function effectively in tightly coupled and component-independent configurations, offering flexibility and adaptability to suit different needs and potential future changes.

This architecture aims to effectively gather, process effectively, and store system and application logs with a focus on reliability. Fluent Bit is sufficient for the initial tasks of log collection and storage, particularly due to its ability to extract information from all the containers. However, the monitoring system goes beyond basic log processing by incorporating Falco. Falco introduces an additional layer of log processing capabilities by actively detecting Indicators of Compromise (IoC) within the log content. This integration enhances the system's ability to identify security threats and take appropriate actions.

In Trendyol's monitoring system, information is obtained from the Linux kernel of each node and the audit logs generated by the nodes that make up the control plane of each Kubernetes cluster. This could introduce additional complexity in the architecture since only a specific number of nodes within a cluster run instances of the Kubernetes API server. However, the right configuration makes Fluent Bit treat those particular nodes as any other, removing that potentially added complexity. Therefore, capturing and processing the audit logs from the control plane nodes would require a few additional tweaks for the Fluent Bit to retrieve the logs correctly.

Within Cloud-Native environments, a widely recommended approach among practitioners is to treat compute nodes and applications as cattle rather than pets. In this approach, the focus is on scalability and resilience rather than the individual instances themselves. The specific number of instances becomes less relevant, as the system is designed to scale up dynamically or down based on demand.

The Trendyol team recognized the importance of this principle and adopted it seriously. They prioritized building a Cloud-Native architecture that could easily scale and handle varying workloads without being constrained by the fixed number of instances. By embracing this approach, Trendyol ensured its system's flexibility and ability to adapt to changing requirements and fluctuations in demand, leading to improved performance and resilience.

As mentioned, the Kubernetes Audit Logs and Linux Kernel System Calls serve as the primary sources of logs in the monitoring system. While Fluent Bit serves as the main log collector and forwarder, it is incapable of understanding and collecting Linux Kernel System Calls. To address this limitation, Falco is responsible for retrieving information related to syscalls using its dedicated libraries. Falco diligently performs this task, ensuring that the necessary syscall data is captured and made available for further processing and analysis within the monitoring system. By leveraging the combined capabilities of Fluent Bit and Falco, Trendyol achieves comprehensive log collection, including both Kubernetes Audit Logs and Linux Kernel System Calls, enhancing their ability to detect and respond to potential security threats.

Understood, let's pause and focus on the Audit Logs. Falco does have the capability to receive Kubernetes Audit Logs directly. However, as of the time of writing, Kubernetes is limited to sending these logs to a single destination using the webhook backend. If the Audit Logs were sent directly to Falco, it would mean losing the option to enrich the log metadata and store the original ones in a dedicated logging storage for later analysis and compliance purposes.

To overcome this limitation, a potential solution is to implement a log-forwarding mechanism. By setting up a log forwarding system, the Kubernetes Audit Logs can be sent simultaneously to both Falco and the dedicated logging storage simultaneously. This way, Falco can effectively analyze the logs in real-time for immediate threat detection, while the original logs are also preserved in the dedicated storage for future analysis, auditing, and compliance requirements.

By employing this log forwarding approach, Trendyol can maintain the benefits of both real-time monitoring and long-term log storage, ensuring a comprehensive, resilient and robust monitoring system that aligns with operational and compliance needs.

In the solution implemented by Trendyol, the log backend mechanism provided by Kubernetes is utilized for collecting the Audit Logs. This mechanism involves writing the audit events to a file, which is then accessed by Fluent Bit. Fluent Bit retrieves the audit events from the file and sends them to multiple destinations, including the Falco Service and previously mentioned dedicated storage.

During this process, Fluent Bit takes the opportunity to enrich the log stream by adding relevant data such as the cluster origin, region, and the team associated with the cluster. This additional information provides contextual details that can be valuable for analysis and monitoring. By leveraging the Kubernetes Audit log backend mechanism and employing Fluent Bit's log enrichment and distribution capabilities, Trendyol achieves a comprehensive monitoring system that incorporates real-time threat detection with Falco and ensures long-term log storage for operational and compliance needs.

Indeed, with Falco receiving information from the Kernel via native System Calls and the Kubernetes API Audit Logs through Fluent Bit using the K8s Audit Plug-in, the next step is processing this collected data.

Falco excels in real-time processing and analysis of the received logs. It leverages its rule-based detection engine to evaluate the log entries against a set of predefined rules or policies. These rules define specific behaviors or Indicators of Compromise (IoCs) that Falco actively looks for within the log content. When a log entry matches a rule, Falco generates an alert or triggers an action, providing the security team with immediate visibility and an opportunity to respond to potential threats swiftly.

To clarify, the same rule engine will process both sets of events, including the parsed System Calls and the K8s Audit Logs. However, they will each be evaluated against different rules tailored to their specific context.

For the System Calls, Falco will apply rules designed to detect anomalous behavior related to file access, process creation, or other relevant activities. These rules are crafted to identify potential security threats or unauthorized activities within the system. When a System Call event matches one of these rules, Falco will generate an alert that will be sent back to Fluent Bit.

On the other hand, the K8s Audit Logs will undergo analysis using a separate set of rules specifically created to identify Indicators of Compromise (IoC) related to the usage of the Kubernetes API. These rules will focus on detecting actions such as unauthorized access attempts, attempts to access deployment secrets, or the exposure of applications to the external world unnecessarily. Whenever an event from the K8s Audit Logs matches one of these rules, Falco will generate an alert that will be treated as those generated when processing the System calls.

To enable simultaneous forwarding of alerts generated by Falco to multiple destinations, additional configuration and auxiliary tools such as Falco Sidekick would be required. However, Trendyol opted for a different approach to achieve this goal.

Following a similar method used to collect the K8s Audit Logs, Trendyol decided to leverage file-based reading to handle the alerts generated by Falco. Each container within the environment is associated with a file descriptor (FD) in a known location on the node. Fluent Bit, configured accordingly, captures the contents of these container-associated log files and sends them to the dedicated logging storage.

Fluent Bit also adds value by labeling the logs with tags for improved identification during later stages of analysis and processing. This ensures that the alerts can be easily distinguished and categorized based on their origin and other relevant metadata. This labeling assigns a different priority to the Falco logs during further processing.

Indeed, utilizing Fluent Bit for forwarding Falco alerts saves resources on the Falco instances themselves. It eliminates the need to configure each Falco instance individually to send alerts to potentially dynamic destinations. With Fluent Bit's capability to identify the cluster it is running in, it can seamlessly handle forwarding the alerts.

By leveraging Fluent Bit's features and implementing a standardized configuration pattern, Trendyol has optimized resource utilization, facilitated log identification, and established an efficient and scalable monitoring system that can be easily replicated across their infrastructure.

Results

The architecture implemented by Trendyol emphasizes optimal performance, scalability, fault tolerance, and vendor independence. The system collects and processes Kubernetes Audit Logs and Linux Kernel System Calls, using Falco and Fluent Bit to enrich and distribute the logs. Falco applies rule-based detection to evaluate the logs, generating alerts when specific behaviors or Indicators of Compromise (IoC) are detected. By forwarding alerts through Fluent Bit, Trendyol efficiently processes and stores them, ensuring comprehensive monitoring and long-term log storage for real-time threat detection and future analysis.

Overall, Trendyol's use of Falco and Fluent Bit has optimized resource utilization, streamlined configuration, and established a scalable monitoring system. The combination of these open source projects has allowed Trendyol to enhance security, improve visibility, and efficiently track activities within its complex infrastructure. Moreover, Trendyol has achieved a repeatable configuration pattern that can be applied to new clusters, regardless of the region they are created in. This consistency in configuration allows for streamlined deployment and management of the monitoring system across different clusters, simplifying the operational processes and ensuring a consistent security monitoring approach.

About: R6 Security Case Study

Tue, 25 Jul 2023 00:00:00 +0000

R6 Security Leverages Falco to Enhance Their Moving Threat Detection Platform, Phoenix

R6 Security was founded in 2020 to address the unique challenges of securing modern computing environments. Realizing that traditional security offerings based on static signatures were insufficient in today’s cloud native world, R6 Security created Phoenix to offer a more proactive approach to address the ever-changing security challenges around Kubernetes and containers.

R6 Security’s flagship product, Phoenix, leverages Falco’s threat detection capabilities. Phoenix is a security solution for Kubernetes that takes protection to a higher level by introducing the Moving Target Defense (MTD) paradigm. MTD ensures the monitored system is constantly changing and evolving, helping to render hacker’s efforts ineffective. MTD does this by killing and relabeling pods on fixed or random time intervals, automatic reconfiguration and other complex obfuscation actions.

Building on Falco

While building Phoenix, R6 Security received customer feedback that real-time threat detection across various scenarios was a mandatory feature. The R6 Security team was familiar with Falco through connections to the wider Falco community and previous experience with the tool. Additionally, the team had previous experience with commercial security offerings, and they evaluated other open source projects as well.

However, they ultimately settled on Falco for three key reasons:

Its powerful threat detection capabilities
The strength of the Falco community
A proven track record of success with other users

Falco serves as the underlying detection mechanism for Phoenix. When Falco detects suspicious activity, Phoenix’s automated remediation processes kicks off. Phoenix’s custom Kubernetes operator handles the remediation process.

As an example, let’s say someone executes a shell into a running container. Falco running as part of the Phoenix platform, would detect that activity in real time and then forward that event to a Phoenix sidecar running inside the Falco pod. From there the Phoenix Kubernetes operator would receive the event from the sidecar, and perform some sort of remediation. That remediation could include tagging the container as compromised and deactivating it (but not deleting it), so it could be examined later as part of any forensics activities.

This workflow happens even if the tool receives a false positive. Companies spend a lot of time investigating false positives, then deciding if they need to take action. So, rather than trying to investigate these false positive indicators, the system simply performs the automated remediation, keeping users up and running while reducing the time operators need to spend investigating.

The combination of Falco's threat detection capabilities and Phoenix's mitigation features helps effectively address security issues that might evade other security offerings.

The addition of real-time alerting via Falco allows Phoenix to adjust the cluster’s configuration as soon as suspicious activity is detected instead of waiting for the next random update interval.

During the development process R6 Security discovered they needed a way to forward Falco events to their Kubernetes operator. To achieve this they added a sidecar to the Falco pod that receives events from Falco, and then forwards them to their operator. These changes were submitted as a PR and eventually merged into Falco.

Falco has proven to be very accurate in detecting threats, catching around 80-85% of attacks based on red teaming and real-life scenarios. Reaching this level of detection required a multi-pronged approach. There was, of course, fine tuning of the Falco rules, but also the addition of static application security testing. And, it’s important to note, that there is an amount of overhead associated with using Falco and performing the automated remediation. Estimates put this at approximately 1-8% additional CPU or memory. Of course, this varies by workload, and you should plan on doing your own testing.

Conclusion

Today, R6 Security’s Phoenix product is leveraging Falco to help customers deal with attacks that might otherwise have gone undetected. Although there were some challenges integrating the two technologies, the R6 Security team ultimately found Falco's real-time detection capabilities and the strength of the Falco community to be invaluable.

About: Falco Ecosystem

Mon, 01 Jan 0001 00:00:00 +0000

Falco ecosystem

Falco’s rich ecosystem of plugins and integrations with the cloud native stack will help you enhance your organization’s security posture. This page showcases plugins and integrations, as well as success stories from end users, and vendors whose products build on Falco.

You can connect Falco with your ecosystem by forwarding the events as output to 50+ targets with Falcosidekick.

More outputs...

Need a new integration?

Helm

You can smoothly install Falco and its ecosystem components in your Kubernetes clusters with our official Helm charts, more info here.

Falco’s capabilities to ingest and analyze events can be extended with Plugins. They are shared libraries that allow you to add new streams of events as inputs to Falco and to enrich your events with more contextual information.

Collect GitHub Webhook Events

Collect Kubernetes Audit Events and monitor Kubernetes Clusters

Read Kubernetes Audit Events from AWS EKS Clusters

Reads CloudTrail JSON logs from files/S3 and injects as events

Read Docker events

Collect Okta Audit logs

Collect Nomad events

More plugins...

Build your own plugin

Falco FAQs

Here are the system call event types and args supported by the Falco drivers.

By default and for performance reasons, Falco will only consider a subset of them, indicated in the first column of the same table. However, it's possible to make Falco consider all events by using the -A command line switch.

This doesn’t make Falco cover all possible threats automatically. Without the proper rules in place, many of those events will be seen as regular behavior between the processes and the kernel.

No, the k8s set of fields k8s.ns.name and k8s.pod.* (i.e., k8s.pod.name, k8s.pod.id, k8s.pod.labels, and k8s.pod.label.*) are populated with data fetched from the container runtime.

Therefore, they can also be accessed without having the Kubernetes Metadata Enrichment functionality enabled (-k Falco option).

The performance overhead of Falco can have a large variability and typically scales up and down in relation to the amount of load of the server or VM and the workload footprint (e.g. network heavy servers likely cause Falco to consume significantly more CPU).

This is because Falco hooks into kernel syscall tracepoints and the more syscalls invocations occur the more work has to be done, that is, parsing the event in the kernel, sending it to userspace over a ring buffer, parsing in userspace and applying Falco's rule filters. This fact also makes it hard to derive stable performance metrics, as CPU and memory will fluctuate with the workloads it is monitoring.

Options available to tune performance

Some syscalls are more high-volume than others, perform a cost-benefit analysis according to your organization's threat model and security posture. The list of syscalls that are activated is one of the most significant factors that drive CPU utilization. In addition, there are tricks to craft Falco rules more effectively.
Contact your organization's SREs and conduct performance tests in your environment early on in order to derive budgets and appropriate limits (CPU and memory used). We recommend to always run Falco in cgroups to also not starve the tool on the flip side.
Memory: Falco allocates a ring buffer for each CPU, the more CPUs you have the more memory is allocated. For high load servers you may even need to increase the size of each buffer to avoid kernel side syscall drops. In addition, Falco builds up process threads state over time and memory increases as a consequence, but at some point should plateau.

Lastly, while the Falco community is constantly improving and optimizing the tool and exposing more settings and options in falco.yaml to customize the deployment, there are factors that are out of reach. Concrete examples include the fact that kernel settings alone or the hardware type can have tremendous impacts on the tool performance even when all else is constant.

Go to all FAQs

Was this page helpful?

Let us know! You feedback will help us to improve the content and to stay in touch with our users.

About: Falco use cases

Mon, 01 Jan 0001 00:00:00 +0000

What you can do with Falco today

Falco can help organizations comply with industry regulations and align with well-known security frameworks. For example, Falco can detect adversarial tactics, techniques, and procedures (TTPs) aligned with the MITRE ATT&CK framework, ensuring proactive identification of threats, intrusions, and data theft in real time. It works well with legacy infrastructures, and excels at supporting containers, Kubernetes, and the cloud. Falco monitors both workloads (processes, containers, services) and infrastructure (hosts, VMs, network, cloud infrastructure and services).

It is lightweight, efficient, and scalable, making it ideal to use in both development and production. Furthermore, Falco assists engineering teams in maintaining regulatory compliance by actively detecting misconfigurations associated with frameworks such as PCI DSS and NIST. Falco can detect many classes of threats and misconfigurations in running workloads out of the box, but should you need more, you can add custom detections. Falco is driven by a thriving open source community, bringing support and constant enhancement.

Align threat detections with the MITRE ATT&CK Framework

The landscape of containers, Kubernetes and Cloud is evolving fast, and so are potential attacks. To help InfoSec teams use Falco in their incident response workflows, we have aligned Falco's threat detection capabilities with the well-known MITRE ATT&CK framework.

Falco's rule alignment with the MITRE ATT&CK matrix enables detection of Tactics, Techniques, and Procedures (TTPs) employed by adversaries, aiding rapid identification and response to potential security incidents. Falco can help organizations proactively defend their systems, maintain compliance, and strengthen overall security posture.

Maintain regulatory compliance

Falco offers real-time runtime detection powered by eBPF, making it a good solution for organizations seeking to maintain regulatory compliance with frameworks such as PCI DSS, NIST, and others in cloud-native systems. Unlike traditional security tools that struggle with the ephemeral nature of these environments, Falco is purpose-built for cloud-native architectures and integrates with container orchestrators like Kubernetes.

Falco adapts to the dynamic nature of containers, ensuring continuous compliance. With a comprehensive library of predefined rules based on security best practices and compliance standards like PCI DSS and NIST, Falco covers a wide range of security events, including unauthorized access attempts, privilege escalation, data exfiltration attempts, and more. By leveraging Falco's robust capabilities, organizations can observe their cloud-native systems while meeting the stringent requirements of regulatory frameworks.

Falco FAQs

Yes. Kernel module and old eBPF All you need are the extracted kernel headers that are passed into the cmake make setup. Modern eBPF For newer kernels >= 5.8 Falco supports a modern_bpf eBPF driver. For modern_bpf you DON’T need kernel headers as BTF information and eBPF CORE is used. As a consequence modern_bpf will work for all distros and future kernel versions.

The most common cause of excessive notifications are noisy rules. Falco ships with a set of default rules, which can be disabled, either individually or by using tags, and default macros, some of them designed to be overridden, depending on the needs and the use case.

There’s also the possibility of configuring a minimum rule priority, used as a threshold to filter out rules with a lower priority (alerts are ignored), and a rate limiter. Take however into account that these options might reduce the visibility of potential threats.

First, make sure Falco is running, either as a service or as a container. Second, the event must be generated on the same host as where Falco is running, otherwise, Falco won’t see it since a different kernel will be serving that process.

Finally, make sure the rule you want to trigger is not too strict and the event is being filtered out. Start by having less parameters in the conditions and keep adding them until the rule is just noise enough. Be also aware that Falco tries to optimize using buffers, so the alert might take some seconds to be displayed.

Go to all FAQs

Was this page helpful?

Let us know! You feedback will help us to improve the content and to stay in touch with our users.

About: FAQs

Mon, 01 Jan 0001 00:00:00 +0000

FAQs

Runtime security is the process of providing real-time monitoring or observability capabilities for your host, containers, and applications while they're running. This allows you to detect a variety of threats, such as:

Privilege escalation attacks through exploiting security bugs.
The deployment of unauthorized workloads by an attacker.
Unauthorized access to secrets or other sensitive information.
The activation of malware that is hidden inside an application.

Falco is designed to detect these and other threats while your services and applications are running. When it detects unwanted behavior, Falco alerts you instantly so you’re informed (and can react!) right away, not after minutes or hours have passed.

You can think of Falco like a set of smart security cameras for your infrastructure: you place the sensors in key locations, they observe what’s going on, and they ping you if they detect harmful behavior.

With Falco, a set of rules define what bad behavior is. You can customize or extend these rules for your needs. The alerts generated by the set of Falco sensors can stay in the local machine, but it is a good practice to export them to a centralized collector.

Yes, Falco can run in almost every Linux kernel, whether it is a bare-metal server or a VM or microVM.

Please check the documentation to learn about kernel versions and more specific deployment restrictions. A list of available drivers can be found here.

No, Falco is deployed once per Linux OS (host OS or guest OS when a hypervisor is involved) - typically as privileged DaemonSet for a deployment in Kubernetes. Falco instruments the Linux kernel (either via a kernel module or eBPF probe) and can therefore monitor everything (e.g. system calls) within each container, because every container scheduled on the same node shares the same kernel.

In addition, Falco can hook into the container runtime and that way associate each kernel event with the exact container (e.g. container id, name, image repository, tags) as well as Kubernetes attributes such as namespace or pod name etc.

Please check the documentation to learn about limitations in kernel instrumentation options for some platforms such as GCP or AWS Fargate.

System calls are Falco’s default data source. To instrument the Linux kernel and collect these system calls, it needs a driver: either a Linux kernel module or an eBPF probe.

The Falco Project provides literally thousands of prebuilt drivers for the vast majority of the most common Linux distributions, with various kernel versions available for download. If a prebuilt driver for your distribution and kernel version is not yet available, it is also possible to build the driver locally. You can find a table listing all compatible kernels on that page.

Here are the system call event types and args supported by the Falco drivers.

This doesn’t make Falco cover all possible threats automatically. Without the proper rules in place, many of those events will be seen as regular behavior between the processes and the kernel.

No, the k8s set of fields k8s.ns.name and k8s.pod.* (i.e., k8s.pod.name, k8s.pod.id, k8s.pod.labels, and k8s.pod.label.*) are populated with data fetched from the container runtime.

Therefore, they can also be accessed without having the Kubernetes Metadata Enrichment functionality enabled (-k Falco option).

Options available to tune performance

Some syscalls are more high-volume than others, perform a cost-benefit analysis according to your organization's threat model and security posture. The list of syscalls that are activated is one of the most significant factors that drive CPU utilization. In addition, there are tricks to craft Falco rules more effectively.
Contact your organization's SREs and conduct performance tests in your environment early on in order to derive budgets and appropriate limits (CPU and memory used). We recommend to always run Falco in cgroups to also not starve the tool on the flip side.
Memory: Falco allocates a ring buffer for each CPU, the more CPUs you have the more memory is allocated. For high load servers you may even need to increase the size of each buffer to avoid kernel side syscall drops. In addition, Falco builds up process threads state over time and memory increases as a consequence, but at some point should plateau.

Didn't find your question? Ask us on Slack.

Was this page helpful?

Let us know! You feedback will help us to improve the content and to stay in touch with our users.

About: Mitre att&ck page

Mon, 01 Jan 0001 00:00:00 +0000

Mitre att&ck page

About: Why Falco?

Mon, 01 Jan 0001 00:00:00 +0000

Why Falco?

Highly Scalable

Falco is highly scalable, due to its containerized architecture and tight Kubernetes integration.

Falco runs as a Kubernetes daemon set, ensuring every node in the cluster is monitored by Falco.

Falco leverages Kubernetes to dynamically update its configuration as new pods are added or removed from the cluster.

Falco's integration with cloud-native technologies like Prometheus and Grafana provides users with the ability to visualize and analyze Falco alerts at scale.

Highly Performant

Falco is highly performant due to its low overhead, streaming event architecture, and the ability to leverage kernel-level instrumentation to observe system events.

Falco keeps its footprint small by using a minimal set of resources, including CPU, memory, and I/O, while monitoring system events.

Falco's event-driven architecture allows it to monitor only relevant events, reducing noise, decreasing latency, and dramatically reducing storage costs.

Falco uses eBPF or kernel modules observing system and application behavior and detecting a broad range of security issues.

Single Policy Language

Falco's policy language is all you need to know: reducing complexity and misconfigurations.

Collaboration over security and operations teams is eased by the use of a shared policy language.

Policy language extensibility means you can create, reuse, and consume others' rules.

A single policy language simplifies compliance and auditing.

Flexible Deployment Options

Customizable install lets you deploy to hosts, VMs, or Kubernetes, on or off-prem.

Falco was born cloud-native, so works well as a containerized app executing inside K8s clusters.

Falco installation plays nice with common cloud-native services such as Prometheus or Grafana.

Falco deploys by default using eBPF, providing performance, maintainability and simplified UX.

Customizable

Define your own custom rules to meet specific security requirements.

Create your own custom plugins to handle events from additional sources.

Configure alerts to trigger specific actions, such as executing custom scripts.

Define custom metadata to enrich Falco alerts with context specific to your needs.

Policy Language Benefits

Ensures Consistency and Reduces Complexity

Falco's rule language is used to define security policies for detecting and alerting on potential threats, and its use across the entire platform ensures a uniform approach to security monitoring. This means that all team members can understand the policies and alerts, regardless of their role or the context in which they are used.

Promotes Collaboration between Security & Ops teams

Since everyone is working with the same set of rules and policies, it becomes easier for these teams to share insights and work together to solve security issues. This can help to reduce the time it takes to identify and resolve security incidents.

Provides Flexibility & Extensibility

The language is designed to be easy to use, and it offers a wide range of operators and conditions that can be used to create customized rules for specific security scenarios. This allows teams to create policies that are tailored to their unique needs and requirements.

Simplifies Compliance & Auditing

Falco's rules language can also be used to alert on compliance violations, such as detecting unauthorized changes to files under PCI/DSS. As a result, it becomes easier to demonstrate compliance with regulations and standards. To better understand how Falco can be used for meeting regulatory compliance in cloud-native environments, check out this video.

Scalability Benefits

Compatibility with Container Orchestration Tools

At its core, Falco is a kernel event monitoring and detection agent. Falco can enhance these events by integrating metadata from the container runtime and Kubernetes. This tight integration with various container orchestration tools enables the expansion of Falco's detection capabilities and scope. It can, for example, detect and alert on new containers and workloads being deployed, ensuring that security visibility is comprehensive across your infrastructure. In addition, through Falco's native support for daemonset-like deployments, it can seamlessly integrate into your existing setup, whether you are using Kubernetes, Docker Swarm, or other container orchestration platforms.

Runs as a Daemonset

Like other workload objects, a DaemonSet manages groups of replicated Pods. However, DaemonSets attempt to adhere to a one-Pod-per-node model, either across the entire cluster or a subset of nodes. As you add nodes to a node pool, DaemonSets automatically add Pods to the new nodes as needed. This enables Falco to monitor all containers on all nodes, providing comprehensive security visibility across the entire cluster. To learn how Falco is used as a DaemonSet, check out our workshop.

Leverages the Kubernetes API

Falco leverages the Kubernetes API to monitor the state of pods and nodes in the cluster. It can detect anomalies and violations in real-time, and alert the user or take automated actions based on defined rules. As the Kubernetes cluster grows, Falco can use the Kubernetes API to dynamically adjust its monitoring capabilities, such as adding more sensors, without manual intervention. This ensures that the monitoring remains effective and efficient even as the cluster scales up or down.

Analyze Alerts at Scale

Falco integrates with Prometheus and Grafana to provide users with a scalable solution for visualizing and analyzing Falco alerts. This allows users to quickly identify and respond to potential security threats in their containerized environments. As your Kubernetes environment expands, so too does your cloud-native monitoring platform.

Performance Benefits

Event-driven Architecture

Falco's high performance is due to several factors, including its low overhead, event-driven architecture, and kernel-level instrumentation. The low overhead of Falco's design allows it to analyze events with minimal impact on system performance. The event-driven architecture enables Falco to quickly detect and alert, while kernel-level instrumentation ensures that it can process events in real-time, further enhancing its performance.

Uses a minimal set of resources

Falco is designed to use a minimal set of resources, such as CPU and memory, while still providing effective monitoring and detection capabilities. By using a minimal set of resources, Falco operates efficiently and does not impact the performance of the monitored applications, ensuring that the applications can continue to function smoothly without any degradation in performance.This makes Falco an ideal choice for monitoring Kubernetes clusters where resource utilization is critical and any performance degradation can have significant consequences.

Only monitor the relevant events

Falco only monitors relevant events by using filters and rules to define which events to monitor, such as file access or network connections. By filtering events, Falco can avoid processing unnecessary data, and concentrate only on security-related events. This reduces the amount of data to be processed and analyzed, which enables Falco to detect security threats more effectively and efficiently.

Kernel-level instrumentation to observe system events

Falco uses kernel instrumentation to observe system events by monitoring system calls and other kernel-level signals. The Falco kernel components are designed to be fast and non intrusive, as they do not alter the system's behavior. By using this approach, Falco can collect rich information of what applications are doing nearly in real-time while minimizing overhead and preventing interference with regular workload behavior.

Flexible Deployment Benefits

Tailor the install process to your specific needs

Users can select which components to install. You can configure specific settings for your needs. And you can even choose the deployment environment, whether it be in Kubernetes, on a bare metal VM, an IoT device or Edge computing. More documentation on install options can be seen here.

Deploy in a “Cloud-Native” way

By installing Falco as a containerized pod within Kubernetes, it becomes easier to scale, manage, and deploy multiple instances of Falco. Containerization provides a lightweight and portable way to package and deploy applications, allowing for faster and more consistent deployments. Kubernetes is designed for enabling automatic scaling, self-healing, and centralized management of Falco instances. This can lead to improved operational efficiency and reduced overhead for security teams.

Deploy Additional Components

The benefit of Falco installation playing nice with common cloud-native services such as Prometheus or Grafana is that it enables seamless integration with existing monitoring and observability toolchains. This integration can help organizations streamline their security workflows, enabling faster detection and alerting. It can also provide a more holistic view of the security landscape, allowing security teams to identify and mitigate potential threats more effectively.

Falco uses eBPF by default

Deploying Falco using eBPF reduces complexity by removing the need for additional kernel modules or user-space agents. This simplifies deployment and maintenance, making it easier to integrate Falco into existing environments. Deploying Falco using eBPF provides a simplified user experience. With eBPF, users can deploy Falco with a single command, eliminating the need for additional configuration or setup.

Customization Benefits

Meet specific security requirements

Defining custom Falco rules can benefit security by allowing organizations to create rules tailored to specific security requirements. Custom rules can detect behaviors unique to an organization's environment, providing more targeted security alerts. They can also help organizations comply with regulatory requirements or internal security policies.

Build your own Falco Plugins

Creating custom Falco plugins can benefit security by allowing organizations to extend Falco's functionality to handle events from additional sources beyond system calls. Custom plugins can integrate with other tools or data sources, providing a more comprehensive view of the security landscape. They can also automate workflows or remediation actions based on Falco alerts.

Trigger your own custom actions

Configuring custom Falco alerts can benefit security by allowing organizations to automate incident response workflows. Custom alerts can trigger specific actions, such as executing custom scripts or sending notifications, enabling faster response times and reducing the impact of security incidents. They can also help organizations comply with internal processes or regulatory requirements.

Enrich alerts with custom metadata context

Defining custom metadata can benefit security by enriching Falco alerts with context specific to an organization's needs. Custom metadata can provide additional information about the alert, such as user information or application details, enabling faster investigation and response times. It can also help organizations comply with regulatory requirements or internal security policies.

Falco FAQs

Please check the documentation to learn about limitations in kernel instrumentation options for some platforms such as GCP or AWS Fargate.

System calls are Falco’s default data source. To instrument the Linux kernel and collect these system calls, it needs a driver: either a Linux kernel module or an eBPF probe.

Go to all FAQs

Was this page helpful?

Let us know! You feedback will help us to improve the content and to stay in touch with our users.

Falco – What is Falco?

About: Incepto Medical Case Study

Protect shared clusters for medical imaging

A secure, multi-tenant medical imaging service

GPU-enabled Kubernetes deployments

Empowering custom workloads securely

Choosing a security solution for Kubernetes

About: Trendyol Case Study

Threat hunting at scale: auditing hundreds of clusters with Falco

Background

Journey to Falco

Learn about the Technology

The Architecture

Results

About: R6 Security Case Study

R6 Security Leverages Falco to Enhance Their Moving Threat Detection Platform, Phoenix

Building on Falco

Conclusion

About: Falco Ecosystem

Falco ecosystem

Helm

Falco FAQs

Does Falco cover all system calls? Is it possible that Falco doesn’t detect a security problem?

Do I need to enable the Kubernetes Metadata Enrichment (-k flag) in order to log Kubernetes namespace and pod name?

What is the performance overhead or resource utilization of Falco?

Was this page helpful?

Falco use cases

Frequently Asked Questions

About: Falco use cases

What you can do with Falco today

Align threat detections with the MITRE ATT&CK Framework

Maintain regulatory compliance

Falco FAQs

Can I build Falco's kernel driver for custom kernels?

I get too many notifications from Falco. What can I do?

Falco doesn’t trigger any alert. What am I doing wrong?

Was this page helpful?

Why Falco?

Falco Ecosystem

About: FAQs

FAQs

What is runtime security and how does Falco help?

How do I explain to someone what Falco does in a nutshell?

Can I run Falco in VMs?

Does Falco need to run in every container or pod in Kubernetes?

Why do I need a driver to use Falco?

Which Linux Kernels are compatible with Falco?

Can I build Falco's kernel driver for custom kernels?

I get too many notifications from Falco. What can I do?

Falco doesn’t trigger any alert. What am I doing wrong?

Does Falco cover all system calls? Is it possible that Falco doesn’t detect a security problem?

Do I need to enable the Kubernetes Metadata Enrichment (-k flag) in order to log Kubernetes namespace and pod name?

What is the performance overhead or resource utilization of Falco?

Was this page helpful?

Falco ecosystem

Documentation

About: Mitre att&ck page

Mitre att&ck page

Falco use cases

Ecosystem

About: Why Falco?

Why Falco?

Highly Scalable

Highly Performant

Single Policy Language

Flexible Deployment Options

Customizable

Policy Language Benefits

Ensures Consistency and Reduces Complexity

Promotes Collaboration between Security & Ops teams

Provides Flexibility & Extensibility

Simplifies Compliance & Auditing

Scalability Benefits

Compatibility with Container Orchestration Tools

Runs as a Daemonset

Leverages the Kubernetes API

Analyze Alerts at Scale

Performance Benefits

Event-driven Architecture

Uses a minimal set of resources