Discovering Devices

Prerequisites

Make sure you have configured the Discovery Settings for your deployment

Set up the Access Credentials for your devices so FortiSIEM can communicate with them

Procedure

After you have set up the access protocols for your devices as described in Setting Access Credentials for Device Discovery, you are ready to discover devices in your IT infrastructure.

1. Log in to your Supervisor node.

Discovering Devices for Multi-Tenant Deployments

If you have a multi-tenant FortiSIEM deployment that uses Collectors and you and want to discover devices for a specific organization, rather than the Global organization, log into your Supervisor node as an admin user for that organization. See Dis covery for Multi-Tenant Deployments for more information about how discovery works for multi-tenant deployments with and without Collectors.

2. Go to Admin > Setup Wizard > Discovery.
3. Click Add.

You can also schedule single or recurring discovery processes as described in Scheduling a Discovery.

4. In the Range Definition dialog, set the options for this discovery.

See Discovery Range Definition Options for more information about the options available in this dialog.

5. Click OK.

Your range definition will be added to the list.

6. Select your range definition, and then click Discover.

A discovery dialog will show you the progress of your discovery. For long-running discoveries, you can use the Run in Background optio n.

7. When discovery completes, the results will be displayed in the dialog. Click Errors to view any errors.

Possible Causes of Discovery Errors

If there are errors during the discovery process, the Errors screen will inform you of their severity, impact, and potential resolution. Some possible reasons for errors include:

A device is not online or not reachable via ping. FortiSIEM will attempt to ping devices before initiating a full discovery to save time.

A device is not responding to SNMP or WMI requests, or there is a firewall blocking these requests from FortiSIEM The SNMP/WMI credentials are incorrect

WMI may not have been set up correctly on the server. See the appropriate topic under Configuring External Systems for Discovery, Monitoring and Log Collection for how to configure WMI for your device.

Approving Newly Discovered Devices

If you selected Approved Devices Only for the discovery setting Allow Incident Firing On, as described in Discovery Settings, then you will need to approve your newly discovered devices before incidents will be triggered for those devices. See Approving Newly Discovered Devices for more information.

Discovering Amazon Web Services (AWS) Infrastructure

Discovering infrastructure in AWS follows the same basic process described in Setting Access Credentials for Device Discovery and Discovering Devices, but requires a different approach to associating credentials to IP addresses, since AWS uses dynamic, rather than static, IP address assignment. The generic AWS SDK credential is used to discover Amazon Machine Instances (AMIs) and associated information such as host name, instance ID, and instance state, while credentials for generic versions of WMI, SMTP, and other access protocols are used to discover associated devices as you would for any other discovery process.

Setting Access Credentials for AWS Instances

Associating the AWS Host with Credentials

If you have not already configured Access Keys and permissions on AWS, please follow the steps outlined in AWS Access Key IAM Permissions and IAM Policies.

Setting Access Credentials for AWS Instances

1. Log into your Supervisor node.
2. Go to Admin > Setup Wizard > Discovery.
3. Under Enter Credentials, click Add.
4. Enter a Name for the credential.
5. For Device Type, select Amazon AWS SDK.
6. For Access Protocol, select AWS SDK.
7. For Region, enter the region where your AWS instance is located.
8. Enter the Access Key ID and Secret Access Key associated with your AWS instance.
9. Click Save.

Associating the AWS Host with Credentials

After you’ve defined all the credentials associated with the access protocols used by devices in your AWS instance, you need to associate those credentials to the AWS host. In other deployment configurations, you would associate credentials with IP addresses corresponding to your device locations, but since AWS uses dynamic IP addressing, you need to associate all your credentials to the same host.

1. Under Enter IP Range to Credential Associations, click Add.
2. For IP/Host Name, enter com.
3. Click +, and add the AWS SDK credential, as well as any other generic credentials you’ve created.
4. Click OK.
5. Click Test Connectivity to make sure you can reach your instance and that all credentials are entered correctly before you initiate discovery.

Both the connectivity test and the discovery process will try to connect to the Amazon instances first, and from there will try to connect to the private IPs of discovered instances using the other access protocols.

6. You can now initiate discovery of your instances and associated devices as described in Discovering Devices, but for Discovery Type, select AWS Scan.

If discovery is successful, your discovered instances and devices will be added to Admin > Setup wizard > Monitor Change/Performance, and in CMDB > Devices, you will see an Amazon EC2 directory, which will include your discovered instances. If you have defined other access credentials, the discovered devices will also appear in that directory, as well as under CMDB > Server. You can query these devices from either directory.

Discovering Microsoft Azure Infrastructure

Discovering Microsoft Azure Cloud infrastructure follows the same basic process described in Setting Access Credentials for Device Discovery an d Discovering Devices, but requires a different approach to associating credentials to IP addresses, since Azure uses dynamic, rather than static, IP address assignment.

Create a Certificate file for communicating to Azure Management Server

Setting Access Credentials for Microsoft Azure Discovery

Associating Microsoft Azure with Credentials

Discovering Microsoft Azure Compute Nodes

Create a Certificate file for communicating to Azure Management Server

3. Login to the Azure old portal, upload the .cer to the Settings->”Management Certificates” section.

Setting Access Credentials for Microsoft Azure Discovery

1. Log into your Supervisor node.
2. Go to Admin > Setup Wizard > Credentials.
3. Under Enter Credentials, click Add.
4. Enter a Name for the credential.
5. For Device Type, select Microsoft Azure Compute.
6. For Subscription ID, enter .
7. Upload the Certificate File, enter the region where your AWS instance is located.
8. Enter the Access Key ID and Secret Access Key associated with your AWS instance.
9. Click Save.

Associating Microsoft Azure with Credentials

After you’ve defined all the credentials associated with the access protocols used by devices in your Microsoft Azure instance, you need to associate those credentials.

1. Log into your Supervisor node.
2. Go to Admin > Setup Wizard > Credentials.
3. Under Enter IP Range to Credential Associations, click Add.
4. For IP/Host Name, enter com.
5. Click +, and add the Microsoft Azure Compute credential created in “Setting Access Credentials for Microsoft Azure Discovery”, as well as any other generic credentials you’ve created.
6. Click OK.
7. Click Test Connectivity to make sure you can reach your instance and that all credentials are entered correctly before you initiate discovery.

Discovering Microsoft Azure Compute Nodes

After you’ve defined and tested all the credentials, you can proceed to discovery.

1. Log into your Supervisor node.
2. Go to Admin > Setup Wizard > Discovery.
3. Click Add
4. For Discovery Type, select Azure Scan.
5. Click
6. Select the entry just created and click

If discovery is successful, your discovered instances will be added to Admin > Setup wizard > Monitor Change/Performance and CMDB > Devices > Microsoft Azure Cloud > Azure Compute.

Approving Newly Discovered Devices

When devices are discovered by FortiSIEM, monitoring of them begins automatically, and incidents for those devices will trigger automatically based on the rules associated with that device. However, you can configure the Discovery Settings so incidents will be triggered only for devices you approve. If you select Approved Devices Only for Allow Incident Firing On, then you will need to approve devices before incidents will be triggered for those devices, but they will still be monitored and added to the CMDB.

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. Expand the folder New Devices.
7. Select the devices you want to approve, and click Approve Selected.

You can approve all the new devices by selecting the New Devices folder, and then click Approve All.

Related Links

Discovery Settings

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.

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.

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.

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.

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.

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

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

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.

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.

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.

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 Business/IT Services

By defining an IT or Business Service, you can create a logical grouping of devices and IT components which can be monitored together.

1. Log in to your Supervisor node.
2. Go to CMDB > Business Services.
3. Click New.
4. Enter a Name and Description for the business service.
5. Select a Device/Application Group, and when the list of associated devices loads into the selection pane, select a device and click >> t o add it to the Selected Devices/Applications for the business service.
6. Click Save when you’re done adding devices to the business service.

After you have created a business service, you can select it, and the Show Topology option, to view it within overall IT topology. You can also use the links in the Analysis menu of the Business Services summary dashboard to find out more information about incidents, device availability, device and application performance, interface and event status, and real-time and historical search for a selected business service.

Data Update Subscription Service

FortiSIEM is constantly developing support for additional IT infrastructure devices. By subscribing to the FortiSIEM Data Update Service, you can receive updates when support for new devices becomes available, rather than waiting for it to be included in a formal release. In addition to devices you can also receive new rules, reports, parser updates etc.

Data Update Overview

Configuring Data Update

Data Update Overview

FortiSIEM data update subscription service updates your FortiSIEM deployment with the latest device support related data as it becomes available, rather than having to wait for it to be included in a formal release.

The following items can be included in an update

New event attribute

New event types

New device type

New parsers or modifications for existing parsers

Performance monitoring templates for new devices or modified ones for existing devices

New rules or modifications for existing rules

New reports or modifications for existing reports – both CMDB report and event based reports

New groups or modifications for existing groups for Event Types, Rules, Reports, Device Groups, Application Groups Code to handle new devices

Configuring Data Update

Provide a brief (two to three sentence) description of the task or the context for the task.

Prerequisites

Procedure

Configure Data Update Server Setting

Check Available Data Updates

Apply Data Update on Supervisor

Apply Data Update on Collectors

Check whether Data Update Installed Successfully

Prerequisites

Contact FortiSIEM support and make sure that your license includes Data Update Service

Make sure you have Data Update URL – this is typically https://images.FortiSIEM.net/upgrade/ds – contact FortiSIEM to make sure that this information has not changed

Make sure you have license credentials

Procedure

Configure Data Update Server Setting

1. Log on to FortiSIEM Supervisor with Administrator credentials
2. Go to Admin > General Settings > System
3. Configure Data Update Server Setting
   1. Enter Data Update URL (see prerequisites)
   2. Enter Server Username and Server Password – these are the license credentials
   3. Specify Notify Email (optional) – you will receive email when new data updates are available d. Click Save

Check Available Data Updates

1. Log on to FortiSIEM Supervisor with Administrator credentials
2. Go to Admin > Data Update
3. Click Refresh
   1. Available data updates are shown on left
   2. Click a version on the left and the contents for that version is shown on the right
4. Check the current data version from Admin > Cloud Health > Data Update Version. The number after 3rd decimal is the data version. For example 4.4.1.38 means data version is 38.
5. Note the data version you would like to upgrade to.

Apply Data Update on Supervisor

1. SSH to FortiSIEM Supervisor as root
2. Go to /pbin
3. Download the data version by running ./phdownloaddata and specify the data version you would like to upgrade to
4. Install the data version by running ./phinstalldata

Apply Data Update on Collectors

1. Log on to FortiSIEM Supervisor with Administrator credentials
2. Go to Admin > Collector Health
   1. Select a Collector
   2. Click Download Data Update – this downloads the data files to the collector
   3. Click Install Data Update – this installs the data files on the collector
   4. Repeat for all collectors

Check whether Data Update Installed Successfully

1. Log on to FortiSIEM Supervisor with Administrator credentials
2. Check Admin > Cloud Health > Data Update Version
3. Check Admin > Collector Health > Data Update Version

Creating Custom Parsers and Monitors for Devices

Creating a custom parser for device logs involves writing an XML specification for the parser, and then using a test event to make sure the logs are parsed correctly. Creating a custom monitor involves defining a performance object that you want to monitor, associating that performance object to a device type, event type, and event attribute type, and then testing to make sure that the monitored metrics are correctly received by FortiSIEM. You can create custom monitors for system and application performance, command outputs, and file monitoring.

Creating a Custom Multi-Line SSH Command Output Monitor

Creating a Custom WINEXE Command Output Monitor

Custom File Monitor

Agent-less File-Integrity Monitoring

Agent-less Target File Monitoring Custom Configuration Change Monitoring

Creating Event Attributes, Event Types, and Device Types

When you create a custom parser or monitor, you must also specify the device, application, event type, and event attribute to which it applies. If these objects aren’t already included in the FortiSIEM CMDB, you can create them as a preliminary step to creating your parser or monitor.

Creating Device and Application Types

Creating Event Attribute Types Creating Event Types

Creating Device and Application Types

If the device or application that you want to create a parser or monitor for isn’t already listed in Admin > Device Support > Device/App Types, you can add it.

1. Go to Admin > Device Support > Device/App Types.
2. Click New, and then choose New Device Type or New Application Type.
3. Enter the information for the new device or application type.

4. Click Save.

Creating Event Attribute Types

Event attributes are used to capture parsed information from events. You only have to create a new attribute if the one you want use for your custom parser or monitor is not listed in Admin > Device Support > Event Attribute Types.

2. Click New.
3. Enter a Name and Display Name.
4. Select the Value Type to associate with the event attribute type.
5. Optionally enter a Display Format Type and Description.
6. Click Save.

Creating Event Types

After parsing an event or log, FortiSIEM assigns a unique event type to that event/log. When you create a new custom parser for device logs, you almost always have to add a new event type to FortiSIEM so the log events can be identified.

1. Go to Admin > Device Support > Event Types.
2. Click New.
3. Enter a Name for the new event type.
4. Select the Device Type to associate with the event type.

If the device type isn’t included in the menu options, you can add it to FortiSIEM.

5. Select the Event Type Group category for this event type.
6. Select a Severity to associate with the event type.
7. Enter an optional Description.
8. Click Save.

Custom Parsers

To start creating a custom parser for device logs, you should begin by reviewing the Event Parser XML Specification. Writing the XML specification is the primary task in creating a custom parser.

Event Parser XML Specification

Custom Parser XML Specification Template

Parser Name Specification

Device or Application Type Specification

Format Recognizer Specification

Pattern Definition Specification

Parsing Instructions Specification

Creating a Custom Parser

Deleting or Disabling a Parser

Exporting a Custom Parser

Importing a Custom Parser

Parser Examples

Cisco IOS Syslog Parser

Event Parser XML Specification

FortiSIEM uses an XML-based parser framework to parse events. These topics describe the parser syntax and include examples of XML parser specifications.

Custom Parser XML Specification Template

Parser Name Specification

Device or Application Type Specification

Format Recognizer Specification

Pattern Definition Specification

Parsing Instructions Specification

Custom Parser XML Specification Template

The basic template for a custom parser XML specification includes five sections. Click on the name of any section for more information.

Custom Parser XML Specification Template

Parser Name Specification

This section specifies the name of the parser, which is used only for readability and identifying the device type associated with the parser.

Device or Application Type Specification

This section specifies the device or the application to which this parser applies. The device and application definitions enable FortiSIEM to detect the device and application type for a host from the received events. This is called log-based discovery in FortiSIEM. Once a received event is successfully parsed by this file, a CMDB entry is created with the device and application set from this file. FortiSIEM discovery may further refine the device.

There are two separate subsections for device and application. In each section, vendor, model and version can be specified, but version is not typically needed.

Examples of Specifications for Types of Device and Applications

Hardware Appliances

In this case, the type of event being parsed specifies the device type, for example Cisco IOS, Cisco ASA, etc.

Software Operating Systems that Specify the Device Type

In this case, the type of events being parsed specifies the device type, for example Microsoft Windows etc. In this case the device type section looks like

Applications that Specify Both Device Type and Application

In this case, the  events being parsed specify the device and application types because Microsoft SQL Server can only run on Microsoft Windows OS.

Applications that Specify the Application Type but Not the Device Type

Consider the example of an Oracle database server, which can run on both Windows and Linux operating systems. In this case, the device type is set to Generic but the application is specific. FortiSIEM depends on discovery to identify the device type.

Format Recognizer Specification

In many cases, events associated with a device or application will contain a unique pattern. You can enter a regular expression in the Format Recognizer section of the parser XML file to search for this pattern, which, if found, will then parse the events according to the parser instructions. After the first match, the event source IP to parser file map is cached, and only that parser file is used for all events from that source IP. A notable exception is when events from disparate sources are received via a syslog server, but that case is handled differently.

While not a required part of the parser specification, a format recognizer can speed up event parsing, especially when one parsing pattern file among many pattern files must be chosen. Only one pattern check can determine whether the parsing file must be used or not. The other less efficient option would be to examine patterns in every file. At the same time, the format recognizer must be carefully chosen so that it is not so broad to misclassify events into wrong files, and at the same time, not so narrow that it fails at classifying the right file.

Format Recognizer Syntax

The specification for the format recognizer section is:

In the regexpattern block, a pattern can be directly specified using regex or a previously defined pattern (in the pattern definition section in this file or in the GeneralPatternDefinitions.xml file) can be referenced.

Example Format Recognizers

Cisco IOS

All Cisco IOS events have a %module name pattern.

Cisco ASA

All Cisco ASA events have the pattern ASA-severity-id pattern, for example ASA-5-12345.

Palo Alto Networks Log Parser

In this case, there is no unique keyword, so the entire message structure from the beginning to a specific point in the log must be considered.

Event

<14>May 6 15:51:04 1,2010/05/06 15:51:04,0006C101167,TRAFFIC,start,1,2010/05/06

15:50:58,192.168.28.21,172.16.255.78,::172.16.255.78,172.16.255.78,rule3,,,icmp,vsys1,untrust,untrust,ether net1/1,ethernet1/1,syslog-172.16.20.152,2010/05/06

15:51:04,600,2,0,0,0,0,0×40,icmp,allow,196,196,196,2,2010/05/06 15:50:58,0,any,0

Pattern Definition Specification

In this section of the parser XML specification, you set the regular expression patterns that that FortiSIEM will iterate through to parse the device logs.

You can also write a long pattern definition in multiple lines and indicate their order as shown in this example. The value of the list attribute should be begin in first line and end in last line. If there are more than two lines, the attribute should be set to continue for the other lines.

Parsing Instructions Specification

This section is the heart of the parser, which attempts to recognize patterns in a log message and populate parsed event attributes.

In most cases, parsing involves applying a regular expression to the log, picking up values, and setting them to event attributes. Sometimes the processing is more involved, for example when attributes need to be stored as local variables and compared before populating the event attributes. There are three key components that are used in parsing instructions: Event attributes and variables, inbuilt functions that perform operations on event attributes and variables, and switch and choose branching constructs for logical operations. Values can be collected from both unstructured and structured strings in log messages.

Event Attributes and Variables

Setting an Event Attribute to a Constant

Setting an Event Attribute from Another Variable

Inbuilt Functions

Combining Two or More Strings to Produce a Final String

Normalize MAC Address

Compare Interface Security Level

Convert Hex Number to Decimal Number

Convert TCP/UDP Protocol String to Port Number

Convert Protocol String to Number

Convert Decimal IP to String

Convert Host Name to IP

Add Two Numbers

Divide Two Numbers

Scale Function

Extract Host from Fully Qualified Domain Name

Replace a String Using a Regular Expression

Replace String in String

Resolve DNS Name

Convert to UNIX Time

Trim Attribute

Branching Constructs

Choose Construct

Switch Construct

Collecting Values from Unstructured Strings

Collecting Fields from Structured Strings

Key=Value Structured Data

Value List Structured Data

Event Attributes and Variables

The dictionary of event attributes are defined in FortiSIEM database and any member not belonging to that list is considered a local variable. For readability, local variables should begin with an _, although this is not enforced.

Setting an Event Attribute to a Constant

Setting an Event Attribute from Another Variable

The $ symbol is used to specify the content of a variable. In the example below, attribute hostMACAddr gets the value stored in the local variable

Combining Two or More Strings to Produce a Final String

This is accomplished by using the combineMsgId function. Here _evIdPrefix is the prefix, _evIdSuffix is the suffix, and the output will be s tring1-_evIdPrefix-_evIdSuffix.

Normalize MAC Address

This is accomplished by using the normalizeMAC function. The output will be six groups of two nibbles separated by a colon, for example AA:BB

This is accomplished by using the compIntfSecVal function. This primarily applies to Cisco ASA and PIX firewalls. The results returned are:

This is accomplished by using the convertHexStrToInt function.

Convert TCP/UDP Protocol String to Port Number

This is accomplished by using the convertStrToIntIpPort function.

Convert Protocol String to Number

