Remediation tasks not created when VIT risk rating/score increases

[Aaron Molenaar]

We use Rapid7's Active Risk score as one of the primary drivers of the normalized risk rating of third-party vulnerability entry records in VR, which then drives the risk score/rating of vulnerable items. As Active Risk is driven by threat intelligence, if the threat increases, the corresponding active risk score flowing in to Vulnerability Response increases, and we get an increased normalized risk rating on the TPVE record. We can get this increase to flow all the way through the system to the VIT records, which change rating from, for instance, a 4 - Low to a 2 - High or 1 - Critical, as desired.

However, if a VIT was not previously in a remediation task as it was a low rating, if the risk rating on the VIT increases because the underlying Active Risk score changes, the system is not picking up the new higher VIT risk rating/score change and issuing that VIT out in a remediation task. We currently have remediation task rules designed to issue tasks for critical/high rated VIT, which work perfectly on new VIT coming in to the system, but the rules do not pick up existing VIT if their risk rating/score changes to something that makes them fit the remediation task rule criteria.

I have been through all the business rules and related code that I think relates on both the VIT and VUL tables, but can not seem to find the right trigger. Can anyone provide guidance on what needs to be changes so that the change in risk score or risk rating on the VIT record will trigger a reconsideration of remediation task rules?

[andy_ojha]

Hey there,

Would suggest taking a look at the Business Rule on the Vulnerable Item table, called "Link to Remediation Task".   That should shed some light to start with for the baseline approach, of getting VITs to eval through the Remediation Task Rules you've defined.

It sounds like you are threading your inputs (R7 Active Risk / Threat Intel) into your current Risk Score Calculator, which would then normalize that into the VIT > Risk Score, Risk Rating.   Then the VIT Risk Rating (or Risk Score) is used at that point moving forward.

• Another Biz Rule you might want to review if you have not already
• On the Vulnerability Entry (sn_vul_entry) table, there is a Biz Rule called "Set recalculate flag"
• That is used to determine when we'd want to re-eval specific VITs through the Risk Score Calcualtor again, due to change on the Vulnerability (e.g. Severity changes, it is added to the CISA KEV, etc)
• It'll set a flag on the Vuln Entry record, and then a Scheduled Job looks for that -> to then initiate re-evaluating the explicit VITs with that Vulnerability -> through the Risk Score Calculator rules you have again
• A similar approach is used for Tenable, and their proprietary VPR scoring value today

[Aaron Molenaar]

Hi Andy,

You are correct, we have modified the TPVE normalization business rule and script includes to account for the source risk score (Active Risk in our case). The severity of the TPVE records updates when the Active Risk score changes, which does send VITs through the risk calculators again, and the Risk Rating of the VITs is updated as expected. However, the Remediation Task rules are not re-evaluated as we would expect, so the VITs do not end up in tasks even though they match task rule conditions.

I previously found and modified the conditions of the BR you mention - Link to Remediation Task - so that if the Risk rating value "changes to" either "1-Critical" or "2 - High", the rule should be run. I also modified the BR script to include the risk rating as one of the 'multiUpdate' possibilities, in case that mattered. See below for current version of script:

~~~~~~~~~~~~~~

(function executeRule(current, previous /*null when async*/ ) {

    //Skipping Br if the same is being reapplied from re-apply rules flow

    if (!gs.nil(current.disable_flows) && current.disable_flows.indexOf("sn_vul.task_rule_vit") >= 0)

      return;

    var before = new GlideDateTime();

    var changeInCI = current.operation() == 'update' && current.cmdb_ci != previous.cmdb_ci;

    var changeInAssignmentGroup = current.operation() == 'update' && current.assignment_group != previous.assignment_group && current.assignment_type == "1";

    var changeInState = current.operation() == 'update' && current.state != previous.state;

    var changeInVulnerability = current.operation() == 'update' && current.vulnerability != previous.vulnerability;

    var changeInNumber = current.operation() == 'update' && current.number != previous.number;

    var changeInRating = current.operation() == 'update' && current.risk_rating != previous.risk_rating; //added for risk rating

    var isInserted = current.operation() == 'insert';

    var multiUpdate = changeInCI || changeInState || changeInVulnerability || changeInNumber || changeInRating || isInserted;  //updated for risk rating

    // if exception rule is matched, no linking of RT with Vit, else Link with RT

    if (!current.isExceptionRuleMatched) {

        new sn_vul.VulnerableGroupRule().groupItemByVulnGroupRule(current, changeInCI, changeInAssignmentGroup, multiUpdate);

        if (changeInAssignmentGroup && (gs.getProperty("sn_vul.rerun_task_rules", false) == "true"))

            new sn_vul.VRRemediationEffort().unlinkAndRegroupItems(current);        

    }

    var delta = GlideDateTime.subtract(before, new GlideDateTime());

    if (gs.nil(sn_vul_cmn.groupRuleTime))

        sn_vul_cmn.groupRuleTime = parseFloat(delta.getNumericValue() / 1000);

    else

        sn_vul_cmn.groupRuleTime += parseFloat(delta.getNumericValue() / 1000);

})(current, previous);

