> ## Documentation Index
> Fetch the complete documentation index at: https://tonelloandco.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

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

<Tabs>
  <Tab title="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.

    <Tip>
      Event notifications are generally limited to a frequency of once every five minutes. For details, see [Message Throttling in Sysdig Secure](https://docs.sysdig.com/en/notification-trouble).
    </Tip>

    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](https://docs.sysdig.com/en/manage-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](https://docs.sysdig.com/en/docs/administration/administration-settings/notifications-management/set-up-notification-channels/#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.
  </Tab>

  <Tab title="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](https://docs.sysdig.com/en/sysdig-secure/threat-detection-policies/runtime_policy_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](https://docs.sysdig.com/en/manage-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](https://docs.sysdig.com/en/docs/administration/administration-settings/notifications-management/set-up-notification-channels/#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](https://docs.sysdig.com/en/manage-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](https://docs.sysdig.com/en/docs/administration/administration-settings/notifications-management/set-up-notification-channels/#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.
  </Tab>

  <Tab title="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](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_settingup.html).

    ## 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](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](https://docs.sysdig.com/en/manage-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](https://docs.sysdig.com/en/set-up-notifications) 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.
  </Tab>

  <Tab title="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](https://docs.sysdig.com/en/notification-trouble).

    ## 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](https://docs.sysdig.com/en/manage-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](https://docs.sysdig.com/en/docs/administration/administration-settings/notifications-management/set-up-notification-channels/#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](https://docs.sysdig.com/en/set-up-notifications).
  </Tab>

  <Tab title="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](https://docs.sysdig.com/en/manage-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](https://docs.sysdig.com/en/docs/administration/administration-settings/notifications-management/set-up-notification-channels/#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](https://docs.sysdig.com/en/manage-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](https://docs.sysdig.com/en/docs/administration/administration-settings/notifications-management/set-up-notification-channels/#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.
  </Tab>

  <Tab title="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](https://docs.sysdig.com/en/administration/troubleshoot-notifications-channels/#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](https://docs.sysdig.com/en/sysdig-secure/drift_policy/#policy-rules).
    * Shield version 14.0+ to enable [Detect Volume Binaries](https://docs.sysdig.com/en/sysdig-secure/classic-secure-agent-configuration/#configure-drift-detection) without enabling Detect Binary Drift first.

    For more details, see [Configure Drift Detection](https://docs.sysdig.com/en/sysdig-secure/classic-secure-agent-configuration/#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](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](https://docs.sysdig.com/en/sysdig-secure/drift_policy/#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](https://docs.python.org/3.7/library/re.html#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](https://docs.sysdig.com/en/sysdig-secure/threats-respond/#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](https://docs.sysdig.com/en/docs/sysdig-secure/configuration/sysdig-agent/configuration-library/secure/#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](https://docs.sysdig.com/en/docs/sysdig-secure/investigate/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](https://docs.sysdig.com/en/set-up-notifications).

    ## 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](https://docs.sysdig.com/en/configuration-library-secure/#configure-container-limits-1).
  </Tab>

  <Tab title="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](https://docs.sysdig.com/en/notification-trouble).

    ## 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](https://docs.sysdig.com/en/manage-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](https://docs.sysdig.com/en/docs/administration/administration-settings/notifications-management/set-up-notification-channels/#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](https://docs.sysdig.com/en/docs/administration/administration-settings/notifications-management/set-up-notification-channels/#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.
  </Tab>

  <Tab title="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](https://docs.sysdig.com/en/notification-trouble).

    ## 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](https://docs.sysdig.com/en/manage-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](https://docs.sysdig.com/en/docs/administration/administration-settings/notifications-management/set-up-notification-channels/#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](https://docs.sysdig.com/en/manage-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](https://docs.sysdig.com/en/docs/administration/administration-settings/notifications-management/set-up-notification-channels/#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.
  </Tab>

  <Tab title="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](https://docs.sysdig.com/en/notification-trouble).

    ## Prerequisites

    * Sysdig Agent version 11.0.0 or greater.
    * Kubernetes audit logging. See [Kubernetes Audit Logging](https://docs.sysdig.com/en/k8s-audit-log).

    ## 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](https://docs.sysdig.com/en/manage-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](https://docs.sysdig.com/en/docs/administration/administration-settings/notifications-management/set-up-notification-channels/#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](https://docs.sysdig.com/en/manage-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](https://docs.sysdig.com/en/docs/administration/administration-settings/notifications-management/set-up-notification-channels/#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 **List Matching**.
    3. You can edit a managed policy, duplicate it to create a custom policy, or click **+ Add Policy**, choose **Kubernetes Audit** to configure it from scratch.
  </Tab>
</Tabs>