Adding a schedule to scan hosts consists of completing a set of questions that are broken out into three steps.

A new scan schedule form can be opened from the Add Scan button found on the Schedules page. From there, provide the data for the following fields:

Step 1: Schedule

• Name - A textual label for the schedule to know what the scan is related to.
• Timer Lower Limit - The minimum number of minutes to wait before running this schedule again.
• Timer Upper Limit - The maximum number of minutes to wait before running this schedule again.
• Restrict Schedule to a Time Window (optional) - If enabled, runs the schedule only within certain hours.
  • Schedule Begin Hour - The beginning hour, in UTC, that a schedule can initiate a scan.
  • Schedule End Hour - The ending hour, in UTC, that a schedule can initiate a scan.

Step 2: Scan

• Priority - What priority level to run the scan on the remote hosts.
• Host Mode - The setting for determining what hosts are to be included in the scan.
  • Scan All - Scan all active hosts registered.
  • Include or Exclude Hosts by Tag - Scan only hosts with the specified host tags.
    • Include Tags - Only hosts with these tags present will be selected to scan.
    • Exclude Tags - This schedule will NOT scan hosts with these tags.
• Sandfly Type - The sandfly type(s) to run as a part of this schedule.
• Sandfly Selection Percentage - The random percentage of active sandflies to use each time.

Step 3: Clean Up

• Delete Offline and Inactive Hosts (optional) - If enabled, the schedule will delete offline and inactive hosts after the specified period of time.
  • Clean Up Time (hours) - Hours after which to delete the relevant hosts.

---

Field Details

Name

The name is simply a label for recognition of what the schedule is. For instance, if looking only for process attacks, it could be called "process_check". Or name it "60_90" for a check that happens every 60-90 minutes.

Timer Lower Limit

The lower time is the absolute minimum to wait between scans. For instance you can enter a value of 30 in here. That tells Sandfly to never run this schedule sooner than 30 minutes from the last time it was run.

Timer Upper Limit

The upper time delay is the maximum time to wait for this schedule. For instance you can enter 60 minutes here and that tells Sandfly to never wait more than 60 minutes to run this scheduled check.

Sandfly types are what kind of sandflies you want to run. You can for instance have a schedule just for file checks, one for process checks, and one for the rest. You can have these schedules run on different times if you want. Or, you can run them all at once as the example above shows.

As will be discussed under Custom Sandflies, your custom sandflies will be run out of the schedule as well depending on what type you have given them (file, process, directory, user, or log)

It is not possible to run Incident Response sandflies as part of a schedule.

The incident type is a special sandfly designed for deeper inspection such as for incident response. They can cause CPU and disk activity spikes on the remote hosts that could be noticed. Sometimes you may get a false positive due to how the sandflies work (they bias towards reporting the slightest thing wrong vs. being more discriminating).

Operation Window

This section restricts the scheduler to initiate random scans only within the provided time frame. Toggle on the Restrict schedule to a time window field to enable this feature and then set the beginning and ending times. The time fields are in UTC and only the hour portion of the time fields can be changed.

Priority

The priority field allows you to control how many resources the scan uses on the remote systems during a check. The priority internally uses Linux convention for how nice the process should be.

For Sandfly, we use a Linux medium low priority of 10 for the default, represented in the UI as "Low". This is sufficient to ensure Sandfly runs and systems which are under heavy loads are not strained by security sweeps versus their primary tasks.

You can run scans via the API at a lower priority, which would be level 20 on Linux, but this is seldom required. The "Normal" Priority runs at a system priority of 0 (zero) and the "High" Priority runs at a system priority of -10 on the remote systems.

We recommend the default value unless you are getting timeout errors. Timeout errors would only happen under very overloaded systems. In this case you may want to experiment with setting the priority lower to see if it resolves the issue. However it could just be the remote system should be upgraded as it is being worked too hard with expected processes, regardless of Sandfly running or not.

Scan All or Include or Exclude Hosts by Tag

Selecting Scan All tells Sandfly to run the scheduled scans against all registered hosts. This is a reasonable setting for smaller deployments.

Optionally you can setup a scan by using host tags. This means if you had a group of hosts labeled "www" for your web servers you can setup a schedule just for them. Then you could have another group tagged "development" for development systems, etc. Any hosts with the selected tag will be included in or excluded from the scan group when it executes.

Sandfly Types

Sandfly types are what kind of sandflies you want to run. You can for instance have a schedule just for file checks, one for process checks, and one for the rest. You can have these schedules run on different times if you want. Or, you can run them all at once as the example above shows.

As will be discussed under Custom Sandflies, your custom sandflies will be run out of the schedule as well depending on what type you have given them (file, process, directory, user, or log).

It is not possible to run Incident Response sandflies as part of a schedule.

The incident type is a special sandfly designed for deeper inspection such as for incident response. They can cause CPU and disk activity spikes on the remote hosts that could be noticed. Sometimes you may get a false positive due to how the sandflies work (they bias towards reporting the slightest thing wrong vs. being more discriminating).

ℹ️

INFO: Sandfly Schedules For Different Sandfly Types

You can have multiple schedules for different sandfly types. For instance the process check sandflies are generally really fast and low impact. You could set them up to run frequently. The disk check sandflies are still pretty fast, but slower than process checks. You can have them run less frequently. Play around with the scheduling and you will soon figure out what kind of impact it has and what works for your network.

Sandfly Selection Percentage

The sandfly selection percentage tells sandfly to pick a percentage of sandflies that are among the Sandfly Types indicated.

For instance if you activate all sandflies and choose 25%, then Sandfly will randomly select 25% of the sandflies in the user, directory, file, log, and process types. It will then run those sandflies along with all active Recon sandflies, which are not included in the selection percentage, when the schedule indicates.

You can select a lower figure like 10% if you want even lower impact on your remote hosts. You can then combine this with a shorter time window for more frequent but fewer checks all day.

Likewise, you can put it at 100% and force Sandfly to run all sandflies on the schedule. This is not what we recommend, but it can be done if you want to do a really intense scan at longer intervals.

Host Maintenance

Sandfly provides the option to automatically clean up hosts that are offline or inactive after a configurable number of hours. When enabled, this step only affects hosts that would be included as a part of the associated scan schedule.This is particularly beneficial for groups of hosts that change often, such as in a dynamic container environment, thus providing you with more time for security analysis while reducing the need to administer hosts.

The Delete Offline and Inactive Hosts toggle switch is used to enable or disable this option. When enable it gives access to the Cleanup Time (hours) field where the number of hours to keep those hosts can be changed from the default of 72 hours.