Scheduling Optimization

Sandfly scan schedules are easy to add and Sandfly is designed to have a low impact on protected hosts. In environments that have shared resources, though, there are additional factors that should be considered when scheduling scans.

The primary factor to consider is the effect on shared resources (e.g. SAN devices, NFS servers, VM host machines, etc.). When file and directory sandflies run on many hosts that use the same shared storage, the cumulative burden placed on that common storage device may become noticeable.

Another important factor to consider is sensitive hosts. These devices could be anything: heavily loaded hosts, lightweight devices with limited resources (e.g. IoT devices, network cameras, etc.), systems providing mission critical services (e.g. a primary database, core routers, etc.), applications on hosts that are affected by even mild extra activity, hosts that have operational requirements that limit scanning periods, or other cases. This subset of hosts may need extra attention for approved security scans.

Sandfly allows you to configure your scan schedules with these factors in mind to ensure a minimum impact on your environment and protected hosts. In general, based on your environment, you will want to define groups, mark those hosts through the use of host tags, and then set up separate schedules for the various groupings. Below we will go into details on how to do this.

Grouping

In general, having schedules for various host groups will greatly aid overall performance. There are two aspects to consider for grouping:

By Sandfly Type

Not all sandflies are equal in terms of on-host impact. File, Directory, and to a much less extent Log and User sandflies access the filesystem, whereas Process sandflies affect the CPU. Therefore, separating schedules by the Sandfly Type is one way to reduce associated resource impact.

  • Lower intensity sandfly types (process/user/log) can be scheduled to run more often and/or with larger percentages of sandfly selection. This tier of grouping also includes the active by default Recon sandflies.
  • Higher intensity sandfly types (file/dir) can be scheduled to run less often and/or with smaller percentages of sandfly selection.

By Host Sensitivity

For shared or sensitive hosts you will likely want to put them in their own, small groups and run lighter and/or less frequent scans. Also, if you also have a large quantity of hosts that connect those shared resources, these could also be divided into sub-groups with interleaved schedules so as to not access the shared resource all at once.

Grouping Summary

There is no one single or best scheduling scenario; schedule optimization largely depends on the needs of your own unique environment. With that said, the following high-level areas are a reasonable starting point for the division of hosts into groups towards the end goal of scheduling optimization:

  • Linux hosts that act as a shared resource to other scanned hosts.
  • Linux hosts that are sensitive to scanning and/or have other special access requirements.
  • All other Linux hosts, potentially sub-divided by their roles and/or by interleaving host scans that use the same shared resource.

Tagging

Every scan schedule provides the ability to include and/or exclude hosts based on their host tags. This is the heart of how groups of similar hosts can be set per schedule. Therefore, once there is a plan for how to group hosts, the next step is to tag them with one or more host tags that align with the groupings.

You can tag hosts in bulk on the Hosts Management page via the "Tag" button on the toolbar.

An image of the Bulk Edit Tags form accessed via the Hosts Management page.

Bulk Edit Tagging via Hosts Management

Schedule

The last step is to put this plan into action by setting up the new schedules.

Please refer to our Adding Schedule - Scan Hosts documentation for details on adding scan schedules via the User Interface (UI).

Schedule Option Considerations

Scan schedules are controlled through the use of these schedule options:

  1. A lower and upper range of time between scans, which can reduce overlap on shared resources.
  2. {Optionally} Add a restricted window of time when the scan runs.
  3. Grouping of hosts via included and/or excluded tags.
  4. Sandfly Types, which affects scanned hosts in different ways.
  5. Percentage of selected Sandflies, the larger the percentage the more to run and process.

Example Optimization

To pull together the information that was covered above, we have provided this hypothetical scan schedule optimization case.

There are 4 network blocks (10.1.0.* - 10.1.3.*) of webserver hosts and those hosts all connect into a shared NFS server on a different netblock. There are also 3 networked cameras looking over those hosts.

The NFS server could be tagged "NFS Server" and make 2 scan schedules, one (named "NFS Servers - Process/Log/User Scan") that uses process/user/log/recon at a normal rate and another (named "NFS Servers - File/Dir Scan") which uses file/dir with a lower sandfly selection percentage and, optionally, with a larger time range. Alternatively, the file/dir schedule could use the time window restriction option to run service impacting scans during low or off-peak periods, potentially with more normal schedule times and/or percentages, depending on the desired performance goals.

The webservers could potentially be host tagged based on even and odd numbered network blocks, e.g. "Webserver - Even" for the webservers that are on the 10.1.0.* and 10.1.2.* networks and "Webserver - Odd" for the odd numbered networks. Next, make 4 scan schedules. Two that use process/user/log/recon at a normal rate but have time ranges that are somewhat less likely to overlap. Name those lower impact schedules "Webservers, Odd - Process/Log/User Scan" and "Webservers, Even - Process/Log/User Scan". The second set would use file/dir with a lower sandfly section percentage and most importantly have time ranges that are much less likely to overlap with each other. Name those higher impact schedules "Webservers, Odd - File/Dir Scan" and "Webservers, Even - File/Dir Scan".

The networked cameras could be tagged "Cameras" and make 1 scan schedule just for them which uses all of the Sandfly types but with a lower sandfly selection percentage so as to not overwhelm those devices.