~~~~~~~~~~~~~

I also looked at the script include "VulnerableGroupRule" called from "Link to Remediation Task" but it doesn't look like I would need to modify anything there. We just need to get the updated VIT injected into the script include, but I'm missing what is preventing that.

I would appreciate any feedback from the community on the piece I'm missing.

Thanks.

[andy_ojha · Accepted solution]

Hey Aaron.

I tested the same scenario in my lab, and agree with the changes you made to the Biz Rule conditions AND script portion, where no changes to the Script Include are needed for this use-case...

• It appears that you do have to force the 'multiUpdate' to be set to True in the Biz Rule
• I tried testing this by just modifying only the Condition, of the Biz Rule
  • The function 'groupItemByVulnGroupRule' did get invoked and the VIT was passed through
  • But then it stopped and nothing else happened 
  • Once I adjusted the Biz Rule script, to handle setting the 'multiUpdate' to True, and pass that into the Script Include call, it appeared to work all the way through
  • When I tested it
    • I used a VIT that was created and not part of a Remediation Task (i.e. did not meet the criteria of my Task Creation Rule which only handles High or Critical (Risk Rating)
      • Further, the VIT State was Open, and had a valid Assignment Group
    • Once the VIT.Risk Rating changed (None -> Critical), the Biz Rule was called, then the Script Include was called passing along the VIT and `multiUpdate` value of True into the function 'groupItemByVulnGroupRule'

By chance, are you testing with a VIT that has the State of Open, and also has a valid Assignment Group?

This one is a bit silly, but just to rule it out > there are several Biz Rules named `Link to Remediation Task` - perhaps double check the one we've modified, targets the right table (sn_vul_vulnerable_item)

On your Remediation Task Rule > Condition, do you have anything else in the Condition that could be causing a wrinkle?

It's a bit more involved, but if you are this far along I'd probably work in a sandbox or sub-prod instance, and add some log statements, then trigger a VIT to have it's Risk Rating changed (increased) and see what the logs show to start tracing where we might be blocked...

• On the Biz Rule (Link to Remediation Task), I added some log statements to:
  • 1) Verify the Biz rule was actually getting triggered 
  • 2) Log the value of 'multiUpdate' to ensure it was getting set to True
  • 3) Ensure I was hitting inside if the IF statement (where the Function groupItemByVulnGroupRule) gets called 
• On the Script Include (VulnerableGroupRule), I added some log statements to:
  • 4) Verify within the Function 'groupItemByVulnGroupRule', the function was getting called for the VIT I was testing with 
  • 5) Log the value of the 'multiUpdate' to ensure the value of True was being passed to the Function from the Biz Rule
  • 6) Ensure I was hitting the condition of the IF statement (right under the script comment "//re-grouping in case of any update or in case no parameters are passed.")

It's a bit overkill, but tracing our steps through 1 - 6 above, ideally should shed some light on where we are being blocked for the use-case you have.

Reference:

For testing, a quick/dirty BG script would do the trick for now (sandbox or sub-prod instance), like this:

var grVIT = new GlideRecord('sn_vul_vulnerable_item');
grVIT.addQuery('number', 'VIT0010051'); // SWAP VIT for testing to meet Task Rule Condition
grVIT.setLimit(1);
grVIT.query();

while (grVIT.next()) {
    grVIT.setValue('risk_rating', '5'); //Toggle between 1 and 5 to trigger Biz Rule for testing
    grVIT.update();
}