Is it possible to extend the Vulnerable Items table?

isqc · ‎04-06-2020

Hi:

We are working on a custom integration to create Vulnerability Entries and Vulnerable Items from a Third-Party provider into the Vulnerability Response application.

We would like to create a vulnerability group rule based on data we provide to the vulnerable item, which is specific to the integration (e.g. it is not one of the fields on sn_vul_vulnerable_item). In fact, in the vulnerability group creation form, we can read the info message: "Choose the vulnerable item fields to group by. If an extended table field is chosen, the field will be used only for vulnerable items that use the extended table."

But the table sn_vul_vulnerable_item cannot be extended without modifying the Vulnerability Response application. We would like to create our application based on the vanilla version of the VR application.

Any ideas on how to proceed? Should we interpret the info message as implying that it is OK to edit the vulnerable items table to make it extensible?

Thanks

Ignacio

andy_ojha · ‎04-06-2020

Hey there,

Got it - any chance you can call out the particular data point of the impacted host?

For what you are after, I don't believe you need to go down the path of extending the Vulnerable Item table.

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

Would need to get a better picture of the overall grouping strategy, but would recommend you check out a few things here as part of your custom integration:

1) Discovered Items

- This holds data about the scanned host
- Discovered Item, is almost a pointer record / middle man ... between the target CMDB CI and Vulnerable Item record
- The Discovered Item can either be Matched or Unmatched ... in either case, it will have a Reference to a CMDB CI record
- If it is Matched, the CI reference will point to a valid CI from the CMDB
- If it is Unmatched, what should happen -> is a new CI is created in the "Unmatched CI" Class .. and that will be value referenced here

2) Unmatched CI, CMDB Class

- Baseline when you install the VR App, you will get this special class to hold hosts brought in from the scanner, but do not have a matching home in the CMDB

3) Detections Table

- In VR v10, there is a capability to store the aggregated detections for a single Vulnerable Item
-- Not super relevant for your grouping strategy here, but something to be aware of as you build your custom integration (e.g. same vulnerability found on different network ports, on the same host)

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

It's likely that you could just stamp the data attribute in question:
- Directly on the target Vulnerable Item
- On the Discovered Item
~ Or potentially on the target CI (would leave that as the last resort, not really ideal).

All of these are accessible from the Vulnerable Item table (directly, or with a dot-walk to a reference field), and you'd be able to setup Vuln Group Rules from there.

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

Would really consider how your Remediation Teams work here, and if that value is truly going to strategically slice and dice work.

The more keys we add, the more Vulnerability Groups end up being created which may not necessarily align to how Remediation Teams work.

View solution in original post

sachin_namjoshi · ‎04-06-2020

Check below for all answers,

Chuck answered your questions

https://community.servicenow.com/community?id=community_question&sys_id=d89e0f21dbdcdbc01dcaf3231f96...

Regards,

Sachin

isqc · ‎04-06-2020

Hi Sachin:

Thanks for the link, but that talks about extending a table which IS extensible out of the box.

That is not our problem, where we are stuck is that the table which we feel should be extended is not extensible by default, and we are hesitant to ask our customer to make that change to the table.

Ignacio

andy_ojha · ‎04-06-2020

Hey there,

Before you proceed down that path - perhaps you could share a bit more about the use-case you are trying to solve for.

What's the additional data point we want to 'group' Vulnerable Items by - that does not have a home on a given Vulnerable Item, Third-Party Entry, CMDB CI record, etc?

Is the data point something related to the impacted host, something tied to the vulnerability, etc.?

isqc · ‎04-06-2020

Hi Andy:

Yes, the additional data point is an attribute of the impacted host. However, that host may or may not be in the CMDB.

So our idea was to include that attribute as an extension to the Vulnerable Item table.

The New Vulnerability Group Form includes the message I was referring to on the original post (see below), which we understood to mean that extending the vulnerable item table should be possible.

But now, from your reference to using a CMDB CI record, I am reading that message as referring to extensions of the Configuration Item table. Is that the correct interpretation? If so, would the recommendation be to create an item on the CMDB if a vulnerability is detected on a host which is not already present on the CMDB?

Thanks

Ignacio