Threat Detection

Sysdig Secure manages Runtime Threat Detection through policies. These policies consist of rules to detect and respond to suspicious activity in your environments. This page outlines the concepts to use Threat Detection Policies.

AWS

AWS CloudTrail CloudConnector Policy

AWS CloudTrail - CloudConnector policies evaluate each AWS CloudTrail entry. You can edit them, duplicate to create a custom version, or create a new list matching policy from scratch. You can scope policies by Account ID or virtual private cloud (VPC). This policy is used by Sysdig’s Legacy Agent-Based with CIEM feature.

Event notifications are generally limited to a frequency of once every five minutes. For details, see Message Throttling in Sysdig Secure.

To create an AWS CloudTrail - CloudConnector policy:

1. Log in to Sysdig Secure and select Policies > Threat Detection > Runtime Policies.
2. Click Add Policy and select AWS CloudTrail - CloudConnector.

Configure an AWS CloudTrail - CloudConnector Policy

Basic Parameters

Name: Enter a policy name.

Description: Provide a meaningful and searchable description.

Enabled/Disabled: Toggle to enable the policy so that it generates events.

Severity: Choose the appropriate severity level as you would like to see it in the Runtime Policies UI: High, Medium, Low, Info.

Policy severity is subjective and is used to group policies within a Sysdig Secure instance. There is no inheritance between the underlying rule priorities and the severity you assign to the policy.

Scope: Define the scope to which the policy will apply, based on the type-dependent options listed.

Link to Runbook: (Optional) Enter the URL of a company procedure that should be followed for events resulting from this policy. For example: https://www.mycompany.com/our-runbook-link.

If you enter a value here, then a View Runbook option will be displayed in any corresponding Event.

Policy Rules

Add or edit policy rules as needed. You can choose to Import from Library or to create a New Rule. To learn more about rules, see Manage Threat Detection Rules.

Actions

Determine what should be done if a Policy is violated.

Notify

Select a notification channel from the drop-down list to send notifications of events to appropriate personnel.

See also: Set Up Notification Channels.

Search for Existing Policies

To review the existing Workload policies:

1. Log in to Sysdig Secure and select Policies > Threat Detection > Runtime Policies.
2. Filter for Managed Policy and AWS CloudTrail - CloudConnector.
3. You can edit a managed policy, duplicate it to create a custom policy, or click + Add Policy and choose the AWS CloudTrail - CloudConnector to configure it from scratch.

CloudTrail

Behavioral Analytics

Sysdig AWS Behavioral Analytics is a unique case under the AWS CloudTrail policy. Instead of triggering at single incidents, its rules detect both suspicious sequences of actions and unusual clusters of activities across various AWS services, such as Identity and Access Management (IAM), Elastic Compute Cloud (EC2) and Simple Storage Service (S3). This improves detection of sophisticated threats, such as privilege escalation attempts and reconnaissance activities.

You can turn rules for Sysdig AWS Behavioral Analytics on or off, and edit existing exceptions field values, but you cannot duplicate it to create custom or ruleset policies, as you can with other managed policies. This is because behavioral analytics is not based on the Falco rules engine.

View Behavioral Analytics

To see behavioral analytics policies:

1. Log in to Sysdig Secure.
2. Select Policies > Runtime Policies.
3. Under the AWS CloudTrail policy, find the managed policy type Sysdig AWS Behavioral Analytics.
4. Select the policy to review its rules in detail.

To see behavioral analytics events:

1. Log in to Sysdig Secure.

2. Select Threats > Activity | Events Feed.

   Behavioral analytics events will show up in the event feed.

   Stats and Sequence are the two types of behavioral analytics. Stats have a list of API names and a corresponding count of how often that API was hit in the time interval. Sequence events show the sequence of APIs that were hit to match the condition of the rule.

   Behavioral Analytics events do not appear in the insights view.

Add Exceptions

Behavioral Analytics do not support custom exceptions, but you can add values to existing exceptions. Exception definitions are added by the Sysdig threat research team. To add values to exceptions:

1. Log in to Sysdig Secure.

2. Select Policies > Runtime Policies.

3. Under the AWS CloudTrail policy, select Sysdig AWS Behavioral Analytics.

   The detail panel appears.

