Malware Control Policy

When a Malware Control policy is created, depending on the options selected, Sysdig Agent can use a managed data bank to monitor executions in a container/on the node for any malware. When a malicious binary is detected, the agent generates an event and can optionally block the execution from starting. This feature is in Technical Preview

Prerequisites

Configure the Sysdig Agent

Malware Control, also called Malware Detection and Prevention, is enabled by default.

You can optionally configure the dragent.yaml file to:

  • Disable Malware Control globally.
  • Enable Malware Control for the underlying host node.

See Agent Configuration for Sysdig Secure for details.

Create a Malware Policy

  1. Log in to Sysdig Secure.

  2. Select Policies > Threat Detection > Runtime Policies to display the Runtime Policies page.

  3. Click +Add Policy and select Malware policy type.

  4. Configure the policy as given in Configure a Malware Policy.

  5. Click Save.

Configure a Malware Policy

Basic Parameters

Name: Enter a unique 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 provide a value here, a View Runbook option will appear in the corresponding event with a link to your Runbook.

Detect

Use Known Hashes: Sysdig maintains a list of known malware hashes which it checks against the executing binary. This option is enabled by default.

Ignore Hashes: If desired, enter known malware hashes for which you do not want the policy to trigger an event. Comma-separate your entries.

Additional Hashes: If desired, add known malware hashes to have them evaluated by the policy. Comma-separate your entries.

Actions

Prevent: Enable the toggle to have Sysdig Secure prevent any detected malware and binaries with known hashes from executing. This option is disabled by default. When Prevent is disabled, malware detection triggers an event and any configured notifications.

Containers: Choose which action the policy should take when the event occurs in a container. Options include:

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

For a detailed breakdown and use cases, see Container Actions.

Capture: Create a capture when the policy triggers.

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

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

Container Actions

In Threat Detection Policies, Kill, Stop and Pause are different response actions, each with distinct impacts on workloads and use cases:

Kill: Killing the container immediately terminates it, removing it from the cluster. Kubernetes will typically attempt to restart the container based on its configuration. This can stop a malicious activity quickly, but can result in data loss (in stateful applications) and service disruption. It is the best choice for severe and urgent threats.

Stop: Stopping a container shuts down its processes and removes it from the scheduling pool, but unlike killing, it allows for a more graceful shutdown of services. Stopping a container might require manual intervention to bring it back online. It’s the best choice for stateful applications.

Pause: Pausing a container suspends its execution, freezing its processes and preserving its runtime state. The container remains in the cluster but is temporarily halted. It’s ideal for forensic analysis and limiting disruption, but may result in higher resource consumption and prolonged risk due to lack of resolution.

Summary

ActionImpact on ContainerUse CaseDrawbacks
KillImmediate terminationHigh risk threat. Rapid mitigation.Loss of forensic data. Possible service disruption.
StopGraceful shutdownControlled threat removal. Preserving service dependencies.Residual risk. Manual restart of container needed.
PauseExecution halted, state preserved.Stealthy containment. Preserves data for analysis.Continued resource use. May prolong risk.