• 1:
• 2:
• 3:
• 3.1:
• 3.2:
• 3.3:
• 4:
• 4.1:
• 4.1.1:
• 4.1.2:
• 4.1.3:
• 4.1.4:
• 4.1.4.1:
• 4.1.4.2:
• 4.1.4.3:
• 4.1.4.4:
• 4.1.4.4.1:
• 4.1.4.4.2:
• 4.1.4.4.3:
• 4.2:
• 5:
• 5.1:
• 5.2:
• 5.3:
• 5.4:
• 5.5:
• 5.5.1:
• 5.6:
• 5.7:
• 5.8:
• 6:
• 6.1:
• 6.2:
• 7:
• 7.1:
• 7.1.1:
• 7.1.2:
• 7.1.3:
• 7.1.4:
• 7.1.5:
• 7.1.6:
• 7.1.7:
• 7.1.8:
• 7.1.9:
• 7.1.10:
• 7.1.11:
• 7.1.12:
• 7.2:
• 7.3:
• 8:
• 8.1:
• 8.2:
• 8.3:
• 9:
• 9.1:
• 9.2:
• 10:
• 10.1:
• 10.1.1:
• 10.2:
• 10.2.1:
• 10.3:
• 10.3.1:
• 11:
• 11.1:
• 11.2:
• 11.3:
• 12:
• 13:
• 13.1:
• 13.1.1:
• 13.2:
• 13.3:
• 13.4:
• 13.4.1:
• 13.4.2:
• 13.4.3:
• 13.5:
• 13.6:
• 13.6.1:
• 13.7:
• 13.8:
• 13.9:
• 13.10:
• 13.10.1:
• 13.11:
• 13.12:
• 14:

1 -

Getting Started with Sysdig Secure

Get Started Page (Free Tier)

Users who choose Sysdig Secure for cloud’s Free Tier option can quickly connect a single cloud account/region with Sysdig Secure CSMP, threat detection, and image/registry scanning functions, using https://sysdig.com/company/start-free/

Once connected, the Get Started page shows a subset of the options available in the 30-day trial or Enterprise page.

Free Tier Entries

What do I get with Free Tier?

• Cloud Security Posture Management and Compliance

• Out-of-the-box CloudTrail threat detections

• Fargate/ECR image scanning for up to 250 scans per month

Connect Your Cloud Account

• Here you can easily launch a CloudFormation template to connect an AWS account to Sysdig Secure. Be sure to deploy in the AWS account and region you want to secure.

Integrate Scanning into your CI/CD Pipeline

• By analyzing images locally on the CI/CD worker nodes, the Sysdig Secure inline scanner provides the following key benefits:

  • The ability to shift security left by scanning images before they are pushed to the registries

  • The ability to parallelize and distribute scanning workloads

  • No need to share credentials with Sysdig’s SaaS service or send images to the Sysdig backend to be analyzed.

Invite Your Team

• Invite someone in your team to use this Sysdig Secure account. They will receive an email and a user will be created for them. They are automatically assigned to Advanced User role.

Get Started Page (Trial or Enterprise)

The Get Started page targets the key steps to ensure users are getting the most value out of Sysdig Secure. The page is updated with new steps as users complete tasks and as Sysdig adds new features to the product.

The Get Started page also serves as a linking page for

• Documentation

• Release Notes

• The Sysdig Blog

• Self Paced Training

• Support

Users can access the Get Started page at any time by clicking the rocketship in the side menu.

Connect Your Data Sources

Connect Your Cloud Account

• Here you can easily launch a CloudFormation template to connect an AWS account to Sysdig Secure. Be sure to deploy in the AWS account and region you want to secure.

Install the Agent

• Installing the agent on your infrastructure allows Sysdig to collect data for monitoring and security purposes. See also Quick Install Sysdig Agent on Kubernetes . Recommended: Use the Helm chart installation option to obtain the Vulnerability Management engine and the runtime scanner.

Integrate with the Kubernetes Audit Log

• The Kubernetes Audit log provides a security-relevant chronological set of records documenting the Kubernetes API activity. By parsing the Kubernetes Audit log we can track user activity, sensitive modifications, and permissions updates. Processing and auditing API logs is key to tracking indicators of compromise within Kubernetes environments, as well as meeting compliance controls.

Invite Your Team

• Invite someone in your team to use this Sysdig Secure account. They will receive an email and a user will be created for them. They are automatically assigned to Advanced User role.

Secure Your Pipeline

Scan an Image

• With the sysdig-cli-scanner you can automatically scan your images even before they are uploaded to a registry. Go to Vulnerabilities pipeline page for a detailed information on how to integrate this feature.

Set up and Link a Notification Channel

• Sysdig Secure will emit alerts to get proactive notification of events, anomalies, or any security incident that requires attention. The alerting system provides out-of-the-box push gateways for regular email, Slack, Cloud-provider notification queues, and custom webhooks, among others.

Secure Your Runtime Environment

Create a Detection Rule

• Sysdig Secure detects and responds to anomalous runtime activity by leveraging its behavioral detection engine, which is built on top of the open-source project, Falco. Additionally, users can easily create whitelist-based security rules for process execution, file access, and network activity using the basic policy engine.

Enable CIS Benchmark Scan

• Schedule a Compliance task to perform regular scans of your environment and ensure you are meeting industry best practices and regulatory requirements.

2 -

Insights

Sysdig Secure (SaaS) has introduced a powerful visualization tool for threat detection, investigation, and risk prioritization, to help identify compliance anomalies and ongoing threats to your environment. With Insights, all findings generated by Sysdig across both workload and cloud environments are aggregated into a visual platform that streamlines threat detection and forensic analysis.

Highlights:

• Birds-eye view of findings across environments and timelines, with responsive representations combined with summaries plus the linear events feed

• Instantly hone in on problem areas or block out noisy results

• Share views with team members

Access the Insights Page

The Insights page is enabled automatically as the landing page for Sysdig Secure.

Usage

The Insights tool is intuitive and easy to use. Note the following design and usage attributes.

Navigation

Choose the resources you want to view from the top-left dropdown.

• Cloud User Activity: Detects vulnerabilities and events related to user activity in connected cloud accounts. It includes User, Account, Region, Resource Category, Resource Type, and Resource.

• Cloud Activity: Detects all findings in connected cloud accounts. Specifically, it includes Account, Region, Resource Category, Resource Type, and Resource.

• Kubernetes Activity: Detects all findings in connected Kubernetes clusters, namespaces, and workloads. It includes Cluster, Namespace, Pod Owner, and Workload.

• Composite View: Detects and aggregates all findings from both the Cloud Activity and the Kubernetes Activity views. It includes Account, Region, Resource Category, Resource Type, Resource, Cluster, Namespace, Pod Owner, and Workload.

The default view shown will be based on the findings in your environment. If there are events in Cloud and Kubernetes, the Composite view is default; otherwise the Cloud or Kubernetes Activity view is chosen.

If a particular type of resource is not connected in your environment, that page will show no findings.

Timeline

As with many other Sysdig tools, you scope by timespan using the timeline at the bottom of the page.

• The default span is 14 days. You can choose other presets (3H, 12H, 1D, 3D, etc.) or set a span using the clickable calendar.

• Insights display up to 14 days or 999 events, whichever comes first.

Visualization Panel

The power of the Insights tool resides in the Visualization panel.

Experiment with the Visualization panel features:

• Concentric rings drill down the resources to the most granular findings. Note that the header labels each level in order (Account > Region > Resource Category > ...)

  

• Hover over a target area for details, and click to isolate in the summary.

  

• Change the Timeline.

• Take advantage of Search | Show | Hide | Exclude.

Activity Panel: Summary

The Summary panel recapitulates the Visualization panel as an ordered list, organized by Severity level and impacted Rule Name.

• Click a line item to open the details. See at a glance the affected containers, images, rules, user names, etc.

  

• Take advantage of Search | Show | Hide | Exclude.

Cloud Activity Summary Panel

For AWS Cloud Activity, the summary also includes a link back to view the data in the AWS Console.

Activity Panel: Events

The Events panel replicates the Sysdig Secure Events feed. Click an entry in the time-based list to open its details.

Search | Show | Hide | Exclude

The Search bar works in conjunction with options in the Activity Summary.

• Each line of the Activity Summary includes the Show (=), Hide (!=) and Exclude options.

  • Show (=): Click Show to add that finding to the Search bar, and to the page URL. The Visualization will be targeted accordingly.

  • Hide (!=): Click Hide to filter that finding from the Visualization, adding the filter to the Search and the URL.

  • Exclude : Click Exclude to refetch the data without the excluded entry. This cuts down on noisy repetitious results (which in some cases could cause the 999-item limit to be exceeded).

  Note that Show and Hide do not trigger a re-fetch of data.

• Once you have excluded an entry, the Exclude icon is displayed in the Visualization header.

  

  • Click the icon to view the current exclusions.

  • Clear All Exclusions if desired.

Insights Team-Based Views and Sharing

Note:

• Your team and user role influence what Insights you have access to.

• The page URL persists search and filter items, and can be shared with team members with the same level of permissions.

See User and Team Administration for more detail.

3 -

Vulnerability Management

Understanding Vuln Management Stages

One key to designing your vulnerability management deployment and strategy is to understand the different lifecycle phases to be addressed:

Basic Concepts

• Vulnerabilities are present in the software that has been installed in the images during the build phase - when we define and assemble the image.
• A container image is immutable by definition. If we change the contents of an image, then it becomes a different image in practice (with different ImageID, etc.).
• Nevertheless, even if the image itself is immutable, Sysdig can discover new vulnerabilities contained in that image at any moment in time, given that the security feeds are constantly updated.
  • For example, an image that had no known vulnerabilities at build time may be impacted by a newly discovered critical vulnerability 10 days after entering runtime. The image itself is exactly the same, but the security feeds discovered a new piece of information related to the image’s software.

Pipeline and Runtime

Although the underlying algorithm to analyze the image contents (SBOM) and match vulnerabilities to it is basically the same, Sysdig treats images differently depending on whether they are located in a pipeline or being used as the base for a running container, also known as runtime workloads.

Pipeline

Any analysis conducted prior to the runtime phase is considered pipeline. This typically means CI/CD builds (Jenkins, Github, etc), but can also be just an execution of the sysdig-cli-scanner binary performed on a developer laptop or with a custom scanning script.

• Pipeline images do not have runtime context.
• The scan happens outside of the execution nodes where the agent is installed:
  • CI/CD
  • External instrumentation
  • Custom scripts or image scanning plugins
• Pipeline scans are one-off vulnerability reports; the information is a static snapshot with its corresponding execution date.
  • If you want to evaluate a never version of the image or just reevaluate the same image with newer feed information, the analysis needs to be triggered again.
• Images analyzed using the sysdig-cli-scanner will show up in the Pipeline section of the vulnerability management interface.

Runtime

Runtime workloads are executed from an image. Accessing the Runtime section of the Vulnerabilities menu, you will be able to see those images and their vulnerability and policy evaluation.

• Runtime workloads are located in an execution node and are being monitored by a Sysdig agent/node analyzer, for example a Kubernetes node that is instrumented using the Sysdig agent bundle.
• Runtime workloads will offer a live, auto-refreshing state. This means:
  • Workloads that are no longer running will be removed from the runtime view
  • Vulnerabilities and policies evaluations will automatically refresh without any user interaction, offering always the most up-to-date information known.
    • At least once per day
• Runtime workload have a runtime context associated with them, i.e. Kubernetes cluster and namespace.
• Workloads analyzed during runtime will show up in the Runtime section of the vulnerability management interface.

Vulnerabilities Features

Sysdig’s Vulnerabilities module addresses the top requirements for effective vulnerability management:

• Provides highly accurate views of vulnerability risk at scale

• Deep visibility into system calls provides high accuracy about active packages

• Rich details provide precision about vulnerability risk (ex. CVSS vector, score, fix age) and insights from multiple expert feeds (ex. VulnDB)

• Access to public exploits allows you to verify security controls and patch efficiently

• Prioritized risk data focused on the vulns that are tied to the packages loaded at runtime

Getting Started with Vulnerabilities

1. Ensure you have completed the Sysdig Secure deployment steps, so you have:

   • The correct Sysdig agent, which includes the vuln management engine and runtime scanner
   • The downloaded cli-scanner.

2. Log in to Sysdig Secure with Advanced User+ permissions and select Vulnerabilities.

   

   The out-of-the-box policies for Pipeline and Runtime vulnerabilities will work without further setup.

3. Choose Pipeline or Runtime to see the scanning results.

4. Choose Reporting to configure schedules for creating downloadable reports on runtime vulnerability results.

5. To create or edit Pipeline or Runtime Vuln Policies and Rule Bundles, select the relevant links from the Policies tab in the navigation bar.

   

Appendix: Supported Packages and Languages

Runtime

• Only Kubernetes Runtime for now, Hosts and Cloud infrastructure coming soon
• Supported container runtimes:
  • Docker daemon
  • ContainerD
  • CRI-O

Installation Options

• Helm chart
• Plain daemonset
  • Runtime scanner
  • Runtime scanner + benchmark runner

CI/CD

Supported Container Image Formats

• Docker Registry V2 - compatible
• Docker Daemon
• Podman
• Docker Archive (tar)
• OCI Archive

Supported Package Types

• Debian
• Alpine
• RHEL
• Ubuntu
• Java Maven
• Golang (built with go 1.13+)
• Pypi
• NPM (JS)
• Ruby Gems
• NuGet
• Cargo (Rust)

3.1 -

Pipeline

Introduction

The sysdig-cli-scanner tools allow you to manually scan a container image, either locally or from a remote registry. You can also integrate the sysdig-cli-scanner as part of your CI/CD pipeline or automations to automatically scan any container image right after it is built and before pushing to the registry scanner.

Development / CI/CD / Pipeline / Shift-Left / …: all of these terms refer to scanning performed on container images that are not (yet) executed in a runtime workload. You can scan these images using the sysdig-cli-scanner tool, and explore the results directly in the console or in the Sysdig UI.

Optionally, you can create additional pipeline scanning policies and rules.

The Pipeline section in Sysdig Secure will display the scan results for all images that are scanned using the sysdig-cli-scanner

For Runtime workloads, see how they are automatically scanned by the Sysdig Runtime Scanner.

Running the CLI Scanner

The sysdig-cli-scanner is a binary you can download and execute locally in your computer or environment. The steps to obtain and run the scanner are given in the Get Started page of the Sysdig Secure UI, and are recapped in this section.

Scanning images

1. Download latest version of sysdig-cli-scanner with:

• Linux:

  curl -LO "https://download.sysdig.com/scanning/bin/sysdig-cli-scanner/$(curl -L -s https://download.sysdig.com/scanning/sysdig-cli-scanner/latest_version.txt)/linux/amd64/sysdig-cli-scanner"
  

• MacOS:

  curl -LO "https://download.sysdig.com/scanning/bin/sysdig-cli-scanner/$(curl -L -s https://download.sysdig.com/scanning/sysdig-cli-scanner/latest_version.txt)/darwin/amd64/sysdig-cli-scanner"
  