4. Select the pencil icon in the top right.

   The editor appears.

5. Select a rule to which you want to add an exception.

   The rule detail panel appears.

6. Select the pencil icon in the top right.

   The rule page appears.

7. Select Open Exceptions Editor.

   The exceptions modal appears.

8. Select the pencil icon on an exception to add values.

   The exception comparator supports regex, in, and = field matching.

   Behavioral analytics do not support Suggested Exceptions or auto tuning.

9. Fill in the exception values and click Apply.

Configure an AWS CloudTrail Policy

To create an AWS CloudTrail policy:

1. Log in to Sysdig Secure and select Policies > Threat Detection > Runtime Policies.
2. Click Add Policy and select AWS CloudTrail.

Basic Parameters

Name: Enter a policy name.

Description: Provide a meaningful and searchable description.

Enabled/Disabled: Toggle to enable the policy so that it generates events.

Severity: Choose the appropriate severity level as you would like to see it in the Runtime Policies UI: High, Medium, Low, Info.

Policy severity is subjective and is used to group policies within a Sysdig Secure instance. There is no inheritance between the underlying rule priorities and the severity you assign to the policy.

Scope: Define the scope to which the policy will apply, based on the type-dependent options listed.

Link to Runbook: (Optional) Enter the URL of a company procedure that should be followed for events resulting from this policy. For example: https://www.mycompany.com/our-runbook-link.

If you enter a value here, then a View Runbook option will be displayed in any corresponding Event.

Policy Rules

Add or edit policy rules as needed. You can choose to Import from Library or to create a New Rule. To learn more about rules, see Manage Threat Detection Rules.

Actions

Determine what should be done if a Policy is violated.

Notify

Select a notification channel from the drop-down list to send notifications of events to appropriate personnel.

See also: Set Up Notification Channels.

Policy Rules

Add or edit policy rules as needed. You can choose to Import from Library or to create a New Rule. To learn more about rules, see Manage Threat Detection Rules.

Actions

Determine what should be done if a Policy is violated.

Notify

Select a notification channel from the drop-down list to send notifications of events to appropriate personnel.

See also: Set Up Notification Channels.

Search for Existing Policies

To review the existing Workload policies:

1. Log in to Sysdig Secure and select Policies > Threat Detection > Runtime Policies.
2. Filter for Managed Policy and AWS CloudTrail.
3. You can edit a managed policy, duplicate it to create a custom policy, or click + Add Policy, and choose AWS CloudTrail to configure it from scratch.

GuardDuty

Prerequisites

GuardDuty findings are only available when the connected AWS cloud account has GuardDuty enabled. To enable GuardDuty on your AWS account, see Getting started with GuardDuty.

Create an AWS GuardDuty Policy

To create an AWS GuardDuty policy:

1. Log in to Sysdig Secure and select Policies > Threat Detection > Runtime Policies.

2. Select + Add Policy > AWS GuardDuty.

   Name: Enter a policy name.

   Description: Provide a meaningful and searchable description or keep the default one.

   Enabled/Disabled: Toggle to enable the policy so that it generates events.

   Severity: Choose the severity level you would like to see in the Runtime Policies UI: High, Medium, Low, Info.

   Policy severity is subjective and is used to group policies within a Sysdig Secure instance. There is no inheritance between the underlying rule priorities and the severity you assign to the policy.

   Scope: Define the scope to which the policy will apply, based on the type-dependent options listed.

   Link to Runbook: (Optional) Enter the URL of a company procedure that should be followed for events resulting from this policy. For example: https://www.mycompany.com/our-runbook-link.

   If you enter a value here, then a View Runbook option will be displayed in any corresponding Event.

Policy Rules

Add or edit policy rules as needed. You can choose to Import from Library or create a New Rule. See Manage Threat Detection Rules.

Actions

Determine what should be done if a Policy is violated.

Notify: Select a notification channel from the drop-down for sending notifications of events to appropriate personnel.

See Set Up Notification Channels for more information.

Search for Existing Policies

To review the existing AWS GuardDuty policies:

1. Log in to Sysdig Secure and select Policies > Threat Detection > Runtime Policies.

2. Filter for Managed Policy and AWS GuardDuty.

