New Site vs. Targeted Schedule?

InsightVM
1

Is there any guidance on when I should have a separate Site vs. a Schedule that Targets a specific Asset Group? I’ve been told to reduce the number of Sites that I have and am wondering what the criteria should be for needing a separate Site.

2

The tactic is going to vary wildly based on your environment. The asset count, network architecture, scan engines in use, os distribution, credentials, etc all play into it

However on a fairly general note, you typically want to have fewer sites and more asset groups to utilize the subset of assets when scheduling scans within a site. The site should be something logical or physical that encompasses a large scope. For example I would have a site for my Boston Data Center as well as my Los Angeles Data Center. Each geographic location would essentially have it’s own site. These sites may be defined by a /16 or maybe even a /8 depending on the size of your environment.

The asset groups would be created as smaller subsets of those. For example I may have a windows asset group that when used in conjunction with the scheduled scan for that site only targets the windows assets in that site. Separating these out from the other assets gives me a predictable time to complete the scans which helps stagger the schedules as needed to avoid overlap.

If you had multiple domains that all use different windows credentials for example you would want to create a site for each of the domains and assign the credentials to the site. Then create asset groups for each of the data centers assets, this way you’re still scanning all of the assets for each data center but through the scheduled scans and the site is handling the designated credentials.

Basically the main reason to reduce the amount of sites and increase asset groups is because asset groups have less overhead than sites. A site definition needs to have templates defined, credentials, scope, etc and can even have more. Instead of repeating that data over and over in your database you can minimize the sites when a lot of them are essentially repetitive and opt for just small asset groups that only have a name and a scope.

3

So I have Scan Engine Pools set up for each DC/Routing Needs, and a Discovery Site for each of these.
I’m thinking of three designs for the Vuln Scan Sites, which one would you go with?

  1. Separate Vuln Scan Sites for each credential and Scan Engine Pool set:
    • DISCOVERY: DC1
    • DISCOVERY: DC2
    • VULN: DC1 - Windows (One Schedule)
    • VULN: DC1 - Linux (One Schedule)
    • VULN: DC2 - Windows (One Schedule)
    • VULN: DC2 - Linux (One Schedule)
  2. One Vuln Scan Site with all Assets and credentials, then use the Schedule to carve up the Scan Engine Pools
    • DISCOVERY: DC1
    • DISCOVERY: DC2
    • VULN Scans (Schedule for each Scan Engine Pool)
  3. One Vuln Scan Site per credentials, then use the Schedule to carve up the Scan Engine Pools
    • DISCOVERY: DC1
    • DISCOVERY: DC2
    • VULN: Windows (Schedule for each Scan Engine Pool)
    • VULN: Linux (Schedule for each Scan Engine Pool)
4

So I think the main advice I can give here is that you don’t need a separate site for DISCOVERY and VULN.

If they’re all using the same credentials, then you could honestly have all of that rolled up into one site (depending on the scope of assets). Like you mentioned, you can pick and choose the engine pools for the scheduled scans so that’s not an issue. In your case the only reason I would break these up into multiple sites is if they were using different credentials and I didn’t want to be spraying passwords (which you should move towards the scan assistant for anyway).

But the discovery scans can be scheduled for Monday, and then run your vuln scans staggered on tuesday for an example.

1 Like
5

Are your vuln sites defined by IP range or asset groups?

6

All Vuln Scans and Schedules are defined by Asset Groups
Discovery Scans are the only ones that use CIDRs

7

Ok, so you could still have that encompassed into one site then. The scheduled scans allow for specifying a subset of assets in which you can use the asset groups.

So you would still define the site by the IP range, run the discovery scan on Monday which would update the asset groups (depending on how they’re defined) and then on Tuesday the scheduled vuln scan filtered down to that asset group (windows) with that engine pool

8

Should I do one Vuln Scan Site per credential, then schedule by Engine Pool using Asset Groups

9

I appreciate this design. Yes, you could use sub-scheduling, but you’re just hiding the complexity of having multiple sites within a single site, which means the complexity is still there, you just have it hidden inside sub-schedules. But at the same time as long as we just limit sub-scheduling to Discovery scans, followed by Vuln scan, it can also be a good strategy to keep things a little cleaner, just be careful not to slip too far down that slope and do one site with 10+ sub schedules, that would just be chaos IMO. But overall, a 1:1:1 Site:Scantemplate:Engine is how I recommend creating sites.