Actionable Compliance (Preview)
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.
Get high-level posture performance indicators (PPIs) on each of the pre-defined policies/filters.
Review the Compliance Views screen.
Select a Policy to get Results and select a failing requirement to see the Controls that comprise it.
Next to the resource appears a Start Remediation link that opens the Remediation panel.
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
It is necessary to upgrade the agents with the following parameters (i.e. in Helm):
--set nodeAnalyzer.kspmAnalyzer.deploy=true --set kspmCollector.deploy=true
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.
Navigate Compliance Overview
Posture > Actionable Compliannce | Compliance Views.
Review the compliance posture Overview. Each row or tile is a view filtering compliance results.
All Resultsare 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
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
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.
Select a tile to drill into the results of a particular policy.
Access and Filter Results
From the Compliance Views page, select a particular tile to see the Results page.
The failed requirements are sorted by severity and importance.
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.
- OS Image
- Type: Deployment, Daemonset, StatefulSet, ReplicaSet, Pod, Job, CronJob
- Identity Object
- Type: ServiceAccount, User, System Group\Builtin Group, Role, ClusterRole
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?
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.
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.
|Previous Term||New Term|
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.
|Control||Requirement (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.
Groupings of requirements in a policy
A control defines the way we identify the issue (check) and the playbook(s) to remediate the violation detected by the check.
|Vulnerability Exception||Risk 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.
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
- OpenShift 3.11 v1.2.1
- CIS OpenShift 4 v1.1.0
Was this page helpful?
Glad to hear it! Please tell us how we can improve.
Sorry to hear that. Please tell us how we can improve.