3. Either edit a managed policy and duplicate it to create a custom policy,

   or

   Click + Add Policy, and choose AWS GuardDuty to configure it from scratch.

AWS ML

Key Features

This policy:

• Extends machine learning to AWS cloud accounts to monitor whether AWS console logins follow irregular patterns and notify users about suspicious activity.
• Quickly detects AWS log-ons from odd locations or different areas of the globe, as well as from unexpected browsers or OSes.
• Enables advanced machine learning detection capabilities based on CloudTrail logs.
• Allows users to understand why an event is considered anomalous compared to the expected behavior. Specifically, the policy provides the following info:
  • Description: What the Anomaly is about
  • Influential Factors: Variables contributing most to anomaly
  • Confidence Level: Probability measure of detection accuracy

The AWS ML policy is available by default in the main policies menu for all Sysdig Secure SaaS users.

Event notifications are generally limited to a frequency of once every five minutes. For details, see Message Throttling in Sysdig Secure.

Configure AWS ML Custom Policy

In the Sysdig Secure UI:

1. Select Policies > Threat Detection > Runtime Policies to display the Runtime Policies page.
2. Click + Add Policy (at the top right of the page).
3. Select AWS ML policy type.
4. Configure the policy:

Basic Parameters

Name: Enter a policy name.

Description: Provide a meaningful and searchable description.

Enabled/Disabled: Toggle to enable the policy so that it generates events.

Severity: Choose the appropriate severity level as you would like to see it in the Runtime Policies UI: High, Medium, Low, Info.

Policy severity is subjective and is used to group policies within a Sysdig Secure instance. There is no inheritance between the underlying rule priorities and the severity you assign to the policy.

Scope: Define the scope to which the policy will apply, based on the type-dependent options listed.

Link to Runbook: (Optional) Enter the URL of a company procedure that should be followed for events resulting from this policy. For example: https://www.mycompany.com/our-runbook-link.

If you enter a value here, then a View Runbook option will be displayed in any corresponding Event.

Policy Rules

Add or edit policy rules as needed. You can choose to Import from Library or to create a New Rule. To learn more about rules, see Manage Threat Detection Rules.

Actions

Determine what should be done if a Policy is violated.

Notify

Select a notification channel from the drop-down list to send notifications of events to appropriate personnel.

See also: Set Up Notification Channels.

Detect

Anomalous Console Login: Toggle on or off and select the confidence level at which the policy should be triggered: Default, Higher, or Highest.

• Default: This is the value at which the model is tested by Sysdig’s Threat Research Team.

• Higher and Highest: The higher the value chosen, the lower the chance of false positives, but the higher the chance of false negatives (i.e. missed anomalous behaviors).

Actions

Notify: Select a notification channel from the drop-down list for sending notifications of events to appropriate personnel.

See also: Set Up Notification Channels.

Azure

Create an Azure Platform Log Policy

To create an Azure Platform Log policy:

1. Log in to Sysdig Secure and select Policies > Threat Detection > Runtime Policies.
2. Click Add Policy and select Azure Platform Log.

Configure an Azure Platform Log Policy

Basic Parameters

Name: Enter a policy name.

Description: Provide a meaningful and searchable description.

Enabled/Disabled: Toggle to enable the policy so that it generates events.

Severity: Choose the appropriate severity level as you would like to see it in the Runtime Policies UI: High, Medium, Low, Info.

Policy severity is subjective and is used to group policies within a Sysdig Secure instance. There is no inheritance between the underlying rule priorities and the severity you assign to the policy.

Scope: Define the scope to which the policy will apply, based on the type-dependent options listed.

Link to Runbook: (Optional) Enter the URL of a company procedure that should be followed for events resulting from this policy. For example: https://www.mycompany.com/our-runbook-link.

If you enter a value here, then a View Runbook option will be displayed in any corresponding Event.

Policy Rules

Add or edit policy rules as needed. You can choose to Import from Library or to create a New Rule. To learn more about rules, see Manage Threat Detection Rules.

Actions

Determine what should be done if a Policy is violated.

Notify

Select a notification channel from the drop-down list to send notifications of events to appropriate personnel.

See also: Set Up Notification Channels.

If you enter a value here, then a View Runbook option will be displayed in any corresponding Event.

