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

Return to the regular view of this page.

  • 1:
    • 1.1:
      • 1.2:
        • 1.3:
          • 1.4:
            • 1.4.1:
              • 1.4.2:
                • 1.4.3:
                  • 1.4.4:
                    • 1.4.4.1:
                      • 1.4.4.2:
                        • 1.4.4.3:
                    • 2:

                      Posture

                      Sysdig is introducing enhanced security capabilities with a new Cloud Infrastructure Entitlements Management (CIEM) module. This feature allows organizations easily to identify areas in their cloud infrastructure with overly permissive access rights which could cause data breaches or other risks, and to quickly and easily update the related policies and user permissions as needed.

                      Along with this capacity, the compliance standards and benchmark checks have all been moved under the umbrella module, Posture.

                      Understand Each Component

                      You can jump directly to each of the three related areas:

                      1 -

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

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

                      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

                      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

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

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

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

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

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

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

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

                      2 -

                      Identity and Access

                      As cloud services proliferate, so do user access policies, and a majority of enterprises use overly permissive policies that create large attack surfaces and significant security risks. With Sysdig’s Identity and Access module (I&A) for cloud accounts, you can review and mitigate these risks in minutes.

                      Understanding Identity and Access

                      In Sysdig Secure for cloud, Identity and Access work together with Compliance and Benchmark tools under the Posture navigation tab in the Sysdig Secure menu.

                      Analysis: From this interface you can quickly acertain risks from two different angles:

                      User-Focused Risks

                      • Users and roles with excessive permissions
                      • Inactive users that can be removed
                      • Unnecessary permissions

                      Resource-focused Risks

                      • Who can access a resource
                      • Any suspicious cloud resource activity from a user with excessive permissions
                      • Recent permissions changes

                      Remediation: From there, the tool can suggest an improved policy, based on users’ actual activity, which you can immediately paste into your AWS policy in the linked AWS console.

                      Understanding the Suggested Policy Changes

                      When you find a user or a policy with excessive permissions, there are two suggested types of remediations:

                      • Global Policy Change: In this case, you click a targeted policy (e.g. AdministratorAccess) from either:

                        • The policy link on a user’s panel, or
                        • The Optimize Policy button on a policy panel

                        A revised policy is suggested based on the activities of all users in the system that have been granted this entitlement.

                        You would copy the suggested code into your existing policy in the AWS console.

                      • User-Specific Policy: In this case, when investigating an individual user entry, you click Generate User-Specific Policy and a policy is suggested based on a combination of all policies and activities detected for that user.

                        You would copy the suggested code into a new user policy in your AWS console.

                      Understanding the Wildcard Warnings

                      The Policies list page flags policies that include wildcards for Action or Resource. By default, all recommended or optimized policies from Sysdig will remove the Action wildcards.

                      Because Sysdig cannot detect the Resources deployed, it cannot automatically remediate Resource wildcards in policy code.

                      Understanding Learning Mode and Disconnected States

                      Sysdig’s IAM page shows helpful information about cloud accounts and indicates several states for each registered account:

                      • Learning Mode: A cloud account is in learning mode when the account was connected less than 90 days prior. This ensures that the user activity has been profiled for a meaningful amount of time.

                      • Disconnected: A cloud account is in disconnected state if either of these events occur:

                        • Cloud-Connector stops sending events. The timestamp shows the time the last events were received
                        • The role provisioned on the customer’s AWS account cannot be impersonated

                      Prerequisites

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

                      Limitations

                      • Currently only the identity-based policies (managed, inline, and group policies) are considered for permission calculation. Resource-based, permission boundaries, organization SCPs, ACLs, and Session policies are not yet accounted for during permission calculations.

                        More details on these policies here.

                      • Two notes about the data displayed:

                        • AWS Last seen timeis based on GetServiceLastAccessedDetails. For more information, see Amazon’s documentation.
                        • The AWS permissions used by IAM identities is based on user activity observed in Cloudtrail logs. Currently, permissions used after assuming roles is not taken into account.

                      Access the Overview

                      1. Log in to Sysdig Secure.
                      2. Select Posture >Identity and Access|Overview.
                      3. Review the global Permissions posture from the various panels and use the filtered links to access the Users and Policies subpages as needed.

                      Filter by Account

                      On each page in the I&A section, all users and resources are listed by default. If desired, you can focus on a single cloud account, using the Accounts drop-down at the top of the page.

                      Review Unused Permissions

                      Total Permissions Usage

                      See at a glance the number of permissions that have been granted vs those that have actually been used. Click on the Used and Given links to see the related Policies list and remediate those with the highest number of unused permissions.

                      Users

                      See at a glance the number of active vs inactive users. Clicked on the Active and Inactive links to see the related Users and Roles lists and to remediate.

                      Average Permissions Per Policy

                      See at a glance the average number of permissions granted per policy. per account, and click into the Policies list to remediate.

                      Average Policies Per User

                      See at a glance the average number of policies a user is associated with, per account and click into the Users and Roles list to remediate.

                      Policies with Unused Permissions

                      The Inventory section orders the Policies, Users, and Roles with the greatest number of unused permissions at the top of the list. Click to expand the lists and remediate.

                      Users and Roles with Unused Permissions

                      The Inventory section orders the Policies, Users, and Roles with the greatest number of unused permissions at the top of the list. Click to expand the lists and remediate.

                      Users and Roles

                      The Identity and Access| Users and Roles page provides numerous ways to sort, filter, and rank the detected user and role information and to quickly remediate permissions in policies.

                      Filter and Sort

                      Available filters:

                      • By account, by just users, by just roles
                      • By unused permissions vs inactive users and roles

                      Each column in the table can be sorted to help target, for example, the users with the highest number of granted permissions or the highest percentage of unused permissions.

                      Analyze and Remediate

                      To reduce the entitlements for a particular user or role:

                      1. Click on a user or role to open the detail pane.

                        In the screenshot example above, the user has actually triggered only 1 of the 10,471 permissions issued, and is associated with five different policies. Full AdministratorAccess has not been needed for the job the user has been performing.

                      2. Decide whether to Generate a User-Specific policy that takes into account all the policies and permissions this users has employed, or whether to use the Suggested Policy for e.g., AdministratorAccess, globally. See: Understanding the Suggested Policy Changes.

                      3. Copy the generated policy and paste it into a policy in your AWS console.

                      Policies

                      The Identity and Access| Policies page currently displays AWS policies only. Other cloud vendors will be added over time.

                      Filter and Sort

                      As with the Users and Roles page, you can filter by account, and each column in the table is sortable.

                      The most common sorting priorities are:

                      • By Unused % or Unused Permissions: Immediately target the policies with the greatest exposure and refine them according to the suggestions

                      • By Shared Policy (# of Users): Focus on the policies affecting the greatest number of users and make a global policy change

                      • By Wildcard warning: The Policies list specifically calls out the security risks posed by policies containing Resource or Action Wildcards. The suggested policies eliminate Action wildcards.

                        See also: Understanding the Wildcard Warnings.

                      Analyze and Remediate

                      To reduce the entitlements globally for a particular policy:

                      1. Click on a policy name to open the detail pane.

                      2. Click Optimize Policy and review the proposed code.

                      3. You can copy (then paste), download (then upload), or open the adjusted policy directly in the AWS console and save.

                      Posture Resources

                      The Resources page will be further developed in future releases.

                      At this time, you can use the S3 Bucket information to see all the S3 buckets currently set to Public and switch them to Private in the AWS console as needed. Similarly, the Lambdas are displayed with their public/private setttings.

                      Download CSV

                      Each page of the Identity and Access module has a Download CSV button for retrieving the page data in a spreadsheet.

                      Note: If your Chrome browser is set to disallow downloading multiple files from a site, you may only get one CSV download and then a “blocked” message in the Chrome address bar. You can click the message to access and change that browser setting, if desired.