Allow InsightVM - Exclude From Alerts

InsightIDR
1

Hi all,
The AllowList functionality of InsightIDR seems to be somewhat lacking. It doesnt seem like there is an easy way to add an asset to an allowlist, or to prevent it triggering certain alerts.
Is this correct?

We have IDR and VM deployed, and get lots of alerts when a scan is running. I dont seem to be able to whitelist/allowlist the scanning engine…

Any ideas?

Thanks,

2

@ross_palmer,

So I come across this with my customers as well, and unfortunately, at this time, you cannot pre-emptively create the allowed list. You will need to find the investigation that corresponds to the host with the scan engine that caused the alert, choose close investigation, and then pick the correct alert modification. If the investigation has already been closed out and you need to modify it, you can always re-open the investigation and then close it again while picking your alert modification.

3

Just wanted to say “me too” regarding Ross’s comments - we use a third party vulnerability scanner and it also triggers alerts during scans which we’re unable to do anything about since the only usable option is to close the investigation i.e. there aren’t any suitable alert modifications available. Sometimes we are given the choice of allowing failed authentication attempts against a given destination asset, but that’s the “wrong way around” for this type of alert - we need there to be an option to allow failed authentication from a single source asset, our vulnerability scanner.

We’ve recently purchased InsightConnect, so I’m now looking at using that to create a workflow to automatically close any investigations where the source IP address is that of our vulnerability scanner, since IDR doesn’t appear to do what we want out of the box.

4

Thanks Stephen, thats what we have had to do to date unfortunately.

We also have a SOAR solution involved, which triggers a load of responses when we have a detection, which obviously gets quite noisy during scans.
I am also looking at doing what Graham has said around closing investigations automatically, or adding in a step into our Workflow to not trigger the rest of the Incident Response process when the source asset is the scanner, however, this feels like putting a plaster over the issue really, when the solution should be able to be configured from within IDR…

5

@ross_palmer and @graeme_hamilton,

Are you able to create a scan exemption from your 3rd party scanner to not hit the IP of your IDR honeypot?

6

Hi Stephen,
Our issue isnt around honeypots, its around things like the insightVM scanner logging into multiple devices in a short amount of time triggering alerts in IDR.

7

Same as @ross_palmer - we don’t use honeypots, these alerts are being triggered by logs that the Insight Agent is collecting from our systems.

8

@graeme_hamilton and @ross_palmer,

Gotcha, unfortunately it doesn’t sound like anything can really be done, especially if there are no Alert Modification options within the investigation when you close it. I would suggest maybe a Request for Enhancement to highlight this issue and see if anything can be done.

9

What we did in our environment is to segment the IVM Scan Engines away in a VLAN that is basically not allowing any incoming traffic to minimize risk of the SE getting owned. Then we choose to close the investigations created from the scans with the option to always allow those IPs to run without triggering any new alerts.

It would however been a great feature if IDR and IVM could talk to each other a bit more since there already exists integration between the two.
Then it should be possible to see if there is currently a scan running in IVM that match the attack pattern seen by IDR. If it do not match any scans then trigger an alert as then the behavior is strange.