Creating remediation tasks so new VIs are not added to existing/active RTs
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
Hello,
We have the VR integration with Tenable.io. We use remediation target rules to set SLAs and task rules to group VIs together by CI support group. The problem we have is that new VIs are being added to existing/open Remediation Tasks that have already missed their target and the Targets aren't updating (although we wouldn't want that because the older ticket is still overdue). Is there a way to ensure new RTs get created for VIs with different remediation target dates?
I'm attaching our Vulnerability Group Rule in case that helps.
Thanks,
Leslie
- Labels:
-
Vulnerability Response
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
Hey there,
I think I see the challenge you are describing.
However, first I think we may want to re-visit this strategy. I noticed we're leveraging the CMDB_CI.Support Group for the grouping key and assignment, but we're not always guaranteed to have a CI that we match to, based on an asset Tenable is sending over.
We'd see better results by first, letting the Classification Rules and Assignment Rules -> first get the Vuln Items (VITs) assigned appropriately (whether a CI exists, whether the CI Support Group is the Team we pinpoint, or whether we're dealing with an "it depends" scenario where we assign VITs in a different way).
Then -> use the outcome of that such as the VIT Assignment Group, is one of our key values for structuring AND assigning the Remediation Tasks appropriately.
We'll also likely see some challenges with using the VIT.CI as a grouping key for Remediation Tasks - perhaps it'd be worth revisiting that to really see if that aligns with how Teams review and address vulnerabilities.
If we have to stick with using CMDB_CI.Support Group as a grouping key (which I think will have some pitfalls), then we would want to be defensive in our Remediation Task Rule -> Condition, we'd want to ensure VITs that do not have that data are handled perhaps in a different grouping rule / task rule. E.g. consider VITs that have a CI without a Support Group such as the ones created by VR in Unclassed HW.
The logic for attaching VITs to Remediation Tasks, is really handled by the State of the Remediation Task. If the Remediation Task is in the Open State, then it is fair game for new VITs coming in to automatically get added to that Remediation Task. Once the State of the Remediation Task advanced forward (beyond Open), then that Remediation Task is locked from new VITs getting added to it.
The Remediation Target Date you see on the Remediation Task, essentially is rolled up from the VITs associated to that Remediation Task, where we cherry pick the worst one (i.e. the Remediation Target Date that will breach first across all the VITs for that RT, and then roll that up to the RT > Remediation Target Date). Overtime as VITs close out, that RT > Remediation Target Date, is continuously evaluated and updated - based on the VITs associated to that RT.
Reference:
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
Thanks for such detail in your reply.
You are correct in that we don't always have a matching CI (and therefore support group). We actually do leverage classification and assignment rules on the VITs. The classification rules are used in our Risk Calculators and Target rules. The VIT assignments are used mainly for reporting purposes. Also, some remediation teams manage their VITs without the Remediation tasks, so those are used in that case, too.
I couldn't figure out how to use the VIT assignment for grouping Remediation Tasks, which is why I used CI Support group.
Assuming we have to stick with groups how they are, is there another way to address our issue? I tried using Risk Rating to the grouping rules, but that combined all of the CIs on one VUL. That's not what we want. I am considering testing adding Remediation Target to the group rules, but my fear there is that there will be too many VULs for each CI. For example, if we scan each week there could potentially be a new VUL each week for the same CI.
We also considered creating dashboards for each assignment group that just groups their VITs in a custom manner, that way remediation teams can view their VITs by Risk, Target, or CVE. What are your thoughts on that?
Thanks!