- 1:
- 2:
- 3:
- 4:
- 4.1:
- 4.2:
- 4.3:
- 4.4:
- 4.5:
- 4.6:
- 4.7:
- 4.8:
- 4.9:
- 4.10:
- 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.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:
- 10:
- 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
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:
These accounts must first enable Insights by logging in to Sysdig
Secure as Admin and choosing User
Profile . Toggle the
feature On in SysdigLabs:.
When Insights is not enabled, these users will see either the
Overview page (if
enabled) or the Events
feed as their default
landing page.
Usage
The Insights tool is intuitive and easy to use. Note the following
design and usage attributes.
Navigation
Choose the resources you want to view from the top-left dropdown.
Cloud User Activity: Detects vulnerabilities and events related
to user activity in connected cloud accounts. It includes User,
Account, Region, Resource Category, Resource Type, and Resource.
Cloud Activity: Detects all findings in connected cloud
accounts. Specifically, it includes Account, Region, Resource
Category, Resource Type, and Resource.
Kubernetes Activity: Detects all findings in connected
Kubernetes clusters, namespaces, and workloads. It includes Cluster,
Namespace, Pod Owner, and Workload.
Composite View: Detects and aggregates all findings from both
the Cloud Activity and the Kubernetes Activity views. It includes
Account, Region, Resource Category, Resource Type, Resource,
Cluster, Namespace, Pod Owner, and Workload.
The default view shown will be based on the findings in your
environment. If there are events in Cloud and Kubernetes, the Composite
view is default; otherwise the Cloud or Kubernetes Activity view is
chosen.
If a particular type of resource is not connected in your environment,
that page will show no findings.
Timeline
As with many other Sysdig tools, you scope by timespan using the
timeline at the bottom of the page.
The default span is 14 days. You can choose other presets
(3H, 12H, 1D, 3D, etc.) or set a span using the clickable
calendar.
Insights display up to 14 days or 999 events, whichever comes first.
Visualization Panel
The power of the Insights tool resides in the Visualization panel.
Experiment with the Visualization panel features:
Concentric rings drill down the resources to the most granular
findings. Note that the header labels each level in order
(Account > Region > Resource Category > ...)
Hover over a target area for details, and click to isolate in the
summary.
Change the
Timeline.
Take advantage of Search | Show | Hide |
Exclude.
Activity Panel: Summary
The Summary panel recapitulates the Visualization panel as an ordered
list, organized by Severity level and impacted Rule Name.
Click a line item to open the details. See at a glance the
affected containers, images, rules, user names, etc.
Take advantage of Search | Show | Hide |
Exclude.
Cloud Activity Summary Panel
For AWS Cloud Activity, the summary also includes a link back to view
the data in the AWS Console.
Activity Panel: Events
The Events panel replicates the Sysdig Secure
Events feed. Click an entry
in the time-based list to open its details.
Search | Show | Hide | Exclude
The Search bar works in conjunction with options in the
Activity Summary.
Each line of the Activity Summary includes the Show (=),
Hide (!=) and Exclude 
options.
Show (=): Click Show to add that finding to the Search
bar, and to the page URL. The Visualization will be targeted
accordingly.
Hide (!=): Click Hide to filter that finding from the
Visualization, adding the filter to the Search and the URL.
Exclude : Click Exclude to refetch
the data without the excluded entry. This cuts down on noisy
repetitious results (which in some cases could cause the
999-item limit to be exceeded).
Note that Show and Hide do not trigger a re-fetch of data.
Once you have excluded an entry, the Exclude icon
is displayed in the Visualization header.
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 DetailsLast 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 DetailsLast 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 DetailsLast 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 DetailsPast 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 DetailsLast 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 DetailsAverage 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:
Vulnerability Databases Used
Sysdig Secure continuously checks against a wide range of vulnerability
databases, updating the Runtime scan results with any newly detected
CVEs.
The current database list includes:
Use Cases
As an organization, you define what is an acceptable, secure, reliable
image running in your environment. Image scanning for the development
pipeline follows a somewhat different flow than for security personnel.
Scanning During Container Development (DevOps)
Use image scanning as part of your development
pipeline, to check for best
practices, vulnerabilities, and sensitive content.
To begin:
Add Registry: Add a registry where your images are stored, along
with the credentials necessary to access them.
Integrate CI Tool: Integrate image scanning with an external CI
tool, using the Jenkins plugin or building your own integration from
a SysdigLabs solution.
Scan Image(s): The plugin or CLI integration triggers the image
scanning process. Failed builds will be stopped, if so configured.
Review Results (in CI tool): Developers can analyze the results
in the integrated CI tool (Jenkins).
(Optionally: add policies or refine the default policies to suit
your needs, assign policies to particular images or tags, and
configure alerts and notifications.)
Scanning Running Containers (Security Personnel)
Security personnel uses image scanning to monitor which containers are
running, what their scan status is, and whether new vulnerabilities are
present in their images.
Add Registry: Add a registry where your images are stored, along
with the credentials necessary to access them.
Scan Image(s): Trigger an image scan with the node image
analyzer or manually (one-by-one).
Review Results (in Sysdig Secure): Security personnel can
analyze scan results in the Sysdig Secure image scanning UI.
(Optionally: add policies or refine the default policies to suit
your needs, assign policies to particular images or tags, and
configure alerts and notifications.)
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 -
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
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
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
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.
It is now possible to scan the image contents for malware as part of the
inline scanning process.
Note two important details to consider:
Malware scanning is resource intensive. Enable this mode for the
required set of images only, i.e. images coming from an
untrustworthy source.
Malware contents in the image are not communicated back to the
Sysdig backend. The default behavior if malware is found is to
consider the scan failed, report malware details, and abort
analysis.
Malware Scanning Flags
--malware-scan-enable: Enable malware detection as part of the
inline scanner analysis process. Mounting an external malware
database (Using ClamAV format) is highly recommended. If no existing
malware database is detected, the analyzer will try to download one
on the spot, which means the download time will be added to the
analysis process and that it will require network connectivity to
pull this database from the Internet.
--malware-scan-db-path <PATH>: Local container path with updated
ClamAV database. Will be used to call clamscan command as
clamscan --database=<PATH>
--malware-fail-fast true|false: Fail fast is true by default,
meaning that, on malware found, the image contents will not be sent
to the Sysdig backend for further policy evaluation. If you want to
send the image contents to the Backend, even on malware detected,
set this parameter to false.
About this flag, note:
If no malware is detected, the image contents will be sent to
the backend and follow the regular evaluation.
If malware is detected, the container will exit with error
code 1.
--malware-scan-output <DIR-PATH>: Save JSON output of scan to
path. Will be saved to <PATH>/malware_findings.json. Path must
exist and must be a directory; remember to mount this path from an
external directory if you want to persist the data.
--malware-exclude REGEX: It is possible to exclude image
directories to speed up the malware analysis (for example
directories that only contain signed software or sizable files).
Arguments are passed to ClamAV. For --exclude AND --exclude-dir
options, please refer to their official
documentation.
Example: Mounting External Malware Database (Recommended)
Note that /absolute/path/to/clamdb/folder (and its contained files)
must have read and execute permissions set for the current Docker
user.
Refer to ClamAV official
documentation.for
how to download and keep a local database in sync.
docker run --rm -v /absolute/path/to/clamdb/folder:/malwaredb quay.io/sysdig/secure-inline-scan:2 --sysdig-token <API_Token> --malware-scan-enable --malware-scan-db-path /malwaredb malwares/malware-example:7
Skipping send analysis to Secure backend due to Malware scan failure.
This behaviour can be tuned via --malware-fail-fast option.
Path | Signature
/data/29D6161522C7F7F21B35401907C702BDDB05ED47.bin
| Win.Trojan.Emotet-6799923-0
/data/29D6161522C7F7F21B35401907C702BDDB05ED47.bin
| Win.Trojan.Emotet-9769817-0
/data/29D6161522C7F7F21B35401907C702BDDB05ED47.bin
| Win.Trojan.Emotet-9769818-0
/data/29D6161522C7F7F21B35401907C702BDDB05ED47.bin
| Win.Trojan.Agent-1280578
/data/29D6161522C7F7F21B35401907C702BDDB05ED47.bin!(0)
| Win.Trojan.Agent-1280578
Example: Download Malware Database Inline
docker run --rm quay.io/sysdig/secure-inline-scan:2 --sysdig-token <API_Token> --malware-scan-enable malwares/malware-example:7
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.
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
Deploy: Deploy Sysdig Secure for cloud on
AWS and choose the
ECR Image Registry Scanning option.
Insights becomes
your default landing page in Sysdig Secure.
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
From the Image Scanning module, select Registry Credentials and
click Add Registry.
The New Registry page is displayed.
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.
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:
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
Service Principal
Username: The service principal app id
Password: The service principal password
Google Container Registry:
JSON Key
(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.
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).
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
Click Save.
Edit a Registry
From the Image Scanning module, select Registry Credentials.
Select an existing registry to open the Edit window.
Update the parameters as necessary and click Save.
The registry Type cannot be edited.
Delete a Registry
From the Image Scanning module, select Registry Credentials.
Select the existing registry to open the Edit window.
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:
From the Scanning module, choose the Runtime tab.
Sort by Unscanned and select an image from the list of unscanned
images.
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
From the Scanning module, choose the Image Results tab.
Click Scan Image.
Define the path to the image, and click Scan.
4.4 -
Manage Scanning Policies
Image scanning policies define several scenarios, such as:
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.
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.
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:
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
From the Image Scanning module, select Scanning Policies and
click Add Policy(+).
The New Policy page is displayed.
Define a Name and an optional Description for the new policy.
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.
Optional: Repeat step 5 to add rules as necessary.
Click Save.
Edit a Policy
From the Image Scanning module, select Scanning Policies.
Select the desired policy from the list.
Edit the policy rules as required, and click Save Policy.
Delete a Policy
From the Image Scanning module, select Scanning Policies.
Select the desired policy from the list.
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
From the Image Scanning module, select Scanning Policies and
choose +Policy Assignments.
The previously defined assignments are listed in priority order.
Click +Add Policy Assignment.
A new entry line appears at the top of the Assignment page. Enter
the desired assignment details:
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.
**Registry:**Any registry domain (e.g. quay.io). Wildcards
are supported; an asterisk * specifies any registry.
**Repository:**Any repository (typically = name of the image).
Wildcards are supported; an asterisk * specifies any
repository.
Tag: Any tag. Wildcards are supported; an asterisk *
specifies any tag.
Assigned Policy: Name of policy to use for evaluation.
Select from the drop-down menu.
Click Save.
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:
Select Image Scanning > Vulnerability Exceptions and click the
Add button on the left side of the screen.
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.
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
SelectImage Scanning > Vulnerability Exceptions and choose the
desired list from the left menu. (In this example, the Exception
list is named “Python exceptions”.)
Click the Add button on the right side of the screen.
Enter the identifying details:
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:
Select Image Scanning > Scan Results.
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.
Click the hover button to open the “Add Exception” dialog .
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:
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:
From the Image Scanning module, select either
Global - Trusted Images or Global - Untrusted Images.
The list of previously added images is displayed.
Click the Add Image button.
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:
From the Image Scanning module, choose the Scan Results tab.
Select the relevant repository from the list and open the relevant
image.
Click Add to List at the top of the page.
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.
effective_user
This trigger reviews whether the effective user matches the user
provided, and will fire based on the configured type.
| Parameter | Description | Example |
|---|
type | Determines whether the user should be whitelisted or blacklisted. | N/A |
user | The 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.
| Parameter | Description | Example |
|---|
actual_dockerfile_only | Defines whether the evaluation should skip inferred or guessed Dockerfiles, and only evaluate user-provided Dockerfiles. The default value is false. | true |
ports | A comma-separated list of port numbers. | 80,8080,8088 |
type | Defines 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.
| Parameter | Description | Example |
|---|
actual_dockerfile_only | Defines whether the evaluation should skip inferred or guessed dockerfiles, and only evaluate user-provided dockerfiles. The default value is false. | true |
check | The type of check to perform. | = |
instruction | The dockerfile instruction to check. | FROM |
value | The 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.
| Parameter | Description | Example |
|---|
regex_name | The 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.
| Parameter | Description | Example |
|---|
regex | The 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.
| Parameter | Description | Example |
|---|
licenses | A 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.
| Parameter | Description | Example |
|---|
licenses | A comma-separated list of strings to blacklist for licenses. | LGPL,BSD |
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.
| Parameter | Description | Example |
|---|
attribute | The attribute name to check. | size |
check | The operation to perform for the evaluation. | > |
value | The 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.
| Parameter | Description | Example |
|---|
name | The name of blacklisted package/s. | openssh-server |
version | The 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.
| Parameter | Description | Example |
|---|
name | The name of the required package. | libssl |
version | The required package version. | 1.10.3rc3 |
version_match_type | Defines 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.
| Parameter | Description | Example |
|---|
check | Defines whether the check should focus on missing packages, changed packages, or all. | changed |
only_directories | Defines the list of directories the check should be limited to. | /usr,/var/lib |
only_packages | Defines 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.
| Parameter | Description | Example |
|---|
entry | The 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.
| Parameter | Description | Example |
|---|
group_ids | A 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.
| Parameter | Description | Example |
|---|
shells | The 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.
| Parameter | Description | Example |
|---|
user_ids | The 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.
| Parameter | Description | Example |
|---|
user_names | A 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.
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:
| Parameter | Description | Example |
|---|
fix_available | If present, the fix availability for the vulnerability record must match the value of the parameter. | true |
package_type | The specific type of package. | all |
severity | The vulnerability severity. | high |
severity_comparison | The type of comparison to perform for the security evaluation. | > |
vendor_only | If 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.
| Parameter | Description | Example |
|---|
max_days_since_sync | Determines 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:
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=
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.
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"
}
]
}
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"
}
]
}
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"
}
]
}
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
To create a new alert: From the Image Scanning module, choose the
Alerts tab and click Add Alert.
Select either Runtime or Repository alert type.
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
From the Image Scanning module, choose the Alerts tab.
Select the desired alert from the list.
Edit the alert trigger, scope, and notification channels as
necessary, and click Save.
Duplicate an Alert
From the Image Scanning module, choose the Alerts tab.
Select the desired alert from the list.
Click the More (three dots) icon and click Duplicate Alert from
the drop-down, then Yes to confirm.
Delete an Alert
From the Image Scanning module, choose the Alerts tab.
Select the desired alert from the list.
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:
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.
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 Severity | Red Hat Severity | Red Hat Definition |
|---|
| Critical | Critical | This 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. |
| High | Important | This 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. |
| Medium | Moderate | This 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. |
| Low | Low | This 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. |
| Negligible | n/a | n/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.
Select an image from a line in the Scan Results list.
From the Compare To drop-down, select another version of this
image with which to compare.
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:
Create Report Definition
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.)
From the Reports list page, click Add Report.
Define the Report Configuration and Data as described below.
Optionally, Preview the selected Data.
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:
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:
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:
Access Host Scanning
Follow the steps for the Node Analyzer: Multi-Feature
Installation.
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.
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.
Select Scanning > Hosts.
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:
Navigate to the Settings menu in the Sysdig Secure UI.
Select Feeds Status.
4.10 -
Admission Controller
Understanding the Admission Controller
Kubernetes' admission controllers help you define and customize which
requests are allowed on your cluster. An admission controller intercepts
and processes requests to the Kubernetes API prior to persistence of the
object, but after the request is authenticated and authorized.
Image Scanning Capabilities: Sysdig’s Admission Controller
(UI-based) builds upon Kubernetes and enhances the capacity of the image
scanner to check images for Common Vulnerabilities and Exposures (CVEs),
misconfigurations, outdated images, etc., elevating the scan policies
from detection to actual prevention. Container images that do not
fulfill the configured admission policies will be rejected from the
cluster before being assigned to a node and allowed to run.
Kubernetes Audit Logging Capabilities (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.
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.
Click +Policy and enter a meaningful Name and Description.
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).
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
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.
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.
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.
Click Save.
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:
Log in as Administrator to Sysdig Secure and select
Image Scanning> Admission Controller|Policy Assignment.
Select the relevant cluster from the left side menu.
Slide the Admission Controller to Enabled.
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
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
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
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
Pull the Scanning Inspector component for Windows or Linux:
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.
| Flag | Description | Required | Argument | Type |
|---|
-f string | output format | yes | pdf or json | Vuln scan |
-i or -image_identifier string | identifier of the image | yes | [my_image:my_tag] | Vuln scan |
-image_type string | image type | yes | tar, daemon, pull | Vuln scan |
-o string or -output string | output file path | yes | | Vuln scan |
-output_format string | output format | yes | pdf or json | Vuln scan |
-fix_available | policy check for fix | no | | Policy creation |
-min_days_fix int | Minimum number of days once a fix for the specific vulnerability is available | no | default -1 | Policy Creation |
-min_severity string | Minimum severity to fail for policy evaluation | no | | Policy creation |
t-string | The image type | yes | tar, 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:
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
Sysdig Secure admin: Enable the feature under
Settings > Sysdig Labs.
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.
Navigate the Benchmark Tasks Landing Page
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:
Understanding Benchmark Scopes
When you Configure Benchmark Tasks
, the available scope
depends on the schema you choose.
| Scope Label | Description | Source | Applicable Schemas |
|---|
host.hostName | The local hostname of the machine running the benchmark container. | Retrieved from the machine running the benchmark container. | All |
host.mac | The MAC address of the machine running the benchmark container. | Retrieved from the machine running the benchmark container. | All |
aws.accountId | The AWS account ID containing the EC2 instance running the benchmark container. | Retrieved from the AWS EC2 Instance Metadata Service | CIS Amazon Elastic Kubernetes Service (EKS) Benchmark v1.0.0 |
aws.region | The Region containing the EC2 instance running the benchmark container. | Retrieved from the AWS EC2 Instance Metadata Service | CIS Amazon Elastic Kubernetes Service (EKS) Benchmark v1.0.0 |
aws.instanceId | The AWS instance ID of the EC2 instance running the benchmark container. | Retrieved from the AWS EC2 Instance Metadata Service | CIS Amazon Elastic Kubernetes Service (EKS) Benchmark v1.0.0 |
gcp.projectId | The Project ID used to create the instance. | Retrieved from the GCP Compute Engine Metadata endpoint | CIS Google Kubernetes Engine (GKE) Benchmark v1.0.0 |
gcp.instanceId | The ID of the VM. | Retrieved from the GCP Compute Engine Metadata endpoint | CIS Google Kubernetes Engine (GKE) Benchmark v1.0.0 |
gcp.instanceZone | The Zone that the VM is running in. | Retrieved from the GCP Compute Engine Metadata endpoint | CIS Google Kubernetes Engine (GKE) Benchmark v1.0.0 |
kubernetes.cluster.name | The configured Cluster name. | Set in the sysdig-agent configmap under the key: k8s_cluster_name | All |
kubernetes.node.name | The name of the node in Kubernetes. | Supplied by Kubernetes Downwards API | All |
agent.tag.* | A set of customizable tags set in the agent configmap. Same as tags for the standard agent | Set in the sysdig-agent configmap under the key: tags | All |
5.1.1 -
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
Select Compliance > Benchmark|Tasks.
The Task benchmark landing page is displayed.
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.
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.
Select Compliance > Benchmark|Tasks.
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.
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.
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.
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.
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:
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:
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.
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 Agent | Targets |
|---|
| CIS 1.3 | Kubernetes v 1.11-1.12 | all | Master control plane, Node, Etcd, Policies |
| CIS 1.4 | Kubernetes v 1.13-1.14 | all | Master control plane, Node, Etcd, Policies |
| CIS 1.5 | Kubernetes v 1.15- | all | Master control plane, Node, Etcd, Policies |
| RH 0.7 Red Hat OpenShift hardening guide | OCP 3.10-3.11 | v9.7- | Master node |
| CIS1.6 | Kubernetes v1.16- | v10.6- | Master control plane, Node, Etcd, Policies |
| GKE 1.0 | GKE | v10.6- | Master control plane, Node, Etcd, Policies, Managed services |
| EKS 1.0 | EKS | v.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 Version | Sysdig Report Filter |
|---|
| CIS_Docker_Community_Edition_Benchmark_v1.1.0 | Docker 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 -
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
From the Benchmarks module, select the Schedule icon.
The Schedule list (of existing tasks) is displayed.
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.
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.
From the Benchmarks module, select the Schedule icon and either
select or create a Task.
The Task configuration page is displayed.
For Report, choose Custom Selection.
Choose the appropriate CIS``benchmark version from the drop-down
menu (based on the Type chosen).
See About Benchmark
Versions
for details.
Filter results as desired.
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.
Optional: Select/deselect individual controls as desired.
Optional: Select All to clear previous selections and begin
again.
Click Save.
Edit a Scheduled Task
From the Benchmarks module, select the Schedule icon.
The list of scheduled tasks is displayed.
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.
Click Save.
Delete a Scheduled Task
From the Benchmarks module, select the Schedule icon.
On the relevant task, click the More Options (three dots) icon.
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.
From the Benchmarks module, select the Schedule icon.
On the relevant task, click the Run Now (arrow) icon.
A notification will state that the test was successfully run.
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.
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
Log in to Sysdig Secure and select
Compliance > AWS Foundations Benchmark.
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.
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
Rules are categorized by tags, so you can group them by functionality,
security standard, target, or whatever schema makes sense for your
organization.
Various tags are predefined and can help you organize rules into logical
groups when creating or editing policies.
Search
Use the search boxes at the top to search by rule name or by tag.
Using Falco within Sysdig Secure
What is Falco
Falco is an open-source intrusion detection and activity monitoring
project. Designed by Sysdig, the project has been donated to the Cloud
Native Computing Foundation, where it continues to be developed and
enhanced by the community. Sysdig Secure incorporates the Falco Rules
Engine as part of its Policy and Compliance modules.
Within the context of Sysdig Secure, most users will interact with Falco
primarily through writing or customizing the rules deployed in the
policies for their environment.
Falco rules consist of a condition under which an alert should be
generated and an output string to send with the alert.
Conditions
Falco rules use the Sysdig filtering
syntax.
(Note that much of the rest of the Falco documentation describes
installing and using it as a free-standing tool, which is not
applicable to most Sysdig Secure users.)
Rule conditions are typically made up of macros and lists.
Macros are simply rule condition snippets that can be
re-used inside rules and other macros, providing a way to factor
out and name common patterns.
Lists are (surprise!) lists of items that can be included in
rules, macros, or other lists. Unlike rules/macros, they can not
be parsed as Sysdig filtering expressions.
Behind the scenes, the falco_rules.yaml file contains the raw code for
all the Falco rules in the environment, including Falco macros and
lists.
Anatomy of a Falco Rule
All Falco rules include the following base parameters:
rule name: default or user-assigned
condition: the command-line collection of fields and arguments
used to create the rule
output:
source:
description:
tags: for searching and sorting
priority
Select a rule from the Rules Library to see or edit its underlying
structure. The same structure applies when creating a new Falco rule and
adding it to the library.
|
|---|
| Existing Rule |
 |
