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

Return to the regular view of this page.

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

                    Compliance

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

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

                    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

                    Actionable Compliance and Unified Compliance can be run in parallel. When the benchmarks have reached End of Life (EOL), the data collection will be only on Actionable Compliance and the Legacy Reports will be available on the interface for a period of a year from creation date.

                    Note that there is no plan to transfer data between compliance versions.

                    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

                    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

                    Previous TermNew Term
                    Framework, BenchmarkPolicy
                    The policy is a group of business/security/compliance/operations requirements that can represent a compliance standard (e.g. PCI 3.2.1), a benchmark (e.g. CIS Kubernetes 1.5.1), or a business policy (e.g. ACME corp policy v1).

                    Note that for the Tech Preview release, there is no direct access to the various policies. In future, they will be available under the Policies module in Sysdig Secure.
                    ControlRequirement (or Policy Requirement)
                    A requirement exists in a single policy and is an integral part of the policy. The requirement represents a section in a policy with which compliance officers & auditors are familiar with and and know requires compliance.
                    FamilyRequirements Group
                    Groupings of requirements in a policy
                    RuleControl
                    A control defines the way we identify the issue (check) and the playbook(s) to remediate the violation detected by the check.
                    Vulnerability ExceptionRisk Acceptance
                    The new module now includes the ability for a user to review a violation or vulnerability, not yet remediate it, and acknowledge it without making it fail the policy.

                    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

                    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

                    4 -

                    Benchmarks (Legacy)

                    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:

                    Schema Name

                    Applicability

                    Notes

                    CIS Kubernetes Benchmark v1.5.1

                    Kubernetes versions 1.15 and below

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

                    CIS Kubernetes Benchmark v1.6.0

                    Kubernetes versions 1.16 and below

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

                    CIS Google Kubernetes Engine (GKE) Benchmark v1.0.0

                     

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

                     

                    OpenShift 3.11 Hardening Guide v1.2.1

                    OpenShift versions 3.10 and 3.11 are supported.

                     

                    CIS RedHat OpenShift Container Platform v4 Benchmark v1.1.0

                    OpenShift Container Platform v4

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

                    CIS Distribution Independent Linux Benchmark v1.1.0

                    Docker Security Benchmark v1.2.0

                    With Secure for cloud:

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

                    CIS Amazon Web Services Foundations Compliance Benchmark v1.3.0

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

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

                    Understanding Benchmark Scopes

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

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

                    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.

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

                    Trigger a Task Manually

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

                    1. Select Compliance > Benchmark|Tasks.

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

                      A notification will state that the test was successfully run.

                    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)

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

                    Version Rules

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

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

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

                    Kubernetes Version Mapping

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

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

                    Sysdig also supports Kubernetes benchmark tests for the following distributions:

                    • IBM IKS: IBM Kubernetes Service

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

                    • Rancher RKE: Rancher Kubernetes Engine

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

                    Linux Bench Versions

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

                    Docker Version Mapping

                    CIS Benchmark VersionSysdig Report Filter
                    CIS_Docker_Community_Edition_Benchmark_v1.1.0Docker 1.0

                    About Profile Levels

                    CIS defines two levels of tests, as described below.

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

                    From the CIS FAQ:

                    • Level 1 Profile: Limited to major issues

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

                    • Level 2 Profile: Extensive checks, more complete

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

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

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

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

                      See also: Configure Benchmark Tasks (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.

                    One Task, One Test, One Environment

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

                    Filter Report Results

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

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

                      The Task configuration page is displayed.

                    2. For Report, choose Custom Selection.

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

                      See About Benchmark Versions for details.

                    4. Filter results as desired.

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

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

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

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

                        See also: About Profile Levels.

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

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

                    5. Click Save.

                    Edit a Scheduled Task

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

                      The list of scheduled tasks is displayed.

                    2. Select a task from the list and edit.

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

                    3. Click Save.

                    Delete a Scheduled Task

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

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

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

                    Trigger a Manual Benchmark Test (Run Now)

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

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

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

                      A notification will state that the test was successfully run.

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

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

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

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

                    Check Remediation Tips

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

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

                    Remediation information is included in downloaded CSV reports as well.

                    Download Report as a CSV File

                    From a Report page, click Download CSV.

                    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.