Managing Application Protection Policies

Scenario

Application protection policies can be added, edited, and deleted in the following scenarios:

• Adding a Policy: HSS provides default policies. For details about the rules they include, see Default Policies. The default policies only support detection and cannot block threats. To customize the policy for a server or enable blocking, you can add a protection policy and customize the rules and configurations in the policy. Up to 20 custom policies are allowed.
• Editing a Policy: You can edit a custom protection policy.
• Deleting a Policy: You can delete a custom protection policy that is not associated with any server.

Adding a Policy

1. Log in to the HSS console.
2. Click in the upper left corner and select a region or project.
3. In the navigation pane on the left, choose Prevention > Application Protection.
4. In the upper right corner of the page, click Policies.
5. Click Add Policy.
6. Configure a custom policy. For details, see Table 1.
   Figure 1 Adding a policy
   

   Table 1 Parameters for adding a policy

   Parameter		Description
   Policy Name		User-defined policy name.
   Description (Optional)		Description of the policy.
   OS		OS of the servers that the protection policy applies to.
   Protection Policy	Detection Rule ID	Unique ID of a rule. To enable a rule, select the check box next to the ID.
   	Action	Action taken when an anomaly is detected. Alarm: Only an alarm is generated and the anomaly is recorded. Alarm and block: An alarm is generated, the anomaly is recorded, and the abnormal behavior is blocked. NOTE: Alarm and block is in the open beta test (OBT) phase. To use this function, submit a service ticket to enable it. When you create a policy, its action can only be set to Alarm. You are advised to use this action for at least seven days. Then, you can edit the policy and change its action to Alarm and block. For details about how to edit a policy, see Editing a Policy. If false alarms are generated during application protection, you can configure the whitelist to reduce false alarms.
   	Description	Description of the checked objects and action of a rule.
   	Whitelist Items	Number of whitelisted items.
   	Configure	The rules XSS, WebShellUpload, FileDirAccess and ZeroDayDetect support user-defined blacklist and whitelist. Click Configure. In the displayed dialog box, configure the rule as needed. XSS: User-defined XSS blocking rules. Example: xml;doctype;xmlns;import;entity WebShellUpload: User-defined file name extension blacklist. Example: .jspx;.jsp;.jar;.phtml;.asp;.php;.ascx;.ashx;.cer FileDirAccess: User-defined path blacklist. Example: /etc/passwd;/etc/shadow;/etc/gshadow; zeroDayDetect: User-defined zero-day whitelist stack.
   	Configure Whitelist	To ensure your services are not affected by false alarms and misblocking, you are advised to configure a whitelist while configuring a protection policy. A detection rule supports up to 25 whitelist conditions. The relationship between them is OR. If an event meets any of the whitelist conditions, no alarm or blocking will be triggered for it. Click Configure Whitelist. In the dialog box that is displayed, click Add Condition and configure Whitelist Object, Logic, and Matched Content. Whitelist Object: Select the type of rules to be whitelisted. The options are as follows: Request URL: Whitelist a specific request URL. Attack payload: Whitelist specific content. Attack probe: Whitelists specific attack detection behaviors. Feature rule: Whitelist specific security rules. Logic: Select a whitelist matching logic. The options are as follows: Equals: No alarms will be triggered if the event content is the same as the specified content. Does not equal: No alarms will be triggered if the event content is different from the specified content. Contains: No alarms will be triggered if the event content contains the specified content. Does not contain: No alarms will be triggered if the event content does not contain the specified content. Starts with: No alarms will be triggered if the event content starts with the specified content. Ends with: No alarms will be triggered if the event content ends with the specified content. Matched Content: Enter the content to be added to the whitelist. The content must match the type selected in Whitelist Object.

7. After the policy is configured, click OK.

Editing a Policy

1. Log in to the HSS console.
2. Click in the upper left corner and select a region or project.
3. In the navigation pane on the left, choose Prevention > Application Protection.
4. In the upper right corner of the page, click Policies.
5. In the Operation column of a policy, click Edit to go to the Edit Policy page.
6. Modify the policy. For details, see Table 2.
   Figure 2 Editing a policy
   

   Table 2 Parameters for editing a policy

   Parameter		Description
   Policy Name		User-defined policy name.
   Description (Optional)		Description of the policy.
   OS		This parameter cannot be modified.
   Protection Policy	Detection Rule ID	Unique ID of a rule. To enable a rule, select the check box next to the ID.
   	Action	Action taken when an anomaly is detected. Alarm: Only an alarm is generated and the anomaly is recorded. Alarm and block: An alarm is generated, the anomaly is recorded, and the abnormal behavior is blocked. NOTE: Alarm and block is in the open beta test (OBT) phase. To use this function, submit a service ticket to enable it. For the first seven days after a policy is created, its actions are limited to Alarm. You can change to Alarm and block after it runs for seven days. When changing the action to Alarm and block, configure the whitelist to prevent false positives affecting your services.
   	Description	Description of the checked objects and action of a rule.
   	Whitelist Items	Number of whitelisted items.
   	Configure	The rules XSS, WebShellUpload, FileDirAccess and ZeroDayDetect support user-defined blacklist and whitelist. Click Configure. In the displayed dialog box, configure the rule as needed. XSS: User-defined XSS blocking rules. Example: xml;doctype;xmlns;import;entity WebShellUpload: User-defined file name extension blacklist. Example: .jspx;.jsp;.jar;.phtml;.asp;.php;.ascx;.ashx;.cer FileDirAccess: User-defined path blacklist. Example: /etc/passwd;/etc/shadow;/etc/gshadow; zeroDayDetect: User-defined zero-day whitelist stack.
   	Configure Whitelist	To ensure your services are not affected by false alarms and misblocking, you are advised to configure a whitelist while configuring a protection policy. A detection rule supports up to 25 whitelist conditions. The relationship between them is OR. If an event meets any of the whitelist conditions, no alarm or blocking will be triggered for it. Click Configure Whitelist. In the dialog box that is displayed, click Add Condition and configure Whitelist Object, Logic, and Matched Content. Whitelist Object: Select the type of rules to be whitelisted. The options are as follows: Request URL: Whitelist a specific request URL. Attack payload: Whitelist specific content. Attack probe: Whitelists specific attack detection behaviors. Feature rule: Whitelist specific security rules. Logic: Select a whitelist matching logic. The options are as follows: Equals: No alarms will be triggered if the event content is the same as the specified content. Does not equal: No alarms will be triggered if the event content is different from the specified content. Contains: No alarms will be triggered if the event content contains the specified content. Does not contain: No alarms will be triggered if the event content does not contain the specified content. Starts with: No alarms will be triggered if the event content starts with the specified content. Ends with: No alarms will be triggered if the event content ends with the specified content. Matched Content: Enter the content to be added to the whitelist. The content must match the type selected in Whitelist Object.

7. Click OK.

Deleting a Policy

1. Log in to the HSS console.
2. Click in the upper left corner and select a region or project.
3. In the navigation pane on the left, choose Prevention > Application Protection.
4. In the upper right corner of the page, click Policies.
5. Locate a target policy and click Delete in the Operation column. The Delete Policy dialog box is displayed.
6. Check the policy information. If the information is correct, enter DELETE and click OK.

   If the policy is no longer displayed in the policy list, it has been deleted.