Policy Rules

Add or edit policy rules as needed. You can choose to Import from Library or to create a New Rule. To learn more about rules, see Manage Threat Detection Rules.

Actions

Determine what should be done if a Policy is violated.

Notify

Select a notification channel from the drop-down list to send notifications of events to appropriate personnel.

See also: Set Up Notification Channels.

Search for Existing Policies

To review the existing Workload policies:

1. Log in to Sysdig Secure and select Policies > Threat Detection > Runtime Policies.
2. Filter for Managed Policy and Azure Platform Log.
3. You can edit a managed policy, duplicate it to create a custom policy, or click + Add Policy, and choose Azure Platform Log to configure it from scratch.

Drift

Drift is when an environment differs from the state checked into a version control system. This can occur in software that was introduced, updated, or upgraded into a live environment. Sysdig’s Drift Detection policy identifies newly created, downloaded, or modified binaries that were not part of a container image before it started running. With policy actions, you can prevent drifted binaries from executing, configure automatic notifications, and stop, pause, or kill drifted containers.

• Drift Detection applies to containers only and does not work on hosts.
• This policy was formerly known as “Container Drift” and “Drift Control”.

Overview

Drift Detection helps you:

• Prevent attacks by blocking container drift in production: Drift Detection automatically flags and denies deviations from the original container, blocking malicious executables before damage is done.
• Enforce immutability best practice: Drift Detection ensures that container software is not modified during its lifetime, driving good practices, consistency from source to run, and preventing actions that could be part of an attack.
• Enable easy and effective security: Teams are often overwhelmed by cloud-native complexity and blind to container drift, especially at scale. Now, security teams and IT can enable Drift Detection for the entire container environment and immediately start protecting it.

The Drift Detection policy has the following unique attributes:

• It includes only one pre-configured rule, which cannot be edited, and no other rules can be added to Drift Detection policies.
• It is a custom policy, not a managed policy.

Event notifications are generally limited to a frequency of once every five minutes. For details, see Message Throttling in Sysdig Secure.

Prerequisites

• Agent version 12.16+ for Drift Detection Policy
• Agent version 13.0 and above for captures and container stop/pause/kill actions
• On agent version v13.1 and above:
  • ignore_container_action: Ignores kill, stop, pause container operation
  • ignore_action: Ignores all the actions including kill, prevent malware, prevent drift and container actions.
• Kernel version 5.0 and above (see Prevent action)
• Agent version 13.1.0+ for the rule Detect Volume Drift.

  • In v13.1.1, it is enabled by default.

  • In v13.1.0, add the following configuration to the dragent.yaml file:

    drift_deny_execution_from_volumes: true
    
    
• Agent version 13.2.0+ to Block Prohibited Binary Execution.
• Shield version 14.0+ to enable Detect Volume Binaries without enabling Detect Binary Drift first.

For more details, see Configure Drift Detection in Agent Configuration.

Create a Drift Detection Policy

To configure a Drift Detection Policy in the Sysdig Secure UI:

1. Select Policies > Threat Detection > Runtime Policies to display the Runtime Policies page.
2. Click + Add Policy in the top right of the page.
3. Select the Drift Detection policy type.

Next, you can configure the policy.

Configure a Drift Detection Policy

Name: Enter a policy name.

Description: Provide a meaningful and searchable description.

Enabled: Toggle to enable or disable the policy. When the policy is enabled, it generates events.

Severity: Choose the appropriate severity level as you would like to see it in the Runtime Policies UI: High, Medium, Low, or Info.

• Policy severity is subjective and is used to group policies within a Sysdig Secure instance.
• There is no inheritance between the underlying rule priorities and the severity you assign to the policy.

Scope: Define the scope to which the policy will apply, based on the type-dependent options listed.

• Auto-tuning is not used with Drift policies. If you have too many false positives, use Scope to tune them.

Link to Runbook: (Optional) Enter the URL of a company procedure that should be followed for events resulting from this policy. For example, https://www.mycompany.com/our-runbook-link.

• If you enter a value here, a View Runbook option will be displayed in any corresponding Event.

Policy Rules

In the Policy Rules section, you can enable or disable the following rules:

Binary Drift: Toggle this on to dynamically detect the execution of drifted binaries.

