VRM Classification rules

[Viji Rohan]

Hello,

We have a requirement to allow more than one way of classification of VITs whereas ootb functionality picks the rule whichever matches first and ignores the rest. 

Currently, there is no OOTB Classification Type in sn_vul_vulnerable_item. We have created a custom field to categorize the VITs. The same VIT qualifies for multiple types of classifications that we want to use it in our business rules for further logic adoption.

Is it a good practice to have a comma separated values in our custom field for categorization and have a script in the classification rule, keep building the conditions in the script to amend the custom field (u_category).

The concerning factor is if ServiceNow improves classification rules in future or introduces ootb classification type in VIT, it will be difficult for us to maintain the tech debt created.

Any thoughts?

Regards,

Viji

[Eliz Skogquist]

Hi Viji,
It is not recommended to write classification rules on the VI table.  Classification rules on the vulnerability table or the discovered item table benefit by being set-up on small tables, for access/use on the large tables via dot walking.  Should you need additional classifications, you could use a custom field on those tables (vulnerability or discovered item) to add more classifications.  It's not clear how many types of classifications you might be looking to use; however, you mention adding multiples with the consideration of commas.  That doesn't sound like an efficient field to condition against.  Be mindful of processing being added to the VI records, as the table can be sizable and each transaction adds up, whether its noticed in ingestion times or user interactions.

Best regards,

Elizabeth

[Viji Rohan]

Hi Elizabeth,

Thanks for the clarification that VIT table is not an ideal one to build the classification rules on.

We have a scenario where Vulnerable Item (VIT) can satisfy multiple classification rules simultaneously. For example, an F5 Load Balancer vulnerability that requires a patch may match both the Patch classification and the F5 classification. If assignment rules are driven by classification, the resulting assignment may vary depending on which classification is applied first or retained as the primary classification.  We are trying to ensure that assignment logic handles VITs with multiple matching classifications consistently and applies a clear precedence model to determine the correct assignment group.