Reporting on CMDB Key Values or Resource Tags???

[Streamline Cam]

We are using VR to analyse vulnerabilities, which are associated to CI's.

There is so much useful information held in the tables for resources tags (imported from scanner tools) and CI key values from discovery.

There are 20k records in our resource tag table (sn_sec_cmn_host_tag) so doing a PA breakdown on those would require increasing ‘com.snc.pa.scorecards.max_breakdown_elements’ which I know is not advised.

Example metric, show me backlog of VI's broken down by a particular resource tag.

Similarly for ‘cmdb_key_value’ values, would be good to even search for VI's where CI has a tag e.g. application = 'Customer Payments AS'. CI's can have 30 tags or so, therefore joining resource tags to Vulnerable item for example could make the view and query so large.

Wondering if anyone has done anything similar before? ‘sn_sec_cmn_host_tag’ or even ‘cmdb_key_value’ values. The data is these fields is so useful to the team but so difficult to report on use effectively.

Any advise welcome!


@andy_ojha @Chris McDevitt 🙂

[andy_ojha]

Hey there...

Can appreciate the challenge but juicy data for reporting here.

For Discovered Item 'Resource Tags', unfortunately they are stored using a GlideList type of field - which does not support doing a clean "Group By" in reports, as there could be many values...
-> Querying is still possible if you can create conditions ("Show me VIs with this VI.DI.Resource Tag")

Another approach or way to look at this, could be to take advantage of the Classification Rules on Discovered Items.  Essentially you could look at potentially normalizing some of the data here like DI.Resource Tags or the CI.Key Tags -> into normalized values you care about.   

Those normalized values (driven by DI Resource Tags, etc) -> would then be stored cleanly on the Discovered Item record, and then could be used in a "Group By" function for rich reporting.

Doing this for the CI Key Value Tags would be a bit more involved with tech debt, as there would be some advanced scripting to crawl the necessary tables involved.

Doing this for the Discovered Item Resource Tags would be easier. 

One thing to keep in mind, is the 'SYS_ID' of those Resource Tags might be different in each of your instance(s) - depending on how we are setup and what was potentially migrated fwd (DEV -> xx --> PROD) or cloned down (PROD -> xx -> DEV).  Often for a fresh installation, it'd be handy to "promote" the records forward so that the "SYS_IDs" persist and are reliable for configurations and other work we promote like conditions in Reports, Classification Rules, etc.

Reference:

• https://docs.servicenow.com/bundle/xanadu-security-management/page/product/vulnerability-response/co...

[Streamline Cam]

Thanks for taking the time to get back to me, using these is something I didn't think to use.

This may seem like the best option we have but this also is very limiting as I would see it. As you can only have 1 active rule per table and only 1 rule can apply, I could have to pick a specific type of tags like environment to classify. But we have loads of different tags, like datacenter, application, status etc. We'd only be able to report on one of these - if I understood correctly?

[andy_ojha · Accepted solution]

Hey there,

Agree - going this route with the Classification Rules, does allow us to normalize (flatten) those Tags (GlideList field, Rel List for CMDB Tags) into a data object on the Discovered Item that we can do a "Group By" on, but the tradeoff is that we'd have a limited output with the target field being set by the rules per table.

Additional reports (conditions in queries, etc.) can still be crafted using the explicit values as a fallback route (e.g. show me Vuln Items where the Discovered Item[.]Resource Tag | IS ONE OF | <tag names>).

[Streamline Cam]

Thanks again for taking the time to get back to me here. As far as I see it there is no perfect solution for using this information in dynamic PA style reports for breakdowns as the system has it's limitations there.

But there are some possible manaul work arounds for more specific reports if we need them.

Cheers Andy 👍