• 1:
• 2:
• 3:
• 4:
• 4.1:
• 4.2:
• 4.3:
• 4.4:
• 4.4.1:
• 4.4.2:
• 4.4.3:

1 -

Actionable Compliance (Preview)

Introduction

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

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

What’s New with Actionable Compliance

• Scheduled Reports vs Stream of Violations

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

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

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

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

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

• Variety of terminology changes

Typical Use Cases

Compliance/Security Team Members

Will want to:

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

DevOps Team Members

Will want to:

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

Path from Detection to Remediation

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

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

   Review the Compliance Views screen.

   

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

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

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

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

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

Enable Actionable Compliance UI

Prerequisites

• Agent upgrade

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

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

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

• Remediation integrated with Git pull requests (optional)

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

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

Usage

Navigate Compliance Overview

1. Select Posture > Actionable Compliannce | Compliance Views.

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

   

   All Results are always listed first.

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

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

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

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

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

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

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

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

Access and Filter Results

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

   

   The failed requirements are sorted by severity and importance.

2. You can filter by:

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

   

Evaluate and Remediate

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

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

Drill Down to the Control Pane

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

Here you can see:

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

Resources and their Attributes (Kubernetes)

These are the resources to which the controls are applied.

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

Filters in the Control Pane

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

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

Remediation: How Do Source Detection and Patching Work?

Source Detection

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

Patching and Pull Requests (PRs)

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

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

Review the Remediation Pane

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

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

Review Issues

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

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

Check the Patch

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

Continue Remediation - Manual

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

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

Continue Remediation - Pull Request

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

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

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

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

• Workflow Name Selector for Helm/Kustomize:

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

  

Appendix

Terminology Changes

Policies Included

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

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

Coming soon:

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

2 -

Compliance (Unified)

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

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

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

From a single page, you can now:

• Scope all types of reports

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

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

  • Fine-tune selections by compliance framework version

    

• Create/Enable/Disable reports

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

• Review all scheduled tasks and the resulting reports

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

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

    

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

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

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

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

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

Enable Unified Compliance UI

Prerequisites

• Agent version >= 12.0.4

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

• Node analyzer installed

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

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

Use Compliance Reports

Access the Compliance Module

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

Schedule New Task

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

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

   

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

3. Configure the report details:

   

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

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

Use Compliance Reports

Review a Report

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

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

   

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

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

   

Frameworks and Controls Implemented

AWS Foundational Security Best Practices v1 (FSBP) Compliance

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

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

AWS Well Architected Framework Compliance

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

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

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

FedRAMP Compliance

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

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

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

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

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

GDPR Compliance

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

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

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

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

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

HIPAA Compliance

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

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

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

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

HITRUST CSF v9.4.2 Compliance

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

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

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

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

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

ISO 27001:2013 Compliance

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

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

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

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

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

NIST 800-53 rev4 and rev5 Compliance

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

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

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

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

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

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

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

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

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

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

NIST 800-82 rev2 Compliance

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

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

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

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

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

NIST 800-171 rev2 Compliance

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

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

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

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

NIST 800-190 Compliance

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

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

PCI DSS v3.2.1

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

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

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

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

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

SOC2

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

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

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

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

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

3 -

Compliance (Legacy)

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

• PCI/DSS 3.2.1

• SOC2

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

• ISO 27001:2013

• HIPAA

• GDPR

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

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

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

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

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

Use Compliance Reports

Access the Compliance Module

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

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

Review a Report

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

Compliance Report Summary

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

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

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

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

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

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

Control Report and Common Fixes

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

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

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

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

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

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

Control Details

PCI Controls Implemented

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

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

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

SOC2 Controls Implemented

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

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

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

NIST 800-53 rev4 and rev5 Controls Implemented

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

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

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

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

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

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

NIST 800-171 rev2 Compliance

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

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

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

ISO 27001:2013 Controls Implemented

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

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

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

HIPAA Controls Implemented

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

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

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

GDPA Controls Implemented

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

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

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

AWS Well Architected Framework Compliance

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

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

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

AWS Foundational Security Best Practices v1 (FSBP) Compliance

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

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

4 -

Benchmarks (Legacy)

Navigate the Benchmark Tasks Landing Page

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

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

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

For users who had Benchmark v1 tasks configured:

• v1 tasks will be migrated to v2.

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

On this page you can:

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

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

• Click a task to access the full benchmark report

Benchmark Components details

Types of Benchmark Schemas

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

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