2. Set the executable flag on the file:

   chmod +x ./sysdig-cli-scanner
   

   You only need to download and set executable once. Then:

3. You can scan images by running the sysdig-cli-scanner command:

SECURE_API_TOKEN=<your-api-token> ./sysdig-cli-scanner --apiurl <sysdig-api-url> <image-name>

See Parameters for more detail.

Integrating in your CI/CD Pipelines

The sysdig-cli-scanner can be included as a step in your CI/CD pipelines (i.e. Jenkins, Github actions or others) simply by running the sysdig-cli-scanner command as part of your pipeline.

• Make sure that the sysdig-cli-scanner binary is available as part of the worker or runner where the pipeline is executing.
  • If you are running an ephemeral environment in the pipeline, include the download and set executable steps in your pipeline to download the tool on every execution.
• Define a secret containing the API-Token and make it available in the pipeline (i.e. via a SECURE_API_TOKEN environment variable).
• Include a step in your pipeline to run the sysdig-cli-scanner after building the container image, and providing the image name as paremeter. For example:

./sysdig-cli-scanner --apiurl <sysdig-api-url> ${IMAGE_NAME}

See a Jenkins pipeline example

About CI/CD Policies

Policies allow you to define a set of rules that will evaluate each scan result. After the evaluation, each policy will pass or fail. A policy failure or non-compliance happens if the scan result doesn’t meet all the rules in a policy.

For CI/CD and manual image scans, you can tell the sysdig-cli-scanner tool to explicitly evaluate one or more policies using the --policy= policy1,policy2,... flag and provide a comma-separated list of policy IDs.

CI/CD policies can be configured as Always apply. If a policy has the Always apply flag, it will be evaluated on every scanned image even if you don’t specify it explicitly.

Learn more about Vulnerability Management policies, the available rules, and how to define policies in Vulnerability Policies.

Parameters

Basic usage of the sysdig-cli-scanner:

sysdig-cli-scanner [OPTIONS] <ImageName>

Required

• The Sysdig CLI scanner will try to find a local image in Docker, ContainerD or other container runtimes, or try to pull if from the remote registry.
• Once the scan is complete, you will see the results directly in the console, and they will be available in the Pipeline section of the UI.

Additional Parameters

Use the -h / --help flag to display a list of all available command line parameters:

Example

Usage:
  sysdig-cli-scanner [OPTIONS] [ImageName]

Application Options:
  -a, --apiurl=                 Secure API base URL
  -t, --apitimeout=             Secure API timeout (seconds) (default: 120)
      --output-json=            Output path of the scan result report in json format
  -s, --skiptlsverify           Skip TLS certificate verification (default: false)
  -u, --skipupload              Skip the scan results upload (default: false)
  -d, --dbpath=                 Database full path. By default it uses main.db.gz from the same directory
      --policy=                 Identifier of policy to apply
  -p, --cachepath=              Cache path
  -c, --clearcache              Clear the cache before to run (default: false)
  -l, --loglevel=               Log level (default: info)
  -o, --logfile=                File destination for logs, used if --console-log not passed
      --console-log             Force logs to console, --logfile will be ignored
      --full-vulns-table        Show the entire list of packages found
      --detailed-policies-eval  Show a detailed view of the policies evaluation

Help Options:
  -h, --help                    Show this help message

Arguments:
  ImageName:                    Image name

Image Sources

The Sysdig CLI scanner can load images from different sources. By default, it will try to automatically find the provided image name from all supported sources, in the order specified by the following list. However, you can explicitly select the image source by using the corresponding prefix for the image name:

• file:// - Load the image from a .tar file
• docker:// - Load the image from the Docker daemon (honoring DOCKER_HOST environment variable or other Docker configuration files)
• podman:// - Load the image from the Podman daemon
• pull:// - Force pulling the image from a remote repository (ignoring local images with same name)
• containerd:// - Load the image from Containerd daemon
• crio:// - Load the image from Containers Storage location

i.e. pull the image from remote registry even if it is locally available:

./sysdig-cli-scanner -a https://secure.sysdig.com pull://nginx:latest

Sample Result in Terminal

It is possible to view scan results in the terminal window (see below)

$ SECURE_API_TOKEN=<YOUR_API_TOKEN> ./sysdig-cli-scanner --apiurl https://secure.sysdig.com redis

Type: dockerImage
ImageID: sha256:7614ae9453d1d87e740a2056257a6de7135c84037c367e1fffa92ae922784631
Digest: redis@sha256:db485f2e245b5b3329fdc7eff4eb00f913e09d8feb9ca720788059fdc2ed8339
BaseOS: debian 11.2
PullString: pull:*//redis*

66 vulnerabilities found
8 Critical (0 fixable)
2 High (0 fixable)
4 Medium (0 fixable)
5 Low (0 fixable)
47 Negligible (0 fixable)

  POLICIES EVALUATION
  Policy: Sysdig Best Practices FAILED (9 failures)`

You can use --full-vulns-table or --detailed-policies-eval flags to include further details in the output.

For a more user-friendly scan result, find the image in the UI.

JSON Output

You can use the --output-json=/path/to/file.json to write a JSON report of the scan result

Scan Logs (for troubleshooting)

The sysdig-cli-scanner automatically writes a log file on every execution. You can change the output path using -o or --logfile flags. For troubleshooting purposes, you can change the log level by setting --loglevel=debug. This will increase the verbosity of the log messages to the debug level.

Review Pipeline Scans in the UI

You can explore the details for every image that has been scanned by executing the sysdig-cli-scanner in Sysdig Secure UI.

1. Navigate to Vulnerabilities > Pipeline.

   

2. Filter the list by Pass | Fail if desired.

   • The Policy Evaluation column reflects the policy state at evaluation time for that image and the assigned policies
     • Failed: If any of the policies used to evaluate the image is failing, the image is considered “Failed”
     • Passed If there is no violation of any of the rules contained in any of the policies, the image is considered “Passed”

From here you can drill down to the scan result details.

Drill into Scan Result Details

Select a result from the Pipeline list to see the details, parsed in different ways depending on your needs.

Overview Tab

Focuses on the package view and filters for those that are fixable. Clickable cells lead into the Vulnerabilities list (next).

Vulnerabilities Tab

Expanded filters and clickable list of CVEs that open the full CVE details, including source data and fix information.

The same security finding (e.g. a particular vulnerability) can be present in more than one rule violation table if it happens to violate several rules.

Content Tab

Also organized by package view, with expanded filters and clickable CVE cells.

Policies Tab

Shows CVEs organized by the policy+rule that failed. Use the toggle to show or hide policies+rules that passed. Click CVE names for the details.

Filter and Sort Results

Within the Pipeline results tabs, there are ways to further refine your view:

• Search by keyword or CVE name
• Use filters: Severity (>=); CVSS Score (>=); Vuln Type; Has Fix; Exploitable.

3.2 -

Runtime

Introduction

Sysdig Secure will automatically analyze and scan the container image for the workloads in your clusters, providing a list of vulnerabilities, policy evaluations and Risk Spotlight, helping you focus on fixing the active, critical and exploitable vulnerabilities.

In order to scan the workloads in your clusters, you need to make sure that the Sysdig Runtime Scanner component is deployed as part of your Agent deployment. Follow the Sysdig Agent Installation.

Why Runtime Scanning?

Although shifting vulnerability management to the earliest phases (such as integrating with CI/CD) is essential, runtime vulnerability management remains important:

• Strong defense: runtime VM provides an additional layer of defense to your arsenal
• Up-to-date: new vulnerabilities are discovered every day; new discoveries need to be checked against your running images
• Priorized feedback: The Risk Spotlight feature allows you to hone in on the most important vulnerabilities discovered within your running images so you can efficiently priorite and act.

Sysdig’s runtime scanner will:

• Automatically observe and report on all the Runtime workloads, keeping a close-to-real time view of images and workloads executing on the different Kubernetes scopes of your infrastructure
• Perform period re-scans, guaranteeing that the vulnerabilities associated with the Runtime workloads and images are up-to-date with the latest vulnerabilities feed databases. It will automatically match a newly reported vulnerability to your runtime workloads without requiring any additional user interaction.

Understanding the Runtime Workload and Labels

Runtime entities are associated using the concept of workload, defined by:

• A unique ImageID

• A set of labels describing the runtime context (Kubernetes in this case)

  

These workload labels are in the order: cluster > namespace > type > container

• Kubernetes cluster name, demo-kube-eks in the example above
• Kubernetes namespace name, example-voting-app above
• Kubernetes workload type deployment (or daemonset, etc.)
• Kubernetes container name, metrics-3 above

This means:

• Several replicas of the same deployment are considered the same workload (single entry on the table), as the images are identical and the runtime context is the same.
• An identical image deployed on two different Kubernetes clusters will be considered two different workloads, as the runtime context is different.

About Runtime Policies

Policies allow you to define a set of rules that will evaluate each workload. After the evaluation, each policy will pass or fail. A policy failure or non-compliance happens if the scan result doesn’t meet all the rules in a policy.

Runtime policies contain a runtime scope filter, so it only applies workloads in that scope, or Entire infrastructure, which will apply globally.

Learn more about Vulnerability Management policies, the available rules, and how to define policies in Vulnerability Policies

Review Runtime Scan Results

1. Navigate to Vulnerabilities > Runtime.

   

   By default, the entire infrastructure results are shown.

   Results are ranked by:

   • Number of actual exploits
   • Severity of vulnerabilities
   • Number of vulnerabilities

2. From here you can:

   • Use Risk Spotlight
   • Drill down to image details
   • Filter results

   to find and remediate the priority issues discovered.

Use Risk Spotlight

Risk Spotlight allows you to focus first on the packages containing vulnerabilities that are actually being executed at runtime. If an image has 180 packages and 160 have vulnerabilities, but only 45 are used at runtime, then much of the vuln notification noise can be reduced.

Click on an image entry to see the the Risk Spotlight panel and drill into the details, clicking on the vulnerabilities for details and examining the link to any known exploits that exist. (See also Drill into Image Details, below.)

To enable Risk Spotlight in your account, please contact your Sysdig representative. Risk spotlight must also be enabled during the Sysdig Agent installation.

Drill into Scan Result Details

Select a worload from the Runtime results list

Overview Tab

Focuses on the package view and top-priority running images (Risk Spotlight).

Clickable cells lead into the Vulnerabilities list (next).

Vulnerabilities Tab

Provides expanded filters and clickable list of CVEs that open the full CVE details, including source data and fix information.

Content Tab

Also organized by package view, with expanded filters and clickable CVE cells.

Policies Tab

Shows CVEs organized by the policy+rule that failed. Use the toggle to show or hide policies+rules that passed. Click CVE names for the details.

Filter and Sort Results

• Filter by workload labels and optionally save constructed filters as Favorite or Default from the kebab (3-dot) menu on the filter bar.

  • Hover over the workload labels and click = or =! to add them to the filter bar to refine by cluster, namespace, type, etc.

    

• Filter by evaluation: Pass / Fail / No Policy

  

• Click Risk Spotlight to list the results that have been evaluated for Risk first

• Use further-refined filters within the image detail tabs, e.g. CVE Name; Severity (>=); CVSS Score (>=); Has Fix; Exploitable.

  

3.3 -

Reporting

Introduction

Use the Vulnerability Reporting interface to schedule asynchronous reports about detected runtime vulnerabilities along with package and image data.

Here you can:

• Create a report definition
• Schedule its frequency
• Define notification channel(s) in which to receive the reports (email, Slack, or webhook)
• Preview how the data will appear (optional)
• Download the resulting reports in .csv, .json, or .ndjson

Create a Report Definition

1. Log in to Sysdig Secure with Advanced User or higher permissions, and select Vulnerabilities > Reporting.

   The Vulnerabilities Reporting list page is displayed. If you have previously created report definitions, you can click one to see the details.

   

2. Click Add Report . The New Report page is displayed.

3. Define the report basic info:

   • Name
   • Description
   • Export format: .csv, .json, or .ndjson
   • Scope: Entire infrastructure or subset from the drop-down menu

4. Optional: Add Conditions from the drop-down if you want to filter the items reported on.

   For example, you might want a report of all vulnerabilites with a Severity >= High, and for which a Fix is Available.

   The available conditions include:

   • Vulnerability ID
   • Image name
   • Package name
   • Package version
   • Package type
   • Severity
   • CVSS score
   • CVSS vector
   • Vuln publish date
   • Vuln fix date
   • Fix available
   • OS name

5. Define the Schedule (frequency and time of day) that the report should be run.

   Note: The schedule determines when the report data collection begins. As soon as evaluation is complete, you will receive a notification in the configured notification channels.

   

6. Notification Channel: If you have configured them, you can use email, Slack, or webhook notification channels, and they will appear in the drop-down. Since reports are typically large, the actual data is not sent to the notification channel; you receive a link to download it. You must be a valid Sysdig Secure user (Advanced User+) to access the link.

7. Data Preview: Click Refresh to apply the configuration you’ve chosen and pull up on the center bar of the Data Preview panel to see sample results.

8. Click Save.

Manage Reports

View and Edit Report Definition

1. Select an entry in the Reporting list to see the detail panel.

   

2. Click Edit to change the report definition parameters. You can also access this panel from the kebab (3-dot) menu.

   

3. Make your edits, click Refresh to see the Data Preview, and Save.

Download Reports

1. From the Reporting list, the latest report download link appears in the Download column.

   

2. To see older reports, select an entry in the Reports list to open the detail panel and select from the report download list.

   

3. The report will be downloaded in the format you defined; the file is zipped (.gz) – double-click to unzip and view.

Generate Report Manually

1. Select an entry in the Reporting list to see the detail panel.
2. Click Generate Now. A Scheduled entry will appear. Within 15 minutes or so it will change to Completed and you can download the manually generated report.

Duplicate a Report Definition

1. Choose the kebab (3-dot) menu for a scheduled report.
2. Click Duplicate.

Report Definition Retention

The scheduled and manually created reports are retained for 14 days.

Delete a Report Definition

Be sure to download any needed reports before deleting the definition.

1. Choose the kebab (3-dot) menu for a scheduled report.

2. Click Delete, click Yes when prompted.

   The report definition and all associated reports are deleted.

4 -

Posture

Sysdig is introducing enhanced security capabilities with a new Cloud Infrastructure Entitlements Management (CIEM) module. This feature allows organizations easily to identify areas in their cloud infrastructure with overly permissive access rights which could cause data breaches or other risks, and to quickly and easily update the related policies and user permissions as needed.

Along with this capacity, the compliance standards and benchmark checks have all been moved under the umbrella module, Posture.

Understand Each Component

You can jump directly to each of the three related areas:

• Compliance
• Identity and Access

4.1 -

Compliance

Customers running older versions of Sysdig Secure may encounter different interations of the Compliance UI and features, as well as the Benchmarks module, which in current versions has moved behind the scenes.

The documentation appropriate for your Compliance tools depends on the software version you are running.

• Actionable Compliance (Tech Preview): Offered for early review on May 31, 2022.

• Compliance (Unified): Since Jan. 26, 2022 in SaaS. See the Prerequisite components and agent version.

• Compliance (Legacy): Earlier SaaS version and all Onprem versions

• Benchmarks (Legacy) and Benchmarks (v1)

4.1.1 -

Actionable Compliance (Preview)

Introduction

Sysdig’s Compliance feature continues to evolve and Actionable Compliance represents the next phase of maturity, as well as the first to support CSPM/KSPM. In the backend, the Compliance module now relies on persisting the resources in an inventory vs the approach of fetching violations only. This enhanced visibility into the resources leads to full-context prioritization to drive remediation and resolve violations.

The validator tool continues to check selected controls from the various compliance standards, and new standards are added regularly.

What’s New with Actionable Compliance

• Scheduled Reports vs Stream of Violations

  • The previous architecture was built on a Reports model. Users define a report schedule for various compliance benchmarks/standards and these reports are triggered and collated at the defined intervals. Each report is run independently and retrieves the violations for the specific scope on the specific compliance framework/benchmark.

  • Now the various endpoints are evaluated against compliance policies and the violations are reported in an ongoing stream, then collected into tiles, or “views” on the Compliance Views page. The new approach relies on the common process of fetching the resources (of any relevant kind) into the backend and performing the relevant analysis of policies of any kind of any scope.

  • At this time, Sysdig provides the policies behind the scenes and runs the checks once per day.

• Click into the resource itself, rather than a list of violations

• Remediation provided, including opening a PR in the development pipeline if IaC integration is enabled.

• Variety of terminology changes

Typical Use Cases

Compliance/Security Team Members

Will want to:

• Check current compliance status against predefined policies
• Demonstrate to an auditor the compliance status in a specific point in time (the audit)
• Create a report on the predefined policies and send it to the management team
• Understand the magnitude of the compliance gap

DevOps Team Members

Will want to:

• Identify the compliance violations of a predefined policy
• Manage the violations according to their severity
• Be told by the solution what needs to be done to fix the violation
• Be able to easily fix the violation
• Document exceptions and accept risk when desirable

Path from Detection to Remediation

Below is a quick overview of how users work through the Actionable Compliance screens to detect prioritized vulnerabilities, analyze them, and remediate.

1. Get high-level posture performance indicators (PPIs) on each of the pre-defined policies/filters.

   Review the Compliance Views screen.

   

2. Select a Policy to get Results and select a failing requirement to see the Controls that comprise it.

3. Next to the resource appears a Start Remediation link that opens the Remediation panel.

4. Begin remediation (where possible). The remediation flow allows you to understand exactly what the issue is, to review the suggested patch that Sysdig created specifically for the problem, and choose how to apply the patch (manually or in the development pipeline).

   • Manually, you can copy the patch code and apply it in production.
   • To remediate in the CICD pipeline, you can choose the relevant GitHub source and the Actionable Compliance will create a pull request integrating the patch (as well as checking for code formatting cleanup). You can review all the changes in the PR before you merge.

The rest of the page describes the screens and actions in detail.

Enable Actionable Compliance UI

Prerequisites

• Agent upgrade

  It is necessary to upgrade the agents with the following parameters (i.e. in Helm):

  --set nodeAnalyzer.kspmAnalyzer.deploy=true 
  --set kspmCollector.deploy=true
  

  See also the Install Agent section of Get Started in the product interface, or the Quick Install docs for more context.

• Remediation integrated with Git pull requests (optional)

  To take advantage of PR-integrated remediation, you will need to have IaC Security enabled.

When these prerequisites are met, the UI for actionable compliance will be populated with your environment’s content.

Usage

Navigate Compliance Overview

1. Select Posture > Actionable Compliannce | Compliance Views.

2. Review the compliance posture Overview. Each row or tile is a view filtering compliance results.

   

   All Results are always listed first.

   The rest of the tiles are ordered alphabetically until custom filters are applied.

   • Views and Scope: This is the lens through which the compliance results are organized– a policy plus a scope. By default, the scope is Entire Infrastructure.

   • Passing Score: The number of requirements passing for this policy view, expressed as a percent. The higher the better.

   • Requirements Failing: The number of requirements remaining to fix to get to 100% for a view, listed as a bar chart of the past 7 days’ results. The smaller the number, the better. Requirements are made up of one or more controls, so requirements will be the smaller number.

   • Controls to Fix: The number of controls to fix to achieve a perfect score. The smaller the better. (Multiple controls make up a single requirement, so control count will be larger than requirement count).

   • Resources Passing: The percent of resources passing (or accepted) out of all resources evaluated. Resources are the most granular of your results. The higher the percentage, the fewer individual resources failing, the better.

   • Violations by Severity: Every control has a Severity (high/medium/low). Resource Violations are the number of resources failing, organized by severity. One resource can be counted multiple times if it’s failing multiple controls. The lower, the better.

3. Select a tile to drill into the results of a particular policy.

Access and Filter Results

1. From the Compliance Views page, select a particular tile to see the Results page.

   

   The failed requirements are sorted by severity and importance.

2. You can filter by:

   • Policy (type or choose from drop-down)
   • Requirement name and number (type or choose from drop-down)
   • Severity (High/Medium/Low)
   • Failing or Passing Requirements

   

Evaluate and Remediate

The remediation solutions are under continued development in the product. At this time, remediations are for a single resource for a single violation. Several types of remediation are supported:

• Static: Playbook text to remediate the violation is presented
• Manually apply patch: (with or without user input) Patch code is presented, with an input field if new values are required, and the user downloads the patch and copy/pastes the patch application code.
• Set up a Pull Request:(with or without user input) Patch code is presented, with an input field if new values are required, and the user opens a PR.

Drill Down to the Control Pane

From the Results page, open a requirement to see the individual failing controls. Click a control to open the Control pane on the right.

Here you can see:

• An explanation of the control
• An overview of all resources that have passed and failed, and
• A list of the actual resources.

Resources and their Attributes (Kubernetes)

These are the resources to which the controls are applied.

• Host
  • Status
  • Name
  • Cluster
  • OS
  • OS Image
• Workload
  • Status
  • Name
  • Type: Deployment, Daemonset, StatefulSet, ReplicaSet, Pod, Job, CronJob
  • Cluster
  • Namespace
  • Labels
• Identity Object
  • Status
  • Name
  • Type: ServiceAccount, User, System Group\Builtin Group, Role, ClusterRole
  • Cluster
  • Namespace

Filters in the Control Pane

The Control pane shows the top 50 results. Use filters to find anything outside that limit.

You can construct filter expressions in the Control pane on all resource fields:

Remediation: How Do Source Detection and Patching Work?

Source Detection

Sysdig tries to match a source with a specific resource to create a pull request. If it can’t find a match, then use the search field to manually explore for files in a relevant GitHub repository.

Patching and Pull Requests (PRs)

Some remediation flows are more static, others are interactive, where Sysdig presents a patch. This can be applied manually to production, or via a Pull Request in the CI/CD pipeline if that has been configured in IaC.

When a Pull Request is opened, Sysdig applies the corrective patch. You can review all the recommended changes in the PR before you merge it.

Review the Remediation Pane

Select a Resource to open the Remediation pane on the right. This pane will differ depending on what is detected.

If a remediation path is found, IaC integration has been set up, and a pipeline source has been detected, then the full remediation pane will be displayed.

Review Issues

Here you check the impact of the remediation, review the resource attributes, and, if relevant, enter a necessary Value that will be incorporated into the patch code.

If a required value can be autodetected, it will be auto-inserted and the Value input field will be read-only.

Check the Patch

The Patch code will be presented for review when there is a patch that can be applied manually or used in a Pull Request to remediate the IaC file. In most cases, it is recommended to download the code in the Continue Remediation section, but you can also copy/paste it.

Continue Remediation - Manual

If you have not integrated your pipeline PRs with Sysdig’s IaC Scanning, or if creating a pull request is not required in a particular resource failure, then you can perform remediation manually.

Use the button to download the patch and the provided code to apply it.

Continue Remediation - Pull Request

If IaC Scanning has been configured on your system, then Sysdig will analyze the manifests defined in the Git sources to scrape resources from it and match them to evaluated deployed resources. The process will run and analyze the resources daily, and if a new git source is added

When the manifest(s) and resources are matched, then the Source is displayed in the Remediation pane.

You can also search manually for sources by their full URL path..

Use the button to Create a Pull Request and evaluate it in your repo (e.g. Github).

• Workflow Name Selector for Helm/Kustomize:

  What is it: you select a source of type Helm/Kustomize, you can type a selector for the workload name. Why: In Helm, in most cases, workload names are derived from the release name, which means that they change with every new release. The selector is a regular expression that matches workloads by prefix/suffix (or a more complex pattern). With that selector in place, the remediation can be ussed for the workloads generated from the same chart, regardless of the release.

  

Appendix

Terminology Changes

Policies Included

For the tech preview, the following policies are included behind the scenes:

• CIS Distribution Independent Linux v2.0.0
• CIS Docker v1.3.1
• CIS Kubernetes v1.6.0
• CIS Kubernetes 1.20 v1.0.0
• CIS Kubernetes 1.23 v1.0.0
• CIS Kubernetes 1.51
• CIS EKS v1.0.1
• CIS GKE v1.1.0
• CIS AKS v1.1.0
• Sysdig Kubernetes - a custom policy based on Sysdig’s security research and best practices

Coming soon:

• OpenShift 3.11 v1.2.1
• CIS OpenShift 4 v1.1.0

4.1.2 -

Compliance (Unified)

The Compliance module in Sysdig Secure is comprised of a validator tool that checks selected controls from various compliance standards, and the reports it compiles. New standards are being added regularly. The validator checks many Sysdig Secure features, including: image scanning policies, Falco runtime policies and rules, scheduled benchmark testing, Admission Controller, Network Security Policies, Node Image Analyzer, and more. Over time we will add new compliance coverage.

Disclaimer: Sysdig cannot check all controls within a framework, such as those related to physical security.

In Jan. 2022, Sysdig Secure has unified and simplified the Compliance interface.

From a single page, you can now:

• Scope all types of reports

  • Scope across both host and cloud* platforms (workload*, Kubernetes, AWS, GCP, etc.)

  • Select any or all compliance frameworks (CIS AWS, CIS Azure, NIST, HIPAA, etc.)

  • Fine-tune selections by compliance framework version

    

• Create/Enable/Disable reports

  • Schedule a new report task for any of the available frameworks or platforms
  • Enable/disable existing tasks

• Review all scheduled tasks and the resulting reports

  • At-a-glance summary of compliance status across the entire environment

  • Click-down from the summary to review pass/fail/remediation details

    

• Benchmark tasks are now treated as just another compliance task, within the same interface

  • No need to configure or reference the Legacy Benchmarks module once unified compliance is switched on

*Terminology note: Compliance standards are scoped to different platforms depending on the specific security rules they include. Broadly, these are divided into:

• Workload types: Including any Falco rules for kernel system calls, Falco rules for Kubernetes audit logs, host benchmarks, and security features that affect hosts, containers, and kubernetes clusters

• Cloud type: Falco rules for CloudTrail and Cloud Custodian rules on AWS, or for GCP, Azure, and other cloud providers as they are added.

Enable Unified Compliance UI

Prerequisites

• Agent version >= 12.0.4

  If necessary, install or upgrade your agent to the appropriate version.

• Node analyzer installed

When these two prerequisites are met, the new UI for unified compliance will be automatically deployed.

NOTE: If you are upgrading from an earlier version of Sysdig Secure, your existing compliance and benchmark records will be migrated to the new version and retained on the same schedule as before.

Use Compliance Reports

Access the Compliance Module

Click the Posture icon in the left-hand navigation and select either All Platforms or an individual platform under Compliance.

Schedule New Task

1. Click +Schedule New from the top-right corner of a Compliance landing page, or choose Posture > New Report from the nav bar.

2. Choose the desired framework from the list presented and click Schedule.

   

   (Note that if a framework already has a scheduled task, you can view that report from here as well.)

3. Configure the report details:

   

   • Report Name: Assign a name to the scheduled task
   • Framework: Auto-filled from the selection you made, or choose a different framework
   • Version: Select from the drop-down as needed
   • Platform: Only applicable options will appear in the drop-down menu, based on the framework chosen
   • Scope: Select Entire Infrastructure or an appropriate subscope from the drop-down menu
   • Schedule: Choose Daily, Weekly, or Monthly and the time at which the task should be run and the report generated.

4. Click Schedule Report. At the designated schedule, the task will run and the report will be displayed on the Compliance landing page.

Use Compliance Reports

Review a Report

1. Navigate to the Compliance list from the Posture menu.

2. Select a report from the list to view the Report details. The top section of the page presents the compliance report summary, with the Pass|Fail summary data.

   

   Report Date: Themost current report is displayed; select a different date/time from the drop-down to see an earlier version.

3. Expand relevant details: For example, click any Failing Controls in the summary at the top of the page and then expand to review the resources that are failing and find the suggested fixes.

   

Frameworks and Controls Implemented

AWS Foundational Security Best Practices v1 (FSBP) Compliance

The AWS Foundational Security Best Practices standard is a set of controls that detect when your deployed accounts and resources deviate from security best practices. The standard allows you to continuously evaluate all of your AWS accounts and workloads to quickly identify areas of deviation from best practices. It provides actionable and prescriptive guidance on how to improve and maintain your organization’s security posture. The controls include best practices from across multiple AWS services.

For AWS protection, Sysdig Secure will check the following sections: AutoScaling.1, CloudTrail.1, Config.1, EC2.6, CloudTrail.2, DMS.1, EC2.1, EC2.2, EC2.3, ES.1, IAM.1, IAM.2, IAM.4, IAM.5, IAM.6, IAM.7, Lambda.2, GuardDuty.1

AWS Well Architected Framework Compliance

The AWS Well Architected Framework helps cloud architects build secure, high-performing, resilient, and efficient infrastructure for a variety of applications and workloads. Built around six pillars—operational excellence, security, reliability, performance efficiency, cost optimization, and sustainability—AWS Well-Architected provides a consistent approach for customers and partners to evaluate architectures and implement scalable designs.

For workload protection, Sysdig Secure will check the following sections: OPS 4, OPS 5, OPS 6, OPS 7, OPS 8, SEC 1, SEC 5, SEC 6, SEC 7, REL 2, REL 4, REL 5, REL 6, REL 10, PERF 5, PERF 6, PERF 7

For AWS protection, Sysdig Secure will check the following sectionsOPS 6, SEC 1, SEC 2, SEC 3, SEC 8, SEC 9, REL 2, REL 9, REL 10

FedRAMP Compliance

FedRAMP is a government-wide program that promotes the adoption of secure cloud services across the federal government by providing a standardized approach to security and risk assessment for cloud technologies and federal agencies. FedRAMP empowers agencies to use modern cloud technologies, with an emphasis on security and protection of federal information.

For workload protection, Sysdig Secure will check the following sections: AC-2, AC-2(4), AC-2(12), AC-6(1), AC-6(2), AC-6(3), AU-2, AU-6, AU-10, AU-12, CM-3(6), CM-7, CM-7(1), SA-10, SC-8, SC-8(1), SI-3, SI-4(4)

For AWS protection, Sysdig Secure will check the following sections: AC-2, AC-2(4), AU-8, SC-8(1)

For Google Cloud protection, Sysdig Secure will check the following sections: AC-6(1), AC-6(2), AC-6(3), AU-9(2), AU-12(1), CM-3(1), SC-7(4)

For Azure protection, Sysdig Secure will check the following sections: AC-2, AU-8

GDPR Compliance

The General Data Protection Regulation 2016/679 (GDPR) is a regulation for data protection and privacy in the European Union (EU) and the European Economic Area (EEA). It also addresses the transfer of personal data outside the EU and EEA areas.

For workload protection, Sysdig Secure will check the following sections: 5.1, 5.2, 24.1, 24.2, 24.3, 25.1, 25.2, 25.3, 32.1, 32.2, 40.2

For AWS protection, Sysdig Secure will check the following sections: 5.1, 5.2, 24.1, 24.2, 24.3, 25.1, 25.2, 25.3, 30.1, 30.2, 30.3, 30.4, 30.5, 32.1, 32.2, 40.2

For Google Cloud protection, Sysdig Secure will check the following sections: 25.1, 25.2, 25.3, 32.1, 32.2

For Azure protection, Sysdig Secure will check the following sections: 25.1, 25.2, 25.3, 32.1, 32.2

HIPAA Compliance

The Health Insurance Portability and Accountability Act (HIPAA) sets the standard for protecting sensitive patient data. Companies dealing with Protected Health Information (PHI) must have and comply with physical, network, and technology security measures to maintain HIPAA compliance. Any entity providing health care treatment, payment, and operations, as weel as any entity who has access to patient information and provides support for treatment, payment, or operations must comply with HIPAA requirements. Other organizations such as subcontractors and any other related business partners must also comply.

For workload protection, Sysdig Secure will check the following sections: 164.308(a)(1)(ii)(D), 164.308(a)(3)(i), 164.308(a)(3)(ii)(A), 164.308(a)(3)(ii)(B), 164.308(a)(4)(i), 164.308(a)(4)(ii)(A), 164.308(a)(4)(ii)(B), 164.308(a)(4)(ii)(C), 164.308(a)(5)(ii)(B), 164.308(a)(5)(ii)(C), 164.310(a)(2)(iii), 164.310(b), 164.312(a)(1), 164.312(a)(2)(i), 164.312(a)(2)(ii), 164.312(a)(2)(iv), 164.312(b), 164.312(c)(1), 164.312(c)(2), 164.312(d), 164.312(e)(2)(i), 164.312(e)(2)(ii)

For AWS protection, Sysdig Secure will check the following sections: 164.308(a)(1)(ii)(D), 164.308(a)(3)(i), 164.308(a)(3)(ii)(A), 164.308(a)(3)(ii)(B), 164.308(a)(4)(i), 164.308(a)(4)(ii)(A), 164.308(a)(4)(ii)(B), 164.308(a)(4)(ii)(C), 164.308(a)(5)(ii)(B), 164.308(a)(5)(ii)(C), 164.308(a)(8), 164.310(b), 164.312(a)(1), 164.312(a)(2)(i), 164.312(a)(2)(ii), 164.312(b), 164.312(c)(1), 164.312(c)(2), 164.312(e)(2)(i)

For Google Cloud protection, Sysdig Secure will check the following sections: 164.310(b), 164.312(b), 164.312(d)

HITRUST CSF v9.4.2 Compliance

The HITRUST Common Security Framework (CSF) provides the structure, transparency, guidance, and cross-references to authoritative sources organizations globally need to be certain of their data protection compliance. It leverages nationally and internationally accepted security and privacy-related regulations, standards, and frameworks–including ISO, NIST, PCI, HIPAA, and GDPR–to ensure a comprehensive set of security and privacy controls and continually incorporates additional authoritative sources. The HITRUST CSF standardizes these requirements, providing clarity and consistency and reducing the burden of compliance.

For workload protection, Sysdig Secure will check the following sections: 01.b, 01.c, 01.i, 01,j, 01.k, 01.l, 01.m, 01.n, 01.o, 01.p, 01.q, 01.s, 01.v, 01.w, 01.x, 01.y, 03.d, 05.i, 06.h, 06.i, 06.j, 09.b, 09.i, 09.j, 09.k, 09.m, 09.n, 09.s, 09.v, 09.w, 09.x, 09.y, 09.z, 09.aa, 09.ab, 09.ac, 09.ad, 09.ae, 10.c, 10.d, 10.g, 10.h, 10.j, 10.k, 10.m, 11.a, 11.b

For AWS protection, Sysdig Secure will check the following sections: 01.c, 01.i, 01.p, 01.s, 01.v, 01.x, 01.y, 05.i, 06.i, 09.m, 09.v, 09.x, 09.ac, 09.af, 10.j, 11.b

For Google Cloud protection, Sysdig Secure will check the following sections: 01.c, 01,j, 01.n, 01.q, 01.y, 05.i, 06.d, 06.j, 09.m, 09.s, 10.g, 10.k

For Azure protection, Sysdig Secure will check the following sections: 01.x, 09.m, 09.ac, 09.af, 11.b

ISO 27001:2013 Compliance

The ISO/IEC 27001:2013 is an international standard on how to manage information security. It details requirements for establishing, implementing, maintaining and continually improving an information security management system (ISMS).

For workload protection, Sysdig Secure will check the following sections: A.6.1.2, A.8.1.1, A.8.1.2, A.8.1.3, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.10.1.1, A.12.1.2, A.12.4.1, A.12.5.1, A.12.6.1, A.12.6.2, A.13.1.1, A.13.1.2, A.13.1.3, A.14.1.2, A.14.2.2, A.14.2.4, A.18.1.3, A.18.1.5

For AWS protection, Sysdig Secure will check the following sections: A.6.1.2, A.9.1.1, A.9.1.2, A.9.2.3, A.9.2.5, A.9.4.2, A.9.4.3, A.10.1.1, A.10.1.2, A.12.1.2, A.13.1.1, A.14.1.2, A.18.1.3, A.18.1.5

For Google Cloud protection, Sysdig Secure will check the following sections: A.6.1.2, A.9.1.2, A.9.2.3, A.10.1.2, A.18.1.3, A.18.1.5

For Azure protection, Sysdig Secure will check the following sections: A.9.1.2, A.9.4.2, A.10.1.1, A.13.1.1, A.14.1.2, A.18.1.3, A.18.1.5

NIST 800-53 rev4 and rev5 Compliance

The National Institute of Standards and Technology (NIST) Special Publication 800-53 revision 4 describes the full range of controls required to pass a NIST 800-53 audit.

For workload protection, Sysdig Secure will check the following sections: AC-2, AC-2(4), AC-2(12), AC-3, AC-4, AC-4(17), AC-6, AC-6(1), AC-6(2), AC-6(3), AC-6(5), AC-6(6), AC-6(9), AC-6(10), AC-14, AC-17, AC-17(1), AC-17(3), AC-17(4), AU-2, AU-6, AU-6(8), AU-10, AU-12, CA-9, CM-3, CM-3(6), CM-5, CM-7, CM-7(1), CM-7(4), IA-3, SA-10, SA-15(10), SC-2, SC-4, SC-7, SC-7(3), SC-7(10), SC-8, SC-8(1), SC-12(3), SC-17, SC-39, SI-3, SI-3(1), SI-3(2), SI-4, SI-4(2), SI-4(4), SI-4(11), SI-4(13), SI-4(18), SI-4(20), SI-4(22), SI-4(23), SI-4(24), SI-7, SI-7(3), SI-7(9), SI-7(11), SI-7(12), SI-7(13), SI-7(14), SI-7(15)

For AWS protection, Sysdig Secure will check the following sections: AC-2, AC-2(4), AC-4, AC-6, AC-6(9), AU-6(8), AU-8, CA-7, CM-6, SC-8(1), SI-4, SI-12

For Google Cloud protection, Sysdig Secure will check the following sections: AC-6(1), AC-6(2), AC-6(3), AC-6(5), AC-6(9), AC-6(10), AC-17(1), AC-17(2), AC-17(3), AU-6(8), AU-9(2), AU-12(1), CM-3(1), IA-2(12), SC-7(3), SC-7(4), SC-7(5), SC-7(8), SC-7(21), SC-12(1)

For Azure protection, Sysdig Secure will check the following sections: AC-2, AU-8, SI-4

Special Publication 800-53 revision 5 was published in September 2020 and includes some modifications. For 12 months both revisions will be valid, and revision 4 will be deprecated in September 2021.

For workload protection, Sysdig Secure will check the following sections: AC-2, AC-2(4), AC-2(12), AC-3, AC-4, AC-4(17), AC-6, AC-6(1), AC-6(2), AC-6(3), AC-6(5), AC-6(6), AC-6(9), AC-6(10), AC-14, AC-17, AC-17(1), AC-17(3), AC-17(4), AC-17(10), AU-2, AU-6, AU-6(8), AU-10, AU-12, CA-3(6), CA-7(4), CA-7(5), CA-9, CM-3, CM-3(6), CM-3(7), CM-3(8), CM-4, CM-4(2), CM-5, CM-5(1), CM-7, CM-7(1), CM-7(4), CM-7(6), CM-7(7), CM-7(8), CM-8, CM-11(3), IA-3, MA-3(5), MA-3(6), PM-5(1), RA-3(4), RA-10, SA-10, SA-15(10), SA-23, SC-2, SC-4, SC-7, SC-7(3), SC-7(10), SC-7(25), SC-7(26), SC-7(27), SC-7(28), SC-7(29), SC-8, SC-8(1), SC-12(3), SC-17, SC-39, SC-50, SI-3, SI-4, SI-4(2), SI-4(4), SI-4(11), SI-4(13), SI-4(18), SI-4(20), SI-4(22), SI-4(23), SI-4(24), SI-4(25), SI-7, SI-7(3), SI-7(9), SI-7(12), SI-7(15)

For AWS protection, Sysdig Secure will check the following sections: AC-2, AC-2(4), AC-4, AC-6, AC-6(9), AU-6(8), AU-8, SC-8(1), SI-4

For Google Cloud protection, Sysdig Secure will check the following sections: AC-6(1), AC-6(2), AC-6(3), AC-6(5), AC-6(9), AC-6(10), AC-17(1), AC-17(2), AC-17(3), AU-6(8), AU-9(2), AU-12(1), CM-3(1), IA-2(12), SC-7(3), SC-7(4), SC-7(5), SC-7(8), SC-7(21), SC-12(1)

For Azure protection, Sysdig Secure will check the following sections: AC-2, AU-8, SI-4

NIST 800-82 rev2 Compliance

The National Institute of Standards and Technology (NIST) Special Publication 800-82 revision 2 provides guidance on how to secure Industrial Control Systems (ICS), including Supervisory Control and Data Acquisition (SCADA) systems, Distributed Control Systems (DCS), and other control system configurations such as Programmable Logic Controllers (PLC), while addressing their unique performance, reliability, and safety requirements.

For workload protection, Sysdig Secure will check the following sections: AC-2, AC-2(4), AC-2(12), AC-3, AC-4, AC-6, AC-6(1), AC-6(2), AC-6(3), AC-6(5), AC-6(9), AC-6(10), AC-17, AC-17(1), AC-17(3), AC-17(4), AU-2, AU-6, AU-10, AU-12, CA-9, CM-3, CM-5, CM-7, CM-7(1), IA-3, SA-10, SC-2, SC-4, SC-7, SC-7(3), SC-8, SC-8(1), SC-17, SC-39, SI-3, SI-3(1), SI-3(2), SI-4, SI-4(2), SI-4(4), SI-7, SI-7(14)

For AWS protection, Sysdig Secure will check the following sections: AC-2, AC-2(4), AC-4, AC-6, AC-6(9), AU-8, SC-8(1), SI-4.

For Google Cloud protection, Sysdig Secure will check the following sections: AC-6(1), AC-6(2), AC-6(3), AC-6(5), AC-6(9), AC-6(10), AC-17(1), AC-17(2), AC-17(3), AU-9(2), AU-12(1), CM-3(1), IA-2(12), SC-7(3), SC-7(4), SC-7(5), SC-7(8), SC-7(21), SC-12(1)

For Azure protection, Sysdig Secure will check the following sections: AC-2, AU-8, SI-4

NIST 800-171 rev2 Compliance

The National Institute of Standards and Technology (NIST) Special Publication 800-171 revision 2  provides agencies with recommended security requirements for protecting the confidentiality of Controlled Unclassified Information (CUI) when the information is resident in nonfederal systems and organizations.

For workload protection, Sysdig Secure will check the following sections:3.1.1, 3.1.2, 3.1.3, 3.1.5, 3.1.6, 3.1.7, 3.1.12, 3.1.13, 3.1.14, 3.1.15, 3.1.16, 3.1.17, 3.1.20, 3.3.1, 3.3.2, 3.3.5, 3.3.8, 3.3.9, 3.4.3, 3.4.5, 3.4.6, 3.4.7, 3.4.9, 3.5.1, 3.5.2, 3.11.2, 3.12.1, 3.13.1, 3.13.2, 3.13.3, 3.13.4, 3.13.5, 3.13.6, 3.13.8, 3.14.1, 3.14.2, 3.14.3, 3.14.4, 3.14.5, 3.14.6, 3.14.7

For AWS protection, Sysdig Secure will check the following sections:3.1.1, 3.1.2, 3.1.3, 3.3.1, 3.3.2, 3.3.7, 3.5.7, 3.5.8, 3.14.6, 3.14.7

For Azure protection, Sysdig Secure will check the following sections: 3.1.1, 3.1.2, 3.3.7, 3.14.6, 3.14.7

NIST 800-190 Compliance

The National Institute of Standards and Technology (NIST) Special Publication 800-190  explains the potential security concerns associated with the use of containers and provides recommendations for addressing these concerns.

For workload protection, Sysdig Secure will check the following sections: 3.1.1, 3.1.2, 3.1.3, 3.1.4, 3.1.5, 3.2.1, 3.2.2, 3.3.1, 3.3.2, 3.3.3, 3.3.4, 3.3.5, 3.4.1, 3.4.2, 3.4.3, 3.4.4, 3.4.5, 3.5.2, 3.5.5

PCI DSS v3.2.1

The PCI Data Secirity Standard (DSS) Quick Reference describes the full range of controls required to pass a PCI 3.2 audit. In this release, Sysdig Secure will check the following subset:

For workload protection: 1.1.2, 1.1.3, 1.1.5, 1.1.6.b, 2.2, 2.2.a, 2.2.1, 2.2.2, 2.4, 2.6, 4.1, 6.1, 6.2, 6.4.2, 6.5.1, 6.5.6, 6.5.8, 7.2.3, 10.1, 10.2, 10.2.1, 10.2.5, 10.2.7, 10.5.5, 11.5.1

For AWS protection, Sysdig Secure will check the following sections: 2.2, 2.2.2, 10.1, 10.2.1, 10.2.2, 10.2.5, 10.2.6, 10.2.7, 10.5.5, 11.4

For Google Cloud protection, Sysdig Secure will check the following sections: 1.1.5, 7.1.2, 10.1, 10.2, 10.3

For Azure protection, Sysdig Secure will check the following sections: 2.2.2

SOC2

The American Institute of CPAs (AICPA) describes the full range of controls required to pass a SOC 2 audit.

For workload protection, Sysdig Secure will check the following sections: CC3.2, CC5.1, CC5.2, CC6.1, CC6.2, CC6.6, CC6.8, CC7.1, CC7.2, CC7.5, CC8.1, CC9.1

For AWS protection, Sysdig Secure will check the following sections: CC3.2, CC5.2, CC6.2, CC6.6, CC7.1, CC7.2

For Google Cloud protection, Sysdig Secure will check the following sections: CC5.2, CC6.1, CC6.2, CC6.6, CC7.1, CC8.1

For Azure protection, Sysdig Secure will check the following sections: CC5.2, CC6.1, CC6.6, CC7.2, CC8.1

4.1.3 -

Compliance (Legacy)

The Regulatory Compliance module in Sysdig Secure is comprised of a validator tool that checks selected controls from various compliance standards, and the reports it compiles. New standards are being added regularly. At this time, checks are provided against specific controls in:

• PCI/DSS 3.2.1

• SOC2

• NIST 800-53 rev4 and NIST 800-53 rev5

• ISO 27001:2013

• HIPAA

• GDPR

The validator checks many Sysdig Secure features, including: image scanning policies, Falco runtime policies and rules, scheduled benchmark testing, Admission Controller, Network Security Policies, Node Image Analyzer, and more. Over time we will add new compliance coverage.

Disclaimer: Sysdig cannot check all controls within a framework, such as those related to physical security.

Terminology note: Compliance standards are scoped to different platforms depending on the specific security rules they include, Broadly, these are divided into:

• Workload types: Including any Falco rules for kernel system calls, Falco rules for Kubernetes audit logs, host benchmarks, and security features that affect hosts, containers, and kubernetes clusters

• AWS/cloud type: Falco rules for CloudTrail and Cloud Custodian rules on Amazon Web Services

Use Compliance Reports

Access the Compliance Module

1. Sysdig Secure admin: Enable the feature under Settings > Sysdig Labs.

2. Click the Posture icon in the left-hand navigation and select AWS or Workloads under Regulatory Compliance.

Review a Report

Each of the standards controls is checked when you visit the Compliance page and it always shows the current state in your environment.

Compliance Report Summary

The top section of the page presents the compliance report summary, with the Pass|Fail summary data.

• Pass %: Total percentage of all available checks that have passed

• Passed: Total number of controls implemented that Sysdig was able to validate

• Failed: Total number of controls not implemented that Sysdig was able to validate

• Unchecked: Total number of controls that Sysdig configured to check but unable to validate (i.e. unavailable API at the time of validation)

• Total Controls: Total number of controls Sysdig is configured to check

Control Report and Common Fixes

The controls are grouped together under collapsable sections of “control families.”

Open them to see each control description with a link to either the:

• Proof: Link to the implemented Sysdig feature that permitted the control to pass, or the

• Remediation: Link to the Sysdig feature that must be implemented to pass a check within the control

The Rationale is the reason an implemented Sysdig feature will pass a check within the control.

The Common Fixes section on the left consolidates the links for enabling Sysdig features in order to pass the control checks.

Control Details

PCI Controls Implemented

The PCI Quick Reference describes the full range of controls required to pass a PCI 3.2 audit. In this release, Sysdig Secure will check the following subset:

For PCI 3.2.1 workload protection: 1.1.2, 1.1.3, 1.1.5, 1.1.6.b, 2.2, 2.2.a, 2.2.1, 2.2.2, 2.4, 2.6, 4.1, 6.1, 6.2, 6.4.2, 6.5.1, 6.5.6, 6.5.8, 7.2.3, 10.1, 10.2, 10.2.1, 10.2.5, 10.2.7, 10.5.5, 11.5.1

For PCI DSS v3.2.1 for AWS Sysdig Secure will check the following sections: 2.2, 2.2.2, 10.1, 10.2.1, 10.2.2, 10.2.5, 10.2.6, 10.2.7, 10.5.5, 11.4

SOC2 Controls Implemented

The American Institute of CPAs (AICPA) describes the full range of controls required to pass a SOC 2 audit.

For workload protection, Sysdig Secure will check the following sections: CC3.2, CC5.1, CC5.2, CC6.1, CC6.2, CC6.6, CC6.8, CC7.1, CC7.2, CC7.5, CC8.1, CC9.1

For AWS protection, Sysdig Secure will check the following sections: CC3.2, CC5.2, CC6.2, CC6.6, CC7.1, CC7.2.

NIST 800-53 rev4 and rev5 Controls Implemented

The National Institute of Standards and Technology (NIST) Special Publication 800-53 revision 4 describes the full range of controls required to pass a NIST 800-53 audit.

For workload protection, Sysdig Secure will check the following sections: AC-2, AC-2(4), AC-2(12), AC-3, AC-4, AC-4(17), AC-6, AC-6(1), AC-6(2), AC-6(3), AC-6(5), AC-6(6), AC-6(9), AC-6(10), AC-14, AC-17, AC-17(1), AC-17(3), AC-17(4), AU-2, AU-6, AU-6(8), AU-10, AU-12, CA-9, CM-3, CM-3(6), CM-5, CM-7, CM-7(1), CM-7(4), IA-3, SA-10, SA-15(10), SC-2, SC-4, SC-7, SC-7(3), SC-7(10), SC-8, SC-8(1), SC-12(3), SC-17, SC-39, SI-3, SI-3(1), SI-3(2), SI-4, SI-4(2), SI-4(4), SI-4(11), SI-4(13), SI-4(18), SI-4(20), SI-4(22), SI-4(23), SI-4(24), SI-7, SI-7(3), SI-7(9), SI-7(11), SI-7(12), SI-7(13), SI-7(14), SI-7(15)

For AWS protection, Sysdig Secure will check the following sections: AC-2, AC-2(4), AC-4, AC-6, AC-6(9), AU-6(8), AU-8, CA-7, CM-6, SC-8(1), SI-4, SI-12.

Special Publication 800-53 revision 5 was published in September 2020 and includes some modifications. For 12 months both revisions will be valid, and revision 4 will be deprecated in September 2021.

For workload protection, Sysdig Secure will check the following sections: AC-2, AC-2(4), AC-2(12), AC-3, AC-4, AC-4(17), AC-6, AC-6(1), AC-6(2), AC-6(3), AC-6(5), AC-6(6), AC-6(9), AC-6(10), AC-14, AC-17, AC-17(1), AC-17(3), AC-17(4), AC-17(10), AU-2, AU-6, AU-6(8), AU-10, AU-12, CA-3(6), CA-7(4), CA-7(5), CA-9, CM-3, CM-3(6), CM-3(7), CM-3(8), CM-4, CM-4(2), CM-5, CM-5(1), CM-7, CM-7(1), CM-7(4), CM-7(6), CM-7(7), CM-7(8), CM-8, CM-11(3), IA-3, MA-3(5), MA-3(6), PM-5(1), RA-3(4), RA-10, SA-10, SA-15(10), SA-23, SC-2, SC-4, SC-7, SC-7(3), SC-7(10), SC-7(25), SC-7(26), SC-7(27), SC-7(28), SC-7(29), SC-8, SC-8(1), SC-12(3), SC-17, SC-39, SC-50, SI-3, SI-4, SI-4(2), SI-4(4), SI-4(11), SI-4(13), SI-4(18), SI-4(20), SI-4(22), SI-4(23), SI-4(24), SI-4(25), SI-7, SI-7(3), SI-7(9), SI-7(12), SI-7(15)

For AWS protection, Sysdig Secure will check the following sections: AC-2, AC-2(4), AC-4, AC-6, AC-6(9), AU-6(8), AU-8, SC-8(1), SI-4.

NIST 800-171 rev2 Compliance

The National Institute of Standards and Technology (NIST) Special Publication 800-171 rev2  describes the full range of controls required to pass a NIST 800-171 audit. It provides agencies with recommended security requirements for protecting the confidentiality of Controlled Unclassified Information (CUI) when the information is resident in nonfederal systems and organizations.

For workload protection, Sysdig Secure will check the following sections:3.1.1, 3.1.2, 3.1.3, 3.1.5, 3.1.6, 3.1.7, 3.1.12, 3.1.13, 3.1.14, 3.1.15, 3.1.16, 3.1.17, 3.1.20, 3.3.1, 3.3.2, 3.3.5, 3.3.8, 3.3.9, 3.4.3, 3.4.5, 3.4.6, 3.4.7, 3.4.9, 3.5.1, 3.5.2, 3.11.2, 3.12.1, 3.13.1, 3.13.2, 3.13.3, 3.13.4, 3.13.5, 3.13.6, 3.13.8, 3.14.1, 3.14.2, 3.14.3, 3.14.4, 3.14.5, 3.14.6, 3.14.7

For AWS protection, Sysdig Secure will check the following sections:3.1.1, 3.1.2, 3.1.3, 3.3.1, 3.3.2, 3.3.7, 3.5.7, 3.5.8, 3.14.6, 3.14.7

ISO 27001:2013 Controls Implemented

The ISO27001:2013 standard describes the full range of controls required to pass an ISO27001:2013 audit. 

For workload protection, Sysdig Secure will check the following sections: A.6.1.2, A.8.1.1, A.8.1.2, A.8.1.3, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.10.1.1, A.12.1.2, A.12.4.1, A.12.5.1, A.12.6.1, A.12.6.2, A.13.1.1, A.13.1.2, A.13.1.3, A.14.1.2, A.14.2.2, A.14.2.4, A.18.1.3, A.18.1.5

For AWS protection, Sysdig Secure will check the following sections: A.6.1.2, A.9.1.1, A.9.1.2, A.9.2.3, A.9.2.5, A.9.4.2, A.9.4.3, A.10.1.1, A.10.1.2, A.12.1.2, A.13.1.1, A.14.1.2, A.18.1.3, A.18.1.5.

HIPAA Controls Implemented

The HIPAA (Health Insurance Portability and Accountability Act) standard describes the full range of controls required to pass an HIPAA audit. 

For workload protection, Sysdig Secure will check the following sections: 164.308(a)(1)(ii)(D), 164.308(a)(3)(i), 164.308(a)(3)(ii)(A), 164.308(a)(3)(ii)(B), 164.308(a)(4)(i), 164.308(a)(4)(ii)(A), 164.308(a)(4)(ii)(B), 164.308(a)(4)(ii)(C), 164.308(a)(5)(ii)(B), 164.308(a)(5)(ii)(C), 164.310(a)(2)(iii), 164.310(b), 164.312(a)(1), 164.312(a)(2)(i), 164.312(a)(2)(ii), 164.312(a)(2)(iv), 164.312(b), 164.312(c)(1), 164.312(c)(2), 164.312(d), 164.312(e)(2)(i), 164.312(e)(2)(ii)

For AWS protection, Sysdig Secure will check the following sections: 164.308(a)(1)(ii)(D), 164.308(a)(3)(i), 164.308(a)(3)(ii)(A), 164.308(a)(3)(ii)(B), 164.308(a)(4)(i), 164.308(a)(4)(ii)(A), 164.308(a)(4)(ii)(B), 164.308(a)(4)(ii)(C), 164.308(a)(5)(ii)(B), 164.308(a)(5)(ii)(C), 164.308(a)(8), 164.310(b), 164.312(a)(1), 164.312(a)(2)(i), 164.312(a)(2)(ii), 164.312(b), 164.312(c)(1), 164.312(c)(2), 164.312(e)(2)(i).

GDPA Controls Implemented

The General Data Protection Regulation 2016/679 (GDPR) is a regulation for data protection and privacy in the European Union (EU) and the European Economic Area (EEA). It also addresses the transfer of personal data outside the EU and EEA areas.

For workload protection, Sysdig Secure will check the following sections: 5.1, 5.2, 24.1, 24.2, 24.3, 25.1, 25.2, 25.3, 32.1, 32.2, 40.2

For AWS protection, Sysdig Secure will check the following sections: 5.1, 5.2, 24.1, 24.2, 24.3, 25.1, 25.2, 25.3, 30.1, 30.2, 30.3, 30.4, 30.5, 32.1, 32.2, 40.2

AWS Well Architected Framework Compliance

The AWS Well Architected Framework whitepaper defines best practices to build secure, high-performing, resilient, and efficient infrastructure for applications and workloads.

For workload protection, Sysdig Secure will check the following sections: OPS 4, OPS 5, OPS 6, OPS 7, OPS 8, SEC 1, SEC 5, SEC 6, SEC 7, REL 2, REL 4, REL 5, REL 6, REL 10, PERF 5, PERF 6, PERF 7

For AWS protection, Sysdig Secure will check the following sectionsOPS 6, SEC 1, SEC 2, SEC 3, SEC 8, SEC 9, REL 2, REL 9, REL 10

AWS Foundational Security Best Practices v1 (FSBP) Compliance

AWS Foundational Security Best Practices v1 (FSBP) describes the full range of controls to detect when your deployed accounts and resources deviate from security best practices.

For AWS protection, Sysdig Secure will check the following sections: AutoScaling.1, CloudTrail.1, Config.1, EC2.6, CloudTrail.2, DMS.1, EC2.1, EC2.2, EC2.3, ES.1, IAM.1, IAM.2, IAM.4, IAM.5, IAM.6, IAM.7, Lambda.2, GuardDuty.1

4.1.4 -

Benchmarks (Legacy)

Navigate the Benchmark Tasks Landing Page

Select Posture > Benchmark|Tasks. The Tasks landing page is displayed.

A “task” is the combination of benchmark test (schema), scheduled to run on a particular scope at a scheduled time. Once a task is configured, it is listed on the landing page and is linked to the full benchmark report.

For new users: If no tasks have been created yet, you will be prompted to create some.

For users who had Benchmark v1 tasks configured:

• v1 tasks will be migrated to v2.

• You can still view all v1 schedules and reports from the View Legacy Benchmarks button, if desired. Modifications to v1 after this point will not be propagated.

On this page you can:

• Enable/disable a task. Note that if you have Sysdig Secure for cloud installed then the AWS Foundations Benchmark task is listed for information but is handled differently than the other task types.

• Filter the list by scope or task type to find the task more easily

• Click a task to access the full benchmark report

Benchmark Components details

Types of Benchmark Schemas

The Center for Internet Security (CIS) issues standardized benchmarks, guidelines, and best practices for securing IT systems and environments. Additionally, Redhat publishes a Container Security Guide that outlines best practices for running Openshift 3.10/3.11 clusters.

With v2, Sysdig supports the following types of benchmarks tests/schemas:

Understanding Benchmark Scopes

When you Configure Benchmark Tasks , the available scope depends on the schema you choose.

4.1.4.1 -

Configure Benchmark Tasks

Use a Benchmark Task to define:

• the type of benchmark test to be run

• the scope of the environment to be checked

• the scheduled test frequency

• the list of controls to be included/excluded. Use this to silence noisy or unfixable controls that you’ve determined are not useful.

Once a task has been set up, it will run tests automatically on the scheduled timeline. You can also trigger the task manually.

Create a Task

1. Select Compliance > Benchmark|Tasks.

   The Task benchmark landing page is displayed.

   

2. Click+Add Taskand define the task parameters on the New Task page:

   

   • Name: Create a meaningful name.

   • Schema: Select the appropriate schema type from the drop-down menu. See Types of Benchmark Schemas for details.

   • Schedule: Choose a frequency and time to run the test. Benchmarks can be scheduled Daily, Weekly or Monthly, on designated days at a specific time. A single task cannot be scheduled more frequently than once per day.

   • Scope: Choose from the available scoping options, which are auto-filtered based on the chosen schema. See also: Understanding Benchmark Scopes.

   • Custom Report: De-select any of the controls you don’t want run in the test or view in the report.

3. Click Save.

The task will appear on the Tasks landing page along with the date and time it was last run. Click the task to review the report.

Trigger a Task Manually

Rather than wait for the next scheduled time for a task to run, users can choose to run a benchmark test manually.

1. Select Compliance > Benchmark|Tasks.

2. On the relevant task, click the Run Now (arrow) icon.

   

   A notification will state that the test was successfully run.

4.1.4.2 -

AWS Foundations Benchmarks

Overview

The CIS Amazon Web Services Foundations Benchmark v 1.3.0 forms one part of Sysdig’s comprehensive Cloud Security Posture Management (CSPM) and Compliance tools. The AWS CIS Benchmarks assessment evaluates your AWS services  against the benchmark requirements and  returns the results and remediation activities you need to fix misconfigurations in your cloud environment.

We’ve included several UI improvements to provide additional details such as:  control descriptions, affected resources, failing assets, and guided remediation steps, both manual and CLI-based when available.

Enable CIS AWS Foundations Benchmarks

Prerequisites

• Sysdig Secure (SaaS)

• Workloads running in the AWS environment, including EKS, Fargate, etc. for which you want to verify best security practices and compliance

Deploy: using a simple CloudFormation Template in the AWS Console. See Deploy Sysdig Secure for cloud on AWS

Using AWS Foundations Benchmarks

The checks and reports for AWS Benchmarks differ from Host Benchmarks in the following ways:

• No scheduling: The check is automatically deployed daily; the user does not choose a particular schedule, nor to “run now.”

• Tasks and Reports combined:

  There is a single page displaying:

  • The chosen AWS account, region, and date when report date

  • The curated list of controls that are run (left panel)

  • The daily report, with its pass/fail details and any recommended remediation steps

Reviewing an AWS CIS Report

1. Log in to Sysdig Secure and select Compliance > AWS Foundations Benchmark.

   

2. Select the relevant report:

   Account id: From the drop-down menu, choose one of the accounts where you deployed the CFT and enabled the AWS Benchmarks feature.

   Region: Choose the AWS region of the account you want to check (not necessarily the region where your Sysdig Secure is installed)

   Date: Choose a report date. Checks are run once per 24 hours.

3. Review the daily report (right panel).

   Note the following:

   • % of Resources Passed: Of the controls implemented by Sysdig, this is the percentage that passed.

   • Resources Passing: Every control checks multiple resources (e.g., hundreds of S3 buckets, etc.). This figure displays an aggregated count of all the resources over all the controls.

   • Resources Failing: Choose this figure to review a consolidated list of all failed controls with their remediation recommendations.

4.1.4.3 -

Review Benchmark Results

Click a listed task to review the full report, check Pass|Fail status, discover remediation steps, and/or download the report as a CSV file.

1. Log in to Sysdig Secure and select Compliance > Benchmark|Tasks and select one of the task line items.

   If you have installed Sysdig Secure for cloud, AWS Foundations Benchmarks are listed on Tasks page, but are handled differentlyfrom the rest of the Host Benchmark results.

   A benchmark report is displayed.

   

2. From the report page, you can do the following:

   • Summary: Review the Summary (left panel) to see every control and its result

   • Date: Choose the test run from a different date. Use the date drop-down to see historical results of this report.

   • Sort and list: by which resources passed/failed the test. Click the Resources Passed/ Resources Failed links to filter the results accordingly.

3. Drill down to review details and remediate.

   

   After sorting, e.g., by Resources Failed , you can review the control details including the recommended Remediation Procedure.

4. Optional: Download as CSV using the button at the top of the page.

4.1.4.4 -

Benchmarks (v1)

The Center for Internet Security (CIS) issues standardized benchmarks, guidelines, and best practices for securing IT systems and environments. Additionally, Redhat publishes a Container Security Guide that outlines best practices for running Openshift 3.10/3.11 clusters.

Sysdig Secure includes implementations of four of these benchmarks that can be run against your environment:

• CIS Docker 1.2

• CIS Kubernetes 1.3/1.4/1.5

• CIS Distribution Independent Linux 1.1.0

• Redhat Container Security Guide 3.10/3.11

These benchmarks are available to run via 3 separate program types:

• Docker Benchmark: for CIS Docker

• Kubernetes Benchmark: For CIS Kubernetes and Redhat Container Security Guide

• Linux Benchmark: for CIS Distribution Independent Linux

How Sysdig Benchmark Tests Work

CIS benchmarks are best practices for the secure configuration of a target system. Sysdig has implemented these standardized controls for different versions of Kubernetes, Linux, and Docker.

Setting Up a Task

Using a new Task, configure the type of test, the environment scope, and the scheduled frequency of the compliance check. You can also filter how you’d like to view the Results report. See also Configure Benchmark Tasks (v1) .

Running a Test

Once a task is configured, Sysdig Secure will:

• Kick off a check in the agent to analyze your system configuration against CIS best-practices

• Store the results of this task

Reviewing Report Results

When a task has run, it is listed on the Results page and can be viewed as a Report.

Reviewing Benchmark Metrics

Consolidated Benchmark metrics can also be viewed in Sysdig Monitor, from default or customized Compliance Dashboards.

Understanding Report Filters

Customize your view of the test report, e.g., to see only high-priority results or the results from selected controls.

Note that the filter may affect only your view of the report (before agent version 9.7.0), or may actually determine of the test (after agent version 9.7.0). See also: About Custom Selections.

In older versions to filter a report, under Report on the Benchmark Task page:

• Choose Custom Selection

• Choose a Benchmark version and

  • apply a Profile filter, and/or

  • select/deselect individual controls.

Use the information in this section to understand the effect of your selections.

About Custom Selections

Filtering rules apply to the report, not the test itself.

• The full test will run but the result view will be edited.

• If you apply a filter to an existing task that has already run, the filter view will be retroactively applied to the historical reports.

• If you deselect the filter, the full results will again be visible.

About Benchmark Versions

CIS issues benchmark versions that correspond to –- but are not identical with – the Kubernetes or Docker software version. See the mapping tables, below.

Kubernetes Version Mapping

Note: CIS 1.0, 1.1, and 1.2 are deprecated.

Sysdig also supports Kubernetes benchmark tests for the following distributions:

• IBM IKS: IBM Kubernetes Service

  Note: Running CIS benchmarks against IKS may result in some failures or false positives due to the way IBM deploys certain components. Read more from IBM.

• Rancher RKE: Rancher Kubernetes Engine

  Note: Running CIS benchmarks against RKE may result in some failures or false positives due to the way Rancher deploys certain components. Read more from Rancher.

Linux Bench Versions

The Linux Benchmarks (e.g. 2.0 and 1.1) should both run on any Linux distribution; it is not necessary to map to a particular distro.

Docker Version Mapping

About Profile Levels

CIS defines two levels of tests, as described below.

In Sysdig Secure, full benchmarks are always run, but you can filter your view of the report to see only top-priority (Level 1 Profile) or only the secondary (Level 2 Priority) results.

From the CIS FAQ:

• Level 1 Profile: Limited to major issues

  Considered a base recommendation that can be implemented fairly promptly and is designed to not have an extensive performance impact. The intent of the Level 1 profile benchmark is to lower the attack surface of your organization while keeping machines usable and not hindering business functionality.

• Level 2 Profile: Extensive checks, more complete

  Considered to be “defense in depth” and is intended for environments where security is paramount. The recommendations associated with the Level 2 profile can have an adverse effect on your organization if not implemented appropriately or without due care.

  In the Sysdig Secure interface, select All to view an in-depth report that includes both Level 1 and Level 2 controls.

  Select Level 1 to view a report that includes only high-priority controls.

  Select Level 2 to view a report that includes only the lower-priority controls that are excluded from Level 1.

  See also: Configure Benchmark Tasks (v1) .

4.1.4.4.1 -

Configure Benchmark Tasks (v1)

Use a Benchmark Task to define:

• the type of benchmark test to be run

• the scope of the environment to be checked

• the scheduled test frequency

• the format in which you want to view the results report.

Once a task has been set up, it will run tests automatically on the scheduled timeline. You can also trigger the task manually.

Schedule an Automated Benchmark Test

Create a Task

1. From the Benchmarks module, select the Schedule icon.

   The Schedule list (of existing tasks) is displayed.

   

2. Click +Add Task and define the task parameters on the New Task page:

   

   • Name: Create a meaningful name.

   • Type: Select Docker Benchmark , Kubernetes Benchmark, or Linux Benchmark, despending on your environment.

   • Schedule: Choose a frequency and time to run the test.

   • Scope: Choose Everywhere, or narrow the scope as needed.

     (See also Grouping, Scoping, and Segmenting Metrics .)

   • Report: Select how you want to view the test results in the report.

     • All Tests: means that no filter will be applied to the Report.

       Sysdig will automatically apply the correct version of the benchmark test for your environment, based on the version of Kubernetes or Docker where the agent is installed.

     • Custom Selection: LEGACY: means that you will Filter Report Results .

       After agent 9.7.0, the custom selection also defines what parts of the test will run.

3. Click Save.

Filter Report Results

Note that the full CIS benchmark test will be run, even when the Report view is filtered.

1. From the Benchmarks module, select the Schedule icon and either select or create a Task.

   The Task configuration page is displayed.

   

2. For Report, choose Custom Selection.

3. Choose the appropriate CIS benchmark version from the drop-down menu (based on the Type chosen).

   See About Benchmark Versions for details.

4. Filter results as desired.

   1. Optional: Choose a Profile Level (1 or 2).

      Select Profile Level 1 to view only high-vulnerability results.

      Select Profile Level 2 to view only the lower-level results that were excluded from Level 1.

      Select All (no profile filter) to view complete results.

      See also: About Profile Levels.

   2. Optional: Select/deselect individual controls as desired.

   3. Optional: Select All to clear previous selections and begin again.

5. Click Save.

Edit a Scheduled Task

1. From the Benchmarks module, select the Schedule icon.

   The list of scheduled tasks is displayed.

2. Select a task from the list and edit.

   Changing the Report filter settings for a task that has already been run will retroactively filter the existing report views.

3. Click Save.

Delete a Scheduled Task

1. From the Benchmarks module, select the Schedule icon.

2. On the relevant task, click the More Options (three dots) icon.

   

3. Select Delete task and click Yes to confirm (or No to revert the change).

Trigger a Manual Benchmark Test (Run Now)

Rather than wait for the next scheduled time for a benchmark test to run, users can choose to run a benchmark test manually.

1. From the Benchmarks module, select the Schedule icon.

2. On the relevant task, click the Run Now (arrow) icon.

   

   A notification will state that the test was successfully run.

3. Return to the Results tab and refresh the page after several minutes to see the results.

4.1.4.4.2 -

Review Benchmark Test Results (Legacy)

When you have configured Benchmark tasks to run tests, each task run produces a listing connected to a report. This page describes the features associated with the Results list and associated Report pages, described below..

Using the Results List

The Benchmarks landing page is also the Results list, where each completed result report is linked.

From this page you can:

• Access Reports

• Create/access Tasks from the Schedule icon

• Search for **Report **listings by Task name from the search bar

• Link to Dashboards and their associated metrics in Sysdig Monitor

Note: If a test fails altogether, an error log is listed instead of a Report link.

On Kubernetes tests, the results list will also display the Kubernetes master node, which can be helpful for identification:

Using the Results Report

Click an entry in the Results list to open the corresponding Results Report.

You can:

• Review the Pass/Fail/Warn results of each compliance control

• Check remediation suggestions on Warn/Fail results

• Download the report as a CSV file if needed

Sample Kubernetes report. (See also: https://www.cisecurity.org/benchmark/kubernetes/ )

Check Remediation Tips

Remediation tips provide a general summary of what is usually required to resolve an issue. This information is not environment-specific and should be used as a guide, rather than specific configuration instructions.

Access Remediation tips from the Wrench icon next to a Warn or Fail entry in a Report.

Remediation information is included in downloaded CSV reports as well.

Download Report as a CSV File

From a Report page, click Download CSV.

4.1.4.4.3 -

Use Compliance Dashboards and Metrics (Legacy)

Links to the Compliance Dashboards in Sysdig Monitor are provided from the Results list in the Sysdig Secure Benchmarks module.

Compliance Dashboards

Sysdig provides Compliance & Security Dashboards as part of Sysdig Monitor:

• Compliance (K8s)

• Compliance (Docker)

Sample Docker compliance dashboard:

Sample Kubernetes compliance dashboard:

Compliance Metrics

A number of compliance metrics for both Kubernetes and Docker are available to view in Sysdig Monitor dashboards. These metrics are documented in full in the Metrics Dictionary and are available here: Compliance.

4.2 -

Identity and Access

As cloud services proliferate, so do user access policies, and a majority of enterprises use overly permissive policies that create large attack surfaces and significant security risks. With Sysdig’s Identity and Access module (I&A) for cloud accounts, you can review and mitigate these risks in minutes.

Understanding Identity and Access

In Sysdig Secure for cloud, Identity and Access work together with Compliance and Benchmark tools under the Posture navigation tab in the Sysdig Secure menu.

Analysis: From this interface you can quickly acertain risks from two different angles:

User-Focused Risks

• Users and roles with excessive permissions
• Inactive users that can be removed
• Unnecessary permissions

Resource-focused Risks

• Who can access a resource
• Any suspicious cloud resource activity from a user with excessive permissions
• Recent permissions changes

Remediation: From there, the tool can suggest an improved policy, based on users’ actual activity, which you can immediately paste into your AWS policy in the linked AWS console.

Understanding the Suggested Policy Changes

When you find a user or a policy with excessive permissions, there are two suggested types of remediations:

• Global Policy Change: In this case, you click a targeted policy (e.g. AdministratorAccess) from either:

  • The policy link on a user’s panel, or
  • The Optimize Policy button on a policy panel

  A revised policy is suggested based on the activities of all users in the system that have been granted this entitlement.

  

  You would copy the suggested code into your existing policy in the AWS console.

• User-Specific Policy: In this case, when investigating an individual user entry, you click Generate User-Specific Policy and a policy is suggested based on a combination of all policies and activities detected for that user.

  

  You would copy the suggested code into a new user policy in your AWS console.

Understanding the Wildcard Warnings

The Policies list page flags policies that include wildcards for Action or Resource. By default, all recommended or optimized policies from Sysdig will remove the Action wildcards.

Because Sysdig cannot detect the Resources deployed, it cannot automatically remediate Resource wildcards in policy code.

Understanding Learning Mode and Disconnected States

Sysdig’s IAM page shows helpful information about cloud accounts and indicates several states for each registered account:

• Learning Mode: A cloud account is in learning mode when the account was connected less than 90 days prior. This ensures that the user activity has been profiled for a meaningful amount of time.

• Disconnected: A cloud account is in disconnected state if either of these events occur:

  • Cloud-Connector stops sending events. The timestamp shows the time the last events were received
  • The role provisioned on the customer’s AWS account cannot be impersonated

Prerequisites

• Sysdig Secure for cloud for AWS, installed with Terraform
• Adequate AWS permissions to edit policies related to users, roles, and access

Limitations

• Currently only the identity-based policies (managed, inline, and group policies) are considered for permission calculation. Resource-based, permission boundaries, organization SCPs, ACLs, and Session policies are not yet accounted for during permission calculations.

  More details on these policies here.

• Two notes about the data displayed:

  • AWS Last seen timeis based on GetServiceLastAccessedDetails. For more information, see Amazon’s documentation.
  • The AWS permissions used by IAM identities is based on user activity observed in Cloudtrail logs. Currently, permissions used after assuming roles is not taken into account.

Access the Overview

1. Log in to Sysdig Secure.
2. Select Posture >Identity and Access|Overview.
3. Review the global Permissions posture from the various panels and use the filtered links to access the Users and Policies subpages as needed.

Filter by Account

On each page in the I&A section, all users and resources are listed by default. If desired, you can focus on a single cloud account, using the Accounts drop-down at the top of the page.

Review Unused Permissions

Total Permissions Usage

See at a glance the number of permissions that have been granted vs those that have actually been used. Click on the Used and Given links to see the related Policies list and remediate those with the highest number of unused permissions.

Users

See at a glance the number of active vs inactive users. Clicked on the Active and Inactive links to see the related Users and Roles lists and to remediate.

Average Permissions Per Policy

See at a glance the average number of permissions granted per policy. per account, and click into the Policies list to remediate.

Average Policies Per User

See at a glance the average number of policies a user is associated with, per account and click into the Users and Roles list to remediate.

Policies with Unused Permissions

The Inventory section orders the Policies, Users, and Roles with the greatest number of unused permissions at the top of the list. Click to expand the lists and remediate.

Users and Roles with Unused Permissions

The Inventory section orders the Policies, Users, and Roles with the greatest number of unused permissions at the top of the list. Click to expand the lists and remediate.

Users and Roles

The Identity and Access| Users and Roles page provides numerous ways to sort, filter, and rank the detected user and role information and to quickly remediate permissions in policies.

Filter and Sort

Available filters:

• By account, by just users, by just roles
• By unused permissions vs inactive users and roles

Each column in the table can be sorted to help target, for example, the users with the highest number of granted permissions or the highest percentage of unused permissions.

Analyze and Remediate

To reduce the entitlements for a particular user or role:

1. Click on a user or role to open the detail pane.

   In the screenshot example above, the user has actually triggered only 1 of the 10,471 permissions issued, and is associated with five different policies. Full AdministratorAccess has not been needed for the job the user has been performing.

2. Decide whether to Generate a User-Specific policy that takes into account all the policies and permissions this users has employed, or whether to use the Suggested Policy for e.g., AdministratorAccess, globally. See: Understanding the Suggested Policy Changes.

3. Copy the generated policy and paste it into a policy in your AWS console.

Policies

The Identity and Access| Policies page currently displays AWS policies only. Other cloud vendors will be added over time.

Filter and Sort

As with the Users and Roles page, you can filter by account, and each column in the table is sortable.

The most common sorting priorities are:

• By Unused % or Unused Permissions: Immediately target the policies with the greatest exposure and refine them according to the suggestions

• By Shared Policy (# of Users): Focus on the policies affecting the greatest number of users and make a global policy change

• By Wildcard warning: The Policies list specifically calls out the security risks posed by policies containing Resource or Action Wildcards. The suggested policies eliminate Action wildcards.

  See also: Understanding the Wildcard Warnings.

Analyze and Remediate

To reduce the entitlements globally for a particular policy:

1. Click on a policy name to open the detail pane.

   

2. Click Optimize Policy and review the proposed code.

3. You can copy (then paste), download (then upload), or open the adjusted policy directly in the AWS console and save.

Posture Resources

The Resources page will be further developed in future releases.

At this time, you can use the S3 Bucket information to see all the S3 buckets currently set to Public and switch them to Private in the AWS console as needed. Similarly, the Lambdas are displayed with their public/private setttings.

Download CSV

Each page of the Identity and Access module has a Download CSV button for retrieving the page data in a spreadsheet.

Note: If your Chrome browser is set to disallow downloading multiple files from a site, you may only get one CSV download and then a “blocked” message in the Chrome address bar. You can click the message to access and change that browser setting, if desired.

5 -

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:

• Runtime Policy Tuning (Threat Detection) for reducing noisy false positives in the events feed
• Image Profiles to automate creation of image-specific policies
• Beta Policy Advisor to automate creation of Kubernetes pod security policies (PSPs)
• Network Security Policy Tool to author and fine-tune Kubernetes network policiess

5.1 -

Vulnerability Policies

Overview

Sysdig includes scanning policies for both Pipeline and Runtime vulnerabilites 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.

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.

       

5.2 -

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.

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 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:

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

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 in time and applying algorithms.

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

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

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.

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

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

• Manage Policies

• Manage Rules

5.3 -

Manage TD Policies

Overview

Review Understanding Sysdig Secure Policies, if needed. Remember that rules are not actionable until they are added to a runtime policy. At minimum, this means:

• Using a default or creating a policy, either manually or using one of the optional tools to help automate policy creation

• Defining the basic parameters, such as scope and severity levels

• Adding rules

• Defining the policy actions to be taken when rules are breached, such as: sending an event to a notification channel (PagerDuty, Slack, email..); triggering a capture file; and/or taking action on the container (stop/kill/pause).

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

Deploy a Default Policy

The first time you access the Policies tab, you will be prompted to load the Sysdig default policies.

The policies are loaded with pre-defined enabled/disabled status, based on most common usage, but you can enable, disable, copy, edit, or delete each one as needed.

Reload Default Policies

You can use the sdc-cli to fetch any new runtime policies that Sysdig has released since you installed, or to overwrite any of your existing runtime policies with the current Sysdig defaults.

• To fetch new policies, run:

  sdc-cli policy update-default

  This will not overwrite any of your existing runtime policies.

• To revert selected existing policies to the Sysdig default:

  1. Delete the policy.

  2. Run sdc-cli policy update-default

• To revert all existing policies to the Sysdig defaults:

  1. Delete all policies with

     sdc-cli policy del `sdc-cli policy list | awk 'NR>1 {print $1}'`

  2. Run sdc-cli policy update-default

Create a Policy

To create a policy manually:

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

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

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

3. Add the rules and the actions to be taken if the policy rules are breached.

4. Enable and Save the policy.

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.

Copy, Edit 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.

Note that policies are only auto-installed when the default policies are loaded first time. If you delete a default policy and subsequently upgrade, that policy will not be recreated.

5.4 -

Manage TD Rules

Review Understanding Sysdig Secure Rules to get started.

Access the Rules Library

1. Select Policies > 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.

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

5.5 -

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.

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.

5.5.1 -

The Falco Rules Tuner (Legacy)

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

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.

Apply Recommended Tuning to Rules

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.

5.6 -

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.

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:

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

5.7 -

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.

5.8 -

[Beta] Policy Advisor

Sysdig Secure has introduced a tool for enhanced Kubernetes security called the Policy Advisor. At this time, it is used exclusively for Kubernetes Pod Security Policies.

[Beta] Pod Security Policies (PSP)

According to Kubernetes, “A Pod Security Policy [PSP] is a cluster-level resource that controls security-sensitive aspects of the pod specification. The PodSecurityPolicy objects define a set of conditions that a pod must run with in order to be accepted into the system, as well as defaults for the related fields.”

See more here: Kubernetes PSP documentation.

With Sysdig’s Kubernetes Policy Advisor, you can auto-generate Pod Security Policies and perform dry tests or “simulations” of them before you commit them to an environment. These features offer several benefits:

• PSPs help enforce least-privilege to strengthen security

• Auto-generation can significantly decrease the time spent configuring Kubernetes policies

• Simulation tests help teams tune their PSPs to avoid false positives, and help them avoid breaking applications during PSP deployments

Understand the PSP Workflow

In general, you will generate a PSP, run a simulated test, review the results, tune the PSP as needed, then turn off the simulator and add the pod security policy to the actual deployment.

Prerequisites

• Sysdig Secure v. 3.0+ and Sysdig Agent v. 93.0+ on Kubernetes

• You must enable Kubernetes Audit Logging in Sysdig

Terminology

Note that Kubernetes Pod Security Policies are not the same as standard Sysdig Secure Policies and will not be displayed on the regular Policies list page.

Steps

Typically, the workflow proceeds as follows:

1. Access the module under Policies > Pod Security Policies.

   

2. Create the Pod Security Policy rules to be tested: either upload an existing PSP or upload a yaml deployment file from which the tool will auto-generate the PSP contents.

3. Click Start Simulation.

4. Deploy the pods in the appropriate cluster in your environment. Because the Simulator is running, it will deploy as a dry test and trigger any resulting alerts.

5. Check the Simulation output and tweak the PSP content if needed.

6. When satisfied that the PSP rules perform as desired, click Stop Simulation.

7. You are now ready to apply this PSP to your cluster. See https://kubernetes.io/docs/concepts/policy/pod-security-policy/#enabling-pod-security-policies.

Manage a Pod Security Policy Simulation

Review the Pod Security Policies Landing Page

Access the module from Policies>Pod Security Policies.

The Pod Security Policies list page is displayed.

After at least one simulation has been generated, there will be content in the list.

Notice the following view-at-a-glance features:

• Search Bar: Search will be performed words or characters in the PSP names as they appear in the Pod Security Policy column.

• Status: This is the status of the simulation associated with the PSP name. It can be Running or Stopped .

  Note that Simulations run continuously until they are manually stopped. The “Running” symbol does not indicate “amount completed.”

• Pod Security Policy (name): The PSP name is auto-inherited or generated from the name parameter in uploaded PSP content. You can use the name parameter to edit this title.

• Scope: The Scope column reflects whatever Kubernetes namespace name and deployment name were defined for the simulation.

• Rerun | Stop | Delete Simulation links: Use the 3 dots on the right to re-run a stopped simulation, stop a running one, or delete a simulation from the system.

Generate a PSP Simulation

1. Select Policies>Pod Security Policies and click New Simulation.

   The New Simulation page is displayed.

   

2. Use the Import buttons to upload either an existing PSP Policy or a deployment YAML file.

   

3. Click Generate PSP.

   The PSP rule content will be displayed in the text box below. If you used a YAML file, the PSP rule content will be auto-generated from it and displayed.

4. Enter the namespace.name and/or deployment.name of the cluster where you will run the simulated PSP, or choose “all.”

5. Click Save.

   The PSP Simulation has been defined and will appear on the PSP list page.

Run a Simulation and Review Output Events

1. Once you have generated a PSP simulation, simply click Start Simulation to begin.

   You can access the Start button from the main List page or from the simulation detail page.

2. Deploy the PSP to the designated environment, where the Simulator will test it.

3. Select the simulation while it’s running to review any generated event output.

4. Edit the rules as needed, and Restart the simulation if necessary.

Stop a Simulation

When you are satisfied with the PSP test behavior. click Stop Simulation.

You are now ready to apply this PSP to your cluster. See https://kubernetes.io/docs/concepts/policy/pod-security-policy/#enabling-pod-security-policies.

6 -

Network

Sysdig Network Security tracks ingress and egress communication from every pod. The Network Security Policy tool allows you to generate Kubernetes Network Policies based on the traffic allowed or denied as defined in the Ingress and Egress tabs. The UI also allows you to view which policies are being applied in real time.

Prerequisites

Sysdig agent: 10.7.0+

If necessary, install or upgrade your agents.

Note: If you are upgrading and not using Helm, you will need to update the clusterrole.yaml manually.

Supported CNI Plugins:

• Calico
• Weave
• Cillium
• OVS

Coverage Limits

• Communications to/from k8s nodes are not recorded
• Workloads with no recorded communications are not present in workloads list

Understanding the Network Security Policy Tool

By default, all pods within a Kubernetes cluster can communicate with each other without any restrictions. Kubernetes Network Policies help you isolate the microservice applications from each other, to limit the blast radius and improve the overall security posture.

With the Network Security Policy tool, you can generate and fine-tune Kubernetes network policies within Sysdig Secure. Use it to generate a “least-privilege” policy to protect your workloads, or view existing network policies that have been applied to you workloads. Sysdig leverages native kubernetes features and doesn’t require any additionl networking requirements other than the CNIs already supported.

Benefits

Key features include:

• Out-of-the-box visibility into network traffic between applications and services, with a visual topology map to help identify communications.
• A baseline network policy that you can directly refine and modify to match your desired declarative state.
• Automated KNP generation based on the network communication baseline + user-defined adjustments.
• Least-privilege: KNPs follow an allow-only model, any communication that is not explicitly allowed will be forbidden
• Enforcement delegated to the Kubernetes control plane, avoiding additional instrumentation or directly tampering with the host’s network configuration
• Map workloads to network policies applied to your cluster, helping operators and developers understand why a pods communicaiton may or may not be blocked

• The ability to view the network policies applied to a cluster for a particular workload or workloads, with drill-down details to the raw yaml

Access the Tool

1. Ensure your environment meets the Prerequisites.

2. Log in to Sysdig Secure and select Network. You will be prompted to select a cluster and namespace, then taken to the Network Security Policies page.

   

   

Next Steps

You can now generate policies, review and tune them, and finesse configurations or troubleshoot.

6.1 -

Netsec Policy Generation

Generating KNPs in the Sysdig Network Security Policy Tool involves four steps, as described in the following sections:

• Set the scope
• Review ingress/egress and edit the detected communications as desired
• Review the topology map
• Click Generated Policy and download the resulting file.

Subsequently, you can check the topology map to:

• Review applied policies
• Click into details for remediation if needed.

Set the Scope

You first define the Kubernetes entity and timeframe for which you want to aggregate communications.

Understanding the aggregation: Communications are aggregated using Kubernetes metadata to avoid having additional entries that are not relevant for the policy creation. For example, if pod A under deployment A communicates several times with pod B under deployment B, only one entry appears in the interface. Or: If pod A1 and pod A2, both under deployment A, both communicate with pod B, deployment A will represent all its pods.

1. In the Sysdig Secure UI, select Network from the left menu.

2. Choose Cluster and Namespace from the drop-down menus.

3. Select the type of Kubernetes entity for which you want to create a policy:

   • Service

   • Deployment

   • Daemonset

   • Stateful Set

   • CronJob Choose CronJob to see communication aggregated to the CronJob (scheduler) level, rather than the Job, which may generate an excess number of entries.

   • Job Choose Job to see entries where a Job has no CronJob parent.

4. Select the timespan, i.e. how far back in time to aggregate the observed communications for the entity. The interface will display the Ingress / Egress tables for that Kubernetes entity and timeframe.

Manage Ingress and Egress

The ingress/egress tables detail the observed communications for the selected entity (pod owner) and time period.

Granular and global assignments: You can then cherry-pick rows to include/exclude from the policy granularly, or establish general rules using the drop-down global rule options.

Understanding unresolved IPs: For some communications, it may not be possible to resolve one of the endpoints to Kubernetes metadata and classify as Service, Deployment, etc.. For example, if a microservice is communicating with an external web server, that external IP is not associated with any Kubernetes metadata in your cluster. The UI will still display these entities as “unresolved IPs.” Unresolved IPs are excluded by default from the Kubernetes network policy, but can be added manually via the ingress/egress interface.

Choose Ingress or Egress to review and edit the detected communications:

1. Select the scope as described above.

2. For in-cluster entities: Edit the permitted communications as desired, by either:

   • Selecting/deselecting rows of allowed communication, or

   • Choosing General Ingress/Egress Rules: Block All, Allow All Inside Namespace, or Allow All.

3. For unresolved IPs (if applicable): If the tool detects many unresolved IPs, you can:

   • Search results by any text to locate particular listings

   • Filter results by

     • Internal: found within the cluster

     • External: found outside the cluster

     • Aliased: displays any given alias

     • Unknown: unable to tell if internal or external.

   • Fine-tune the handling of unknown IPs (admins only) .

     You can assign an alias, set the IP to “allowed” status, or add a CIDR configuration so the IP so the IP is correctly categorized and labelled.

4. Repeat on the other table, then proceed to check the topology and/or generate the policy.

Use Topology Visualization

Use the Topology view to visually validate if this is the policy you want, or if something should be changed. The topology view is a high-level Kubernetes metadata view: pod owners, listening ports, services, and labels.

Communications that will not be allowed if you decide to apply this policy are color-coded red.

Pop-up detail panes: Hover over elements in the topology to see all the relevant details for both entities and communications.

Review Applied Policies

Once policies have been generated, you can view the network policies applied to a cluster for a particular workload or workloads.

You can:

• Review the relevant policies applied to the pod-to-pod communication for the current view

• Click View Policy to see the raw yaml output of the network policy applied to that workload.

Topology Legend

When glancing at the topology, the color codes indicate:

• Lines:

  Black = resolved connection

  Red = connection not resolved; communication not included in the generated policy. (Go to Ingress/Egress panels and select the relevant rows to allow the communication.)

• Entities:

  Blue = the selected workload

  Black = other services and deployements the selected workload communicates with

Review and Download Generated Policy

When you are satisfied with the rules and communication lines, simply click the Generated Policy tab to get an instantaneously generated file.

Review the resulting YAML file and download it to your browser.

Sample Use Cases

In all cases, you begin by leaving the application running for at least 12 hours, to allow the agent to collect information.

Case 1: Only Allow Specified Ingress/Egress Communications

As a developer, you want to create a Kubernetes network policy that only allows your service/deployment to establish ingress and egress network communications that you explicitly allow.

• Select the cluster namespace and deployment for your application. You should see pre-computed ingress and egress tables. You know the application does not communicate with any external IP for ingress or egress, so should not see any unresolved IPs. The topology map shows the same information.

• Change a rule: You decide one service your application is communicating with is obsolete. You uncheck that row in the egress table.

• Check the topology map. You will see the communication still exists, but is now drawn in red, meaning that it is forbidden using the current Kubernetes network policy (KNP).

• Check the generated policy code. Verify that it follows your plan:

  • No ingress/egress raw IP

  • No entry for the service you explicitly excluded

• Download the generated policy and upload it to your Kubernetes environment.

• Verify that your application can only communicate with the services that were marked in black in the topology and checked in the tables. Then generate and download the policy to apply it.

Case 2: Allow Access to Proxy Static IPs

As a developer, you know your application uses proxies with a static IP and you want to configure a policy that allows your application to access them.

• See the proxy IPs in the egress section of the interface

• Use the Allow Egress to IP mask to create a manual rule to allow those IPs in particular

• De-select all the other entries in the ingress and egress tables

• Looking at the topology map, verify that only the communications to these external IPs are marked in black, the other communications with the other services/deployments are marked in red

• Download the generated Kubernetes network policy and apply it.

Case 3: Allow Communication Only Inside the Namespace

You know that your application should only communicate inside the namespace, both for ingress and for egress.

• Allow ingress inside the namespace using the general rules

• Allow egress inside the namespace using the general rules

• Generate the policy and confirm: everything inside the namespace is allowed, without nominating a particular service/deployment, then apply it.

Case 4: Allow Access to a Specified Namespace, Egress Only

Your application deployment A only communicates with applications in deployment B, which lives in a different namespace. You only need that egress traffic; there is no ingress traffic required for that communication.

• Verify that the ingress table is empty, both for Kubernetes entities and for raw IPs

• Verify that the only communication listed on the Egress table is communication with deployment B

• Download the autogenerated policy, apply it, and verify:

  • Your application cannot communicate with other entities inside A’s namespace

  • The application can contact the cluster DNS server to resolve other entities

Case 5: Allow Access When a Deployment Has Been Relabeled

As a developer, you want to create a policy that only allows your service/deployment to establish ingress and egress network communications that you explicitly allow, and you need to make a change.

• After leaving the application running for a few hours, you realize you didn’t tag all the namespaces involved in this policy

  A message at the top of the view will state “you need to assign labels to this namespace”.

• Confirm the situation in the different views:

  • The generated policy should not have an entry for that communication

  • The Topology map should show the connection with a red line

• Attach a label to the namespace that was missing it. After some minutes, a row shows the updated information.

• Whitelist the connection appropriately.

• Generate and download the policy and apply it.

6.2 -

Configuration and Troubleshooting

Kubernetes Network Configuration

Sysdig provides a Configuration page for Administrators who want to fine-tune the way the agent processes the network data.

It contains three areas, described below:

• Workload labels

• Unresolved IPs

• Cluster CIDR configurations

  

Workload Labels

The Sysdig agent automatically detects labels used for the Kubernetes objects in a cluster. Sometimes, there are many more labels than are required for network security purposes. In this cases, you can select the two or three most meaningful labels and use include or exclude namespace or workload labels to avoid clutter in both the UI and your network security policies. For example you can exclude labels inherited by helm, and only include the labels that are required for each ojbect, like app and name

Unresolved IP Configuration

If the Sysdig agent cannot resolve an IP to a higher-level structure (Service, Deployment, Daemonset, etc.) it will be displayed as “unresolved” in the ingress/egress tables. Additionaly you can add unresolved IPs from the ingress or egress tabs by clicking the @ and creating a new alias or assigning it to an existing alias

You can manually enter such IPs or CIDRs in the configuration panel, label them with an alias, and optionally set them to “allowed” status. Note that grouping IPs under a single alias helps declutter the Topography view.

Pod communication without an alias

Pod communicaiton with IP aliases

Cluster CIDR Configuration

Unresolved IPs are listed and categorized as “internal” (inside the cluster), “external” (outside the cluster) or “unknown,” (subnet information incomplete). For unknowns, Sysdig will prompt with an error message to help you resolve it.

The simplest resolution is to manually specify cluster and service CIDRs for the clusters.

Troubleshooting

Tips to resolve common error messages:

Error message: Namespaces without labels

Problem: Namespaces must be labeled for the KNPs to define ingress/egress rules. If non-labeled namespaces are detected in the targeted communications, the “Namespaces without labels” error message is displayed in the UI:

Resolution: Simply assign a label to the relevant namespace and wait a few minutes for the system’s auto-detection to catch up.

Error Message: Cluster subnet is incomplete

Problem: To categorize unresolved IPs as inside or outside the cluster, the agent must know which CIDR ranges belong to the cluster. By default, the agent tries to discover the ranges by examining the command line arguments of the kube-apiserver and kube-controller-manager processes.

If it cannot auto-discover the cluster subnets, the “cluster subnet is incomplete” error message is displayed in the UI:

Resolution:

• Preferred: Use the Configuration panel to add the CIDR entries.

• In rare cases, you may need to configure the agent to look for the CIDR ranges in other processes than the default kube-apiserver, kube-controller-manager processes. In that case, append the following to the agent configmap:

  network_topology:
    pod_prefix_for_cidr_retrieval:
  [<PROCESS_NAME>, <PROCESS_NAME>]
  

7 -

Secure Events

The Events page in Sysdig Secure displays a complete list of events that have occurred within the infrastructure during a defined timeline.

It provides a navigable interface to:

• Find and surface insights around the most relevant security events in your infrastructure

• Slice and dice your event data using multiple filters and scopes to hone into the events that will require further inspection or remediation actions

• Inspect any items using an advanced event detail panel

• Follow up on forensics, activity audits, etc., by directly linking to other sections of the product for additional event information

It provides an overview of the entire infrastructure, and the ability to deep-dive into specific security events, identify false positives, and configure policies to optimize performance.

Without filters or scope defined, the event list comprises all events within the timeline, in chronological order. Clicking on an event opens the event detail panel on the right.

Filter Secure Events

Using the Improved Filter Bar

Building expressions in the improved filter bar is simpler and cleaner than in the original filter UI. Both use the Filter Expression Elements described below.

• Build expressions from the drop-down options: Click Add Filter for an initial drop-down list of valid scope elements. Keep clicking in the filter bar to be presented with the next logical operand, value, etc. to add to your expression.

  

• Build expressions using elements from the Events list: Click the operand after an element in an event to add it directly to the filter expression.

  

• Add priority or type filters and save a constructed expression as a Favorite or set as the Default filter

  

Understanding Filter Expression Elements

Note that the filters are additive. For example, if you set the Type to Image Scanning events and don’t see what you expected, make sure the scope and time span have also been set appropriately.

You construct a filtering expression from the following elements:

Scope

By default, the Event scope encompasses Everywhere, but you can define the environment scope(containers, namespaces, etc.) to limit the range. Those environment limits are assigned to the team active during the scope definition.

See also: Team Scope and the Event Feed, below.

Define a Scope Filter (Original)

You an set a scope label as “variable,” so you can change its value using a dropdown without having to edit the entire scope.

1. Log in to Sysdig Secure.

   Any event scope you define will be applied to the team under which you logged in.

2. On the Events page, click Edit Scope.

3. From the drop-down menus(s), select the elements, values, and labels needed, and click Apply.

   

Free-Text Search

You can search by the event title and scope label values, such as “my-cluster-name,” visible in the events lists.

Type

Events include both Runtime and Image Scanning events.

Runtime events correspond to the rules and violations defined in Policies.

Image Scanning events correspond to the runtime scanning alerts.

Severity

Use the appropriate buttons to filter events by High, Medium, Low, and Info level of severity, corresponding to the levels defined in the relevant runtime Policies or runtime scanning alerts.

Time Span

As in the rest of the Sysdig Platform interface, the time span can be set by date ranges using the calendar pop-up, and in increments from 10 minutes to 3 days. You can additionally use the calendar picker to select other time ranges that are not available as fast buttons.

Attributes

Under Policies and Triggered Rules, hover over an attribute to reveal the =/!= filter button and click to add to the Attribute filter.

Event Detail Panel

The Event Detail contents vary depending on the selected event. In general, the following are always present:

• Attributes on which you can filter directly:

  See the Attributes discussion, above.

• Action Buttons:

  If relevant, the Captures button links to Captures. See also: Quick Menu to Captures from Runtime Events.

  For Runtime events, the Activity shortcut button is available and links to Activity Audit.

  For Image Scanning, the Scan Results shortcut links to the Scan Results page.

• Edit Policy Shortcut:

  For image scanning: Links to the runtime alert that generated the event.

  For policy (runtime) events: Links to the runtime rule that created the event, as well as the rule type (i.e. Falco - Syscall) and the labels associated with that rule.

  All three elements are filterable using the attribute filter widgets (see above).

• Output (For Policy events):

  The Falco rule output as configured in the rule is listed.

• Scope

  The new scope selector allows for additional selector logic (in, not in, contains, starts-with, etc), improving the scoping flexibility over previous versions. This scope selector also provides scope variables, allowing you to quickly switch between, for example, Kubernetes namespaces without having to edit the panel scope. See also: Team Scope and the Event Feed, below.

  Note that the scope details listed can be entered in the free-text search field if desired.

• Live/Pause Button -

  When live, events continually update. Use Pause to focus on a section of the screen and not continue scrolling away in a noisy environment.

• Portable URLs

  The Event Feed URL maintains the current filters, scope, and selected elements. You can share this URL with other users to allow them to display the same data.

Quick Menu to Captures from Runtime Events

For runtime policy events that have an associated capture, we now offer a contextual menu for performing quick actions over the event capture, rather than a simple link to the Captures interface. You can:

• View the capture directly in Sysdig Inspect

• Directly download or delete the capture

Additionally, if the event is scoped to a particular container, Sysdig Inspect will automatically filter the displayed information to the scope of that Container ID.

Team Scope and the Event Feed

Not every label available in the Sysdig Platform is compatible with the set of labels used to define the scope of a security event in the Event Feed.

Practically, this means that in order to correctly determine if a set of events is visible for a certain Sysdig Secure team, the team scope must not use any label outside the following list.

Permitted Labels

agent.tag.* (any label starting with agent.tag is valid)

host.hostName
host.mac

kubernetes.cluster.name
kubernetes.namespace.name
kubernetes.node.name
kubernetes.namespace.label.field.cattle.io/projectId
kubernetes.namespace.label.project

kubernetes.pod.name
kubernetes.daemonSet.name
kubernetes.deployment.name
kubernetes.replicaSet.name
kubernetes.statefulSet.name
kubernetes.job.name
kubernetes.cronJob.name
kubernetes.service.name

container.name
container.image.id
container.image.repo
container.image.tag
container.image.digest

container.label.io.kubernetes.container.name
container.label.io.kubernetes.pod.name
container.label.io.kubernetes.pod.namespace
container.label.maintainer

Not using any label to define team scope (Everywhere) is also supported.

If the Secure team scope is defined using a label outside of the list above, the Event Feed will be empty for that particular team.

7.1 -

Event Forwarding

Sysdig supports sending different types of security data to third-party SIEM (security information and event management) platforms and logging tools, such as Splunk, Elastic Stack, Qradar, Arcsight, LogDNA. Use Event Forwarding to perform these integrations so you can view security events and correlate Sysdig findings with the tool that you are already using for analysis.

Review the Types of Secure Integrations table for more context. The Event Forwarding column lists the various options and their levels of support.

You must be logged in to Sysdig Secure as Administrator to access the event forwarding options.