Compliance

Introduction

Sysdig’s Compliance feature continues to evolve and the new Compliance module represents the next phase of maturity, as well as the first to support CSPM/KSPM. The Compliance module now relies on persisting the resources in an inventory; this enhanced resource visibility and full-context prioritization drives remediation and resolution of violations.

  • Compliance IBM Cloud and On-Prem Users, please see Legacy Compliance
  • Compliance is not available for Managed Falco (secure light).

What’s New with Compliance

  • Compliance that is Actionable

    • The new CSPM Compliance lets you manage your risks:
      • Remediate
      • Accept the risk
      • Open a Pull Request in your code repository - if Git IaC integration is enabled
      • Coming Soon: open a JIRA ticket for remediation
  • A Stream of Violations

    • The resources of your Zones are evaluated against compliance policies; the violations are collected into tiles in an ongoing stream and shown on the Compliance page.

    • The new approach relies on the common process of fetching the resources once per day into the backend and performing the relevant analysis of policies.

    • You can create custom policies or use Sysdig out-of-the-box policies.

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

  • Variety of terminology changes

  • Downloadable reports and the APIs to support reporting

For Legacy Compliance Users:

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

There is no plan to transfer data between compliance versions.

See also: Appendix B

Typical Use Cases

Compliance/Security Team Members

Will want to:

  • Check current compliance status of their business zones against predefined policies
  • Demonstrate to an auditor the compliance status of their business zone in a specific point in time (the audit)
  • Create a report of the compliance status of their business zone, share it with their auditors and the management team
  • Understand the magnitude of the compliance gap

DevOps Team Members

Will want to:

  • Identify the compliance violations of a predefined policy applied on their business zones
  • Manage the violations according to their severity
  • Easily fix the violation
  • Document exceptions and accept risk according to the risk management policy of their organization

Path from Detection to Remediation

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

  1. Compliance Page: Get high-level posture performance indicators (PPIs) on each of the policies applied applied on your zones:

    Your zones are ordered alphabetically. The results under each zone are ordered by the passing score, lowest first, to help you focus on improving your scores.

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

  3. Start Remediation to open 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 your Git repository).

    • Manually, you can copy the patch code and apply it in production.
    • To remediate in the code repository, you can choose the relevant Git source and 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.
  5. You can Accept the Risk (temporarily or forever) and remove the violation from the failed controls.

  6. Download a report as a CSV/spreadsheet of your compliance results for development teams, executives or auditors (optional).

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

Installation

To connect new cloud accounts or Kubernetes clusters to Sysdig Secure, please follow our installation guide, where --set global.kspm.deploy=true \.

For existing connected data sources, please follow the migration guide.

Usage

CSPM Zones Management

On the Compliance landing page, a default Entire Infrasture zone is automatically created. CIS policies and the Sysdig Kubernetes policy are automatically added to the Entire Infrastructure zone.

To see results from any of the other 40+ out-of-the-box policies provided with the Compliance module, or for any custom policies, you must apply them to a zone.

  1. Select Posture > Compliance .

  2. Review the compliance posture for each of your zones. Each row or tile shows your compliance results of a policy that is applied on your zone.

    The zones are ordered alphabetically. The default Entire Infrastructure zone was created by Sysdig and some policies are applied to it. You can customize the Entire Infrastructure zone , along with your own zones, in the Zones management page.

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

    • Zones / Policies: This is the lens to evaluate your compliance results through your zones and the policies you applied to them.

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

Review and Filter Results

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

    The failed requirements are sorted by severity and importance.

  2. You can edit the filters to focus on the compliance results that are relevant for you.The Compliance results page presents the policy requirements for the selected zones and policies, and the controls under each requirement.

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 and review the resources that were evaluated by the control.

Here you can see:

  • An description of the control
  • An overview of all resources that have passed, failed, or had their risks temporarily accepted
Filters in the Control Pane

The Control pane shows the top 50 results. Use filters to find additional resources.

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

For each of the following Control Types, you can refine your search in the mini-inventory using the associated attributes:

Kubernetes Identity

  • Cluster
  • Name
  • Name
  • NamespaceType (= Resource Type in Inventory) - ex: Group, ServiceAccount, User

Kubernetes Resource

  • Cluster
  • Labels
  • Name
  • Namespace
  • Type (= Resource Type in Inventory) - ex: Deployment, Daemonset, StatefulSet, ReplicaSet, Pod, Job, CronJobHost (K8s, Linux, Docker)

Host (K8s, Linux, Docker)

  • Cluster
  • Name
  • OS (= Operating System in Inventory)
  • OS Image (doesn’t exist in Inventory)

Managed Cloud Identity & Resource (AWS, GCP, Azure)

  • Account
  • Location (= Region in Inventory)
  • Name
  • Organization

Select a failing resource to review its remediation guidelines and take action towards its remediation.

Evaluate and Remediate

The remediation solutions are under continued development in the product.

Some remediation flows are manual, while others offer different degrees of automation.

Sysdig can present a patch to be manually applied to production, or it can fix the resource via creation of Pull Request with the required changes directly in the Git repository that has been previously configured as an IaC integration.

At this time, risk response actions are for a single resource for a single violation. Several types of risk responses are supported:

  • Manual Remediation: Playbook text to remediate the violation is presented
  • Automatically generate a 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 an Automatic 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.
  • Accept this Risk

Remediation: How Do Source Detection and Patching Work?

Source Detection

When applying remediation to a resource, Sysdig tries to identify the matching source file from your configured Git integrations. If there are multiple candidates or in case it is not possible to find the matching source file, you can use the search field to manually explore and select the relevant file from the connected Git repositories.

Patching and Pull Requests (PRs)

When using Pull Request for remediation, Sysdig will create a branch directly in your Git repository, patching the offending resource with corrective changes. You can review all the suggested 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 the specific control and resource evaluation.

If remediation via patch is possible, and Git integration has been set up, then the full remediation pane will be displayed. If there is more than a single possible matching file for the resource, all the candidates are displayed as “Suggested Sources”. If no candidates are displayed or you want to choose a different file, you can click the “Search Source” button to manually select from the list of possible files in the connected Git repositories.

Review Issues

Here you see 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 Git repository 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

After configuring IaC Scanning in your account, Sysdig will scan and analyze the manifests and modules from your defined Git sources, and scrape resources declared in your source files. The scan process runs daily or whenever a new Git source is added.

Sysdig tries to match and identify the resources discovered from the Git IaC Scanning with the deployed and evaluated resources.The best matches are listed under “Suggested Sources” in the Remediation pane when setting up a Pull Request.

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

Use the button to Open a Pull Request .

  • 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 used for the workloads generated from the same chart, regardless of the release.

    Note that Sysdig will create a new Pull Request in your repository with the suggested fixes, and depending on your Git source configuration, Sysdig can run a Pull Request Policy Evaluation that might report other unfixed control violations.

Option: Accept Risk

In some cases, a failing control can be safely ignored for a period of time so the resource will pass and the compliance score will improve. To do so:

  1. Click the Accept Risk button on the remediation pane.

  2. Fill out the required fields, to comply with audit best practices, and click Save.

    Reason: Risk Owned, Transferred, Avoided, Mitigated, Not Relevant, or Custom

    Details: Explain to an auditor the reason for accepting the risk, or select the risk management action taken

    **Expired In: **Select when you want this acceptance to expire and the resource to fail. 7/30/60/90 days, Custom time frame, Never

    Expiration Date: Enter for Custom time frame, otherwise autocompleted

  3. Later, you can filter violations by Accepted status to address them.

Create and Download a Report

To meet compliance goals, an organization may need to generate output to be shared with other stakeholders, such as executives or auditors, to show point-in-time compliance/violations.

Reports could also be used for sharing compliance results with your development teams. Also consider Using the CSPM APIs .

You can download ad hoc reports as CSV files from the Compliance Results page or from an individual control.

To generate a report of Compliance results:

  1. Select Posture > Compliance.

  2. Select a tile of a policy under one of your zones.

  3. Optional: filter as desired. For example: by dates, by pass/fail status, by controls, etc. You can select more than one policy for a single zone. The maximum report size of 10 MB.

  4. Click Download Report.

    A file is downloaded in a CSV (Comma-Separated-Values) format and can be used as a spreadsheet.

To generate a report from an individual control:

  1. Select Posture > Compliannce.

  2. Select a tile of a policy under one of your zones.

  3. Select a control to open the control pane, filter the resources if desired, and click the “Download Report” button.

    The maximum report size is 10 MB.

Using the CSPM API

When your organization uses a 3rd-party system to receive remediation reports and create tasks, consider using the CSPM APIs.

These are documented online along with the rest of the Sysdig Secure APIs.

Compliance Results API Call (Requirements)
  • Please specify a zone in the request. If a zone is not specified in the request, results will be returned for policies applied on the default “Entire Infrastructure” zone.
  • If no policy is applied on the default “Entire Infrastructure” zone, you will receive empty results.
  • Note that URL Links to every Control Resource List API call are contained in the Compliance Results Response.

Appendix A

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

You can review the available policies and create custom CSPM/Risk and Compliance policies under Policies
ScopesZone
A business group of resources for a specific customer, defined by a collection of Scopes of various resource types, calculated by “OR” operators
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.
FamilyRequirements Group
Group 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.
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

The following risk and compliance policies are included out-of-the-box:

  • National Institute of Standards and Technology (NIST)

    • NIST SP 800-53 Rev 5
    • NIST SP 800-53 Rev 5 Privacy Baseline
    • NIST SP 800-53 Rev 5 Low Baseline
    • NIST SP 800-53 Rev 5 Moderate Baseline
    • NIST SP 800-53 Rev 5 High Baseline
    • NIST SP 800-82 Rev 2
    • NIST SP 800-82 Rev 2 Low Baseline
    • NIST SP 800-82 Rev 2 Moderate Baseline
    • NIST SP 800-82 Rev 2 High Baseline
    • NIST SP 800-171 Rev 2
    • NIST SP 800-190
    • NIST SP 800-218 v1.
  • Federal Risk and Authorization Management Program (FedRAMP)

    • FedRAMP Rev 4 LI-SaaS Baseline
    • FedRAMP Rev 4 Low Baseline
    • FedRAMP Rev 4 Moderate Baseline
    • FedRAMP Rev 4 High Baseline
  • Defense Information Systems Administration (DISA) Security Technical Implementation Guide (STIG)

    • DISA Kubernetes Security Technical Implementation Guide (STIG) Ver 1 Rel 6
    • DISA Kubernetes Security Technical Implementation Guide (STIG) Ver 1 Rel 6 Category II (Medium)
    • DISA Kubernetes Security Technical Implementation Guide (STIG) Ver 1 Rel 6 Category I (High)
    • DISA Docker Enterprise 2.x Linux/UNIX Security Technical Implementation Guide (STIG)
    • DISA Docker Enterprise 2.x Linux/UNIX Security Technical Implementation Guide (STIG) v2 Category III (Low)
    • DISA Docker Enterprise 2.x Linux/UNIX Security Technical Implementation Guide (STIG) v2 Category II (Medium)
    • DISA Docker Enterprise 2.x Linux/UNIX Security Technical Implementation Guide (STIG) v2 Category I (High)
  • Center for Internet Security (CIS) Benchmarks

    • CIS Distribution Independent Linux Benchmark v2.0.0
    • CIS Docker Benchmark v1.3.1
    • CIS Kubernetes V1.15 Benchmark v1.5.1
    • CIS Kubernetes V1.18 Benchmark v1.6.0
    • CIS Kubernetes V1.20 Benchmark v1.0.0
    • CIS Kubernetes V1.23 Benchmark v1.0.0
    • CIS Amazon Elastic Kubernetes Service (EKS) Benchmark v1.0.1
    • CIS Google Kubernetes Engine (GKE) Benchmark v1.1.0
    • CIS Azure Kubernetes Service (AKS) Benchmark v1.1.0
    • CIS Amazon Web Services Foundations Benchmark v1.4.0
    • CIS Google Cloud Platform Foundations Benchmark v1.3.0
    • CIS Microsoft Azure Foundations Benchmark v1.4.0
  • Amazon Web Services (AWS) Best Practices

    • AWS Well Architected Framework
    • AWS Foundational Security Best Practices
  • Regulatory Compliance Standards

    • System and Organization Controls (SOC) 2
    • Health Insurance Portability and Accountability Act (HIPAA)
    • Payment Card Industry Data Security Standard (PCI DSS) v3.2.1
    • Payment Card Industry Data Security Standard (PCI DSS) v4.0
    • NSA/CISA Kubernetes Hardening Guide
    • General Data Protection Regulation (GDPR)
    • ISO/IEC 27001:2013 v2
    • Health Information Trust Common Security Framework (HITRUST CSF) v9.4.2
  • Risk Frameworks

    • All Findings
    • MITRE ATT&CK for Enterprise v10.1
    • MITRE D3FEND
  • Sysdig Best Practices

    • Sysdig Kubernetes - based on Sysdig’s security research and best practices

Coming soon:

  • CIS Red Hat OpenShift Container Platform (OCP) Benchmark v1.2.0

Appendix B

Legacy Compliance Versions

Migration Guide

For customers migrating to the new Compliance module, released January, 2023:

  • Starting January 17th, SaaS customers that connect new data sources for Sysdig cloud accounts or Sysdig agents will automatically have the new Compliance module (previously known as “Actionable Compliance”) enabled. Resources of the connected data sources will be evaluated according to CSPM/Risk and Compliance policies that are applied on zones. Results are displayed about 5-10 minutes after connection, varying by the scale of the resources.

  • If you were using Unified Compliance:

    • For Existing Kubernetes clusters: please make sure that your applied helm charts are updated according to the KSPM Components guide.
    • For Existing GCP cloud accounts, please be sure to enable the Cloud Asset API
    • The new Compliance module will be auto-enabled on your existing Cloud accounts by January 26th.
  • Currently, the New CSPM Compliance module is not available for OnPrem and IBM Cloud users; they could continue using Unified Compliance

Topics in This Section
Compliance Legacy Versions