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

Return to the regular view of this page.

  • 1:
    • 2:
      • 3:
        • 4:
          • 4.1:
            • 4.1.1:
            • 4.2:
              • 4.3:
                • 4.4:
                  • 4.4.1:
                    • 4.4.2:
                      • 4.4.3:
                      • 4.5:
                        • 4.6:
                          • 4.6.1:
                          • 4.7:
                            • 4.8:
                              • 4.9:
                                • 4.10:
                                  • 4.10.1:
                                  • 4.11:
                                  • 5:
                                    • 5.1:
                                      • 5.1.1:
                                        • 5.1.2:
                                          • 5.1.3:
                                            • 5.1.3.1:
                                              • 5.1.3.2:
                                                • 5.1.3.3:
                                              • 5.2:
                                              • 6:
                                                • 6.1:
                                                  • 6.2:
                                                    • 6.3:
                                                      • 6.3.1:
                                                      • 6.4:
                                                        • 6.5:
                                                          • 6.6:
                                                          • 7:
                                                            • 8:
                                                              • 8.1:
                                                                • 8.1.1:
                                                                  • 8.1.2:
                                                                    • 8.1.3:
                                                                      • 8.1.4:
                                                                        • 8.1.5:
                                                                          • 8.1.6:
                                                                            • 8.1.7:
                                                                            • 8.2:
                                                                              • 8.3:
                                                                              • 9:
                                                                                • 9.1:
                                                                                  • 9.1.1:
                                                                                  • 9.2:
                                                                                    • 9.3:
                                                                                    • 10:
                                                                                      • 10.1:
                                                                                      • 11:

                                                                                        Sysdig Secure

                                                                                        Sysdig Secure is part of Sysdig’s container intelligence platform. Sysdig uses a unified platform to deliver security, monitoring, and forensics in a container and microservices-friendly architecture. Sysdig Secure takes a services-aware approach to runtime security and forensics and brings together deep container visibility with Docker and Kubernetes integration to block threats more effectively.

                                                                                        In the background, the Sysdig agent lives on the hosts being monitored and collects the appropriate data and events. For more information, see the Sysdig Agent Documentation.

                                                                                        Key Features

                                                                                        • Presents relevant performance and security data together.

                                                                                        • Offers image scanning, auditing, and runtime vulnerability management capabilities:

                                                                                          • Filter and surface vulnerabilities against images, clusters, namespaces, hosts or any other label

                                                                                          • Alert on unscanned images or images whose evaluation status has changed from new vulnerabilities

                                                                                          • Log user actions, container activity, and command-line arguments

                                                                                          • Enforce security policies and block attacks

                                                                                        • Provides compliance testing for a distributed environment:

                                                                                          • Easily schedule customized benchmark tests to run across hosts, services, or clusters

                                                                                          • Export results to SIEM, logging clusters, or other tools your organization uses

                                                                                        • Provides runtime detection and data enrichment:

                                                                                          • Identify and block threats in real-time, based on application, container, and network activity

                                                                                          • Instrument Kernel to track all app, container, host, and network system calls

                                                                                          • View security policy violation based on orchestrated services

                                                                                        • Supports incident response and forensics:

                                                                                          • Protect distributed, dynamic, and ephemeral services with a single-service policy involving no manual configuration

                                                                                          • Create detailed system captures for any policy violation or incident, enabling the ability to take actions against malicious activity

                                                                                          • Drill down from policy violations into 100% granularity captures of pre- and post-attack activity

                                                                                          • View SCAP files to see all system activity before, during, and after any security event

                                                                                          • Create detailed system captures for any policy violation or incident enabling ability to take actions malicious activity

                                                                                          • Integrate alerting and incident response

                                                                                        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?

                                                                                        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

                                                                                        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

                                                                                        Insights is a Beta feature and will be available first in the US East region.

                                                                                        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.

                                                                                        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 -

                                                                                        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

                                                                                        Duration

                                                                                        Process

                                                                                        Drill-Down

                                                                                        Last 24 hours of data

                                                                                        Data is collected and aggregated every 6 hours.

                                                                                        Example: Suppose the last computation happened at 10 AM. Was: 6 pass, 2 fail. Two new images are added at 12 PM (status = pass). The panel count is updated at 4 PM to 8 pass, 2 fail.

                                                                                        Reports page.

                                                                                        Shows all the images that were added.

                                                                                        In this example, if user drills down at 10 AM, reports page will show 6 pass, 2 fail. At 12 PM, reports page will show 8 pass, 2 fail (may not match overview data). At 4 PM, both reports and overview page will show 8 pass, 2 fail.

                                                                                        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

                                                                                        Duration

                                                                                        Process

                                                                                        Drill-Down

                                                                                        Last 1-hour snapshot

                                                                                        Shows the runtime images across clusters for the last 1 hour.

                                                                                        Example: Suppose the last computation happened at 10 AM was: 6 pass, 2 fail, 1 unscanned.

                                                                                        Three new runtime images were added at 12 PM (2 fail, 1 unscanned). The panel count is updated at 4 PM and shows as 6 pass, 3 fail, 2 unscanned.

                                                                                        Runtime Scanning Image page.

                                                                                        Note: Though the count usually matches between the overview panel and the runtime image page, it may not always match. Reason: The overview runtime panel aggregates data for the last hour of data (10.30 - 11.30), but the runtime scanning page shows the snapshot for the last hour (10.00 - 11.00).

                                                                                        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

                                                                                        Duration

                                                                                        Process

                                                                                        Drill-Down

                                                                                        Last 24 hours of data

                                                                                        Data is collected and aggregated every 6 hours.

                                                                                        Example: suppose the last computation happened at 10 AM. Was: 10 high, 4 medium, 7 low, 2 info. Four new events were triggered at 12 PM (2 high, 2 info). The panel count is updated at 4PM and shows 12 high, 4 medium, 7 low, 4 info.

                                                                                        Events page

                                                                                        Note: The Events page shows all events that were triggered.

                                                                                        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

                                                                                        Duration

                                                                                        Process

                                                                                        Drill-Down

                                                                                        Past 24 hours of data

                                                                                        Data is collected and aggregated every 6 hours.

                                                                                        Example: suppose the last computation happened at 10 AM. Was: 10 critical, 4 high, 7 medium, 2 low. Two new images with vulnerabilities were added at 12 PM (OS Vuln: 2 high, 2 low; Non OS vuln: 3 Critical, 1 high). The panel count is updated at 4 PM and shows as 13 Critical, 7 high, 7 medium, 3 low.

                                                                                        No drilldown yet. To be added.

                                                                                        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

                                                                                        Duration

                                                                                        Process

                                                                                        Drill-Down

                                                                                        Last 1-hour snapshot

                                                                                        Shows CVEs for runtime images across clusters for the last 1 hour.

                                                                                        Example: suppose the last computation happened at 10 AM. Was: 10 critical, 4 high, 7 medium, 2 low. Two new images with vulnerabilities were added at 12 PM (OS Vuln: 2 high, 2 low; Non OS vuln: 3 Critical, 1 high). The panel count is updated at 4 PM and shows as 13 Critical, 7 high, 7 medium, 3 low.

                                                                                        No drilldown yet. To be added.

                                                                                        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

                                                                                        Duration

                                                                                        Process

                                                                                        Drill-Down

                                                                                        Average of last host for the type

                                                                                        Average of failed benchmark results across hosts

                                                                                        Example: Suppose there are 3 Kubernets hosts and the last Kubernetes benchmark result on the hosts were: h1 = 23 fail, h2 = 24 fail, h3 = 24 fail.

                                                                                        The Overview page will now show Kubernetes benchmarks results as 24.

                                                                                        Benchmarks Results page

                                                                                        Data Collection Details

                                                                                        4 -

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

                                                                                        Host scanning documentation is self-contained; the rest of the topics in this Scanning module concern image scanning.

                                                                                        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:

                                                                                        Centos Debian Ruby Red Hat Ubuntu Python

                                                                                        CVE NIST NPM Alpine NVD VulnDB

                                                                                        See also: Updating Vulnerability Feed in Airgapped Environments.

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

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

                                                                                        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:

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

                                                                                        Review the Types of Secure Integrations table for more context. The CI/CD Tools column lists the various options and their levels of support.

                                                                                        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

                                                                                        Using the inline_script.sh is deprecated. This script uses a different set of parameters; for more information about porting the parameters to the inline scanner container, see changes-from-v1xx.

                                                                                        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

                                                                                        Parameter

                                                                                        Description

                                                                                        Image name (mandatory)

                                                                                        Container image to be analyzed, following the usual registry/repo:tag format, i.e. docker.io/alpine:3.12.1. If no tag is specified, the latest will be used.

                                                                                        Digest format is also supported, i.e.: docker.io/alpine@sha256:c0e9560cda118f9ec6...

                                                                                        --sysdig-token (mandatory)

                                                                                        Sysdig API token, visible from the User Profile page.

                                                                                        --sysdig-url:

                                                                                        Not required for Sysdig Secure SaaS in the us-east region. For any other case, you must adjust this parameter. I.e. for SaaS us-west it is: --sysdig-url https://us2.app.sysdig.com. See also SaaS Regions and IP Ranges.

                                                                                        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.

                                                                                        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.

                                                                                        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
                                                                                        

                                                                                        Malware detection is provided by a third-party software. Sysdig cannot directly remediate false negatives or false positives reported by this functionality.

                                                                                        Pipeline Integration Examples

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

                                                                                        Additional Options

                                                                                        You can also:

                                                                                        4.1.1 -

                                                                                        Integrate with Jenkins

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

                                                                                        Review the Types of Secure Integrations table for more context. The CI/CD Tools column lists the various options and their levels of support.

                                                                                        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.

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

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

                                                                                        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.

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

                                                                                        If you have run the single line agent install with the --image-analyzer flag, then this component is already running in your infrastructure.

                                                                                        The feature is available for Kubernetes environments in Sysdig Secure SaaS and in On-Premises version 3.5.1+.

                                                                                        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.

                                                                                        4.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 four baseline policies that can be used as-is or as templates on which to build.

                                                                                        Default Policy

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

                                                                                        • checking for medium and high vulnerabilities

                                                                                        • checking configuration items (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.

                                                                                        You can edit the Default policy and edits will be retained even when you upgrade Sysdig Secure.

                                                                                        Preconfigured Compliance Policies

                                                                                        The three other preconfigured policies deal with compliance rules. To use them, you may be prompted to activate them.

                                                                                        If you want to edit a preconfigured compliance policy, create a new policy with matching rules, and edit that.

                                                                                        Otherwise, your customizations may be overwritten and lost during Sysdig Secure upgrades.

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

                                                                                        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

                                                                                        Remember not to edit preconfigured compliance scanning policies directly. Create a matching policy and edit that one.

                                                                                        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.

                                                                                        For example, imagine a list with two defined policy assignments:

                                                                                        Priority 1 Registry = quay.io Repository = sysdig/*

                                                                                        Priority 2 Registry = quay.io Repository = sysdig/myrepo

                                                                                        Since the first rule uses a wild card, the evaluation applies to all repos beginning with sysdig/ and will stop before evaluating sysdig/myrepo.

                                                                                        Reverse the priority order to get the behavior you want.

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

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

                                                                                        Previous versions of Sysdig Secure called this feature Whitelist and Blacklist, and the options were located under the Scanning Policies tab.

                                                                                        Note that “blacklist” options for other entities, such as users, ports, packages, etc., are listed in Scanning Policy Gates and Triggers.

                                                                                        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.

                                                                                        If you delete or rename an exception list, the modification will be also applied to the policy assignments that contain that 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.

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

                                                                                        This information can also be obtained using the CLI:

                                                                                        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.

                                                                                        The Always gate is useful for testing whether the image blacklist/whitelist is working as expected.

                                                                                        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.

                                                                                        The gate can assume what the contents would be based on the Docker layer history. See also: Dockerfile Gate and Triggers Deep Dive

                                                                                        effective_user

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

                                                                                        ParameterDescriptionExample
                                                                                        typeDetermines whether the user should be whitelisted or blacklisted.N/A
                                                                                        userThe name of the user.root,docker

                                                                                        exposed_ports

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

                                                                                        ParameterDescriptionExample
                                                                                        actual_dockerfile_onlyDefines whether the evaluation should skip inferred or guessed Dockerfiles, and only evaluate user-provided Dockerfiles. The default value is false.true
                                                                                        portsA comma-separated list of port numbers.80,8080,8088
                                                                                        typeDefines whether the ports should be whitelisted or blacklisted.N/A

                                                                                        instruction

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

                                                                                        ParameterDescriptionExample
                                                                                        actual_dockerfile_onlyDefines whether the evaluation should skip inferred or guessed dockerfiles, and only evaluate user-provided dockerfiles. The default value is false.true
                                                                                        checkThe type of check to perform.=
                                                                                        instructionThe dockerfile instruction to check.FROM
                                                                                        valueThe value to check the dockerfile instruction against.scratch

                                                                                        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.

                                                                                        For more information regarding the regex values, refer to the analyzer_config.yaml file.

                                                                                        ParameterDescriptionExample
                                                                                        regex_nameThe regex string that appears in the FILECHECK_CONTENTMATCH analyzer parameter..*password.*

                                                                                        name_match

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

                                                                                        This trigger has a performance impact on policy evaluation.

                                                                                        ParameterDescriptionExample
                                                                                        regexThe regex to search for..*\.pem

                                                                                        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.

                                                                                        ParameterDescriptionExample
                                                                                        licensesA comma-separated list of license names to blacklist.GPLv2+,GPL-3+,BSD-2-clause

                                                                                        blacklist_partial_match

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

                                                                                        ParameterDescriptionExample
                                                                                        licensesA comma-separated list of strings to blacklist for licenses.LGPL,BSD

                                                                                        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.

                                                                                        ParameterDescriptionExample
                                                                                        attributeThe attribute name to check.size
                                                                                        checkThe operation to perform for the evaluation.>
                                                                                        valueThe value used for the evaluation.1073741824

                                                                                        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.

                                                                                        ParameterDescriptionExample
                                                                                        nameThe name of blacklisted package/s.openssh-server
                                                                                        versionThe exact version of the package that should be blacklisted.1.0.1

                                                                                        required_package

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

                                                                                        ParameterDescriptionExample
                                                                                        nameThe name of the required package.libssl
                                                                                        versionThe required package version.1.10.3rc3
                                                                                        version_match_typeDefines whether the trigger should require the exact package and version (exact), or just a version of the package (minimum). This is only relevant if the version is defined.exact

                                                                                        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.

                                                                                        ParameterDescriptionExample
                                                                                        checkDefines whether the check should focus on missing packages, changed packages, or all.changed
                                                                                        only_directoriesDefines the list of directories the check should be limited to./usr,/var/lib
                                                                                        only_packagesDefines the list of packages that should be verified.libssl,openssl

                                                                                        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.

                                                                                        ParameterDescriptionExample
                                                                                        entryThe full entry to match in /etc/passwd.ftp:x:14:50:FTP User:/var/ftp:/sbin/nologin

                                                                                        blacklist_groupids

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

                                                                                        ParameterDescriptionExample
                                                                                        group_idsA numeric, comma separated list of group ids that will cause the trigger to trip.999,20

                                                                                        blacklist_shells

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

                                                                                        ParameterDescriptionExample
                                                                                        shellsThe list of shell commands to blacklist./bin/bash,/bin/zsh

                                                                                        blacklist_userids

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

                                                                                        ParameterDescriptionExample
                                                                                        user_idsThe numerical, comma-separated list of user IDs to blacklist.0,1

                                                                                        blacklist_usernames

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

                                                                                        ParameterDescriptionExample
                                                                                        user_namesA comma-separated list of usernames to blacklist.daemon,ftp

                                                                                        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.

                                                                                        The content_regex_name should be a value from the secret_search section of analyzer_config.yaml.

                                                                                        Parameter

                                                                                        Description

                                                                                        Example

                                                                                        content_regex_name

                                                                                        The name of the variable / content. If found in the image, this should trip the trigger.

                                                                                        The names available by default are AWS_ACCESS_KEY, AWS_SECRET_KEY, PRIV_KEY, DOCKER_AUTH, and API_KEY.

                                                                                        AWS_ACCESS_KEY

                                                                                        filename_regex

                                                                                        Filters the files that should be analyzed for the presence of the content_regex_name.

                                                                                        /etc/.*

                                                                                        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:

                                                                                        ParameterDescriptionExample
                                                                                        fix_availableIf present, the fix availability for the vulnerability record must match the value of the parameter.true
                                                                                        package_typeThe specific type of package.all
                                                                                        severityThe vulnerability severity.high
                                                                                        severity_comparisonThe type of comparison to perform for the security evaluation.>
                                                                                        vendor_onlyIf true, an available fix for this CVE must not be explicitly marked as “Won’t be addressed by the vendor”.true

                                                                                        stale_feed_data

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

                                                                                        ParameterDescriptionExample
                                                                                        max_days_since_syncDetermines how old in days sync data can be before the trigger is tripped.10

                                                                                        vulnerability_data_unavailable

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

                                                                                        4.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": []
                                                                                        }
                                                                                        
                                                                                        

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

                                                                                        OpsGenie and ViktorOps notification channels are not supported for image scanning alerts.

                                                                                        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.

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

                                                                                        NOTE: Images containing RPM packages with SHA512 hashes are not supported.

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

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

                                                                                        Sysdig SeverityRed Hat SeverityRed Hat Definition
                                                                                        CriticalCriticalThis rating is given to flaws that could be easily exploited by a remote unauthenticated attacker and lead to system compromise (arbitrary code execution) without requiring user interaction. Flaws that require authentication, local or physical access to a system, or an unlikely configuration are not classified as Critical impact. These are the types of vulnerabilities that can be exploited by worms.
                                                                                        HighImportantThis rating is given to flaws that can easily compromise the confidentiality, integrity or availability of resources. These are the types of vulnerabilities that allow local or authenticated users to gain additional privileges, allow unauthenticated remote users to view resources that should otherwise be protected by authentication or other controls, allow authenticated remote users to execute arbitrary code, or allow remote users to cause a denial of service.
                                                                                        MediumModerateThis rating is given to flaws that may be more difficult to exploit but could still lead to some compromise of the confidentiality, integrity or availability of resources under certain circumstances. These are the types of vulnerabilities that could have had a Critical or Important impact but are less easily exploited based on a technical evaluation of the flaw, and/or affect unlikely configurations.
                                                                                        LowLowThis rating is given to all other issues that may have a security impact. These are the types of vulnerabilities that are believed to require unlikely circumstances to be able to be exploited, or where a successful exploit would give minimal consequences. This includes flaws that are present in a program’s source code but to which no current or theoretically possible, but unproven, exploitation vectors exist or were found during the technical analysis of the flaw.
                                                                                        Negligiblen/an/a

                                                                                        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.

                                                                                        4.7 -

                                                                                        Scheduled Reports

                                                                                        Image Scanning Reports [BETA]

                                                                                        Overview

                                                                                        You need to enable this feature from the Sysdig Labs setting on the User Profile page. Once enabled, it will replace the Reporting v2 UI in the product page. (Reporting v2 API endpoints will still be available at this time, though deprecated eventually).

                                                                                        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
                                                                                        
                                                                                        

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

                                                                                        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.

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

                                                                                        4.10 -

                                                                                        Admission Controller

                                                                                        This feature is offered through Sysdig Labs and is installed as its own component. See Admission Controller: Installation

                                                                                        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 (SaaS only): 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:

                                                                                        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. See also: ???.

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

                                                                                        The Disable function can also be used to quickly stop the Admission Controller if unexpected behavior is detected that adversely affects the function of a cluster.

                                                                                        4.10.1 -

                                                                                        Admission Controller (CLI-Based)

                                                                                        A UI-based Admission Controller is now available, and is not backward-compatible with the CLI-based version. We advise not installing the CLI-based version at this time.

                                                                                        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

                                                                                        4.11 -

                                                                                        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.

                                                                                        This is a standalone scanning engine. There is no centralized UI, management, or historical data. These features are planned for a future release.

                                                                                        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.

                                                                                        FlagDescriptionRequiredArgumentType
                                                                                        -f stringoutput formatyespdf or jsonVuln scan
                                                                                        -i or -image_identifier stringidentifier of the imageyes[my_image:my_tag]Vuln scan
                                                                                        -image_type stringimage typeyestar, daemon, pullVuln scan
                                                                                        -o string or -output string output file pathyesVuln scan
                                                                                        -output_format string output formatyespdf or jsonVuln scan
                                                                                        -fix_availablepolicy check for fixnoPolicy creation
                                                                                        -min_days_fix intMinimum number of days once a fix for the specific vulnerability is availablenodefault -1Policy Creation
                                                                                        -min_severity stringMinimum severity to fail for policy evaluationnoPolicy creation
                                                                                        t-stringThe image typeyestar, daemon, pull

                                                                                        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
                                                                                        
                                                                                        

                                                                                        5 -

                                                                                        Compliance

                                                                                        The Benchmarks module, formerly listed in the left-hand navigation bar, is now a subset of Compliance.

                                                                                        The Compliance module in Sysdig Secure is comprised of a validator tool that checks selected controls from various compliance standards, and the reports it compiles. New standards are being added regularly. 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 Compliance icon in the left-hand navigation.

                                                                                        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

                                                                                        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

                                                                                        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

                                                                                        5.1 -

                                                                                        Benchmarks

                                                                                        The Benchmarks v2 (SaaS-only) release has several differences from v1:

                                                                                        • Installation is handled through a dedicated benchmark runner included with the new Node Analyzer.

                                                                                        • Host and cloud benchmarks are handled in one interface

                                                                                        • Reports combine results from all relevant hosts, rather than one report per host

                                                                                        • Improvements in scoping, scheduling, and team scoping, with associated changes to the UI

                                                                                        • Improved processing pipeline

                                                                                        Users who were running v1 in Sysdig Secure SaaS will be upgraded to v2 when the Node Analyzer is installed, but can access v1 through the Legacy Benchmarks button on the landing page. Legacy documentation is also available.

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

                                                                                        Schema Name

                                                                                        Applicability

                                                                                        Notes

                                                                                        CIS Kubernetes Benchmark v1.5.1

                                                                                        Kubernetes versions 1.15 and below

                                                                                        Sections 1,2,3 will only be run on Master nodes, section 4 will be run on all nodes (master + worker)

                                                                                        CIS Kubernetes Benchmark v1.6.0

                                                                                        Kubernetes versions 1.16 and below

                                                                                        Sections 1,2,3 will only be run on Master nodes, section 4 will be run on all nodes (master + worker)

                                                                                        CIS Google Kubernetes Engine (GKE) Benchmark v1.0.0

                                                                                         

                                                                                        CIS Amazon Elastic Kubernetes Service (EKS) Benchmark v1.0.0

                                                                                         

                                                                                        OpenShift 3.11 Hardening Guide v1.2.1

                                                                                        OpenShift versions 3.10 and 3.11 are supported.

                                                                                         

                                                                                        CIS RedHat OpenShift Container Platform v4 Benchmark v1.1.0

                                                                                        OpenShift Container Platform v4

                                                                                        Choose Server Software > Virtualization > Kubernetes to access the link to the CIS Benchmark for RedHat OpenShift Container Platform v4 on the CIS site.

                                                                                        CIS Distribution Independent Linux Benchmark v1.1.0

                                                                                        Docker Security Benchmark v1.2.0

                                                                                        With Secure for cloud:

                                                                                        Prerequisite: Installed Sysdig Secure for cloud and selected CSPM/AWS Benchmarks.

                                                                                        CIS Amazon Web Services Foundations Compliance Benchmark v1.3.0

                                                                                        These tasks are auto-created when Secure for cloud benchmarks are enabled.

                                                                                        They are read-only; schedule and scope are fixed. They display that a cloud bench task exists, and give access to the results.

                                                                                        Understanding Benchmark Scopes

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

                                                                                        Scope LabelDescriptionSourceApplicable Schemas
                                                                                        host.hostNameThe local hostname of the machine running the benchmark container.Retrieved from the machine running the benchmark container.All
                                                                                        host.macThe MAC address of the machine running the benchmark container.Retrieved from the machine running the benchmark container.All
                                                                                        aws.accountIdThe AWS account ID containing the EC2 instance running the benchmark container.Retrieved from the AWS EC2 Instance Metadata ServiceCIS Amazon Elastic Kubernetes Service (EKS) Benchmark v1.0.0
                                                                                        aws.regionThe Region containing the EC2 instance running the benchmark container.Retrieved from the AWS EC2 Instance Metadata ServiceCIS Amazon Elastic Kubernetes Service (EKS) Benchmark v1.0.0
                                                                                        aws.instanceIdThe AWS instance ID of the EC2 instance running the benchmark container.Retrieved from the AWS EC2 Instance Metadata ServiceCIS Amazon Elastic Kubernetes Service (EKS) Benchmark v1.0.0
                                                                                        gcp.projectIdThe Project ID used to create the instance.Retrieved from the GCP Compute Engine Metadata endpointCIS Google Kubernetes Engine (GKE) Benchmark v1.0.0
                                                                                        gcp.instanceIdThe ID of the VM.Retrieved from the GCP Compute Engine Metadata endpointCIS Google Kubernetes Engine (GKE) Benchmark v1.0.0
                                                                                        gcp.instanceZoneThe Zone that the VM is running in.Retrieved from the GCP Compute Engine Metadata endpointCIS Google Kubernetes Engine (GKE) Benchmark v1.0.0
                                                                                        kubernetes.cluster.nameThe configured Cluster name.Set in the sysdig-agent configmap under the key: k8s_cluster_nameAll
                                                                                        kubernetes.node.nameThe name of the node in Kubernetes.Supplied by Kubernetes Downwards APIAll
                                                                                        agent.tag.*A set of customizable tags set in the agent configmap. Same as tags for the standard agentSet in the sysdig-agent configmap under the key: tagsAll

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

                                                                                        Tasks are immutable once created. You cannot change the scope, schedule, schema or filtered controls for an existing task.

                                                                                        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.

                                                                                        5.1.2 -

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

                                                                                        5.1.3 -

                                                                                        Benchmarks (Legacy)

                                                                                        Earlier versions of Sysdig Secure referred to this module as Compliance.

                                                                                        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:

                                                                                        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.

                                                                                        Version Rules

                                                                                        • If you do not customize/filter your report, the Sysdig agent will auto-detect your environment version and will run the corresponding version of the benchmark controls.

                                                                                        • If you specify a benchmark version, you can then apply a report filter.

                                                                                        • If the test version doesn’t match the environment version, the filter will be ignored and all the tests will be displayed.

                                                                                        Kubernetes Version Mapping

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

                                                                                        CIS Benchmark Ver.Kubernetes Ver.Sysdig AgentTargets
                                                                                        CIS 1.3Kubernetes v 1.11-1.12allMaster control plane, Node, Etcd, Policies
                                                                                        CIS 1.4Kubernetes v 1.13-1.14allMaster control plane, Node, Etcd, Policies
                                                                                        CIS 1.5Kubernetes v 1.15-allMaster control plane, Node, Etcd, Policies
                                                                                        RH 0.7 Red Hat OpenShift hardening guideOCP 3.10-3.11v9.7-Master node
                                                                                        CIS1.6Kubernetes v1.16-v10.6-Master control plane, Node, Etcd, Policies
                                                                                        GKE 1.0GKEv10.6-Master control plane, Node, Etcd, Policies, Managed services
                                                                                        EKS 1.0EKSv.10.6-Control plane, Node, Policies, Managed services

                                                                                        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

                                                                                        CIS Benchmark VersionSysdig Report Filter
                                                                                        CIS_Docker_Community_Edition_Benchmark_v1.1.0Docker 1.0

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

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

                                                                                        One Task, One Test, One Environment

                                                                                        To run benchmarks on environments with different Kubernetes versions, create a separate task for that scope and version. Sysdig cannot run tests for multiple versions in a single task.

                                                                                        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.

                                                                                        5.1.3.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/ )

                                                                                        Remember: You may have chosen to filter the Report view to highlight a subset of information.

                                                                                        A filter will apply to ALL relevant listings in the Results page; remove the filter to view the entire test result. See Filter Report Results.

                                                                                        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.

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

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

                                                                                        6 -

                                                                                        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.

                                                                                        Default rules appear in the UI as Published By: Sysdig

                                                                                        User-defined rules appear as Published By: Secure UI

                                                                                        Tags

                                                                                        Rules are categorized by tags, so you can group them by functionality, security standard, target, or whatever schema makes sense for your organization.

                                                                                        Various tags are predefined and can help you organize rules into logical groups when creating or editing policies.

                                                                                        Use the search boxes at the top to search by rule name or by tag.

                                                                                        Using Falco within Sysdig Secure

                                                                                        What is Falco

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

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

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

                                                                                        Conditions
                                                                                        • Falco rules use the Sysdig filtering syntax.

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

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

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

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

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

                                                                                        Anatomy of a Falco Rule

                                                                                        All Falco rules include the following base parameters:

                                                                                        • rule name: default or user-assigned

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

                                                                                        • output:

                                                                                        • source:

                                                                                        • description:

                                                                                        • tags: for searching and sorting

                                                                                        • priority

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

                                                                                        Existing Rule
                                                                                        Create a Rule

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

                                                                                        About Falco Macros

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

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

                                                                                        About Falco Lists

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

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

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

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

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

                                                                                        Rules Installer

                                                                                        For the Docker pull command and instructions for the Rules Installer, see Install Falco Rules On-Premises.

                                                                                        Understanding List-Matching Rules

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

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

                                                                                          Or

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

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

                                                                                        The five list-matching Rule Types are described below.

                                                                                        Container Rules

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

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

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

                                                                                        File System Rules

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

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

                                                                                        Network Rules

                                                                                        These rules are used to:

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

                                                                                        • Generally identify any inbound or outbound connection attempts

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

                                                                                        For both Inbound and Outbound connections:

                                                                                        • Allow means do nothing

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

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

                                                                                        Process Rules

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

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

                                                                                        Syscall Rules

                                                                                        The syscall rule type is almost never deployed in user-created policies; the definitions below are for information only.

                                                                                        These rules are used (internally) to:

                                                                                        • Notify if a specific syscall happens in a list

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

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

                                                                                        How Matching Works: Container Example

                                                                                        A Container Image consists of the following components:

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

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

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

                                                                                        Where:

                                                                                        <registry host> = docker.io

                                                                                        <registry port> = 1234

                                                                                        <image> = sysdig/agent

                                                                                        <tag> = 1.0

                                                                                        <digest> = sha256:da39a3ee5e6b4b0d3255bfef95601890afd80709

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

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

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

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

                                                                                        Examples:

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

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

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

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

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

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

                                                                                        Getting Started

                                                                                        There are a variety of optional tools to help automate the creation of policies. See also:

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

                                                                                        Create a Policy

                                                                                        There are a variety of optional tools to help automate the creation of policies. See also:

                                                                                        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:

                                                                                        Scopes and Actions for Policy Types

                                                                                        The scopes and actions available differ by type:

                                                                                        Falco

                                                                                        List-Matching

                                                                                        Kubernetes

                                                                                        AWS Cloud

                                                                                        Scope Options

                                                                                        Custom

                                                                                        Hosts only

                                                                                        Container only

                                                                                        Customer

                                                                                        Hosts only

                                                                                        Container only

                                                                                        kubernetes.cluster.name

                                                                                        kubernetes.namespace.name

                                                                                        aws.accountId

                                                                                        aws.region

                                                                                        Action Options

                                                                                        Stop/ pause/ kill

                                                                                        Capture

                                                                                        Notification channel

                                                                                        Stop/ pause/ kill

                                                                                        Capture

                                                                                        Notification channel

                                                                                        Notification channel

                                                                                        Notification chann

                                                                                        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.

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

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

                                                                                        Create a List-Matching Rule: Container Type Example

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

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

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

                                                                                        2. Enter the parameters:

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

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

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

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

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

                                                                                        3. Click Save.

                                                                                        Review a Rule Detail Panel

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

                                                                                        From here you can:

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

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

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

                                                                                        Edit a Rule

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

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

                                                                                        To display existing rules:

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

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

                                                                                        Append to Falco Macros and Lists

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

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

                                                                                        To append items in a default list:

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

                                                                                        2. The list content is displayed. Click Append.

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

                                                                                          The same process applies to macros.

                                                                                        How to Use the Rules Editor

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

                                                                                        Understand the Interface

                                                                                        To access the interface, select Policies > Rules Editor:

                                                                                        The Right Panel (Default)

                                                                                        Displays the rules_yamls provided from Sysdig.

                                                                                        • Contains the default rules and macros

                                                                                        • Is read-only

                                                                                        The Left Panel (Custom)

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

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

                                                                                        To search the rules YAML files

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

                                                                                        See also: Runtime Policy Tuning .

                                                                                        Use Cases: List-Matching Rules

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

                                                                                        I WANT TO KNOW…

                                                                                        when any process other than web server programs are run:

                                                                                        • Rule Type: Process

                                                                                        • If Not Matching

                                                                                        • Entries: [apache, httpd, nginx]

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

                                                                                        • Rule Type: Process

                                                                                        • If Matching

                                                                                        • Entries: [minerd, ccminer]

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

                                                                                        • Rule Type: Filesystem

                                                                                        • Read Operations: If Matching

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

                                                                                        if any program writes anywhere below binary directories:

                                                                                        • Rule Type: Filesystem

                                                                                        • Read/Write Operations: If Matching

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

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

                                                                                        • Rule Type: Filesystem

                                                                                        • Read/Write Operations: If Not Matching

                                                                                        • Entries: /var/tmp

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

                                                                                        • Rule Type: Container

                                                                                        • If Matching

                                                                                        • Entries: [docker.io/]

                                                                                        if any container runs an Apache web server:

                                                                                        • Rule Type: Container

                                                                                        • If Matching

                                                                                        • Entries: [httpd, amd64/httpd]

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

                                                                                        • Rule Type: Container

                                                                                        • If Not Matching

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

                                                                                        if any program accepts an inbound ssh connection:

                                                                                        • Rule Type: Network

                                                                                        • Tcp, "If Matching"

                                                                                        • Entries: [22]

                                                                                        if any program receives a DNS datagram:

                                                                                        • Rule Type: Network

                                                                                        • UDP, "If Matching"

                                                                                        • Entries: [53]

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

                                                                                        • Rule Type: Network

                                                                                        • TCP, "If Not Matching"

                                                                                        • Entries: [80, 443]

                                                                                        if any program accepts any inbound connection:

                                                                                        • Rule Type: Network

                                                                                        • Inbound Connection: Deny

                                                                                        if any program makes any outbound connection

                                                                                        • Rule Type: Network

                                                                                        • Outbound Connection: Deny

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

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

                                                                                        Using Runtime Policy Tuner

                                                                                        Prerequisites

                                                                                        • Sysdig agent 11.0.0+

                                                                                        • Sysdig SaaS or Sysdig On-Prem 5.0+

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

                                                                                        Enable, View, Edit Exceptions, Disable

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

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

                                                                                        2. Enable the feature with the Tuning Engine toggle.

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

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

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

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

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

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

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

                                                                                        Understanding How the Tuning Engine Works

                                                                                        When Does the Tuner Add Exceptions?

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

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

                                                                                        6.3.1 -

                                                                                        The Falco Rules Tuner (Legacy)

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

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

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

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

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

                                                                                        Requirements

                                                                                        • Sysdig Secure SaaS or On-Prem version 3.5.0+

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

                                                                                        • Environment variable values listed in the table below

                                                                                        Set Variables and Run the Container

                                                                                        Gather the values needed for the following environment variables.

                                                                                        Required Environment Variables for Falco Rule Tuner

                                                                                        Variable

                                                                                        Description

                                                                                        SECURE_CUSTOMER

                                                                                        Optional: Name of the business entity. Default: test

                                                                                        SECURE_ENDPOINT

                                                                                        The endpoint for the tuning engine to query.

                                                                                        For SaaS, see SaaS Regions and IP Ranges.

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

                                                                                        SECURE_TOKEN

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

                                                                                        SLACK_WEBHOOK

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

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

                                                                                        EVENT_LOOKBACK_MINUTES

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

                                                                                        EVENT_COUNT_THRESHOLD

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

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

                                                                                        Required Environment Variables for Falco Rule Tuner

                                                                                        Run as a Docker container:

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

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

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

                                                                                        Check Output in Slack Channel (Optional)

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

                                                                                        For review: How to Use the Rules Editor.

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

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

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

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

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

                                                                                          You will find both the Rule itself

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

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

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

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

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

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

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

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

                                                                                        Example

                                                                                        Non-Airgapped Environment

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

                                                                                        1. Download the container image:

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

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

                                                                                        Airgapped Environment

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

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

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

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

                                                                                        4. Untar the image file:

                                                                                          # docker load -i file.tar
                                                                                          

                                                                                          It restores both images and tags.

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

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

                                                                                        Usage

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

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

                                                                                        VariablesDescription
                                                                                        DEPLOY_HOSTNAMEThe server that hosts the Sysdig API endpoints. The default is https://secure.sysdig.com.
                                                                                        DEPLOY_USER_NAMEThe username for the account that has the admin-level access to the Sysdig API endpoints. The value defaults to a meaningless user, nobody@nobody.com.
                                                                                        DEPLOY_USER_PASSWORDThe password for the admin user. The value defaults to a meaningless password nopassword.
                                                                                        VALIDATE_RULESIf set to yes, ensure that the rules file is compatible with your user rules file. Otherwise, skip this validation step. The value defaults to yes.
                                                                                        DEPLOY_RULESIf set to yes, the falco rules file is deployed. Otherwise, skip deploying the falco rules file. The value defaults to yes.
                                                                                        CREATE_NEW_POLICIESIf set to yes, create new policies for any Falco rules that do not map to a policy. The value defaults is no.
                                                                                        SDC_SSL_VERIFYIf set to false, allow certificate validation failures when deploying the rules. The value defaults to true.

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

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

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

                                                                                        This feature is available in the Enterprise tier of the Sysdig product. See https://sysdig.com/pricing for details, or contact sales@sysdig.com.

                                                                                        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

                                                                                        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.

                                                                                        7 -

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

                                                                                        8 -

                                                                                        Secure Events

                                                                                        From Sysdig Secure 3.5.0, the Policy Events module has been reworked and renamed Events. The new functionality includes both runtime policy and runtime image scanning events and has much more powerful filtering capabilities.

                                                                                        BE AWARE!

                                                                                        Events in the old and new formats are stored separately.

                                                                                        • No event or event data will be lost during the transition

                                                                                        • Events that were registered before the new feed is deployed can be browsed using the oldP Policy Events interface, available on the burger menu in the top-right corner.

                                                                                        If you are running on a GKE cluster, review the GKE Limitations.

                                                                                        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.

                                                                                        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.

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

                                                                                        Supported 3rd-Party Solutions

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

                                                                                        Supported Event Forwarding Data Sources

                                                                                        At this time, Sysdig Secure can forward the following types of data:

                                                                                        • Policy events: there are now two supported formats: the older one (legacy policy events) and current one (runtime policy events).

                                                                                        • Activity audit information in each of the four audit types: command, network, file, and kubectl exec.

                                                                                        • Benchmarks (v2): When the benchmarks component is installed with the Node Analyzer, forwarding benchmark data is supported.

                                                                                        • Host Scanning: When the feature has been installed with the Node Analyzer, forwarding host scanning data is supported.

                                                                                        JSON Formats Used per Data Source

                                                                                        Informational; in most cases, there is no need to change the default format.

                                                                                        Policy Event Payloads

                                                                                        There are now two formats supported. See also this Release Note.

                                                                                        New Runtime Policy Events Payload

                                                                                        {
                                                                                            "id": "164ace360cc3cfbc26ec22d61b439500",
                                                                                            "type": "policy",
                                                                                            "timestamp": 1606322948648718268,
                                                                                            "originator": "policy",
                                                                                            "category": "runtime",
                                                                                            "source": "syscall",
                                                                                            "name": "Notable Filesystem Changes",
                                                                                            "description": "Identified notable filesystem activity that might change sensitive/important files. This differs from Suspicious Filesystem Changes in that it looks more broadly at filesystem activity, and might have more false positives as a result.",
                                                                                            "severity": 0,
                                                                                            "agentId": 13530,
                                                                                            "containerId": "",
                                                                                            "machineId": "08:00:27:54:f3:9d",
                                                                                            "content": {
                                                                                              "policyId": 544,
                                                                                              "baselineId": "",
                                                                                              "ruleName": "Write below etc",
                                                                                              "ruleType": "RULE_TYPE_FALCO",
                                                                                              "ruleTags": [
                                                                                                "mitre_persistence",
                                                                                                "NIST",
                                                                                                "NIST_3.4.4",
                                                                                                "filesystem"
                                                                                              ],
                                                                                              "output": "File below /etc opened for writing (user=root command=touch /etc/ard parent=bash pcmdline=bash file=/etc/ard program=touch gparent=su ggparent=sudo gggparent=bash container_id=host image=<NA>)",
                                                                                              "fields": {
                                                                                                "container.id": "host",
                                                                                                "container.image.repository": "<NA>",
                                                                                                "falco.rule": "Write below etc",
                                                                                                "fd.name": "/etc/ard",
                                                                                                "proc.aname[2]": "su",
                                                                                                "proc.aname[3]": "sudo",
                                                                                                "proc.aname[4]": "bash",
                                                                                                "proc.cmdline": "touch /etc/ard",
                                                                                                "proc.name": "touch",
                                                                                                "proc.pcmdline": "bash",
                                                                                                "proc.pname": "bash",
                                                                                                "user.name": "root"
                                                                                              },
                                                                                              "falsePositive": false,
                                                                                              "matchedOnDefault": false,
                                                                                              "policyVersion": 2,
                                                                                              "policyOrigin": "Sysdig"
                                                                                            },
                                                                                            "labels": {
                                                                                              "host.hostName": "ardbox",
                                                                                              "process.name": "touch /etc/ard"
                                                                                            }
                                                                                        }
                                                                                        

                                                                                        Legacy Secure Policy Event Payload

                                                                                        {
                                                                                            "id": "164ace360cc3cfbc26ec22d61b439500",
                                                                                            "containerId": "",
                                                                                            "name": "Notable Filesystem Changes",
                                                                                            "description": "Identified notable filesystem activity that might change sensitive/important files. This differs from Suspicious Filesystem Changes in that it looks more broadly at filesystem activity, and might have more false positives as a result.",
                                                                                            "severity": 0,
                                                                                            "policyId": 544,
                                                                                            "actionResults": [],
                                                                                            "output": "File below /etc opened for writing (user=root command=touch /etc/ard parent=bash pcmdline=bash file=/etc/ard program=touch gparent=su ggparent=sudo gggparent=bash container_id=host image=<NA>)",
                                                                                            "ruleType": "RULE_TYPE_FALCO",
                                                                                            "matchedOnDefault": false,
                                                                                            "fields": [
                                                                                              {
                                                                                                "key": "container.image.repository",
                                                                                                "value": "<NA>"
                                                                                              },
                                                                                              {
                                                                                                "key": "proc.aname[3]",
                                                                                                "value": "sudo"
                                                                                              },
                                                                                              {
                                                                                                "key": "proc.aname[4]",
                                                                                                "value": "bash"
                                                                                              },
                                                                                              {
                                                                                                "key": "proc.cmdline",
                                                                                                "value": "touch /etc/ard"
                                                                                              },
                                                                                              {
                                                                                                "key": "proc.pname",
                                                                                                "value": "bash"
                                                                                              },
                                                                                              {
                                                                                                "key": "falco.rule",
                                                                                                "value": "Write below etc"
                                                                                              },
                                                                                              {
                                                                                                "key": "proc.name",
                                                                                                "value": "touch"
                                                                                              },
                                                                                              {
                                                                                                "key": "fd.name",
                                                                                                "value": "/etc/ard"
                                                                                              },
                                                                                              {
                                                                                                "key": "proc.aname[2]",
                                                                                                "value": "su"
                                                                                              },
                                                                                              {
                                                                                                "key": "proc.pcmdline",
                                                                                                "value": "bash"
                                                                                              },
                                                                                              {
                                                                                                "key": "container.id",
                                                                                                "value": "host"
                                                                                              },
                                                                                              {
                                                                                                "key": "user.name",
                                                                                                "value": "root"
                                                                                              }
                                                                                            ],
                                                                                            "eventLabels": [
                                                                                              {
                                                                                                "key": "host.hostName",
                                                                                                "value": "ardbox"
                                                                                              },
                                                                                              {
                                                                                                "key": "process.name",
                                                                                                "value": "touch /etc/ard"
                                                                                              }
                                                                                            ],
                                                                                            "falsePositive": false,
                                                                                            "baselineId": "",
                                                                                            "policyVersion": 2,
                                                                                            "origin": "Sysdig",
                                                                                            "timestamp": 1606322948648718,
                                                                                            "timestampNs": 1606322948648718268,
                                                                                            "hostMac": "08:00:27:54:f3:9d",
                                                                                            "isAggregated": false
                                                                                        }
                                                                                        

                                                                                        Activity Audit Forwarding Payloads

                                                                                        Each of the activity audit types has its own JSON format.

                                                                                        Command (cmd) Payload

                                                                                        {
                                                                                            "id": "164806c17885b5615ba513135ea13d79",
                                                                                            "agentId": 32212,
                                                                                            "cmdline": "calico-node -felix-ready -bird-ready",
                                                                                            "comm": "calico-node",
                                                                                            "containerId": "a407fb17332b",
                                                                                            "count": 1,
                                                                                            "cwd": "/",
                                                                                            "hostname": "qa-k8smetrics",
                                                                                            "loginShellDistance": 0,
                                                                                            "loginShellId": 0,
                                                                                            "pid": 29278,
                                                                                            "ppid": 29275,
                                                                                            "rxTimestamp": 1605540695537513500,
                                                                                            "timestamp": 1605540695178065200,
                                                                                            "type": "command",
                                                                                            "tty": 0,
                                                                                            "uid": 0
                                                                                        }
                                                                                        

                                                                                        Network (net) Payload

                                                                                        {
                                                                                            "id": "164806f43b4d7e8c6708f40cdbb47838",
                                                                                            "agentId": 32212,
                                                                                            "clientIpv4": 2886795285,
                                                                                            "clientPort": 60720,
                                                                                            "containerId": "da3abd373c7a",
                                                                                            "direction": "out",
                                                                                            "errorCode": 115,
                                                                                            "hostname": "qa-k8smetrics",
                                                                                            "l4protocol": 6,
                                                                                            "pid": 2452,
                                                                                            "processName": "kubectl",
                                                                                            "rxTimestamp": 0,
                                                                                            "serverIpv4": 174063617,
                                                                                            "serverPort": 443,
                                                                                            "timestamp": 1605540913194303200,
                                                                                            "type": "connection"
                                                                                        }
                                                                                        

                                                                                        File (file) Payload

                                                                                        {
                                                                                            "id": "164806c161a5dd221c4ee79d6b5dd1ce",
                                                                                            "agentId": 32212,
                                                                                            "containerId": "a407fb17332b",
                                                                                            "hostname": "qa-k8smetrics",
                                                                                            "timestamp": 1605540694794296600,
                                                                                            "type": "fileaccess",
                                                                                            "directory": "/etc/service/enabled/confd/supervise/",
                                                                                            "filename": "ok",
                                                                                            "permissions": "w",
                                                                                            "pid": 29237,
                                                                                            "comm": "sv",
                                                                                            "cmdline": ""
                                                                                        }
                                                                                        

                                                                                        Kubernetes (kube exec) Payload

                                                                                        {
                                                                                            "id": "164806f4c47ad9101117d87f8b574ecf",
                                                                                            "agentId": 32212,
                                                                                            "args": {
                                                                                                "command": "bash",
                                                                                                "container": "nginx"
                                                                                            },
                                                                                            "auditId": "c474d1de-c764-445a-8142-a0142505868e",
                                                                                            "containerId": "397be1762fba",
                                                                                            "hostname": "qa-k8smetrics",
                                                                                            "name": "nginx-76f9cf7469-k5kf7",
                                                                                            "namespace": "nginx",
                                                                                            "resource": "pods",
                                                                                            "sourceAddresses": [
                                                                                                "172.17.0.21"
                                                                                            ],
                                                                                            "stages": {
                                                                                                "started": 1605540915526159000,
                                                                                                "completed": 1605540915660084000
                                                                                            },
                                                                                            "subResource": "exec",
                                                                                            "timestamp": 1605540915495754000,
                                                                                            "type": "kubernetes",
                                                                                            "user": {
                                                                                                "username": "system:serviceaccount:default:default-kubectl-trigger",
                                                                                                "groups": [
                                                                                                    "system:serviceaccounts",
                                                                                                    "system:serviceaccounts:default",
                                                                                                    "system:authenticated"
                                                                                                ]
                                                                                            },
                                                                                            "userAgent": "kubectl/v1.16.2 (linux/amd64) kubernetes/c97fe50"
                                                                                        }
                                                                                        

                                                                                        Benchmark Result Payloads

                                                                                        To forward benchmark events, you must have Benchmarks v2 installed and configured, using the Node Analyzer.

                                                                                        A Benchmark Control payload is emitted for each control on each host on every Benchmark Run. A Benchmark Run payload containing a summary of the results is emitted for each host on every Benchmark Run.

                                                                                        Benchmark Control Payload

                                                                                        {
                                                                                          "agentId": 0,
                                                                                          "category": "runtime",
                                                                                          "containerId": "",
                                                                                          "content": {
                                                                                            "control": {
                                                                                              "auditCommand": "ps -ef | grep etcd | grep -- --data-dir | sed 's%.*data-dir[= ]\\([^ ]*\\).*%\\1%' | xargs stat -c %U:%G",
                                                                                              "description": "etcd is a highly-available key-value store used by Kubernetes deployments for persistent storage of all of its REST API objects. This data directory should be protected from any unauthorized reads or writes. It should be owned by `etcd:etcd`.",
                                                                                              "expectedOutput": "'' is present",
                                                                                              "failingResources": [
                                                                                                {
                                                                                                  "Hostname": "qa-k8smetrics"
                                                                                                }
                                                                                              ],
                                                                                              "familyName": "Master Node Configuration Files",
                                                                                              "id": "1.1.12",
                                                                                              "level": "Level 1",
                                                                                              "rationale": "etcd is a highly-available key-value store used by Kubernetes deployments for persistent storage of all of its REST API objects. This data directory should be protected from any unauthorized reads or writes. It should be owned by `etcd:etcd`.",
                                                                                              "remediation": "On the etcd server node, get the etcd data directory, passed as an argument --data-dir,\nfrom the below command:\nps -ef | grep etcd\nRun the below command (based on the etcd data directory found above).\nFor example, chown etcd:etcd /var/lib/etcd\n",
                                                                                              "resourceCount": 0,
                                                                                              "resourceType": "Hosts",
                                                                                              "result": "Fail",
                                                                                              "title": "Ensure that the etcd data directory ownership is set to etcd:etcd (Automated)"
                                                                                            },
                                                                                            "runId": "e569ccbb-b314-4fcc-991e-7baa0671ff34",
                                                                                            "schema": "kube_bench_cis-1.6.0",
                                                                                            "source": "host",
                                                                                            "subType": "control",
                                                                                            "taskId": 205
                                                                                          },
                                                                                          "description": "Kubernetes benchmark kube_bench_cis-1.6.0 control 1.1.12 completed.",
                                                                                          "id": "167e641d319f53438dca3c702ecb2460",
                                                                                          "labels": {
                                                                                            "aws.accountId": "059797578166",
                                                                                            "aws.instanceId": "i-0fb61365358ce26a7",
                                                                                            "aws.region": "us-east-1",
                                                                                            "host.hostName": "qa-k8smetrics",
                                                                                            "host.mac": "16:16:ef:cb:72:15",
                                                                                            "kubernetes.cluster.name": "test-k8s-data",
                                                                                            "kubernetes.node.name": "qa-k8smetrics"
                                                                                          },
                                                                                          "machineId": "16:16:ef:cb:72:15",
                                                                                          "name": "Kubernetes Benchmark Control Reported",
                                                                                          "originator": "benchmarks",
                                                                                          "severity": 0,
                                                                                          "source": "host",
                                                                                          "timestamp": 1620842992449311555,
                                                                                          "type": "benchmark"
                                                                                        }
                                                                                        

                                                                                        Benchmark Run Payload

                                                                                        {
                                                                                          "agentId": 0,
                                                                                          "category": "runtime",
                                                                                          "containerId": "",
                                                                                          "content": {
                                                                                            "run": {
                                                                                              "failCount": 11,
                                                                                              "passCount": 67,
                                                                                              "warnCount": 44
                                                                                            },
                                                                                            "runId": "e569ccbb-b314-4fcc-991e-7baa0671ff34",
                                                                                            "schema": "kube_bench_cis-1.6.0",
                                                                                            "source": "host",
                                                                                            "subType": "run",
                                                                                            "taskId": 205
                                                                                          },
                                                                                          "description": "Kubernetes benchmark kube_bench_cis-1.6.0 completed.",
                                                                                          "id": "167e641d319f5343019a4183b1ec2906",
                                                                                          "labels": {
                                                                                            "aws.accountId": "059797578166",
                                                                                            "aws.instanceId": "i-0fb61365358ce26a7",
                                                                                            "aws.region": "us-east-1",
                                                                                            "host.hostName": "qa-k8smetrics",
                                                                                            "host.mac": "16:16:ef:cb:72:15",
                                                                                            "kubernetes.cluster.name": "test-k8s-data",
                                                                                            "kubernetes.node.name": "qa-k8smetrics"
                                                                                          },
                                                                                          "machineId": "16:16:ef:cb:72:15",
                                                                                          "name": "Kubernetes Benchmark Run Failed",
                                                                                          "originator": "benchmarks",
                                                                                          "severity": 0,
                                                                                          "source": "host",
                                                                                          "timestamp": 1620842992449311555,
                                                                                          "type": "benchmark"
                                                                                        }
                                                                                        

                                                                                        Host Scanning Payload

                                                                                        Incremental Report

                                                                                        This is the “vuln diff” report; it contains the list of added, removed, or updated vulnerabilities that the host presents compared to the previous scan.

                                                                                        [
                                                                                          {
                                                                                            "id": "167fddc1197bcc776d72f0f299e83530",
                                                                                            "type": "hostscanning",
                                                                                            "timestamp": 1621258212302,
                                                                                            "originator": "hostscanning",
                                                                                            "category": "hostscanning_incremental_report",
                                                                                            "source": "hostscanning",
                                                                                            "name": "Vulnerability updates - Host dev-vm",
                                                                                            "description": "",
                                                                                            "severity": 4,
                                                                                            "agentId": 0,
                                                                                            "containerId": "",
                                                                                            "machineId": "00:0c:29:e5:9e:51",
                                                                                            "content": {
                                                                                              "hostname": "dev-vm",
                                                                                              "mac": "00:0c:29:e5:9e:51",
                                                                                              "reportType": "incremental",
                                                                                              "added": [
                                                                                                {
                                                                                                  "cve": "CVE-2020-27170",
                                                                                                  "fixAvailable": "5.4.0-70.78",
                                                                                                  "packageName": "linux-headers-5.4.0-67",
                                                                                                  "packageType": "dpkg",
                                                                                                  "packageVersion": "5.4.0-67.75",
                                                                                                  "severity": "High",
                                                                                                  "url": "http://people.ubuntu.com/~ubuntu-security/cve/CVE-2020-27170",
                                                                                                  "vulnerablePackage": "linux-headers-5.4.0-67:5.4.0-67.75"
                                                                                                },
                                                                                                {
                                                                                                  "cve": "CVE-2019-9515",
                                                                                                  "fixAvailable": "None",
                                                                                                  "packageName": "libgrpc6",
                                                                                                  "packageType": "dpkg",
                                                                                                  "packageVersion": "1.16.1-1ubuntu5",
                                                                                                  "severity": "Medium",
                                                                                                  "url": "http://people.ubuntu.com/~ubuntu-security/cve/CVE-2019-9515",
                                                                                                  "vulnerablePackage": "libgrpc6:1.16.1-1ubuntu5"
                                                                                                }
                                                                                              ],
                                                                                              "updated": [
                                                                                                {
                                                                                                  "cve": "CVE-2018-17977",
                                                                                                  "fixAvailable": "None",
                                                                                                  "packageName": "linux-modules-5.4.0-72-generic",
                                                                                                  "packageType": "dpkg",
                                                                                                  "packageVersion": "5.4.0-72.80",
                                                                                                  "severity": "Medium",
                                                                                                  "url": "http://people.ubuntu.com/~ubuntu-security/cve/CVE-2018-17977",
                                                                                                  "vulnerablePackage": "linux-modules-5.4.0-72-generic:5.4.0-72.80"
                                                                                                },
                                                                                                {
                                                                                                  "cve": "CVE-2021-3348",
                                                                                                  "fixAvailable": "5.4.0-71.79",
                                                                                                  "packageName": "linux-modules-extra-5.4.0-67-generic",
                                                                                                  "packageType": "dpkg",
                                                                                                  "packageVersion": "5.4.0-67.75",
                                                                                                  "severity": "Medium",
                                                                                                  "url": "http://people.ubuntu.com/~ubuntu-security/cve/CVE-2021-3348",
                                                                                                  "vulnerablePackage": "linux-modules-extra-5.4.0-67-generic:5.4.0-67.75"
                                                                                                },
                                                                                                {
                                                                                                  "cve": "CVE-2021-29265",
                                                                                                  "fixAvailable": "5.4.0-73.82",
                                                                                                  "packageName": "linux-headers-5.4.0-67-generic",
                                                                                                  "packageType": "dpkg",
                                                                                                  "packageVersion": "5.4.0-67.75",
                                                                                                  "severity": "Medium",
                                                                                                  "url": "http://people.ubuntu.com/~ubuntu-security/cve/CVE-2021-29265",
                                                                                                  "vulnerablePackage": "linux-headers-5.4.0-67-generic:5.4.0-67.75"
                                                                                                },
                                                                                                {
                                                                                                  "cve": "CVE-2021-29921",
                                                                                                  "fixAvailable": "None",
                                                                                                  "packageName": "python3.8-dev",
                                                                                                  "packageType": "dpkg",
                                                                                                  "packageVersion": "3.8.5-1~20.04.2",
                                                                                                  "severity": "Medium",
                                                                                                  "url": "http://people.ubuntu.com/~ubuntu-security/cve/CVE-2021-29921",
                                                                                                  "vulnerablePackage": "python3.8-dev:3.8.5-1~20.04.2"
                                                                                                }
                                                                                              ],
                                                                                              "removed": [
                                                                                                {
                                                                                                  "cve": "CVE-2021-26932",
                                                                                                  "fixAvailable": "None",
                                                                                                  "packageName": "linux-modules-5.4.0-67-generic",
                                                                                                  "packageType": "dpkg",
                                                                                                  "packageVersion": "5.4.0-67.75",
                                                                                                  "severity": "Medium",
                                                                                                  "url": "http://people.ubuntu.com/~ubuntu-security/cve/CVE-2021-26932",
                                                                                                  "vulnerablePackage": "linux-modules-5.4.0-67-generic:5.4.0-67.75"
                                                                                                },
                                                                                                {
                                                                                                  "cve": "CVE-2020-26541",
                                                                                                  "fixAvailable": "None",
                                                                                                  "packageName": "linux-modules-extra-5.4.0-67-generic",
                                                                                                  "packageType": "dpkg",
                                                                                                  "packageVersion": "5.4.0-67.75",
                                                                                                  "severity": "Medium",
                                                                                                  "url": "http://people.ubuntu.com/~ubuntu-security/cve/CVE-2020-26541",
                                                                                                  "vulnerablePackage": "linux-modules-extra-5.4.0-67-generic:5.4.0-67.75"
                                                                                                },
                                                                                                {
                                                                                                  "cve": "CVE-2014-4607",
                                                                                                  "fixAvailable": "2.04-1ubuntu26.8",
                                                                                                  "packageName": "grub-pc",
                                                                                                  "packageType": "dpkg",
                                                                                                  "packageVersion": "2.04-1ubuntu26.7",
                                                                                                  "severity": "Medium",
                                                                                                  "url": "http://people.ubuntu.com/~ubuntu-security/cve/CVE-2014-4607",
                                                                                                  "vulnerablePackage": "grub-pc:2.04-1ubuntu26.7"
                                                                                                }
                                                                                              ]
                                                                                            },
                                                                                            "labels": {
                                                                                              "host.hostName": "dev-vm",
                                                                                              "host.id": "d82e5bde1d992bedd10a640bdb2f052493ff4b3e03f5e96d1077bf208f32ea96",
                                                                                              "host.mac": "00:0c:29:e5:9e:51",
                                                                                              "host.os.name": "ubuntu",
                                                                                              "host.os.version": "20.04"
                                                                                            }
                                                                                          }
                                                                                        ]
                                                                                        

                                                                                        Full Report

                                                                                        The full report contains all the vulnerabilities found during the first host scan.

                                                                                        [
                                                                                          {
                                                                                            "id": "1680c8462f368eaf38d2f269d9de1637",
                                                                                            "type": "hostscanning",
                                                                                            "timestamp": 1621516069618,
                                                                                            "originator": "hostscanning",
                                                                                            "category": "hostscanning_full_report",
                                                                                            "source": "hostscanning",
                                                                                            "name": "Host ip-172-31-94-81 scanned",
                                                                                            "description": "",
                                                                                            "severity": 4,
                                                                                            "agentId": 0,
                                                                                            "containerId": "",
                                                                                            "machineId": "16:1f:b4:f5:02:03",
                                                                                            "content": {
                                                                                              "hostname": "ip-172-31-94-81",
                                                                                              "mac": "16:1f:b4:f5:02:03",
                                                                                              "reportType": "full",
                                                                                              "added": [
                                                                                                {
                                                                                                  "cve": "CVE-2015-0207",
                                                                                                  "fixAvailable": "None",
                                                                                                  "packageName": "libssl1.1",
                                                                                                  "packageType": "dpkg",
                                                                                                  "packageVersion": "1.1.0l-1~deb9u3",
                                                                                                  "severity": "Negligible",
                                                                                                  "url": "https://security-tracker.debian.org/tracker/CVE-2015-0207",
                                                                                                  "vulnerablePackage": "libssl1.1:1.1.0l-1~deb9u3"
                                                                                                },
                                                                                                {
                                                                                                  "cve": "CVE-2016-2088",
                                                                                                  "fixAvailable": "None",
                                                                                                  "packageName": "libdns162",
                                                                                                  "packageType": "dpkg",
                                                                                                  "packageVersion": "1:9.10.3.dfsg.P4-12.3+deb9u8",
                                                                                                  "severity": "Negligible",
                                                                                                  "url": "https://security-tracker.debian.org/tracker/CVE-2016-2088",
                                                                                                  "vulnerablePackage": "libdns162:1:9.10.3.dfsg.P4-12.3+deb9u8"
                                                                                                },
                                                                                                {
                                                                                                  "cve": "CVE-2017-5123",
                                                                                                  "fixAvailable": "None",
                                                                                                  "packageName": "linux-headers-4.9.0-15-amd64",
                                                                                                  "packageType": "dpkg",
                                                                                                  "packageVersion": "4.9.258-1",
                                                                                                  "severity": "Negligible",
                                                                                                  "url": "https://security-tracker.debian.org/tracker/CVE-2017-5123",
                                                                                                  "vulnerablePackage": "linux-headers-4.9.0-15-amd64:4.9.258-1"
                                                                                                },
                                                                                                {
                                                                                                  "cve": "CVE-2014-2739",
                                                                                                  "fixAvailable": "None",
                                                                                                  "packageName": "linux-headers-4.9.0-15-common",
                                                                                                  "packageType": "dpkg",
                                                                                                  "packageVersion": "4.9.258-1",
                                                                                                  "severity": "Negligible",
                                                                                                  "url": "https://security-tracker.debian.org/tracker/CVE-2014-2739",
                                                                                                  "vulnerablePackage": "linux-headers-4.9.0-15-common:4.9.258-1"
                                                                                                },
                                                                                                {
                                                                                                  "cve": "CVE-2014-9781",
                                                                                                  "fixAvailable": "None",
                                                                                                  "packageName": "linux-kbuild-4.9",
                                                                                                  "packageType": "dpkg",
                                                                                                  "packageVersion": "4.9.258-1",
                                                                                                  "severity": "Negligible",
                                                                                                  "url": "https://security-tracker.debian.org/tracker/CVE-2014-9781",
                                                                                                  "vulnerablePackage": "linux-kbuild-4.9:4.9.258-1"
                                                                                                },
                                                                                                {
                                                                                                  "cve": "CVE-2015-8705",
                                                                                                  "fixAvailable": "None",
                                                                                                  "packageName": "libisc-export160",
                                                                                                  "packageType": "dpkg",
                                                                                                  "packageVersion": "1:9.10.3.dfsg.P4-12.3+deb9u8",
                                                                                                  "severity": "Negligible",
                                                                                                  "url": "https://security-tracker.debian.org/tracker/CVE-2015-8705",
                                                                                                  "vulnerablePackage": "libisc-export160:1:9.10.3.dfsg.P4-12.3+deb9u8"
                                                                                                }
                                                                                              ]
                                                                                            },
                                                                                            "labels": {
                                                                                              "agent.tag.distribution": "Debian",
                                                                                              "agent.tag.fqdn": "ec2-3-231-219-145.compute-1.amazonaws.com",
                                                                                              "agent.tag.test-type": "qa-hs",
                                                                                              "agent.tag.version": "9.13",
                                                                                              "host.hostName": "ip-172-31-94-81",
                                                                                              "host.id": "cbd8fc14e9116a33770453e0755cbd1e72e4790e16876327607c50ce9de25a4b",
                                                                                              "host.mac": "16:1f:b4:f5:02:03",
                                                                                              "host.os.name": "debian",
                                                                                              "host.os.version": "9.13"
                                                                                            }
                                                                                          }
                                                                                        ]
                                                                                        

                                                                                        Delete an Event Forwarding Integration

                                                                                        To delete an existing integration:

                                                                                        1. From the Settings module of the Sysdig Secure UI, navigate to the Events Forwarding tab.

                                                                                        2. Click the More Options (three dots) icon.

                                                                                        3. Click the Delete Integration button.

                                                                                        4. Click the Yes, delete button to confirm the change.

                                                                                        8.1.1 -

                                                                                        Forwarding to Splunk

                                                                                        Prerequisites

                                                                                        Splunk event forwards originates from specific IPs, such as 18.209.200.129 for US -East. For the full list of outbound IPs in other regions, see SaaS Regions and IP Ranges.

                                                                                        Update your firewall and allow inbound requests from these IP addresses to enable Sysdig to handle Splunk event forwarding.

                                                                                        Configure Splunk Event Forwarding

                                                                                        To forward event data to Splunk:

                                                                                        1. From the Settings module of the Sysdig Secure UI, navigate to the Events Forwarding tab.

                                                                                        2. Click the Add Integration button.

                                                                                        3. Select Splunk from the drop-down menu.

                                                                                        4. Configure the required options:

                                                                                          Integration Name: Define an integration name.

                                                                                          URL: Define the URL of the Splunk service. This is the HTTP Event Collector that forwards the events to a Splunk deployment. Be sure to use the format scheme://host:port.

                                                                                          Token: This is the token that Sysdig uses to authenticate the connection to the HTTP Event Collector. This token is created when you create the Splunk Event Collector.

                                                                                          Optional: Configure additional Splunk parameters (Index, Source, Source Type) as desired.

                                                                                          Index: The index where events are stored. Specify the Index if you have selected one while configuring the HTTP Event Collector.

                                                                                          Source Type: Identifies the data structure of the event. For more information, see Source Type.

                                                                                          For more information on these parameters, refer to the Splunk documentation.

                                                                                          Data to send: Currently, Sysdig only supports sending policy events.

                                                                                          Select whether or not you want to allow insecure connections (i.e. invalid or self-signed certificate on the receiving side).

                                                                                          Toggle the enable switch as necessary. Remember that you will need to “Test Integration” with the button below before enabling the integration.

                                                                                        5. Click the Save button to save the integration.

                                                                                        Here is an example of how policy events forwarded from Sysdig Secure is displayed on Splunk:

                                                                                        8.1.2 -

                                                                                        Forwarding to Syslog

                                                                                        Syslog refers to System Logging protocol. It is a standard chiefly used by network devices to send events and logs in a particular format to a centralized system for storage and analysis. A Syslog event includes severity level, host IP, timestamps, diagnostics information, and so on.

                                                                                        Sysdig Event Forwarding allows you to send events gathered by Sysdig Secure to a Syslog server.

                                                                                        Configure Syslog Event Forwarding

                                                                                        To forward event data to a Syslog Server:

                                                                                        1. From the Settings module of the Sysdig Secure UI, navigate to the Events Forwarding tab.

                                                                                        2. Click the Add Integration button.

                                                                                        3. Select Syslog from the drop-down menu.

                                                                                        4. Configure the required options:

                                                                                          Integration Name: Define an integration name.

                                                                                          Address: Specify the Syslog server where the events are forwarded. Enter a domain name or IP address. If a domain name resolves to several IP addresses, the first resolved address is used.

                                                                                          Port: Specify the port number.

                                                                                          Protocol: Choose the protocol depending on the server you are sending the logs to:

                                                                                          RFC 3164: RFC 3164 is the older version of the protocol, default port and transport is 514/UDP.

                                                                                          RFC 5424: RFC 5424 is the current version of the protocol, default port and transport is 514/UDP

                                                                                          RFC 5425 (TLS): RFC 5425 (TLS) is an extension to RFC 5424 to use an encrypted channel, default port and transport is 6514/TCP

                                                                                          UDC/TCP; Define transport layer protocol UDP/TCP. Use TCP for security incidents, as it’s far more reliable than UDP for handling network congestion and preventing packet loss.

                                                                                          NOTE: RFC 5425 (TLS) only supports TCP.

                                                                                          Data to Send: Currently, Sysdig only supports sending policy events (events from Sysdig Secure).

                                                                                          Allow insecure connections: Toggle on if you want to allow insecure connections (i.e. invalid or self-signed certificate on the receiving side).

                                                                                          Toggle the enable switch as necessary. Remember that you will need to “Test Integration” with the button below before enabling the integration.

                                                                                        5. Click the Save button to save the integration.

                                                                                        8.1.3 -

                                                                                        Forwarding to IBM Cloud Pak for Multicloud Management

                                                                                        Prerequisite: A grafeas-service-admin-id API key in IBM Cloud Pak for Multicloud Management

                                                                                        To forward event data to IBM Cloud Pak for Multicloud Management:

                                                                                        1. From the Settings module of the Sysdig Secure UI, navigate to the Events Forwarding tab.

                                                                                        2. Click the Add Integration button.

                                                                                        3. Select IBM MCM from the drop-down menu.

                                                                                        4. Configure the required options:

                                                                                          Integration Name: Define an integration name.

                                                                                          URL: This is the URL for your MCM API endpoint. This should be the same that you use to connect to the IBM MCM CloudPak console. Be sure to use the format scheme://host:port.

                                                                                          Grafeas API Key:: You need to create a Grafeas API key that Sysdig will use to authorize and authenticate.

                                                                                          Account ID: (Optional) You can leave it blank to use the default value of id-mycluster-account. If you want to use a different account name, provide it here.

                                                                                          Data to send: Currently, Sysdig only supports sending policy events.

                                                                                          Select whether or not you want to allow insecure connections (i.e. invalid or self-signed certificate on the receiving side).

                                                                                          Toggle the enable switch as necessary. Remember that you will need to “Test Integration” with the button below before enabling the integration.

                                                                                        5. Click the Save button to save the integration.

                                                                                        Here is an example of how events forwarded from Sysdig Secure are displayed on IBM Multicloud Managment Console:

                                                                                        8.1.4 -

                                                                                        Forwarding to IBM QRadar

                                                                                        To forward event data to IBM QRadar:

                                                                                        1. From the Settings module of the Sysdig Secure UI, navigate to the Events Forwarding tab.

                                                                                        2. Click the Add Integration button.

                                                                                        3. Select IBM QRadar from the drop-down menu.

                                                                                        4. Configure the required options:

                                                                                          Integration Name: Define an integration name.

                                                                                          Address: Specify the DNS address of the QRadar installation endpoint.

                                                                                          Port: Port to send data, hardcoded to TCP transport protocol. 514/TCP is the default

                                                                                          Data to Send: Currently, Sysdig only supports sending policy events (events from Sysdig Secure).

                                                                                          Allow insecure connections: Toggle on if you want to allow insecure connections (i.e. invalid or self-signed certificate on the receiving side).

                                                                                          Toggle the enable switch as necessary. Remember that you will need to “Test Integration” with the button below before enabling the integration.

                                                                                        5. Click the Save button to save the integration.

                                                                                        See also: Installing Extensions from IBM’s Knowledge Center.

                                                                                        8.1.5 -

                                                                                        Forwarding to Kafka Topic

                                                                                        Kafka is a distributed system consisting of servers and clients that communicate via a high-performance TCP network protocol. It can be deployed on bare-metal hardware, virtual machines, or containers in on-premise as well as cloud environments.

                                                                                        Events are organized and durably stored in topics. Very simplified, a topic is similar to a folder in a filesystem, and the events are the files in that folder.

                                                                                        Configure Event Forwarder Integration with a Kafka Topic

                                                                                        To forward secure data to Kafka:

                                                                                        1. From the Settings module of the Sysdig Secure UI, navigate to the Events Forwarding tab.

                                                                                        2. Click the Add Integration button.

                                                                                        3. Select Kafka topic from the drop-down menu.

                                                                                        4. Configure the required options:

                                                                                          Integration Name: Define an integration name.

                                                                                          Brokers: Kafka server endpoints. A Kafka cluster may provide several brokers; it follows the “hostname: port” (without protocol scheme). You can list several using a comma-separated list.

                                                                                          Topic: Kafka topic where you want to store the forwarded data

                                                                                          Partitioner/Balancer: Algorithm that the client uses to multiplex data between the multiple Brokers. For compatibility with the Java client, Murmur2 is used as the default partitioner. Supported algorithms are:

                                                                                          • Murmur2

                                                                                          • Round robin

                                                                                          • Least bytes

                                                                                          • Hash

                                                                                          • CRC32

                                                                                          Compression: Compression standard used for the data. Supported algorithms are:

                                                                                          • LZ4

                                                                                          • Snappy

                                                                                          • Gzip

                                                                                          • Standard

                                                                                          Data to send: At present, the integration with Kafka topic supports forwarding Secure Policy Events

                                                                                          Select whether or not you want to allow insecure connections (i.e. invalid or self-signed certificate on the receiving side).

                                                                                          Toggle the enable switch as necessary. Remember that you will need to “Test Integration” with the button below before enabling the integration.

                                                                                        5. Click the Save button to save the integration.

                                                                                        8.1.6 -

                                                                                        Forwarding to Webhook

                                                                                        Webhooks are “user-defined HTTP callbacks.” They are usually triggered by some event. When that event occurs, the source site makes an HTTP request to the URL configured for the webhook. Users can configure them to cause events on one site to invoke behavior on another.

                                                                                        Sysdig Secure leverages webhooks to support integrations that are not covered by any other particular integration/protocol present in the Event Forwarder list.

                                                                                        To forward secure data to a Webhook:

                                                                                        1. From the Settings module of the Sysdig Secure UI, navigate to the Events Forwarding tab.

                                                                                        2. Click the Add Integration button.

                                                                                        3. Select Webhook from the drop-down menu.

                                                                                        4. Configure the required options:

                                                                                          Integration Name: Define an integration name.

                                                                                          Endpoint: Webhook endpoint following the schema protocol (i.e. https://)hostname:port

                                                                                          Authentication: Three different methods are supported:

                                                                                          • Basic authentication: If you select this method, you must fill the Secret field with the desired user: password. No whiteespaces, semicolon character as separation.

                                                                                          • Bearer token: If you select this method, you must fill the Secret field with the desired user: password. No whiteespaces, semicolon character as separation.

                                                                                          • Signature header: If you select this method, you must fill the Secret field with the cryptographic key provided by the software on the other end.

                                                                                          Secret: Authorization / Authentication data. This field depends on the method selected in c).

                                                                                          Custom Headers Any number of custom headers defined by the user to accommodate additional parameters required on the receiving end.

                                                                                          To avoid interfering with the regular webhook protocol and expected headers, the following headers cannot be set using this form.

                                                                                          Data to Send: Currently, Sysdig only supports sending policy events (events from Sysdig Secure).

                                                                                          Due to the heavy connection establishment overhead imposed by the HTTP protocol, the Secure policy events are grouped by time proximity into batches and sent together in a single request as a JSON array. In other words, every HTTP request will contain a JSON array containing one or more policy runtime events.

                                                                                          Select whether or not you want to allow insecure connections (i.e. invalid or self-signed certificate on the receiving side).

                                                                                          Toggle the enable switch as necessary. Remember that you will need to “Test Integration” with the button below before enabling the integration.

                                                                                        5. Click the Save button to save the integration.

                                                                                        8.1.7 -

                                                                                        Event Enrichment with Agent Labels

                                                                                        The agent includes these labels by default when enabling event labels

                                                                                        Enable labels

                                                                                        event_labels:
                                                                                          enabled: true/false
                                                                                        

                                                                                        Default labels

                                                                                        event_labels:
                                                                                          include:
                                                                                            - process.name
                                                                                            - host.hostName
                                                                                            - agent.tag
                                                                                            - container.name
                                                                                            - kubernetes.cluster.name
                                                                                            - kubernetes.namespace.name
                                                                                            - kubernetes.deployment.name
                                                                                            - kubernetes.pod.name
                                                                                            - kubernetes.node.name
                                                                                        

                                                                                        Adding Custom Labels

                                                                                        Event labeling has the ability to both include and exclude event labels.

                                                                                        event_labels:
                                                                                          exclude:
                                                                                            - custom.label.to.exclude
                                                                                        
                                                                                        event_labels:
                                                                                          include:
                                                                                            - custom.label.to.include
                                                                                        

                                                                                        Example of an enriched event being sent to splunk

                                                                                        { [-]
                                                                                        baselineId: null
                                                                                        containerId: e4d32e56d9d2
                                                                                        description: A shell was used as the entrypoint/exec point into a container with an attached terminal.
                                                                                        eventLabels: [ [-]
                                                                                        { [-]
                                                                                        key: kubernetes.node.name
                                                                                        value: ip-172-31-72-246
                                                                                        }
                                                                                        { [-]
                                                                                        key: container.name
                                                                                        value: k8s_elasticsearch_sysdigcloud-elasticsearch-0_sysdigcloud_c824e1f8-aa1f-11e9-aff4-027768606bae_0
                                                                                        }
                                                                                        { [-]
                                                                                        key: kubernetes.cluster.name
                                                                                        value: SysdigBackend
                                                                                        }
                                                                                        { [-]
                                                                                        key: kubernetes.pod.name
                                                                                        value: sysdigcloud-elasticsearch-0
                                                                                        }
                                                                                        { [-]
                                                                                        key: kubernetes.namespace.name
                                                                                        value: sysdigcloud
                                                                                        }
                                                                                        { [-]
                                                                                        key: agent.tag.timezone
                                                                                        value: UTC
                                                                                        }
                                                                                        { [-]
                                                                                        key: agent.tag.location
                                                                                        value: europe
                                                                                        }
                                                                                        { [-]
                                                                                        key: process.name
                                                                                        value: bash
                                                                                        }
                                                                                        { [-]
                                                                                        key: host.hostName
                                                                                        value: ip-172-31-72-246
                                                                                        }
                                                                                        ]
                                                                                        falsePositive: false
                                                                                        fields: [ [+]
                                                                                        ]
                                                                                        hostMac: 02:77:68:60:6b:ae
                                                                                        id: 702701271278202880
                                                                                        isAggregated: false
                                                                                        matchedOnDefault: false
                                                                                        name: Terminal shell in container
                                                                                        output: A shell was spawned in a container with an attached terminal (user=root k8s_elasticsearch_sysdigcloud-elasticsearch-0_sysdigcloud_c824e1f8-aa1f-11e9-aff4-027768606bae_0 (id=e4d32e56d9d2) shell=bash parent=docker-runc cmdline=bash terminal=34816)
                                                                                        policyId: 18
                                                                                        ruleSubtype: null
                                                                                        ruleType: RULE_TYPE_FALCO
                                                                                        severity: 5
                                                                                        timestamp: 1564065391633554
                                                                                        version: 1
                                                                                        }
                                                                                        
                                                                                        

                                                                                        8.2 -

                                                                                        Kubernetes Audit Logging

                                                                                        Kubernetes log integration enables Sysdig Secure to use Kubernetes audit log data for Falco rules, activity audit, and to test the impact of Pod Security Policies. We now provide examples for the distributions and platforms listed below.

                                                                                        The integration allows auditing of:

                                                                                        • Creation and destruction of pods, services, deployments, daemon sets, etc.

                                                                                        • Creating/updating/removing config maps or secrets

                                                                                        • Attempts to subscribe to changes to any endpoint

                                                                                        Review the Types of Secure Integrations table for more context. The Audit Logging (Kubernetes) column lists the various options and their levels of support.

                                                                                        To enable this feature in Sysdig Secure SaaS, install the Sysdig Admission Controller and set the features.k8sAuditDetections to true. After installing, create Kubernetes Audit policies and then you should be able to view results in the UI.

                                                                                        View Results in the UI

                                                                                        Policies will need to be created to use the new Falco rules for Kubernetes audit logging. For information on creating policies, refer to the Policies documentation.

                                                                                        View Audit Logging Rules

                                                                                        The Kubernetes audit logging rules can be viewed in the Sysdig Policies Rules Editor, found in the Policies module. To view the audit rules:

                                                                                        1. From the Policies module, navigate to the Rules Editor tab.

                                                                                        2. Open the drop-down menu for the default rules, and select k8s_audit_rules.yaml:

                                                                                        View Audit Events

                                                                                        Kubernetes audit events will now be routed to the Sysdig agent daemon set within the cluster.

                                                                                        Once the policies are created, the audit events will be able to be observed via the Sysdig Secure Events module.

                                                                                        LEGACY INSTALLATION INSTRUCTIONS

                                                                                        These methods of enabling Kubernetes audit logging on Sysdig Secure SaaS have been replaced by simply installing the Sysdig Admission Controller. See also: July 27, 2021.

                                                                                        if your cluster already has the Kubernetes audit logging enabled, there’s no need to change to the Admission Controller method.

                                                                                        Prerequisites

                                                                                        Install Sysdig Agent and Apply the Agent Service

                                                                                        These instructions assume that the Sysdig agent has already been deployed to the Kubernetes cluster. See Agent Installation for details. When the agent(s) are installed, have the Sysdig agent service account, secret, configmap, and daemonset information on hand.

                                                                                        • If the sysdig-agent-service.yaml was not explicitly deployed during agent installation, you need to apply it now:

                                                                                          kubectl apply -f https://raw.githubusercontent.com/draios/sysdig-cloud-scripts/master/agent_deploy/kubernetes/sysdig-agent-service.yaml -n sysdig-agent
                                                                                          

                                                                                          Note: It is also assumed that the agent has been deployed in the sysdig-agent namespace; if it’s not, you might need to adjust the commands.

                                                                                        • If your agent version is less than 11.2.0: You must add a a variable, k8s_audit_server_url to your agent configmap, and set it to 0.0.0.0.

                                                                                          apiVersion: v1
                                                                                          kind: ConfigMap
                                                                                          metadata:
                                                                                            name: sysdig-agent
                                                                                          data:
                                                                                            dragent.yaml: |
                                                                                              configmap: true
                                                                                              ...
                                                                                              security:
                                                                                                k8s_audit_server_url: 0.0.0.0
                                                                                          

                                                                                          For agent versions 11.2.0+, this step is already configured and no action is needed.

                                                                                        Choose Enablement Steps

                                                                                        Sysdig has tested Kubernetes audit log integration on a variety of platforms and distributions. Each requires different steps, as detailed in the sections below.

                                                                                        The routing of Kubernetes audit events has changed rapidly between Kubernetes versions. For more information, review the Kubernetes documentation.

                                                                                        Routing is accomplished via either:

                                                                                        • Webhook backend: Kubernetes version >= 1.11, or

                                                                                        • Dynamic backend with Audit Sink: Kubernetes version >= 1.13 and <1.19 (deprecated since 1.19)

                                                                                        The table below summarizes the tested options:

                                                                                        Distro/PlatformVersionUses WebhookUses DynamicUses Other
                                                                                        OpenShift3.11X
                                                                                        OpenShift4.2, 4.3X
                                                                                        OpenShift4.4+ not yet supported
                                                                                        MiniShift3.11X
                                                                                        Kops1.15, 1.18, 1.20X
                                                                                        GKE (Google)1.13X (bridge)
                                                                                        EKS (Amazon)eks.5/ Kubernetes 1.14 on AWS Cloud or AWS OutpostX CloudWatch
                                                                                        AKS (Azure)1.15+X (bridge)
                                                                                        RKE (Rancher)RKE v1.0.0/Kubernetes 1.13+X
                                                                                        IKS (IBM)1.15X
                                                                                        Minikube1.11+X

                                                                                        Enable Kubernetes Audit Logging

                                                                                        These instructions assume that the Kubernetes cluster has NO audit configuration or logging in place. The steps add configuration only to route audit log messages to the Sysdig agent.

                                                                                        There is a beta script automating many of these steps, which is suitable for proof-of-concept/non-production environments. In any case, we recommend reading the step-by-step instructions carefully before continuing.

                                                                                        OpenShift 3.11

                                                                                        Openshift 3.11 only supports webhook backends (described as “Advanced Audit” in the Openshift Documentation).

                                                                                        Follow the steps below on the Kubernetes API master node:

                                                                                        1. Copy the provided audit-policy.yaml file to the Kubernetes API master node in the /etc/origin/master directory.

                                                                                          (The file will be picked up by OpenShift services running in containers because this directory is mounted into the Kube API server container at /etc/origin/master.)

                                                                                        2. Create a Webhook Configuration File and copy it to the Kubernetes API master node, in the /etc/origin/master directory.

                                                                                        3. Modify the master configuration by adding the following to your /etc/origin/master/master-config.yaml file, replacing any existing auditConfig: entry.

                                                                                          auditConfig:
                                                                                            enabled: true
                                                                                            maximumFileSizeMegabytes: 10
                                                                                            maximumRetainedFiles: 1
                                                                                            auditFilePath: "/etc/origin/master/k8s_audit_events.log"
                                                                                            logFormat: json
                                                                                            webHookMode: "batch"
                                                                                            webHookKubeConfig: /etc/origin/master/webhook-config.yaml
                                                                                            policyFile: /etc/origin/master/audit-policy.yaml
                                                                                          

                                                                                          One way to do this is to use oc ex config patch.

                                                                                          Assuming the above content were in a file audit-patch.yaml and you had copied /etc/origin/master/master-config.yaml to /tmp/master-config.yaml.original, you could run:

                                                                                          oc ex config patch /tmp/master-config.yaml.original -p "$(cat audit-patch.yaml)" &gt; /etc/origin/master/master-config.yaml
                                                                                          
                                                                                        4. Restart the API server by running the following:

                                                                                          # sudo /usr/local/bin/master-restart api
                                                                                          # sudo /usr/local/bin/master-restart controllers
                                                                                          

                                                                                          Once restarted, the server will route Kubernetes audit events to the Sysdig agent service.

                                                                                        MiniShift 3.11

                                                                                        Like OpenShift 3.11, Minishift 3.11 supports webhook backends, but the way Minishift launches the Kubernetes API server is different. Therefore, the command line arguments are somewhat different than in the instructions above.

                                                                                        1. Copy the provided audit-policy.yaml file to the Minishift VM into the directory /var/lib/minishift/base/kube-apiserver/.

                                                                                          (The file will be picked up by Minishift services running in containers because this directory is mounted into the kube API server container at /etc/origin/master.)

                                                                                        2. Create a Webhook Configuration File and copy it to the Minishift VM into the directory /var/lib/minishift/base/kube-apiserver/.

                                                                                        3. Modify the master configuration by adding the following to /var/lib/minishift/base/kube-apiserver/master-config.yaml on the Minishift VM, merging/updating as required. 

                                                                                          Note:master-config.yaml also exists in other directories such as /var/lib/minishift/base/openshift-apiserver and /var/lib/minishift/base/openshift-controller-manager/.

                                                                                          You should modify the one in kube-apiserver:

                                                                                          kubernetesMasterConfig:
                                                                                            apiServerArguments:
                                                                                            audit-log-maxbackup:
                                                                                            - "1"
                                                                                            audit-log-maxsize:
                                                                                            - "10"
                                                                                            audit-log-path:
                                                                                            - /etc/origin/master/k8s_audit_events.log
                                                                                            audit-policy-file:
                                                                                            - /etc/origin/master/audit-policy.yaml
                                                                                            audit-webhook-batch-max-wait:
                                                                                            - 5s
                                                                                            audit-webhook-config-file:
                                                                                            - /etc/origin/master/webhook-config.yaml
                                                                                            audit-webhook-mode:
                                                                                            - batch
                                                                                          
                                                                                        4. Restart the API server by running the following:

                                                                                          (For minishift)
                                                                                          # minishift openshift restart
                                                                                          

                                                                                          Once restarted, the server will route Kubernetes audit events to the Sysdig agent service.

                                                                                        OpenShift 4.2, 4.3

                                                                                        By default, Openshift 4.2/4.3 enables Kubernetes API server logs and makes them available on each master node, at the path /var/log/kube-apiserver/audit.log. However, the API server is not configured by default with the ability to create dynamic backends.

                                                                                        You must first enable the creation of dynamic backends by changing the API server configuration. You then create audit sinks to route audit events to the Sysdig agent.

                                                                                        1. Run the following to update the API server configuration:

                                                                                          oc patch kubeapiserver cluster --type=merge -p '{"spec":{"unsupportedConfigOverrides":{"apiServerArguments":{"audit-dynamic-configuration":["true"],"feature-gates":["DynamicAuditing=true"],"runtime-config":["auditregistration.k8s.io/v1alpha1=true"]}}}}'
                                                                                          
                                                                                        2. Wait for the API server to restart with the updated configuration.

                                                                                        3. Create a Dynamic Audit Sink.

                                                                                          Once the dynamic audit sink is created, it will route Kubernetes audit events to the Sysdig agent service.

                                                                                        Kops

                                                                                        You will modify the cluster configuration using kops set, update the configuration using kops update, and then perform a rolling update using kops rolling-update.

                                                                                        1. Create a Webhook Configuration File and save it locally.

                                                                                        2. Get the current cluster configuration and save it to a file:

                                                                                          kops get cluster <your cluster name> -o yaml > cluster-current.yaml
                                                                                          
                                                                                        3. To ensure that webhook-config.yaml is available on each master node at /var/lib/k8s_audit, and that the kube-apiserver process is run with the required arguments to enable the webhook backend, you will edit cluster.yaml to add/modify the fileAssets and kubeAPIServer sections as follows:

                                                                                          apiVersion: kops.k8s.io/v1alpha2
                                                                                          kind: Cluster
                                                                                          spec:
                                                                                            ...
                                                                                            fileAssets:
                                                                                              - name: webhook-config
                                                                                                path: /var/lib/k8s_audit/webhook-config.yaml
                                                                                                roles: [Master]
                                                                                                content: |
                                                                                                  <contents of webhook-config.yaml go here>
                                                                                              - name: audit-policy
                                                                                                path: /var/lib/k8s_audit/audit-policy.yaml
                                                                                                roles: [Master]
                                                                                                content: |
                                                                                                  <contents of audit-policy.yaml go here>
                                                                                            ...
                                                                                            kubeAPIServer:
                                                                                              auditLogPath: /var/lib/k8s_audit/audit.log
                                                                                              auditLogMaxBackups: 1
                                                                                              auditLogMaxSize: 10
                                                                                              auditWebhookBatchMaxWait: 5s
                                                                                              auditPolicyFile: /var/lib/k8s_audit/audit-policy.yaml
                                                                                              auditWebhookConfigFile: /var/lib/k8s_audit/webhook-config.yaml
                                                                                            ...
                                                                                          

                                                                                          A simple way to do this using yq would be with the following script:

                                                                                          cat <<EOF > merge.yaml
                                                                                          spec:
                                                                                            fileAssets:
                                                                                              - name: webhook-config
                                                                                                path: /var/lib/k8s_audit/webhook-config.yaml
                                                                                                roles: [Master]
                                                                                                content: |
                                                                                          $(cat webhook-config.yaml | sed -e 's/^/        /')
                                                                                              - name: audit-policy
                                                                                                path: /var/lib/k8s_audit/audit-policy.yaml
                                                                                                roles: [Master]
                                                                                                content: |
                                                                                          $(cat audit-policy.yaml | sed -e 's/^/        /')
                                                                                            kubeAPIServer:
                                                                                              auditLogPath: /var/lib/k8s_audit/audit.log
                                                                                              auditLogMaxBackups: 1
                                                                                              auditLogMaxSize: 10
                                                                                              auditWebhookBatchMaxWait: 5s
                                                                                              auditPolicyFile: /var/lib/k8s_audit/audit-policy.yaml
                                                                                              auditWebhookConfigFile: /var/lib/k8s_audit/webhook-config.yaml
                                                                                          EOF
                                                                                          
                                                                                          yq m -a cluster-current.yaml merge.yaml > cluster.yaml
                                                                                          
                                                                                        4. Configure Kops with the new cluster configuration:

                                                                                          kops replace -f cluster.yaml
                                                                                          
                                                                                        5. Update the cluster configuration to prepare changes to the cluster:

                                                                                          kops update cluster <your cluster name> --yes
                                                                                          
                                                                                        6. Perform a rolling update to redeploy the master nodes with the new files and API server configuration:

                                                                                          kops rolling-update cluster --yes
                                                                                          

                                                                                        GKE (Google)

                                                                                        These instructions assume you have already created a cluster and configured the gcloud and kubectl command-line programs to interact with the cluster. Note the known limitations, below.

                                                                                        GKE already provides Kubernetes audit logs, but the logs are exposed using Stackdriver and are in a different format than the native format used by Kubernetes.

                                                                                        To simplify things, we have written a bridge program that reads audit logs from Stackdriver, reformats them to match the Kubernetes-native format, and sends the logs to a configurable webhook and to the Sysdig agent service.

                                                                                        1. Create a Google Cloud (not Kubernetes) service account and key that has the ability to read logs:

                                                                                          $ gcloud iam service-accounts create swb-logs-reader --description "Service account used by stackdriver-webhook-bridge" --display-name "stackdriver-webhook-bridge logs reader"
                                                                                          $ gcloud projects add-iam-policy-binding <your gce project id> --member serviceAccount:swb-logs-reader@<your gce project id>.iam.gserviceaccount.com --role 'roles/logging.viewer'
                                                                                          $ gcloud iam service-accounts keys create $PWD/swb-logs-reader-key.json --iam-account swb-logs-reader@<your gce project id>.iam.gserviceaccount.com
                                                                                          
                                                                                        2. Create a Kubernetes secret containing the service account keys:

                                                                                          kubectl create secret generic stackdriver-webhook-bridge --from-file=key.json=$PWD/swb-logs-reader-key.json -n sysdig-agent
                                                                                          
                                                                                        3. Deploy the bridge program to your cluster using the provided stackdriver-webhook-bridge.yaml file:

                                                                                          kubectl apply -f stackdriver-webhook-bridge.yaml -n sysdig-agent
                                                                                          

                                                                                        The bridge program routes audit events to the domain name sysdig-agent.sysdig-agent.svc.cluster.local, which corresponds to the sysdig-agent service you created either when deploying the agent or as a prerequisite step.

                                                                                        GKE Limitations

                                                                                        GKE uses a Kuberenetes audit policy that emits a more limited set of information than the one recommended by Sysdig. As a result, there are several limitations when retrieving Kubernetes audit information for the Events feed and Activity Audit features in Sysdig Secure.

                                                                                        Request Object

                                                                                        In particular, audit events for config maps in GKE generally do not contain a requestObject field that contains the object being created/modified.

                                                                                        Pod exec does not Include command/container

                                                                                        For many Kubernetes distributions, an audit event representing a pod exec includes the command and specific container as arguments to the requestURI. For example:

                                                                                        “requestURI”:"/api/v1/namespaces/default/pods/nginx-deployment-7998647bdf-phvq7/exec?command=bash&container=nginx1&container=nginx1&stdin=true&stdout=true&tty=true

                                                                                        In GKE, the audit event is missing those request parameters.

                                                                                        Implications for the Event Feed

                                                                                        If the rule condition trigger includes a field that is not available in the Kubernetes audit log provided by GKE, the rule will not trigger.

                                                                                        As a result, the following rule from k8s_audit_rules.yaml will not trigger: Create/Modify Configmap With Private Credentials. (The contents of configmaps are not included in audit logs, so the contents can not be examined for sensitive information.)

                                                                                        This will limit the information that can be displayed in the outputs of rules. For example the  command=%ka.uri.param[command] output variable in the Attach/Exec Pod rule will always return N/A.

                                                                                        Implications for Activity Audit
                                                                                        • kubectl exec elements will not be scoped to the cluster name; they will only be visible scoping by entire infrastructure

                                                                                        • A kubectl exec item in Activity Audit will not display command or container information

                                                                                        • Drilling down into a kubectl exec will not provide the container activity as there is no information that allows Sysdig to correlate the kubectl exec action with an individual container.

                                                                                        EKS (Amazon)

                                                                                        These instructions were verified with eks.5 on Kubernetes v1.14 for both AWS public cloud and AWS Outposts.

                                                                                        Amazon EKS does not provide webhooks for audit logs, but it allows audit logs to be forwarded to CloudWatch. To access CloudWatch logs from the Sysdig agent, proceed as follows:

                                                                                        1. Enable CloudWatch logs for your EKS cluster.

                                                                                        2. Allow access to CloudWatch from the worker nodes.

                                                                                        3. Add a new deployment that polls CloudWatch and forwards events to the Sysdig agent.

                                                                                        You can find an example configuration that can be implemented with the AWS UI, along with the code and the image for an example audit log forwarder. (In a production system this would be implemented as IaC scripts.)

                                                                                        Please note that CloudWatch is an additional AWS paid offering. In addition, with this solution, all the pods running on the worker nodes will be allowed to read CloudWatch logs through AWS APIs.

                                                                                        AKS (Azure)

                                                                                        Requirements

                                                                                        The installation script (below) has the following command-line tool requirements:

                                                                                        • Azure CLI, already logged into your account

                                                                                        • envsubst (shipped with gettext package)

                                                                                        • kubectl

                                                                                        • curl, tr, grep

                                                                                        Installation

                                                                                        Execute the following script:

                                                                                        curl -s https://raw.githubusercontent.com/sysdiglabs/aks-audit-log/master/install-aks-audit-log.sh | bash -s -- -g YOUR_RESOURCE_GROUP_NAME -c YOUR_AKS_CLUSTER_NAME
                                                                                        

                                                                                        Some resources will be created in the same resource group as your cluster:

                                                                                        • Storage Account, to coordinate event consumers

                                                                                        • Event Hubs, to receive audit log events

                                                                                        • Diagnostic setting in the cluster, to send audit log to Event Hubs

                                                                                        • Kubernetes deployment aks-audit-log-forwarder, to forward the log to Sysdig agent

                                                                                        If everything worked as expected, you can verify that the audit logs are being forwarded executing:

                                                                                        kubectl get pods -n sysdig-agent
                                                                                        # take note of the pod name for aks-audit-log-forwarder
                                                                                        kubectl logs aks-audit-log-forwarder-XXXX -f
                                                                                        

                                                                                        For additional information, optional parameters, and architecture details, see the repository.

                                                                                        To Uninstall

                                                                                        Use the same parameters as for installation. The script will delete all created resources and configurations.

                                                                                        curl -s https://raw.githubusercontent.com/sysdiglabs/aks-audit-log/master/uninstall-aks-audit-log.sh |  bash -s -- -g YOUR_RESOURCE_GROUP_NAME -c YOUR_AKS_CLUSTER_NAME
                                                                                        

                                                                                        RKE (Rancher) with Kubernetes 1.13+

                                                                                        These instructions were verified with RKE v1.0.0 and Kubernetes v1.16.3. It should work with versions as old as Kubernetes v1.13.

                                                                                        Audit support is already enabled by default, but the audit policy must be updated to provide additional granularity. These instructions enable a webhook backend pointing to the agent’s service. Dynamic audit backends are not supported as there isn’t a way to enable the audit feature flag.

                                                                                        1. On each Kubernetes API Master Node, create the directory /var/lib/k8s_audit.

                                                                                        2. On each Kubernetes API master node, copy the provided audit-policy.yaml file to to the master node into the directory /var/lib/k8s_audit. (This directory will be mounted into the API server, giving it access to the audit/webhook files.)

                                                                                        3. Create a Webhook Configuration File and copy it to each Kubernetes API master node, into the directory /var/lib/k8s_audit.

                                                                                        4. Modify your RKE cluster configuration cluster.yml to add extra_args and extra_binds sections to the kube-api section. Here’s an example:

                                                                                          kube-api:
                                                                                          ...
                                                                                              extra_args:
                                                                                                audit-policy-file: /var/lib/k8s_audit/audit-policy.yaml
                                                                                                audit-webhook-config-file: /var/lib/k8s_audit/webhook-config.yaml
                                                                                                audit-webhook-batch-max-wait: 5s
                                                                                              extra_binds:
                                                                                              - /var/lib/k8s_audit:/var/lib/k8s_audit
                                                                                          ...
                                                                                          

                                                                                          This changes the command-line arguments for the API server to use an alternate audit policy and to use the webhook backend you created.

                                                                                        5. Restart the RKE cluster via rke up.

                                                                                        IKS (IBM)

                                                                                        IKS supports routing Kubernetes audit events to a single configurable webhook backend URL. It does not support dynamic audit sinks and does not support the ability to change the audit policy that controls which Kubernetes audit events are sent.

                                                                                        The instructions below were adapted from the IBM-provided documentation on how to integrate with Fluentd. It is expected that you are familiar with (or will review) the IKS tools for forwarding cluster and app logs described there.

                                                                                        Limitation: The Kubernetes default audit policy generally does not include events at the Request or RequestResponse levels, meaning that any rules that look in detail at the objects being created/modified (e.g. rules using the ka.req.* and ka.resp.* fields) will not trigger. This includes the following rules:

                                                                                        • Create Disallowed Pod

                                                                                        • Create Privileged Pod

                                                                                        • Create Sensitive Mount Pod

                                                                                        • Create HostNetwork Pod

                                                                                        • Pod Created in Kube Namespace

                                                                                        • Create NodePort Service

                                                                                        • Create/Modify Configmap With Private Credentials

                                                                                        • Attach to cluster-admin Role

                                                                                        • ClusterRole With Wildcard Created

                                                                                        • ClusterRole With Write Privileges Created

                                                                                        • ClusterRole With Pod Exec Created

                                                                                        These instructions describe how to redirect from Fluentd to the Sysdig agent service.

                                                                                        1. Set the webhook backend URL to the IP address of the sysdig-agent service:

                                                                                          http://$(kubectl get service sysdig-agent -o=jsonpath={.spec.clusterIP} -n sysdig-agent):7765/k8s_audit
                                                                                          
                                                                                        2. Verify that the webhook backend URL has been set:

                                                                                          ibmcloud ks cluster master audit-webhook get --cluster <cluster_name_or_ID>
                                                                                          
                                                                                        3. Apply the webhook to your Kubernetes API server by refreshing the cluster master. It may take several minutes for the master to refresh.

                                                                                          ibmcloud ks cluster master refresh --cluster <cluster_name_or_ID>
                                                                                          

                                                                                        Minikube 1.11+

                                                                                        These instructions were verified using Minikube 1.19.0. Other Minikube versions should also work as long as they run Kubernetes versions 1.11. In all cases below, “the Minikube VM” refers to the VM created by Minikube. In cases where you’re using --vm-driver=none, this means the local machine.

                                                                                        1. Create the directory /var/lib/k8s_audit on the master node. (On Minikube, it must be on the Minikube VM.)

                                                                                        2. For Kubernetes 1.11 to 1.18: Copy the provided audit-policy.yaml file into the directory /var/lib/k8s_audit. (This directory will be mounted into the API server, giving it access to the audit/webhook files. On Minikube, it must be on the Minikube VM.)

                                                                                          For Kubernetes 1.19: Use this audit-policy.yaml file instead.

                                                                                        3. Create a Webhook Configuration File and copy it to each Kubernetes API master node, into the directory /var/lib/k8s_audit.

                                                                                        4. Modify the Kubernetes API server manifest at /etc/kubernetes/manifests/kube-apiserver.yaml, adding the following command-line arguments:

                                                                                          --audit-log-path=/var/lib/k8s_audit/k8s_audit_events.log
                                                                                          --audit-policy-file=/var/lib/k8s_audit/audit-policy.yaml
                                                                                          --audit-log-maxbackup=1
                                                                                          --audit-log-maxsize=10
                                                                                          --audit-webhook-config-file=/var/lib/k8s_audit/webhook-config.yaml
                                                                                          --audit-webhook-batch-max-wait=5s
                                                                                          

                                                                                          Command-line arguments are provided in the container spec as arguments to the program /usr/local/bin/kube-apiserver. The relevant section of the manifest will look like this:

                                                                                          spec:
                                                                                            containers:
                                                                                            - command:
                                                                                              - kube-apiserver --allow-privileged=true --anonymous-auth=false
                                                                                                --audit-log-path=/var/lib/k8s_audit/audit.log
                                                                                                --audit-policy-file=/var/lib/k8s_audit/audit-policy.yaml
                                                                                                --audit-log-maxbackup=1
                                                                                                --audit-log-maxsize=10
                                                                                                --audit-webhook-config-file=/var/lib/k8s_audit/webhook-config.yaml
                                                                                                --audit-webhook-batch-max-wait=5s
                                                                                                ...
                                                                                          
                                                                                        5. Modify the Kubernetes API server manifest at /etc/kubernetes/manifests/kube-apiserver.yaml to add a mount of /var/lib/k8s_audit into the kube-apiserver container. The relevant sections look like this:

                                                                                          volumeMounts:
                                                                                          - mountPath: /var/lib/k8s_audit/
                                                                                            name: k8s-audit
                                                                                            readOnly: true
                                                                                               ...
                                                                                          volumes:
                                                                                          - hostPath:
                                                                                            path: /var/lib/k8s_audit
                                                                                            type: DirectoryOrCreate
                                                                                            name: k8s-audit
                                                                                              ...
                                                                                          
                                                                                        6. Modifying the manifest will cause the Kubernetes API server automatically to restart. Once restarted, it will route Kubernetes audit events to the Sysdig agent’s service.

                                                                                        Prepare Webhook or (Legacy) Dynamic Backend

                                                                                        Most of the platform-specific instructions will use one of these methods.

                                                                                        Create a Webhook Configuration File

                                                                                        Sysdig provides a templated resource file that sends audit events to an IP associated with the Sysdig agent service, via port 7765.

                                                                                        It is “templated” in that the actual IP is defined in an environment variable AGENT_SERVICE_CLUSTERIP, which can be plugged in using a program like envsubst.

                                                                                        1. Download webhook-config.yaml.in.

                                                                                        2. Run the following to fill in the template file with the ClusterIP IP address associated with the sysdig-agent service you created, either when installing the agent or in the prereq step:

                                                                                          AGENT_SERVICE_CLUSTERIP=$(kubectl get service sysdig-agent -o=jsonpath={.spec.clusterIP} -n sysdig-agent) envsubst < webhook-config.yaml.in > webhook-config.yaml
                                                                                          

                                                                                          Note: l Athough service domain names like sysdig-agent.sysdig-agent.svc.cluster.local can not be resolved from the Kubernetes API server (they’re typically run as pods but not really a part of the cluster), the ClusterIPs associated with those services are routable.

                                                                                        Using a webhook backend to route audit events is a feature available from Kubernetes v1.11+. See Kubernetes' documentation for background info.

                                                                                        Create a Dynamic Audit Sink

                                                                                        When using dynamic audit sinks, you must create an AuditSink object that directs audit events to the sysdig agent service.

                                                                                        Sysdig provides a template file that can be used to create the sink.

                                                                                        Dynamic audit webhooks using AuditSink API objects are available from Kubernetes v1.13 and were deprecated it 1.19. See [Kubernetes' documentation](http:// https://kubernetes.io/docs/tasks/debug-application-cluster/audit/#dynamic-backend) for background info.

                                                                                        1. Download audit-sink.yaml.in .

                                                                                        2. Run the following to fill in the template file with the ClusterIP IP address associated with the sysdig-agent service you created, either when installing the agent or in the prereq step:

                                                                                          AGENT_SERVICE_CLUSTERIP=$(kubectl get service sysdig-agent -o=jsonpath={.spec.clusterIP} -n sysdig-agent) envsubst < audit-sink.yaml.in > audit-sink.yaml
                                                                                          
                                                                                        3. Apply the following:

                                                                                          kubectl apply -f audit-sink.yaml -n sysdig-agent
                                                                                          

                                                                                        Test the Integration

                                                                                        To test that Kubernetes audit events are being properly passed to the agent, you can do any of the following:

                                                                                        • Enable the All K8s Object Modifications policy and create a deployment, service, configmap, or namespace to see if the events are recorded and forwarded.

                                                                                        • Enable other policies, such as Suspicious K8s Activity,if and test them.

                                                                                        • You can use the falco-event-generator Docker image to generate activity that maps to many of the default rules/policies provided in Sysdig Secure. You can run the image via a command line like the following:

                                                                                          docker run -v $HOME/.kube:/root/.kube -it falcosecurity/falco-event-generator k8s_audit
                                                                                          

                                                                                          This will create resources in a namespace falco-event-generator.

                                                                                          See also: Using Falco within Sysdig Secure and the native Falco documentation for more information about this tool.

                                                                                        (BETA) Script to Automate Configuration Changes

                                                                                        As a convenience, Sysdig has created a script: enable-k8s-audit.sh, which performs the necessary steps for enabling audit log support for all Kubernetes distributions described above, except EKS.

                                                                                        You can run it via: bash enable-k8s-audit.sh <distribution> where <distribution> is one of the following:

                                                                                        • minishift-3.11

                                                                                        • openshift-3.11

                                                                                        • openshift-4.2, openshift-4.3

                                                                                        • gke

                                                                                        • iks

                                                                                        • rke-1.13 (implies Kubernetes 1.13)

                                                                                        • kops

                                                                                        • minikube-1.13 (implies Kubernetes 1.13)

                                                                                        • minikube-1.12 (implies Kubernetes 1.11/1.12)

                                                                                        It should be run from the sysdig-cloud-scripts/k8s_audit_config directory.

                                                                                        In some cases, it may prompt for the GCE project ID, IKS cluster name, etc..

                                                                                        For Minikube/Openshift-3.11/Minishift 3.11, it will use ssh/scp to copy files to and run scripts on the API master node. Otherwise, it should be fully automated.

                                                                                        8.3 -

                                                                                        Threat Detection with AWS CloudTrail

                                                                                        Threat Detection leverages audit logs from AWS CloudTrail plus Falco rules to detect threats as soon as they occur and bring governance, compliance, and risk auditing for your cloud accounts.

                                                                                        Deploy Sysdig Secure for cloud on AWS and choose the Threat Detection module to track abnormal and suspicious activities in your AWS environment. (In the future, cloud Threat Detection will extend into other environments such as Google and Azure.)

                                                                                        With out-of-the-box Falco rules, this feature can detect events such as:

                                                                                        • Add an AWS user to a group

                                                                                        • Allocate a new elastic IP address to AWS account

                                                                                        • Associate an elastic IP Address to an AWS network interface

                                                                                        • Attach an Administrator Policy

                                                                                        • CloudTrail logging disabled

                                                                                        • Create an HTTP target group without SSL

                                                                                        • Create an AWS user

                                                                                        • Create an internet-facing AWS public-facing load balancer

                                                                                        • Deactivate MFA for user access

                                                                                        • Delete bucket encryption

                                                                                        • Put inline policy in a group to allow access to all resources

                                                                                        Usage Steps

                                                                                        1. Deploy:Deploy Sysdig Secure for cloud on AWS and choose the Threat Detection with CloudTrail option.

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

                                                                                        3. Review the Events feed for detected activity.

                                                                                          • Policies: Check Policies > Runtime Policies and confirm that the AWS Best Practices policy is enabled. This consists of the most-frequently-recommended rules for AWS and CloudTrail. You can customize it by creating a new policy of the AWS CloudTrail type.

                                                                                          • Events: In the Events feed, search ‘cloud’ to show events from AWS CloudTrail.

                                                                                        9 -

                                                                                        Investigate

                                                                                        With Sysdig Secure On-Premises v4.0, an optional feature has been introduced called Rapid Response. It enables designated users to remote connect into a host from within the Sysdig Secure interface. For on-prem users who enable this functionality, their menu options will differ from earlier versions and from the SaaS version. This section describes those options and changes.

                                                                                        With Sysdig Secure SaaS (June, 2021), the Activity Audit and Capture modules have been moved into Investigate.

                                                                                        On-Prem Overview

                                                                                        If Sysdig Secure On-Prem v.4.0.0 is installed and the Rapid Response feature flag has been enabled by Sysdig Support, the following differences will appear in the Sysdig Secure UI for designated users:

                                                                                        • Left navigation: Captures is replaced by Investigate

                                                                                          The Captures feature is now a subset of the Investigate module, along with the new Rapid Response feature.

                                                                                        • Rapid Response pages: Accessed from the Investigate module, the Start Session and Session Log pages have been added. See Rapid Response for details.

                                                                                        SaaS Overview

                                                                                        Activity Audit and Captures features are now both subsets of the Investigate module. See also: June 9, 2021.

                                                                                        9.1 -

                                                                                        Activity Audit

                                                                                        From Sysdig Secure 3.0 (with Sysdig Agent 0.93.0+), the Commands Audit feature has been replaced by the more powerful and intuitive Activity Audit module.

                                                                                        Contact Sysdig Support to have Activity Audit enabled for your SaaS Sysdig Secure environment.

                                                                                        To track kubectl exec and other Kubernetes commands, you must enable Kubernetes audit logging.

                                                                                        If you are running on a GKE cluster, review the GKE Limitations.

                                                                                        From June, 2021, Activity Audit has been moved under the Investigate menu in the nav bar.

                                                                                        Activity Audit takes the high-value data from captures and makes it always-on, searchable, and indexed against your cloud-native assets. This stream includes executed commands, network activity, file activity, and kube exec requests to the Kubernetes API.

                                                                                        Understanding How Activity Audit is Used

                                                                                        Activity Audit allows users to view different data sources in-depth for monitoring, troubleshooting, diagnostics, or to meet regulatory controls.

                                                                                        Troubleshooting

                                                                                        A system investigation may be triggered by an event generated by Sysdig, or by an alert from another tool or person.

                                                                                        • Find contextualized, relevant data Activity Audit allows easy access to the underlying data to help trace the event, evaluate its impact, and resolve the issue.

                                                                                          From Policy Events in Sysdig Secure, jump directly to the relevant Activity Audit to investigate details.

                                                                                        • Trace commands and connections back to users Activity Audit can correlate the interactive requests from a Kubernetes user with the commands and network connections performed inside the container, allowing an operator to trace this activity back to a user identity.

                                                                                        Regulatory

                                                                                        The Activity Audit can also provide data about the infrastructure to help prove to auditors that proper data visibility and security measures are in place

                                                                                        Activity Audit is a critical requisite for many compliance standards:

                                                                                        Activity Audit displays a continuously updated list of activities. Use the UI features to find and filter the information you need.

                                                                                        Select Investigate > Activity Audit to access.

                                                                                        Groupings

                                                                                        Filter activities by pre-defined groupings from the drop-down menu.

                                                                                        Note that each element in a group shows a summary of the activity entries for that entity. You can use this number to discover areas of high activity; filtering changes the number.

                                                                                        Data Sources

                                                                                        Use the top-right drop-down to filter information from one particular data set. Current data sources are:

                                                                                        • User commands

                                                                                        • Network connections

                                                                                        • File activities

                                                                                        • Kube exec commands

                                                                                        Activity audit feature captures only interactive commands and the network connections and file modifications related to those commands. Kube exec commands, on the other hand, are extracted from the Kubernetes/OpenShift audit log.

                                                                                        Frequency Graph

                                                                                        The graph shows the activity frequency for each data source, allowing users easily to zero-in on anomalies.

                                                                                        The image above shows a spike in network activity (orange line) between 7:00 - 8:00 pm.

                                                                                        Drag the mouse over the peak to auto-zoom on the time frame and see more detail.

                                                                                        Time Navigation Buttons

                                                                                        Use the time window navigation bar to show only activities run within that window. (For more information, see also Time Windows.)

                                                                                        Sysdig Secure does not currently provide the functionality to configure a custom time window.

                                                                                        Detail View

                                                                                        Select an activity row to see its details, including the attributes by which you can filter (whitelist/blacklist).

                                                                                        See Review Activity Details for the attributes of each data source.

                                                                                        You can also use the whitelist (=)/blacklist (!=) attribute filters from the detail view.

                                                                                        Whitelist (=) and Blacklist (!=) Attribute Options

                                                                                        Next to attributes in the Detail View are =/!= signs used for filtering.

                                                                                        Click = to include an attribute; click != to exclude an attribute from a filter.

                                                                                        Trace Button (kube exec activity)

                                                                                        Beside each kube exec item is a Trace button .

                                                                                        Using this feature you can correlate container activity to the original Kubernetes user and IP. See Follow a kubectl exec Trace.

                                                                                        This button does not appear if you are running on a GKE cluster.

                                                                                        Filter

                                                                                        Filtering is the heart of Activity Audit’s power. Filters allow you to search, sort, parse, and surface meaningful data and connections as they are needed.

                                                                                        Filters are used instead of free text search in Activity Audit.

                                                                                        Ways to filter Activity Data:

                                                                                        • Data Source: Choose a data source from the drop-down: network activity, commands, kubectl exec, or file activity.

                                                                                        • Attribute (=/!=): Choose = or -!= next to an attribute to include/exclude that attribute from the filter

                                                                                        • Attribute (manual): If you know the attribute, you can type it into the filter box manually, with the following syntax:

                                                                                          Include an attribute

                                                                                          attribute_name="attribute_value" e.g. comm="grep"

                                                                                          Exclude an attribute

                                                                                          attribute_name!="attribute_value" e.g. comm!="grep"

                                                                                        • Trace Trace kube exec entries to see all relevant activity in that session from that user

                                                                                        • Time graph: Select a section of the graph to zoom in on a time frame and see detailed activity

                                                                                        • Combine: These methods can be combined as needed.

                                                                                          For example, the filter below surfaces activity on a particular pod, while excluding activity from one IP address that is known to be normal.

                                                                                          resource="pods" name="woocommerce-6877958" sourceaddresses!="172.20.41.2

                                                                                        Review Activity Details

                                                                                        Command Details

                                                                                        Name

                                                                                        Description

                                                                                        When

                                                                                        The date and time the command was executed.

                                                                                        Command

                                                                                        The command executed.

                                                                                        Full Command Line

                                                                                        The complete command, including all variables/options.

                                                                                        Working Directory

                                                                                        The directory the command was executed in.

                                                                                        Scope

                                                                                        The entities within the infrastructure impacted by the command.

                                                                                        Host

                                                                                        The hostname and MAC address of the host the command was executed on.

                                                                                        Container

                                                                                        The container ID, container name, and image that the command was executed on.

                                                                                        Additional Details

                                                                                        Detailed user/host information:

                                                                                        • The Process ID (PID) of the command.

                                                                                        • The Parent Process ID (PPID) of the command.

                                                                                        • The user ID of the user that executed the command.

                                                                                        • The Shell ID.

                                                                                        Network Connection Details

                                                                                        Only TCP or UDP connections are currently captured in activity audit.

                                                                                        Name

                                                                                        Description

                                                                                        Time

                                                                                        The date and time of the network connection

                                                                                        Connection Direction

                                                                                        Incoming or outgoing connection

                                                                                        Connection Details

                                                                                        Including:

                                                                                        • Transport-level protocol (lp4)

                                                                                        • Client address, server address (lp4)

                                                                                        • Client port, server port

                                                                                        Scope

                                                                                        The entities impacted by the network connection

                                                                                        Host

                                                                                        The host name and MAC address of the host where the connection was made

                                                                                        Additional Details

                                                                                        The process name and ID (Parent Process ID/PID) that launched or received the network connection

                                                                                        Kubectl Exec Details

                                                                                        Name

                                                                                        Description

                                                                                        Time

                                                                                        The date and time of the kubectl command

                                                                                        Kubernetes resource

                                                                                        Including:

                                                                                        • resource: The kind of Kubernetes resource affected (currently only pods)

                                                                                        • name: name of the resource (pod name)

                                                                                        • subresource: currently exec

                                                                                        • command: the command executed

                                                                                        • container: the high-level name in the Kubernetes defintion

                                                                                        Kubernetes user and group

                                                                                        Including:

                                                                                        • user: user name performing the kubectl command. Can be either a service account or a human user.

                                                                                        • groups: groups the user belongs to

                                                                                        • userAgent: client userAgent

                                                                                        Sources addresses

                                                                                        External IP address that initiated the connection

                                                                                        Scope

                                                                                        Including

                                                                                        • Kubernetes namespace name

                                                                                        • Kubernetes deployment name

                                                                                        • Kubernetes pod name

                                                                                        • Container ID

                                                                                        Host

                                                                                        Host name and MAC address of the host where the kubectl exec was made

                                                                                        File Activity Details

                                                                                        Name

                                                                                        Description

                                                                                        When

                                                                                        Date and time the file was modified

                                                                                        File access details

                                                                                        - File name

                                                                                        - File directory

                                                                                        - Command used to access the file

                                                                                        - Access mode

                                                                                        Scope

                                                                                        Entities impacted by the file activity

                                                                                        Host

                                                                                        The host name and MAC address of the host where the file activity occurred

                                                                                        Sample Use Cases

                                                                                        Blacklist: Commands

                                                                                        I have a noisy command happening every 0.2s, which I know is totally normal in my environment. There are other commands that look more suspicious to me:

                                                                                        Foo
                                                                                        Foo
                                                                                        Foo
                                                                                        Foo
                                                                                        Foo
                                                                                        Suspicious command - curl
                                                                                        Foo
                                                                                        Foo
                                                                                        Foo
                                                                                        … 200 Foo
                                                                                        Suspicious command  - dpkg
                                                                                        …. 500 Foo
                                                                                        Suspicious command  - shred
                                                                                        

                                                                                        This is a clear case for blacklisting “Foo” and concentrating on the rest.

                                                                                        Filtering for Incident Response

                                                                                        A Policy Event reports a dangerous peak in network connections coming from a specific pod. This example describes one way to search for the root cause.

                                                                                        What user and what activity triggered this issue?

                                                                                        1. Use the Activity Audit button next to the policy event to jump directly to the relevant audit trail.

                                                                                        2. Here one can determine at a glance:

                                                                                          • The pod/namespace on which the heightened activity is occurring (where the 3396 network entries are)

                                                                                          • The process related to the activity (in this case, ab, or the Apache Benchmark tool)

                                                                                          • Related activities in the graph (cmd and kube exec lines)

                                                                                          • Repetitive entries that can be screened out

                                                                                        3. Refine the view through filtering:

                                                                                          1. Switch from network data source to cmd and kube exe.

                                                                                          2. Filter out noisy, repetitive entries (e.g. comm!="bash")

                                                                                          3. Investigate details of a kube exec item for user information.

                                                                                        4. After filtering, you have a focused incident report detailing:

                                                                                          • The Kubernetes user “johndoe”

                                                                                          • The external IP he used to connect

                                                                                          • The set of commands he used to install and launch the Apache Benchmark stress-testing tool.

                                                                                        Follow a kubectl exec Trace

                                                                                        In a production environment, kubectl exec commands are typically suspicious. Also, because such commands are interactive sessions, it can be difficult to pinpoint which individual has issued the command(s) and what other activities the individual performed. This is where Sysdig’s Trace functionality comes in, correlating kubectl exec commands with a specific user and the network and command activities performed in that user’s session.

                                                                                        In this example, suspicious activity has been detected and you want to determine whether someone has downloaded and executed a Trojan horse.

                                                                                        1. Use the Groups to display your Kubernetes hierarchy by namespace and deployment. Focus on the pod displaying unexpected high levels of activity (based on the number in parentheses).

                                                                                        2. Checking the corresponding activity graph, you zero in on a time frame and see kube exec activity among the hundreds of commands and network events.

                                                                                        3. Select the kube exec item and click the Trace button on left.

                                                                                          This session trace will display a formatted report of any container activity (network, commands) that the user performed inside the container.

                                                                                          This button does not appear if you are running on a GKE cluster.

                                                                                        9.1.1 -

                                                                                        [Legacy] Commands Audit

                                                                                        The Commands Audit module provides Sysdig Secure users with a searchable and sortable audit trail of user commands executed within the infrastructure.

                                                                                        While policy events are an inherently suspicious activity that warrants investigation, commands are not themselves considered suspicious.

                                                                                        The Sysdig Agent examines all execve events. Information about commands that meet the following criteria is saved by the Sysdig backend, and made available for review as a command entry in the Commands Audit module table:

                                                                                        • A program was launched by a shell associated with a terminal (i.e. is related to a user-entered command).

                                                                                        • The parent process was launched in a running container (i.e. the result of a docker exec <container> command).

                                                                                        If an excessive volume of commands occurs in a given second, some commands may be excluded from the information sent from the agent to the Sysdig backend.

                                                                                        The table below outlines the information displayed in the Command Audits module:

                                                                                        DataDescription
                                                                                        TimeThe date and time the command was executed.
                                                                                        ShellThe terminal shell the command was executed in.
                                                                                        Command LineThe full command executed, including flags/variables.
                                                                                        ScopeThe affected scope within the infrastructure.

                                                                                        Review a Command

                                                                                        Individual commands can be reviewed by selecting the line item in the Commands Audit module table. This opens the Command Details window:

                                                                                        The table below outlines the information displayed in the Command Details window:

                                                                                        Name

                                                                                        Description

                                                                                        When

                                                                                        The date and time the command was executed.

                                                                                        Command

                                                                                        The command executed.

                                                                                        Full Command Line

                                                                                        The complete command, including all variables/options.

                                                                                        Working Directory

                                                                                        The directory the command was executed in.

                                                                                        Scope

                                                                                        The entities within the infrastructure impacted by the command.

                                                                                        Host

                                                                                        The hostname and MAC address of the host the command was executed on.

                                                                                        Container

                                                                                        The container ID, container name, and image that the command was executed on.

                                                                                        Additional Details

                                                                                        Detailed user/host information:

                                                                                        • The Process ID (PID) of the command.

                                                                                        • The Parent Process ID (PPID) of the command.

                                                                                        • The user ID of the user that executed the command.

                                                                                        • The Shell ID.

                                                                                        • The distance from the root of the process hierarchy.

                                                                                        Filtering the Commands Table

                                                                                        The Commands Audit module’s table can be filtered to display only the most relevant commands for a particular issue, or to provide greater visibility of a more targeted scope within the infrastructure. There are three ways to filter the table, which can be used in tandem to refine the information presented.

                                                                                        Groupings

                                                                                        Groupings are hierarchical organizations of labels, allowing users to organize their infrastructure views in a logical hierarchy. Users can switch between pre-configured groupings via the Browse By menu, or configure custom groupings, and then dive deeper into the infrastructure.

                                                                                        Time Navigation

                                                                                        Use the time window navigation bar to show only activities run within that window. (For more information, see also Time Windows.)

                                                                                        Sysdig Secure does not currently provide the functionality to configure a custom time window.

                                                                                        Search Filters

                                                                                        Search filters can be applied by either using the search bar directly or by adding pre-configured search strings via the Command Details panel. The search bar example below displays only table items that include apt-get:

                                                                                        To use a pre-configured search string:

                                                                                        1. From the Commands Audit module, select a command from the table to open the Command Details window.

                                                                                        2. Add a filter by click the Add link beside one of the available options:

                                                                                        The example below shows the table filtered by the working directory:

                                                                                        Pre-configured filters exist for the following information:

                                                                                        • Command

                                                                                        • Working Directory

                                                                                        • Process ID

                                                                                        • Parent Process ID

                                                                                        • User ID

                                                                                        • Shell ID

                                                                                        • Shell Distance

                                                                                        Search filters can be deleted by either deleting the text in the search bar or clicking the Remove link beside the filter in the Command Details window.

                                                                                        9.2 -

                                                                                        Captures

                                                                                        Sysdig capture files contain system calls and other OS events that can be analyzed with either the open-source sysdig or csysdig (curses-based) utilities, and are displayed in the Captures module.

                                                                                        The Captures module contains a table listing the capture file name, the host it was retrieved from, the time frame, and the size of the capture. When the capture file status is uploaded, the file has been successfully transmitted from the Sysdig agent to the storage bucket, and is available for download and analysis.

                                                                                        This section describes how to create capture files in Sysdig Secure.

                                                                                        This feature is available in the Enterprise tier of the Sysdig product. See https://sysdig.com/pricing for details, or contact sales@sysdig.com.

                                                                                        If upgrading from Essentials to Enterprise, users must go to Settings>Teams><Your Team> and check the Enable Captures box. They must then log out and log in again. See also: User and Team Administration.

                                                                                        From June, 2021, the Captures module has moved under the Investigate menu in the nav bar.

                                                                                        Configure Capture Files

                                                                                        Store Capture Files

                                                                                        Sysdig capture files are stored in Sysdig’s AWS S3 storage (for SaaS environments), or in the Cassandra DB (for on-premises environments) by default.

                                                                                        Create a Capture File

                                                                                        Capture files can be created in Sysdig Secure either by configuring them as part of a policy, or by manually creating them from the Captures module.

                                                                                        For more information on creating a capture as part of a policy, see Manage Policies.

                                                                                        To create a capture file manually:

                                                                                        1. From the Captures module, click the Take Capture button to open the capture creation window.

                                                                                        2. Define the name of the capture.

                                                                                        3. Configure the host and container the capture file should record system calls from.

                                                                                        4. Define the duration of the capture. The maximum length is 300 seconds (five minutes).

                                                                                        5. Click the Start button.

                                                                                        The Sysdig agent will be signaled to start a capture and send back the resulting trace file. The file will then be displayed in the Captures module.

                                                                                        Delete a Capture File

                                                                                        1. From the Captures module, select the capture file(s) to be deleted.

                                                                                        2. Click the Delete (trash can) icon:

                                                                                        3. Click the Yes (tick) icon to confirm deleting the capture, or the No (cross) icon to cancel.

                                                                                        Review Capture Files

                                                                                        Review the Capture File with Sysdig Inspect

                                                                                        To review the capture file in Sysdig Inspect:

                                                                                        1. From the Captures module, select the capture file to be deleted.

                                                                                        2. Click the Inspect (Sysdig logo) icon to open Sysdig Inspect in a new browser tab:

                                                                                        See also: Quick Menu to Captures from Runtime Events.

                                                                                        Download a Capture File

                                                                                        To download a capture file:

                                                                                        1. From the Captures module, select the target capture file.

                                                                                        2. Click the Download icon to download the capture file.

                                                                                        The capture file will now be downloaded to the local machine.

                                                                                        Disable Capture Functionality

                                                                                        Sometimes, security requirements dictate that capture functionality should NOT be triggered at all (for example, PCI compliance for payment information).

                                                                                        To disable Captures altogether, edit the agent configuration file as described in Disable Captures.

                                                                                        9.3 -

                                                                                        Rapid Response

                                                                                        Overview

                                                                                        With Rapid Response, Sysdig has introduced a way to grant designated Advanced Users in Sysdig Secure the ability to remote connect into a host directly from the Event stream and execute desired commands there.

                                                                                        Finding the team or developer responsible for an application in a cloud or Kubernetes environment can take hours or days. Troubleshooting a live issue or security event may require faster investigation, to lower the MTTR of these events.

                                                                                        Rapid Response allows security teams to connect to a remote shell within your environment to start troubleshooting and investigating an event using the commands they are already accustomed to, with the flexibility they need to run the security tools at their disposal, directly from the event alert.

                                                                                        Process Overview

                                                                                        • Install: Install and configure the Rapid Response container on Sysdig Secure on-premises v4.0 and request that Sysdig Support enable the Rapid Response flag.

                                                                                        • Create Teams: Create a team/teams of Sysdig Secure Advanced Users who should have Rapid Response privileges

                                                                                        • Enable: Enable Rapid Response for those teams

                                                                                        • Use: Team members log in and manage events using Rapid Response shell or review and manage Rapid Response logs.

                                                                                        Create Rapid Response Teams

                                                                                        Rapid Response team members have access to a full shell from within the Sysdig Secure UI. Responsibility for the security of this powerful feature rests with you: your enterprise and your designated employees.

                                                                                        Suppose you have an existing team called CustomerResponse with 40 members and you’d like five of those users to be granted Rapid Response capabilities. You could create a team called, e.g.,CustomerResponse_RR and add the five designated Advanced Users to it.

                                                                                        1. Create a team or teams, as described here

                                                                                        2. Add users, assigning them the Advanced User role.

                                                                                        3. Enable Rapid Response for the designated team(s). Select Settings > Teams and choose a Rapid Response team from the list. On the resulting Edit Teams page, select the Enable Rapid Response checkbox.

                                                                                        Usage

                                                                                        There are two points of entry to the Rapid Response feature:

                                                                                        • From the Investigate component link

                                                                                        • From the Events feed detail panel

                                                                                        In either case, the user will be prompted to enter a 2FA authentication code generated on the fly by the Sysdig backend as soon as they launch the session. This code will be emailed to the user.

                                                                                        Launch Session from Investigate Button

                                                                                        1. Log in the Sysdig Secure UI as a Rapid Response team member.

                                                                                        2. Select Investigate > Rapid Response | Start Session.

                                                                                        3. Select the host as prompted and click Start Session.

                                                                                        4. Enter your password.

                                                                                        5. Enter the 2FA code that was emailed to your user address and click Confirm.

                                                                                        6. Begin your session. You can dock the terminal window at the bottom or right panel of your page, or as a separate screen.

                                                                                        Launch Session from Events Detail

                                                                                        1. Log in the Sysdig Secure UI as a Rapid Response team member.

                                                                                        2. Select Events and choose an event from the list to open the detail pane. Click Respond: Launch Rapid Response.

                                                                                        3. Enter the 2FA code that was emailed to your user address and click Confirm.

                                                                                        4. Begin your session. You can dock the terminal window at the bottom or right panel of your page, or as a separate screen.

                                                                                        Manage Rapid Response Logs

                                                                                        When reviewing the logs, you can download log sessions that have been completed, or close sessions that are live, if needed.

                                                                                        The logs visible to the user depend on the team and role under which they are logged in. Administrators will see the entire log list.

                                                                                        Review Session Log Info

                                                                                        The Session Log list includes the session initiator, the timestamp, and the host name accessed.

                                                                                        Download Session Information

                                                                                        If the session has been closed, the content of the session can be downloaded from the UI (input and output) as an Open SLL-compatible gzip encrypted file.

                                                                                        To open the file, use the following command, where session-file is the name of the downloaded file.

                                                                                        gzip -dc session-file | openssl enc -d -aes-256-ctr -pbkdf2zcat session-file | openssl enc -d -aes-256-ctr -pbkdf2
                                                                                        

                                                                                        Close an Active Session

                                                                                        Any Rapid Response team member can review the Session Log list and close any active session by clicking the Close link.

                                                                                        10 -

                                                                                        Integrations for Sysdig Secure

                                                                                        “Integrations” for Sysdig Secure include a wide range of tools and software designed to connect Secure functionality (e.g., image scanning, event handling, audit logging, and risk analysis) with other systems. Some such tools are installed with the backend. Others are not, because they exist to accommodate specific use cases, infrastructure details, or additional customizations.

                                                                                        Levels of Support

                                                                                        These added tools are called “extensions” and It is up to the user to decide which extensions to install on top of the core backend functionality.

                                                                                        There are two different categories of extensions depending on the support level and backward- compatibility guarantees:

                                                                                        • Preview features - These are pre-release features for which Sysdig is seeking early feedback from users. If you’re interested in trying these items, we will connect you directly with our product/engineering teams. Depending on the level of engagement with a preview Sysdig will decide to deprecate it or move it into an officially supported extension or feature.   

                                                                                        • Fully supported) Extension features - These extensions are installed outside the core Sysdig product and leverage Sysdig APIs, but they are fully supported at the same level as any other core product feature.

                                                                                        Features that are delivered with the core product are designated as “built-in” and always receive full support.

                                                                                        Sysdig delivers many other code examples and integrations as blog content, webinars, whitepapers, etc. Any code snippet or integration that is not explicitly listed in the tables above is not officially supported and is merely illustrative of a particular feature or capability.

                                                                                        Types of Secure Integrations

                                                                                        Image scanning functionality can be integrated into the CI/CD pipeline and with container registries. Kubernetes logs can be integrated from a variety of platforms and distributions. Events can be forwarded to various external processing systems.

                                                                                        Fully supported Extensions are marked with E. Preview features are marked with P.

                                                                                        CI/CD PipelineContainer RegistriesAudit Logging (Kubernetes)Event Forwarding
                                                                                        Jenkins pluginEAWS ECR EGoogle GKEESplunk (built-in)
                                                                                        Azure PipelinesPHarbor Scanner AdaptorPAmazon EKSESyslog (built-in)
                                                                                        AWS CodepipelinePGoogle GCR (built-in)Azure AKSPIBM QRadar (built-in)
                                                                                        CircleCIPAzure ACR (built-in)Native configurationsEIBM MCM (built-in)
                                                                                        Github ActionsPArtifactory (built-in)
                                                                                        GitlabPDockerhub (built-in)
                                                                                        Tekton PipelinesPQuay (built-in)

                                                                                        Additional Integration Tools

                                                                                        Developer Tools:

                                                                                        Admission ControllerPfor image scanning:

                                                                                        Notification Channels which must be configured for Sysdig Secure and Sysdig Monitor separately. All are built-in.

                                                                                        IBM Cloud Pak for Multicloud Management E full integration guide

                                                                                        10.1 -

                                                                                        Integrate IBM Cloud Pak for Multicloud Management

                                                                                        IBM Cloud Pak for Multicloud Management centralizes visibility, governance, and automation for containerized workloads across clusters and clouds into a single dashboard. One of the key capabilities of the product is the centralization of security findings to help cloud team administrators understand, prioritize, manage and resolve security issues that are related to their cloud applications and workloads.

                                                                                        The integration of Sysdig Secure with IBM Cloud Pak for Multicloud Management extends the depth of security intelligence available with:

                                                                                        • Container image vulnerability management and configuration validation

                                                                                        • Runtime security with prevention, threat detection, and mitigation

                                                                                        • Incident response and forensics

                                                                                        • Compliance and audit

                                                                                        Sysdig Secure increases IBM Cloud Pak for Multicloud Management compliance capabilities to help meet regulatory requirements like NIST, PCI, GDPR, or HIPAA. By deploying the products together, users can extend container security to prevent vulnerabilities, stop threats, accelerate incident response, and enable forensics.

                                                                                        The integration involves several components, each of which is installed and configured separately.

                                                                                        Users of IBM Cloud Pak for Multicloud Management can follow the Installation Integration Guide to install and configure:

                                                                                        • The Sysdig agent

                                                                                        • Event forwarding integration

                                                                                        • Single sign-on (SSO) integration via OpenID Connect

                                                                                        • Navigation menu shortcut integration

                                                                                        For More Information

                                                                                        11 -

                                                                                        Sysdig Secure for cloud

                                                                                        Sysdig Secure for cloud is the software that connects Sysdig Secure features to your cloud environments to provide unified threat detection, compliance, forensics, and analysis.

                                                                                        Because modern cloud applications are no longer just virtualized compute resources, but a superset of cloud services on which businesses depend, controlling the security of your cloud accounts is essential. Errors can expose an organization to risks that could bring resources down, infiltrate workloads, exfiltrate secrets, create unseen assets, or otherwise compromise the business or reputation. As the number of cloud services and configurations available grows exponentially, using a cloud security platform protects against having an unseen misconfiguration turn into a serious security issue.

                                                                                        Multiple Installation Options

                                                                                        At this time, Sysdig Secure for cloud is available on AWS using either:

                                                                                        • An AWS CloudFormation Template (CFT): This option provides all four cloud features: threat detection, CSPM benchmarks, and image and container registry scanning), or

                                                                                        • Terraform files: for two types of AWS account

                                                                                          • Organizational/management account: This is the account that you use to create the organization in AWS. Organizational accounts create and contain member accounts.

                                                                                            At this time, only threat detection is available for organizational/management accounts

                                                                                          • Single/member account: Each of these is a stand-alone account which can be a member of only one organization at a time.

                                                                                            At this time, threat detection, CSPM benchmarks, and image and container registry scanning are all available for single accounts.

                                                                                        About Sysdig Secure for cloud on AWS

                                                                                        On AWS, Sysdig Secure for cloud offers a range of features which can deployed together or separately from a single CloudFormation Template.

                                                                                        • Threat detection based on auditing CloudTrail events

                                                                                        • Compliance Security Posture Management (CSPM) in the form of CIS AWS Benchmark compliance evaluations

                                                                                        • Container registry scanning for ECR

                                                                                        • Image scanning for Fargate on ECS

                                                                                        Threat Detection Based on CloudTrail

                                                                                        Threat Detection leverages audit logs from AWS CloudTrail plus Falco rules to detect threats as soon as they occur and bring governance, compliance, and risk auditing for your cloud accounts.

                                                                                        A rich set of Falco rules, an AWS Best Practices default policy, and an AWS CloudTrail policy type for creating customized policies are included. These correspond to security standards and benchmarks such as: NIST 800-53, PCI DSS, SOC 2, MITRE ATT&CK®, CIS AWS, and AWS Foundational Security Best Practices

                                                                                        CSPM/Compliance with CIS AWS Benchmarks

                                                                                        A new cloud compliance standard has been added to the Sysdig compliance feature -  CIS AWS Benchmark. This assessment is based on an  open-source engine - Cloud Custodian - and is an initial release of Sysdig Cloud Security Posture Management (CSPM) engine. This first Sysdig cloud compliance standard will be followed by additional security compliance and regulatory standards for GCP, IBM Cloud and Azure.

                                                                                        The CIS AWS 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 also 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.

                                                                                        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.

                                                                                        Fargate Image Scanning on ECS

                                                                                        Fargate Image Scanning automatically scans any container image deployed on a serverless Fargate task that run on Elastic Container Service. This includes public images that live in registries other than ECR, as well as private ones for which you set the credentials.

                                                                                        An ephemeral CodeBuild pipeline is automatically created when a container is deployed on ECS Fargate to execute the inline scan.

                                                                                        Cloud Account Limits

                                                                                        Currently, the Enterprise version of Sysdig Secure for cloud can audit a maximum of 50 cloud accounts.

                                                                                        If this limit needs to be increased, please contact your account team. If you exceed the license purchased, Sysdig will not block cloud connection or stop the service and the account team will reach out to you.

                                                                                        See Also: