Confused about Remediation Task Rules, when do they run/trigger?

[Ketil Ellertsen]

Hi!

I have set up a remediation task rule, that groups based on assigned_to field and vulnerability. When I click the reapply button, it correctly deletes all existing VULs related to the rule and creates new, which contain any VIT meeting the condition. 

However, when new VITs are created these are not automatically added to existing VULs, even though they satisfy the conditions. I saw in the documentation that only VULs created through condition filter/filter groups that are updated automatically. If that is the case, what is the point of having these Remediation Task Rules? It feels like I am missing something. 

The remediation task rule in question:

[Ketil Ellertsen]

In our case, we wanted to assign Remediation Tasks to the same assignee as the VIT. So I created a business rule that does that. Because it is through the related list that we have the connection between VUL and VIT, I had to create a BR on the 'sn_vul_m2m_vul_group_item' table, after insert/update: 

var vul = new GlideRecord('sn_vul_vulnerability');
vul.get(current.sn_vul_vulnerability);
if(vul.assigned_to == ""){
	vul.setValue('assigned_to', current.sn_vul_vulnerable_item.assigned_to);
	vul.update();
}

So whenever a m2m record between VUL and VIT is created, it will check the VUL. If the VUL does not have any value in the assigned_to field, it will populate the field with the assignee value from the VIT.

Hope this will help you on your way. 🙂 

[William Froger]

This is clearly smart indeed. Nice one.

I've succeeded in doing what I wanted. For that I have created a Vuln assignment rule to assign all created VIT based on a specific field to a specific group. Once this field filled, a RT rule gather all the VIT based on assignment group to create RT.

Business rule comes then to assign those RT to a specific user.

I couldn't find a way out of the box to assign a RT to a specific user. This field doesn't seem to be assignable.

[Chris McDevitt]

Hi,

Yes, it is confusing. I think people's intuition tells them that if a VI matches it should be added to a Task/Group. But... the process is more complicated than that. Once a group is being "worked" (aka anything but Open) then it is locked because you may be working on a Change/Deferral/Fix based on the original VIs (assets with a vulnerability) and you really do not want the list of thing you have planned to work on change.

The info is there is the Doc you linked to... it is just not 100% clear...

[Ketil Ellertsen · Accepted solution]

Hi Chris!

Thanks for taking the time to reply. What you are saying makes sense.

However, that means something is wrong in our instance. Whenever I create new VITs they are not added to existing VULs (which are in state open) nor is any new VUL created. I am not sure as to why it is not working. As I've mentioned above, when I use the reapply function, it works fine.

Any suggestion as where to look for an error? I've looked for scheduled jobs but I could not find what triggers it.

While writing this, I realized I had not checked the business rules. And there I found the issue: I was not fulfilling the conditions for triggering the "Link to Remediation Tasks" BR. When creating the VITs correctly, it now works! 

Thanks for your help!