Threat Detection Policies
Understand Threat Detection Policies
A Sysdig Secure policy is a combination of rules about activities an enterprise wants to detect in an environment, the actions that should be taken if the policy rule is breached, and– potentially– the notifications that should be sent. A number of policies are delivered out-of-the-box and can be used as-is, duplicated, or edited as needed. You can also create policies from scratch, using either predefined rules or creating custom rules.
Managed Policies, Managed Rulesets, and Custom
As of July, 2022, threat detection policies have three “flavors.”
Default/Managed Policies These are the default policies provided and managed by Sysdig. The Sysdig Threat Research team may update them at any time.
Default policies exist across all accounts, the names cannot be changed, and they cannot be deleted.
They are loaded with a pre-defined enabled/disabled status, based on most common usage, but you can
enable
ordisable
them at will.Only the
Scope
andAction
(such as notification channel) can be edited.Note: Earlier versions of Sysdig Secure had “default” policies that were not managed by Sysdig and used different naming. See the release notes for information about that transition.
If you want to edit other attributes, you can
Duplicate
policies to create:Managed Ruleset Policies:
Name
,Description
, andSeverity
can also be editedAs with the default Managed policies, Managed Ruleset policies may be updated by the Sysdig Threat Research team.
Use case example: You need different scopes or actions (such as notification channels) for the same set of rules within a Managed Policy.
If you want to change the rules in a policy, then you need:
Custom Policies: These can be created three ways:
- Converting a Default policy to Custom
- Converting a Managed Ruleset policy to Custom
- Creating a policy from scratch
- (Any policies from before July, 2022 are auto-converted to Custom policies and continue to work as they did before.)
Custom policies cannot be updated by the Sysdig Threat Research team. If/when Sysdig creates new rules, the user must apply them to custom policies themselves.
Manage Daily Updates (On-Prem Only)
For on-premises deployments (v 6.1.1+), the managed policies and rules are updated daily at midnight UTC. The schedule is handled automatically by a cron job service sysdigcloud-falco-rules-deployer
.
To change the frequency:
Edit Values.sysdig.secure.rulesDeployer.schedule
to your preferred settings.
To disable:
Edit Values.sysdig.secure.rulesDeployer.enabled
to suspend the cron job.
Review the Runtime Policies List
Select Policies > Runtime Policies
see the default policies you loaded
into Sysdig Secure, as well as any custom policies you have created.
From this overview, you can:
See at a Glance
- Severity Level Default policies are assigned High, Medium, Low, or Info level severity, which can be edited.
- Enabled/Not Enabled Viewed by toggle position.
- Policy Summary Includes
Update
status, the number ofRules
, assignedActions
to take on affected containers (Stop | Pause | Notify
), andCapture
details, if any. - Policy Status
Default
policies are “managed policies,”Ruleset
are managed ruleset policies, andCustom
policies may be user-designed from scratch or converted from default policies with changes to their rules. - Added/Updated Badges indicate managed policies with rules that have been added or updated in the past 7 days.
Take Action
From this panel you can also:
Drill down to policy details (and potentially Edit them)
Search and filter policies by name, policy name, severity level, policy type, or whether captures are enabled
Enable/Disable a policy using the toggle
Create a new policy using the
+Add Policy
button
Review Policy Types
Additional types are added periodically.
Runtime Policies
Workload Policy
Powered by the Falco engine, these provide a way to filter system calls using flexible condition expressions. See Using Falco within Sysdig Secure for more context.
List-Matching Policy
Policies using a simple matching or not-matching for containers, syscalls, processes, etc. See Understanding List Matching Rules for more context.
Drift Policy
Policy with a single rule that provides default drift detection and prevention.
See also: Understanding DriftControl and Additional Parameters for Drift Policy Type.
Machine Learning
Policy leveraging Machine Learning to provide advanced detection capabilities.
See also: Understanding Machine Learning and Additional Parameters for Machine Learning Policy Type.
Log-Detection Policies
Kubernetes Audit Policy
Powered by the falco engine, provide a way to filter Kuernetes audit logs using flexible condition expressions. See also Kubernetes Audit Logging.
AWS CloudTrail Policy
Provides a way to filter AWS CloudTrail events using Falco-compatible condition expressions. You need to have Sysdig Secure for cloud installed to transmit your AWS CloudTrail events.
GCP Audit Log Policy
Provides a way to filter GCP audit logs using Falco-compatible condition expressions.
Azure Platform Log Policy
Provides a way to filter Azure platform logs using Falco-compatible condition expressions.
Scopes and Actions for Policy Types
The scopes and actions available differ by type:
Source | Scope Options | Action Options | |
---|---|---|---|
RUNTIME | |||
Workload | Sys call | Custom Hosts only Container only | Stop/ pause/ kill Capture Notification channel |
List-Matching | Sys call | Custom Hosts only Container only | Stop/ pause/ kill Capture Notification channel |
Drift | Custom only | Prevent Notification channel | |
LOG DETECTION | |||
Kubernetes | k8s_audit | kubernetes.cluster.name kubernetes.namespace.name | Notification channel |
AWS Cloud | cloudtrail | aws.accountId aws.region | Notification channel |
GCP | gcp.projectid gcp.location | Notification channel | |
Azure | azure.subscriptionId azure.tenantId azure.location azure.resourceGroup | Notification channel |
Understanding DriftControl
Drift is the change in an environment that differs from the expected state checked into a version control system, e.g. software that was introduced, updated, or upgraded into a live environment.
Sysdig’s DriftControl feature uses various detection techniques, such as watching the system for when new executables are downloaded, updated, or modified inside a container which was not part of the container image before the container started up.
With the default agent configuration, a Drift policy/rule will stop such a detected process after it has begun.
If it is necessary to ensure that a particular task should be blocked from ever starting, you can enable the following configuration in the agent config file:
drift_killer:
enabled: true
Or if using Helm, add the --set agent.sysdig.settings.drift_killer.enabled=true
flag.
For agent 12.14.x release, the drift_killer
flag must be set for drift detection to send events at all.
Understanding Machine Learning Policies
Prerequisite: Machine Learning policies require enabling the Profiling Sysdig Labs toggle to activate the underling fingerprint collection mechanism.
Machine Learning collects low-level activities from your infrastructure, aggregating them over time and applying algorithms.
With machine learning policies you can configure the detections you want to use and their thresholds.
Machine Learning Detection algorithms work by estimating the probability that those activities are related the detection subjects, i.e. miners. Sysdig Machine Learning detections don’t rely on mere program names or executable checksums matching. Instead, they are based on actual runtime behaviors, collected in the form of fingerprints by the Profiling feature.
Understanding Threat Detection Rules
Rules are the fundamental building blocks you will use to compose your security policies. A rule is any type of activity that 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.
Understanding the Rules Library
The Rules Library includes all created rules which can be referenced in policies. Out of the box, it provides a comprehensive runtime security library with container-specific rules (and predefined policies) developed by Sysdig’s threat-research teams, Falco’s open-source community rules, and international security benchmarks such as CIS or MITRE ATT&CK.
Audit-Friendly Features
In the Rules Library interface, you can see at a glance:
Published By:
Last Updated
for enhanced traceability and audit.
- Default rules appear in the UI as Published By: Sysdig
- User-defined rules appear as Published By: Secure UI
Tags
Rules are categorized by tags, so you can group them by functionality, security standard, target, or whatever schema makes sense for your organization.
Various tags are predefined and can help you organize rules into logical groups when creating or editing policies.
Search
Use the search boxes at the top to search by rule name or by tag.
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.yaml
file 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 the 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.
Existing Rule |
![]() |
Create a Rule |
Falco rules with the source k8s_audit
need Kubernetes Audit
logging enabled for
conditions to be met.
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.
(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
meansdo nothing
Deny
meansmatch 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/killing
the
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
The syscall
rule type is almost never deployed in user-created
policies; the definitions below are for information only.
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 noimage/tag/digest
provided.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
There are optional tools to help automate the creation of policies. See also: Network Security Policy Tool to author and fine-tune Kubernetes network policies
Feedback
Was this page helpful?
Glad to hear it! Please tell us how we can improve.
Sorry to hear that. Please tell us how we can improve.