Configuring Monitoring

Once FortiSIEM discovers your devices, they will monitored continuously, and you can use the data collected to analyze the performance of your infrastructure. You can also configure FortiSIEM to send notifications when events that meet specific conditions occur in your infrastructure.

You can disable the collection of metrics for specific devices, disable devices for monitoring, and change the polling interval for metric collection.

Some devices need to be configured to send logs to FortiSIEM, as described in the topics under Configuring External Systems for Discovery, Monitoring and Log Collection. You can also configure FortiSIEM to monitor important ports, processes, and interfaces, and set up monitoring tests that use synthetic transaction to make sure that critical services are up and running.

Device Monitoring Settings

Adding Important Interfaces

Adding Important Processes

Adding Important Ports

Excluding Disks from Disk Capacity Utilization Monitoring

Managing Monitoring of System and Application Metrics for Devices

Setting Up Synthetic Transaction Monitoring Tests

Protocol Settings for Synthetic Transaction Monitoring Tests Adding a Synthetic Monitoring Test to a Business Service

Device Monitoring Settings

While FortiSIEM constantly monitors and reports on your IT infrastructure, there are several settings you can use to refine reporting on critical interfaces, important processes and ports, and disk utilization.

Adding Important Interfaces

Adding Important Processes

Adding Important Ports

Excluding Disks from Disk Capacity Utilization Monitoring

Adding Important Interfaces

This setting allows you to always get interface utilization reports on a set of important network interfaces across all device types.

Important Interface Setup after 4.8.1 Upgrade

The behavior of interface monitoring has dramatically changed since 4.8. So it is very important to follow these steps.

1. Create a list of all Important interfaces
2. Go to Admin > General Settings > Monitoring > Important Interfaces Click Enable. This will stop all interface monitoring.
3. Click
4. Select either Device View or Interface View.
5. Select a device to view and select its interfaces, or select an interface.
6. Click OK to add the selected interface to the list. The Critical and Monitor boxes would be automatically checked.
7. Check the WAN box if applicable. If checked, the interface utilization events would have isWAN = “yes” attribute. You can use this to run a report for all WAN interfaces.
8. Click Apply All. Now FortiSIEM will start monitoring only the selected interfaces in this tab will be monitored.
9. If you want to disable this behavior and return to ALL interface monitoring (as in releases prior to 4.8), then click Disable.

Adding Important Processes

This setting allows you to always get process resource utilization reports and up/down alerts on a set of important processes across all device types.

Important Process Setup after 4.8.1 Upgrade

The behavior of process utilization monitoring has dramatically changed since 4.8. So it is very important to follow these steps.

1. Create a list of all Important interfaces
2. Go to Admin > General Settings > Monitoring > Important Processes Click Enable. This will stop all interface monitoring.
3. Click
4. Enter a Process Name and any Parameters, and then click OK.
5. Click Apply All. Now FortiSIEM will start monitoring only the selected processes in this tab.
6. If you want to disable this behavior and return to ALl interface monitoring, then click Disable.

Adding Important Ports

Always reporting the UP/DOWN status for every TCP/UDP port on every server can consume a significant amount of resources. FortiSIEM will report the UP/DOWN status only for the ports you add to the Important Ports list. Matching is exact based on port number and IP protocol.

1. Go to Admin > General Settings > Monitoring.
2. Under Important Ports, click Add.
3. Enter the Port Number and select the Port Type.
4. Click OK.
5. Click Apply All.

Excluding Disks from Disk Capacity Utilization Monitoring

You can exclude disks from disk capacity utilization monitoring. Disk capacity utilization events will not be generated for devices matching the device name, access IP, and disk name that you provide. Incidents will not trigger for these events, and the disks will not show up in summary dashboards.

2. Under Excluded Disks, click Add.
3. Select a device to to view its disks, and then select the disk you want to exclude from monitoring.
4. Click OK.
5. Click Apply All.

Managing Monitoring of System and Application Metrics for Devices

When FortiSIEM discovers devices, it also discovers the system and application metics that can be monitored for each device, and displays these in the Monitor Change/Performance tab of the Setup Wizard. Here you can also disable the monitoring of specific metrics for devices, disable devices from being monitored, and change the polling interval for specific metrics. See Inspecting Event Pulling Methods for Devices for an explanation of the different status indicators for System Monitor and Application Monitor metrics.

1. Go to Admin > Setup Wizard > Monitor Change/Performance.
2. Click Refresh to make sure you have the latest list of devices.
3. To disable monitoring for a device, clear the Enable option for it.
4. To enable or disable monitoring of a specific metrics for a device, click on a device to select it, then click Edit and select System Monitoring or Application Monitoring to view the list of metrics associated with that monitor and device.
5. To change the polling interval for a metric, in the More menu, select Set Intervals. Select the Monitor Type and Device, and then set the interval.
6. When you are done making changes, click Apply.

Setting Up Synthetic Transaction Monitoring Tests

A Synthetic Transaction Monitoring (STM) test lets you test whether a service is up or down, and measure the response time. An STM test can range from something as simple as pinging a service, to something as complex as sending and receiving an email or a nested Web transaction. Setting up an STM test involves defining the type of monitor, associating the monitor definition to a device and testing it, and then deploying the STM test to a Supervisor or Collector. You can view the results of STM tests in the Synthetic Transaction Monitoring page, either by navigating to Summary Dashboard > Availability/Performance > Application Summary > Synthetic Transaction Monitoring, or to Admin > Setup Wizard > Synthetic Transaction Monitoring, and then clicking on Monitoring Status. You can also report on the results of STM tests in the reports Top Applications By Synthetic Transaction Response Time and Top Applications By Synthetic Transaction Response Time –

Detailed view. When an STM test fails, three system rules are triggered, and you can receive an email notification of that failure by creating a notification policy for these rules.

System Rule	Description
Service Degraded – Slow Response to STM	Detects that the response time of an end-user monitored service is greater than a defined threshold (average over 3 samples in 15 minutes is more than 5 seconds)
Service Down – No Response to STM	Detects a service suddenly went down from the up state and is no longer responding to synthetic transaction monitoring probes.
Service Staying Down – No Response to STM	Detects a service staying down, meaning that it went from up to down and did not come up, and is no longer responding to end user monitoring probes

1. Go to Admin > Setup Wizard > Synthetic Transaction Monitoring.
2. Click Add.
3. Enter a Name and Description for the test.
4. For Frequency, enter how often, in minutes, you want the test to run.
5. Select the Protocol for your test.

See Protocol Settings for Synthetic Transaction Monitoring Tests for more information about the settings and test results for specific protocols.

6. Click Save.

You now have to associate the STM test with a target host name, IP address, or IP range.

7. Click Create and Test.
8. For Monitoring Definition select one of the STM tests you have created.
9. For Host Name or IP/Range, enter the information for your STM test target.
10. For Port, click + and enter any ports to use when connecting to the target with this test.
11. Click OK.

FortiSIEM will run the test and verify if it is successful. If it succeeds, it will be added to the list of tests with a yellow Star next to it, indicating that it has been added but is not yet running.

12. Click Apply All to begin executing your tests at their set frequency.

The yellow Star will be removed from your test after it executes against the target the first time

 

Protocol Settings for Synthetic Transaction Monitoring Tests

This table describes the settings associated with the various protocols used for setting up Synthetic Transaction Monitoring tests.

