Vulnerability Assignment Rule Logic and Execution Order

Nicole Allen · ‎03-23-2021

Hi There,

Just wanting some clarity around how vulnerability assignment rules are applied when a new VI is created. We currently have a few hundred vulnerability assignment rules configured because each technology type have different requirements for remediation ownership. For example, on our Windows AU servers, some vulnerabilities will be the responsibility of the technical service team to remediate and other the Business Application Support Group who are using that server. Then I have a catch all rule which should pick anything not assigned by one of the previously defined rules and assign to a group who will perform analysis on why the VI was not assigned to either a technical service or business server. In most cases those VIs that should end up there would be where an assignment rule doesn't match OR a previous assignment rule could not find a related Business Application against a CI (these are scripted assignment rules using the CMDB service mapping to identify which Business Application is using the host.

Now I've noticed something recently where my catch all assignment rule is not picking up a VI.

For example, I have a VI related to Microsoft Excel on a windows servers. Now I have an assignment rule (execution order 50) which says if the server is a windows server and the plugin name contains 'Microsoft Excel', then use this scripted rule to locate the related Business Application and assign to the related Support Group.

Now if the script was unable to detect a related Business Application, the support group field on the VI is not populated, so is blank. I would then expect the next assignment rule (execution order 75) to pick up this VI and process it. This assignment rule basically says, if its a windows servers assign to this support group.

But from what I can see in the system is if the first rule matches but wasn't able to derive a support group, the system is leaving the VI unassigned. Can someone clarify what the logic should be?

julian_azaret · ‎03-24-2021

Beat me to it Chris!
Hi Nicole, hope all is well.

Chris is absolutely correct - a scripted rule should check whether it has successfully retrieved a group, and try another way or return the default group if it has not.

This is probably not how most people would assume Assignment rules work, and your assumptions are perfectly reasonable. So I'd like to also share how they are executed so you and your colleagues can interrogate the logic yourselves.

Assignment rules are run by a Business Rule on the Vulnerable Item table named "Run assignment rules". This business rule invokes the Script Include "AssignmentUtils", and calls the method "getAssignmentGroup" in that Script include.

While it does check to see if any object has been returned, this just ensures there hasn't been an error when evaluating the script. Here's the script itself, from Vulnerability Response version 13.0.3:

    getAssignmentGroup: function(vulItem) {
        var assignment_info = {};
        assignment_info['assignment_group'] = "";
        assignment_info['assignment_rule'] = "";
        var assignmentGroup = "";
        // Iterate assignment rules
        var assignmentRules = this._getAssignmentRules();
        if ((!assignmentRules) || (!assignmentRules.list) || (!assignmentRules.rules))
            return assignment_info;
        for (var i = 0; i < assignmentRules.list.length; i++) {
            var gr = assignmentRules.rules[assignmentRules.list[i]];

            // This check ensures, 
            // (1) The assignment rules for Infrastructure Vulnerability are applied
            //     only for Vulnerable Item (sn_vul_vulnerable_item) records
            // (2) The assignment rules for Application Vulnerability are applied 
            //     only on Application flaw (sn_vul_app_vulnerable_item) records
            if (gr.table != vulItem.sys_class_name)
                continue;

            // If the condition is empty, this is a default condition, always matches
            if ((!gr.condition) || (this.util.checkRecord(vulItem, gr.condition))) {
                // Simple group
                if (gr.type == "1")
                    assignmentGroup = gr.assignment_group;
                // Assignment group field
                else if (gr.type == "2") {
                    var arr = gr.assignment_group_fields.split('.');
                    var recordPosition = vulItem;
                    for (var x = 0; x < arr.length; x++) {
                        var columnName = arr[x];
                        recordPosition = recordPosition[columnName]; // dot walking into assignment group
                        if (recordPosition == null)
                            break;
                    }
                    assignmentGroup = recordPosition;
                    // Script
                } else if (gr.type == "3") {
                    var evaluator = new GlideScopedEvaluator();
                    evaluator.putVariable("current", vulItem);
                    evaluator.evaluateScript(assignmentRules.rules[assignmentRules.list[i]], "script", null);
                    assignmentGroup = vulItem.assignment_group;
                }

                // return the assignment information
                assignment_info = {};
                assignment_info['assignment_group'] = assignmentGroup;
                assignment_info['assignment_rule'] = gr.sys_id;
                return assignment_info;
            }
        }
        return assignment_info;
    },

View solution in original post

bharanikumar20 · ‎08-06-2024

Hi, Would like to know if this code worked. Am facing similar issue with the VITs assignment rules

julian_azaret · ‎03-24-2021

Hey Nicole,

I think the former is a fantastic idea, please do submit a summary of your experience and the behaviour you'd like to see using the Idea Portal. This way it can be upvoted by other customers who feel the same way, and gain some momentum to be considered for an enhancement.

I certainly do appreciate Paul's suggestion, and a direct modification to the script could work if implemented correctly. However, it would be recognised as a customisation to the Script Include. Your organisation would own that component including manual management of future upgrade conflicts - this means if we do update that Script Include, you would not get the update unless you revert to the baseline version.

For that reason, I can't recommend customising in this way. However, should you choose to do so, we always recommend keeping a register of customisations and the reasons why they were made, to aid in upgrade conflict resolution in the future.

Hope this helps! Best of luck.

Cheers,

Julian

Nicole Allen · ‎03-24-2021

Thanks Julian, understood. We'll discuss whether this is an ideal approach whilst we wait to hear if our idea is adopted 🙂

Dagan · ‎06-27-2025

@Nicole Allen ,

I found this post while experiencing the same issue for my client. I kicked the code around based on what @Chris McDevitt and @julian_azaret provided in this thread.

As Julian suggested, I have created an idea through the portal that alters the logic for just the scripted assignment rules to allow subsequent rules to run. Have a look and see what you think! Hopefully you're not still experiencing this after 4 years.

Idea: Modify Vulnerability Assignment Scripted Rule Behavior to Continue Processing Rules if No Valid Grou...

Now, as Julian also pointed out, touching the OOB script includes directly would be deliberate customization, which is against best practices. I would advise documenting this change and reviewing the skipped files come upgrade time to see if we can revert the script includes to OOB conditions hopefully in the near future.