How do others address changes in VIT Assignments?

[Joe Kline]

Trying to gain better understanding on what all actions can be, should be, cannot be taken when a VIT is reassigned to a different Assignment Group.  I have tried searching for relevant other forum posts and have not yet found one that really covers the full best practice and/or spell out all the truly needed updates that can cause ... Currently we are using Qualys integration, assignment rules are limited to out of the box CI Support Group or defaults to a VM Mgr. group.  VGR's are also limited to out of box Vulnerability/Assignment group.  Such that if we reassign one of those VM Mgr. items to a proper remediation group, that VIT no longer should be a part of the original VUL that it was grouped into.  But, no real known way to remove it, and no real well documented way to re-evaluate groups to create a new one for the group that VIT is now assigned to ..  Updating a VGR and then using the reapply is too overly aggressive to remove and recreate (often compared to killing a fly with a shotgun), as that can be rather intensive to process with 10's of thousands of vulnerability groups and 100's of thousands or millions of vulnerable items, not to mention it tends to mess up potential VCA correlation of deferred VITs/VULs.

What is considered the best practice, or how are some of you out there addressing this fully end-to-end across the various types of records?

Thanks, in advance, for any insight and suggestions,

Joe

[Fatih Karacaer]

Hi Joe,

Normally it is possible for a VIT to be part of 2 or more Vulnerability Groups. There is no problem in there. When the VIT is remediated it will be removed from all the VGs it is a member of.

If you want to update your vulnerability assignment groups for VITs and VGs the best practice is to update the assignment rules first. When you change your assignment rules, depending on the order of the rules, ReApply flag will appear for the applicable ones. You can manually execute the re-apply activity or wait for a scheduled job to re-calculate the new assignment group for the VITs.

Kind regards,

Fatih.

[Joe Kline]

Faith,

Thank you for a response, although it really kind of misses part of the point of why we are asking.  It is not an issue to be a part of multiple vulnerability groups.  The issue is since we are using grouping based on Assignment Group, it causes incorrect grouping of VITs into groups where the group in fact is not responsible to address the VIT.  Yes, if the new assignment group on the VIT mitigates the vulnerability, it will be closed upon next import/integration regardless of how inaccurate a VUL now might be.  But the fact that the VUL is absolutely now inaccurate should have some amount of concern, as it has been our experience that users of the system will see a VIT within the VUL that is not theirs, and they will discount the whole system as being wrong and not worth trying to work on those items that are in fact theirs to do.  If I were able to then merely modify the group rules to now automate the assignment to match the manual change, and then reapply those rules, does it only create new VULs for the now changed assignments or does it pretty much kill off any VUL that has that VIT (now incorrectly represented) and recreate those as well?

Or in your summary, are we concluding that SN practices allow for inaccurate data as a result of operational changes that might occur?

Thanks, again, for your input and thoughts,

Joe