VR: Risk Rating calculation - Business Rule clashes with Vulnerability Calculator

[aasch]

Hi,

I'm currently facing a challenge in Vulnerability Response:
A customer would like extend Risk Ratings for the Vulnerable Item table. The way they have currently set this up seems to clash with how VR is meant to work out-of-the-box.

Can someone shed light on the inner workings and perhaps guide me on Best Practices?

The proper way how to set up custom or changed Risk Ratings is outlined in the Docs here (section "Vulnerability Risk Score Weights"). The customer has currently only extended and adjusted the Risk Rating field choices on Vulnerable Item instead of adjusting and adding Risk Score Weights or making up their own new Risk Score Weights type.

The Docs mention the Business Rule "Update Risk Rating from Risk Score", which is also mentioned in the community here.
However, the customer has currently set up a Vulnerability Calculator that is targeting the risk_rating field. He expects to be able to set Risk Rating via this mechanism instead of the comprehensive setup as outlined in the Docs link above.

His reasoning as far as I know stems from the fact that the newly created Calculator for the Risk Rating field does execute when using the UI Action "Calculate Risk Score" on a Vulnerable Item.
The code of the UI Action is a few rabbit holes deep. From skimming it I understand that it not only applies Calculators targeting the risk_score field. Instead it applies all calculators for the Vulnerable Item table, including their own Calculator for the risk_rating field.

To my mind, the Calculator targeting risk_rating should not have been implemented, as it seems to be "clashing" with the OOB Business Rule.

However I can't find any documentation in the Docs, Community or the learning material that says that you shouldn't use a Calculator for risk_rating.

I think the script order is pretty clear. The UI Action calls a chain of Script Includes, does a record update and then the Business Rule does its job, because it runs before record update.
The fact that it's still possible to set up a Calculator, which seems to "sidestep" the BR, make me think I'm missing crucial details.
In theory only the BR should be relevant, because that's the mechanism that calculates Risk Ratings when new VITs come in from the scanner.

Has anyone faced this issue before?

I hope the wall of text got the message across. I'm happy to share more info.
Thanks in advance.

[Dave Winsor]

You can customize your Risk Ratings to any Risk Score ranges so you could just have 3 ratings to broad score ranges.

Another option is to use rollup calculators for the Remediation Tasks (VUL's) and set your VUL's to group all VIT's by Host so you will have a score/rating for each like you said.

[aasch]

"This is where I stop and try to understand if this is what I would need to prioritize the vulnerable items for remediation."

Afaik this is not how ServiceNow's VR is meant to work.

Grouping occurs via Remediation Tasks and their grouping rules. They are the end of the chain of events.

Third Party Entries and scans are at the start of the chan. They provide inputs for Vulnerable Items.
Any factor that poses any form of risk you can transform into a numerical value. The sum of those value make up the "Risk Score" of the Vulnerable Item.

Any input from the Third Party Entry should flow into the Risk Score.
Based on the Risk Score you can configure which Risk Rating you get or use the default ranges.

And at last: Based on the Risk Ratings you get grouped/rolled up ratings, which you can in turn use to prioritize remediation.

The Risk Score -> Risk Rating mechanic abstracts all specifics away. In my opinion it's crucial a feature we should stick to.

If I understand your Use Case correctly, introducing custom fields would bend the standard unnecessarily.