Setting Timing for Monitoring

Overview

By default, the settings on this page affect all devices that are monitored in the relevant monitoring mode (real time, periodic polling, or OS monitoring). The administrator can override these settings, for each specific monitored device, in the properties for that device (Monitoring > Devices > select device > Edit configuration). In some cases, the monitoring mode itself can be set there as well.

Polling and fetching, as described on this page, are the same action. This action initially sends a request, from TOS Aurora to the device, to receive policy data. TOS Aurora then compares this data with the last revision received and if there is a difference, the newly updated policy from the device appears in TOS Aurora as a new revision. The difference between polling and fetching is in the context in which they are used.

About Monitoring Settings

The settings on the Timing page include the following:

Timing

  • Real-Time Monitoring: Applies to Cisco, Fortinet, and Juniper devices that have been configured to send syslogs to SecureTrack (unless in the device's properties real-time monitoring has been disabled), and to Check Point management servers:

    • 'Save policy' interval (Applies only to Check Point management servers): When a Save Policy event is followed within this time interval by an Install Policy event for the same policy, SecureTrack tries to combine the two events into a single revision (default: 60 seconds).

    • 'Install policy' interval: When two or more Install Policy events for the same policy occur within this time interval, SecureTrack combines the events into a single Install Policy revision (default: 60 seconds).

    • Automatic fetch frequency: Applies to devices that have been configured to use syslog to notify TOS Aurora when there are policy changes. Its purpose is to initiate a check for policy changes in case syslog messages are not received for more than the time specified. This ensures that the device will be checked for policy changes even if there is no syslog communication, due to network failure or any other reason (frequency (in minutes).

  • Periodic Polling: Applies to TOP and Palo Alto devices, and to Cisco, Fortinet, and Juniper devices that do not send syslogs or that have had real-time monitoring disabled in the device properties:

    Automatic fetch frequency is typically longer than Polling frequency because with real-time monitoring, frequent notifications are expected to be received from the device's syslog, and the action is an additional mechanism that occurs only when syslog notifications are not received at the expected frequency. Polling frequency is the only method of checking for policy changes for devices that do not have syslog configured. Frequent polling is preferred to maintain a more up-to-date picture of the device policy in TOS Aurora.

    • Polling frequency: Determines the frequency at which SecureTrack fetches the configuration from each device. To select an exact time for daily polling, set the polling frequency specifically for each device, in the device's properties.

  • Session timeout: Length of time that SecureTrack waits for a response from device before giving up. This setting is used in case a device is down or too busy. Applies to Automatic fetch (for real-time monitored devices) and to Periodic polling.

  • OS Monitoring:

    • Polling frequency: How often SecureTrack fetches the configuration from each device.

    • Timeout: Controls how long SecureTrack waits for a response from device before giving up. This setting is used in case a device is down or too busy.

    • Retries: Number of attempts that SecureTrack will make.

  • Database Update:

    • Write to database every: Dictates the frequency with which SecureTrack updates its database. The default is every 3600 seconds (1 hour), but this can be changed. When you increase this time, you increase the amount of memory used, but have fewer write actions to the database, which in turn means a smaller amount of disk is required to store the same amount of data. Changing the default database update frequency may adversely affect the responsiveness of your system. Contact Tufin Support before making any changes to the default value.

What Can I do Here?

From the Timing screen, administrators can configure:

  • Timing values for policy retrieval, device polling, and database updating
  • SSH host key mismatch handling where you can choose to replace SSH host key automatically when a new SSH host key is detected for a device

Warning: Automatic replacement of the SSH host key can expose your server to security risks and is not recommended.

For changes to take effect, you must click Save.

How Do I Get Here?

In SecureTrack, go to Monitoring > Timing.