Threat Detection Policies

Threat Detection Runtime Policies provide granular control over runtime behavior by defining rules and configurations. Policies specify where to apply rules and how to respond to security violations. Use policies to monitor clusters, hosts, or user-defined tags and take actions. For example, alert Slack channels, trigger webhooks, or prevent malware from executing.

Review the Runtime Policies List

To review the Runtimes Policies list:

1. Log in to Sysdig Secure.

2. Select Policies > Threat Detection | Runtime Policies.

Here you can see the default policies loaded into Sysdig Secure, as well as any custom policies you have created.

See at a Glance

• Collapse or expand policy groups: Policies are grouped by policy type.
• Policies are assigned High, Medium, Low, or Info level severity, which can be edited.
• Enabled/Disabled: Viewed by toggle position.
• Managed Type: Filter by policy management type; Managed Policy, Managed Ruleset or Custom Policy. See Manage Threat Detection Policies for details.
• Select policy type: Filter by policy type, such as Workload or List Matching.
• Policy Summary: Includes Update status, the number of Rules, assigned Actions to take on affected containers (Stop | Pause | Notify), and Capture details, if any.
• Policy Status: The Default policies are managed policies, Ruleset are managed ruleset policies, and Custom policies may be user-designed from scratch or converted from default policies with changes to their rules.
• Last Updated indicates when a policy was last updated.

Take Action

From this page, you can also:

• Select a policy to open the details panel, where you can review policy details, and potentially Edit them.

• Search and Filter policies by name, severity level, type, or whether captures are enabled.

• Enable or Disable a policy using the toggle.

• Create a new policy by selecting +Add Policy.

View Recent Changes

When rules are changed, either by the Sysdig Threat Detection team or by users, an Updated badge is displayed next to relevant policies for seven days.

There are several ways to view recent changes to a rule.

From Runtime Policies

1. Go to Polices > Threat Detection | Runtime Policies and scroll down to find any Updated badges.

2. Select the policy to open the detail panel and scroll to find the updated rule.

   

3. Select the +/- rule diff icon to compare the two versions of the rule.

   

From the Policy Edit Page

1. Go to Policies > Threat Detection | Runtime Policies and select a policy.

2. Click the Edit (pencil) icon to open the Policy Edit page.

3. Select a rule from the page.

4. If the rule has been updated, you can use the +/- icon next to the rule.

   
   
   

   If the change has happened in the past seven days, there will also be an icon available next to the Updated badge on the main Policy Edit page.

See View Recent Changes to a Rule from the Rules Library.

Report Policy Actions in Kubernetes Events

Some Threat Detection Runtime policies, such as Workload policies, allow you to take actions on containers. When you perform a container Stop, Pause, or Kill action, Sysdig includes a message in Kubernetes events to explain that Sysdig acted on the container due to the given rule. You will see this information when you kubectl events in your terminal, without requiring login to the Sysdig Secure UI.

Enablement

This feature is included with agent v.12.18+. If you have deployed agent 12.18+ using Helm, the feature and its associated permissions are enabled by default. If you deploy agents manually, you must set Kubernetes role permissions. See Agent Configuration Library for details.

Understand Threat Detection Rules

Rules are the fundamental building blocks you will use to compose your security policies. Rules discover types of activity an enterprise would want to detect in its environment.

Rules can be expressed in two formats:

• Falco rules syntax, which can be complex and layered. All the default rules delivered by Sysdig are Falco rules, and users can also create their own Falco rules.

• List-matching rules syntax, which is simply a list against which a match/not match condition is applied. All these rules are user-defined. They are grouped into five types: Container Image, File System, Network, Process, and Syscall.

Using Falco within Sysdig Secure

What is Falco

Falco is an open-source intrusion detection and activity monitoring project. Designed by Sysdig, the project has been donated to the Cloud Native Computing Foundation, where it continues to be developed and enhanced by the community. Sysdig Secure incorporates the Falco Rules Engine as part of its Policy and Compliance modules.

Within the context of Sysdig Secure, most users will interact with Falco primarily through writing or customizing the rules deployed in the policies for their environment.

Falco rules consist of a condition under which an alert should be generated and an output string to send with the alert.

Conditions

• Falco rules use the Sysdig filtering syntax.

  (Note that much of the rest of the Falco documentation describes installing and using it as a free-standing tool, which is not applicable to most Sysdig Secure users.)

• Rule conditions are typically made up of macros and lists.

  • Macros are simply rule condition snippets that can be re-used inside rules and other macros, providing a way to factor out and name common patterns.

  • Lists are (surprise!) lists of items that can be included in rules, macros, or other lists. Unlike rules/macros, they can not be parsed as Sysdig filtering expressions.

Behind the scenes, the falco_rules.yamlfile contains the raw code for all the Falco rules in the environment, including Falco macros and lists.

Anatomy of a Falco Rule

All Falco rules include the following base parameters:

• rule name: default or user-assigned

• condition: the command-line collection of fields and arguments used to create the rule

• output

• source

• description

• tags: for searching and sorting

• priority

Select a rule from Rules > Rules Library to see or edit its underlying structure. The same structure applies when creating a new Falco rule and adding it to the library.

About Falco Macros

Many of the Falco rules in the Rules Library contain Falco macros in their condition code.

You can browse the Falco Macros list, examine a macro’s underlying code, or create your own macro. The default Falco rule set defines a number of macros that make it easier to start writing rules. These macros provide shortcuts for a number of common scenarios and can be used in any user-defined rule sets.

About Falco Lists

Default Falco lists are added to improve the user experience around writing custom rules for the environment.

