Vulnerability Response: Calculate risk score BR works unpredictably

[Alex150]

Hello,

We have configured Vulnerability Response and Tenable Integration with ServiceNow OOTB solution. There is a low-code Calculator that calculates priority based on conditions. We don't set "Critical" priority because of owner requirements. All works perfect except the next issues:

1) after each scan the system imports new Detections. Each new detection inserts, the system makes "magic " in background and VITs are being updated. Having many correct calculated Items, we have some mount of VITs with "Critical" priority. OOTB Script Includes skips Vulnerability Calculator and runs inner processings that calculates priority with different way. I would like to underline that based on our Calculator, Critical priority should not have been created.

Calculator settings:

 "TenableIOVulnerabilitiesProcessor" script include and line 266

and refers to "TenableUtil" and line since 532

Recalculate button works as expected.

New VITs are being created with correct Priority, but are being changed later after new detections. 

Can somebody explain me why it was added by ServiceNow to the scripts? What work around can be applied not to run this functionality and not customize scripts? There are no documentation description and community posts. We have contacted the SN support, but unfortunately they the couldn't provide us explanation and fix. They just explained us what we have found out before.

2) The second issue leads from the first question. Here is a list of Critical VITs created by System

Some of them were reopened and we expected "Calculate risk score" BR will perform our Calculator, but happens nothing. 

If I close manually and reopen VIT - it works. If I do the same with script - it works. It doesn't work after the main integration.

We expected to a see message that Priority was changed. What can be the root cause not running the BR?

I will appreciate any help)

[andy_ojha]

Hey there,

For Issue 1 - It does seem like if you continue to use the Calculator to set the VI.Priority, it is going to fight with the Tenable integration and try to override that when Tenable brings in an update (such as a new Detection on an existing VI) for the Plugin Severity.  Can't explain why it was done this why, but currently it is wanting to stamp the Tenable Plugin Severity there, and if you try to point the Calculator to the same target field - they will fight with each other as you are seeing.

How about approaching this another way

• Instead of using the VI.Priority, take advantage of the VI.Risk score and VI.Risk rating 
• This is much better path for calculating tailored values onto the VI and basically only the Calculator will be setting values into these fields -- you won't have to deal with the Calculator and Tenable integration fighting over the same field (VI.Priority) like you are having to right now
  
• I agree with you, it is a bit redundant to slap the "Severity from Tenable" onto both the VI and Vuln Entry, but the Risk Score and Risk Rating are what we should be calculating and driving Remediation Teams with
• VI.Risk score and VI.Risk rating make more sense AND you will be setting yourself up to take advantage of other features such as Reporting, Performance Analytics, etc -- that are based on the framework of VIs having their Risk score and Risk rating calculated (will be easier to adopt new features as time goes forward too) -- and there is no customization of baseline scripts needed on your part for this 
• This also gives your Remediation Teams some extra value, they not appreciate it right away but when there are 1000 "High" items assigned to them to focus on with the same Target Date, the ones that are High with a greater Risk Score are likely the ones I would want to focus on if I have a small amount of time (different flavors or degrees of Risk)
• The system will automatically calc a normalized Risk Rating, based on the Risk Score range (0-100)
• Let the Tenable integration slap the Severity onto VI.Priority (as is OOB), and your Calculator will drive the Risk Score, Risk Rating without any conflict (you'll be able to de-prioritize those "Criticals" without flapping)

-----------------------------------

For Issue 2 - Calculators are not being ran for Reopen (Closed -> Open)

• Interesting to see this baseline Biz Rule was updated to include the "Active | CHANGES TO | True", it previously did not include this 
• The issue might be the  "Active -> True" is handled by another Business Rule, "Transit to Open" - which has an Order way down the list -- i.e. it might be that the Active flag is being updated after the "Calculator Risk Score" business rule has already ran and it wont see the Active flag change because of the ordering
• [Calculate risk score] - ORDER = 40, [Transit to Open] - ORDER = 100
• Might be worth a Support Case if you are seeing the Calculator not running in the "re-open" scenario -- perhaps its an issue with the Business Rule ordering?

[Alex150]

Hi,

Thank you for response.

I Agree, It would be batter using VI.Risk score and VI.Risk. It was suggested to Owner, but he and his team decided to use Priority field. 

It says nothing in SN documentation about any restrictions. And as I can see priority is available to be chosen in Calculator and it means that it should be working.

I checked these BR, and it works properly. Something broken in Script Includes because the issue only with unexpected Critical VITs.

[andy_ojha]

Hey there,

I get it - I guess I'm trying to advise you to stick to VI.Risk Rating and VI.Risk Score because otherwise there will be issues - now and potentially in the future:

1) The Tenable integration is going to fight with VI.Priority and your Calc (as currently experiencing)
2) You will be missing out on current and future product features, an example is reporting (or anything that threads from the VI.Risk score, VI.Risk rating
3) Your Vulnerability Group recs (Remediation Task) will miss out on the Risk Roll-Up feature
4) Your Third-Party Entry recs will miss out on the Risk Roll-Up feature 
5) If you opt to use Solution Mgmt for VR, you will miss out on the Risk Roll-Up feature in the future

We used to use "VI.Priority" before VI.Risk score and VI.Risk rating existed - in the docs and calc templates OOB, they purposely earmark it for "Risk score" - but nothing stops someone from setting other fields on the - it's one of those "just because you can, should you" type things.

It just seems counter productive to fight with VI.Priority, and go down the path of technical debt with customizations - when there is an out-of-box solution that actually is what VR implementations should be using in the current generation, and what the VR framework is built around currently and probably in the future.

Perhaps some of these facts above could help you and your product owner justify the right decision to move forward with - earmarking a frictionless experience, smoothly adopting new features in the future and staying in-line with the intent of core product features.

Reference: Calculators and Risk Score