Is it possible to extend the Vulnerable Items table?

[isqc]

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 · Accepted solution]

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.