For example, the list allow.inbound.source.domains can be customized and easily referenced within any rule.

About Rule Exceptions

To reduce false positives, Sysdig uses Falco exceptions in many of the default rules, including adding exceptions to community rules. Rule exceptions are used in the auto-tuning and rules exception features as part of Runtime Policy Tuning.

To understand how exceptions are managed: there are the exception definitions, used to define a set of fields and comparisons (comps) that the values (which are optional) can use to create those exceptions

Available Fields

Sysdig SaaS and the Sysdig Agent enrich events with details that are not available to Falco. The most common classes of fields available are:

Workload/syscall Rules

• proc
• user
• group
• container
  • See below for container fields that are not available from Falco
• fd To understand each field in those classes, you can find them here.

The Kubernetes fields are not available in the Falco rules. This is due to performance improvements that could affect the Kubernetes API server when collecting those values from Falco. In the event details you may see this information enriched from other parts of Sysdig, with values such as kubernetes.deployment.name.

Kubernetes Audit/k8s_audit Rules

All ka fields are available. You can find a comprehensive list here.

However as noted above, Sysdig enriches some additional metadata in the event details. An event may have the field kubernetes.cluster.name, however that is not available in the rule or rule exceptions.

Common fields that are not available

• agent.tag.*
• kubernetes.*
• host.*
• container.label.*
• container.name.repo instead use
  • container.image.repository which outputs sysdig/agent
  • container.image which outputs sysdig/agent:latest

(On-Prem Only) Upgrading Falco Rules with the Rules Installer

Sysdig Secure SaaS is always using the most up-to-date Falco rules set.

Sysdig Secure On-Prem accounts should upgrade their Falco rules set regularly.

This can be achieved through our Rules Installer.

Understanding List-Matching Rules

List-matching rules (formerly known as “fast” rules) are used for matching against lists of items (when matchItems=true) or matching everything other than lists of items (when matchItems=false). They provide for simple detections of processes, network connections, and other operations. For example:

• If this process is detected, trigger an action when this rule is in a policy (such as send notification).

  Or

• If a network connection on x port is detected, trigger an action when this rule is in a policy (such as send notification)

Unlike Falco rules, the list-matching rule types do not permit complex rule combinations, such as “If a connection on x port from y IP address is detected…”

The five list-matching Rule Types are described below.

Container Rules

These rules are used to notify if a specific image name is running in an environment. The rule is evaluated when the container is started. The items in the list are image pattern names, which have the syntax <host.name>:<port>/<name>/<name2>:<tag>@<digest>.

Only <name2>is required; everything else is optional and inferred building on the name.

See also: How Matching Works: Container Example and Create a List-Matching Rule: Container Type Example.

File System Rules

These rules are used to notify if there is write activity to a specific directory/file. The rule is evaluated when a file is opened. The items in the list are path prefixes.

For example: /one/two/three would match a path /one/two/three, /one/two/three/four, but not /one/two/three-four.

Network Rules

These rules are used to:

• Detect attempts to listen for inbound connections on ports on a specific list

• Generally identify any inbound or outbound connection attempts

Note that the current Sysdig UI talks about “Allowing” or “Denying” connections with network rules, but this can introduce some confusion.

For both Inbound and Outbound connections:

• Allow means do nothing

• Deny means match any attempt to make an inbound or outbound a connection

You would still need to add the rule to a policy and attach actions to respond to a connection attempt by stopping/pausing/killingthe container where the connection occurred. See also: Understanding How Policy Actions Are Triggered.

Process Rules

These rules are used to detect if a specific process, such as SSH, is running in a particular area of the environment.

The rule is evaluated when a process is launched. The items in the list are process names, subject to the 16-character limit enforced by the Linux kernel. (See also: Process Name Length information.)

Syscall Rules

These rules are used (internally) to:

• Notify if a specific syscall happens in a list

• Notify if a syscall outside this trusted list happens in the environment

The rule is evaluated on syscalls that create inbound (accept, recvfrom, recvmsg, listen) and/or outbound (connect, sendto, sendmsg) connections. The items in the list are port numbers.

How Matching Works: Container Example

A Container Image consists of the following components:

<registry host>:<registry port>/<image>:<tag>@<digest>.

Note that <image> might consist of multiple path components such as <project>/<image> or <project>/<subproject>/<image>.

Complete example: docker.io:1234/sysdig/agent:1.0@sha256:da39a3ee5e6b4b0d3255bfef95601890afd80709

Where:

<registry host> = docker.io

<registry port> = 1234

<image> = sysdig/agent

<tag> = 1.0

<digest> = sha256:da39a3ee5e6b4b0d3255bfef95601890afd80709

Each item in the containers list is first broken into the above components, using the following rules:

• If the string ends in /, it is interpreted as a registry host and optional registry port, with no image/tag/digestprovided.

• Otherwise, it is interpreted as an image. The registry host and port may precede the image and are optional, and the tag and digest may follow the image, and are optional.

Once the item has been broken into components, they are considered a prefix match against candidate image names.

Examples:

docker.io:1234/sysdig/agent:1.0 @sha256:da39a3ee5e6b4b0d3255bfef95601890afd80709: must match all components exactly

docker.io:1234/sysdig/agent:1.0:must match the registry host, port, image, and tag, with any digest

docker.io:1234/sysdig/agent:must match the registry host, port, and image, with any tag or digest

sysdig/agent:must match the image, with any tag or digest. Would not match an image docker.io:1234/sysdig/agent, as the image provides additional information not in the match expression.

docker.io:1234/: matches all images for that registry host and port

docker.io/: matches all images for that registry host

Getting Started

• Manage Policies

• Manage Rules