• 1:
• 2:
• 3:
• 3.1:
• 3.2:
• 3.3:
• 3.4:
• 3.4.1:
• 3.4.2:
• 3.4.3:
• 4:
• 5:
• 5.1:
• 5.1.1:
• 5.2:
• 5.3:
• 5.4:
• 5.4.1:
• 5.4.2:
• 5.4.3:
• 5.5:
• 5.6:
• 5.6.1:
• 5.7:
• 5.8:
• 5.9:
• 5.10:
• 5.10.1:
• 5.11:
• 5.12:
• 6:
• 6.1:
• 6.2:
• 7:
• 7.1:
• 7.2:
• 7.3:
• 7.3.1:
• 7.4:
• 7.5:
• 7.6:
• 8:
• 9:
• 9.1:
• 9.1.1:
• 9.1.2:
• 9.1.3:
• 9.1.4:
• 9.1.5:
• 9.1.6:
• 9.1.7:
• 9.1.8:
• 9.1.9:
• 9.1.10:
• 9.2:
• 9.3:
• 10:
• 10.1:
• 10.1.1:
• 10.2:
• 10.3:
• 11:
• 11.1:
• 12:
• 12.1:
• 12.1.1:
• 12.2:
• 12.2.1:
• 12.3:
• 12.3.1:
• 13:
• 13.1:
• 13.2:

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, usinghttps://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 using AWS CIS Benchmmarks

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

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

• Trigger an image scan, based on whatever image scanning options you’ve enabled.

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.

Set up a Repository Scanning Alert

• By integrating scan results with any of the notification channels provided by Sysdig, users can swiftly receive actionable updates reporting on the output of the image analysis process. Repository alerts can then be customized using different trigger conditions depending on the registry/repo scope.

Secure Your Runtime Environment

Set up a Runtime Scanning Alert

• One of the most actionable alerts a user can set up is to detect if an existing runtime image is impacted by newly discovered vulnerabilities. These alerts can be scoped using container and Kubernetes metadata so the right teams are notified as soon as the image falls out of compliance.

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.

2 -

Insights

Sysdig Secure (SaaS) has introduced a powerful new 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 in some cases and must be manually enabled in others. (Note that your Sysdig Secure region may affect availability as well during the roll-out phase.)

• Default Landing Page: for users that connect a cloud account

• Manually enable in SysdigLabs:

  • 30-Day Trial users

  • Existing or new Sysdig Secure enterprise users who have not connected a cloud account.

  These accounts must first enable Insights by logging in to Sysdig Secure as Admin and choosing User Profile . Toggle the feature On in SysdigLabs:.

  When Insights is not enabled, these users will see either the Overview page (if enabled) or the Events feed as their default landing page.

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 -

Benchmarks

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.

3.1 -

Configure Benchmark Tasks

Use a Benchmark Task to define:

• the type of benchmark test to be run, based on “schemas”

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

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

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

3.4 -

Benchmarks (Legacy)

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 (Legacy) .

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 (Legacy) .

3.4.1 -

Configure Benchmark Tasks (Legacy)

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. See Trigger a Manual Benchmark Test (Run Now).

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. See also Understanding Report Filters.

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.

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

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

Secure Overview

The Secure Overview page provides an entry point to Sysdig Secure and a birds-eye view of your assets and their status.

Chart Highlights

The Overview page displays pass/fail results over time, to a maximum of 90 days.

If there are any broken lines in the trend chart, it means there was no data available for that period.

Definitions

• Build-time images: All the images that have been evaluated by Sysdig Secure.

• Runtime images: All the images that are being used by running containers in the past few hours

• Policy Events: The security events generated as a result of policies

• Benchmarks: Docker/Kubernetes CIS benchmark check results

Scope

Panels can be scoped by Cluster or Namespace. The scope will update all panels that are displaying run-time data and the corresponding drill-down views.

The panels are affected in the following ways by the scope:

• Build Time - Images Scanned and Build Time - CVEs Found by Severity (OS and Non-OS):

  Not impacted by this filter.

  When filtered by cluster, a small info icon appears on build time panels showing the results are independent of cluster

• All other panels get filtered by cluster/namespace (filters both instant data and trend chart).

• Benchmarks panel: cannot be filtered by namespace.

  When namespace is selected, it will still show the cluster’s data and a small info icon appears on the panel showing the results are independent of namespace.

• Namespace: disabled when a non-Kubernetes cluster is selected.

• “Non-k8s” as a cluster selection will show all results that are running outside of the scope of a kubernetes cluster.

Panel Details

The graphs display pass/fail results over time, to a maximum of 90 days. Note that if you have less data (e.g., two days), then only two days will be shown.

Build Time - Images Scanned

Shows the pass/fail status of all the images analyzed by Sysdig Secure.

Donut: shows past 24 hours

Data Collection Details

Runtime - Images Scanned

Shows the pass/fail status of all runtime images scanned across clusters for the past 1 hour.

Donut: shows last 1-hour snapshot of data

Data Collection Details

Runtime - Policy Events by Severity

Shows the events in Sysdig Secure over the past 24 hours, sorted by high, medium, low, and information levels of severity.

Donut: shows past 24 hours of data

Data Collection Details

Build Time - CVEs Found by Severity (OS and non-OS)

Shows the Common Vulnerabilities and Exposures detected over the past 24 hours, sorted by high, medium, low, and information levels of severity.

Donut: shows last 24 hours of data

Data Collection Details

Runtime - CVEs Found by Severity (OS and non-OS)

Shows the Common Vulnerabilities and Exposures detected for runtime images across clusters for the last 1 hour.

Donut: shows 1-hour snapshot

Data Collection Details

Runtime - Benchmark Tests Failed

Shows the average of failed benchmark results across hosts, sorted by test type.

Donut: shows

Data Collection Details

5 -

Scanning

Two Types of Scanning

As of May 2021, Sysdig Secure includes two different types of scanning for vulnerabilities:

• Image scanning This includes all prior scanning tools, policies, alerts, etc. in Sysdig Secure and focuses on scanning the container images in an environment.

• Host scanning: (New) This feature, deployed via the Node Analyzer, scans the host operating system, whether OS (e.g rpm, dpkg) or non-OS (e.g. Java packages, Ruby gems).

How Sysdig Image Scanning Works

Image scanning allows you to scan container images for vulnerabilities, secrets, license violations, and more. It can be used as part of a development build process, can validate images added to your container registry, and can scan the images used by running containers on your infrastructure.

The basic set up for image scanning is simple: provide registry information where your images are stored, trigger a scan, and review the results.

Behind the scenes:

• Image contents are analyzed.

• The contents report is evaluated against multiple vulnerability databases.

• It is then compared against default or user-defined policies.

• Results are reported, both in Sysdig Secure and (if applicable) in a developer’s external CI tool.

Prerequisites

• Network and port requirements

  Image Scanning requires access to an external vulnerability feed. To ensure proper access to the latest definitions, refer to the Network and Port requirements.

• Whitelisted IP for image scanning requests

  Image scanning requests and Splunk event forwards both originate from 18.209.200.129. To enable Sysdig to scan private repositories, your firewall will need to allow inbound requests from this IP address.

Image Contents Reported

The analysis generates a detailed report of the image contents, including:

• Official OS packages

• Unofficial OS packages

• Configuration files

• Credentials files

• Localization modules and software-specific installers:

  • Javascript with NPM

  • Python PiP

  • Ruby with GEM

  • Java/JVM with .jar archives

• Image metadata and configuration attributes

Vulnerability Databases Used

Sysdig Secure continuously checks against a wide range of vulnerability databases, updating the Runtime scan results with any newly detected CVEs.

The current database list includes:

Use Cases

As an organization, you define what is an acceptable, secure, reliable image running in your environment. Image scanning for the development pipeline follows a somewhat different flow than for security personnel.

Scanning During Container Development (DevOps)

Use image scanning as part of your development pipeline, to check for best practices, vulnerabilities, and sensitive content.

To begin:

• Add Registry: Add a registry where your images are stored, along with the credentials necessary to access them.

• Integrate CI Tool: Integrate image scanning with an external CI tool, using the Jenkins plugin or building your own integration from a SysdigLabs solution.

• Scan Image(s): The plugin or CLI integration triggers the image scanning process. Failed builds will be stopped, if so configured.

• Review Results (in CI tool): Developers can analyze the results in the integrated CI tool (Jenkins).

  (Optionally: add policies or refine the default policies to suit your needs, assign policies to particular images or tags, and configure alerts and notifications.)

Scanning Running Containers (Security Personnel)

Security personnel uses image scanning to monitor which containers are running, what their scan status is, and whether new vulnerabilities are present in their images.

• Add Registry: Add a registry where your images are stored, along with the credentials necessary to access them.

• Scan Image(s): Trigger an image scan with the node image analyzer or manually (one-by-one).

• Review Results (in Sysdig Secure): Security personnel can analyze scan results in the Sysdig Secure image scanning UI.

  (Optionally: add policies or refine the default policies to suit your needs, assign policies to particular images or tags, and configure alerts and notifications.)

Add Scanning to Container Registries

In some cases, it is possible to integrate image scanning directly into a container registry and automatically trigger an event or action every time a new container is pushed into the registry. This feature is currently supported for the following container registry:

• AWS ECR

5.1 -

Integrate with CI/CD Tools

You have the option to use image scanning as part of your development pipeline, to check for best practices, vulnerabilities, and sensitive content.

Inline Scanning

Sysdig provides a stand-alone inline scanner– a containerized application that can perform local analysis on container images (both pulling from registries or locally built) and post the result of the analysis to Sysdig Secure.

Other scanning integrations (i.e. the Jenkins CI/CD plugin) make use of this component under the hood to provide local image analysis capabilities, but it can also be used as a stand-alone component for custom pipelines, or simply as a way to one-shot scan a container from any host.

The Sysdig inline scanner works as an independent container, without any Docker dependency (it can be run using other container runtimes), and can analyze images using different image formats and sources.

This feature has a variety of use cases and benefits:

• Images don’t leave their own environment 

• SaaS users don’t send images and proprietary code to Sysdig’s SaaS service

• Registries don’t have to be exposed

• Images can be scanned in parallel more easily

• Images can be scanned before they hit the registry, which can

  • cut down on registry costs

  • simplify the build pipeline

Prerequisites

At a minimum, the inline scanner requires:

• Sysdig Secure v2.5.0+ (with API token)

• Internet access to post results to Sysdig Secure (SaaS or On-Prem)

• Ability to run a container

Implement Inline Scanning

Quick Start

You can scan an image from any host by executing:

docker run --rm quay.io/sysdig/secure-inline-scan:2 <image_name> --sysdig-token <my_API_token> --sysdig-url <secure_backend_endpoint>
…
…
Status is pass
View the full result @ https://secure.sysdig.com/#/scanning/scan-results/docker.io%2Falpine%3A3.12.1/sha256:c0e9560cda118f9ec63ddefb4a173a2b2a0347082d7dff7dc14272e7841a5b5a/summaries
PDF report of the scan results can be generated with -r option.

Common Parameters

Quick Help and Parameter List from -h

Display a quick help and parameters description from the image itself by executing: docker run --rm quay.io/sysdig/secure-inline-scan:2 -h.

Sample output:

$ docker run quay.io/sysdig/secure-inline-scan:2 -h
Sysdig Inline Analyzer -- USAGE

  Container for performing analysis on local container images, utilizing the Sysdig analyzer subsystem.
  After image is analyzed, the resulting image archive is sent to a remote Sysdig installation
  using the -s <URL> option. This allows inline analysis data to be persisted & utilized for reporting.

  Usage: sysdig-inline-scan.sh -k <API Token> [ OPTIONS ] <FULL_IMAGE_TAG>

    == GLOBAL OPTIONS ==

    -k <TEXT>   [required] API token for Sysdig Scanning auth
                (ex: -k 'xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx')
                Alternatively, set environment variable SYSDIG_API_TOKEN
                Alias: --sysdig-token
    -s <URL>    [optional] Sysdig Secure URL (ex: -s 'https://secure-sysdig.svc.cluster.local').
                If not specified, it will default to Sysdig Secure SaaS URL (https://secure.sysdig.com).
                Alias: --sysdig-url
    --sysdig-skip-tls
                [optional] skip tls verification when calling secure endpoints
    -o          [optional] Use this flag if targeting onprem sysdig installation
                Alias: --on-prem
    -a <TEXT>   [optional] Add annotations (ex: -a 'key=value,key=value')
                Alias: --annotations
    -f <PATH>   [optional] Path to Dockerfile (ex: -f ./Dockerfile)
                Alias: --dockerfile
    -m <PATH>   [optional] Path to Docker image manifest (ex: -m ./manifest.json)
                Alias: --manifest
    -i <TEXT>   [optional] Specify image ID used within Sysdig (ex: -i '<64 hex characters>')
                Alias: --image-id
    -d <SHA256> [optional] Specify image digest (ex: -d 'sha256:<64 hex characters>')
                Alias: --digest
    -c          [optional] Remove the image from Sysdig Secure if the scan fails
    -r <PATH>   [optional] Download scan result pdf in a specified container-local directory (ex: -r /staging/reports)
                This directory needs to be previously mounted from the host to persist the data
                Alias: --report-folder
    -v          [optional] Increase verbosity
                Alias: --verbose
    --format <FORMAT>
                [optional] The only valid format is JSON. It sets the output format to a valid JSON which
                can be processed in an automated way.
    --write-json <PATH>
                Write the final JSON report to <PATH>.
    --time-profile
                Output information about the time elapsed in the different stages of the scan process
    --malware-scan-enable
                Enables malware scan on container.
                WARNING: it's generally a very slow process.
    --malware-scan-db-path <PATH>
                Local container path with updated ClamAV database.
                Will be used to call clamscan command as "clamscan --database=<PATH> ..."
    --malware-scan-output <DIR-PATH>
                Save JSON output of scan to path. Will be saved to <PATH>/malware_findings.json.
                Output is a JSON array of {"path": "...", "signature": "..."} objects.
                Note: path should exists and should be a directory.
    --malware-fail-fast true|false
                Fails immediately when a malware is found, skipping sending analysis
                results to Secure Backend.
                Default: true
    --malware-exclude REGEX
                Exclude dirs (and its content) and files which match the given regex.
                Arguments are passed to ClamAV --exclude AND --exclude-dir options, please
                refer to its official documentation.
                (https://www.clamav.net/documents/clam-antivirus-user-manual)

    == IMAGE SOURCE OPTIONS ==

    [default] If --storage-type is not specified, pull container image from registry.

        == REGISTRY AUTHENTICATION ==

        When pulling from the registry,
        the credentials in the config file located at /config/auth.json will be
        used (so you can mount a docker config.json file, for example).
        Legacy .dockercfg file is also supported.
        Alternatively, you can provide authentication credentials with:
        --registry-auth-basic     username:password  Authenticate using the provided <username> and <password>
        --registry-auth-token     <TOKEN>            Authenticate using this Bearer <Token>
        --registry-auth-file      <PATH>             Path to config.json or auth.json file with registry credentials
        --registry-auth-dockercfg <PATH>             Path to legacy .dockercfg file with registry credentials

        == TLS OPTIONS ==

        -n                    Skip TLS certificate validation when pulling image
                              Alias: --registry-skip-tls

    --storage-type <SOURCE-TYPE>

        Where <SOURCE-TYPE> can be one of:

        docker-daemon   Get the image from the Docker daemon.
                        Requires /var/run/docker.sock to be mounted in the container
        cri-o           Get the image from containers-storage (CRI-O and others).
                        Requires mounting /etc/containers/storage.conf and /var/lib/containers
        docker-archive  Image is provided as a Docker .tar file (from docker save).
                        Tarfile must be mounted inside the container and path set with --storage-path
        oci-archive     Image is provided as a OCI image tar file.
                        Tarfile must be mounted inside the container and path set with --storage-path
        oci-dir         Image is provided as a OCI image, untared.
                        The directory must be mounted inside the container and path set with --storage-path

    --storage-path <PATH>   Specifies the path to the source of the image to scan, that has to be
                            mounted inside the container, it is required if --storage-type is set to
                            docker-archive, oci-archive or oci-dir

    == EXIT CODES ==

    0   Scan result "pass"
    1   Scan result "fail"
    2   Wrong parameters
    3   Error during execution

Supported Execution Modes and Image Formats

The inline scanner can pull the target image from different sources. Each case requires a different set of parameters and/or host mounts, as described in the relevant Execution Examples.

• Directly pulling from a registry: default option if no other source is specified

• Docker daemon: Retrieve the image from the host-local Docker daemon

• Docker archive: Passing a Docker tar file (i.e. output of docker save)

• OCI archive: passing an OCI tar file

• OCI layout: OCI image directory

• Container storage (CRI-O and others): CRI-O storage directory

Output Options

When the inline scanner has completed the image analysis, it sends the metadata to the Sysdig Secure backend to perform the policy evaluation step. The scan results can then be consumed inline or by accessing the Secure UI.

Container Exit Code

The container exit codes are:

• 0 - image passed policy evaluation

• 1 - image failed policy evaluation

• 2 - incorrect parameters (i.e. no API token)

• 3 - other execution errors

Use the exit code, for example, to decide whether to abort the CI/CD pipeline.

Standard Output

The standard output produces a human-readable output including:

• Image information (digest, image ID, etc)

• Evaluation results, including the final pass / fail decision

• A link to visualize the complete scan report using the Sysdig UI

If you prefer JSON output, simply pass --format JSON as a parameter.

JSON Output

You can write a JSON report, while keeping the human-readable output in the console, by adding the following flag: --write-json /out/report.json

Remember to bind mount the output directory from the host in the container and provide the corresponding write permissions.

PDF Report

You can also download the scan result PDF in a specified container-local directory. Remember to mount this directory from the host in the container to retain the data.

--report-folder /output

Execution Examples

Docker Daemon

Scan a local image build; mounting the host Docker socket is required. You might need to include Docker options ‘-u root’ and ‘--privileged’, depending on the access permissions for /var/run/docker.sock

docker build -t <image-name> .

docker run --rm \
    -v /var/run/docker.sock:/var/run/docker.sock \
    quay.io/sysdig/secure-inline-scan:2 \
    --sysdig-url <omitted> \
    --sysdig-token <omitted> \
    --storage-type docker-daemon \
    --storage-path /var/run/docker.sock \
    <image-name>

Docker Archive

Trigger the scan, assuming the image is available as an image tarball at image.tar. For example, the command docker save <image-name> -o image.tar creates a tarball for <image-name>. Mount this file inside the container:

docker run --rm \
    -v ${PWD}/image.tar:/tmp/image.tar \
    quay.io/sysdig/secure-inline-scan:2 \
    --sysdig-url <omitted> \
    --sysdig-token <omitted> \
    --storage-type docker-archive \
    --storage-path /tmp/image.tar \
    <image-name>

OCI Archive

Trigger the scan assuming the image is available as an OCI tarball at oci-image.tar.  Mount this file inside the container:

docker run --rm \
    -v ${PWD}/oci-image.tar:/tmp/oci-image.tar \
    quay.io/sysdig/secure-inline-scan:2 \
    --sysdig-url <omitted> \
    --sysdig-token <omitted> \
    --storage-type oci-archive \
    --storage-path /tmp/oci-image.tar \
    <image-name>

OCI Layout

Trigger the scan assuming the image is available in OCI format in the directory ./oci-image. Mount the OCI directory inside the container:

docker run --rm \
    -v ${PWD}/oci-image:/tmp/oci-image \
    quay.io/sysdig/secure-inline-scan:2 \
    --sysdig-url <omitted> \
    --sysdig-token <omitted> \
    --storage-type oci-dir \
    --storage-path /tmp/oci-image \
    <image-name>

Container Storage: Build w/ Buildah & Scan w/ Podman

Build an image using Buildah from a Dockerfile, and perform a scan. You might need to include docker options '-u root' and '--privileged', depending on the access permissions for /var/lib/containers. Mount the container storage folder inside the container:

sudo buildah build-using-dockerfile -t myimage

sudo podman run \
--rm -u root --privileged \
-v /var/lib/containers/:/var/lib/containers \
quay.io/sysdig/secure-inline-scan:2 \
--storage-type cri-o \
--sysdig-token <omitted> \
localhost/myimage

Using a Proxy

To use a proxy, set the standard http_proxy and https_proxy variables when running the container.

Example:

docker run --rm \
    -e http_proxy="http://my-proxy:3128" \
    -e https_proxy="http://my-proxy:3128" \
    quay.io/sysdig/secure-inline-scan:2 \
    --sysdig-url <omitted> \
    --sysdig-token <omitted> \
    alpine

Both http_proxy and https_proxy variables are required, as some tools will use a per-scheme proxy.The no_proxy variable can be used to define a list of hosts that don’t use the proxy.

Perform Inline Malware Scanning

It is now possible to scan the image contents for malware as part of the inline scanning process.

Note two important details to consider:

• Malware scanning is resource intensive. Enable this mode for the required set of images only, i.e. images coming from an untrustworthy source.

• Malware contents in the image are not communicated back to the Sysdig backend. The default behavior if malware is found is to consider the scan failed, report malware details, and abort analysis.

Malware Scanning Flags

• --malware-scan-enable: Enable malware detection as part of the inline scanner analysis process. Mounting an external malware database (Using ClamAV format) is highly recommended. If no existing malware database is detected, the analyzer will try to download one on the spot, which means the download time will be added to the analysis process and that it will require network connectivity to pull this database from the Internet.

• --malware-scan-db-path <PATH>: Local container path with updated ClamAV database. Will be used to call clamscan command as clamscan --database=<PATH>

• --malware-fail-fast true|false: Fail fast is true by default, meaning that, on malware found, the image contents will not be sent to the Sysdig backend for further policy evaluation. If you want to send the image contents to the Backend, even on malware detected, set this parameter to false.

  About this flag, note:

  • If no malware is detected, the image contents will be sent to the backend and follow the regular evaluation.

  • If malware is detected, the container will exit with error code 1.

• --malware-scan-output <DIR-PATH>: Save JSON output of scan to path. Will be saved to <PATH>/malware_findings.json. Path must exist and must be a directory; remember to mount this path from an external directory if you want to persist the data.

• --malware-exclude REGEX: It is possible to exclude image directories to speed up the malware analysis (for example directories that only contain signed software or sizable files).

Arguments are passed to ClamAV. For --exclude AND --exclude-dir options, please refer to their official documentation.

Example: Mounting External Malware Database (Recommended)

Note that /absolute/path/to/clamdb/folder (and its contained files) must have read and execute permissions set for the current Docker user.

Refer to ClamAV official documentation.for how to download and keep a local database in sync.

docker run --rm -v /absolute/path/to/clamdb/folder:/malwaredb quay.io/sysdig/secure-inline-scan:2 --sysdig-token <API_Token> --malware-scan-enable --malware-scan-db-path /malwaredb malwares/malware-example:7

Skipping send analysis to Secure backend due to Malware scan failure.
This behaviour can be tuned via --malware-fail-fast option.
Path                                                                        | Signature
/data/29D6161522C7F7F21B35401907C702BDDB05ED47.bin
| Win.Trojan.Emotet-6799923-0
/data/29D6161522C7F7F21B35401907C702BDDB05ED47.bin
| Win.Trojan.Emotet-9769817-0
/data/29D6161522C7F7F21B35401907C702BDDB05ED47.bin
| Win.Trojan.Emotet-9769818-0
/data/29D6161522C7F7F21B35401907C702BDDB05ED47.bin
| Win.Trojan.Agent-1280578
/data/29D6161522C7F7F21B35401907C702BDDB05ED47.bin!(0)
| Win.Trojan.Agent-1280578

Example: Download Malware Database Inline

docker run --rm quay.io/sysdig/secure-inline-scan:2 --sysdig-token <API_Token> --malware-scan-enable malwares/malware-example:7

Pipeline Integration Examples

There are well-documented examples for a variety of pipelines:

• Gitlab

• Github Actions

• AWS Codepipeline

• Azure Pipelines

• CircleCI

• Tekton Pipelines

Additional Options

You can also:

• Integrate with Jenkins

5.1.1 -

Integrate with Jenkins

Sysdig has a plugin to integrate Sysdig image scanning into a Jenkins-based build process.

Install and Configure the Jenkins Plugin

The Sysdig Secure Jenkins Plugin documentation (at jenkins.io) describes:

• Prerequisites

• Obtaining the plugin

• Necessary system configuration steps in the Jenkins UI

• Adding Sysdig Secure Image Scanning as build step (in the Jenkins UI)

• Configuring the actions to take on scanned builds (e.g. when to fail a build or issue a warning).

Obtain Scan Results in Jenkins

The Sysdig plugin generates a scan report listed in the Jenkins build list:

Click on the Sysdig Scanning Report to view the summary information and a list of policy checks and results.

5.2 -

Integrate with Container Registries

Some image registries can trigger an automatic event or action every time a new container is pushed into the registry. Sysdig has provided seamless integration with AWS Elastic Container Registries (ECR) for this kind of automatic scanning. See ECR Registry Scanning.

Other image scanning pipelines use the container registry as a “passive” element; when you know which image you want to scan, you retrieve the target image from the registry. For this type of integration, you must provide the registry credentials in the Sysdig Secure interface. See Manage Registry Credentials, below.

ECR Registry Scanning

ECR Registry Scanning automatically scans all container images pushed to all your Elastic Container Registries, so you have a vulnerability report available in your Sysdig Secure dashboard at all times, without having to set up any additional pipeline.

An ephemeral CodeBuild pipeline is created each time a new image is pushed, which executes an inline scan based on your defined scan policies. Default policies cover vulnerabilities and dockerfile best practices, and you can define advanced rules yourself.

Usage Steps

1. Deploy: Deploy Sysdig Secure for cloud on AWS and choose the ECR Image Registry Scanning option.

2. Insights becomes your default landing page in Sysdig Secure.

3. Review the Scan Results to confirm that AWS Registry appears and use the feature.

   

Manage Registry Credentials

Registry credentials are required for Sysdig Secure to pull and analyze images. Each of the registry types has unique input fields for the credentials required (e.g., username/password for docker.io; JSON key for Google Container Registry).

The login requires at least read permissions.

Add a New Registry

1. From the Image Scanning module, select Registry Credentials and click Add Registry.

   The New Registry page is displayed.

   

2. Enter the basic identification information:

   Registry Name:Self-defined

   Path The path to the registry, e.g. docker.io

   NOTE: In some cases, you may have a registry with various namespaces, each with different permissions.

   You can use a partial path name with a wildcard (*) to subsume all those credentials into the single set of credentials you configure on this page.

   The wildcard indicates that any image located under the partial path inside the registry (/rg-2-1er in the screenshot) will use the registry credentials configured in step 3, below.

   Type Select from the from the drop-down menu.

3. Configure the registry-specific credentials (based on the Type chosen).

   Docker V2 There are many Docker V2 registries, and the credential requirements may differ.

   For Azure Container Registry:

   1. Admin Account

      Username: in the 'az acr credentials show --name <registry name>' command result

      Password: The password or password2 value from the 'az acr credentials show' command result

   2. Service Principal

      Username: The service principal app id

      Password: The service principal password

   Google Container Registry:

   JSON Key

4. (Primarily for OpenShift clusters): Add an internal registry address.

   The recommended way to run an image registry for an OpenShift cluster is to run it locally. The Sysdig agent will detect the internal registry names, but for the Anchore engine to pull and scan the image it needs access to the internal registry itself.

   Example:

   External name: mytestregistry.example.com

   Internal name: docker-registry.default.svc:5000

   Sysdig maps the internal registry name to the external registry name, so the Runtime and Repository lists will show only the external names.

5. Optional: Toggle the switch to Allow Self-Signed certificates.

   By default, the UI will only pull images from a TLS/SSL-enabled registry.

   Toggle Allow Self-Signed to instruct the UI not to validate the certificate (if the registry is protected with a self-signed certificate or a cert from an unknown certificate authority).

6. Optional: Toggle the Test Credentials switch to validate your entries.

   When enabled, Sysdig will attempt to pull the image using the entered credentials. If it succeeds, the registry will be saved. If it fails, you will receive an error and can correct the credentials or image details.

   If enabled, then enter the test registry path in the format :

   registry/repo:tag
   

   E.g. quay.io/sysdig/agent:0.89

7. Click Save.

Edit a Registry

1. From the Image Scanning module, select Registry Credentials.

2. Select an existing registry to open the Edit window.

3. Update the parameters as necessary and click Save.

   The registry Type cannot be edited.

Delete a Registry

1. From the Image Scanning module, select Registry Credentials.

2. Select the existing registry to open the Edit window.

3. Click Delete Registry and click Yes to confirm the change.

Next Steps

When at least one registry has been added successfully, it is possible to scan images and review scan results, taking advantage of the Default scanning policy provided.

5.3 -

Scan Running Images

To automatically trigger scans of running images, install a node-based image analyzer alongside the agent. Alternatively, you can scan individual images manually from the UI.

Auto-Scan with the Image Analyzer

What is the Image Analyzer?

The (node) image analyzer (NIA) provides the capability to scan images as soon as they start running on hosts where the analyzer is installed. It is typically installed alongside the Sysdig agent container.

On container start-up, the analyzer scans all pre-existing running images present in the node. Additionally, it will scan any new image that enters a running state in the node. It will scan each image once, then forward the results to the Sysdig Secure scanning backend. Image metadata and the full scan report is then available in the Sysdig Secure UI.

The analyzer performs the image analysis directly on the local host. This poses several benefits:

• Automation: Every image executed on your environments will be automatically scanned and checked against the vulnerability databases and configured scanning policies, without requiring any manual intervention

• Privacy: Using local analysis, only image metadata is sent to the Sysdig backend, as opposed to pulling the entire image to be evaluated with backend scanning, which provides improved privacy

• Improved registry security: Since the Sysdig backend will not pull the image from a registry, there is no need to configure registry credentials on the Sysdig-side, nor open up the registry endpoints to be accessed over public networks

If the node image analyzer is installed, there is no longer any need to manually trigger running image scans.

Installing the Image Analyzer

Otherwise, the Image Analyzer is now deployed as a part of the Node Analyzer: Multi-Feature Installation.

Manually Scan an Image

If the node image analyzer is not installed, then when a new image is added to a running environment it may need to be scanned manually. This can be done from either the Runtime tab, or the Scan Results tab.

From the Runtime Tab

To manually scan an image from the Runtime tab:

1. From the Scanning module, choose the Runtime tab.

   

2. Sort by Unscanned and select an image from the list of unscanned images.

   

3. Click Scan Now if the option is displayed. You may be prompted to install the Image Analyzer if the digest could not be detected.

From the Image Results Tab

1. From the Scanning module, choose the Image Results tab.

2. Click Scan Image.

3. Define the path to the image, and click Scan.

5.4 -

Manage Scanning Policies

Image scanning policies define several scenarios, such as:

• The build process may be stopped.

• Administrators may be alerted to potential risks within container images.

Each scanning policy is comprised of rules built of gates and triggers. Sysdig includes default policies that can be used to run scans as soon as registry credentials have been configured.

Users can create additional rules or policies from the available Scanning Policy Gates and Triggers.

Preconfigured Policies

Sysdig provides a number of Default (read-only) baseline policies that can be used as-is or as templates on which to build.

DefaultPolicy

This policy covers the most common image scanning cases, such as:

• checking for high vulnerabilities that have a fix available

• checking Dockerfile best practices (e.g., ensuring health checks in an image or disallowing exposed ports)

• validating that the vulnerability feed data is up-to-date.

This policy is a basic catch-all that cannot be deleted. If no other policy assignments are made, the Default policy is automatically used.

Dockerfile Best Practices

This policy provides out-of-the-box rules around Dockerfile best practices, such as disallowing:

• secrets baked in as environment variables

• root user configuration

• exposed ports

• run instructions that include yum upgrades.

Preconfigured Compliance Policies

The remaining preconfigured default policies deal with compliance rules such as NIST 800, PCI, GDPR, HIPAA, ISO 270001:2013 and SCO2

Audit Policy - NIST 800-190

This policy maps NIST 800-190 controls to a Sysdig Secure scanning policy, such as disallowing:

• non-official node or Ruby packages

• add instructions in a Docker file

• the use of base distributions outside of expected values.

Audit Policy - PCI

This policy maps PCI (Payment Card Industry) controls to a Sysdig Secure scanning policy, such as disallowing vulnerabilities or credentials to be included in the image.

Customized Policies

You can’t edit a Default Policy - instead use the Duplicate Policy function and then customize it.

Create a Scanning Policy

1. From the Image Scanning module, select Scanning Policies and click Add Policy(+).

   The New Policy page is displayed.

   

2. Define a Name and an optional Description for the new policy.

3. Add a Rule:

   Select the Gate and then the Trigger from the drop-down menus.

   Configure relevant parameters. (Some triggers do not require parameters to be set.)

   See Scanning Policy Gates and Triggers for details on each option.

   The example below uses the vulnerabilities gate with the package  trigger.

   

1. Optional: Repeat step 5 to add rules as necessary.

2. Click Save.

Edit a Policy

1. From the Image Scanning module, select Scanning Policies.

2. Select the desired policy from the list.

3. Edit the policy rules as required, and click Save Policy.

Delete a Policy

1. From the Image Scanning module, select Scanning Policies.

2. Select the desired policy from the list.

3. Click the Delete (trash can) icon and choose Yes to confirm the change.

Globally Trust|Untrust

You can add images to a globally trusted or untrusted list, or put CVEs on defined Global Exceptions lists, if desired. See Manage Vulnerability Exceptions and Global Lists. This does not affect the policy evaluation order.

Manage Policy Assignments

Unless you use a very simple, single-policy approach to scanning, you will probably assign particular policies to particular registries, repositories, or tags.

Use the Policy Assignments page to do this.

For example:

• To evaluate all images with a “Prod” tag with your Example Prod Image Policy, use the assignment (registry/repo/tag): */*/Prod

• To evaluate all images from gcr.io with an Example Google Policy, use the assignment (registry/repo/tag): gcr.io/*/*

Assign a Policy

1. From the Image Scanning module, select Scanning Policies and choose +Policy Assignments.

   The previously defined assignments are listed in priority order.

   

2. Click +Add Policy Assignment.

   A new entry line appears at the top of the Assignment page. Enter the desired assignment details:

   1. Priority: Priority is the order of evaluation against the assigned policy. Each new assignment is auto-placed at Priority 1. Once a policy assignment is created and saved, you can change its priority order by dragging it into a new position on the list. See also Using Priorities.

   2. Registry: Any registry domain (e.g. quay.io). Wildcards are supported; an asterisk * specifies any registry.

   3. Repository: Any repository (typically = name of the image). Wildcards are supported; an asterisk * specifies any repository.

   4. Tag: Any tag. Wildcards are supported; an asterisk * specifies any tag.

   5. Assigned Policy: Name of policy to use for evaluation. Select from the drop-down menu.

3. Click Save.

4. Optional: Reorganize the Priority order by clicking the drag handle (the four dots to the left of a line) and dragging the assignment to a different spot on the list.

Using Priorities

When you use more than one scanning policy, the Anchore engine evaluates them in top-down order, starting from Priority 1 in the Policy Assignment list. The first policy assignment rule that matches an input image will be evaluated, and all subsequent rules ignored. Therefore, the priority order is important.

There is a catch-all entry at the bottom of the Policy Assignment list that cannot be removed. It has the format :

registry = * repository = * tag = * assigned policy = default

(You can change the assigned policy, but other fields cannot be edited.)

The purpose of this row is to ensure that any registries that do not fall under another policy evaluation will at least be evaluated against the system-configured DefaultPolicy.

5.4.1 -

Manage Vulnerability Exceptions and Global Lists

Sysdig Secure allows users to put specific CVEs on Global Exception lists. Common reasons to exempt a vulnerability from consideration while scanning an image include, for example:

• Knowing that the vuln does not apply to your runtime or cannot be exploited

• Knowing that the suggested “fix version” will break a chain of dependencies, and you plan to evaluate how to patch this vulnerability in more detail

• Knowing that there is no available fix for the vulnerability yet and you absolutely must deploy this application in production. (You decide to use a temporary alternate security strategy to protect from the vulnerability.)

When devising exception lists, you can detail what exceptions you introduce, for which images, and for how long, establishing a vulnerability exception management workflow.

Additionally, specific images can be marked as untrusted or globally trusted to ensure they always/never pass a scan.

Create Multiple Exception Lists

By default, a single list is provided. Its name, Default exceptions list, can be retitled or removed if desired.

To create additional lists:

1. Select Image Scanning > Vulnerability Exceptions and click the Add button on the left side of the screen.

   

2. Enter a Name and Description and click Save.

   Hover over the info bubble on an existing list to see its name, description, and last-modified date.

3. For an exception list to be applied to an image during a scan, you must set up a scanning policy assignment to map the image to the list.

Add a Vulnerability to a List

There are two ways to add a vulnerability to a list: from the Exceptions List page, or from the Scan Results.

From the Exceptions List Page

1. SelectImage Scanning > Vulnerability Exceptions and choose the desired list from the left menu. (In this example, the Exception list is named “Python exceptions”.)

2. Click the Add button on the right side of the screen.

3. Enter the identifying details:

   

   • VULN ID: Required

   • Expiration Date: Required, but can be ‘never’

   • Note Optional.

From the Scan Results

The scan results for an image may flag vulnerabilities you don’t consider necessary. From the results list, you can quickly append those entries to exception lists as follows:

1. Select Image Scanning > Scan Results.

2. Select the Vulnerability type from the left menu and review the resulting list of flagged vulnerabilities.

   Note: The Exceptions column displays the number of lists already containing this vulnerability.

   

3. Click the hover button to open the “Add Exception” dialog .

   

4. Enter the details and click Save.

   • List: Sysdig will indicate with a “radar” icon the lists that are being applied to this image according to the policy assignments which are relevant for the evaluation of this particular image

     You can also enter additional list names in the field to create a new list.

   • Expiration Date: Required, but can be ‘never’

   • Note Optional.

Manage Vulnerabilities in a List

An exception list can contain any number of vulnerabilities. Each vulnerability listing displays additional properties to help the security team understand the context, feed sources, and the justification and time span for the vulnerability to be on the list.

Fields in the List View

Select Image Scanning > Vulnerability Exceptions and choose a list from the left menu to review the vulnerability list details.

Review the column data:

• Enabled: On/off toggle for whether the exception for this vulnerability is active. If the vulnerability exception is disabled, it will not disappear from the list but will not be taken into account when evaluating an image. Rows that have met their expiration date are automatically disabled.

• Name: String entered by the user to identify the vulnerability. For example, CVE-2019-9639 or VULNDB-213986.

• Description: Vulnerability description, provided by Sysdig once the Vuln ID is provided by the user.

• Notes: User-defined exception notes. Could be used to justify the decision or to append any additional links or information.

• Expiration date: Day configured by the user for this exception to expire.

  • Default is never, for a vulnerability that should not expire. If an expiration is set, then day is the minimum time resolution.

  • All expiration dates are evaluated against 0:00 UTC timezone

Access and Edit Additional Details

Click on an exception row to see additional details about the vulnerability and to edit its properties.

You can:

• View the full description

• View and modify user notes

• View and modify Expiration date

  Disabled exceptions cannot be re-enabled until a future date is set.

• View segmented feed information, for every feed that is reporting this vulnerability:

  • Severity of the vulnerability as reported per each individual feed (color-coded)

  • Link to vulnerability details as provided per feed

Add Images to a Global List

There are two ways to add images to a Global Trusted or Untrusted list: from the list or from a scan result.

From the Global list:

1. From the Image Scanning module, select either Global - Trusted Images or Global - Untrusted Images.

   The list of previously added images is displayed.

2. Click the Add Image button.

3. Add each image in a comma-separated list, then click Ok.

   A tag name must be valid ASCII and may contain lowercase and uppercase letters, digits, underscores, periods and dashes.

   A tag name may not start with a period or a dash and may contain a maximum of 128 characters.

From the Scan Results:

1. From the Image Scanning module, choose the Scan Results tab.

2. Select the relevant repository from the list and open the relevant image.

3. Click Add to List at the top of the page.

   

4. Select either Add Image to Trusted Images or Add Image to Untrusted Images as needed.

5.4.2 -

Scanning Policy Gates and Triggers

This document describes the gates (and their respective triggers / parameters) that are supported within Sysdig Secure policy bundles. Use these policy gates, triggers, and parameters to build in-depth scanning policies, from whitelisting / blacklisting partial file names to defining what login shells are approved.

user@host:~$ anchore-cli policy describe (--gate <gatename> (--trigger <triggername))

For more information, see Manage Scanning Policies and Dockerfile Gate and Triggers Deep Dive.

Always

This gate provides users with a valuable testing resource, as it will be triggered unconditionally.

always

The always trigger / gate will trip if it is present in the policy.

Dockerfile

The dockerfile gate reviews the contents of a Dockerfile, or the assumed contents of a dockerfile if one is not provided, for exposed ports and instructions that do not follow best practices.

effective_user

This trigger reviews whether the effective user matches the user provided, and will fire based on the configured type.

exposed_ports

This trigger evaluates the set of exposed ports to determine whether they should be whitelisted or blacklisted.

instruction

This trigger evaluates whether any directives/instructions in the list match the conditions in the Dockerfile.

no_dockerfile_provided

This trigger will trip if there is no Dockerfile supplied with the image. No parameters are required for this trigger.

Files

The Files gate reviews files within the analyzed image. This evaluation covers file content, names, and filesystem attributes.

content_regex_match

This trigger is tripped for each file where a match has been found using the configured regex in the analyzer_config.yaml content_search section.

name_match

This trigger is tripped if the name of a file in the container matches the provided regex.

suid_or_guid_set

This trigger is tripped for each file that has a set-user identification (SUID) or set-group identification (SGID) configured. No parameters are required.

Licenses

This gate is used to review software licenses found in the container image, to ensure, for example, that packages that violate internal company policy are not being used.

blacklist_exact_match

This trigger will be tripped if the image contains packages distributed under the exact license specified.

blacklist_partial_match

This trigger will be tripped if the image contains packages distributed under a license that includes the partial strings provided.

Metadata

This gate reviews image metadata, including the size, operating system, and architecture.

attribute

The attribute trigger is tripped if a named image metadata value matches the given condition.

Packages

The Packages gate reviews all packages within the image, verifying names, versions, and whitelisted / blacklisted packages.

blacklist

This trigger is tripped if the image contains packages that have been blacklisted by either name, or name and version.

required_package

The required_package trigger is tripped if the specified package / version is not found in the image.

verify

This trigger reviews the package integrity against the package database in the image, and is tripped for change or removal of content in either all or a defined list of directories provided.

Passwd File

This gate reviews /etc/passwd for blacklisted users, groups, and shells.

blacklist_full_entry

This trigger trips if the whole password is found in the /etc/password file.

blacklist_groupids

This trigger is tripped if the designated group id/s are found in the /etc/passwd file.

blacklist_shells

This trigger will trip if a designated login shell is found under any user in the /etc/passwd file.

blacklist_userids

This trigger will be tripped if the specified user ID is present in /etc/passwd.

blacklist_usernames

The blacklist_usernames trigger will trip if the specified username is found in the /etc/passwd file.

content_not_available

The content_not_available trigger will trip if the /etc/passwd file is not present in the image. No parameters are required.

Secret Scans

Secret scans determine, based on configured regex, whether secrets that could be available if an image was compromised have been baked into the image.

content_regex_checks

The content_regex_checks trigger trips if the content search analyzer finds a match with the configured and named regexes. Matches are filtered by the content_regex_name, and the filename_regex, if either are set.

Vulnerabilities

CVE / vulnerability checks can be used to ensure the included packages don’t have vulnerabilities above a set level, are older than a designated period, or if data is unavailable.

package

The package trigger is tripped if a vulnerability in an image matches the configured comparison criteria. The table below outlines the available parameters and criteria:

stale_feed_data

The stale_feed_data trigger will be tripped if the CVE data is older than the window specified.

vulnerability_data_unavailable

If no vulnerability data is available, the vulnerability_data_unavailable trigger will trip. No parameters are required for this trigger.

5.4.3 -

Dockerfile Gate and Triggers Deep Dive

This article reviews the dockerfile gate and its triggers. Review the documentation from Docker if you want more background on Dockerfiles themselves.

Conventions note: In this article, “Dockerfile” refers to the actual file, while “dockerfile” refers to the Sysdig Secure gate used in Policies.

The dockerfile gate in Sysdig Secure allows users to perform checks on the content of the Dockerfile, or the Docker history for an image, and make policy actions based on the construction of an image, not just its content. This is particularly useful for enforcing best practices or metadata inclusion (e.g. labels) on images.

Sysdig is either given a Dockerfile or infers one from the docker image layer history. There are implications to what data is available and what it means depending on these differing sources, so first, we’ll cover the input data for the gate and how it impacts the triggers and parameters used.

The “Dockerfile”

The data that this gate operates on can come from two different sources:

1. The actual Dockerfile used to build an image, as provided by the user at the time of running sdc-cli image add <img ref> --dockerfile <filename>; or the corresponding API call to: POST /images?dockerfile=

2. The history from layers as encoded in the image itself (see docker history<img>for this output)

All images have data from history available, but data from the actual Dockerfile is only available when a user provides it. This also means that any images analyzed by automated alerts or the image analyzer will not have an actual Dockerfile.

Differences between Dockerfile and Docker History

Actual Dockerfile

• FROM line is preserved, so the parent tag of the image is easily available

• Instruction checks are all against instructions created during the build for that exact image, not any parent images

  Note: When the actual_dockerfile_only parameter is set to true, all instructions from the parent image are ignored in policy processing. This may have some unexpected consequences depending on how your images are structured and layered (e.g. golden base images that establish common patterns of volumes, labels, healthchecks).

• COPY/ADD instructions will maintain the actual values used

• Multistage-builds in that specific dockerfile will be visible with multiple FROM lines in the output

Docker history data (with no Dockerfile provided)

This is a best-effort option and can catch some things, but not all.

• FROM line is not accurate, and will nearly always default to FROM scratch

• Instructions are processed from all layers in the image

• COPY and ADD instructions are transformed into SHAs rather than the actual file path/name used at build-time

• Multi-stage builds are not tracked with multiple FROM lines, only the copy operations between the phases

Using the actual_dockerfile_only Parameter to Avoid Checking History

The actual file vs history impacts the semantics of the Dockerfile gate’s triggers. To allow explicit control of the differences, most triggers in this gate includes a parameter: actual_dockerfile_only that if set to true or false will ensure the trigger check is only done on the source of data specified.

If actual_dockerfile_only = true, then the trigger will evaluate only if an actual Dockerfile is available for the image and will skip evaluation if not.

If actual_dockerfile_only is false or omitted, then the trigger will run on the actual Dockerfile if available, or the history data if the Dockerfile was not provided.

Understanding the FROM Line

In the actual Dockerfile, the FROM instruction is preserved and available as used to build the image. However, in the history data, the FROM line will always be the very first FROM instruction used (to build the image and all of its dependent images). In this case, the value in the history will be omitted and the scanning engine will automatically infer a FROM-scratch line, which is logically inserted for this gate if the history does not contain an explicit FROM entry.

The files below show how this would play out. See also: Using the Parameter to Avoid Checking History, to work around this outcome.

For example, using the docker.io/jenkins/jenkins image:

IMAGE                                                                     CREATED             CREATED BY                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                       SIZE                COMMENT
sha256:3b9c9666a66e53473c05a3c69eb2cb888a8268f76935eecc7530653cddc28981   11 hours ago        /bin/sh -c #(nop) COPY file:3a15c25533fd87983edc33758f62af7b543ccc3ce9dd570e473eb0702f5f298e in /usr/local/bin/install-plugins.sh                                                                                                                                                                                                                                                                                                                                                                                                                                8.79kB
<missing>                                                                 11 hours ago        /bin/sh -c #(nop) COPY file:f97999fac8a63cf8b635a54ea84a2bc95ae3da4d81ab55267c92b28b502d8812 in /usr/local/bin/plugins.sh                                                                                                                                                                                                                                                                                                                                                                                                                                        3.96kB
<missing>                                                                 11 hours ago        /bin/sh -c #(nop)  ENTRYPOINT ["/sbin/tini" "--" "/usr/local/bin/jenkins.sh"]                                                                                                                                                                                                                                                                                                                                                                                                                                                                                    0B
<missing>                                                                 11 hours ago        /bin/sh -c #(nop) COPY file:dc942ca949bb159f81bbc954773b3491e433d2d3e3ef90bac80ecf48a313c9c9 in /bin/tini                                                                                                                                                                                                                                                                                                                                                                                                                                                        529B
<missing>                                                                 11 hours ago        /bin/sh -c #(nop) COPY file:a8f986413b77bf4d88562b9d3a0dce98ab6e75403192aa4d4153fb41f450843d in /usr/local/bin/jenkins.sh                                                                                                                                                                                                                                                                                                                                                                                                                                        1.45kB
<missing>                                                                 11 hours ago        /bin/sh -c #(nop) COPY file:55594d9d2aed007553a6743a43039b1a48b30527f8fb991ad93e1fd5b1298f60 in /usr/local/bin/jenkins-support                                                                                                                                                                                                                                                                                                                                                                                                                                   6.12kB
<missing>                                                                 11 hours ago        /bin/sh -c #(nop)  USER jenkins                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                  0B
<missing>                                                                 11 hours ago        /bin/sh -c #(nop)  ENV COPY_REFERENCE_FILE_LOG=/var/jenkins_home/copy_reference_file.log                                                                                                                                                                                                                                                                                                                                                                                                                                                                         0B
<missing>                                                                 11 hours ago        /bin/sh -c #(nop)  EXPOSE 50000                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                  0B
<missing>                                                                 11 hours ago        /bin/sh -c #(nop)  EXPOSE 8080                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                   0B
<missing>                                                                 11 hours ago        |9 JENKINS_SHA=e026221efcec9528498019b6c1581cca70fe9c3f6b10303777d85c6699bca0e4 JENKINS_URL=https://repo.jenkins-ci.org/public/org/jenkins-ci/main/jenkins-war/2.161/jenkins-war-2.161.war TINI_VERSION=v0.16.1 agent_port=50000 gid=1000 group=jenkins http_port=8080 uid=1000 user=jenkins /bin/sh -c chown -R ${user} "$JENKINS_HOME" /usr/share/jenkins/ref                                                                                                                                                                                                  328B
<missing>                                                                 11 hours ago        /bin/sh -c #(nop)  ENV JENKINS_INCREMENTALS_REPO_MIRROR=https://repo.jenkins-ci.org/incrementals                                                                                                                                                                                                                                                                                                                                                                                                                                                                 0B
<missing>                                                                 11 hours ago        /bin/sh -c #(nop)  ENV JENKINS_UC_EXPERIMENTAL=https://updates.jenkins.io/experimental                                                                                                                                                                                                                                                                                                                                                                                                                                                                           0B
<missing>                                                                 11 hours ago        /bin/sh -c #(nop)  ENV JENKINS_UC=https://updates.jenkins.io                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                     0B
<missing>                                                                 11 hours ago        |9 JENKINS_SHA=e026221efcec9528498019b6c1581cca70fe9c3f6b10303777d85c6699bca0e4 JENKINS_URL=https://repo.jenkins-ci.org/public/org/jenkins-ci/main/jenkins-war/2.161/jenkins-war-2.161.war TINI_VERSION=v0.16.1 agent_port=50000 gid=1000 group=jenkins http_port=8080 uid=1000 user=jenkins /bin/sh -c curl -fsSL ${JENKINS_URL} -o /usr/share/jenkins/jenkins.war   && echo "${JENKINS_SHA}  /usr/share/jenkins/jenkins.war" | sha256sum -c -                                                                                                                  76MB
<missing>                                                                 11 hours ago        /bin/sh -c #(nop)  ARG JENKINS_URL=https://repo.jenkins-ci.org/public/org/jenkins-ci/main/jenkins-war/2.161/jenkins-war-2.161.war                                                                                                                                                                                                                                                                                                                                                                                                                                0B
<missing>                                                                 11 hours ago        /bin/sh -c #(nop)  ARG JENKINS_SHA=5bb075b81a3929ceada4e960049e37df5f15a1e3cfc9dc24d749858e70b48919                                                                                                                                                                                                                                                                                                                                                                                                                                                              0B
<missing>                                                                 11 hours ago        /bin/sh -c #(nop)  ENV JENKINS_VERSION=2.161                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                     0B
<missing>                                                                 11 hours ago        /bin/sh -c #(nop)  ARG JENKINS_VERSION                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                           0B
<missing>                                                                 11 hours ago        /bin/sh -c #(nop) COPY file:c84b91c835048a52bb864c1f4662607c56befe3c4b1520b0ea94633103a4554f in /usr/share/jenkins/ref/init.groovy.d/tcp-slave-agent-port.groovy                                                                                                                                                                                                                                                                                                                                                                                                 328B
<missing>                                                                 11 hours ago        |7 TINI_VERSION=v0.16.1 agent_port=50000 gid=1000 group=jenkins http_port=8080 uid=1000 user=jenkins /bin/sh -c curl -fsSL https://github.com/krallin/tini/releases/download/${TINI_VERSION}/tini-static-$(dpkg --print-architecture) -o /sbin/tini   && curl -fsSL https://github.com/krallin/tini/releases/download/${TINI_VERSION}/tini-static-$(dpkg --print-architecture).asc -o /sbin/tini.asc   && gpg --no-tty --import ${JENKINS_HOME}/tini_pub.gpg   && gpg --verify /sbin/tini.asc   && rm -rf /sbin/tini.asc /root/.gnupg   && chmod +x /sbin/tini   866kB
<missing>                                                                 11 hours ago        /bin/sh -c #(nop) COPY file:653491cb486e752a4c2b4b407a46ec75646a54eabb597634b25c7c2b82a31424 in /var/jenkins_home/tini_pub.gpg                                                                                                                                                                                                                                                                                                                                                                                                                                   7.15kB
<missing>                                                                 11 hours ago        /bin/sh -c #(nop)  ARG TINI_VERSION=v0.16.1                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                      0B
<missing>                                                                 11 hours ago        |6 agent_port=50000 gid=1000 group=jenkins http_port=8080 uid=1000 user=jenkins /bin/sh -c mkdir -p /usr/share/jenkins/ref/init.groovy.d                                                                                                                                                                                                                                                                                                                                                                                                                         0B
<missing>                                                                 11 hours ago        /bin/sh -c #(nop)  VOLUME [/var/jenkins_home]                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                    0B
<missing>                                                                 11 hours ago        |6 agent_port=50000 gid=1000 group=jenkins http_port=8080 uid=1000 user=jenkins /bin/sh -c mkdir -p $JENKINS_HOME   && chown ${uid}:${gid} $JENKINS_HOME   && groupadd -g ${gid} ${group}   && useradd -d "$JENKINS_HOME" -u ${uid} -g ${gid} -m -s /bin/bash ${user}                                                                                                                                                                                                                                                                                            328kB
<missing>                                                                 11 hours ago        /bin/sh -c #(nop)  ENV JENKINS_SLAVE_AGENT_PORT=50000                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                            0B
<missing>                                                                 11 hours ago        /bin/sh -c #(nop)  ENV JENKINS_HOME=/var/jenkins_home                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                            0B
<missing>                                                                 11 hours ago        /bin/sh -c #(nop)  ARG JENKINS_HOME=/var/jenkins_home                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                            0B
<missing>                                                                 11 hours ago        /bin/sh -c #(nop)  ARG agent_port=50000                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                          0B
<missing>                                                                 11 hours ago        /bin/sh -c #(nop)  ARG http_port=8080                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                            0B
<missing>                                                                 11 hours ago        /bin/sh -c #(nop)  ARG gid=1000                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                  0B
<missing>                                                                 11 hours ago        /bin/sh -c #(nop)  ARG uid=1000                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                  0B
<missing>                                                                 11 hours ago        /bin/sh -c #(nop)  ARG group=jenkins                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                             0B
<missing>                                                                 11 hours ago        /bin/sh -c #(nop)  ARG user=jenkins                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                              0B
<missing>                                                                 11 hours ago        /bin/sh -c apt-get update && apt-get install -y git curl && rm -rf /var/lib/apt/lists/*                                                                                                                                                                                                                                                                                                                                                                                                                                                                          0B
<missing>                                                                 3 weeks ago         /bin/sh -c set -ex;   if [ ! -d /usr/share/man/man1 ]; then   mkdir -p /usr/share/man/man1;  fi;   apt-get update;  apt-get install -y --no-install-recommends   openjdk-8-jdk="$JAVA_DEBIAN_VERSION"  ;  rm -rf /var/lib/apt/lists/*;   [ "$(readlink -f "$JAVA_HOME")" = "$(docker-java-home)" ];   update-alternatives --get-selections | awk -v home="$(readlink -f "$JAVA_HOME")" 'index($3, home) == 1 { $2 = "manual"; print | "update-alternatives --set-selections" }';  update-alternatives --query java | grep -q 'Status: manual'                    348MB
<missing>                                                                 3 weeks ago         /bin/sh -c #(nop)  ENV JAVA_DEBIAN_VERSION=8u181-b13-2~deb9u1                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                    0B
<missing>                                                                 3 weeks ago         /bin/sh -c #(nop)  ENV JAVA_VERSION=8u181                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                        0B
<missing>                                                                 3 weeks ago         /bin/sh -c #(nop)  ENV JAVA_HOME=/docker-java-home                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                               0B
<missing>                                                                 3 weeks ago         /bin/sh -c ln -svT "/usr/lib/jvm/java-8-openjdk-$(dpkg --print-architecture)" /docker-java-home                                                                                                                                                                                                                                                                                                                                                                                                                                                                  33B
<missing>                                                                 3 weeks ago         /bin/sh -c {   echo '#!/bin/sh';   echo 'set -e';   echo;   echo 'dirname "$(dirname "$(readlink -f "$(which javac || which java)")")"';  } > /usr/local/bin/docker-java-home  && chmod +x /usr/local/bin/docker-java-home                                                                                                                                                                                                                                                                                                                                       87B
<missing>                                                                 3 weeks ago         /bin/sh -c #(nop)  ENV LANG=C.UTF-8                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                              0B
<missing>                                                                 3 weeks ago         /bin/sh -c apt-get update && apt-get install -y --no-install-recommends   bzip2   unzip   xz-utils  && rm -rf /var/lib/apt/lists/*                                                                                                                                                                                                                                                                                                                                                                                                                               2.21MB
<missing>                                                                 3 weeks ago         /bin/sh -c apt-get update && apt-get install -y --no-install-recommends   bzr   git   mercurial   openssh-client   subversion     procps  && rm -rf /var/lib/apt/lists/*                                                                                                                                                                                                                                                                                                                                                                                         142MB
<missing>                                                                 3 weeks ago         /bin/sh -c set -ex;  if ! command -v gpg > /dev/null; then   apt-get update;   apt-get install -y --no-install-recommends    gnupg    dirmngr   ;   rm -rf /var/lib/apt/lists/*;  fi                                                                                                                                                                                                                                                                                                                                                                             7.81MB
<missing>                                                                 3 weeks ago         /bin/sh -c apt-get update && apt-get install -y --no-install-recommends   ca-certificates   curl   netbase   wget  && rm -rf /var/lib/apt/lists/*                                                                                                                                                                                                                                                                                                                                                                                                                23.2MB
<missing>                                                                 3 weeks ago         /bin/sh -c #(nop)  CMD ["bash"]                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                  0B
<missing>                                                                 3 weeks ago         /bin/sh -c #(nop) ADD file:da71baf0d22cb2ede91c5e3ff959607e47459a9d7bda220a62a3da362b0e59ea in /                                                                                                                                                                                                                                                                                                                                                                                                                                                                 101MB

Where the actual dockerfile for that image is:
FROM openjdk:8-jdk-stretch

RUN apt-get update && apt-get install -y git curl && rm -rf /var/lib/apt/lists/*

ARG user=jenkins
ARG group=jenkins
ARG uid=1000
ARG gid=1000
ARG http_port=8080
ARG agent_port=50000
ARG JENKINS_HOME=/var/jenkins_home

ENV JENKINS_HOME $JENKINS_HOME
ENV JENKINS_SLAVE_AGENT_PORT ${agent_port}

# Jenkins is run with user `jenkins`, uid = 1000
# If you bind mount a volume from the host or a data container,
# ensure you use the same uid
RUN mkdir -p $JENKINS_HOME \
  && chown ${uid}:${gid} $JENKINS_HOME \
  && groupadd -g ${gid} ${group} \
  && useradd -d "$JENKINS_HOME" -u ${uid} -g ${gid} -m -s /bin/bash ${user}

# Jenkins home directory is a volume, so configuration and build history
# can be persisted and survive image upgrades
VOLUME $JENKINS_HOME

# `/usr/share/jenkins/ref/` contains all reference configuration we want
# to set on a fresh new installation. Use it to bundle additional plugins
# or config file with your custom jenkins Docker image.
RUN mkdir -p /usr/share/jenkins/ref/init.groovy.d

# Use tini as subreaper in Docker container to adopt zombie processes
ARG TINI_VERSION=v0.16.1
COPY tini_pub.gpg ${JENKINS_HOME}/tini_pub.gpg
RUN curl -fsSL https://github.com/krallin/tini/releases/download/${TINI_VERSION}/tini-static-$(dpkg --print-architecture) -o /sbin/tini \
  && curl -fsSL https://github.com/krallin/tini/releases/download/${TINI_VERSION}/tini-static-$(dpkg --print-architecture).asc -o /sbin/tini.asc \
  && gpg --no-tty --import ${JENKINS_HOME}/tini_pub.gpg \
  && gpg --verify /sbin/tini.asc \
  && rm -rf /sbin/tini.asc /root/.gnupg \
  && chmod +x /sbin/tini

COPY init.groovy /usr/share/jenkins/ref/init.groovy.d/tcp-slave-agent-port.groovy

# jenkins version being bundled in this docker image
ARG JENKINS_VERSION
ENV JENKINS_VERSION ${JENKINS_VERSION:-2.121.1}

# jenkins.war checksum, download will be validated using it
ARG JENKINS_SHA=5bb075b81a3929ceada4e960049e37df5f15a1e3cfc9dc24d749858e70b48919

# Can be used to customize where jenkins.war get downloaded from
ARG JENKINS_URL=https://repo.jenkins-ci.org/public/org/jenkins-ci/main/jenkins-war/${JENKINS_VERSION}/jenkins-war-${JENKINS_VERSION}.war

# could use ADD but this one does not check Last-Modified header neither does it allow to control checksum
# see https://github.com/docker/docker/issues/8331
RUN curl -fsSL ${JENKINS_URL} -o /usr/share/jenkins/jenkins.war \
  && echo "${JENKINS_SHA}  /usr/share/jenkins/jenkins.war" | sha256sum -c -

ENV JENKINS_UC https://updates.jenkins.io
ENV JENKINS_UC_EXPERIMENTAL=https://updates.jenkins.io/experimental
ENV JENKINS_INCREMENTALS_REPO_MIRROR=https://repo.jenkins-ci.org/incrementals
RUN chown -R ${user} "$JENKINS_HOME" /usr/share/jenkins/ref

# for main web interface:
EXPOSE ${http_port}

# will be used by attached slave agents:
EXPOSE ${agent_port}

ENV COPY_REFERENCE_FILE_LOG $JENKINS_HOME/copy_reference_file.log

USER ${user}

COPY jenkins-support /usr/local/bin/jenkins-support
COPY jenkins.sh /usr/local/bin/jenkins.sh
COPY tini-shim.sh /bin/tini
ENTRYPOINT ["/sbin/tini", "--", "/usr/local/bin/jenkins.sh"]

# from a derived Dockerfile, can use `RUN plugins.sh active.txt` to setup /usr/share/jenkins/ref/plugins from a support bundle
COPY plugins.sh /usr/local/bin/plugins.sh
COPY install-plugins.sh /usr/local/bin/install-plugins.sh

Where the actual Dockerfile for that image is:

FROM openjdk:8-jdk-stretch

RUN apt-get update && apt-get install -y git curl && rm -rf /var/lib/apt/lists/*

ARG user=jenkins
ARG group=jenkins
ARG uid=1000
ARG gid=1000
ARG http_port=8080
ARG agent_port=50000
ARG JENKINS_HOME=/var/jenkins_home

ENV JENKINS_HOME $JENKINS_HOME
ENV JENKINS_SLAVE_AGENT_PORT ${agent_port}

# Jenkins is run with user `jenkins`, uid = 1000
# If you bind mount a volume from the host or a data container,
# ensure you use the same uid
RUN mkdir -p $JENKINS_HOME \
  && chown ${uid}:${gid} $JENKINS_HOME \
  && groupadd -g ${gid} ${group} \
  && useradd -d "$JENKINS_HOME" -u ${uid} -g ${gid} -m -s /bin/bash ${user}

# Jenkins home directory is a volume, so configuration and build history
# can be persisted and survive image upgrades
VOLUME $JENKINS_HOME

# `/usr/share/jenkins/ref/` contains all reference configuration we want
# to set on a fresh new installation. Use it to bundle additional plugins
# or config file with your custom jenkins Docker image.
RUN mkdir -p /usr/share/jenkins/ref/init.groovy.d

# Use tini as subreaper in Docker container to adopt zombie processes
ARG TINI_VERSION=v0.16.1
COPY tini_pub.gpg ${JENKINS_HOME}/tini_pub.gpg
RUN curl -fsSL https://github.com/krallin/tini/releases/download/${TINI_VERSION}/tini-static-$(dpkg --print-architecture) -o /sbin/tini \
  && curl -fsSL https://github.com/krallin/tini/releases/download/${TINI_VERSION}/tini-static-$(dpkg --print-architecture).asc -o /sbin/tini.asc \
  && gpg --no-tty --import ${JENKINS_HOME}/tini_pub.gpg \
  && gpg --verify /sbin/tini.asc \
  && rm -rf /sbin/tini.asc /root/.gnupg \
  && chmod +x /sbin/tini

COPY init.groovy /usr/share/jenkins/ref/init.groovy.d/tcp-slave-agent-port.groovy

# jenkins version being bundled in this docker image
ARG JENKINS_VERSION
ENV JENKINS_VERSION ${JENKINS_VERSION:-2.121.1}

# jenkins.war checksum, download will be validated using it
ARG JENKINS_SHA=5bb075b81a3929ceada4e960049e37df5f15a1e3cfc9dc24d749858e70b48919

# Can be used to customize where jenkins.war get downloaded from
ARG JENKINS_URL=https://repo.jenkins-ci.org/public/org/jenkins-ci/main/jenkins-war/${JENKINS_VERSION}/jenkins-war-${JENKINS_VERSION}.war

# could use ADD but this one does not check Last-Modified header neither does it allow to control checksum
# see https://github.com/docker/docker/issues/8331
RUN curl -fsSL ${JENKINS_URL} -o /usr/share/jenkins/jenkins.war \
  && echo "${JENKINS_SHA}  /usr/share/jenkins/jenkins.war" | sha256sum -c -

ENV JENKINS_UC https://updates.jenkins.io
ENV JENKINS_UC_EXPERIMENTAL=https://updates.jenkins.io/experimental
ENV JENKINS_INCREMENTALS_REPO_MIRROR=https://repo.jenkins-ci.org/incrementals
RUN chown -R ${user} "$JENKINS_HOME" /usr/share/jenkins/ref

# for main web interface:
EXPOSE ${http_port}

# will be used by attached slave agents:
EXPOSE ${agent_port}

ENV COPY_REFERENCE_FILE_LOG $JENKINS_HOME/copy_reference_file.log

USER ${user}

COPY jenkins-support /usr/local/bin/jenkins-support
COPY jenkins.sh /usr/local/bin/jenkins.sh
COPY tini-shim.sh /bin/tini
ENTRYPOINT ["/sbin/tini", "--", "/usr/local/bin/jenkins.sh"]

# from a derived Dockerfile, can use `RUN plugins.sh active.txt` to setup /usr/share/jenkins/ref/plugins from a support bundle
COPY plugins.sh /usr/local/bin/plugins.sh
COPY install-plugins.sh /usr/local/bin/install-plugins.sh

The scanning engine will detect the history/“dockerfile” as follows:

[
   {
      "Size" : 45323792,
      "Tags" : [],
      "Comment" : "",
      "Id" : "sha256:cd8eada9c7bb496eb685fc6d2198c33db7cb05daf0fde42e4cf5bf0127cbdf38",
      "Created" : "2018-12-28T23:29:37.981962131Z",
      "CreatedBy" : "/bin/sh -c #(nop) ADD file:da71baf0d22cb2ede91c5e3ff959607e47459a9d7bda220a62a3da362b0e59ea in / "
   },
   {
      "Size" : 0,
      "Tags" : [],
      "Comment" : "",
      "Id" : "<missing>",
      "Created" : "2018-12-28T23:29:38.226681736Z",
      "CreatedBy" : "/bin/sh -c #(nop)  CMD [\"bash\"]"
   },
   {
      "Size" : 10780911,
      "Comment" : "",
      "Tags" : [],
      "CreatedBy" : "/bin/sh -c apt-get update && apt-get install -y --no-install-recommends \t\tca-certificates \t\tcurl \t\tnetbase \t\twget \t&& rm -rf /var/lib/apt/lists/*",
      "Created" : "2018-12-29T00:04:28.920875483Z",
      "Id" : "sha256:c2677faec825930a8844845f55454ee0495ceb5bea9fc904d5b3125de863dc1d"
   },
   {
      "Comment" : "",
      "Tags" : [],
      "Size" : 4340024,
      "CreatedBy" : "/bin/sh -c set -ex; \tif ! command -v gpg > /dev/null; then \t\tapt-get update; \t\tapt-get install -y --no-install-recommends \t\t\tgnupg \t\t\tdirmngr \t\t; \t\trm -rf /var/lib/apt/lists/*; \tfi",
      "Created" : "2018-12-29T00:04:34.642152001Z",
      "Id" : "sha256:fcce419a96b1219a265bf7a933d66b585a6f8d73448533f3833c73ad49fb5e88"
   },
   {
      "Size" : 50062697,
      "Tags" : [],
      "Comment" : "",
      "Id" : "sha256:045b51e26e750443c84216071a1367a7aae0b76245800629dc04934628b4b1ea",
      "CreatedBy" : "/bin/sh -c apt-get update && apt-get install -y --no-install-recommends \t\tbzr \t\tgit \t\tmercurial \t\topenssh-client \t\tsubversion \t\t\t\tprocps \t&& rm -rf /var/lib/apt/lists/*",
      "Created" : "2018-12-29T00:04:59.676112605Z"
   },
 ... <truncated for brevity> ...
   {
      "Tags" : [],
      "Comment" : "",
      "Size" : 0,
      "Id" : "<missing>",
      "CreatedBy" : "/bin/sh -c #(nop)  ENTRYPOINT [\"/sbin/tini\" \"--\" \"/usr/local/bin/jenkins.sh\"]",
      "Created" : "2019-01-21T08:56:30.737221895Z"
   },
   {
      "Size" : 1549,
      "Tags" : [],
      "Comment" : "",
      "Id" : "sha256:283cd3aba8691a3b9d22d923de66243b105758e74de7d9469fe55a6a58aeee30",
      "Created" : "2019-01-21T08:56:32.015667468Z",
      "CreatedBy" : "/bin/sh -c #(nop) COPY file:f97999fac8a63cf8b635a54ea84a2bc95ae3da4d81ab55267c92b28b502d8812 in /usr/local/bin/plugins.sh "
   },
   {
      "Comment" : "",
      "Tags" : [],
      "Size" : 3079,
      "Created" : "2019-01-21T08:56:33.158854485Z",
      "CreatedBy" : "/bin/sh -c #(nop) COPY file:3a15c25533fd87983edc33758f62af7b543ccc3ce9dd570e473eb0702f5f298e in /usr/local/bin/install-plugins.sh ",
      "Id" : "sha256:b0ce8ab5a5a7da5d762f25af970f4423b98437a8318cb9852c3f21354cbf914f"
   }
]

Triggers

This section provides more detail on four triggers than is found in the Scanning Policy Gates and Triggers reference.

Trigger: instruction

This trigger evaluates instructions found in the “dockerfile”.

Parameters

• actual_dockerfile_only (optional). See Using the actual_dockerfile_only section, above.

• instruction: The dockerfile instruction to check against. One of:

  • ADD

  • ARG

  • COPY

  • CMD

  • ENTRYPOINT

  • ENV

  • EXPOSE

  • FROM

  • HEALTHCHECK

  • LABEL

  • MAINTAINER

  • ONBUILD

  • USER

  • RUN

  • SHELL

  • STOPSIGNAL

  • VOLUME

  • WORKDIR

• check: The comparison/evaluation to perform. One of: =, != , exists, not_exists, like, not_like, in, not_in

• value (optional): A string value to compare against, if applicable

Examples

Ensure an image has a HEALTHCHECK defined in the image. Warn if not found

{
  "gate": "dockerfile",
  "trigger": "instruction",
  "action": "warn",
  "parameters": [
    {
      "name": "instruction",
      "value": "HEALTHCHECK"
    },
    {
      "name": "check",
      "value": "not_exists"
    }
  ]
}

Check for AWS environment variables set

{
  "gate": "dockerfile",
  "trigger": "instruction",
  "action": "stop",
  "parameters": [
    {
      "name": "instruction",
      "value": "ENV"
    },
    {
      "name": "check",
      "value": "like"
    },
    {
      "name": "value",
      "value": "AWS_.*KEY"
    }
  ]
}

Trigger: effective_user

This trigger processes all USER directives in the Dockerfile or history to determine which user will be used to run the container by default (assuming no user is set explicitly at runtime). The detected value is then subject to a whitelist or blacklist filter depending on the configured parameters. Typically, this is used for blacklisting the root user.

Parameters

• actual_dockerfile_only (optional). See Using the actual_dockerfile_only section, above.

• users: A string with a comma-delimited list of username to check for

• type: The type of check to perform. One of: blacklist or whitelist. This determines how the value of the users parameter is interpreted.

Examples

Blacklist root user

{
  "gate": "dockerfile",
  "trigger": "effective_user",
  "action": "stop",
  "parameters": [
    {
      "name": "users",
      "value": "root"
    },
    {
      "name": "type",
      "value": "blacklist"
    }
  ]
}

Blacklist root user but only if set in actual Dockerfile, not inherited from parent image

{
  "gate": "dockerfile",
  "trigger": "effective_user",
  "action": "stop",
  "parameters": [
    {
      "name": "users",
      "value": "root"
    },
    {
      "name": "type",
      "value": "blacklist"
    },
    {
      "name": "actual_dockerfile_only",
      "value": "true"
    }
  ]
}

Warn if the user is not either “nginx” or “jenkins”

{
  "gate": "dockerfile",
  "trigger": "effective_user",
  "action": "warn",
  "parameters": [
    {
      "name": "users",
      "value": "nginx,jenkins"
    },
    {
      "name": "type",
      "value": "whitelist"
    }
  ]
}

Trigger: exposed_ports

This trigger allows checks on the way the image was added, firing if the Dockerfile was not explicitly provided at analysis time. This is useful in identifying and qualifying other trigger matches.

Parameters

• actual_dockerfile_only (optional). See Using the actual_dockerfile_only section, above.

• ports: String of comma-delimited port numbers to be checked

• type: The type of check to perform. One of: blacklist or whitelist. This determines how the value of the users parameter is interpreted.

Examples

Allow only ports 80 and 443. Trigger will fire on any port defined to be exposed that is not 80 or 443

{
  "gate": "dockerfile",
  "trigger": "exposed_ports",
  "action": "warn",
  "parameters": [
    {
      "name": "ports",
      "value": "80,443"
    },
    {
      "name": "type",
      "value": "whitelist"
    }
  ]
}

Blacklist ports 21 (ftp), 22 (ssh), and 53 (dns) . Trigger will fire a match on ports 21, 22, 53 if found in EXPOSE directives

{
  "gate": "dockerfile",
  "trigger": "exposed_ports",
  "action": "warn",
  "parameters": [
    {
      "name": "ports",
      "value": "21,22,53"
    },
    {
      "name": "type",
      "value": "blacklist"
    }
  ]
}

Trigger: no_dockerfile_provided

This trigger allows checks on the way the image was added, firing if the Dockerfile was not explicitly provided at analysis time. This is useful in identifying and qualifying other trigger matches.

Parameters

None

Examples

Raise a warning if no Dockerfile was provided at analysis time

{
  "gate": "dockerfile",
  "trigger": "no_dockerfile_provided",
  "action": "warn",
  "parameters": []
}

5.5 -

Manage Scanning Alerts

Image scanning alerts, like all Sysdig alerts, can be configured to notify users when an issue in the infrastructure arises. Scanning alerts can be created for static images in the repository or for running (runtime) images. Scanning alerts focus on when unscanned images are added to the environment, images fail a policy evaluation, scanning results change, or CVEs are updated.

Examples of when users might implement alerts:

• I want to know if there are new CVE updates for the 3 different images I handle

• I want to be notified if any of the common images from docker hub that are used all over my organization have a policy status that has changed

Manage the Scanning Alert List

From the Image Scanning module, choose the Alerts tab. The Scanning Alert list is displayed.

From here you can search for existing alerts, and create, duplicate or delete alerts.

Add an Alert

1. To create a new alert: From the Image Scanning module, choose the Alerts tab and click Add Alert.

2. Select either Runtime or Repository alert type.

3. Fill in the appropriate New Alert page (below).

Create a Runtime Alert

Use Runtime alerts to scan running images and trigger a notification in case of a policy violation, status change, or unscanned image added to the environment. Enter the alert parameters and click Save.

Basic Parameters

Enter a Name and optional Description.

Scope

Use Everywhere or define a narrower scope.

Triggers

Unscanned Image

Check the box to trigger an alert. To have images scanned automatically instead of simply triggering the alert, install the Node Image Analyzer.

Note that this is a change from the way automated scanning was handled in previous releases.

Scan Result Change

• Pass/Fail: Choose this option to be notified when an image that had previously passed now fails its policy evaluation.

• Any Change: Choose this option to be notified when there is any change on a previously scanned image result.

Note that if Scan Result Change is checked and a notification channel is configured, an alert will be sent. If no channel is set up, nothing will happen.

For example, the following image shows a Slack notification that was triggered when “Any Change” was configured.

CVE Update

Choose this option to be notified whenever a vulnerability is added, updated, or removed from a running image.

Notification Channel

Click **+ Add Channel **to select a configured notification channel (e.g. email) to be used for alert notifications.

If no notification channels have been defined for your Sysdig Secure environment yet, see Set Up Notification Channels.

Create a Repository Alert

Use Repository alerts to scan static images in the repository and trigger a notification in case of a policy violation, status change, or a new image added to the environment. Enter the alert parameters and click Save.

Basic Parameters

Enter a Name and optional Description.

Registry/Repo/Tag

Enter the registry scope to be considered in the alert. Wildcards * are supported. If a wildcard is used for either the registry or the repo, the only alert option will be New Image Analyzed.

Triggers

New Image Analyzed

Check the box to be alerted whenever a new image is analyzed, regardless of the result.

Scan Result Change

• Pass/Fail: Choose this option to be notified when an image that had previously passed now fails its policy evaluation.

• Any Change: Choose this option to be notified when there is any change on a previously scanned image result.

Note that if Scan Result Change is checked and a notification channel is configured, an alert will be sent. If no channel is set up, nothing will happen.

CVE Update

Choose this option to be notified whenever a vulnerability is added, updated, or removed from an image within the repository alert scope.

For example, the following image shows a Slack notification that was triggered when “CVE Update” was configured.

Notification Channel

Click + Add Channel to select a configured notification channel (e.g. email) to be used for alert notifications.

If no notification channels have been defined for your Sysdig Secure environment yet, see Set Up Notification Channels.

Edit an Alert

1. From the Image Scanning module, choose the Alerts tab.

2. Select the desired alert from the list.

3. Edit the alert trigger, scope, and notification channels as necessary, and click Save.

Duplicate an Alert

1. From the Image Scanning module, choose the Alerts tab.

2. Select the desired alert from the list.

3. Click the More (three dots) icon and click Duplicate Alert from the drop-down, then Yes to confirm.

Delete an Alert

1. From the Image Scanning module, choose the Alerts tab.

2. Select the desired alert from the list.

3. Click the More (three dots) icon and click Delete Alert from the drop-down, then Yes to confirm.

5.6 -

Review Scan Results

When you have set up your build environment for scanning (if applicable), added the desired registries, and either triggered a scan manually or configured an alert to scan automatically, then an image scanning report is generated.

There are different ways to access scan results:

• Externally (for developers): From an external Continuous Integration (CI) tool such as Jenkins.

• Internally (for security personnel): From the Runtime tab or the Scan Results tab (formerly titled “Repositories”) in the Image Scanning module of Sysdig Secure.

Scan Results Landing Page

Once a scan has been run, choose Image Scanning > Scan Results to see the landing page.

From here you can:

• Check quick-view charts for at-a-glance summaries of:

  • Number of images scanned

  • Pass/fail status

  • Origins of image feeds

• Search and filter results, by:

  • Keyword

  • Pass/fail status

  • Origin (drop-down menu)

  • Registry (drop-down menu)

  Save or Reset a search from the three-dots menu to the right of the nav bar.

• Sort the results list by date.

• Select an Image to see its Summary page.

Summary View

Select Image Scanning > Scan Results and select an Image to land on the results summary.

On the Summary page you can:

• Review results of vulnerability matching and policy evaluations in two separate sections

• Check the date and time of the vulnerability match and the most recent policy evaluation. These usually differ.

• Expand/collapse the policy breakdown for ease of view and removal of visual clutter

• Click Reevaluate Policies to trigger new policy results.

• Download results as a PDF, including all the policy and vulnerability details.

Select detail pages from the left navigation to see detail views.

Runtime View

Runtime provides an always-updated report on images that have been running in your environment over the past 1 hour.

In the left column: view the Entire Infrastructure or drill down to a namespace.

In the Image Overview: See the percentage of Unscanned, Failed, and Passed images and click on each to get the relevant filtered list.

Use the Search bar: To find images based on Registry, Image Name, or Tag.

You can drill down to the Scan Result Details.

Unscanned Images

Select an unscanned image to manually trigger a scan.

Scanned Images

Select a scanned image to drill down into the details: a Summary page, Policy details, Vulnerability details, and Content violations (e.g., licenses).

5.6.1 -

Scan Result Details

When you drill down into the Scan Results list, the details menu provides a variety of ways to view vulnerability and policy violation data at a glance.

• Policy Summary views

• Vulnerabilities summaries

• Content summaries

These summaries provide:

• An easy-to-parse view of why a specific image failed

• Which rules generated the most Warn and Stop actions

• Overview of how an image has performed against the various audit policies that have been put in place

• Ability to filter for high-severity CVEs, and see which have an available fix

You can also download the Policy Summary to PDF and the Vulnerabilities Summary to a CSV file.

Policy Results Views

Summary

The landing page of a Scan Results detail is the Policy Summary view.

You can:

• Get a birds-eye view of scanning status

• Drill down to a detail page

• Click Download as PDF to get a full report, including all underlying CVEs.

• Added On: See the date and time the scan was added.

• Added By: See the mechanism by which the scan was reported.

  Possible values are: Sysdig Secure UI, Node Image Analyzer, API, Sysdig Inline Scanner, or Scanning alert.

• Re-evaluate: Click the button to fetch the newest scan results

Select Dates for Past Scans

From the dropdown, select the date of the scan you’d like to analyze.

Review Scanning Policy Details

Select a listed Policy to see details about the STOP and WARN actions triggered in the Evaluation,

as well as the underlying Rules affected.

Review Vulnerability Summaries

Select either Operating System-related or Non-Operating System-related Vulnerability summaries to review.

You can:

• Get a birds-eye-view of vulnerability status

• Click a CVE number to get the full details and/or add it to an Exceptions list

• Search or filter by severity: Critical, High, Medium, Negligible, Unknown. Also filter by whether it “Has a Fix”.

• Click Download CSV to get the vulnerabilities data as a CSV file

• Open the Vulnerabilty Details panel on the right by selecting an image from the list

• Added On: See the date and time the scan was added.

Red Hat Vulnerability Details

For Red Hat vulnerabilities, the details panel provides both the Sysdig severity rating and the equivalent severity label from the Red Hat Security Tracker.

The labels are mapped as follows:

Vulnerability Comparison

The vulnerability comparison allows users to compare two different tags within the same repo to see which vulnerabilities are new or have been fixed in version X compared to version Y.

This allows developers easily to compare the latest image to a previous version to easily report on which vulnerabilities have been addressed and which are new.

1. Select an image from a line in the Scan Results list.

2. From the Compare To drop-down, select another version of this image with which to compare.

3. The comparison report is displayed.

   

Review Content Details

Navigate through node, ruby, python, java, OS packages, and the files in a container to search for details about a particular package or file.

5.7 -

Scheduled Reports

Image Scanning Reports [BETA]

Overview

The Image Scanning Reports feature has been thoroughly updated and has moved from a synchronous model to an asynchronous mode, in which you schedule the reports you need and then receive them through your normal notification channels (email, Slack, webhook.). The new version also includes:

• A preview function to check report structure in the UI

• A more advanced query builder

• Extended set of data columns (i.e. CVSS base score and vector) and extended set of available filters (i.e. package type)

Asynchronous Reports can be run on vulnerabilities and on policies.

There are two different types of asynchronous reports:

• Vulnerabilities: Vulnerabilities, package and image data

• Policies: Images and scanning policies data

Create Report Definition

1. Log in to Sysdig Secure with Advanced User or higher permissions, and select Image Scanning|Reports.

   Note: For Runtime Reports, the runtime scope must fall within your team’s designated scope. (For static reports, there is no scope requirement.)

2. From the Reports list page, click Add Report.

3. Define the Report Configuration and Data as described below. Optionally, Preview the selected Data.

4. Click Save and review the entry on the Report list page.

Define Report Configuration

Reporting creates a point-in-time snapshot of the scanning results state whenever the process starts, regardless of reports frequency.

Here you define the report name, description, schedule, and the notification channel(s) used to deliver the report.

Define the following properties:

• Name and Description: Choose a meaningful title and description

• Schedule- Report creation starts: Choose the cadence (daily, weekly, monthly) and the time (by half-hour) at which you want this report generated.

  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.

• Notification channel: The options presented in the drop-down list correspond to the notification channels you have set up in your environment.

  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 .

Define Report Data

Here you define the data to be included in the report.

Select from the options:

• Type: Choose whether to report on Vulnerabilities or Policies.

  Vulnerability Vulnerabilities, package and image data

  Columns:

  • Vulnerability ID

  • Severity

  • Vulnerability type (OS / NON-OS)

  • Vulnerability feed link

  • Fix version (if any)

  • Image name

  • Image tag

  • Image added date (to the Sysdig backend)

  • Package name

  • Package version

  • CVSS v2 vector (if any), CVSS v2 base score (if any), CVSS v3 vector (if any), CVSS v3 base score (if any)

  • Image ID

  • Vuln exception (Whether you have configured an exception for this vulnerability)

  • Runtime scope (only if configuring a runtime scope)

  Policies: Images and scanning policies data

  Columns:

  • Policy name

  • Policy evaluation (pass / fail)

  • Image name

  • Image tag

  • Image ID

  • Image added date (to the Sysdig backend)

  • Last evaluation date (against this scanning policy)

  • Runtime scope (only if configuring a runtime scope)

• Scope: Choose Registry or Runtime.

  Registry: Report on the images belonging to a registry and present on the Sysdig Secure scan results. The Rgistry field is mandatory (i.e. docker.io), repository and tag are optional, if you want to narrow down the report to a specific set of images.

  Runtime: Report on the runtime images present on the Sysdig Secure scan results. You can select Entire infrastructure or scope down using Sysdig runtime scope labels (i.e. kubernetes.cluster.name = mycluster).

  Note that the runtime scope must fall within your team’s designated scope, and only those options will be displayed.

• Condition: (Optional) You can configure one or more conditions that will filter the data that you deem relevant for the report.

  Vulnerability Report Filters

  • Vulnerability type (OS/Non-OS)

  • Vulnerability ID

  • Vulnerability added to feed (x days ago)

  • Package name: supports startswith, i.e. ‘cur’ will match ‘curl’

  • Severity: supports exact match, equals or greater than and equals or lower than

  • CVSS v2 score greater than ‘value’, one decimal place supported

  • CVSS v3 score greater than ‘value’, one decimal place supported

  • Feed source (multi-select)

  • Fix Available (yes/no)

  • Severity (critical, high, medium, low,. negligible, unknown)

  • Package type (i.e. rpm, apk, python)

  • OS name, i.e. debian, supports startswith

  • Image added to the Sysdig scan results ‘more than’ or ‘less than’ X days ago

  • Vuln exception (true/false)

• Policy Report Filters

  • Policy: Filter by images evaluated by a specific policy (i.e. NIST scan policy)

  • Policy evaluation (pass/fail)

  • Last evaluation ‘more than’ or ‘less than’ X days ago

  • OS Name, i.e. ‘debian’, supports startswith

  • Docker file available (yes/no)

  • Image added to the Sysdig scan results ‘more than’ or ‘less than’ X days ago

Preview or Clear

Preview offers a quick sample of the rows that will be obtained given the current report configuration. Preview can be used to verify format, filters and expected output. Take into account that preview data, although extracted from the real environment data, is too reduced to be significant.

The Clear button will reset the filters.

Sample Use Cases and their Previews

• Show me all Vulnerabilities in my Runtime with High Severity and a Fix Available, which are not on an Exclusions list.

  

• Show Images in my docker.io registry failing the NIST 800-190 scanning policy.

  

Manage Reports List

• Enable/Disable: By default, all report definitions are enabled. To disable, toggle the button by the Name on the List view. The report definition will be saved, but the report will not be run. It can be re-enabled at any time.

• Use the More (three dot) menu to:

  • Edit Report Definition

  • Duplicate the Report Definition

  • Delete Report Definition

  

Instrumenting Reports

From email notification:

If you have configured email as a notification channel for reports (see sample screenshot) :

then click the button to automatically download the report, provided your browser contains a valid Sysdig Secure user session. If no session is found, you will be redirected to the login screen.

From a webhook or Slack notification:

These methods will also send a link to the report, which you can download programmatically using the your Sysdig API token, for example:

curl -L -H "Authorization: Bearer <my_API_token>" https://secure.sysdig.com/api/reporting/v1/scanning/reports/1q8gX9ErBwpDdNZKDbYm5Zzzyyxxx -o report.csv

5.8 -

Host Scanning

With Host Scanning, Sysdig is now able to check for vulnerabilities in the host operating system, whether OS (e.g rpm, dpkg) or non-OS (e.g. Java packages, Ruby gems). This contrasts with all other Sysdig scanning tools, which are focused on container images, rather than the host itself.

The analyzer component of host scanning works by inspecting the files on the host root filesystem, looking for installed packages, and sending them to the Sysdig backend.

By default, host scanning:

• Is triggered every 24 hours

• Includes a default list of directories that are scanned by the analyzer.

It is possible to configure the schedule and/or the list of directories to be scanned using the Host Scanning Configuration Options if needed.

The feature is installed using the Node Analyzer component and is currently available for Sysdig Secure SaaS.

Supported Operating Systems

Supported OSs:

• Ubuntu 16.04, 18.04, 20.04

• RedHat Enterprise Linux 7, 8

• Debian 8, 9, 10

• Amazon Linux 2

Unsupported OSs:

• RedHat CoreOS (currently not supported)

• Google COS (this system does not have a package manager or standard packages and therefore cannot be supported)

Access Host Scanning

1. Follow the steps for the Node Analyzer: Multi-Feature Installation.

2. Log in to Sysdig Secure with at least Advanced User privileges.

   The results you can see in the Host Scanning list are affected by your user and team privileges.

3. Select Scanning > Hosts. The Host Scanning list page is displayed.

   

   From here you can:

   • Search Results or Filter by Scope

   • Purge Disabled Hosts

   • Review Host Vulnerabilities on the Host Results page.

   • Click to see the runtime scanning results for images on that host

Search Results or Filter by Scope

On the Host Scanning landing page, you can:

• Search: by hostname, mac, cluster name

• Filter by Team Scope: Your active team scope is applied when viewing Host Scanning results, but you can further narrow down from Entire Infrastructure using the scope filters.

  

  You can compose a scope filter using various operators (in, not-in, equal, not-equal, etc.).

  

Then proceed to review the vulnerabilities.

Purge Disabled Hosts

On the Host Scanning list page, click the three dot selector on the far right to access the Purge Disabled Hosts from Scope button.

Use this feature for hosts that have been removed from your cluster, to ensure they are also removed from the host scan list page.

Review Host Vulnerabilities

There are multiple ways to access the result details:

• Select a host (line item) from the landing page, or

• Choose View Vulnerabilities from the expanded selector at the end of a line item

  

Either choice opens a Host Results page.

From the Host Results page, you can:

• Filter by severity and whether the vulnerability has a fix

  

• Select a vulnerability to review details and remediation steps in a pull-out

  

• Compare earlier results and/or view the diff

  By default, host scans are run every 24 hours, so you can view the Current results, the Previous (one day ago) results, or the Difference in findings between the two.

  

  If nothing was changed or fixed between the two scans, the findings will look the same. The summary is displayed.

  

• Download report as a CSV or JSON file

  

See Scanning Results for Containers on the Host

For any given host, you can also check the image scan results of its containers from the Host Scanning landing page.

1. Select Scanning > Hosts.

2. Hover over a line item and choose View Runtime Images from the far-right selector.

   The Scanning Results page is displayed, showing the detailed runtime scanning results for the containers on your selected host.

5.9 -

Feeds Status

The Feeds Status page shows the different vulnerability feeds with which Sysdig integrates.

It displays the vulnerability feed group (often the distro version), the time of the last synchronization, and how many CVE records are present in the feed group.

To review the Feeds Status:

1. Navigate to the Settings menu in the Sysdig Secure UI.

2. Select Feeds Status.

   

5.10 -

Admission Controller

Understanding the Admission Controller

Kubernetes' admission controllers help you define and customize which requests are allowed on your cluster. An admission controller intercepts and processes requests to the Kubernetes API prior to persistence of the object, but after the request is authenticated and authorized.

Image Scanning Capabilities: Sysdig’s Admission Controller (UI-based) builds upon Kubernetes and enhances the capacity of the image scanner to check images for Common Vulnerabilities and Exposures (CVEs), misconfigurations, outdated images, etc., elevating the scan policies from detection to actual prevention. Container images that do not fulfill the configured admission policies will be rejected from the cluster before being assigned to a node and allowed to run.

Kubernetes Audit Logging Capabilities: Enable the features.k8sAuditDetections=true option to use Kubernetes audit logging features with the admission controller. (See also: Kubernetes Audit Logging.)

Usage Steps for Image Scanning with the AC

The Admission Controller is installed per-cluster. The workflow is straightforward:

Installation:

• Enable the feature in Sysdig Labs to activate it in the Sysdig Secure backend, for image scanning.

• Install the Admission Controller in the target cluster(s) and verify that it appears in the Sysdig UI as “Connected.”

Usage:

• Define the Admission Controller policies as you see fit for your use cases
• Assign the policies to the connected clusters
• Enable the Admission Controller for the cluster

Create Admission Controller Policies

Admission Controller Policies define the criteria to accept or reject a given container image at admission time. Remember that Policies must be assigned to a cluster to be enforced.

1. Log in as Administrator to Sysdig Secure and select Image Scanning> Admission Controller|Policies.

   The Admission Controller Policies page displays a list of any previously defined policies.

   

2. Click +Policy and enter a meaningful Name and Description.

3. Define the policy Rules:

   • Evaluation Failure: Whether to reject images that are failing scanning policy evaluation

   • Evaluation Age: Whether to reject images when the evaluation is older than X days. You might set this condition to force a new vulnerability check, for example.

   • Unscanned Image: Whether to reject images that do not have an existing evaluation at admission time. Choose from three options:

     • Ignore: Ignore this condition

     • Reject: Reject the request

     • Reject and Scan: Reject the request and scan the image in parallel.

       Typically, Kubernetes will retry creating the pending image, so eventually the image will have a valid evaluation and then the other conditions will apply. Since scanning during admission can potentially slow down the deployment process, we don’t recommend this option unless you are confident that most images will have an evaluation before admission (i.e. instrumenting the CI/CD pipelines).

4. Click Save.

How Policy Conditions are Applied

Policy conditions are applied using an AND operator.

For example, if I set Evaluation Fail to Reject, AND Evaluation Age to Reject for older than 15 days, then if I receive an image with an existing evaluation that is passing, and that evaluation is 20 days old, the request will be rejected.

Assign Admission Controller Policies

1. Log in as Administrator to Sysdig Secure and select Image Scanning> Admission Controller|Policy Assignment.

   The admission controller policy assignment page displays the list of Kubernetes clusters with Admission Controllers, and their current status.

   

   • Connected/disconnected clusters: Clusters where the admission controller was never installed will not appear at all. Otherwise:

     • Connected: Clusters with a connected and healthy admission controller will show under the “Connected” label. 

     • Disconnected: A Kubernetes cluster that had an admission controller installed, but the admission controller component is not reporting back to the Sysdig backend, will appear under the “Disconnected” label.

   • Enabled/disabled Admission Controllers: You enable/ disable the admission controller for each cluster using the switch on the top right.

     • Enabled: A green dot by the cluster name shows the admission controller is enabled (enforcing)

     • Disabled: A grey dot means the admission controller is disabled.

2. Click +Add Assignment and enter the basic assignment details.

   A cluster can have multiple assignments at different levels of granularity, and the policies are evaluated from top to bottom.

   • Namespace: Leave blank to match any namespace, or add a relevant entry.

   • Prefix: Leave blank to match any image name, or limit by entering a particular prefix. For example, the redis prefix would match images declared as redis:latest or redis:v2 in the container creation request.

   • Policy: Select a policy from the drop-down list.

3. Choose Default policy if no other assignment matches: Select to Allow by default or Reject by default.

   Be very careful with the Reject by default option. Be sure to explicitly allow critical workloads in your system.

4. Click Save.

5. Optional: Drag the new assignment to a different position in the evaluation list if it should be applied before another assignment.

Understanding Evaluation Order

Assignments are evaluated from top to bottom. The first match dictates which policy will be applied,. The default cluster action will be applied if no assignment matches.

For example:

Assignment 1:  Namespace kube-system; any Image path uses Policy1

Assignment 2: All namespaces; Image path starts with quay.io/myimage uses Policy2

Default policy: If no other assignment matches, them Reject

Then:

• Requesting to create a container with path docker.io/myimage in the kube-system namespace will apply Policy1

• Requesting to create a container with path quay.io/myimage in the kube-system namespace will apply Policy1

• Requesting to create a container with path quay.io/myimage in the mynamespace namespace will apply Policy2

• Requesting to create a container with path docker.io/myimage in the mynamespace namespace will be Rejected.

Usage Steps for Kubernetes Audit Logging with the AC

• When Installing the Admission Controller, set features.k8sAuditDetections to true.

• Create policies of the Kubernetes Audit Policy type.

• Check the Events UI for entries.

Enable/Disable the Admission Controller

It is recommended to develop the policies and assignments while the Admission Controller is Disabled. Enable on a staging cluster to test before enabling in production.

When you are happy with the defined behavior:

1. Log in as Administrator to Sysdig Secure and select Image Scanning> Admission Controller|Policy Assignment.

2. Select the relevant cluster from the left side menu.

3. Slide the Admission Controller to Enabled.

4. Monitor any resulting events as usual.

5.10.1 -

Admission Controller (CLI-Based)

Sysdig Admission Controller

Sysdig’s Admission Controller (UI-based) combines the Sysdig Secure image scanner with a policy language to evaluate scan results and the admission context, providing great flexibility in the admission decision. It also provides the first line of defense against image-based security threats.

By using Kubernetes API extensions to perform image scanning and other security checks on admission, we cover a major threat-prevention and hardening use case: “Only the images that are explicitly approved will be allowed to run on my cluster”.

The admission decision relies not only on the image name and tag but also on additional context from the admission review, including namespace, pod metadata, etc.

Features

• Registry and repository whitelist / blacklist

• Global and per-namespace admission configuration

• Configurable pre-scan and post-scan behavior, i.e.:

  • Accept only the images that pass the scan (default)

  • Directly reject non-whitelisted registries / repos, without scanning

  • Accept the image even if it doesn’t pass the scan

  • Do not accept any image that hasn’t been scanned already

• Pod mutation: image tag is replaced by digest to prevent TOCTOU (Time of Check, Time of Use) issue if the tag is updated between the scan and the pod scheduling

Requirements

• Helm 3

• Kubernetes 1.15 or higher

More Information

• Sysdig blog post

5.11 -

New Scanning Engine [Preview]

Sysdig is developing a new scanning engine with major improvements and additional features. Some of the features offered with the first iteration of the new engine are:

• Provides faster scan times when analyzing an image from the CI/CD pipeline or from your developer machine.
• Offers more advanced and accurate vulnerability data and CVSS vector scoring from different vendors and exploitability metrics.
• Features improved and more intuitive user experience.

The new engine is currently under development, but it can be enabled already as a Preview.

About Preview

In Sysdig parlance, Preview means showcasing a new feature that is under heavy development. In this case:

• The new scanning engine cannot be used for production data or flows and there are no forward compatibility guarantees for the data or the configuration yet. We recommend that you do not store any data beyond testing and evaluation.

• The new scanning engine is distinct and independent from the existing scan engine. What it means is that, for example, an image scanned with the new inline scanner will be available only in the new scanning engine menu options.

However, it is safe to test the new scanning engine while you are still using the current scanning engine for production. These features will not interfere with each other in any way.

• The main goal of Preview is to collect feedback from you, and use it to keep advancing the feature set.

Deploy the New Scanning Enginer

Enable for Your Account

1. Log in to Sysdig Secure.

2. Navigate to Settings > User Profile.

3. In the Sysdig Labs section, enable New Scanning Engine.

   

4. Check whether the Vulnerability Management section is displayed.

   

Scan results are separated from the scan results in the current scanning engine to indicate that data and configurations for these interfaces are completely detached from the current scanning engine.

Get the Inline Scanner Binary

1. Download the inline scanner binary and use it to scan the target containers:

Linux

curl -LO "https://download.sysdig.com/scanning/inlinescan/inlinescan_$(curl -L -s https://download.sysdig.com/scanning/inlinescan/latest_version.txt)_linux_amd64"

MacOS

curl -LO "https://download.sysdig.com/scanning/inlinescan/inlinescan_$(curl -L -s https://download.sysdig.com/scanning/inlinescan/latest_version.txt)_darwin_amd64"

2. On both Linux and MacOS, ensure that you make the inline scan executable by using chmod +x ./inlinescan_<version>_<arch>. Replace <version> with the latest version that you have downloaded. Replace <arch> with your OS/architecture version.

Currently supported OS and arch:

• linux_amd64
• darwin_amd64

For example: ./inlinescan_0.1.0_linux_amd64

Analyze an Image with Inline Scanner

Run the following command:

SECURE_API_TOKEN=<user_API_token> ./inlinescan_<version>_<arch> --apiurl https://secure.sysdig.com mongo-express:0.54.0

You can get the inline help by running -h or --help from the command line. For example:

./inlinescan_<version>_<arch> -h

Usage

inlinescan_<version>_<arch> [OPTIONS] ImageName

Mandatory Parameters

• SECURE API TOKEN : The SECURE_API_TOKEN is an environment variable. Navigate to Settings > User Profile to find the API token associated with your user account.
• API URL: --apiurl specifies the Secure backend location where you want to push the scanning results.
• Image: The image that you want to scan. In the example given, it is mongo-express:0.54.0.

Arguments

ImageName: Required parameter. Specify the image name.

Help Options

-h, --help: Show the command line help.

Example

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

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

Arguments:
  ImageName:              Image name

Compatibility and Supported Modes

Supported Registries and Image Types

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

Supported Package Types

• Debian
• Alpine
• RHEL
• Ubuntu
• Java Maven
• Pypi
• NPM (JS)
• Ruby Gems
• NuGet
• Cargo (Rust)

Scanning Policies and Rule Bundles

Getting Started with Defaults

Sysdig provides a default set of policies and rule bundles that work out of the box. You can use them as-is if you don’t require customizations. Running the basic inline scanner code will automatically trigger the Sysdig Best Practices policy and present results.

Code-Line Example

$ SECURE_API_TOKEN=<YOUR_API_TOKEN> ./inlinescan_latest_linux_amd64 --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)

**NOTE: ** You must have at least one scanning policy in the system. If you mistakenly delete the default and have not yet created custom policies, the system will prompt you to recreate the default.

Custom Policies and Rule Settings

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

Access the UI

While the feature is in the Preview phase, you access the UI as follows:

Scanning > Vulnerabiity Management | Settings > Policy

Scanning > Vulnerabiity Management | Settings > Rule Bundles

Create a Scanning Policy

A scanning policy groups several rule bundles under a single entity. The policy is the entity that is effectively applied / passed as a parameter when scanning an image.

To create a new policy:

1. Navigate to Scanning > Vulnerabiity Management | Settings > Policy and click +Policy.

   

2. 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 inline 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 inline scanner in order to apply it to the evaluation.
   • Rule Bundles: A policy contains rule bundles to be evaluated (see the following section). Using this widget you can add, remove, or modify the bundles used for this policy.
   • 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 inline scanner run.

3. Click Create.

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.

To create a new rule bundle:

1. Navigate to Scanning > Vulnerabiity Management | Settings > Rule Buncle 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).

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

Navigate Policy Sections in the Scan Results UI

Once an image has been evaluated against a policy or set of policies, a policy evaluation will be available

• Directly in the inline scanner output, as in the Code Line Example, above
• In the Scan Results interface (Scanning > Vulnerabiity Management> Scan Results)

Scan Results View

• The Policy Eval 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”

Image Overview

Select an image from the scan results to see the image Overview, with a summary of the eval of the different policies used to evaluate it.

Evaluation Details

From the image Overview, click a particular policy, or click the Vulnerabilities tab at the top of the page to see the eval details.

• You can hide or display the “Passing” rules using the slider at the top right
• Nested inside a “Failing” rule you will see the violation instances and their full detail (such as the vulnerabilities)
• 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.

5.12 -

Windows Container Image Scanning [BETA]

Overview

Sysdig provides a standalone vulnerability scanning and policy engine for Windows containers called the Scanning Inspector. It can be used on both Windows and Linux hosts.

Features

• Identify Windows container image vulnerabilities from:

  • Windows OS CVEs

• Windows or Linux hosts

• Reports in JSON and PDF

• Policy support

  • Severity

  • Fix available

  • Days since fixed

Ways to Use

The Windows Scanning Inspector can be integrated into the CI/CD pipeline or deployed ad hoc during development.

CI/CD Pipeline

The image below shows how the Scanning Inspector fits within a development pipeline. A policy can pass or fail the workflow and provide a PDF or JSON report for each CI/CD job.

Ad Hoc Scanning

Developers can run the Windows Scanning Inspector anywhere Docker can be run: a machine (Mac, Windows, or Linux), VM, or Cloud. It provides immediate feedback on Windows OS or .NET vulnerabilities, allowing quick mitigation of known security vulnerabilities.

Installation

Prerequisites

Request a Quay secret from your Sysdig sales agent.

Install Scanning Inspector

1. Use the provided secret to authenticate with Quay:

   PULL_SECRET="enter secret"
   AUTH=$(echo $PULL_SECRET | base64 --decode | jq -r '.auths."quay.io".auth'| base64 --decode)
   QUAY_USERNAME=${AUTH%:*}
   QUAY_PASSWORD=${AUTH#*:}
   docker login -u "$QUAY_USERNAME" -p "$QUAY_PASSWORD" quay.io
   

2. Pull the Scanning Inspector component for Windows or Linux:

   • Window Host/Kernel: quay.io/sysdig/scanning-inspector-windows:latest

   • Linux Host/Kernel: :quay.io/sysdig/scanning-inspector-linux:latest

3. Run the --help command to see the parameters available for the Scanning Inspector.

   docker run --rm -v $(pwd):/outdir quay.io/sysdig/scanning-inspector-linux:latest --help
   

Parameters for Scanning Inspector

The --help command lists the available parameters and their usage. They can be divided into those related to scanning for vulnerabilities and generating a report, and those related to creating policies.

Use Cases

Scan Remote Image and Save PDF Report

In this example, the Inspector should scan a remote image on a Linux host and save the resulting report as a PDF to ./scanResults.pdf

docker run --rm -v $(pwd):/outdir quay.io/sysdig/scanning-inspector-linux:latest \
  -t pull \ # pull image from remote repo
  -i mcr.microsoft.com/windows/nanoserver:10.0.17763.1518 \ # inspect container name
  -f pdf \ # format
  -o /outdir/scanResults.pdf # output name

Scan Local Image Apply Policy Conditions and Generate JSON Report

In this example, the Inspector should:

• Scan a local image on a Windows host

• Mount the Docker socket to access the local image. This can be done with -v "//./pipe/docker_engine://./pipe/docker_engine" in Windows

• Apply a policy to specify vulnerabilities with a minimum severity of high and a minimum number of days after the vulnerability fix is available set to 7.

• If the scan does not pass, the container will have an exit 1 error.

• The report is in JSON

docker run --rm -v $(pwd):/outdir -v "//./pipe/docker_engine://./pipe/docker_engine" quay.io/sysdig/scanning-inspector-windows:latest \
  -t daemon \ # Use local daemon for image scan
  -i nanoserver:10.0.17763.1518 # local image name
  -min_severity high # Any sev high or greater CVEs will fail the image scan policy
  -min_days_fix 7 # Only fail scan if found vulnerabilities have a fix for more than 7 days
  -f json \ # format
  -o /outdir/scanResults.json # output name

6 -

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:

• Permissions and Entitlements
• Regulatory Compliance
• Benchmarks

6.1 -

Permissions and Entitlements

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 Permissions and Entitlements (P&E) module for cloud accounts, you can review and mitigate these risks in minutes.

Understanding Permissions and Entitlements

In Sysdig Secure for cloud, Permissions and Entitlements 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 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 Resourcewildcards in policy code.

Prerequisites

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

Limitations

• Currently a beta release

• 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 >Permissions and Entitlements|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 P&E 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 Permissions and Entitlements| 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 Permissions and Entitlements|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.

6.2 -

Compliance

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

7 -

Policies

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

Understanding Sysdig Secure 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

Understanding Sysdig Secure 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

7.1 -

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

• Workload Policies: 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 Policies: Policies using a simple matching or not-matching for containers, syscalls, processes, etc. See Understanding List Matching Rules for more context.

• Kubernetes Audit Policies: Powered by the falco engine, provide a way to filter Kuernetes audit logs using flexible condition expressions. See also Kubernetes Audit Logging.

• AWS CloudTrail Policies: Provide 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. See: Threat Detection with AWS CloudTrail.

Scopes and Actions for Policy Types

The scopes and actions available differ by type:

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.

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.

7.2 -

Manage 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

7.3 -

Runtime 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 three of the following conditions must be met:

• The rule has generated at least 50 policy events

• The average rate of events over the measurement period is greater than 10 events per minute

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

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.

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

7.4 -

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.

7.5 -

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.

7.6 -

[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 namesl 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.

8 -

Network

As of June, 2021, the Network Security Policy tool has moved out of Policies and into its own menu item in Sysdig Secure SaaS.

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 author and fine-tune Kubernetes network policies within Sysdig Secure. Use it to generate a “least-privilege” policy to protect your workloads, incorporating both observed network traffic and additional user assessment. It doesn’t introduce any additional firewalls or inline connection proxies, leveraging the functionality that already exists in Kubernetes instead.

Benefits

This tool provides deep insight into microservice communications, saves time and effort by automatically describing network policies based on observed traffic, and guides the user to author appropriate policies.

More specifically, it delivers:

• 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

Prerequisites

Sysdig agent version 10.7+

Supported Orchestrator Distributions and CNI Plugins:

• Vanilla Kubernetes (kops, kube-admin) using Calico, Weave, or cillium

• OpenShift 4.x using OVS

• Google GKE using Calico, Weave, or cillium

• Amazon EKS using Calico, Weave, or cillium

• Rancher Kubernetes using Calico, Weave, or cillium

• Azure using Calico CNI

Using the Network Security Policy Tool

To use the Network Security Policy tool, follow these basic steps:

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.

   

   

3. Set up the scope. (Which entities over which time periods should be analyzed?)

4. Review the Ingress/Egress tables and edit the detected communications as desired.

5. Review everything visually in the Topography Map.

6. Click Generated Policy and download the resulting file.

7. Optional: Fine-tune the tool configuration.

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

Configuration Fine-Tuning

Sysdig has introduced a Configuration panel for Administrators who want to fine-tune the way the agent pre-processes the network data.

It contains three areas, described below:

• Workload labels

• Unresolved IPs

• Cluster CIDR configurations

To access:

1. Log in to Sysdig Secure as administrator.

2. Select Network from the left navigation.

3. Click the Configuration button on the upper right.

   

Workload Labels

The Sysdig agent automatically detects the labels used for entities in a cluster. Sometimes, there are many more labels than are needed for network security purposes. In these cases, you can select the two or three most meaningful labels and use include/exclude to avoid clutter in both the UI and your network security policies.

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.

You can now 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.

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 (see ??? ).

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

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.

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

9 -

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.

Ways to Filter Events

There are six types of filtering available: Scope, Severity, Type, Attributes, and Time Span, as well as a free-text Search field, to filter by event name or label value.

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.

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

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

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