Malware Control Policy

Prerequisites

• Sysdig Secure SaaS
• Kernel 5.x+
• Agent 13.0.1+
• Review Set Up Notification Channels
• Agent version 13.6.0 is required to use Regex.

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.

For agent configuration options, see Configure Malware Control.

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: Toggle to enable or disable the policy. The policy must be enabled to generates events.

Severity: Choose the appropriate severity level as you would like to see it in the Runtime Policies UI.

• The available severities are 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: Choose the scope to which the policy will apply. You can select Hosts Only, Containers Only, or define a Custom Scope.

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

Additional hashes: (Optional) Enter hashes of binaries in a SHA-256 format to have them evaluated by the policy. Comma-separate your entries.

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

Use YARA rules: Toggle to enable or disable detection with YARA rules provided by Sysdig’s Threat Research Teams. YARA rules help to classify and identify malware samples by creating descriptions of malware families based on textual or binary patterns. Some malware add random bytes to the generated binary to generate unique hashes. This allows them to bypass detection based on hash-matching. YARA rules can detect such malware by inspecting the binary for known sequence of bytes. Detection with YARA rules is enabled by default.

Exceptions

Hash exceptions: (Optional) Enter hashes in a SHA-256 format for which you do not want the policy to trigger an event. Comma-separate your entries.

File Based Exceptions

The File Based Exceptions feature allows you to exclude specific files or file paths from malware scanning, helping reduce false positives and optimize scanning performance.

Use Regex for exceptions: Toggle to enable or disable pattern matching using regular expressions. When disabled, the system uses exact string matching for file paths.

• 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 the the regex pattern defined.
• To learn more about regex syntax, see Regular Expression Syntax.
• Agent version 13.6.0 or above is required for this feature.

Exceptions: Enter complete file paths that should be excluded from malware scanning. For example: /usr/bin/test, /usr/local/scan, /opt/trusted/*. Multiple paths can be specified using comma separation.

Best practices include:

• Use specific paths rather than broad patterns to maintain security.
• Document all exceptions for audit purposes.
• Regularly review excluded paths to ensure they remain necessary.

Actions

Prevent: Enable the toggle to have Sysdig Secure prevent the execution of detected binaries. 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.

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