This the multi-page printable view of this section. Click here to print.

Return to the regular view of this page.

  • 1:
    • 2:
      • 3:
        • 4:
          • 5:
            • 6:
              • 6.1:
              • 7:
                • 8:

                  Policies

                  Sysdig Secure deploys different types of policies. Those described in this module include:

                  Vulnerability Management Policies and Rules for scanning pipeline and runtime images for vulnerabilities (only available after April 20, 2022)

                  Threat Detection Policies and Rules for all types of security threats such as disallowed actions, excessive permissions, suspicious changes, etc.

                  There are also variety of optional tools to help automate the creation of policies, such as:

                  1 -

                  CSPM Policies (Preview)

                  Overview

                  CSPM Policies allow you to:

                  • See what is being evaluated by the Actionable Compliance feature in the context of compliance standards (CIS, NIST, etc.)
                  • Review the policy structure and the controls connected to it
                  • Enable/disable controls
                  • Filter controls by enablement status, violation severity, name, and control type

                  The features are under development and will soon include the ability to create custom CSPM policies as well.

                  Prerequisites

                  This feature requires the Actionable Compliance component, also currently in preview state.

                  If necessary, review:

                  Usage

                  1. Select Policies > Actionable Compliance | CSPM Policies.

                  2. Review the CSMP Policy list. The included policies are listed alphabetically.

                    • Policy Name/Description: The full policy name and description, in accordance with naming used by, e.g., the Center for Internet Security (CIS). Click the arrow to link directly to the relevant standards website.

                    • Version: This column lists the version of the standard published. Not to be confused with the version, e.g., of Kubernetes, listed in the policy name.

                    • Date Published: Date the policy was published or activated (for custom policies).

                    • Author: Sysdig for default policies.

                  3. Click a row to open the individual policy page.

                  Select a policy from the CSPM Policies list to review requirements and controls, enable/disable controls, and filter/search.

                  • Requirement Groups and Requirements: Open the rows in the left pane to view requirement groups and the nested requirements to which the controls are linked.

                    Hover to get the full description text.

                  • Enable/Disable: Toggle to enable/disable an individual control within a policy. The control will be enabled/disabled for ONLY the targeted policy.

                  • Filter: See below.

                  Filter

                  • Use the Select drop-down to narrow the view into a requirement group or requirement.

                  • Use the Filter features to perform actions such as:

                    • Find a requirement group, requirement, or control by Name

                    • Find all Enabled controls within a policy

                    • Find controls in a policy by Control Type (Host/Identity/Resource)

                    • Filter by control Severity

                  Filter Details

                  Note that any filters can be combined. For example, you could filter to find:

                  How many high-severity disabled controls are linked to the policies I care about?

                  Enabled/Disabled

                  • Click in the Filter box and select Enabled = [True | False]

                  • Optional: Add more filters, such as Severity = High.

                  Name

                  • Click in the Filter box and select Name =

                  • Type a keyword and select from the drop-down options.

                  Severity

                  • Click in the Filter box and select Severity in [High | Medium | Low].

                  Type

                  • Click in the Filter box and select Type in [Host | Identity | Resource]

                    CSPM Control Types:

                    • Host: Linux, Docker, Kubernetes Cluster
                    • Resource: Kubernetes / Cloud Resource (i.e. bucket, compute, AWS resource…)
                    • Identity: Kubernetes / Cloud Identity (e.g.,. IAM)

                  2 -

                  Vulnerability Policies

                  This doc applies only to the Vulnerability Management engine. If your Sysdig Secure was deployed before April 20, 2022, use the Scanning features and the Threat Detection policy documentation. See also: Which Scanning Engine to Use

                  Overview

                  Sysdig includes scanning policies for both Pipeline and Runtime vulnerabilities that work out of the box, along with relevant rule bundles. The process of editing or creating new policies and rules is similar for both.

                  Available Rules

                  Vulnerability Rules

                  Severities and Threats

                  Scanning for vulnerabilities in the software is a primary concern; at the same time, reported vulnerabilities may not be relevant to the particular production environment being analyzed, and it’s usually unrealistic to achieve an environment with no vulns at all for a particular software package. Each organization sets an acceptable risk threshold for a vulnerability, in order to decide whether the evaluated asset is within acceptable boundaries or should be considered non-compliant.

                  CVE DenyList

                  If any vulnerability listed in this rule is detected, the rule will fail, regardless of severity or any other vulnerability attribute.

                  ImageConfig Rules

                  An OCI Image Configuration is a JSON document describing images for use with a container runtime and execution tool, and their relationship to filesystem changesets.

                  In short, is comprises the image configuration and metadata.

                  For example:

                  • Entrypoint / CMD
                  • Configured user
                  • Environment variables
                  • Labels
                  • Author
                  • Creation time
                  • Build history
                  • … (many other config keys, some of them mandatory some optional)

                  Dockerfiles VS ImageConfiguration: Dockerfiles specify a language used to generate the resulting image, which contain the mentioned ImageConfiguration file inside. Although Dockerfiles and Image Configuration files are closely related, they are not the same concept. Compliant ImageConfiguration files can be generated using development tools other than Docker/Dockerfiles.

                  Default User

                  The default user configured to run the entrypoint or CMD.

                  Defaulting to root is discouraged, as it can confer unnecessary privileges and allow an attacker easier privilege escalation or lateral movements if successfully exploited.

                  Apart from avoiding root, this rule also allows specifying a particular user (i.e. jenkins) that must be set , or otherwise fail.

                  Image Label

                  Environment Variables

                  The use of the ADD instruction is discouraged, as COPY is more predictable and less error prone.

                  Package Manager Instructions

                  This rule forbids the use of package manager instructions, per recommended security practices. (Directly fetching the latest available version of a package(s) using a package manager during image build can lead to non-reproducible builds, so may be discouraged.)

                  The following package managers / update subcommands are currently detected from the image’s build history:

                  apk
                  .*apk upgrade.*
                  apt
                  .*apt-get upgrade.*
                  .*apt upgrade.*
                  yum
                  .*yum upgrade.*
                  rpm
                  .*rpm (--upgrade|-U).*
                  pip
                  .*pip3* install (--upgrade|-U).*
                  pipenv
                  .*pipenv update.*
                  poetry
                  .*poetry update.*
                  npm
                  .*npm update.*
                  yarn
                  .*yarn update.*
                  composer
                  .*composer update.*
                  cargo
                  .*cargo update.*
                  bundle
                  .*bundle update.*
                  gem
                  .*gem update.*
                  

                  Image Creation Date

                  The creation date of an image can be used to indicate that the image has become stale.

                  NOTE: Image creation date is an optional attribute, so this rule will also fail if the date has not been declared.

                  Sensitive Information and Secrets

                  Leakage of sensitive information is one of the most severe security issues and has often led to actual security breaches. By enabling this rule, the ImageConfig metadata will be parsed for sensitive strings.

                  Example violation of an AWS secret found in the image label AWS_TOKEN:

                  The currently available detections for this rule are:

                  • Aws_secret

                    • AKIA keys: AKIA[0-9A-Z]{16}
                    • Any other key: aws.{0,20}?(?:key|pwd|pw|password|pass|token).{0,20}?
                  • Azure storage account key

                  • Basic Auth: detects [http,ssh]://user@pass:domain.com

                  • JWT token

                  • Private keys: Check if strings contains

                    "BEGIN DSA PRIVATE KEY",
                    "BEGIN EC PRIVATE KEY",
                    "BEGIN OPENSSH PRIVATE KEY",
                    "BEGIN PGP PRIVATE KEY BLOCK",
                    "BEGIN PRIVATE KEY",
                    "BEGIN RSA PRIVATE KEY",
                    "BEGIN SSH2 ENCRYPTED PRIVATE KEY",
                    "PuTTY-User-Key-File-2"
                    

                  Create Rule Bundles

                  A rule bundle is a set of scanning rules that are grouped together.

                  Note:

                  • Default Sysdig rule bundles (identified with the Sysdig shovel icon) cannot be deleted, but they can be duplicated if you want to use them as a template for a new rule bundle
                  • The same rule bundle can be used for several different policies
                  • Rules order is irrelevant from the evaluation perspective, but you can organize them to your liking for easier visualization.

                  Creation Steps

                  1. Navigate to Policies > Rule Bundles and click +Add Bundle.

                  2. Enter the parameters:

                    • Name: User-assigned name for this rule bundle
                    • Description: User-assigned rule bundle description
                    • Rules: A rule bundle is composed of 1..N scanning rules; you can use the visual editor to create and configure new rules (represented as “cards” in the interface).
                  3. Click Save. You can now attach this rule bundle to policies.

                  Example

                  In the example below, a particular vulnerability will fail the check if:

                  • The severity is High or Critical AND
                  • It was discovered 60 days ago or more AND
                  • It has a published fix AND
                  • There is a public exploit available

                  Notes:

                  • You can create multiple version of the same rule template for the same policy bundle, i.e. you can have two or more cards like the one above of type Vulnerabilities: Severities and Threats"
                  • Conditions between the same rule are evaluated with AND logic, as in the example above, a vulnerability needs to meet all the conditions in order to be considered a violation
                  • All the rules in a rule bundle are evaluated using OR logic
                    • If any rule is in violation, the rule bundle is in violation
                    • Also if any rule bundle is in violation, the policy containing it is in violation as well, considered “failed”.

                  Create Scanning Policies

                  You can create custom scanning policies and rule bundles as needed to meet your organization’s vulnerability management guidelines. The basic concepts of scanning polices and rules are:

                  • An image can be evaluated with 1..N policies at the same time
                  • A policy can contain 1..N rule bundles to be evaluated
                  • A rule bundle is composed of any number of rules to be evaluated

                  Pipeline

                  1. Navigate to Policies | Vulnerabilities > Pipeline. The Pipeline scanning policy list is displayed.

                  2. Click +Add Policy|Pipeline.

                  3. Enter the parameters:

                    • Name: User-assigned name for this policy

                    • Description: User-assigned policy description

                    • Always apply toggle: Mapping strategy to use:

                      • If Always Apply is enabled, every execution of the scanner will apply this policy. This cannot be overridden by the CLI parameters.
                      • If Always Apply is disabled, this policy must be explicitly requested when executing the scanner in order to apply it to the evaluation.
                    • Rule Bundles: A policy contains rule bundles to be evaluated. Using this widget you can add, remove, or modify the bundles used for this policy.

                      • Click Edit Assigned Rule Bundles and toggle on the bundle(s) to be assigned. Click Update.

                    • How to Scan Images with this policy: Helper widget that previews the command line to be used in order to apply the policy to the scanner run. See also: Getting Started with Sysdig Secure.

                  4. Click Create.

                  Runtime

                  1. Navigate to Policies | Vulnerabilities > Runtime. The Runtime scanning policy list is displayed.

                  2. Click +Add Policy|Runtime.

                  3. Enter the parameters:

                    • Name: User-assigned name for this policy

                    • Description: User-assigned policy description

                    • Scope: Use Entire Infrastructure or build out a desired scope.

                      • Click See Workloads in this Scope to check that the scope is valid and working as expected.
                    • Rule Bundles: A policy contains rule bundles to be evaluated. Using this widget you can add, remove, or modify the bundles used for this policy.

                      • Click Edit Assigned Rule Bundles and toggle on the bundle(s) to be assigned. Click Update.

                  3 -

                  Threat Detection Policies and Rules

                  This page introduces Sysdig threat detection policies and the rules that comprise them, providing the conceptual background needed to create, edit, and apply security policies in your own environment.

                  Understanding 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 and Action (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, and Severity can also be edited

                    • As 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.

                  Reviewing 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 of Rules, assigned Actions to take on affected containers (Stop | Pause | Notify), and Capture details, if any.

                  • Policy Status: 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.

                  • Policy Type icons

                  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:

                  Scope OptionsAction Options
                  RUNTIME
                  WorkloadCustom
                  Hosts only
                  Container only
                  Stop/ pause/ kill
                  Capture
                  Notification channel
                  List-MatchingCustom
                  Hosts only
                  Container only
                  Stop/ pause/ kill
                  Capture
                  Notification channel
                  DriftCustom onlyPrevent
                  Notification channel
                  LOG DETECTION
                  Kuberneteskubernetes.cluster.name
                  kubernetes.namespace.name
                  Notification channel
                  AWS Cloudaws.accountId
                  aws.region
                  Notification channel
                  GCPgcp.projectid
                  gcp.location
                  Notification channel
                  Azureazure.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.

                  Be aware that this option uses ptrace, which is more resource-intensive than the default mode.

                  Understanding Machine Learning Policies

                  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.

                  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.

                  Understanding How Policy Actions Are Triggered

                  Policy actions occur asynchronously. If a policy has a container action and matched activity, the agent asks the Docker/Cri-o daemon to perform the stop/kill/pause action. This process takes a few minutes, during which the container still runs and the connect/accept etc. still occurs.

                  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.

                  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 Insteller.

                  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/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 no image/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:

                  4 -

                  Manage Threat Detection Policies

                  Overview

                  Review Threat Detection Polices and Rules, if needed.

                  In general, users will:

                  • Use Default Managed policies out-of-the-box, defining only the Scope , actions such as Nofication Channels, and enabling/disabling the policy;
                  • Duplicate a policy to create a Managed Ruleset and edit additional parameters such as Name, Description, and Severity, creating Managed Ruleset policies;
                  • Require Custom rules and either convert an existing policy or build policy parameters and ruleset from scratch.

                  Create a Policy

                  NOTE: Policies can also be generated using Image Profiles to automate creation of image-specific policies

                  Steps to Create a Custom Policy from Scratch

                  1. Log in to Sysdig Secure and select Policies > Runtime Policies.

                  2. On the Runtime Policies list page, select +Add Policy.

                  3. Select Type: Select the policy type and define the policy parameters. Note: The Scope available will differ by policy type.

                  4. Define parameters: E.g., Name, Description, Severity, etc. Most policy types have the same parameters; Drift and Machine learning have some differences.

                  5. Add rules: Add or edit the rules to be used.

                  6. Define actions: to be taken if the policy rules are breached.

                  7. Enable and Save the policy.

                  Details in the following sections.

                  Policy Details

                  Select the Policy Type

                  When you click +Add Policy, you are prompted to choose the Policy Type desired. See also: Review Policy Types

                  Define the Basic Parameters

                  The Policy parameters differ mainly by the Scope and Actions available on the type selected.

                  • Name and Description: Provide meaningful, searchable descriptors

                  • Enabled/Disabled: Once enabled, the policy will begin to generate events.

                  • Severity: Choose the appropriate severity level as you would like to see it in the Runtime Policies UI.

                    Policy severity is subjective and is used to group policies within a Sysdig Secure instance.

                    NOTE: There is no inheritance between the underlying rule priorities and the severity you assign to the policy.

                  • Scope: Define the scope to which the policy will apply, based on the type-dependent options listed.

                  Additional Parameters for Drift Policy Type

                  The Drift policy differs from the other policy types in a few ways:

                  • 1:1 Policy:Rule Drift includes only one rule.
                  • Prevent You can toggle the Prevent action to stop the binary ever from starting.
                  • Dynamic Deny List When enabled, the policy evaluates and tracks any downloaded executable on the container. If that executable attempts to run, Sysdig will create an alert, or the executable is denied from running if Prevent is enabled.
                  • Exceptions A user-defined list that can allow a downloaded executable to not trigger an alert
                  • Always Deny A user-defined list that will always block the executable from running even if it was built with the image

                  Additional Parameters for Machine Learning Policy Type

                  The Machine Learning policy differs from the other policy types in a few ways:

                  • Detection types You can what type of Machine Learning based detections you want enable in your policy. We support only Crypto Mining Detection at this time.
                  • Confidence level You can fine-tune the policy to choose at which certainty level the detection should trigger an event.
                  • Severity defined at detection level, so that you can have a different severity for each detection type.

                  Add Rules

                  You can select existing rules from the Library or create new rules on the fly and add them to a policy.

                  The Policy Editor interface provides many flexible ways to add rules to or remove rules from a Policy; the instructions below demonstrate one way.

                  See also: Manage Rules

                  Import from Library
                  1. From the New Policy (or Edit Policy) page, click Import from Library.

                    The Import from Rules Library page is displayed.

                  2. Select the checkboxes by the rules to import.

                    You can pre-sort a collection of rules by searching for particular keywords or tags, or clicking a colored Tag icon (e.g. ).

                  3. Click Mark for Import.

                    A blue Import icon

                    appears to the right of the selected rules and the Import Rules button is activated.

                  4. Click Import Rules.

                    The Policy page is displayed with the selected rules listed.

                    You can remove a rule from a Policy by clicking the X next to the rule in the list.

                  Create a Rule from the Policy Editor

                  If you click New Rule instead of Import from Library, you will be linked to the procedure described in Create a Rule.

                  Define Actions

                  Determine what should be done if a Policy is violated. See also: Understanding How Policy Actions Are Triggered.

                  Containers

                  Select what should happen to affected containers if the policy rules are breached:

                  • Nothing (alert only): Do not change the container behavior; send a notification according to Notification Channel settings.

                  • Kill: Kills one or more running containers immediately.

                  • Stop: Allows a graceful shutdown (10-seconds) before killing the container.

                  • Pause: Suspends all processes in the specified containers.

                  For more information about stop vs kill command, see Docker’s documentation.

                  Capture

                  Toggle Capture ON if you want to create a capture in case of an event, and define the number of seconds before and after the event that should be in the snapshot.

                  As of June, 2021, you can add the Capture option to policies affecting events from both the Sysdig agent and Fargate Serverless Agents Fargate serverless agents. Note that for serverless agents, manual captures are not supported; you must toggle on the Capture option in the policy defintion.

                  See also: Captures.

                  Notification Channels

                  Select a notification channel from the drop-down list, for sending notification of events to appropriate personnel.

                  See also: Set Up Notification Channels.

                  Duplicate, Convert, or Delete a Policy

                  Select a row in the Runtime Policies list to expand the policy details and access the icons to Edit, Copy, or Delete the policy.

                  Duplicate to Create a Managed Ruleset Policy

                  1. Select a Managed Policy in the Runtime Policies list and click the Duplicate icon in the details panel.

                  2. Optionally edit any of the parameters except the rules.

                  3. Click Save.

                    The new policy will appear in the Runtime policy list tagged Ruleset.

                    Note you can also duplicate a Ruleset, if desired.

                    If the Sysdig Threat Research team updates the underlying ruleset in the Default policy on which it was based, the Managed Ruleset policy will be updated accordingly.

                  Convert to Create a Custom Policy

                  1. Select a Default or a Ruleset policy from the Runtime Policies list and click the Edit icon in the details panel.

                  2. Click the Convert to Custom button in the middle of the page.

                    You can now edit everything about this policy, including the rules. It will not be managed/updated by the Sysdig team; if new rules are offered, the user is responsible for adding them to the custom policies as desired.

                  3. Click Save.

                    Duplicating a custom policy simply creates another unmanged custom policy.

                  5 -

                  Manage Threat Detection Rules

                  Review Understanding Threat Detection Rules to get started.

                  Access the Rules Library

                  1. Select Policies > Rules | Rules Library.

                  2. The Rules Library is displayed.

                  Tips:

                  • Rules are listed alphabetically by name.

                  • Search: Click the magnifying glass if the Search field is not automatically opened. Search by words in the rule name.

                  • Published by: Remember that default (Falco) rules show up as Published by: Sysdig ; user-created rules show as Published by: Secure UI. See also: Edit a Rule.

                  • Usage: Shows number of policies where the rule and used, and whether the policies are enabled. Click the rule to see the policy names in the Rule Detail panel.

                  Create a Rule

                  There are different interfaces for creating Falco rules vs. list-matching rules.

                  Create a Falco Rule

                  1. From the Rules Library page, click +Add Rule and select Falco from the drop-down.

                    The New Rule page for the Falco rule type is displayed.

                  2. Enter the parameters:

                    Name and Description: create a name and a meaningful description for the rule

                    Condition and Output: write the condition code and outputs required. See Supported Fields for more information.

                    Priority: This is a required field to meet the Falco rule syntax.

                    Source: Define if the rule is detecting events using the Kubernetes Audit data source or using the standard syscall mechanisms

                    Tags: Select relevant tags from the drop-down or add your own custom tag

                  3. Click Save.

                  Falco rules with the source k8s_audit need Kubernetes Audit logging enabled for conditions to be met.

                  Create a List-Matching Rule: Container Type Example

                  Suppose you want detect whenever someone used a specific container image that has known problems. In this case, a Container rule would be appropriate. (The other list-matching rule types have similar entry fields, as appropriate to their type.)

                  1. From the Rules Library page, click +Add Rule and select Container from the drop-down.

                    The New Rule page for the Container rule type is displayed.

                  2. Enter the parameters:

                    Name: Enter a Name, e.g. Problematic Images.

                    Description: Enter a Description, e.g. Images that shouldn’t be used

                    If Matching/ If Not Matching: Select If Matching. When added to a policy, if the rule conditions match, then the policy action you define (such as “send notification”) will be triggered.

                    Containers: Add the container name(s) that are problematic, e.g. cassandra:3.0.23.

                    Tags: Select relevant tags from the dropdown, e.g. database and container.

                  3. Click Save.

                  Review a Rule Detail Panel

                  From the Rules Library list, select a rule to see its details.

                  From here you can:

                  • Review the rule definition, including clicking embedded macros to open their details in a pop-up window

                  • See all the tags associated with the rule (colored boxes)

                  • Check all policies in which the rule is used and see whether those policies are enabled or disabled.

                  Edit a Rule

                  Any rules published by Sysdig are default and are read-only. You can append to their lists and macros, but cannot change the core parameters. Default rules cannot be deleted.

                  Self-created rules can be freely edited. You can also override the behavior of default Falco rules and macros using a placholder mechanism in the Rules Editor.

                  To display existing rules:

                  1. Select Policies > Rules | Rules Library and select a rule.

                  2. The Rule Details panel opens on the right. You can review the parameters and append to macros and lists inline if desired.

                  Append to Falco Macros and Lists

                  Default Falco rules have a variety of macros and lists embedded in them. While these cannot be deleted from a default rule, you can append additional information onto them.

                  For example, consider the Policy DB Program Spawned Process in the screenshot above. The embedded rule is used to check that databases have not spawned illicit processes. You can see in the rule condition the Falco list : db_server_binaries.

                  To append items in a default list:

                  1. Click the blue list text in the rule condition, or go to Policies > Falco Lists and search for it by name.

                  2. The list content is displayed. Click Append.

                  3. Enter the additional items (i.e. databases) you want to include in the rule and click Save.

                    The same process applies to macros.

                  How to Use the Rules Editor

                  The Rules Editor allows you can freely create custom Falco rules, lists, and macros and can override the behavior of the defaults.

                  Understand the Interface

                  To access the interface, select Policies > Rules Editor:

                  The Right Panel (Default)

                  Displays the rules_yamls provided from Sysdig.

                  • Contains the default rules and macros

                  • Is read-only

                  The Left Panel (Custom)

                  Displays the custom rules and overrides you want to add to the selected rules_yaml.

                  Note that many default Falco rules and macros have a parallel placeholder entry (commented out) in the yaml file. These have the prefix user_known. To change the behavior of a default rule, it is recommended to copy the placeholder equivalent into the custom rules panel and edit it there, rather than editing the default rule directly.

                  To search the rules YAML files

                  Click inside the Rules Editor right panel and use CNRL F to open an internal search field .

                  See also: Runtime Policy Tuning .

                  Use Cases: List-Matching Rules

                  It is more helpful to think of the rules as matching the activity, rather than using concepts of allowing or denying. (The Network types can be a little confusing in this regard; see the last two use cases for more detail on that type). Thus, the use cases are based on answering the question: What do I want to know?

                  I WANT TO KNOW…

                  when any process other than web server programs are run:

                  • Rule Type: Process

                  • If Not Matching

                  • Entries: [apache, httpd, nginx]

                  if any of the following crypto-mining processes are run:

                  • Rule Type: Process

                  • If Matching

                  • Entries: [minerd, ccminer]

                  if any program reads any file containing password-related information:

                  • Rule Type: Filesystem

                  • Read Operations: If Matching

                  • Entries: /etc/shadow, /etc/sudoers, /etc/pam.conf, /etc/security/pwquality.conf

                  if any program writes anywhere below binary directories:

                  • Rule Type: Filesystem

                  • Read/Write Operations: If Matching

                  • Entries: /usr, /usr/bin, /bin

                  if a program writes to anywhere other than /var/tmp:

                  • Rule Type: Filesystem

                  • Read/Write Operations: If Not Matching

                  • Entries: /var/tmp

                  if any container with an image from docker.io is started:

                  • Rule Type: Container

                  • If Matching

                  • Entries: [docker.io/]

                  if any container runs an Apache web server:

                  • Rule Type: Container

                  • If Matching

                  • Entries: [httpd, amd64/httpd]

                  I want to know if any container with a non-database image is started:

                  • Rule Type: Container

                  • If Not Matching

                  • Entries [percona/percona-server, mysql, postgres]

                  if any program accepts an inbound ssh connection:

                  • Rule Type: Network

                  • Tcp, "If Matching"

                  • Entries: [22]

                  if any program receives a DNS datagram:

                  • Rule Type: Network

                  • UDP, "If Matching"

                  • Entries: [53]

                  if any program accepts a connection on a port other than http/https

                  • Rule Type: Network

                  • TCP, "If Not Matching"

                  • Entries: [80, 443]

                  if any program accepts any inbound connection:

                  • Rule Type: Network

                  • Inbound Connection: Deny

                  if any program makes any outbound connection

                  • Rule Type: Network

                  • Outbound Connection: Deny

                  6 -

                  Runtime TD Policy Tuning

                  The Runtime Policy Tuning feature assists in reducing noisy false positives in the Sysdig Secure Events feed. Built on top of the Falco Rules Tuner, it automatically adds Exceptions to rules, thereby removing particularly noisy sets of policy events and leaving the lower-volume events for later analysis.

                  The tuner may be especially helpful when deploying Sysdig Secure runtime policies in a new environment. Your environment may include applications that legitimately perform actions such as running Docker clients in containers, changing namespaces, or writing below binary directories, but which trigger unwanted floods of related policy events in the default policies and rules provided by Sysdig.

                  Earlier versions of Sysdig used the The Falco Rules Tuner (Legacy) .

                  Using Runtime Policy Tuner

                  Prerequisites

                  • Sysdig agent 11.0.0+

                  • Sysdig SaaS or Sysdig On-Prem 5.0+

                  Please contact Sysdig Support to make this feature available in your environment.

                  Enable, View, Edit Exceptions, Disable

                  The tuner is enabled and disabled as needed to tame false positives and optimize the use of the Events feed. By default, it is disabled.

                  1. Log in to Sysdig Secure as Admin and choose Policies > Runtime Policy Tuning.

                  2. Enable the feature with the Tuning Engine toggle.

                    It may take up to 24 hours to see the initial Applied Tuning Exceptions listed in the left panel.

                    In the background, the tuner will evaluate policy events as they are received by the Sysdig backend, find applicable exceptions values, and add them. The AppliedTuning Exceptions file is passed along to all Sysdig agents, along with the rules and policies.

                  3. If needed, you can edit the Exceptions created directly in the left-hand panel.

                    Any changes will be retained as the tuner evaluates additional events.

                  4. Toggle the Tuning Engine off when you feel the feature has addressed the most commonly occurring (unwanted) policy events.

                    NOTE: Any exceptions in the Applied Tuning Exceptions panel will still be passed along to agents.

                    To start over from scratch, clear the Applied Tuning Exceptions text and re-enable with the Tuning Engine toggle.

                  Understanding How the Tuning Engine Works

                  When Does the Tuner Add Exceptions?

                  The Policy Tuning feature is conservative, only adding exceptions for commonly occurring events for a single rule with similar attributes.

                  All the conditions must be met:

                  • The rule has generated at least 25 policy events in the past hour

                  • A candidate set of exception values is applicable to at least 25% of the events in the past hour

                  This ensures the tuning feature only adds exceptions for high-volume sets of events that can be easily addressed with a single set of exception values.

                  Exceptions Behind the Scenes

                  If you want to understand the process of exception insertion by the tuner, consider a sample rule:

                  - rule: Write below root
                    desc: an attempt to write to any file
                     directly below / or /root
                    condition: root_dir and evt.dir = < and
                     open_write
                    exceptions:  - name: proc_writer
                    fields: [proc.name, fd.filename]
                  

                  And a stream of policy events with outputs such as:

                  File below / or /root opened for writing (user=root user_loginuid=-1 command=/usr/local/bin/my-app-server parent=java file=/state.txt program=my-app-server container_id=a97d44bbe437 image=my-registry/app-server:latest
                  File below / or /root opened for writing (user=root user_loginuid=-1 command=/usr/local/bin/my-app-server parent=java file=/state.txt program=my-app-server container_id=a97d44bbe437 image=my-registry/app-server:latest
                  File below / or /root opened for writing (user=root user_loginuid=-1 command=/usr/local/bin/my-app-server parent=java file=/state.txt program=my-app-server container_id=a97d44bbe437 image=my-registry/app-server:latest
                  File below / or /root opened for writing (user=root user_loginuid=-1 command=/usr/local/bin/my-app-server parent=java file=/state.txt program=my-app-server container_id=a97d44bbe437 image=my-registry/app-server:latest
                  

                  Then the tuner would add the following exception values to address the false positives:

                  - rule: Write below root
                    exceptions:
                    - name: proc_writer
                      values:
                         - [my-app-server, /state.txt]
                     append: true
                  

                  See the Falco proposal for more background information on using exceptions.

                  6.1 -

                  The Falco Rules Tuner (Legacy)

                  This version of the tuner has been updated for Sysdig SaaS; this content is preserved for older on-prem Sysdig environments.

                  Sysdig policies are built on rules, including Falco rules and macros. (For review: Understanding Sysdig Secure Rules and Using Falco within Sysdig Secure.) Sysdig is always working to improve its out-of-the-box policies based on activity captured about well-known containers and OSS applications. Nevertheless, proprietary software running in unique user environments can require a customized approach.

                  The Falco Rule Tuner was created to simplify the process of updating the existing ruleset to reduce false positives.

                  The tool fetches policy events generated during a configurable time window (EVENT_LOOKBACK_MINUTES), and based on occurrence threshold (EVENT_COUNT_THRESHOLD), it suggests updates to rules. It’s up to the user to evaluate the suggestions and selectively apply the changes.

                  To use the Rule Tuner, you will provide some environment variables, run as a Docker container, review the output in a Slack channel or the terminal window, and then apply the recommended tuning adjustments as desired, in the Sysdig Secure Rules Editor.

                  Requirements

                  • Sysdig Secure SaaS or On-Prem version 3.5.0+

                  • An available Slack channel (optional, for receiving output information)

                  • Environment variable values listed in the table below

                  Set Variables and Run the Container

                  Gather the values needed for the following environment variables.

                  Required Environment Variables for Falco Rule Tuner

                  Variable

                  Description

                  SECURE_CUSTOMER

                  Optional: Name of the business entity. Default: test

                  SECURE_ENDPOINT

                  The endpoint for the tuning engine to query.

                  For SaaS, see SaaS Regions and IP Ranges.

                  For On-Prem, the endpoint has been user-defined.

                  SECURE_TOKEN

                  The Sysdig Secure API token used to access the Secure backend. See Find Sysdig API Token.

                  SLACK_WEBHOOK

                  Optional: The Slack webhook URL to receive the events summary and rule tuning recommendations.

                  For example: https://hooks.slack.com/services/...

                  EVENT_LOOKBACK_MINUTES

                  The number of minutes the Falco Rule Tuner should look back to gather the events. Default: 60

                  EVENT_COUNT_THRESHOLD

                  The threshold number of events over which a tuning is recommended. Default: 5.

                  Setting the threshold to 1 would mean that every policy event should be considered a false positive.

                  Required Environment Variables for Falco Rule Tuner

                  Run as a Docker container:

                  docker run -e SECURE_ENDPOINT=${SECURE_ENDPOINT} -e SECURE_TOKEN=${SECURE_TOKEN} quay.io/sysdig/falco_rules_tuner
                  

                  The output in the terminal window will show the recommended rules to be adjusted and the recommended/generated macros and their conditions, e.g.:

                  ... <etc.>
                  
                  # Change for rule: Write below root
                  - macro: elasticsearch-scripts_python_access_fileshost_exe_access_files
                    condition: (container, image, repository endswith locationservices/elasticsearch-scripts and proc.name=python and (fd.name startswith=/root/app/))
                  

                  Check Output in Slack Channel (Optional)

                  The output provided in the terminal window includes only the recommended rule changes. If you provide a Slack channel URL in the environment variables, the Tuner gives both an event summary and the recommended rule changes.

                  For review: How to Use the Rules Editor.

                  The Tuner detects rules that may be triggering excess alert “noise” and proposes content relevant macros and macro conditions that would reduce the noise.

                  To implement the suggestions, you can 1) copy the rule contents directly into the left panel of the Rules Editor and edit them, or 2) find the existing placeholder macro that was created for that rule (usual format: user_known_<rule_name> ) and add the suggested macros and conditions there.

                  Note that editing the definition of a rule directly could cause overwrite issues when upgrading Sysdig versions. Creating custom rules or using the user_known placeholders is a safer procedure.

                  For example, suppose you decide to implement the Tuner prompt 4 in the image above, which suggests changing the configuration of the rule Write below root. One way to proceed:

                  1. Search [CTRL F] the falco_rules.yaml for Write below root.

                    You will find both the Rule itself

                    and placeholder macros, user_known_write_below_root_activities and user_known_write_below_root_conditions. Either one can be used.

                  2. Copy one placeholder to the left-hand Custom Rules panel of the Editor: user_known_write_below_root_activities .

                  3. Copy the tuner-generated macro (elasticsearch-scripts_python_access_files in this case), and conditions into the Custom Rules panel, overwriting the never_true default condition. The result is something like:

                    # generated by tuner and copied to here (custom panel in the rules editor)
                    - macro: elasticsearch-xxx
                      condition: (...)
                    - macro: user_known_write_below_root_acitivies
                      condition: (elasticsearch-xxx) # updated from "never_true" with the generated macro name
                    
                  4. Click Save.

                    The tuning adjustment will apply when the Write below root rule is invoked in a policy.

                    These changes will apply anywhere that the edited macro ( user_known_write_below_root) is used. Some macros have been embedded in multiple rules and/or other macros. Edit at your discretion.

                  7 -

                  Install Falco Rules On-Premises

                  Periodically, Sysdig releases new Falco Rules that provide additional coverage for new behaviors and adds exceptions for known good behaviors. This topic helps you install Falco Rules as a container in an on-prem deployment. For air-gapped deployments, the instructions slightly differ given the security measures employed in the isolated setup.

                  Sysdig provides a container image on the Docker hub to install Falco Rules on the Sysdig Platform.

                  This container image allows easy installation and upgrades of the Falco rules files for Sysdig Secure. The file contains the following:

                  • The rule files.

                  • The latest version of Falco.

                  •  The sysdig-sdk-python wrappers that deploy the rule files to a Sysdig platform deployment.

                  The image is tagged with new versions as new sets of rules files are released, and the latest tag is always pointed to the latest version.

                  When a container is run with this image, it does the following:

                  • Validates the rules.

                  • Fetches the custom rules file and verifies compatibility with the to-be-deployed default Falco rules file.

                  • Deploys the rules to the configured Sysdig Platform backend component.

                  The Falco Rules Updater can be run from ANY machine on the same network as the backend that has Docker installed. It does not have to be the backend server.

                  Example

                  Non-Airgapped Environment

                  This section assumes that the installation machine has network access to pull the image from the Docker hub.

                  1. Download the container image:

                    # docker pull sysdig/falco_rules_installer:latest
                    
                  2. Use the docker run to install the Falco Rules. For example:

                    # docker run --rm --name falco-rules-installer --network host -it -e DEPLOY_HOSTNAME=https://my-sysdig-backend.com -e DEPLOY_USER_NAME=test@sysdig.com -e DEPLOY_USER_PASSWORD=<my password> -e VALIDATE_RULES=yes -e DEPLOY_RULES=yes -e CREATE_NEW_POLICIES=no -e SDC_SSL_VERIFY=True sysdig/falco_rules_installer:latest
                    

                  Airgapped Environment

                  This section assumes that the installation machine does not have the network access to pull the image from the Docker hub.

                  1. Download the container image on a machine that is connected to the network:

                    # docker pull sysdig/falco_rules_installer:latest
                    
                  2. Create an archive file for the image:

                    # docker save sysdig/falco_rules_installer:latest -o falco_rules_installer.tar
                    
                  3. Transfer the tar file to the air-gapped machine.

                  4. Untar the image file:

                    # docker load -i file.tar
                    

                    It restores both images and tags.

                  5. Use the docker run to install the Falco Rules. For example:

                    # docker run --rm --name falco-rules-installer --network host -it -e DEPLOY_HOSTNAME=https://my-sysdig-backend.com -e DEPLOY_USER_NAME=test@sysdig.com -e DEPLOY_USER_PASSWORD=<my password> -e VALIDATE_RULES=yes -e DEPLOY_RULES=yes -e CREATE_NEW_POLICIES=no -e SDC_SSL_VERIFY=True sysdig/falco_rules_installer:latest
                    

                  Usage

                  You can run this container from any host that has access to the server that hosts the Sysdig backend API endpoint. The hostname is specified in the DEPLOY_HOSTNAME variable. The container need not run on the hosts where the Sysdig Platform backend components are running.

                  To run, the container depends on the following environment variables:

                  VariablesDescription
                  DEPLOY_HOSTNAMEThe server that hosts the Sysdig API endpoints. The default is https://secure.sysdig.com.
                  DEPLOY_USER_NAMEThe username for the account that has the admin-level access to the Sysdig API endpoints. The value defaults to a meaningless user, nobody@nobody.com.
                  DEPLOY_USER_PASSWORDThe password for the admin user. The value defaults to a meaningless password nopassword.
                  VALIDATE_RULESIf set to yes, ensure that the rules file is compatible with your user rules file. Otherwise, skip this validation step. The value defaults to yes.
                  DEPLOY_RULESIf set to yes, the falco rules file is deployed. Otherwise, skip deploying the falco rules file. The value defaults to yes.
                  CREATE_NEW_POLICIESIf set to yes, will fetch new DEFAULT runtime policies, and restore any missing/deleted DEFAULT runtime policies. This will NOT overwrite any of your existing runtime policies. The value default is no.
                  SDC_SSL_VERIFYIf set to false, allow certificate validation failures when deploying the rules. The value defaults to true.

                  See Docker hub for the latest information about the image and usage.

                  8 -

                  Image Profiles

                  The image profiling tool in Sysdig Secure takes advantage of the agent’s ability to observe the behavior of an image during runtime. It learns what is common behavior for the container and then suggests a customized policy of Falco rules to match the observed behaviors.

                  This feature enhances and automates Sysdig Secure’s ability to detect anomalies at enterprise scale.

                  Compared with manual creation of rules and policies, image profiles have the following advantages:

                  • Actionable accuracy: Profiling provides deep visibility into the application behavior

                  • Automation: Profiling uses machine learning and automated rule creation, allowing busy administrators to secure images quickly and easily

                  • Security enhancement: Explicitly stating what is allowed provides better security than stating what is forbidden

                  How Image Profiles Work

                  Once the feature is enabled, the agents start sending “fingerprints” of what happened on the containers – network activity, files and directories accessed, processes run, and system calls used – and Sysdig Secure aggregates this information per image. Thus, for multiple containers based off of the same image, running on different nodes, the image profiler will collect and combine system activity into an image profile.

                  Internal algorithms determine two aspects of behavior:

                  • Length of time observed: Related to the image being in a learning/done learning state

                  • Consistency of behavior: Related to the confidence level of the observed behavior and related policy rule suggestions

                  Profile Contents

                  A container image profile is a collection of data points related to:

                  • Network activity

                    • TCP ports (in/out)

                    • UDP ports (in/out)

                  • Processes detected

                  • File system (informational only)

                    • Files (read/write)

                    • Directories (read/write)

                  • System calls detected

                  Learning/Done Learning

                  If the containers run consistently, the learning phase lasts about 24 hours.

                  (Note that containers, for example, that are triggered for a job that lasts an hour and then are re-triggered a week later, would have a much longer learning phase.)

                  When enough samples are collected for observation, the image status is designated as Done learning. At this point, you can create a policy based on the profile.

                  Confidence Levels

                  The confidence level is a smart statistical indicator calculated based on behavioral consistency, both temporal and across different containers, for a given image. Low, Medium, and High confidence levels are displayed in the UI with 1, 2, or 3 squares.

                  Policies should only be created from profiles with HIGH confidence levels. In this case, the container behaves very predictably across the cluster and you can create a policy to whitelist the observed behavior and trigger notifications on any anomalous activity.

                  Using Image Profiles

                  To use the Image Profile tool, follow these basic steps:

                  1. Contact Sysdig (SaaS) or the Sysdig administrator (On-Prem) to enable the feature.

                  2. Allow the agents to collect information for at least 24 hours.

                  3. Review the collected profiles details, selecting those that are Done Learning and have High Confidence.

                  4. Use the checkboxes to include details and create per-image policies.

                  5. Repeat regularly.

                  Review Profiles and Create Policies

                  1. Log in to Sysdig Secure and select Policies > Image Profiles.

                  2. Filter the list by Done Learning to see the actionable profiles. Focus on those with High Confidence levels (three squares).

                  3. Select an image title to review and expand the elements in the Details panel. Select an individual element to see the specific data collected.

                  4. Check the boxes for the items you want to include and click Create Policy from Profiles.

                    The Create a Scanning Policy page is displayed.

                    By default, the:

                    • Title is “Image Policy - <image name>

                    • Description is “Policy automatically generated by Sysdig Profiler

                    • Severity is Medium

                    • Scope is limited to that image

                    • Action is Notify only

                  5. Edit any defaults as desired and click Save.

                    The new policy appears in the Runtime list.

                  Additional Profile Options

                  From the Image Profiles page, there are two additional actions you can take: Restart or Delete Profile. Restart purges the profile for the image and resets it to the initial learning state. Delete completely removes the profile from the database.

                  Restart Profile

                  Click Restart Profile to begin the learning process again. Restart is useful when the previously created policy generates false positives due to changed behavior of the containers.

                  Delete Profile

                  If you click Delete Profile, then:

                  • The profile is deleted from the list. If the agent continues to detect activity on this image, the profile will be created again.

                  • If you have already created a policy based on this profile, you should remove it as no longer useful.

                  • This option is useful for deleting profiling for images that are no longer used.