Understanding Benchmark Scopes

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

4.1 -

Configure Benchmark Tasks

Use a Benchmark Task to define:

• the type of benchmark test to be run

• the scope of the environment to be checked

• the scheduled test frequency

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

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

Create a Task

1. Select Compliance > Benchmark|Tasks.

   The Task benchmark landing page is displayed.

   

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

   

   • Name: Create a meaningful name.

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

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

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

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

3. Click Save.

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

Trigger a Task Manually

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

1. Select Compliance > Benchmark|Tasks.

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

   

   A notification will state that the test was successfully run.

4.2 -

AWS Foundations Benchmarks

Overview

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

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

Enable CIS AWS Foundations Benchmarks

Prerequisites

• Sysdig Secure (SaaS)

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

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

Using AWS Foundations Benchmarks

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

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

• Tasks and Reports combined:

  There is a single page displaying:

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

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

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

Reviewing an AWS CIS Report

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

   

2. Select the relevant report:

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

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

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

3. Review the daily report (right panel).

   Note the following:

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

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

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

4.3 -

Review Benchmark Results

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

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

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

   A benchmark report is displayed.

   

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

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

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

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

3. Drill down to review details and remediate.

   

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

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

4.4 -

Benchmarks (v1)

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

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

• CIS Docker 1.2

• CIS Kubernetes 1.3/1.4/1.5

• CIS Distribution Independent Linux 1.1.0

• Redhat Container Security Guide 3.10/3.11

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

• Docker Benchmark: for CIS Docker

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

• Linux Benchmark: for CIS Distribution Independent Linux

How Sysdig Benchmark Tests Work

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

Setting Up a Task

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

Running a Test

Once a task is configured, Sysdig Secure will:

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

• Store the results of this task

Reviewing Report Results

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

Reviewing Benchmark Metrics

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

Understanding Report Filters

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

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

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

• Choose Custom Selection

• Choose a Benchmark version and

  • apply a Profile filter, and/or

  • select/deselect individual controls.

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

About Custom Selections

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

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

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

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

About Benchmark Versions

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

Kubernetes Version Mapping

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

Sysdig also supports Kubernetes benchmark tests for the following distributions:

• IBM IKS: IBM Kubernetes Service

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

• Rancher RKE: Rancher Kubernetes Engine

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

Linux Bench Versions

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

Docker Version Mapping

About Profile Levels

CIS defines two levels of tests, as described below.

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

From the CIS FAQ:

• Level 1 Profile: Limited to major issues

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

• Level 2 Profile: Extensive checks, more complete

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

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

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

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

  See also: Configure Benchmark Tasks (v1) .

4.4.1 -

Configure Benchmark Tasks (v1)

Use a Benchmark Task to define:

• the type of benchmark test to be run

• the scope of the environment to be checked

• the scheduled test frequency

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

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

Schedule an Automated Benchmark Test

Create a Task

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

   The Schedule list (of existing tasks) is displayed.

   

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

   

   • Name: Create a meaningful name.

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

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

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

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

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

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

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

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

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

3. Click Save.

Filter Report Results

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

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

   The Task configuration page is displayed.

   

2. For Report, choose Custom Selection.

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

   See About Benchmark Versions for details.

4. Filter results as desired.

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

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

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

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

      See also: About Profile Levels.

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

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

5. Click Save.

Edit a Scheduled Task

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

   The list of scheduled tasks is displayed.

2. Select a task from the list and edit.

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

3. Click Save.

Delete a Scheduled Task

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

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

   

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

Trigger a Manual Benchmark Test (Run Now)

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

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

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

   

   A notification will state that the test was successfully run.

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

4.4.2 -

Review Benchmark Test Results (Legacy)

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

Using the Results List

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

From this page you can:

• Access Reports

• Create/access Tasks from the Schedule icon

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

• Link to Dashboards and their associated metrics in Sysdig Monitor

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

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

Using the Results Report

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

You can:

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

• Check remediation suggestions on Warn/Fail results

• Download the report as a CSV file if needed

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

Check Remediation Tips

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

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

Remediation information is included in downloaded CSV reports as well.

Download Report as a CSV File

From a Report page, click Download CSV.

4.4.3 -

Use Compliance Dashboards and Metrics (Legacy)

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

Compliance Dashboards

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

• Compliance (K8s)

• Compliance (Docker)

Sample Docker compliance dashboard:

Sample Kubernetes compliance dashboard:

Compliance Metrics

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