Lesson 03 — Falco

Learning Objectives

By the end of this lesson, you will be able to:

Understand what Falco is
Learn why runtime security is important
Understand how Falco detects threats
Explore Falco architecture
Learn Falco rules and policies
Integrate Falco with Amazon EKS
Apply enterprise runtime security best practices

Why This Matters

Traditional security controls focus on preventing vulnerabilities before workloads reach production.

These controls include:

Secure Dockerfiles
Vulnerability Scanning
Image Signing
Admission Controllers
RBAC
Network Policies

However, once a container is running, new threats emerge.

Examples include:

Reverse shells
Cryptocurrency miners
Privilege escalation
File tampering
Container escapes
Suspicious process execution

Runtime security solutions like Falco continuously monitor workloads and alert security teams when suspicious activity occurs.

What is Falco?

Falco is an open-source runtime security platform originally created by Sysdig and now maintained by the Cloud Native Computing Foundation (CNCF).

Falco continuously monitors:

Containers
Kubernetes
Linux hosts
System calls
Kubernetes Audit Events
Cloud-native workloads

It detects suspicious behaviour using predefined and custom security rules.

Runtime Security

Runtime security focuses on protecting workloads after deployment.

Build

↓

Deploy

↓

Running Container

↓

Runtime Monitoring

↓

Threat Detection

↓

Alert

↓

Incident Response

Unlike vulnerability scanners, runtime security observes what workloads actually do.

Why Runtime Detection Matters

Even fully patched applications can be compromised.

Examples include:

Stolen credentials
Zero-day exploits
Insider attacks
Supply chain attacks
Misconfigured applications

Runtime monitoring detects these attacks while they are occurring.

How Falco Works

Falco observes system activity by monitoring Linux system calls.

Running Container

↓

Linux Kernel

↓

System Calls

↓

Falco Engine

↓

Rule Evaluation

↓

Alert

Every system call is evaluated against security rules.

What are System Calls?

Applications communicate with the Linux kernel using system calls (syscalls).

Examples include:

open()
execve()
connect()
chmod()
mount()
ptrace()

These operations provide valuable insight into application behaviour.

Falco Monitoring Sources

Falco can monitor:

Source	Example
Linux System Calls	File access, process execution
Kubernetes Audit Events	API requests
Container Runtime	Container lifecycle
Kubernetes Metadata	Namespaces, Pods, Labels
Process Activity	Shell execution
Network Connections	Outbound communication

This provides visibility across both Kubernetes and the operating system.

Falco Detection Workflow

Application

↓

System Call

↓

Falco

↓

Rule Match

↓

Security Alert

↓

SOC Investigation

Only activities matching defined rules generate alerts.

Example Threat Detection

Suppose an attacker gains access to a running container.

Attacker

↓

kubectl exec

↓

Shell Started

↓

Falco Rule Triggered

↓

Alert Generated

Falco immediately identifies that an interactive shell has been opened inside a container.

Common Falco Detection Rules

Falco includes hundreds of built-in rules.

Examples include:

Terminal shell in a container
Privileged container execution
Container escape attempts
Sensitive file access
Unexpected process execution
Modification of system binaries
Kubernetes Secret access
Unexpected outbound connections
Suspicious package installation
Privilege escalation attempts

Organizations can also create custom rules.

Example Rule

A simplified rule might look like:

Condition

↓

Container Started

AND

Shell Executed

↓

Alert

Falco evaluates every relevant event against its rule set.

Falco Architecture

Containers

↓

Linux Kernel

↓

Falco

↓

Rule Engine

↓

Alert

↓

Amazon CloudWatch

↓

AWS Security Hub

↓

Enterprise SIEM

↓

SOC Team

This architecture enables real-time detection and centralized security monitoring.

Falco on Amazon EKS

Falco is typically deployed as a DaemonSet.

Amazon EKS Cluster

├── Node 1

│     └── Falco

├── Node 2

│     └── Falco

├── Node 3

│     └── Falco

└── Node N

      └── Falco

Running one Falco instance per node ensures complete visibility across the cluster.

Alert Destinations

Falco supports multiple alert outputs.

Examples include:

Amazon CloudWatch Logs
AWS Security Hub
Slack
Microsoft Teams
Email
Splunk
Elastic SIEM
IBM QRadar
Microsoft Sentinel
Webhooks

This allows organizations to integrate Falco into existing SOC workflows.

Falco and Kubernetes Metadata

Falco enriches alerts with Kubernetes context.

Example:

Namespace

↓

Pod

↓

Container

↓

Image

↓

Node

↓

Process

↓

Alert

This additional context makes investigations much faster.

Enterprise Runtime Security Architecture

Amazon EKS

↓

Containers

↓

Falco DaemonSet

↓

Amazon CloudWatch Logs

↓

Amazon OpenSearch

↓

AWS Security Hub

↓

Enterprise SIEM

↓

Security Operations Centre (SOC)

Runtime events are correlated with other security telemetry to provide complete visibility.

Enterprise Example

A multinational retail company hosts customer-facing applications on Amazon EKS.

An attacker exploits a vulnerable web application and successfully gains shell access to a container.

Within seconds:

Falco detects an interactive shell.
A high-severity alert is sent to Amazon CloudWatch.
AWS Security Hub creates a security finding.
The SIEM correlates the event with unusual outbound network traffic.
The SOC isolates the affected Pod.
The compromised container is replaced automatically.

Because runtime monitoring was enabled, the attack is detected before it spreads to other workloads.

Common Runtime Threats

Falco helps detect:

Interactive shell sessions
Reverse shells
Cryptocurrency miners
Container escapes
Privilege escalation
Unauthorized file modification
Secret access
Suspicious binaries
Unexpected network activity
Kubernetes API abuse

These threats often bypass traditional vulnerability scanning.

Enterprise Monitoring

Security teams should monitor:

Interactive shells
Privileged containers
Failed security policies
Process execution
Network connections
File system changes
Package installations
Sensitive file access
Authentication events
Kubernetes audit events

Continuous monitoring enables rapid threat detection.

Enterprise Implementation Strategy

A recommended rollout:

Step 1

↓

Deploy Falco DaemonSet

↓

Step 2

↓

Enable Default Rules

↓

Step 3

↓

Create Custom Rules

↓

Step 4

↓

Forward Alerts to CloudWatch

↓

Step 5

↓

Integrate AWS Security Hub

↓

Step 6

↓

Connect Enterprise SIEM

↓

Step 7

↓

Tune Detection Rules

↓

Step 8

↓

Perform Continuous Monitoring

Organizations should begin with default rules and gradually introduce organization-specific detections.

Falco vs Vulnerability Scanning

Vulnerability Scanning	Falco Runtime Detection
Before deployment	After deployment
Detects known CVEs	Detects suspicious behaviour
Analyses container images	Monitors running workloads
Preventive security	Detective security
Build-time control	Runtime control

Enterprise Kubernetes security requires both preventive and detective controls.

Best Practices

As a Kubernetes Security Engineer:

Deploy Falco on every production Kubernetes node.
Enable runtime monitoring for all workloads.
Regularly update Falco rules.
Create organization-specific custom detection rules.
Integrate alerts with Amazon CloudWatch and AWS Security Hub.
Forward alerts to the enterprise SIEM.
Continuously tune rules to reduce false positives.
Monitor privileged containers and shell execution.
Correlate Falco alerts with Kubernetes Audit Logs.
Include Falco in incident response playbooks.

Falco provides one of the most effective runtime detection capabilities available for Kubernetes environments.

Real-World Scenario

A global healthcare provider runs sensitive patient applications on Amazon EKS.

A compromised application attempts to:

Spawn a shell
Download a malicious binary
Modify system files

Falco immediately detects:

Shell execution inside the container
File modification attempts
Execution of an unexpected process

Security teams receive alerts through AWS Security Hub and their enterprise SIEM.

The affected Pod is quarantined, forensic evidence is collected and the compromised workload is replaced automatically.

Because Falco detected abnormal runtime behaviour, the incident is contained before patient data is affected.

Key Takeaways

After completing this lesson, you should understand:

What Falco is
Why runtime security is important
How Falco monitors Linux system calls
Falco architecture
Built-in and custom detection rules
Amazon EKS integration
Runtime monitoring workflows
Enterprise deployment best practices

Falco is a leading runtime security solution for Kubernetes. By continuously monitoring containers, Linux system calls and Kubernetes events, it enables organizations to detect attacks that occur after deployment. Combined with audit logging, vulnerability scanning and SIEM integration, Falco provides a critical layer of defence for enterprise Amazon EKS environments.

Knowledge Check

Question 1

What is the primary purpose of Falco?

A. Build container images
B. Detect suspicious runtime behaviour in Kubernetes and Linux environments
C. Replace Kubernetes RBAC
D. Schedule Pods

Answer: B

Question 2

What does Falco primarily monitor?

A. DNS records
B. Linux system calls and Kubernetes events
C. Amazon S3 buckets
D. EC2 Auto Scaling Groups

Answer: B

Question 3

How is Falco commonly deployed in Amazon EKS?

A. As a Deployment with one replica
B. As a DaemonSet running on every worker node
C. As an Ingress Controller
D. As a StatefulSet

Answer: B

Question 4

Which of the following is an example of activity Falco can detect?

A. Interactive shell inside a running container
B. Increasing CPU limits
C. Creating a Kubernetes Namespace
D. Installing Docker Desktop

Answer: A

Question 5

Which combination represents enterprise best practice?

A. Deploy Falco as a DaemonSet, update detection rules regularly, integrate alerts with Amazon CloudWatch, AWS Security Hub and an enterprise SIEM, and continuously tune rules to reduce false positives.
B. Enable Falco only during penetration tests.
C. Deploy Falco on only one worker node.
D. Ignore runtime alerts if vulnerability scanning has already been performed.

Answer: A

What’s Next?

In the next lesson, you will learn about Prometheus, exploring how Kubernetes metrics are collected, how Prometheus monitors cluster health, and how enterprise organizations use metrics for observability, alerting and proactive security monitoring in Amazon EKS.

➡️ Next Lesson: Lesson 04 — Prometheus