Protocol	Description	Settings	Notes
Ping	Checks packet loss and round trip time	Maximum Packet Loss PCT: tolerable packet loss Maximum Average Round Trip Time: tolerable round trip time (seconds) from FortiSIEM to the destination and back If either of these two thresholds are exceeded, then the test is considered as failed.
LOOP Email	This test sends an email to an outbound SMTP server and then attempts to receive the same email from a mailbox via IMAP or POP. It also records the end-to-end time.	Timeout: the time limit by which the end to end LOOP EMAIL test must complete. Outgoing Settings: these specify the outgoing SMTP server account for sending the email. SMTP Server: name of the SMTP server User Name: user account on the SMTP server Email Subject: content of the subject line in the test email Incoming Settings: These specify the inbound IMAP or POP server account for fetching the email. Protocol Type: choose IMAP or POP Server: name of the IMAP or POP server User Name: user account on the IMAP or POP server Email Subject: content of the subject line in the test email	Before you set up the test you will need to have set up access credentials  for an outbound SMTP account for sending email, and an inbound POP/IMAP account for receiving email
HTTP(S) – Selenium Script	This test uses a Selenium script to play back a series of website actions in FortiSIEM.	Upload: select the java file you exported from Selenium Total Timeout: the script must complete by this time or the test will be considered failed Step Timeout: each step must complete by this time	How to export: Make sure Selenium IDE is installed within Firefox browser Open Firefox Launch Tools > Selenium IDE. From now on, Selenium is recording user actions Visit websites Once done, stop recording Click File > Export Test case as > Java / Junit 4 /WebDriver Save the file as .java in your desktop. This file has to be inputted in FortiSIEM.
HTTP(S) – Simple	This test connects to a URI over HTTP(s) and checks the response time and expected results	URI: the URI to connect to Authentication: any authentication method to use when connecting to this URI Timeout: this is the primary success criterion – if there is no response within the time specified here, then the test fails Contains: an expected string in the test results Does Not Contain: a string that should not be contained in the test results Response Code: an expected HTTP(S) response code in the test results. The default is set to 200 – 204.

 

HTTP(S) – Advanced	This test uses HTTP requests to connect to a URI over HTTP(s), and checks the response time and expected results	Click + to add an HTTP request to run against a URI. URI: the URI to run the test against SSL: Whether or not to use SSL when connecting to the URI, and the port to connect on Authentication: the type of authentication use when connecting to the URI Timeout: this is the primary success criterion – if there is no response within the time specified here, then the test fails Method Type: the type of HTTP request to use Send Parameters: click + or the Pencil ic on to add or edit any parameters for the request Contains: an expected string in the test results Does Not Contain: a string that should not be contained in the test results Response Code: an expected HTTP(S) response code in the test results. The default is set to 200 – 204. Store Variables as Response Data for Later Use: click + or the Pencil icon to add or edit any variable patterns that should be used as data for later tests
TCP	This test attempts to connect to the specified port using TCP	Timeout: this is the single success criterion. If there is no response within the time specified here, then the test fails.
DNS	Checks response time and expected IP address	Query: the domain name that needs to be resolved Record Type: the type of record to test against Result: specify the expected IP address that should be associated with the DNS entry Timeout: this is the primary success criterion – if there is no response within the time specified here, then the test fails
SSH	This test issues a command to the remote server over SSH, and checks the response time and expected results	Remote Command: the command to run after logging on to the system Timeout: this is the primary success criterion – if there is no response within the time specified here, then the test fails Contains: an expected string in the test results	You will need to have set up an SSH credential on the target server before setting up this test As an example test, you could set Raw Command t o ls, and then set Contains to the name of a file that should be returned when that command executes on the target server and directory

 

 

LDAP	This test connects to the LDAP server, and checks the response time and expected results	Base DN: an LDAP base DN you want to run the test against Filter: any filter criteria for the Base DN Scope: any scope for the test Timeout: this is the primary success criterion – if there is no response within the time specified here, then the test fails Number of Rows: the expected number of rows in the test results Contains: an expected string in the test results Does Not Contain: a string that should not be contained in the test results	You will need to have set up an access credential for the LDAP server before you can set up this test
IMAP	This tests checks connectivity to the IMAP service	Timeout: this is the single success criterion – if there is no response within the time specified here, then the test fails
POP	This test checks connectivity to the IMAP service	Timeout: this is the single success criterion – if there is no response within the time specified here, then the test fails
SMTP	This test checks connectivity to the SMTP service	Timeout: this is the single success criterion – if there is no response within the time specified here, then the test fails
JDBC	This test issues a SQL command over JDBC to a target database, and checks the response time and expected results	JDBC Type: the type of database to connect to Database Name: the name of the target database SQL: the SQL command to run against the target database Timeout: this is the primary success criterion – if there is no response within the time specified here, then the test fails Number of Rows: the expected number of rows in the test results Contains: an expected string in the test results Does Not Contain: a string that should not be contained in the test results
FTP	This test issues a FTP command to the server and checks expected results	Anonymous Login: choose whether to use anonymous login to connect to the FTP directory Remote Directory: the remote directory to connect to Timeout: this is the primary success criterion – if there is no response within the time specified here, then the test fails
TRACE ROUTE	This test issues a trace route command to the destination and parses the results to create PH_DEV_MON_TRACEROUTE events, one for each hop.	Timeout: If there is no response from the system within the time specified here, then the test fails. Protocol Type: Specifies the IP protocol over which trace route packets are send current options are UDP, TCP and ICMP Max TTL: Max time to live (hop) value used in outgoing trace route probe packets. Wait Time: Max time in seconds to wait for a trace route probe response	For the trace route from AO to destination D via hops H1, H2, H3, FortiSIEM generates 3 hop by hop PH_DEV_MON_TRACEROUTE events. First event: Source AO, destination H1, Min/Max/Avg RTT, Packet Loss for this hop Second event: Source H1, destination H2, Min/Max/Avg RTT, Packet Loss for this hop Third event: Source H2, destination H3, Min/Max/Avg RTT, Packet Loss for this hop Fourth event: Source H3, destination D, Min/Max/Avg RTT, Packet Loss for this hop

Adding a Synthetic Monitoring Test to a Business Service

You may want to add a Synthetic Transaction Monitoring (STM) test to a Business Service as part of the monitoring infrastructure for that service. However, in order to enable reporting on that STM, you need to add it to the business service as a device that FortiSIEM can then report on. This topic explains how to create a device for an STM test and add it to your business service report.

1. Create your STM as described in Setting Up Synthetic Transaction Monitoring Tests.
2. Note the IP address that your STM resolves to in Step 9 of the setup instructions.
3. In the CMDB tab, select Devices, and then select a subcategory where you want to add the STM device.

You may want to create your own group where you manage your STM devices.

4. In the summary pane for the device subcategory, click New.
5. Complete all relevant information for the STM device, providing the IP address/range from Step 2 in the Access IP field of the Summary
6. Click Save when you’re done entering device information for the STM.
7. Follow the instructions in Creating a Report to add information about the STM device to a business service report, and then use the instructions in Adding Widgets to Dashboards to add it to your dashboard.

Related Links

Adding Devices to the CMDB Outside of Discovery

Creating CMDB Groups and Adding Objects to Them

Creating a Report

Adding Widgets to Dashboards

 

Creating Dynamic CMDB Group Policies

This setting allows you to write rules to put devices in CMDB Device Group and Business Service Groups of your choice. When a device is discovered, the policies defined here are applied and the device is assigned to the group(s) defined in the matching policies.

To create a new CMDB Group Policy

1. Go to Admin > General Settings > Discovery > CMDB Group
2. Click Add
3. For matching conditions – enter the following information
   1. Organization – the organization which this rule applies to
   2. Vendor – the matching device vendor – select from the list
   3. Model – the matching device model – select from the list
   4. Host Name – matching device host name via regular expression match
   5. IP Range – matching device access IP – format is single IP, IP range, CIDR
4. For Actions (Add To) – enter the following information
   1. Groups – specify the groups which the matching devices will be added to
   2. Biz Services – specify the business services which the matching devices will be added to

To apply one or more CMDB Group policies,

1. Select one or more policies and click Apply or Click Apply All to apply all policies.
2. Once a policy is saved, then next discovery will apply these policies. That means, discovered devices will belong to the groups and business services defined in the policies.

Decommissioning a device

Decommissioning a device lets you re-assign the IP address to a new device but still keep the old device in CMDB for historical purposes.

To decommission a device

1. Go to CMDB > Devices 2. Select the device.
2. Click on the menu under Name and select Decommission.
3. Provide a Reason and Select OK to decommission the device
4. Consequences of decommissioning
   1. Device will be moved to CMDB > Devices > Decommission folder
   2. Device will be removed from maintenance calendars
   3. Performance monitoring will stop
   4. A new device with the same IP can be discovered

To re-commission the device

1. Go to CMDB > Devices > Decommission 2. Select the device.

3. Click on the menu under Name and select Recommission.
4. The device will be moved back to the folder where it was when it was decommissioned. 5. Performance monitoring will resume

Adding Devices to the CMDB Outside of Discovery

There are situations in which you may want to add devices to the Configuration Management Database (CMDB) outside of the discovery procedure. For example, FortiSIEM needs access to devices over SNMP or WMI to discover them, but you may have devices in your

infrastructure that don’t utilize these access protocols. The IP addresses for those devices will still be contained in traffic logs, and rules may need to incorporate that device. In order to make sure that logs are parsed correctly and rules function as expected, you need to make sure that these undiscovered devices are associated with an IP address. Adding a device directly to the CMDB lets you provide the information necessary for FortiSIEM to recognize the device, including associating it with an IP address or range.

Adding Devices to Device Groups

When you add a device to the CMDB manually, make sure to choose the group, such Firewall, Printers, or Storage, in the Device View where you want to add it. If you only add it to the top-most Devices group, it will not be added to the topology map correctly.

1. Log into your Supervisor node.
2. Click CMDB.
3. In the Device View, select Devices, then select the sub-category where you want to add the device.
4. In the summary pane, click New.
5. For Summary, Contact, Interfaces, and Properties, enter information for the new device.

Entering Interface Information

When you enter the interface information for the device, make sure to provide the correct IP address and network mask for the interfaces. FortiSIEM will use this network information to generate the Network Segments for the device.

6. Click Save when you’re done adding the device information.

Related Links

Adding a Synthetic Monitoring Test to a Business Service

Scheduling a Discovery

Discovery can be a long-running process when performed on a large network, or over a large IP range, and so you may want to schedule it to occur when there is less load on your network or during off hours. You may also want to set up a schedule for the process to run and discover new devices on a regular basis.

1. Log in to your Supervisor node.
2. Go to Admin > Setup Wizard > Discovery.
3. Click Schedule.
4. Click the +
5. Select from the available ranges.

You can select multiple ranges and set the order in which discovery will run on them by using the up and down arrows.

6. Set the time at which you want discovery to run.
7. For a one-time scheduled discovery, enter a Date for the discovery to run.
8. For recurring discoveries, select how often (hourly, daily, weekly, monthly), you want discovery to run, and then enter other scheduling options.
9. Click OK.

 

Discovery Range Definition Options

When you set the range definition for your discovery processes, several options are available for how you want the discovery process to run.

Option	Description
Discovery Type	Four types of scans are available for the discovery process: Smart Scan Smart Scan is an optimized search method in which only the live devices in the network are searched. To use Smart Scan, you first provide a root device (typically the first hop Layer 3 router). FortiSIEM then discovers the root device and learns of its first hop neighbors from the ARP table. These devices are then discovered using existing credentials, and their one hop neighbors are subsequently discovered. This continues until no more devices are discovered. Often a single Layer 3 router, switch, or firewall is sufficient to discover the entire network. However, if a firewall that can block SNMP is installed, then devices on either side of the firewall need to be provided as root devices. Smart Scan is usually faster than Range Scan, but in rare cases discovery can miss a device when it is quiet and not present in the ARP table of adjacent devices. Range Scan (d efault) In contrast to Smart Scan, Range Scan is a brute force method in which FortiSIEM attempts to discover all the devices in the IP ranges you provide. With Range Scan, FortiSIEM will first attempt to ping a device, and if that succeeds, discovery will proceed. AWS Scan AWS Scan is used to discover devices in Amazon Web Services. See Discovering Amazon Web Services (AWS) Infrastructure for more information. L2 Scan L2 Scan is used to update the Layer 2 connectivity information used in the Identity and Location report. It does not discover system and application monitors, installed and running software, or users and groups, and, in contrast to the other scan methods, it does not update the CMDB and executes more quickly.
Root IPs	For Smart Scan only, provide the root IPs from which you want the Smart Scan to start.
Include/Exclude Domains (AWS Only)	Enter the domains you want to include or exclude from the discovery process.
Include/Exclude Zones (AWS Only)	Enter the zones you want to include or exclude from the discovery process.
Include/Exclude Ranges	Enter the IP addresses or host names you want to include or exclude from the discovery process.
Include/Exclude Device Types	Click the Edit icon to select devices that you want to include or exclude from the discovery process. Note that if you have entries for both of these option, the discovery process will prioritize included devices over excluded ones.
Do Not Ping Before Discovery	To save time, FortiSIEM first attempts to reach devices by ping before initiating discovery. You should select this option if ping has been disabled for your network, otherwise discovery will fail.
Ping Only Discovery	Select this option if you are only interested in discovering whether a device or service is up or down.
Only Discover Devices not in CMDB	If you select this option, discovery will only find those devices whose IP addresses do not match the address of any device in CMDB. To make an exception to this rule, specify a list of IP addresses in the Exclude Ranges field. The primary use case for this is for indirect device discovery such as VCenter-based VM discovery, or WLAN controller-based access point discovery. By specifying the VCenter IP address in the Exclude Ranges field, new guest VMs can always be discovered even if the VCenter is already in the CMDB.
Include Powered Off VMs	By default, only powered on VMs are discovered.
Include VM Templates	By default, VM templates are not discovered.
Discover Routes	Selected by default, if you clear this option then discovery will not use the route table to find next hop devices. This can be useful if your network includes border routers, which can significantly impact the time required for the discovery process.

Inspecting Changes Since Last Discovery

After you run discovery for the first time, FortiSIEM keeps track of changes to your discovered devices during subsequent discovery runs, including new devices, changed devices, and failed devices.

1. Log in to your Supervisor node.
2. Go to Admin > Discovery Results.
3. Select a discovery result.
4. Click View Changes.
5. Expand the folder Discovery Delta.
6. Move your mouse cursor over a folder or item until a blue Information icon appears, and then click on the icon to view basic information about the item.

 

Inspecting Event Pulling Methods for Devices

Once you have discovered and approved the devices in your IT infrastructure, you should verify that the FortiSIEM perfMonitor module is polling them over the correct access protocol and pulling event information from them. If you are having issues collecting performance metrics from your devices, you should begin troubleshooting by first checking the status of the event pulling method for the device.

1. Go to Admin > Setup Wizard > Pull Events.
2. Review the Event Pulling Status for each of your discovered devices.

Status	Description
Successful	If event information is being pulled from the device, you will see the name of the event pulling method rendered in plain black text.
Added but Not Monitored	If the name of the event pulling method has a Star icon next to it, event information can be successfully pulled from the device, but the perfMonitor module has not yet initiated monitoring.
Paused	A Pause icon indicates that event information is not being pulled from the device because it failed the verification check at the beginning of the monitoring cycle. This is usually caused by an issue with the access protocol credentials. The credential was valid when discovery succeeded, and so the event pulling method was able to monitor the associated metrics, but the perfMonitor module failed on the credential at a later time. You should check the access protocol credentials associated with the devices and event pulling methods, and then re-initiate discovery of the device.
Failed	An Alert icon and the name of the event pulling method in red indicates that adding that event pulling method for the device failed.

3. Click Show Errors to view a more detailed description of any errors associated with an event pulling method.
4. Click Edit to change any of the event pulling methods associated with a device.
5. Click Apply to apply any changes to your event pulling methods.
6. Click Test Pull Events to test any changes you make.