• A drifted binary is any binary that was not part of the original image of the container. It is typically downloaded or compiled into a running container.
• If a detected binary attempts to run when this toggle is enabled, Sysdig will create an event.
• To prevent a detected drifted binary from running, use Prevent.

Volume Drift: Toggle this on to treat all binaries from mounted volumes as drifted. This will generate events and prevent the binaries from being executed.

• Independent volume drift requires shield version 14.0+. On earlier versions, you must enable Binary Drift detection first in order to enable Volume Drift detection.

Block Prohibited Binary Execution: Toggle this on to block execution of detected drifted binaries. When toggled on, the Prohibited Binaries section appears in the Rules Configuration section. You must define at least one prohibited binary to enable this toggle.

• Requires agent version 13.2.0+.

Rules Configuration

Define binaries with their full path, separated by commas, using string or regex (if enabled). Defining with string is very specific, while regex is pattern matching and more flexible.

Use Regex: Toggle this on to use regex (regular expression) when you configure exceptions.

• Regex allows you to create patterns for matching file names or process paths. For example, .*\.log$ matches any file ending with “.log”. You can use regex to identify drifted files or processes that should be allowed or blocked by matching their names or paths against the regex pattern defined.
• To learn more about regex syntax, see Regular Expression Syntax.
• Agent version 13.2.0 or above is required for this feature.

File-based Exceptions

Exceptions: Specify which drifted files can execute within a container. If a file matches any condition in the Exceptions list, it will be allowed. Even if a file is prohibited, has been modified or added post-deployment, it can still be executed if it is listed as an exception. This is useful for scenarios where certain files need to be updated or added and executed as part of legitimate operations, such as configuration scripts or updates.

Prohibited Binaries: Specify which drifted files are not allowed to execute. Prohibited binaries will be prevented from executing unless they are listed as an Exception.

Process-based Exceptions

Exceptions: Specify which processes can execute drifted files. If a process matches any condition in the Exceptions list, it will be allowed. Specified processes can interact with modified or newly added files without triggering security alerts, facilitating legitimate operations that require such interactions. Use Exceptions sparingly to ensure that only necessary drifted processes are allowed.

Prohibited Binaries: Specify binaries of processes whose execution is blocked even if they are built with the image. Prohibited binaries will be prevented from executing unless they are listed as an Exception.

If a file or process matches an entry in both the Exceptions and Prohibited Binaries lists, the Exception will take precedence. This means the file or process will be allowed to execute even if it is also listed as prohibited. Once something is explicitly added to the Exceptions list, it overrides any detection or prohibition rules.

The Prohibited Binaries option was formerly called always deny.

Actions

Determine what should be done if a Policy is violated.

Prevent

Prevent Execution: Toggle this to stop detected executables from running.

• Depending on the kernel version, the agent will either:

  • Kill the process once it is detected as drifted (kernel version <5.0)
  • Prevent drifted processes from running (kernel version 5.0+)

  The latter method is preferable because it stops the drifted process from running for any period. The agent determines which mode to use at agent startup. One of the above-mentioned types of prevention is always available with 12.15+ agents. For example, Bottlerocket prevents by using the kill action.

Containers

Container policy actions coverage map:

Environment	Container Policy Action Supported?
Kubernetes - Linux	✅
Kubernetes - Windows	❌
Hosts - Linux Containers	✅
Hosts - Linux Packages	✅
Hosts - Windows	❌
Hosts - ECS on EC2	❌
Serverless - Azure Container Apps	❌
Serverless - Cloud Run Service	❌
Serverless - ECS on Fargate	❌

Select what should happen to affected containers if the policy rules are breached. The appropriate action depends on your use case:

• No container action: Do not change the container behavior; send a notification according to Notification Channel settings.
• Kill: Kill one or more running containers immediately.
• Stop: Allow a graceful shutdown (10-seconds) before killing the container.
• Pause: Suspend all processes in the specified containers.

For details, see Available Response Actions.

You can configure the agent to prevent kill/pause/stop actions, regardless of the policy.

See Ignore Container Actions at the Agent Level.

Capture

Toggle Capture ON if you want to create a capture in case of an event, and define the number of seconds before and after the event that should be in the snapshot.

