Thank you for your feedback.
Form temporarily unavailable. Please try again or contact to submit your comments.

Vulnerability groups and group rules overview

Log in to subscribe to topics and get notified when content changes.

Vulnerability groups and group rules overview

You can configure vulnerability groups (VG) to help analysts and remediation specialists organize vulnerable items (VI) and analyze them in bulk. The criteria by which groups are formed is configured so that you do not have to manually assign vulnerable items into groups. Using vulnerability groups, you can monitor progress and drive the remediation process more efficiently.

Understanding vulnerability groups

Vulnerability groups represent a set of vulnerable items to remediate. Grouping vulnerable items has many advantages. You can move vulnerable items through the remediation states, mark them under investigation, defer them, mark them resolved in bulk by using groups. You can create conditions to automatically group all items with specified vulnerabilities, departments, locations, and any other data related to the vulnerable item. Vulnerable items can belong to more than one vulnerability group giving you the flexibility to actively work with one group and monitor another. It all depends on your organizational needs. For example, you could group by department, and also create a group containing all currently exploitable vulnerabilities.

Vulnerability groups are created as follows.
  • Manually, using one of three options, to add vulnerable items to the group.
    • Add vulnerable items to the group by hand.
    • Use a Condition filter that automatically adds vulnerable items to the vulnerability group.
    • Use a Filter group that automatically adds vulnerable items to the vulnerability group.
    Note: Manually added vulnerable items are not automatically removed from vulnerability groups by vulnerability group rules or group conditions.
  • Automatically, using vulnerability group rules (VGR). This option is the easiest option, once configured, vulnerability group rules create all desired vulnerability groups.

From a vulnerability group, the group of vulnerable items may be assigned to a user, deferred until later, used to create a Change Request, and so on.

Starting with Vulnerability Response v9.0, create emergency, standard, and normal change requests directly that contain pre-populated information imported directly from vulnerability groups with Change management for Vulnerability Response.

When it is determined that a new vulnerable item can be added to a group, the vulnerability item is included in the Associated Vulnerable Items list of the vulnerability group. Conversely, the vulnerability group appears in the Associated Vulnerability Group list of Vulnerable Items.

When updating the state of a vulnerability group, associated vulnerable items can have their state updated to match this vulnerability group. See Vulnerability group and vulnerable item states for more information on state changes.

You can create security incidents and change requests from vulnerability groups, as needed.

Refreshing vulnerable items automatically

Note: Vulnerable item refresh automation applies only to groups created using the condition filter or filter group. Automation does not apply to VIs that were added manually or created using vulnerability group rules (VGRs).

When the Automatically refresh vulnerable items check box is selected, new VIs matching the vulnerability group filter criteria are automatically added to the group. Vulnerable items in the group that no longer match the filter criteria are automatically removed from the group.

By default, when the group leaves the Open state, the check box is cleared. If you want vulnerable items to continue being added to the group, regardless of state, disable the Set auto refresh vulnerable items business rule.

You can select the check box again manually from the Under Investigation state. Automatically refresh vulnerable items is not disabled when the group moves into the Awaiting Implementation state. Once in the Awaiting Implementation state, no new vulnerable items can be added to the existing group, nor can existing vulnerable items be removed from the group.
Note: When a group is created manually, and VIs are added using the Condition filter or Filter Group, the check box is unchecked. You have the choice to select the box or not.

Refreshing vulnerable items manually

For manually created vulnerability groups with a Filter Group or Condition filter, when you click the Refresh associated vulnerable items related link on the Vulnerability Group page, any vulnerable items that match the filter criteria are added. Items no longer matching the criteria are removed. This action allows an immediate update of the list of vulnerable items and is used whether the Automatically refresh vulnerable item check box is selected or not.

Manually created vulnerability groups using Condition or Filter Group filter types are refreshed once an hour.

Understanding vulnerability group rules

Vulnerability groups rules allow you to define how vulnerable items are automatically grouped and assigned. A default rule, Vulnerability, is included in the base system grouping vulnerable items based on its vulnerability. However, you can group by any other set of values in columns accessible from the VI. These values could include configuration item (CI) support group, vulnerability severity, and, so on. You can use up to five keys and any number of conditions. You can automate group assignment, as well. See Create or edit vulnerability group rules and Filtering within Vulnerability Response for more information.
Note: Version 9.0: To make Rapid7 InsightVM asset tags available for use in the Condition filter for Vulnerability Group Rules, you must run the Rapid7 InsightVM Asset List integration before the other Rapid7 InsightVM integrations.

For example, you can group your vulnerable items by the cost center of the vulnerable CI, or by the attack vector of the vulnerability. You can have one group rule for low severity vulnerabilities or low risk CIs. You can have another group rule for critical servers, and vulnerabilities with exploits — vulnerable items that expose the company to more risk.

A different set of rules can be used for vulnerable items that expose the company to more risk. The VGR name is appended to the vulnerability group key values to make the short description of the new vulnerability group. See Create a Vulnerability Response group for more information on available fields.

Example of a vulnerability group rule showing the Group By entries

When a new vulnerable item is created, imported, or reopened after being closed, the vulnerability rules are evaluated against it. A VI is only evaluated once, unless it is reopened after being closed.

The following process is used for each new or reopened VI:
  • For each vulnerability group rule, the VI is compared to the VGR filter.
  • For each rule where the VGR condition matches, the rule pulls the data from the group key columns on the VI. It builds a group name and key. In this case, High Risk: QID-32342: Accounting: Joan Doe – VGR Name, vulnerability name, department, and manager). The rule checks to see if there is a matching Open vulnerability group that is assigned to the same assignment group as the VI.

    If the group is found, the VI is added to the existing group in the Open state.

  • If no group in the Open state is found, the rule creates a High Risk: QID-32342: Accounting: Pat Doe group, assigns it to the same assignment group as the VI, and places the VI in it.

More than one VGR can be defined, to group different kinds of vulnerabilities. Since each vulnerability is compared with the VGR conditions before putting it in a group, too many VGRs may have a performance impact.

By default, VGRs use the assignment group set by the Assignment Rules on the vulnerable item when grouping the items, and assigns the vulnerability group to match the vulnerable items. If you want different behavior, see Advanced vulnerability group assignment.

As part of the Vulnerability group rule, the assignment of these vulnerability groups is controlled by the rules in the Assignment Rules module. For more information on assignment rules, see Vulnerability Response assignment rules overview.

Advanced vulnerability group assignment

If you want the VGR to create groups and assign them differently, use the Advanced Assignment view in VGRs to display your assignment options. See Create or edit vulnerability group rules for more information on vulnerability group rule options.

When a vulnerability group assignment is made or changed, the Assignment group and the Assigned to fields roll down to all vulnerable items, except for those where the vulnerable item has a different assignment group than the VG.

There are three different ways to assign the groups by:
  1. Assignment by: This option allows you to select any of the following:
    • Assignment group: This option allows you to choose any platform group.

      For example, you can define:

      Assignment rule 1 as: Vulnerability Summary contains Java, Assignment group: IT Security, Order: 100.

      Assignment rule 2 as: Vulnerability Summary contains Microsoft Service Pack, Assignment group: IT Operations, Order: 200.

    • Assignment group field: This option allows you to choose any assignment group field available using the cmdb_ci table. By default you see the following three group fields:
      1. Configuration Item: Approval Group
      2. Configuration Item: Assignment Group
      3. Configuration Item: Support Group
    • Assignment Rules: This option uses pre-defined Assignment Rules. See Vulnerability Response assignment rules overview for more information.

    These assignments are used automatically for this group on the next import.