| Create a Rule |
 |
About Falco Macros
Many of the Falco rules in the Rules Library contain Falco macros in
their condition code.
You can browse the Falco Macros list, examine a macro’s underlying code,
or create your own macro. The default Falco rule set defines a number of
macros that make it easier to start writing rules. These macros provide
shortcuts for a number of common scenarios and can be used in any
user-defined rule sets.
About Falco Lists
Default Falco lists are added to improve the user experience around
writing custom rules for the environment.
For example, the list allow.inbound.source.domains can be customized
and easily referenced within any rule.
(On-Prem Only) Upgrading Falco Rules with the Rules Installer
Sysdig Secure SaaS is always using the most up-to-date Falco rules set.
Sysdig Secure On-Prem accounts should upgrade their Falco rules set
regularly.
Understanding List-Matching Rules
List-matching rules (formerly known as “fast” rules) are used for
matching against lists of items (when matchItems=true) or matching
everything other than lists of items (when matchItems=false). They
provide for simple detections of processes, network connections, and
other operations. For example:
If this process is detected, trigger an action when this rule is in
a policy (such as send notification).
Or
If a network connection on x port is detected, trigger an action
when this rule is in a policy (such as send notification)
Unlike Falco rules, the list-matching rule types do not permit complex
rule combinations, such as “If a connection on x port from y IP
address is detected…”
The five list-matching Rule Types are described below.
Container Rules
These rules are used to notify if a specific image name is running in an
environment. The rule is evaluated when the container is started. The
items in the list are image pattern names, which have the syntax
<host.name>:<port>/<name>/<name2>:<tag>@<digest>.
Only <name2> is required; everything else is optional and inferred
building on the name.
See also: How Matching Works: Container
Example
and Create a List-Matching Rule: Container Type
Example.
File System Rules
These rules are used to notify if there is write activity to a specific
directory/file. The rule is evaluated when a file is opened. The items
in the list are path prefixes.
For example: /one/two/three would match a path /one/two/three,
/one/two/three/four, but not /one/two/three-four.
Network Rules
These rules are used to:
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:
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:
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:
Log in to Sysdig Secure and select Policies > Runtime Policies.
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.
Add the rules and the actions to be taken if the policy rules are
breached.
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:
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
From the New Policy (or Edit Policy) page, click
Import from Library.
The Import from Rules Library page is displayed.
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.
).
Click Mark for Import.
A blue Import icon
appears to the right of the selected rules and the Import Rules
button is activated.
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
Select Policies > Rules Library.
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
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.
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
Click Save.
Create a List-Matching Rule: Container Type Example
Suppose you want detect whenever someone used a specific container image
that has known problems. In this case, a Container rule would be
appropriate. (The other list-matching rule types have similar entry
fields, as appropriate to their type.)
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.
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.
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:
Select Policies>Rules Library and select a rule.
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:
Click the blue list text in the rule condition, or go to
Policies > Falco Lists and search for it by name.
The list content is displayed. Click Append.
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.
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:
if any of the following crypto-mining processes are run:
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:
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:
I want to know if any container with a non-database image is
started:
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
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.
Using Runtime Policy Tuner
Prerequisites
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.
Log in to Sysdig Secure as Admin and choose
Policies > Runtime Policy Tuning.
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.
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.
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 TunerSECURE_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.
Apply Recommended Tuning to Rules
For review: How to Use the Rules
Editor.
The Tuner detects rules that may be triggering excess alert “noise” and
proposes content relevant macros and macro conditions that would reduce
the noise.
To implement the suggestions, you can 1) copy the rule contents directly
into the left panel of the Rules Editor and edit them, or 2) find the
existing placeholder macro that was created for that rule (usual format:
user_known_<rule_name> ) and add the suggested macros and conditions
there.
Note that editing the definition of a rule directly could cause
overwrite issues when upgrading Sysdig versions. Creating custom rules
or using the user_known placeholders is a safer procedure.
For example, suppose you decide to implement the Tuner prompt 4 in the
image above, which suggests changing the configuration of the rule
Write below root. One way to proceed:
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.
Copy one placeholder to the left-hand Custom Rules panel of the
Editor: user_known_write_below_root_activities .
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
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 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:
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.
Download the container image:
# docker pull sysdig/falco_rules_installer:latest
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.
Download the container image on a machine that is connected to the
network:
# docker pull sysdig/falco_rules_installer:latest
Create an archive file for the image:
# docker save sysdig/falco_rules_installer:latest -o falco_rules_installer.tar
Transfer the tar file to the air-gapped machine.
Untar the image file:
# docker load -i file.tar
It restores both images and tags.
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:
| Variables | Description |
|---|
DEPLOY_HOSTNAME | The server that hosts the Sysdig API endpoints. The default is https://secure.sysdig.com. |
DEPLOY_USER_NAME | The 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_PASSWORD | The password for the admin user. The value defaults to a meaningless password nopassword. |
VALIDATE_RULES | If 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_RULES | If set to yes, the falco rules file is deployed. Otherwise, skip deploying the falco rules file. The value defaults to yes. |
CREATE_NEW_POLICIES | If set to yes, create new policies for any Falco rules that do not map to a policy. The value defaults is no. |
SDC_SSL_VERIFY | If 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:
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:
Contact Sysdig (SaaS) or the Sysdig administrator (On-Prem) to
enable the feature.
Allow the agents to collect information for at least 24 hours.
Review the collected profiles details, selecting those that are Done
Learning and have High Confidence.
Use the checkboxes to include details and create per-image policies.
Repeat regularly.
Review Profiles and Create Policies
Log in to Sysdig Secure and select Policies > Image Profiles.
Filter the list by Done Learning to see the actionable profiles.
Focus on those with High Confidence levels (three squares).
Select an image title to review and expand the elements in the
Details panel. Select an individual element to see the specific data
collected.
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
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
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:
Access the module under Policies > Pod Security Policies.
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.
Click Start Simulation.
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.
Check the Simulation output and tweak the PSP content if needed.
When satisfied that the PSP rules perform as desired, 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.
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
Select Policies>Pod Security Policies and click New
Simulation.
The New Simulation page is displayed.
Use the Import buttons to upload either an existing PSP Policy or a
deployment YAML file.
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.
Enter the namespace.name and/or deployment.name of the cluster
where you will run the simulated PSP, or choose “all.”
Click Save.
The PSP Simulation has been defined and will appear on the PSP list
page.
Run a Simulation and Review Output Events
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.
Deploy the PSP to the designated environment, where the Simulator
will test it.
Select the simulation while it’s running to review any generated
event output.
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.
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
To use the Network Security Policy tool, follow these basic steps:
Ensure your environment meets the
Prerequisites.
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.
Set up the scope. (Which entities
over which time periods should be analyzed?)
Review the Ingress/Egress tables and
edit the detected communications as desired.
Review everything visually in the Topography
Map.
Click Generated Policy and download the resulting file.
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.
In the Sysdig Secure UI, select Network from the left menu.
Choose Cluster and Namespace from the drop-down menus.
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.
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:
Select the scope as described above.
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.
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.
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:
To access:
Log in to Sysdig Secure as administrator.
Select Network from the left navigation.
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:
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:
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:
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.
Log in to Sysdig Secure.
Any event scope you define will be applied to the team under which
you logged in.
On the Events page, click Edit Scope.
From the drop-down menus(s), select the elements, values, and labels
needed, and click Apply.
Free-Text Search
You can search by the event title and scope label values, such as
“my-cluster-name,” visible in the events lists.
Type
Events now include both Runtime and Image Scanning events.
Runtime events correspond to the rules and violations defined in
Policies.
Image Scanning events correspond to the runtime scanning
alerts.
Severity
Use the appropriate buttons to filter events by High, Medium,
Low, and Info level of severity, corresponding to the levels
defined in the relevant runtime
Policies
or runtime scanning
alerts..
Time Span
As in the rest of the Sysdig Platform interface, the time span can be
set by date ranges using the calendar pop-up, and in increments from 10
minutes to 3 days. You can additionally use the calendar picker to
select other time ranges that are not available as fast buttons.
Attributes
Under Policies and Triggered Rules, hover over an attribute to reveal
the =/!= filter button and click to add to the Attribute filter.
Event Detail Panel
The Event Detail contents vary depending on the selected event. In
general, the following are always present:
Attributes on which you can filter directly:
See the Attributes discussion, above.
Action Buttons:
If relevant, the Captures button links to
Captures. See also:
Quick Menu to Captures from Runtime
Events.
For Runtime events, the Activity shortcut button is available
and links to Activity
Audit.
For Image Scanning, the Scan Results shortcut links to the Scan
Results page.
Edit Policy Shortcut:
For image scanning: Links to the runtime alert that generated the
event.
For policy (runtime) events: Links to the runtime rule that
created the event, as well as the rule type (i.e. Falco - Syscall)
and the labels associated with that rule.
All three elements are filterable using the attribute filter widgets
(see above).
Output (For Policy events):
The Falco rule output as configured in the rule is listed.
Scope
The new scope selector allows for additional selector logic (in, not
in, contains, starts-with, etc), improving the scoping flexibility
over previous versions. This scope selector also provides scope
variables, allowing you to quickly switch between, for example,
Kubernetes namespaces without having to edit the panel scope. See
also: Team Scope and the Event
Feed,
below.
Note that the scope details listed can be entered in the free-text
search field if desired.
Live/Pause Button -
When live, events continually update. Use Pause to focus on a
section of the screen and not continue scrolling away in a noisy
environment.
Portable URLs
The Event Feed URL maintains the current filters, scope, and
selected elements. You can share this URL with other users to allow
them to display the same data.
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:
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.
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:
From the Settings module of the Sysdig Secure UI, navigate to the
Events Forwarding tab.
Click the More Options (three dots) icon.
Click the Delete Integration button.
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.
To forward event data to Splunk:
From the Settings module of the Sysdig Secure UI, navigate to the
Events Forwarding tab.
Click the Add Integration button.
Select Splunk from the drop-down menu.
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.
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.
To forward event data to a Syslog Server:
From the Settings module of the Sysdig Secure UI, navigate to the
Events Forwarding tab.
Click the Add Integration button.
Select Syslog from the drop-down menu.
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.
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:
From the Settings module of the Sysdig Secure UI, navigate to the
Events Forwarding tab.
Click the Add Integration button.
Select IBM MCM from the drop-down menu.
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.
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:
From the Settings module of the Sysdig Secure UI, navigate to the
Events Forwarding tab.
Click the Add Integration button.
Select IBM QRadar from the drop-down menu.
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.
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.
To forward secure data to Kafka:
From the Settings module of the Sysdig Secure UI, navigate to the
Events Forwarding tab.
Click the Add Integration button.
Select Kafka topic from the drop-down menu.
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:
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.
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:
From the Settings module of the Sysdig Secure UI, navigate to the
Events Forwarding tab.
Click the Add Integration button.
Select Webhook from the drop-down menu.
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.
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:
From the Policies module, navigate to the Rules Editor tab.
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:
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:
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.)
Create a Webhook Configuration
File
and copy it to the Kubernetes API master node, in
the /etc/origin/master directory.
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)" > /etc/origin/master/master-config.yaml
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.
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.)
Create a Webhook Configuration
File
and copy it to the Minishift VM into the
directory /var/lib/minishift/base/kube-apiserver/.
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
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.
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"]}}}}'
Wait for the API server to restart with the updated configuration.
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.
Create a Webhook Configuration
File
and save it locally.
Get the current cluster configuration and save it to a file:
kops get cluster <your cluster name> -o yaml > cluster-current.yaml
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
Configure Kops with the new cluster configuration:
kops replace -f cluster.yaml
Update the cluster configuration to prepare changes to the cluster:
kops update cluster <your cluster name> --yes
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.
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
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
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:
Enable CloudWatch logs for your EKS cluster.
Allow access to CloudWatch from the worker nodes.
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:
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.
On each Kubernetes API Master Node, create the
directory /var/lib/k8s_audit.
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.)
Create a Webhook Configuration
File
and copy it to each Kubernetes API master node, into the
directory /var/lib/k8s_audit.
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.
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.
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
Verify that the webhook backend URL has been set:
ibmcloud ks cluster master audit-webhook get --cluster <cluster_name_or_ID>
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.
Create the directory /var/lib/k8s_audit on the master node. (On
Minikube, it must be on the Minikube VM.)
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.
Create a Webhook Configuration
File
and copy it to each Kubernetes API master node, into the
directory /var/lib/k8s_audit.
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
...
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
...
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.
Download webhook-config.yaml.in.
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.
Download audit-sink.yaml.in .
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
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
Deploy:Deploy Sysdig Secure for cloud on
AWS and choose the
Threat Detection with CloudTrail option.
Insights becomes
your default landing page in Sysdig Secure.
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:
Navigate the Audit Interface
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.
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.
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
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.
Time | The date and time of the network connection |
Connection Direction | Incoming or outgoing connection |
Connection Details | Including: |
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
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 |
Host | Host name and MAC address of the host where the kubectl exec was made |
File Activity Details
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?
Use the Activity Audit button next to the policy event to jump
directly to the relevant audit trail.
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
Refine the view through filtering:
Switch from network data source to cmd and kube exe.
Filter out noisy, repetitive entries (e.g. comm!="bash")
Investigate details of a kube exec item for user information.
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.
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).
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.
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:
| Data | Description |
|---|
| Time | The date and time the command was executed. |
| Shell | The terminal shell the command was executed in. |
| Command Line | The full command executed, including flags/variables. |
| Scope | The 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:
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:
From the Commands Audit module, select a command from the table to
open the Command Details window.
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.
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:
From the Captures module, click the Take Capture button to open
the capture creation window.
Define the name of the capture.
Configure the host and container the capture file should record
system calls from.
Define the duration of the capture. The maximum length is 300
seconds (five minutes).
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
From the Captures module, select the capture file(s) to be
deleted.
Click the Delete (trash can) icon:
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:
From the Captures module, select the capture file to be deleted.
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:
From the Captures module, select the target capture file.
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.
Create a team or teams, as described
here
Add
users,
assigning them the Advanced User
role.
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:
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.
Log in the Sysdig Secure UI as a Rapid Response team member.
Select Investigate > Rapid Response | Start Session.
Select the host as prompted and click Start Session.
Enter your password.
Enter the 2FA code that was emailed to your user address and click
Confirm.
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
Log in the Sysdig Secure UI as a Rapid Response team member.
Select Events and choose an event from the list to open the detail
pane. Click Respond: Launch Rapid Response.
Enter the 2FA code that was emailed to your user address and click
Confirm.
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.
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.
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
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:
