Posture Controls

• Understand precisely what is or will be evaluated
• Review the logic behind each control and suggested remediation steps
• Tune your compliance results for personalized evaluation parameters
• Customize evaluation parameters to fit your specific needs
• Address misconfigurations across Kubernetes, containers, and cloud environments

Sysdig Posture Controls are built on the Open Policy Agent (OPA) engine, using OPA’s policy language, Rego.

Prerequisites

This feature requires the Compliance component.

Navigate Posture Controls List

1. To see the Posture Controls list, select Policies > Posture | Controls.

2. Select a specific control to open details in the right panel.

   

Search and Filter the List

Find specific controls through search and several filter options:

• Search: Enter any word or part of a word in the name, description, or author to find matching controls.
• Severity: Filter controls by their severity level; High, Medium, or Low.
• Select Type: From the drop-down, choose a control type such as Cluster, Host, Identity, or Resource.
• Select Target: From the drop-down, select the specific platforms, distributions, and supported versions against which a control evaluates resources. Online cloud platforms, such as Azure Kubernetes Service (AKS), Amazon Web Services (AWS), and Google Cloud Platform (GCP), do not have versioning but always resolve to the latest version.

Add multiple parameters to create more specific filter expressions.

Review a Control

To review a control in Posture Controls:

1. Select a specific control.

   The control detail panel appears.

2. Review basic attributes. At the top of the panel you can see:

   • The title of the control.

   • The severity: High, Medium, or Low.

   • The type: Cluster, Host, Identity, or Resource.

   • The author: For example, Sysdig, for out-of-the-box controls

   • A brief description.

   • The policies to which the control is linked.

     Hover over the policy names to get full details, such as the exact requirement number for the particular compliance standard, and to navigate to that requirement in the policy details page.

3. Review the bottom panel. Here, you can see the following tabs:

   • Code: Use the provided code snippets.

     The code provides visibility into the precise objects that are evaluated and how the evaluation rules are structured. The display includes Inputs (where applicable) and the evaluation code written in Rego.

     You can copy and download the code as a .json file.

   • Remediation Playbook: Review the suggested steps to resolve failing controls. Where applicable, you must enter inputs in the remediation code provided.

     

   • Parameters: You can Customize the control parameters. See Customize Posture Controls.

Customize Posture Control

You can customize controls by adjusting values within predefined parameters.

Configure Severity

By default, Sysdig assigns an opinionated severity level to the posture controls it delivers.

To edit the Severity assignment:

1. Select a specific control and select the Parameters tab.

2. Click Customize.

   

3. Choose the Severity level, and click Save.

   A success message appears. The Compliance results will be updated during the next evaluation.

Configure Evaluation Parameters

1. Select a specific control and select the Parameters tab.

2. Click Customize.

3. Customize an evaluation parameter.

4. Click Save.

Customize Labels

You can add or delete custom labels on controls that originally contained labels:

1. Select a control that contains labels and open the Parameters tab.

2. Click Customize.

3. Enter a label in key:value or key format, such as env:prod or owner.

4. Click Return.

   If you want to add another label, insert a comma and the next label and click Return again.

5. Click Save when your list is complete.

   The labels appear as Custom Values in the Parameters tab.

   

Custom Controls

In the context of cloud security posture management (CSPM), custom controls are policies or rules that give security teams the flexibility to create and enforce policies. You can use them to manage posture, tailor compliance measures, and detect misconfigurations across infrastructures like Kubernetes, containers, and the cloud.

You can duplicate and edit any control. For example, you can create a new custom control that checks for a specific label.

Guidelines

• You cannot link a user-duplicated control to an out-of-the-box policy.
• You can use a control from one policy in another custom policy with different parameter values. Even a change in severity level constitutes a different use case.
• You can delete or edit a duplicated (custom) control.

Duplicate a Control

1. Select Policies > Posture | Controls and browse or search for a specific control.

   For example, if a control contains labels, the default Control Name includes the word Label. Search label to find these controls and duplicate them if desired.

2. Click the three-dot menu and select Duplicate.

3. Edit the following as desired and click Save:

   Name: You can enter any name that is not used by another control. By default, Sysdig uses the format Original Control Name (copy). For example, Examine Audit policies (Copy).

   Description: Optionally, enter a meaningful description about the control.

   Severity: Select a severity for your custom control.

4. If the original control contained configurable evaluation parameters, you can customize them.

   See Configure Evaluation Parameters.

5. You can now link the new custom control to a requirement in your custom policies.

Edit or Delete Custom Controls

1. Select a custom control from the Control List.

   Tip: Look for the Author to identify custom controls. If the author is not Sysdig, then the control is custom.

2. Select the three-dot menu in the detail panel.

3. Select Edit.

4. Change the Control Details, such as Name, Description, and Severity, as needed.

5. Click Save.

   The changed details will be applied to any custom policy where the control is used after the next evaluation.

To delete a custom control:

1. Select a custom control from the list.

2. Select the three-dot menu icon.

3. Select Delete.

4. After the warning, confirm Yes, Delete.

   The Compliance and Posture results of evaluations made from this control and any accepted risks for the control are deleted upon the next evaluation.

Create a Custom Control with Rego

Sysdig Secure’s Terraform provider lets you define, manage, and deploy custom controls as part of your infrastructure automation. This ensures your security policies are version-controlled, easily maintainable, and consistent across environments.

Prerequisites

• Ensure you have both Terraform and Go installed in your environment:

  • Terraform version >0.12.x.

    • Check your version with the command terraform version.

  • Go version higher than the one specified in go.mod.

    • Check your version with the command go version.

    • Set up $GOPATH as per the instructions in Go Wiki.

• Terraform Provider for Sysdig: To install and configure the provider, see Create Custom Controls with Terraform.

• Your Sysdig API token and Agent Access keys.

  • Replace these values in the Terraform code snippet below:
  Click to expand

  terraform {
  
  required_providers {
  
     sysdig = {
  
        source = "local/sysdiglabs/sysdig"
  
        version = "~> 1.0.0"
  
     }
  
  }
  
  }
  
  provider "sysdig" {
  
  sysdig_secure_url="https://secure.sysdig.com"
  
  sysdig_secure_api_token = "XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXXX"
  
  extra_headers = {
  
     "Proxy-Authorization": "Basic XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX"
  
  }
  
  }
  

Terraform Resource for Custom Controls

Sysdig Secure’s Terraform Provider uses the sysdig_secure_posture_control resource to define custom controls. Resource attributes include:

• name: The name of the custom control.
• description: A detailed explanation of what the control does.
• resource_kind: The type of resource to which the control applies. For example, AWS S3 buckets or Kubernetes pods.
• severity: The severity level that defines the control’s importance, such as High, Medium or Low.
• rego: The Rego policy code that defines the control logic.
• remediation_details: Instructions for remediating any issues identified by the control.

Next, we’ll create a custom Sysdig Secure custom control using Rego and Terraform.

S3 Bucket Without Versioning

S3 bucket versioning is important for several reasons, such as data protection, recovery, and management. In this scenario, we’ll create a custom control to ensure object versioning is enabled for your Amazon S3 buckets to preserve and recover overwritten and deleted objects:

1. Download and unzip the git file from the GitHub repository `terraform-provider-sysdig.

2. Inside the terraform-provider-sysdig-master folder, create a new Terraform file.

3. Copy this code snippet and paste it in your file. The Rego code is embedded within the Terraform script:

   Click to expand

   resource "sysdig_secure_posture_control" "s3_bucket_without_versioning" {
   
   name = "S3 Bucket without versioning"
   
   description = "Ensure that S3 object versioning is enabled for your Amazon S3 buckets to protect and recover overwritten and deleted S3 objects."
   
   resource_kind = "AWS_S3_BUCKET"
   
   severity = "High"
   
   rego = <<-EOF
   
      package sysdig
   
      import future.keywords.if
   
      import future.keywords.in
   
      default risky := false
   
      # Control fails if no versioning configuration is found
   
      risky if {
   
         count(input.Versioning) == 0
   
      }
   
      # Control fails if versioning is not enabled
   
      risky if {
   
         some version in input.Versioning
   
         lower(version.Status) != "enabled"
   
      }
   
   EOF
   
   remediation_details = <<-EOF
   
   ## Remediation Impact
   Enabling versioning for S3 buckets helps preserve and recover previous versions of objects. 
   It allows recovery of deleted or overwritten data, and helps ensure data protection. 
   Archiving previous versions to Amazon S3 Glacier is also possible for long-term, low-cost storage.
   
   <code>## Remediate Using Command Line</code>
   Run the following command to enable versioning for the selected bucket:
   

     aws s3api put-bucket-versioning --bucket <bucket-name> --versioning-configuration Status=Enabled
   
     ```
   
     Repeat this command for other buckets in your AWS environment.
   

   EOF

   }

4. From your terminal, initialize the Terraform environment. If the prerequisites are properly configured, you’ll see a message similar to the following snapshot:

   

5. To deploy this Terraform script as a custom control in Sysdig Secure, run terraform apply from your terminal.

   Terraform generates an execution plan describing what it will do to deploy the code, and then executes it to build the described infrastructure or configuration.

6. The prompt will pause for user input. At this stage, type yes and continue.

   The custom control S3 Bucket without versioning appears in the Posture Controls library and is ready to be used in custom policies.

7. To verify it, log in to Sysdig Secure, select Policies > Posture | Controls, and search S3 Bucket without versioning.

Apply Your Custom Control

Now, you can assign the new custom control to a new or existing Sysdig Secure Posture Policy based on your enterprise needs. The following example was created using these steps:

1. Navigate to Policies > Posture | Policies.

2. Select New Policy.

3. Configure the policy:

   Duplicate from: None, start from scratch.

   Name: Custom Controls_S3 Bucket without versioning.

   Description: Add a description.

4. Click Save.

   The policy detail page appears.

5. Select Publish.

   Sysdig will prompt you to edit the policy. Alternatively, you can find the policy from the Posture Policies list, and select Edit from the three-dot menu icon.

6. In the Policy Details tab, select Add Zones, and choose the infrastructure scope across which the new control must apply.

7. In the Requirements & Controls, link your custom control to evaluate the posture compliance of your defined infrastructure.

To roll back, delete the resource definitions from your Terraform file and reapply. This updates the Posture Controls library and detaches the defined controls from the policies.

Sysdig API Endpoint

The Sysdig API Endpoint enables you to query and fetch values for Terraform attributes, such as resource_kind. The REST APIs enable you to programmatically access and manage Sysdig Monitor and Sysdig Secure. You can use this to streamline your development workflows.

The Sysdig API endpoint has several category headers, such as Compliance, Cloud Organizations, and CSPM, along with details like the query parameters. For example, to fetch cloud resources, query with the GET request and define parameters such as providerType, resourceKind, and filter. The API endpoint also builds your custom queries in multiple formats, such as Go, Curl, Node, Java, and Python.

The following example shows you how to use Curl to query the API endpoint using a GET request, and then fetch values for the Terraform attribute resource_kind:

1. Export the Sysdig API token in your environment. To export it in Windows, see Best Practices for API Key Safety.
2. From the left panel, select CSPM, scroll down, and select Get Resource Kinds. Alternatively, use the link Get Resource Kinds.
3. Switch to the Curl tab and copy the GET request.
4. Open up a terminal window and paste the GET request. Provide your Sysdig API token for $SYSDIG_SECURE_API_TOKEN.

The JSON output provides a list of all legitimate resource kinds available to query within the Sysdig Secure platform.

If we look back at our Terraform script, we had defined resource_kind as AWS_S3_Bucket.

1. On the Sysdig API endpoint, click Get Resource Example.

2. Choose Curl, copy the GET request, and paste it in your terminal.

   The new request fetches all the values associated with AWS_S3_Bucket.

3. Copy and save the results.

   You will need it for the next section to verify the Rego code.

The Rego Playground

The Rego Playground is an online interactive environment that lets you write, test, and debug Rego policies in a sandboxed, browser-based interface. It’s ideal for those looking to explore policy-based control across various systems.

The following example shows you how to use the platform to evaluate the Rego code logic previously defined in your Terraform script. The JSON outputs from the last example are required as input variables.

1. Copy the following code snippet and paste it in the editor section. If needed click Format to align the code:

   Click to expand

   package sysdig
   
   import future.keywords.if
   
   import future.keywords.in
   
   default risky := false
   
   # Control fails if no versioning configuration is found
   
   risky if {
   
   count(input.Versioning) == 0
   
   }
   
   # Control fails if versioning is not enabled
   
   risky if {
   
   some version in input.Versioning
   
   lower(version.Status) != "enabled"
   
   }
   

2. Add the previously saved JSON output in the INPUT window

   The Versioning.Status field is defined at the bottom of the JSON output. It’s currently set to string.

3. Click Evaluate to test the Rego script

   In the OUTPUT window, the value of risky is set to true. So, the AWS S3 Bucket will be tagged as a risk if the version status is not enabled in your cloud accounts.

4. Modify the Status field to enabled.

5. Evaluate the script again and notice that riskychanges to false in the OUTPUT window. This validates the Rego logic.

6. Use the link here to run the sample.

Best Practices for Implementing Custom Controls

• Start with high-impact controls: Prioritize custom controls that address significant security risks, such as blocking privileged containers or ensuring S3 versioning.
• Use Terraform for automation: Terraform makes it easy to manage custom controls as code, ensuring consistency across environments and allowing you to automate the deployment and updates of controls.
• Test controls in a staging environment: Always test your custom controls in a non-production environment to ensure that they work as expected and do not generate false positives.
• Continuously review and update controls: As your infrastructure evolves, regularly review and update your custom controls to reflect new security challenges and compliance requirements.

Customizable Default Controls

The following controls are customizable and have evaluation parameters that could be configured to personalize posture controls for specific use cases:

AWS

• API Gateway - Gateway with VPC_LINK connection type
• API Gateway - REST API Gateway Stage with unencrypted cache
• API Gateway - Rest API Gateway Stage without required tag
• API Gateway - Rest API Gateway without required tag
• API Gateway - Stage without required ACL
• AutoScaling - App-Tier Auto Scaling Group with associated Elastic Load Balancer
• AutoScaling - Auto Scaling Group Cooldown Period
• CloudFront - Use CloudFront Content Distribution Network
• ECR - Restricted User Access
• ElastiCache - Valid Node Type
• ElastiCache - Latest MemCached Engine Version
• ElastiCache - Latest Redis Engine Version'
• ElastiCache - Latest Instance Generation
• ElastiCache - Appropriate Cluster Cache Nodes Count
• ElastiCache - Expiration of Lease for Reserved Cache Node
• ElastiCache - Recent Acquisitions of Reserved Cache Nodes
• IAM - Appropriate Access Key Rotation
• IAM - Appropriate Password Minimum Length
• IAM - Appropriate Password Reuse
• IAM - No Unused Passwords
• IAM - No Unused Access Keys
• IAM - Unused Root Account
• Lambda - Function Uses Supported Runtime
• Lambda - Lambda Cross Account Access
• Networking - Defined Compliant destination-cidr-block in Routing Tables
• Resource Contains Required Labels
• SNS - Appropriate Subscribers
• SNS - Cross Account Access
• S3 - Enabled Encryption At Rest

GCP

• GCR - Restricted User Access
• Project - Corporate Credentials

Azure

• ACR - Restricted User Access
• AppService - Enabled Java Autoupdate
• AppService - Required Latest PHP Version
• AppService - Required Latest Python Version
• AppService - Required Latest TLS Version
• Compute - Installed Endpoint Protection
• Logging - Appropriate Diagnostic Setting
• Networking - Appropriate Flow Retention Setting
• PostgreSQL - Appropriate Log Retention Setting
• SQL Server - Appropriate Auditing Retention

Kubernetes

• ACR - Approved Registries
• API Server - Access to Pod Spec (OCP4)
• API Server - Defined audit-log-maxage
• API Server - Defined audit-log-maxbackup
• API Server - Defined audit-log-maxsize
• API Server - Owner of Pod Spec (OCP4)
• Approved Registries
• Container Contains Required Labels
• Container with Forbidden Capabilities
• GCR - Approved Registries
• Kubelet - Appropriate event-qps Level