See also: Captures.

Notify

Select a notification channel from the drop-down to send notifications of events to appropriate personnel.

This will ensure you know there’s a serious security incident. You can then save the notification as a record of what happened for later analysis.

See also: Set Up Notification Channels.

Check Events

When the policy is enabled, you can check for any detected events:

1. Log in to Sysdig Secure and select Events.
2. Type Drift in the filter bar to find where the Drift policy was triggered and drill down to examine the event details.

Known Limitations

There are certain conditions that the Drift Detection policy will not catch.

Script Execution using Binaries from the Base Image

Drift detection tracks the execution of binaries that were not part of the original image. It does not cover cases where a script is executed leveraging binaries from the original image. For example, if an attacker downloads a Python script and leverages an existing Python binary from the base image, drift detection will not detect it at runtime.

Persistent Volumes

As the Drift Detection policy uses overlays for detection, execution from persistent volumes is not considered “drifted.” Therefore, if a malicious binary is downloaded to a persistent volume and executed, it will not be caught.

Suppose you are using persistent volumes exclusively for data. In that case, you can set the following option in the agent config file to treat the execution of all binaries from persistent volumes as drifted:

drift_deny_execution_from_volumes: true

Use with caution. When this option is used with the Prevent action, the execution of any binary from any mounted volumes will be stopped.

Container Limits

• For kernel versions below v5.13, Drift Detection can monitor up to 128 containers per node.
• For kernel versions v5.13 or above, you can modify the container limit as described in Configure Container Limits.

GCP

GCP Audit Log Policy

GCP Audit Log policies evaluate each GCP Audit Log entry. You can edit them, duplicate to create a custom version, or create a new list matching policy from scratch. You can scope policies by Account ID or virtual private cloud (VPC).

Event notifications are generally limited to a frequency of once every five minutes. For details, see Message Throttling in Sysdig Secure.

Create a GCP Audit Log Policy

To create a GCP Audit Log policy:

1. Log in to Sysdig Secure and select Policies > Threat Detection > Runtime Policies.
2. Click Add Policy and select GCP Audit Log.

Configure a GCP Audit Log Policy

Basic Parameters

Name: Enter a policy name.

Description: Provide a meaningful and searchable description.

Enabled/Disabled: Toggle to enable the policy so that it generates events.

Severity: Choose the appropriate severity level as you would like to see it in the Runtime Policies UI: High, Medium, Low, Info.

Policy severity is subjective and is used to group policies within a Sysdig Secure instance. There is no inheritance between the underlying rule priorities and the severity you assign to the policy.

Scope: Define the scope to which the policy will apply, based on the type-dependent options listed.

Link to Runbook: (Optional) Enter the URL of a company procedure that should be followed for events resulting from this policy. For example: https://www.mycompany.com/our-runbook-link.

If you enter a value here, then a View Runbook option will be displayed in any corresponding Event.

Policy Rules

Add or edit policy rules as needed. You can choose to Import from Library or to create a New Rule. To learn more about rules, see Manage Threat Detection Rules.

Actions

Determine what should be done if a Policy is violated.

Notify

Select a notification channel from the drop-down list to send notifications of events to appropriate personnel.

See also: Set Up Notification Channels.

Notify

Select a notification channel from the drop-down list to send notifications of events to appropriate personnel.

See also: Set Up Notification Channels.

Search for Existing Policies

To review the existing Workload policies:

1. Log in to Sysdig Secure and select Policies > Threat Detection > Runtime Policies.
2. Filter for Managed Policy and GCP Audit Log.
3. You can edit a managed policy, duplicate it to create a custom policy, or click + Add Policy, and choose GCP Audit Log to configure it from scratch.

GitHub

GitHub Policy

GitHub policies evaluate GitHub logs in Sysdig Cloud. You can edit them, duplicate to create a custom version, or create a new list matching policy from scratch.

Event notifications are generally limited to a frequency of once every five minutes. For details, see Message Throttling in Sysdig Secure.

Create a GitHub Policy

To create a GitHub policy:

1. Log in to Sysdig Secure and select Policies > Threat Detection > Runtime Policies.
2. Click Add Policy and select GitHub.

Configure a GitHub Policy

Basic Parameters

Name: Enter a policy name.