This is accomplished by the using the convertStrToIntIpProto function.

Convert Decimal IP to String

This is accomplished by using the converIpDecimalToStr function.

Convert Host Name to IP

This is accomplished by using the convertHostNameToIp function.

Add Two Numbers

This is accomplished by using the add function.

Divide Two Numbers

This is accomplished by using the divide function.

Scale Function

This is accomplished by using the scale function.

Extract Host from Fully Qualified Domain Name

This is accomplished by using the extractHostFromFQDN function. If _fqdn` contains a . , get the string before the first .,  otherwise, get the whole string.

Replace a String Using a Regular Expression

This is accomplished by using the replaceStringByRegex function.

Replace String in String

This is accomplished by using the replaceStrInStr function.

Resolve DNS Name

This is accomplished by using the resolveDNSName function, which converts DNS name to IP address.

Convert to UNIX Time

This is accomplished by using the toDateTime function.

Trim Attribute

This is accomplished by using the trimAttribute function. In the example below, it is used to trim the leading and trailing dots in destName.

Branching Constructs

Choose Construct

The format is:

Switch Construct The format is:

Collecting Values from Unstructured Strings

From a string input source, a regex match is applied and variables are set. The variables can be event attributes or local variables. The input will be a local variable or the default raw message variable. The syntax is:

The regexpattern is specified by a list of variables and sub-patterns embedded within a larger pattern. Each variable and sub-pattern pair are enclosed within <>.

Consider an example in which the local variable _body is set to list 130 permitted eigrp 172.16.34.4(Serial1 ) > 172.16.34.3, 1 packet. From this sting we need to set the values to local variables and event attributes.

This is achieved by using this XML. Note that you can use both the collectAndSetAttrByRegex and collectFieldsByRegex functions to collect values from fields.

Collecting Fields from Structured Strings

The are usually two types of structured strings in device logs:

Key=value structured

Value list structured

In each case, two simpler specialized parsing constructs than are provided

Key=Value Structured Data

Certain logs, such as SNMP traps, are structured as Key1 = value1 <separator> Key2 = value2,…. These can be parsed using the col lectAndSetAttrByKeyValuePair XML attribute tag with this syntax.

When a key1 match is found, then the entire string following key1 up to the separatorString is parsed out and stored in the attribute variab leOrEventAttribute1.

As an example, consider this log fragment.

_body =

SNMPv2-SMI::enterprises.14823.2.3.1.11.1.1.60 = Hex-STRING: 07 D8 06 0B

13 15 00 00 2D 07 00    SNMPv2-SMI::enterprises.14823.2.3.1.11.1.1.11.0

= Hex-STRING: 00 16 B6 DB 12 22

SNMPv2-SMI::enterprises.14823.2.3.1.11.1.1.12.0 = Hex-STRING: 00 21 55

4D 66 B0  SNMPv2-SMI::enterprises.14823.2.3.1.11.1.1.13.0 = INTEGER: 36

SNMPv2-SMI::enterprises.14823.2.3.1.11.1.1.1.0 = Hex-STRING: 00 1A 1E C0

60 7A  SNMPv2-SMI::enterprises.14823.2.3.1.11.1.1.56.0 = INTEGER: 2   SNMPv2-SMI::enterprises.14823.2.3.1.11.1.1.17.0 = STRING:

“00:1a:1e:c0:60:7a”

The corresponding parser fragment is:

After parsing, the attribute values are set:

Value List Structured Data

Certain application logs, such as those from Microsoft IIS, are structured as a list of values with a separator. These can be parsed using the coll ectAndSetAttrByPos XML attribute tag following this syntax.

When the position offset1 is encountered, the subsequent values up to the separatorString is stored in variableOrEventAttribute1.

As an example, consider this log fragment.

The parser fragment is:

<collectAndSetAttrByPos src=”$_body” sep=’  ‘>

<attrPosMap attr=”srvInstName” pos=’1’/>

<attrPosMap attr=”destName” pos=’2’/>

<attrPosMap attr=”relayDevIpAddr” pos=’2’>

<attrPosMap attr=”destIpAddr” pos=’3’/>

<attrPosMap attr=”httpMethod” pos=’4’/>

<attrPosMap attr=”uriStem” pos=’5’/>

<attrPosMap attr=”uriQuery” pos=’6’/>

<attrPosMap attr=”destIpPort” pos=’7’/>

<attrPosMap attr=”user” pos=’8’/>

<attrPosMap attr=”srcIpAddr” pos=’9’/>

<attrPosMap attr=”httpVersion” pos=’10’/>

<attrPosMap attr=”httpUserAgent” pos=’11’/>

<attrPosMap attr=”httpReferrer” pos=’13’/>

<attrPosMap attr=”httpStatusCode” pos=’15’/>

<attrPosMap attr=”httpSubStatusCode” pos=’16’/>

<attrPosMap attr=”httpWin32Status” pos=’17’/>

<attrPosMap attr=”recvBytes” pos=’18’/>

<attrPosMap attr=”sentBytes” pos=’19’/>

<attrPosMap attr=”durationMSec” pos=’20’/>

</collectAndSetAttrByPos>

For structured strings, techniques in this section are more efficient than in the previous section since, the expression is simpler and ONE tag can be used to parse regardless of the order in which the keys or values appear in the string.

Creating a Custom Parser

Prerequisites

You should have examples of the logs that you want to parse

You should have created any new device/application types, event attribute types, or event types that you want to use in your XML specification

You should already have written the XML specification for your parser

You should have prepared a test event that you can use to validate the parser

Parsers Applied in Order

Parsers are applied in the order they are listed in Admin > Device Support > Parsers, so it is important to add your custom parser to the list in relation to any other parsers that may be applied to your device logs. If you click Fix Order, this will arrange the parsers with system-defined parsers at the top of the list in their original order, and user-defined parsers at the bottom. By sure to click Apply to make sure the change in order is picked up by the back-end module.

Procedure

1. Go to Admin > Device Support > Parsers.
2. Select a parser that is above the location in the list where you want to add your parser, and then click New.
3. Enter a Name for the parser.
4. Select a Device Type to which the parser should apply.

If the device type doesn’t appear in the menu, you should create a new device type

5. Enter a Test Event containing an example of an event that you want to use to validate the parser.
6. Enter the Parser XML.
7. Click Validate.

This will validate the XML.

8. Click Test.

This will send the test event to the parser to make sure it is parsed correctly, and will also test the parsers above and below yours in the list to make sure they continue to parse logs correctly.

9. If the XML for your parser validates and the test event is correctly parsed, select Enable.

If you need to continue working on your parser, you can Save it without selecting Enable.

10. Click Save.
11. Click Apply to have the backend module pick up your parser and begin applying it to device logs.

You should now validate that events are being parsed by creating some activity that will cause a log to be generated, and then run a query against the new device IP address and validate the parsed results.

Deleting or Disabling a Parser

1. Go to Admin > Device Support > Parsers.
2. Select the parser you want to delete or disable.
3. Click Delete or Disable.
4. Click Yes to confirm that you want to delete or disable the parser.

Exporting a Custom Parser

To export a parser, you must also export XML files for the device/app types, event attribute types, event types, and then the parser specification file used by your parser.

1. Go to Admin > Device Support > Device/App Types.
2. Select the device/application types used in your parser, and then click Export.
3. Go to Admin > Device Support > Event Attribute Types.
4. Select the event attribute types used in your parser, and then click Export.
5. Go to Admin > Device Support > Event Types.
6. Select the event types used in your parser, and then click Export.
7. Go to Admin > Device Support > Parsers.
8. Select the parser specification for your parser, and then click Export.

Importing a Custom Parser

Importing a custom parser involves importing four XML files: the XML files containing any device/app types, event attribute types, or event types that you have created for this parser, followed by the parser specification XML file.

1. For each device/app type, event attribute type, or event type XML file that is required for your parser, go to the appropriate tab in Admin > Device Support, and then click Import.
2. Browse to the location of your XML file, and then click Upload.
3. Go to Admin > Device Support > Parsers, and then click Import.
4. Browse to the location of your parser specification XML file, and then click Upload.
5. Follow the instruction in Creating a Custom Parser to validate your XML and test the parser, and to make sure it appears in the correct position in the list of parsers.

Parser Examples

Cisco IOS Syslog Parser

Cisco IOS Syslog Parser

Add Device Type

Create a file CiscoIOSParser.xml with this content.

Create the Parser Specification and Add Local Patterns

Create the parser XML file with this content, and add the pattern definition patCiscoIOSMod for detecting IOS modules such as SEC.

Define the Format Recognizer

Add this format recognizer for detecting %SEC-6-IPACCESSLOGP, which is a signature of Cisco IOS syslog messages.

Parse the Syslog Header

A syslog message consists of a syslog header, and a body. For better organization, we first parse the syslog header and event type. Subsequent code will include event type specific parsing, which is why event type is extracted in this step. In this example, the header is in boldface.

<190>91809: Jan 9 02:38:47.872: %SEC-6-IPACCESSLOGP: list testlog permitted tcp 192.168.20.33(3438) -> 69.147.86.184(80), 1 packet

The XML code for parsing the header does the following:

1. Matches the pattern <190>91809: Jan 9 02:38:47.872: %SEC-6-IPACCESSLOGP:
2. Sets the eventType attribute to IOS-SEC- IPACCESSLOGP.
3. Sets deviceTime.
4. Sets event severity (1-7 scale in Cisco IOS, 1=> most severe, to normalized 1-10 scale in FortiSIEM where 10=>most severe)
5. Saves the event list testlog permitted tcp 192.168.20.33(3438) -> 69.147.86.184(80), 1 packet in a temporary variable _body.

Note that the patterns gPatSyslogPRI, gPatMon, gPatDay, gPatTime, gPatInt, gPatmesgBody are global patterns that are defined in the GeneralPatternDefinitions.xml file:

This parser file XML fragment for parsing the example syslog message looks like this:

Parse the Syslog Body

The parsing is done on an eventType by eventType basis, since the formats are eventType specific. Parsing the syslog body involves three steps:

1. Parsing the action string. Based on the action staring value (permit or denied), modify the eventType by appending the action string value at the end, and also modify the eventSeverity
2. Parsing the protocol, source and destination IP, port, and totalPackets.
3. Converting the protocol string to a protocol integer.

Final Parser

</patternDefinitions>

<parsingInstructions>

<!—parse header –>

<collectFieldsByRegex src=”$_rawmsg”>

<regex><![CDATA[<:gPatSyslogPRI>?<:gPatMon>\s+<:gPatDay>\s+<:gPatTime>

%<_evIdPrefix:patCiscoIOSMod>-<_severity:gPatInt>-<_evIdSuffix:patStrEnd

Colon>: <_body:gPatMesgBody>]]></regex>

</collectFieldsByRegex>

<setEventAttribute attr=”eventType”>combineMsgId(“IOS-“,

$_evIdPrefix, “-“, $_evIdSuffix)</setEventAttribute>

<choose>

<when test=’$_severity IN “6, 7″‘>             <setEventAttribute attr=”eventSeverity”>1</setEventAttribute>         </when>

<when test=’$_severity = “1”‘>            <setEventAttribute attr=”eventSeverity”>10</setEventAttribute>         </when>

<when test=’$_severity = “2”‘>

<setEventAttribute attr=”eventSeverity”>8</setEventAttribute>

</when>

<when test=’$_severity IN “3, 4″‘>

<setEventAttribute attr=”eventSeverity”>5</setEventAttribute>

</when>

<when test=’$_severity = “5”‘>

<setEventAttribute attr=”eventSeverity”>2</setEventAttribute>

</when>

</choose>

<!—parse body –>

<choose>

<when test=’$eventType IN “IOS-SEC-IPACCESSLOGP,

IOS-SEC-IPACCESSLOGDP, IOS-SEC-IPACCESSLOGRP”‘>

<collectAndSetAttrByRegex src=”$_body”>

<regex><![CDATA[list

<_aclName:gPatStr>\s+<_action:gPatWord>\s+<_proto:gPatWord>\s+<srcIpAddr

:gPatIpV4Dot>\(<srcIpPort:gPatInt>\)<:gPatMesgBody>->\s+<destIpAddr:gPat

IpV4Dot>\(<destIpPort:gPatInt>\),\s+<totPkts:gPatInt> <:gPatMesgBody>]]>

</regex>           </collectAndSetAttrByRegex>

<choose>

<when test=’$_action = “permitted”‘>                  <setEventAttribute

attr=”eventType”>combineMsgId(“IOS-“, $_evIdPrefix, “-“, $_evIdSuffix, “-PERMITTED”)</setEventAttribute>           <setEventAttribute attr=”eventSeverity”>1</setEventAttribute>

</when>

<when test=’$_action = “denied”‘>

<setEventAttribute attr=”eventType”>combineMsgId(“IOS-“, $_evIdPrefix, “-“, $_evIdSuffix, “-DENIED”)</setEventAttribute>                  <setEventAttribute attr=”eventSeverity”>3</setEventAttribute>               </when>

</choose>           <setEventAttribute attr=”ipProto”>convertStrToIntIpProto($_proto)</setEventAttribute>

Parsed Output Input syslog:

<190>91809: Jan 9 02:38:47.872: %SEC-6-IPACCESSLOGP: list testlog permitted tcp 192.168.20.33(3438) ->

69.147.86.184(80), 1 packet

Parsed fields:

1. phRecvTime: the time at which the event was received by FortiSIEM
2. phDeviceTime: Jan 9 02:38:47 2010
3. eventType: SEC-IPACCESSLOGP-PERMITTED
4. eventSeverity: 3
5. eventSeverityCategory: LOW
6. aclName: testlog
7. ipProto: 6
8. srcIpAddr: 192.168.20.33
9. destIpAddr: 69.147.86.184
10. srcIpPort: 3438
11. destIpPort: 80
12. totPkts: 1

The master list of event attributes supported by FortiSIEM is here

Custom Performance Monitors

Creating a custom performance monitor involves creating a performance object that specifies the monitoring access protocol to use, maps event attributes available for that protocol to FortiSIEM event attribute types, and then associates those attributes to an event type. You can use system or user-defined device types, event attribute types, and event types when creating the performance object.

Creating a Custom Performance Monitor

Monitoring Protocol Configuration Settings

JDBC Configuration Settings

JMX Configuration Settings

SNMP Configuration Settings for Custom Performance Monitors

Importing OID Definitions from a MIB File

WMI Configuration Settings for Custom Performance Monitors

Mapping Monitoring Protocol Objects to Event Attributes

Exporting a Custom Performance Monitor

Importing a Custom Performance Monitor

Examples of Custom Performance Monitors

Custom JDBC Performance Monitor for a Custom Table

Custom JMX Monitor for IBM Websphere

Custom SNMP Monitor for D-Link HostName and SysUpTime Custom SNMP Monitor for D-Link Interface Network Statistics

Custom WMI Monitor for Windows Domain and Physical Registry

Creating a Custom Performance Monitor

You create custom performance monitors by defining the performance object that you want to monitor, including the relationship between the performance object and FortiSIEM events and event attributes, and then associating the performance object to a device type.

Prerequisites

You should review the configuration settings for the monitoring protocols that you will use in your monitor, and be ready to provide the appropriate OIDs, classes, or database table attributes for the access protocol.

You should have created any new device/application types, event attribute types, or event types that you want to use in your performance monitor

You should have the IP address and access credentials for a device that you can use to test the monitor

Procedure

Creating the Performance Object and Applying it to a Device

1. Go to Admin > Device Support > Performance Monitoring.
2. Click New.
3. Enter a Name for the performance monitor.
4. For Type, select either System or Application.
5. For Method, select the monitoring protocol for the performance monitor.

See the topics under Monitoring Protocol Configuration Settings for more information about the configuration settings for each type of monitoring protocol.

6. Click New next to List of Attributes, and create the mapping between the performance object and FortiSIEM event attributes. Note that the Method you select will determine the name of this mapping and the configuration options that are available. See Mapping Monitoring Protocol Objects to Event Attributes for more information.
7. Select the Event Type that will be monitored.
8. Enter the Polling Frequency for the monitor.
9. Enter a Description.
10. Click Save.
11. In Admin > Device Support > Performance Monitoring, under Enter Device Type to Performance Object Mapping, click New.
12. Enter a Name for the mapping.
13. In the top pane of the dialog, select the Device Type to which you want to apply the monitor.

Whenever a device belonging to the selected device type is discovered, FortiSIEM will attempt to apply the performance monitor to it.

14. In the bottom pane of the dialog, select the custom performance monitor.
15. Click Save.

Testing the Performance Monitor

1. Go to Admin > Device Support > Performance Monitoring.
2. Select the performance monitor.
3. Click Test.
4. For IP, enter the IP address of the device that you want to use to test the monitor.
5. Click Test.

If the test succeeds, click Close, and then click Apply to register the new monitor with the backend module.

After you have successfully tested and applied the performance monitor, you should initiate discovery of the device that it will monitor, and then make sure that the new monitor is enabled as described in Managing Monitoring of System and Application Metrics for Devices.

Monitoring Protocol Configuration Settings

These topics describe the configuration settings for monitoring protocols such as SNMP, WMI, and JDBC that are used for creating custom performance monitors.

JDBC Configuration Settings

JMX Configuration Settings

SNMP Configuration Settings for Custom Performance Monitors

Importing OID Definitions from a MIB File

WMI Configuration Settings for Custom Performance Monitors

JDBC Configuration Settings

When configuring JDBC as the access protocol for a custom performance monitor, use these settings. You may also want to review the topic Cust om JDBC Performance Monitor for a Custom Table as example of how to set up a custom performance monitor using JDBC.

JMX Configuration Settings

When configuring JMX as the monitoring protocol for a custom performance monitor, use these settings. You may also want to review the topic C ustom JMX Monitor for IBM Websphere as an example of creating a custom JMX performance monitor.

Identifying MBean Names and Attributes for Custom Applications

This section discusses how to get MBean names and attributes for custom J2EE based applications.

1. Launch JConsole on your workstation and connect to the application.
2. Select the MBeans
3. Browse to the application you want to monitor, and select it.
4. In the right pane you will see the MBeanInfo. Note the ObjectName, while the attributes for the application will be listed in the tree view.

SNMP Configuration Settings for Custom Performance Monitors

When configuring SNMP as the access protocol for a custom performance monitor, use these settings. You may also want to review the topics Cu stom SNMP Monitor for D-Link Interface Network Statistics and Custom SNMP Monitor for D-Link HostName and SysUpTime as example of how to set up a custom performance monitor using SNMP.

Importing OID Definitions from a MIB File

Many devices include MIB files that you can then use to create a custom performance monitor for the device. This involves creating a

configuration file based on information in the MIB file, using that file as input for the mib2xml executable, and then placing the resulting output file in the /data/mibXml directory of your Supervisor. Once placed in this directory, you can select the file from the MIB File List menu to select the parent OID, which will then also affect which OIDs you can select for the OID to event attribute mapping.

Procedure

1. Collect the device OID files you want to use and place them in a directory where the mib2XML
2. Create the input config file with these fields, and name it with the .cfg file designation.

See the attached alcatel.cfg  file for an example.

3. Run mib2XML <filename>.cfg.
4. Move the resulting .mib.xml file to the /data/mibXml directory of your Supervisor.

Example

In this example, a set of MIB files from an Alcatel 7×50 device are used to generate the XML output file.

1. Sample MIB files:

TIMETRA-CHASSIS-MIB.mib

TIMETRA-GLOBAL-MIB.mib

TIMETRA-SYSTEM-MIB.mib

TIMETRA-TC-MIB.mib

2. Information in these files, and the paths to them, are then used to create this config file. cfg
3. Running mib2xml alcatel.cfg generates both an output and an mib2XML file.

alcatel.out

TIMETRA-TC-MIB.mib.xml

WMI Configuration Settings for Custom Performance Monitors

When configuring WMI as the monitoring protocol for a custom performance monitor, use these settings. You may also want to review the topic C ustom WMI Monitor for Windows Domain and Physical Registry as example of how to set up a custom performance monitor using WMI.

Mapping Monitoring Protocol Objects to Event Attributes

When you select a monitoring protocol for your custom performance monitor, you must also establish the relationship between the objects used by that protocol and event attributes in FortiSIEM. For example, creating a performance monitor that uses SNMP to monitor a device requires that you create a mapping between the SNMP OIDs that you want to monitor, and set of event attributes. This topic describes the configuration settings that you will use to create these object-to-event attribute relationships.

Procedure

1. When creating your custom performance monitor, after you have selected the Method, click New next to List of Attributes.

Depending on the monitoring protocol that you select, this table may be named List of OIDs (SNMP), or List of Columns (JDBC).

2. In the first field, enter or select the monitoring protocol object that you want to map to an FortiSIEM event attribute.

Your options depend on the monitoring protocol you selected for Method.

3. Select the Format for the object attribute.

Your options will depend on the monitoring protocol you selected for Method.

4. For Type, select Raw Value or Counter.
5. For Event Attribute, select the FortiSIEM event attribute that the monitoring protocol object should map to.

If you need to create a new event attribute, see Creating Event Attribute Types.

6. Create any Transforms of the values returned for the monitoring protocol object.

See the next section for more information how to configure transforms.

7. Click Save when you are done creating the mappings, and then complete the configuration of your custom performance monitor.

Creating Transforms

You can use a transform to convert the value returned for your monitoring project object into a more physically meaningful or usable metric. You an create multiple transforms, and they will be evaluated in the order shown in the table. Multiple transforms can be selected – they are evaluated in sequential order as shown in the display table

1. Next to Transforms, click New.
2. For Type, select System or Custom.
3. For Formula, either select a system-defined transformation formula from the menu if you selected System for Type, or enter a formula if you selected Custom.
4. Click Save.

Exporting a Custom Performance Monitor

To export a parser, you must also export XML files for the device/app types, event attribute types, event types, and then the monitor.

1. Go to Admin > Device Support > Device/App Types.
2. Select the device/application types used in your monitor, and then click Export.
3. Go to Admin > Device Support > Event Attribute Types.
4. Select the event attribute types used in your monitor, and then click Export.
5. Go to Admin > Device Support > Event Types.
6. Select the event types used in your monitor, and then click Export.
7. Go to Admin > Device Support > Performance Monitoring.
8. Select the monitor, and then click Export.

Importing a Custom Performance Monitor

Importing a custom performance monitor involves importing four XML files: the XML files containing any device/app types, event attribute types, or event types that you have created for this parser, followed by the custom performance monitor file.

1. For each device/app type, event attribute type, or event type XML file that is required for your monitor, go to the appropriate tab in Admin > Device Support, and then click Import.
2. Browse to the location of your XML file, and then click Upload.
3. Go to Admin > Device Support > Performance Monitors, and then click Import.
4. Browse to the location of your performance monitor file, and then click Upload.
5. Follow the instructions in Creating a Custom Performance Monitor to test and apply your performance monitor.

Examples of Custom Performance Monitors

Custom JDBC Performance Monitor for a Custom Table

Custom JMX Monitor for IBM Websphere

Custom SNMP Monitor for D-Link HostName and SysUpTime Custom SNMP Monitor for D-Link Interface Network Statistics

Custom WMI Monitor for Windows Domain and Physical Registry

Custom JDBC Performance Monitor for a Custom Table

Planning

Examining the Table Structure

Creating New Device Types, Event Attribute Types, and Event Types Event Types

Adding New JDBC Performance Objects

Performance Object Configuration for Static Table HEALTH_STATIC_DEMO

Performance Object Configuration for Dynamic Table HEALTH_DYNAMIC_DEMO

Associating Device Types to Performance Objects Edit Device to Performance Object

Testing the Performance Monitor

Enabling the Performance Monitor

Writing Queries for the Performance Metrics

Planning

Examining the Table Structure

For this example, consider two custom Oracle tables that you want to monitor.

• A table called HEALTH_STATIC_DEMO that does not have time stamp as a column. The table does not grow with time, and the HEALTH c olumn is updated by the application.

2. A table called HEALTH_DYNAMIC_DEMO that has a time-stamp in the column create_time. Only records with a more recent time-stamp than previous ones have to be pulled in, and every time a new record is written, it includes a time stamp.

Creating New Device Types, Event Attribute Types, and Event Types

In this case, you only need to create two new event types to handle the contents of the two tables.

Event Types

Adding New JDBC Performance Objects

Each table requires its own performance object for monitoring.

Performance Object Configuration for Static Table HEALTH_STATIC_DEMO

Performance Object Configuration for Dynamic Table HEALTH_DYNAMIC_DEMO

Associating Device Types to Performance Objects

In this example, the Oracle database runs on Microsoft Windows, so you would need to associate Microsoft Windows device types to the two performance objects. Because the discovered device type has to exactly match one of device types in this association in order for the discovery module to initiate monitoring, you would need to add other device types, such as Linux, if you also wanted to monitor Oracle databases over JDBC on those devices.

Edit Device to Performance Object

Testing the Performance Monitor

Before testing the monitor, make sure you have defined the access credentials for the database server, created the IP address to credentials mapping, and tested connectivity to the server.

1. Go to Admin > Device Support > Performance Monitoring.
2. Select one of the performance monitors you created, and then click Test.
3. For IP, enter the address of the Oracle database server, and select either the Supervisor or Collector node that will retrieve the information for this monitor.
4. Click Test.

You should see succeed under Result, and a parsed event attributes in the test result pane.

5. When the test succeeds, click Close, and then click Apply to register the new monitor with the backend module.

Enabling the Performance Monitor

1. Discover or re-discover the device you want to monitor.
2. Once the device is successfully discovered, make sure that the monitor is enabled and pulling metrics.

Writing Queries for the Performance Metrics

You can now use a simple query to make sure that that the metrics are pulled correctly. The search results should display the metrics for the event attributes you defined.

1. Create a structured historical search, and in the Filter Criteria, enter Event Type =

“PH_DEV_MON_CUST_JDBC_PERFORMANCE_STATIC”; Group by: [None] This should show the entries in the HEALTH_STATIC_DEMO table

2. Create a structured historical search, and in the Filter Criteria, enter Event Type =

“PH_DEV_MON_CUST_JDBC_PERFORMANCE_SDynamic”; Group by: [None] This should show the entries in the HEALTH_DYNAMIC_DEMO table .

Custom JMX Monitor for IBM Websphere

Creating New Device Types, Event Attribute Types, and Event Types

Event Attribute Types

Event Types

Adding New IBM WebSphere Performance Objects

Performance Object Configuration for Event Type PH_DEV_MON_CUST_WEBSPHERE_HEAPMEMORY

Performance Object Configuration for Event Type PH_DEV_MON_CUST_WEBSPHERE_THREAD

Transform Formula for websphere_threadPCT Event Attribute

Performance Object Configuration for Event Type PH_DEV_MON_CUST_WEBSPHERE_NON_HEAPMEMORY Associating Device Types to Performance Objects Edit Device to Performance Object

Testing the Performance Monitor

Enabling the Performance Monitor

Writing Queries for the Performance Metrics

This example illustrates how to write a custom performance monitor for retrieving IBM Websphere thread, heap memory, and non-heap memory metrics.

Planning

Creating New Device Types, Event Attribute Types, and Event Types

In this case, the IBM Websphere device type is already supported by FortiSIEM, but you need to create new event attributes and event types for the metrics you want to retrieve.

Event Attribute Types

Event Types

Adding New IBM WebSphere Performance Objects

Each of the event types requires creating a performance object for monitoring.

Performance Object Configuration for Event Type PH_DEV_MON_CUST_WEBSPHERE_HEAPMEMORY

Performance Object Configuration for Event Type PH_DEV_MON_CUST_WEBSPHERE_THREAD

For the webSphere_threadPct Event Attribute, you will enter a transform as shown in the second table.

Transform Formula for websphere_threadPCT Event Attribute

Click New next to Transforms in the dialog to enter the formula.

Performance Object Configuration for Event Type PH_DEV_MON_CUST_WEBSPHERE_NON_HEAPMEMORY

Associating Device Types to Performance Objects

In this example, IBM WebSphere runs on Microsoft Windows, so you would need to associate Microsoft Windows device types to the three performance objects. Because the discovered device type has to exactly match one of device types in this association in order for the discovery module to initiate these monitors, you would need to add other device types, such as Linux, if you also wanted to monitor IBM Websphere over JMX on those devices.

Edit Device to Performance Object

Testing the Performance Monitor

Before testing the monitor, make sure you have defined the access credentials for the server, created the IP address to credentials mapping, and tested connectivity.

1. Go to Admin > Device Support > Performance Monitoring.
2. Select one of the performance monitors you created, and then click Test.
3. For IP, enter the address of the Oracle database server, and select either the Supervisor or Collector node that will retrieve the information for this monitor.
4. Click Test.

You should see succeed under Result, and the parsed event attributes in the test result pane.

5. When the test succeeds, click Close, and then click Apply to register the new monitor with the backend module.

Enabling the Performance Monitor

1. Discover or re-discover the device you want to monitor.
2. Once the device is successfully discovered, make sure that the monitor is enabled and pulling metrics.

Writing Queries for the Performance Metrics

You can now use a simple query to make sure that that the metrics are pulled correctly. The search results should display the metrics for the event attributes you defined.

Create a structured historical search with these settings:

Custom SNMP Monitor for D-Link HostName and SysUpTime

Although D-link switches and routers are not supported in this release of AccelOps, you can still use the custom monitor feature to create a system uptime event that will collect basic performance metrics like hostName and SysUpTime.

Planning

Mapping SNMP OIDs to AccelOps Event Attribute Types

If you run the command snmpwalk -v 1 -c <community> <ip> .1.3.6.1.2.1.1 against the D-Link switch, you should see an output similar to this:

From these outputs you can see that if you want to create a performance monitor for D-Link switch uptime, you need to:

1. Create a new device type, since D-Link switches are not supported in this release
2. Create an event type, PH_DEV_MON_CUST_DLINK_UPTIME, that will contain the event attribute types hostName and SysUpTime, which are already part of the AccelOps event attribute type library.
3. Create the mapping between the SNMP OIDs and the event attributes:
   1. OID .1.3.6.1.2.1.1.5 and hostName.
   2. OID .1.3.6.1.2.1.1.5 and SysUpTime.

Creating New Device Types, Event Attribute Types, and Event Types

Device Type

Create a new device type with these attributes:

Event Attribute Types and Event Types

Both sysUptime and hostName are included in the Event Attribute Types, so you only need to create a new event type, PH_DEV_MON_CUST_ DLINK_UPTIME, that will contain them.

Adding the D-Link SNMP Performance Object

In this case, you will create one performance object that will map the SNMP OIDs to the AccelOps event attribute types hostName and SysUpti me, and then associate them with the PH_DEV_MON_CUST_DLINK_UPTIME event type. When you create the SysUpTime mapping you will also a dd a transform to convert system time to centiseconds to seconds as shown in the second table.

Performance Object Configuration for Event Type PH_DEV_MON_CUST_DLINK_UPTIME

Transform Formula for SysUptime Event Attribute

Associating Device Types to Performance Objects

In this case you would only need to make one association with the D-Link DGS device you created.

Testing the Performance Monitor

Before testing the monitor, make sure you have defined the access credentials for the D-Link device, created the IP address to credentials mapping, and tested connectivity.

1. Go to Admin > Device Support > Performance Monitoring.
2. Select the performance monitor you created, and then click Test.
3. For IP, enter the address of the device, and select either the Supervisor or Collector node that will retrieve the information for this monitor.
4. Click Test.

You should see succeed under Result, and the parsed event attributes in the test result pane.

5. When the test succeeds, click Close, and then click Apply to register the new monitor with the backend module.

Enabling the Performance Monitor

1. Discover or re-discover the device you want to monitor.
2. Once the device is successfully discovered, make sure that the monitor is enabled and pulling metrics.

Writing Queries for the Performance Metrics

You can now use a simple query to make sure that that the metrics are pulled correctly. The search results should display the metrics for the event attributes you defined.

Create a structured historical search with these settings:

Custom SNMP Monitor for D-Link Interface Network Statistics

This example shows how to create a custom performance monitor for network interface statistics for D-link switches. In this case, the result is a table, with one set of metrics for each interface.

Planning

Matching SNMP OIDs to AccelOps Event Attribute Types

Creating New Device Types, Event Attributes, and Event Types

Device Type

Event Attribute Types

Event Types

Adding the D-Link SNMP Performance Object

Performance Object Configuration for Event Type PH_DEV_MON_CUST_INTF_STAT

Transform Formula for recvBitsPerSec and sentBitsPerSec Event Attributes

Associating Device Types to Performance Objects

Testing the Performance Monitor

Enabling the Performance Monitor

Writing Queries for the Performance Metrics

Planning

Matching SNMP OIDs to AccelOps Event Attribute Types

If you run the command snmpwalk -v 1 -c <community> <ip> .1.3.6.1.2.1.2.2.1 against the D-Link switch, you should see an output similar to this:

To get interface queue length (the outQLen event attribute in AccelOps), you would run snmpwalk -v 1 -c <community> <ip>

To get interface speed, you would run snmpwalk -v 1 -c <community> <ip> .1.3.6.1.2.1.2.2.1.5:

To get received bytes (the recvBitsPerSec event attribute in AccelOps), you would run snmpwalk -v 1 -c <community> <ip>

Finall,y to get sent bytes (the sentBitsPerSec event attribute in AccelOps ), you would  run snmpwalk -v 1 -c <community> <ip>

From these outputs you can see that if you want to create a performance monitor for D-Link switch uptime, you need to:

1. Create a new device type, since D-Link switches are not supported in this release.
2. Create an event type, PH_DEV_MON_CUST_DLINK_INTF_STAT, that will contain the event attribute types outQLen, recvBitsPerSec, and sentBitsPerSec, which are already part of the AccelOps event attribute library, and hostNameSnmpIndx and intfSpeed, which you need to create.
3. Create the mapping between the SNMP OIDs and the event attributes:
   1. OID .1.3.6.1.2.1.2.2.1.1 and hostNameSnmpIndx
   2. OID .1.3.6.1.2.1.2.2.1.5 and intfSpeed
   3. OID .1.3.6.1.2.1.2.2.1.21 and outQLen
   4. OID .1.3.6.1.2.1.2.2.1.10 and recvBitsPerSec
   5. OID .1.3.6.1.2.1.2.2.1.16 and sentBitsPerSec

Creating New Device Types, Event Attributes, and Event Types

Device Type

Create a new device type with these attributes:

Event Attribute Types

Create these event attribute types:

Adding the D-Link SNMP Performance Object

In this case, you will create one performance object that will map the SNMP OIDs to the AccelOps event attribute types, and then associate them with the PH_DEV_MON_CUST_INTF_STAT event type. When you create the recvBitsPerSec and sentBitsPerSec mapping you will also add a sequential transform to convert the cumulative metric to a rate, and then convert bytes per second to bits per second. .

Performance Object Configuration for Event Type PH_DEV_MON_CUST_INTF_STAT

Transform Formula for recvBitsPerSec and sentBitsPerSec Event Attributes

Associating Device Types to Performance Objects

In this case you would only need to make one association with the D-Link DGS device you created.

Testing the Performance Monitor

Before testing the monitor, make sure you have defined the access credentials for the D-Link device, created the IP address to credentials mapping, and tested connectivity.

1. Go to Admin > Device Support > Performance Monitoring.
2. Select the performance monitor you created, and then click Test.
3. For IP, enter the address of the device, and select either the Supervisor or Collector node that will retrieve the information for this monitor.
4. Click Test.

You should see succeed under Result, and the parsed event attributes in the test result pane.

5. When the test succeeds, click Close, and then click Apply to register the new monitor with the backend module.

Enabling the Performance Monitor

1. Discover or re-discover the device you want to monitor.
2. Once the device is successfully discovered, make sure that the monitor is enabled and pulling metrics.

Writing Queries for the Performance Metrics

You can now use a simple query to make sure that that the metrics are pulled correctly. The search results should display the metrics for the event attributes you defined.

Create a structured historical search with these settings:

Custom WMI Monitor for Windows Domain and Physical Registry

Planning

Mapping Windows WMI Classes to FortiSIEM Event Attribute Types

If you run the command wmic -U <domain>/<user>%<pwd> //<ip> “select * from Win32_ComputerSystem against a Windows server, you will see an output similar to this:

CLASS: Win32_ComputerSystem AdminPasswordStatus::SEP::AutomaticManagedPagefile::SEP::AutomaticResetB ootOption::SEP::AutomaticResetCapability::SEP::BootOptionOnLimit::SEP::B ootOptionOnWatchDog::SEP::BootROMSupported::SEP::BootupState::SEP::Capti on::SEP::ChassisBootupState::SEP::CreationClassName::SEP::CurrentTimeZon e::SEP::DaylightInEffect::SEP::Description::SEP::DNSHostName::SEP::Domai n::SEP::DomainRole::SEP::EnableDaylightSavingsTime::SEP::FrontPanelReset Status::SEP::InfraredSupported::SEP::InitialLoadInfo::SEP::InstallDate::

SEP::KeyboardPasswordStatus::SEP::LastLoadInfo::SEP::Manufacturer::SEP:: Model::SEP::Name::SEP::NameFormat::SEP::NetworkServerModeEnabled::SEP::N umberOfLogicalProcessors::SEP::NumberOfProcessors::SEP::OEMLogoBitmap::S EP::OEMStringArray::SEP::PartOfDomain::SEP::PauseAfterReset::SEP::PCSyst emType::SEP::PowerManagementCapabilities::SEP::PowerManagementSupported: :SEP::PowerOnPasswordStatus::SEP::PowerState::SEP::PowerSupplyState::SEP ::PrimaryOwnerContact::SEP::PrimaryOwnerName::SEP::ResetCapability::SEP: :ResetCount::SEP::ResetLimit::SEP::Roles::SEP::Status::SEP::SupportConta ctDescription::SEP::SystemStartupDelay::SEP::SystemStartupOptions::SEP:: SystemStartupSetting::SEP::SystemType::SEP::ThermalState::SEP::TotalPhys icalMemory::SEP::UserName::SEP::WakeUpType::SEP::Workgroup

1::SEP::True::SEP::True::SEP::True::SEP::3::SEP::3::SEP::True::SEP::Norm al

boot::SEP::WIN2008-ADS::SEP::3::SEP::Win32_ComputerSystem::SEP::-420::SE P::True::SEP::AT/AT

COMPATIBLE::SEP::WIN2008-ADS::SEP::FortiSIEM.net::SEP::5::SEP::True::SEP ::3::SEP::False::SEP::NULL::SEP::(null)::SEP::3::SEP::(null)::SEP::VMwar e, Inc.::SEP::VMware Virtual Platform::SEP::WIN2008-ADS::SEP::(null)::SEP::True::SEP::1::SEP::1::SEP:

:NULL::SEP::([MS_VM_CERT/SHA1/27d66596a61c48dd3dc7216fd715126e33f59ae7],

Welcome to the Virtual

Machine)::SEP::True::SEP::3932100000::SEP::0::SEP::NULL::SEP::False::SEP

::0::SEP::0::SEP::3::SEP::(null)::SEP::Windows User::SEP::1::SEP::-1::SEP::-1::SEP::(LM_Workstation,LM_Server,Primary_D omain_Controller,Timesource,NT,DFS)::SEP::OK::SEP::NULL::SEP::0::SEP::NU LL::SEP::0::SEP::X86-based PC::SEP::3::SEP::4293496832::SEP::FortiSIEM\Administrator::SEP::6::SEP::

(null)

From this output you can see that the Win32_ComputerSystem WMI class has two attributes: 1.  Domain

2. TotalPhysicalMemory

From these outputs you can see that if you want to create a performance monitor for Windows Domain and Physical Registry, you need to

1. Create an event type, PH_DEV_MON_CUST_WIN_MEM, that will contain the event attribute types Domain and memTotalMB, both of which are already contained in the FortiSIEM event attribute types library.
2. Create the mapping between the WMI class attributes and the FortiSIEM event attribute types:
   1. WMI class attribute Domain and Domain.
   2. WMI class attribute TotalPhysicalMemory (Bytes) and memTotalMB (type INT64). Because TotalPhysicalMemory return s in bytes, and memTotalMB is in INT64, a transform will be required to convert the metrics.

Creating New Device Types, Event Attributes, and Event Types

Device Type

Since Microsoft Windows is supported by FortiSIEM, you don’t need to create a new device type. Event Attribute Types and Event Types

Both Domain and memTotalMB are included in the FortiSIEM event attribute type library, so you only need to create a new event type, PH_DEV_ MON_CUST_WIN_MEM, that will contain them.

Adding the Microsoft Windows WMI Performance Object

In this case, you will create one performance object that will map the WMI Class attributes to the FortiSIEM event attribute types Domain and mem

TotalMB, and then associate them with the PH_DEV_MON_CUST_WIN_MEM event type. When you create the memTotalMB mapping you will also add a transform to convert bytes to INT64 as shown in the second table.

Performance Object Configuration for Event Type PH_DEV_MON_CUST_DLINK_UPTIME

Transform Formula for TotalPhysicalMemory Event Attribute Type

Associating Device Types to Performance Objects

In this example, you would need to associate Microsoft Windows device types to the performance object. Edit Device to Performance Object

Testing the Performance Monitor

Before testing the monitor, make sure you have defined the access credentials for the server, created the IP address to credentials mapping, and tested connectivity.

1. Go to Admin > Device Support > Performance Monitoring.
2. Select one of the performance monitors you created, and then click Test.
3. For IP, enter the address of the Microsoft Windows server, and select either the Supervisor or Collector node that will retrieve the information for this monitor.
4. Click Test.

You should see succeed under Result, and the parsed event attributes in the test result pane.

5. When the test succeeds, click Close, and then click Apply to register the new monitor with the backend module.

Enabling the Performance Monitor

1. Discover or re-discover the device you want to monitor.
2. Once the device is successfully discovered, make sure that the monitor is enabled and pulling metrics.

Writing Queries for the Performance Metrics

You can now use a simple query to make sure that that the metrics are pulled correctly. The search results should display the metrics for the event attributes you defined.

Create a structured historical search with these settings:

Custom Command Output Monitor

You may already have commands or scripts for your devices that collect important metrics or perform some useful function. By creating a custom command output monitor, you can import the output of those commands into the AccelOps event database, where it can be used to create reports , write rules to alert against anomolies, or trigger the execution of scripts. Creating a custom command output monitor involves collecting a sample output from the command, and then creating a performance object that uses regex to parse the command output, maps the output event attributes to AccelOps event attribute types, and then associates those to an event type.

Creating a Custom SSH Command Output Monitor

Creating a Custom Multi-Line SSH Command Output Monitor

Creating a Custom WINEXE Command Output Monitor

Device Types Supported for Custom SSH Command Output Monitors

Linux variants

Unix variants – IBM AIX, HP UX

Microsoft Windows (with Cygwin tools installed that allows SSH)

Cisco IOS, NX-OS, ASA, CatOS

Juniper JunOS, SSG, ISG

PaloAlto PANOS

Fortinet FortiGate

HP Procurve, H3C

Extreme Ntwork XOS

Foundry BigIron

Avaya ERS

Device Types Supported for Custom WINEXE Command Output Monitors

Microsoft Windows

Creating a Custom SSH Command Output Monitor

Mapping SSH Command Outputs to FortiSIEM Event Attribute Types

Creating New Event Attribute Types and Event Types

Event Attributes

Event Types

Adding the iostat Command Output Performance Object

Performance Object Configuration for Event Type PH_DEV_MON_CUST_CMD

Associating Device Types to Performance Objects

Testing the Performance Monitor

Enabling the Performance Monitor

Writing Queries for the Performance Metrics

In this example, the regular expression is used to parse a single line of the command output.

Planning

Mapping SSH Command Outputs to FortiSIEM Event Attribute Types

In this example, you want to monitor the output of the iostat command. On a Linux machine, the output would look similar to this:

From this example, you can see that to create a monitor for the iostat command output, you would need to:

1. Create the event attribute types readBytes,readRate, tps, writtenBytes, writtenRate, and diskName, to correspond to Blk_ read, Blk_read/s, tps, Blk_wrtn, Blk_wrtn/s, and Device from the command output.
2. Create an event type, PH_DEV_MON_CUST_CMD, that will contain the event attribute types readBytes, readRate, tps, writtenByte s, writtenRate, and diskName,
3. Create a performance object containing the regular expression that will parse the command output and match value positions to event attribute types, and then associate those event attribute types and values to PH_DEV_MON_CUST_CMD.

Creating New Event Attribute Types and Event Types

Event Attributes

Create these event attribute types:

Event Types

Create this event type:

Adding the iostat Command Output Performance Object

In this case, you will create one performance object that will use a regular expression to parse the command output, match value positions in the command output against FortiSIEM event attributes, and then associate those with the event type PH_DEV_MON_CUST_CMD.

Performance Object Configuration for Event Type PH_DEV_MON_CUST_CMD

Associating Device Types to Performance Objects

Testing the Performance Monitor

Before testing the monitor, make sure you have defined the access credentials for the D-Link device, created the IP address to credentials mapping, and tested connectivity.

1. Go to Admin > Device Support > Performance Monitoring.
2. Select the performance monitor you created, and then click Test.
3. For IP, enter the address of the device, and select either the Supervisor or Collector node that will retrieve the information for this monitor.
4. Click Test.

You should see succeed under Result, and the parsed event attributes in the test result pane.

5. When the test succeeds, click Close, and then click Apply to register the new monitor with the backend module.

Enabling the Performance Monitor

1. Discover or re-discover the device you want to monitor.
2. Once the device is successfully discovered, make sure that the monitor is enabled and pulling metrics.

Writing Queries for the Performance Metrics

You can now use a simple query to make sure that that the metrics are pulled correctly. The search results should display the metrics for the event attributes you defined.

Create a structured historical search with these settings:

Creating a Custom Multi-Line SSH Command Output Monitor

In some cases, the output from a command may run over several lines. An example, as shown in the code block below, is the show interfaces command for Cisco IOS routers. Here the information for each interface, such as Vlan1, Vlan2, etc., needs to be consolidated into a single FortiSIEM event. This topic will show you how to configure a performance object for multi-line SSH command outputs, including an example of the regular expression you would use to parse the example output.

Planning

Mapping a Multi-Line SSH Command Output to FortiSIEM Event Attribute Types

Creating New Event Attribute Types and Event Types Event Types

Adding the show interfaces Command Output Performance Object

Performance Object Configuration for Event Type PH_DEV_MON_CUST_SHOW_INTF

Associating Device Types to Performance Objects

Testing the Performance Monitor

Enabling the Performance Monitor

Writing Queries for the Performance Metrics

Planning

Mapping a Multi-Line SSH Command Output to FortiSIEM Event Attribute Types

In this example, you want to monitor the output of the ‘show interfaces’ command, which would look similar to this for a Cisco IOS router:

Vlan1 is up, line protocol is up

Hardware is EtherSVI, address is 00d0.055b.5000 (bia 00d0.055b.5000)

Description: DevNet

Internet address is 192.168.20.1/22   MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec,      reliability 255/255, txload 1/255, rxload 1/255   Encapsulation ARPA, loopback not set

Keepalive not supported

ARP type: ARPA, ARP Timeout 04:00:00

Last input 00:00:00, output 00:00:00, output hang never

Last clearing of “show interface” counters never   Input queue: 1/75/12681/0 (size/max/drops/flushes); Total output drops: 0   Queueing strategy: fifo

Output queue: 0/40 (size/max)

5 minute input rate 3583000 bits/sec, 1726 packets/sec

5 minute output rate 3118000 bits/sec, 1064 packets/sec   L2 Switched: ucast: 2060202231 pkt, 586057481378 bytes – mcast:

62824587 pkt, 9271104426 bytes   L3 in Switched: ucast: 43940778993 pkt, 16358818361299 bytes – mcast:

0 pkt, 0 bytes mcast   L3 out Switched: ucast: 37329069590 pkt, 18769383194932 bytes mcast: 0 pkt, 0 bytes      44460046444 packets input, 16420615020121 bytes, 0 no buffer

Received 52655932 broadcasts (0 IP multicasts)

0 runts, 0 giants, 146 throttles

0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored      37746681819 packets output, 18872504999045 bytes, 0 underruns

0 output errors, 0 interface resets

0 output buffer failures, 0 output buffers swapped out

Vlan2 is up, line protocol is up

Hardware is EtherSVI, address is 00d0.055b.5000 (bia 00d0.055b.5000)

Description: ServerNet

Internet address is 192.168.0.1/24   MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec,      reliability 255/255, txload 1/255, rxload 1/255   Encapsulation ARPA, loopback not set

Keepalive not supported

ARP type: ARPA, ARP Timeout 04:00:00

Last input 00:00:00, output 00:00:01, output hang never

Last clearing of “show interface” counters never

Input queue: 0/75/16/0 (size/max/drops/flushes); Total output drops: 0

Queueing strategy: fifo

Output queue: 0/40 (size/max)

5 minute input rate 1652000 bits/sec, 367 packets/sec

5 minute output rate 258000 bits/sec, 177 packets/sec   L2 Switched: ucast: 3422947811 pkt, 2275729058787 bytes – mcast:

4291290 pkt, 528654887 bytes   L3 in Switched: ucast: 17926721335 pkt, 14810495462969 bytes – mcast:

0 pkt, 0 bytes mcast   L3 out Switched: ucast: 13822525718 pkt, 7788778830975 bytes mcast: 0 pkt, 0 bytes      19067733427 packets input, 15044884652941 bytes, 0 no buffer

Received 4283101 broadcasts (0 IP multicasts)

0 runts, 0 giants, 2 throttles

0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored

13850959642 packets output, 7791605865261 bytes, 0 underruns

0 output errors, 0 interface resets

0 output buffer failures, 0 output buffers swapped out

Vlan3 is up, line protocol is up

Hardware is EtherSVI, address is 00d0.055b.5000 (bia 00d0.055b.5000)

Description: newbuildnet

Internet address is 192.168.24.1/24   MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec,      reliability 255/255, txload 1/255, rxload 1/255   Encapsulation ARPA, loopback not set

Keepalive not supported

ARP type: ARPA, ARP Timeout 04:00:00

Last input 00:00:04, output 00:00:01, output hang never

Last clearing of “show interface” counters never

Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0

Queueing strategy: fifo

Output queue: 0/40 (size/max)

5 minute input rate 23000 bits/sec, 1 packets/sec

5 minute output rate 1000 bits/sec, 1 packets/sec   L2 Switched: ucast: 319623039 pkt, 321540971691 bytes – mcast: 6427637 pkt, 563598014 bytes   L3 in Switched: ucast: 9237477530 pkt, 10166398798345 bytes – mcast: 0 pkt, 0 bytes mcast   L3 out Switched: ucast: 5881512921 pkt, 4457997315264 bytes mcast: 0 pkt, 0 bytes

9289735817 packets input, 10171188457635 bytes, 0 no buffer

Received 6427548 broadcasts (0 IP multicasts)

0 runts, 0 giants, 0 throttles

0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored

From this example, you can see that to create a monitor for the ‘show interfaces’ command output, you would need to:

1. Create an event type, PH_DEV_MON_CUST_SHOW_INTF, that will contain the event attribute types intfName, recvBitsPerSec, rec vPacketsPerSec, sentBitsPerSec, and sentPacketsPerSec, all of which are already contained in the FortiSIEM event attribute types library.
2. Create a performance object containing the regular expression that will parse the command output and match values against the event attribute types, and then associate those event attribute types and values to PH_DEV_MON_CUST_CMD. Creating New Event Attribute Types and Event Types

Event Types

Create this event type:

Adding the show interfaces Command Output Performance Object

In this case, you will create one performance object that will use a regular expression to parse the command output, match value positions in the command output against FortiSIEM event attributes, and then associate those with the event type PH_DEV_MON_CUST_SHOW_INTF.

Performance Object Configuration for Event Type PH_DEV_MON_CUST_SHOW_INTF

Associating Device Types to Performance Objects

Testing the Performance Monitor

Before testing the monitor, make sure you have defined the access credentials for the Cisco IOS device, created the IP address to credentials mapping, and tested connectivity.

1. Go to Admin > Device Support > Performance Monitoring.
2. Select the performance monitor you created, and then click Test.
3. For IP, enter the address of the device, and select either the Supervisor or Collector node that will retrieve the information for this monitor.
4. Click Test.

You should see succeed under Result, and the parsed event attributes in the test result pane.

5. When the test succeeds, click Close, and then click Apply to register the new monitor with the backend module.

Enabling the Performance Monitor

1. Discover or re-discover the device you want to monitor.
2. Once the device is successfully discovered, make sure that the monitor is enabled and pulling metrics.

Writing Queries for the Performance Metrics

You can now use a simple query to make sure that that the metrics are pulled correctly. The search results should display the metrics for the event attributes you defined.

Create a structured historical search with these settings:

Creating a Custom WINEXE Command Output Monitor

There may be times when you want the output of a PowerShell command from a Microsoft server as an input for FortiSIEM. Because PowerShell commands can’t be sent via SSH, you need to configure a WINEXE performance object to send the command, parse the output, and associate values to FortiSIEM event attribute types.

Often there is a need to have powershell command output from Microsoft servers into FortiSIEM. These commands cannot be run on Windows systems via SSH. The equivalent way of remotely running a command on Windows systems is Winexe. FortiSIEM will run the Winexe command on Windows systems, collect the output and parse the output into fields for use in FortiSIEM analytics.

Planning

For this example, assume you want to monitor disabled users in Microsoft Active Directory. You would use this command:

which would have an output similar to this:

From this example, you can see that to create a monitor for the iostat command output, you would need to:

1. Create an event type, PH_DEV_MON_CUST_DISABLED_USERS, that will contain the event attribute types distName, samAccount, and sid, all of which are already contained in the FortiSIEM event attribute types library, and which match to DistinguishedName, S amAccountName, and SID in the command output.
2. Create a performance object containing the regular expression that will parse the command output and match values against the event attribute types, and then associate those event attribute types and values to PH_DEV_MON_CUST_CMD.

After enabling the WIINEXE output monitor, you should see an event similar to this in FortiSIEM:

Creating New Event Attribute Types and Event Types

Event Types

Create this event type:

Adding the show interfaces Command Output Performance Object

In this case, you will create one performance object that will use a regular expression to parse the command output, match value positions in the command output against FortiSIEM event attributes, and then associate those with the event type PH_DEV_MON_CUST_DISABLED_USERS. Performance Object Configuration for Event Type PH_DEV_MON_CUST_DISABLED_USERS

Associating Device Types to Performance Objects

Testing the Performance Monitor

Before testing the monitor, make sure you have defined the access credentials for the D-Link device, created the IP address to credentials mapping, and tested connectivity.

1. Go to Admin > Device Support > Performance Monitoring.
2. Select the performance monitor you created, and then click Test.
3. For IP, enter the address of the device, and select either the Supervisor or Collector node that will retrieve the information for this monitor.
4. Click Test.

You should see succeed under Result, and the parsed event attributes in the test result pane.

5. When the test succeeds, click Close, and then click Apply to register the new monitor with the backend module.

Enabling the Performance Monitor

1. Discover or re-discover the device you want to monitor.
2. Once the device is successfully discovered, make sure that the monitor is enabled and pulling metrics.

Writing Queries for the Performance Metrics

You can now use a simple query to make sure that that the metrics are pulled correctly. The search results should display the metrics for the event attributes you defined.

Create a structured historical search with these settings:

Custom File Monitor

You can create custom file monitors to monitor changes to directories and specific files, and also to trigger incidents when the content of a monitored file is changed from a target gold file.

Agent-less File-Integrity Monitoring Agent-less Target File Monitoring

Agent-less File-Integrity Monitoring

You can use file integrity monitoring to make sure that critical files and directories on servers are not modified. When you enable a file integrity monitor for a specific file or directory, the monitor will:

1. Log in to the system using SSH.
2. Compute the checksums of the files or a directory, including all files in the directory.
3. Periodically verify the computed checksums.
4. Create an event when a change to the checksums is detected.

Supported Servers

Example Events

A Directory is Modified by Adding a File

A Specific File is Modified

A Specific File is Deleted

Permissions or Ownership of a Specific File or Any File in a Directory is Changed File Scan Event

Adding the File Integrity Monitoring Performance Object

Performance Object Configuration for File Integrity Monitoring

Performance Object Configuration for Directory Integrity Monitoring

Associating Device Types to Performance Objects

Testing the Performance Monitor

Enabling the Performance Monitor

Writing Queries for the Performance Metrics

Change: Audited File Added/Deleted

Change: Audited File Content Modifications

Change: Audited File Attribute Modifications

Supported Servers

File and directory integrity monitoring is supported for these servers:

Linux variants

Unix variants

Windows (with Unix tools installed that allow SSH)

Example Events

These are examples of events that are generated by FortiSIEM when a file or directory is modified, deleted, or has its permissions changed.

File Monitors and Event Types

Unlike other custom monitors, you don’t need to set the event type to associate with the monitor. When you select File Monitor for the Used For option, this automatically associates the event types with the file or directory you specify for monitoring. These examples include the event type associated with each monitoring event.

A Directory is Modified by Adding a File

Event Type: PH_DEV_MON_CUST_FILE_CHANGE_CONTENT

A Specific File is Deleted

Permissions or Ownership of a Specific File or Any File in a Directory is Changed

Event Type: PH_DEV_MON_CUST_FILE_CHANGE_ATTRIB.

For permissions changes, look for the preaccess and access attributes.

For ownership changes, look for the preuser, user, pregroup, and group attributes.

File Scan Event

Event Type: PH_DEV_MON_CUST_FILE_SCAN

When FortiSIEM scans a file or a directory, this event is generated and can be reported against.

Adding the File Integrity Monitoring Performance Object

In multi-tenant deployments, the performance object should be created by the Super/Global account, and will apply to all organizations. For both multi-tenant and enterprise deployments, the performance object can be created for an organization by any user who has access to the Admin ta b.

In this case, you will create one performance object for each file or directory you want to monitor. You don’t need to create a new event type or event attribute type, as these are automatically associated with the performance object when you select File Monitoring for the Used For field. Performance Object Configuration for File Integrity Monitoring

Performance Object Configuration for Directory Integrity Monitoring

Associating Device Types to Performance Objects

You should associate the performance object to the Linux, Unix, or SSH-capable Windows device type that contains the file or directory path you want to monitor.

Testing the Performance Monitor

Before testing the monitor, make sure you have defined the access credentials for the device, created the IP address to credentials mapping, and tested connectivity.

1. Go to Admin > Device Support > Performance Monitoring.
2. Select the performance monitor you created, and then click Test.
3. For IP, enter the address of the device, and select either the Supervisor or Collector node that will retrieve the information for this monitor.
4. Click Test.

You should see succeed under Result, and the parsed event attributes in the test result pane.

5. When the test succeeds, click Close, and then click Apply to register the new monitor with the backend module.

Enabling the Performance Monitor

1. Discover or re-discover the device you want to monitor.
2. Once the device is successfully discovered, make sure that the monitor is enabled and pulling metrics.

Writing Queries for the Performance Metrics

You can now use a simple query to make sure that that the metrics are pulled correctly.

Change: Audited File Added/Deleted

Create a structured historical search with these settings:

Change: Audited File Content Modifications

Create a structured historical search with these settings:

Change: Audited File Attribute Modifications Create a structured historical search with these settings: