Decommissioned Assets: Filter Configuration for Playbooks
Summary: Leveraging Playbook rules to automate migrating decommissioned assets into a Decom group.
Building on the concepts of addressing asset decommissioning scenarios described in another RiskSense Knowledge Base article, this walkthrough describes one option for configuring platform filters and Playbook rules to handle applications, hosts, and their vulnerabilities identified in older scans but are no longer present in your environment.
This walkthrough will make the following assumptions, so any group or filter configuration should be adjusted to align with your RiskSense client data:
The RiskSense client contains four groups: Default Group, Decom, Development, and External.
Criteria for determining whether an application or host has been removed from the scanned environment is the time since a scanner last fingerprinted the asset.
The client prefers the user of ‘Discovered On’ dates rather than ‘Ingested On’ for identifying assets' last fingerprint date.
Vulnerability scanning is conducted on a monthly cadence, so the automated identification and migration of decommissioned assets should be scheduled monthly as well, shortly after the monthly assessment is populated with new scan results.
Applications or hosts not appearing in scans over the past 180 days will be the threshold for determining whether an asset is considered ‘decommissioned.’
The first step in automating moving old or stale assets into the Decom group is to create and save filters within the Manage > Hosts or Manage > Applications list views. The RiskSense Playbooks feature will then leverage these saved filters to facilitate the migration of assets on a scheduled basis. This article focuses on decommissioning network hosts, but the same process can be leveraged for managing web application assets, as well.
Navigate to the Manage > Hosts view and select the top-most filter icon to launch the Active Filters dialog.
When creating filters for use with RiskSense Playbooks, give some forethought to the desired outcome. If the end result should be that hosts not picked up in scans of your environment over the past 180 days are to be migrated to only the Decom group, that result will provide insight into which RiskSense filters may be most effective. Given the assumptions made in the bullet points listed near the top of this article, the filters should be configured to identify hosts belonging to any existing group except for the Decom group and should not have been identified by a scanner in the past 180 days. The following three filters can be used to meet those requirements:
Group / is / one of / Default Group,Development,External
Group / is not / exactly / Decom
Last Discovered On / is not / last X days / 180
The first two filters are used to return all hosts that belong to all groups except the Decom group. This avoids forcing the Playbook feature to add assets already belonging to the Decom group to that same group each and every month. The Last Discovered On filter is then used to narrow the returned results down to just those assets belonging to the other three groups (Default Group, Development, and External) that have not been observed or fingerprinted by a scanner in the past 180 days. This is the set of assets to be moved into the Decom group. With those three filters in place, click the Save button near the top of the Active Filter dialog to capture and name the collection of filters for later use.
Because assets within RiskSense can be assigned to multiple groups, the playbook that leverages these filters will need to handle the addition of assets to the target Decom group and the removal of those assets from their original group(s). For this reason, a second set of filters should be created and saved so that a corresponding Playbook rule action can be configured for the cleanup of assets after being added to the Decom group. As the Playbook rule action for removing assets from groups will run after the first action of adding assets to the Decom group, that second saved filter set should be configured under the assumption that all relevant assets will now belong to both Decom and other groups:
Group / is / exactly / Decom
Group / is / one of / Default Group,Development,External
Now that the two sets of filters have been saved, the second step is to create and configure a RiskSense Playbook so that the process of dispositioning assets into a Decom group can be automated.
After navigating to the Automate > Playbooks view via the RiskSense toolbar menu, select the blue +Create New Playbook button near the top of the page. Next, provide a playbook name, description, and schedule the playbook run time and frequency.
After saving the new playbook, users will be taken back to the main Playbooks view. Select the name of the newly created playbook to open the Rule Creation dialog.
Select the +Create New Rule button to bring up the rule creation view, where the first rule can be named, described, and an action can be selected. In this case, the Add to Group action should be selected. Once the subject (Host, rather than Application, in this case) and the target group (Decom) are also specified, select either the Forward button or the Filter icon to proceed to the Filter Rule dialog.
Select the first filter saved during the earlier filter-creation step within the Manage > Hosts list view, then click the Forward button again.
The final Playbook Rule dialog provides options for configuring an email notification which can be delivered at the conclusion of the rule execution. Once the notification options are set, select the Submit button to be taken back to the +Create New Rule view. The same steps would then be followed to configure a second rule which leverages the second filter set saved in the Hosts list view for the purpose of removing the hosts from all groups except Decom.
At this point, the Playbook will contain one rule for adding assets to the Decom group and one for removing assets from all other groups. Please note the “Change Order” option in the image below. Rules within a playbook run sequentially. This is an important consideration as the second rule in this exercise (removing assets from all other existing groups) assumes that the first rule has already run and has added the assets in question to the Decom group.
Please also note the status of ‘Disabled’ from this screenshot. The final step in Playbook configuration is to click the blue ‘back’ arrow to navigate back to the main Playbooks list view, select the checkbox next to the newly created playbook, and use the Enable option within the Actions drop-down menu.
As described in the companion article on decommissioning assets, the use of a Decom group for the purpose of hiding old hosts, applications, and their vulnerabilities relies on RiskSense Groups’ function as a security boundary. If my user account is not assigned to the Decom group, the assets and vulnerabilities assigned to only that group will not appear in any list views, dashboards, reports, or have any impact on my RiskSense scoring metrics. For that reason, the last step in the process would be to navigate to the Organize > Groups view to remove your and any relevant colleague user accounts from the Decom group. If the need to audit the Decom group arises, any users with the Group Control privilege can temporarily add themselves back to the Decom group.
Speaking of managing a Decom group, a common addition to the Decom Playbooks setup is to add additional rules that automate the process of removing assets from the Decom group as they reappear in subsequent scans of your environment. One example would be to create, save, and leverage filters and rules that identify assets assigned to the Decom group but have a “Last Discovered On” date of fewer than 180 days. The Playbook rule action would then be set to add those assets back to the Default Group or another group and then remove them from Decom. Similar filter-saving and playbook rule creation can also be performed to automate tasks, such as dispositioning assets to their appropriate groups based on filters for items such as IP ranges or subnets, hostname prefixes or suffixes, or operating systems.
We hope this article has provided insight into how common and time-intensive tasks can be automated through RiskSense Playbooks.