Create custom defense rules to whitelist activities for false positive alerts - Security Center

Security Center's Malicious Behavior Defense feature protects your hosts by detecting and blocking suspicious system behaviors. You can create custom allowlist rules to exclude known-safe operations from detection, reducing false positive alerts while maintaining security visibility. This topic explains how to analyze security alerts and configure effective allow list rules for your specific environment.

Why use allowlist rules

Allowlist rules offer several advantages over disabling entire detection categories:

Granular control: Create custom filters to fine-tune which behaviors are excluded from alerting.
Maintain visibility: Allowlisted behaviors are still monitored—detection still occurs in the background, but alerts are suppressed. This preserves audit trails and lets you re-evaluate rules later.
Business continuity: Prevent legitimate operations (O&M scripts, inter-service communication, development tools) from triggering false alarms that disrupt workflows.

When to use allowlist rules:

Security Center flags a trusted internal tool or script as malicious
A legitimate cross-service network connection triggers repeated alerts
Development or testing activities (e.g., debugging tools, test frameworks) generate noise
You need temporary exclusions during maintenance windows

When NOT to use allowlist rules:

The detected behavior is actually suspicious but comes from a trusted source (consider improving security posture instead)
You want to completely disable a detection type (use feature settings instead—but understand you'll lose visibility)

How it works

The allowlist rule feature provides a user-defined policy layer above Security Center's detection engine. Here's the evaluation workflow:

Behavior monitoring: The Security Center agent continuously monitors system activities (process creation, network connections, file operations, registry changes).
Rule matching (evaluation order):
Decision and execution:
- If a behavior matches an allowlist rule: Operation is allowed, no alert generated. Detection still occurs in the background (audit trail preserved).
Continuous optimization: Refine rules based on new alerts to improve detection accuracy over time.

Note

When multiple allowlist rules match the same behavior, Security Center applies all matching rules (not just the first match). This means overlapping rules don't conflict—each rule independently suppresses alerts for its specified conditions.

Alert status flow:

Behavior detected: The Security Center agent detects a system behavior (e.g., process execution, network connection).
Check allowlist rules: The agent checks if the behavior matches any user-defined allowlist rules.
Decision:
- If match found: Alert is suppressed (no alert generated). The behavior is allowed, and audit trails are preserved for compliance.
- If no match: The behavior is checked against built-in detection rules. If it matches a malicious pattern, an alert is generated with status "Active" and the behavior is blocked or monitored based on your Protection Mode settings.

Before you begin

Ensure the following requirements are met:

Edition requirements:
- Subscription (recommended): You must have purchased Security Center Advanced Edition, Enterprise Edition, or Ultimate Edition. After purchase, ensure your server protection edition is set to the purchased edition level.
  
  Note
  If your server protection edition is set to a lower level than your purchased edition, the Malicious Behavior Defense feature will not be available. Go to System Settings > Feature Settings to verify your protection edition matches your purchased edition.
- Pay-as-you-go: You must enable Vulnerability Fixing, Security Configuration Assessment, or Container Intrusion Detection features with protection level set to Malicious Behavior Defense or higher.
Agent: Security Center agent is installed on target hosts and running normally.
Alert: At least one false positive alert exists in the Malicious Behavior Defense console (to extract rule parameters from alert details).

Procedure

Step 1: Analyze an alert and select a rule type

To create an effective rule, first analyze the details of the false positive alert.

Log on to the Security Center console.
In the left-side navigation pane, choose Detection and Response > Alert. In the upper-left corner of the console, select the region where the asset you want to protect is located: Chinese Mainland or Outside Chinese Mainland.

Note
If you have activated the Agentic SOC service, the navigation path changes to Agentic SOC > Manage > Alert.
On the Alert page, on the CWPP tab, click Precise Defense to view all alerts for threats that were automatically blocked by the Malicious Behavior Defense feature.
Choose the most appropriate rule type based on the key fields in the alert details.

Recommended rule type	Key alert fields	Scenario
Process Hash	Malicious File MD5	Whitelist the execution of a specific file identified by its MD5 hash.
Command Line	Process Path, Command line	Whitelist a specific process that is executed with specific command-line arguments.
Process Network	Process Path of Network Communication, IP Address, Port	Whitelist a network connection that is initiated by a specific process to a specific IP address and port.
File Read and Write	File Path	Whitelist a read or write operation that is performed by a specific process on a specific file or directory.
Operation on Registry	Registry path, Registry value	Whitelist an operation that is performed by a specific process on a specific registry key. This rule type applies only to Windows.
Dynamic-link Library Loading	Hijacked process path, Malicious so file path	Whitelist the loading of a specific dynamic-link library (.so or .dll) by a specific process.
File Renaming	Decoy directory file protection	Whitelist a file rename operation that is performed by a specific process. This rule type applies only to Windows.

Step 2: Configure a rule

Go to Security Center console > Protection Settings > Host Protection > Host-specific Rule Management. In the upper-left corner of the page, select the region where your asset is located: Chinese Mainland or Outside Chinese Mainland.
On the Malicious Behavior Defense tab, click the Custom Defense Rule sub-tab, and then click Create Rule.
In the Create Rule panel, complete the basic settings as described below:
- Rule Name: We recommend that you name the rule based on the alert it addresses. Example: Process Startup Whitelist.
- Rule Type: Select the appropriate rule type based on the analysis in Step 1.
- Action: Select Add to Whitelist.

Configure the parameters for the selected rule type:

Note

For more information about the rule syntax, see Appendix: Rule syntax.

Process Hash

Parameter	Description
Process MD5	Enter the value of the Malicious File MD5 field from the alert details. Example: `d2f295a89555579c39a0507e96XXXXXX`.

Command Line

Parameter	Description
Process Path	Enter the path from the Process of executing command field in the alert details. Example: `*/pkill`.
Command Line	Enter a characteristic string from the Command in execution field in the alert details. Example: `AliYunDun`.

Process Network

Parameter	Description
Process Path	Enter the path from the Process Path of Network Communication field in the alert details. Example: `*/powershell.exe`.
Command Line	Enter a characteristic string from the Process Commands For Network Communication field in the alert details. Example: `dAByAhADQAKAHsADQAkACXXXXXX`.
IP Address	Enter the value of the IP Address field from the alert details. Example: `45.117.XX.XX`.
Port	Enter the value of the Port field from the alert details. Example: `14XX`.

File Read and Write

Parameter	Description
Process Path	Enter the path from the Process of executing command field in the alert details. Example: `*/java`.
Command Line	Enter a characteristic string from the Command in execution field in the alert details. Example: `weaver`.
File Path	Enter the path from the Target document of the read and write field in the alert details. Example: `*/console_login.jsp`

Operation on Registry

Parameter	Description
Process Path	Enter the path from the Process of executing command field in the alert details. Example: `*/iexplore.exe`.
Command Line	Enter a characteristic string from the Command in execution field in the alert details. Example: `iexplore.exe`.
Registry Key	Enter a characteristic string from the Registry path field in the alert details. Example: `currentversion`.
Registry Value	Enter a characteristic string from the Registry value field in the alert details. Example: `svch0st.exe`.

Dynamic-link Library Loading

Parameter	Description
Process Path	Enter the path from the Hijacked process path field in the alert details. Example: `/python`.
Command Line	Enter a characteristic string from the Hijacked process command field in the alert details. Example: `python`.
File Path	Enter the path from the Malicious so file path field in the alert details. Example: `/usr/local/lib/kswapd0.so`.

File Renaming

Parameter	Description
Process Path	Enter the path from the Process of executing command field in the alert details. Example: `*/cdgregedit.exe`.
Command Line	Enter a characteristic string from the Command in execution field in the alert details. Example: `CDGRegedit.exe`.
File Path	Enter the path from the Target document of the read and write field in the alert details. Example: `c:/programdata/hipsdata/private/*`.
New File Path	Enter the path from the Target document of the read and write field in the alert details. Example: `c:/programdata/hipsdata/private/*`.

In the Select Asset panel, select the assets to which you want to apply the rule, and then click Complete.

Note
A new custom rule is enabled by default. You can edit the rule and manage the servers where it is applied.

Step 3: Validate and troubleshoot rules

Validation method: Monitor the host where the rule is applied to ensure no new, identical alerts are generated.
Troubleshooting: If the rule does not take effect and alerts are still being generated, follow these steps to troubleshoot:
1. Check asset scope: In the rule list, ensure the target host is within the rule's scope.
2. Verify matching conditions: Carefully compare the details of the new alert with the rule's parameters. Ensure that all strings, including paths and filenames, match exactly (case-sensitivity, spaces, etc.). Copy the field values directly from the alert details into the rule configuration.
3. Simplify the rule for testing: Try creating a rule with broader conditions, such as using only the Process Path, to test its effectiveness. If the broader rule works, the issue is likely the combination of conditions or a specific field value in the original rule. Gradually add conditions back to pinpoint the problem.

Appendix: Rule syntax

Rule fields support wildcards and logical operators for flexible behavior matching.

Wildcards

The asterisk (*) is the universal wildcard—it matches any sequence of characters (including zero characters).

Pattern	Matches	Example
`keyword`	Any string containing "keyword"	`AliYunDun` matches `/usr/local/AliYunDun/aegis_client`
`keyword*`	Any string starting with "keyword"	`python*` matches `python3`, `python3.8`
`*keyword`	Any string ending with "keyword"	`*.log` matches `/var/log/app.log`, `/tmp/debug.log`
`*`	Any string (universal match)	Use cautiously—may create overly broad rules

Logical operators

Combine multiple conditions for precise matching. Use parentheses to group expressions when needed.

Operator	Symbol	Behavior	Example
AND	`&`	All conditions must match	`python&script.py` - must contain both "python" and "script.py"
OR	`\|`	At least one condition must match	`/usr/bin/python \| /usr/bin/python3` - matches either path
NOT	`!`	Exclude a pattern	`python&!test` - contains "python" but not "test"

Important syntax rules:

&!pattern is supported (AND NOT) - Example: *process*&!*debug*
|!pattern is NOT supported - use !pattern1&!pattern2 instead
Avoid overly broad exclusion rules that weaken security

Examples:

Scenario	Syntax	Explanation
Allow Python processes except test scripts	`python&!test&!pytest`	Must contain "python", must not contain "test" or "pytest"
Allow processes from /usr/bin or /usr/local/bin	`/usr/bin/* \| /usr/local/bin/*`	Matches paths starting with either prefix
Allow Java processes with specific configs	`java&(prod \| production)`	Java process with either "prod" or "production" in command line

Best practices:

Start with simple patterns, add complexity only if needed
Test rules in a non-production environment first
Document your rule logic (use descriptive rule names)
Avoid double negatives (!(!pattern)) - rewrite for clarity

Glossary

Term	Definition	Related terms
Allowlist rule	A user-defined rule that excludes specific behaviors from alerting. Industry-standard term (replaces deprecated "whitelist").	Suppression rule (AWS GuardDuty, Azure Sentinel), Mute rule (GCP Security Command Center)
Alert	A security finding that indicates suspicious or malicious behavior detected by Security Center.	Finding (AWS/GCP term for detection result)
False positive	An alert triggered by legitimate behavior incorrectly identified as malicious.	False alarm, benign detection
Malicious Behavior Defense	A Security Center feature that monitors host behaviors and blocks suspicious activities in real-time.	Threat detection (industry term), behavioral analysis
Rule matching	The process of comparing captured behaviors against configured rule criteria to determine if an allowlist rule applies. Rule evaluation refers to the internal engine logic that determines which detection rules fire.	Rule evaluation (internal engine perspective)