Separate Qualys integration between VR and CC

[moulikine]

Hi all, 

We're implementing VR for one of our client that has already CC implemented, they are using the same source data which is Qualys.

What is the recommendation of sharing the same integration ?

1- create two instances one for CC and the other for VR ?  (this approach will cause the creation of duplicate Discovered items with different sources)

2- using the same instance ? (importing data will took a lot of time, we may have a delay to import all VR and CC data)

Thank you in advance.

[Community Alums]

Hi @moulikine ,

We have a custom integration going back to Qualys to pull a report and load test results for failed authentications.  Initially, we were designing to have the call initiate the report to receive the report id, and needed extended permissions than those needed for the VR integration and other CC calls.  To keep extended access limited we had a second account configured to comply with least privileged access design. Secondly, we were wanting to record the assets that were matching with CC loads, and with source being the same across both integration jobs we weren't able to decipher what was occurring with the CC assets.  So, for test purposes, we updated all CC integration jobs to run with the second account, having cleared the data for a fresh load, to record those numbers.  Were were attempting to assess a problem the Prod instance is having with VR matches having detections for other assets align to VITs with different CIs, and as we prepare to role out CC we want to be certain that any issues occurring with VR and the CI matching issue and detection misalignment will not affect the CC data.  With CC using the Test Result History table, instead of the Detection table.  With this test we were able to confirm, similar patterns of mismatch have not been discovered.  However, it surfaced this question needing confirmation that it was using its own DI record for the different source (detection table too large to do a group on CI and have it easily stand out). 

With licensing driven by DI counts, we'll want to confirm we continue to align.  The CC CI count is showing significantly lower counts than licensed for, but haven't checked how many were recording for VR.

So, if for licensing purposes and least privilege, we use the same source account, I'm lead to believe that the same DI record will be used for both VR and CC.  Still would need to test if there would be issue getting to the right asset.  I've only recently been introduced to that issue so haven't assessed what's causing it.

[superhumanben]

Having the same issue but with a caveat. We had VR first and when we installed CC, pre-existing integration instances did not get all the CC vulnerability integrations added to them. We have a lot of reporting that ties to integration instances so cannot readily just use a new integration.