Grouping Rules

With grouping rules, you can group individual vulnerability incidents in a group based on different criteria. This reduces the number of incidents, making the remediation easier.

You must have one-to-one detection rules configured in Qualys Core to define the grouping rules. The grouping rules group the incidents from the incident table based on the defined rules.

Perform the following steps to define Grouping Rules:

1. Go to Configuration > Detection Event Rules > Grouping Rules to view the grouping rules that are available by default. However, you can update an existing rule or create a new rule.

   

   You can use the Copy this Rule option to clone the detection rule, modify the required field, and save the rule with a new name. See Clone a detection rule.

2. Review the existing values in the fields and modify them as required:

   

   • Source table - Select the Incident table, where the incidents are created when the one-to-one detection rules are triggered.

   • Destination table - Select Incident. This is where the group incident are created when this rule is triggered.

     To create a change request, select Change Request in the Destination table.

     The Trigger Criteria tab defines the condition in which the detection event rule is triggered.

     

   • Order - Provide the number that indicates the order of priority for running this detection event rule. The value in the Order field is a relative value, and the detection event rules are executed in ascending order, from lowest to highest. The order assigned to a rule helps decide the priority when multiple rules exist for the same table.

   • Stop processing - Select this check box to stop processing the rules ordered after this rule once the detection conditions are met.
     Grouping defines how grouping is performed.

     

   • Group by - Select which field from the Source table should be used as a criteria for grouping the incidents. You can select a criteria for grouping from the list

     

     You can define up to 4 criteria for grouping.

     For details on how the incident grouping works, see Example of Grouping.

     Once you select a value in the Group by field, you cannot edit the value in the field. To change value in the Group by field, click Clear Group By Fields. This clears values in the Group by field. The Clear Group By Fields option is available only if you have the required privileges. 

     You can also define when the incident grouping should be stopped. For example, the following image displays that a incident should not be included in a group if its state matches any of the selected values.

     

     The Assignment tab defines how the assignment groups are assigned.

     

     If the Assignment group based on ServiceNow Assignment Rules is selected, the incidents are assigned based on the rules set in the Configure Assignment Rules.

     If the Assignment based on Detection Event Rule is selected, you can select a value in the Assignment Group field. This assignment group is applicable only for this rule.

     If the Assignment based on Group by field is selected, you can select a value in the Assignment Group field. This assignment group will be applicable only for this rule.

3. Click Submit to create a new detection event grouping rule.

Detection Event Field Maps

Once the detection event rule is created, add field mappings.

Click your created detection event group rule, and go to Detection event field maps.

You must add the following field mappings:

Example of Grouping

This example presents how the Group by feature works. The grouping criteria are defined as

• Group by: Configuration Item.Support Group
• Then group by: Configuration Item.Business Criticality
• Then group by: Configuration Item.Operating System

There are 12 VMDR incidents with unique Configuration Item categorized as:

• Configuration Item support groups: Group A, Group B, and Group C
• Configuration Items with criticality: High and Low
• Operating Systems: Windows Server 2008 R2, RedHat, and Windows 11 22h02

The following scenarios explain how the incident grouping is created. This explains how the incident groups are created in this example.

Support groups first group the incidents as it is the first grouping criteria.

Scenario 1: Support Group A

Out of 12 VMDR incidents, the following four incidents belong to Configuration Item Group A.

VMDRTSK0001 CI.Support Group = Support Group A, AND a Business Criticality of High, AND a CI Operating System of Windows Server 2008 R2

VMDRTSK0002 CI.Support Group = Support Group A, AND a Business Criticality of Low, AND a CI Operating System of Windows Server 2008 R2

VMDRTSK0003 CI.Support Group = Support Group A, AND a Business Criticality of High, AND a CI Operating System of Windows Server 2008 R2

VMDRTSK0004 CI.Support Group = Support Group A, AND a Business Criticality of High, AND a CI Operating System of RedHat

In this case, the following incident groups will be created:

 

Scenario 2: Support Group B

Out of remaining incidents, the following two incidents belong to Configuration Item Support Group B.

VMDRTSK0005 CI.Support Group = Support Group B, AND a Business Criticality of Low, AND a CI Operating System: RedHat

VMDRTSK0006 CI.Support Group = Support Group B, AND a Business Criticality of Low, AND a CI Operating System: RedHat

In this case, the following incident group will be created:

 

Scenario 3: Support Group C

Remaining 6 incidents belong to Configuration Item support group C.

VMDRTSK0007 CI.Support Group = Support Group C, AND a Business Criticality of High, AND a CI Operating System of Windows 11 22h02

VMDRTSK0008 CI.Support Group = Support Group C, AND a Business Criticality of Low, AND a CI Operating System of Windows Server 2008 R2

VMDRTSK0009 CI.Support Group = Support Group C, AND a Business Criticality of High, AND a CI Operating System of Windows Server 2008 R2

VMDRTSK0010 CI.Support Group = Support Group C, AND a Business Criticality of Low, AND a CI Operating System of Windows Server 2008 R2

VMDRTSK0011 CI.Support Group = Support Group C, AND a Business Criticality of Low, AND a CI Operating System of RedHat

VMDRTSK0012 CI.Support Group = Support Group C, AND a Business Criticality of High, AND a CI Operating System of Windows 11 22h02

In this case, the following incident groups will be created:

Reprocess the detection event rules

To import new vulnerabilities, you need to process one-to-one detection rules manually, and subsequently, the grouping rules must also be processed again.

To manually reprocess the grouping and one-to-one rules, click Reprocess Detection Event in the detection event rule. 

The Reprocess Detection Event option is available only if you have the required privileges. If you cannot view this option, contact your ServiceNow administrator.

Clone a detection rule

You can create a clone of a grouping rule or one-to-one rule. Click Copy this Rule to create a copy of the rule with all the defined settings along with detection event field maps.

You can provide a new name or save the rule with the default name. In this case, the prefix COPY is added to the existing name.

 

Related Topic

Configure Assignment Rules