Description: Provide a meaningful and searchable description.

Enabled/Disabled: Toggle to enable the policy so that it generates events.

Severity: Choose the appropriate severity level as you would like to see it in the Runtime Policies UI: High, Medium, Low, Info.

Policy severity is subjective and is used to group policies within a Sysdig Secure instance. There is no inheritance between the underlying rule priorities and the severity you assign to the policy.

Scope: Define the scope to which the policy will apply, based on the type-dependent options listed.

Link to Runbook: (Optional) Enter the URL of a company procedure that should be followed for events resulting from this policy. For example: https://www.mycompany.com/our-runbook-link.

If you enter a value here, then a View Runbook option will be displayed in any corresponding Event.

Policy Rules

Add or edit policy rules as needed. You can choose to Import from Library or to create a New Rule. To learn more about rules, see Manage Threat Detection Rules.

Actions

Determine what should be done if a Policy is violated.

Notify

Select a notification channel from the drop-down list to send notifications of events to appropriate personnel.

See also: Set Up Notification Channels.

Policy Rules

Add or edit policy rules as needed. You can choose to Import from Library or to create a New Rule. To learn more about rules, see Manage Threat Detection Rules.

Actions

Determine what should be done if a Policy is violated.

Notify

Select a notification channel from the drop-down list to send notifications of events to appropriate personnel.

See Set Up Notification Channels for more information.

Search for Existing Policies

To review the existing Workload policies:

1. Log in to Sysdig Secure and select Policies > Threat Detection > Runtime Policies.
2. Filter for Managed Policy and GitHub.
3. You can edit a managed policy, duplicate it to create a custom policy, or click + Add Policy, and choose GitHub to configure it from scratch.

K8s

Kubernetes Audit Policy

Kubernetes Audit policies evaluate a Kubernetes Audit Log entry. You can edit them, duplicate to create a custom version, or create a new list matching policy from scratch. You can scope policies by cluster or namespace.

Event notifications are generally limited to a frequency of once every five minutes. For details, see Message Throttling in Sysdig Secure.

Prerequisites

• Sysdig Agent version 11.0.0 or greater.
• Kubernetes audit logging. See Kubernetes Audit Logging.

Create a Kubernetes Audit Policy

To create a Kubernetes Audit policy:

1. Log in to Sysdig Secure and select Policies > Threat Detection > Runtime Policies.
2. Click Add Policy and select Kubernetes Audit.

Configure a Kubernetes Audit Policy

Basic Parameters

Name: Enter a policy name.

Description: Provide a meaningful and searchable description.

Enabled/Disabled: Toggle to enable the policy so that it generates events.

Severity: Choose the appropriate severity level as you would like to see it in the Runtime Policies UI: High, Medium, Low, Info.

Policy severity is subjective and is used to group policies within a Sysdig Secure instance. There is no inheritance between the underlying rule priorities and the severity you assign to the policy.

Scope: Define the scope to which the policy will apply, based on the type-dependent options listed.

Link to Runbook: (Optional) Enter the URL of a company procedure that should be followed for events resulting from this policy. For example: https://www.mycompany.com/our-runbook-link.

If you enter a value here, then a View Runbook option will be displayed in any corresponding Event.

Policy Rules

Add or edit policy rules as needed. You can choose to Import from Library or to create a New Rule. To learn more about rules, see Manage Threat Detection Rules.

Actions

Determine what should be done if a Policy is violated.

Notify

Select a notification channel from the drop-down list to send notifications of events to appropriate personnel.

See also: Set Up Notification Channels.

Policy Rules

Add or edit policy rules as needed. You can choose to Import from Library or to create a New Rule. To learn more about rules, see Manage Threat Detection Rules.

Actions

Determine what should be done if a Policy is violated.

Notify

Select a notification channel from the drop-down list to send notifications of events to appropriate personnel.

See also: Set Up Notification Channels.

Search for Existing Policies

To review the existing Workload policies:

1. Log in to Sysdig Secure and select Policies > Threat Detection > Runtime Policies.
2. Filter for Managed Policy and Kubernetes Audit.
3. You can edit a managed policy, duplicate it to create a custom policy, or click + Add Policy and choose Kubernetes Audit to configure it from scratch.