Fortisiem 4.10.0 User Guide
Fortisiem 4.10.0 User Guide
Fortisiem 4.10.0 User Guide
VERSION 4.10.0
FORTINET DOCUMENT LIBRARY
http://docs.fortinet.com
FORTINET VIDEO GUIDE
http://video.fortinet.com
FORTINET BLOG
https://blog.fortinet.com
CUSTOMER SERVICE & SUPPORT
https://support.fortinet.com
http://cookbook.fortinet.com/how-to-work-with-fortinet-support/
FORTIGATE COOKBOOK
http://cookbook.fortinet.com
FORTINET TRAINING SERVICES
http://www.fortinet.com/training
FORTIGUARD CENTER
http://www.fortiguard.com
FORTICAST
http://forticast.fortinet.com
FEEDBACK
Email: techdocs@fortinet.com
Change Log 7
What's new in 4.10.0 8
Features 8
Unlimited Unmanaged CMDB Devices 8
EPS Bursting Using Unused EPS 9
Enhancements 9
New Rules 9
Windows Sysmon based attack detection 10
Linux syslog based attack detection 12
FortiGate, FortiSandbox and FortiMail Rules 12
FortiSIEM own analytics 13
FortiSIEM Basics 14
Features and Architecture 15
Supervisors, Workers, Collectors, and Organizations 18
Deployment Options 19
Enterprise Deployment Options 20
Multi-Tenant Deployment Options for Managed Service Providers or Multiple Organizations 27
Export-Restrictions 33
Configuring FortiSIEM 34
Initial System Configuration 35
Setting Up the Email Gateway 36
Setting Up Routing Information for Reports and Incident Notifications 37
Setting Up User Roles 42
Adding Users for Enterprise Deployments 45
Managing Organizations for Multi-Tenant Deployments 54
Adding Users to Multi-Tenant Deployments 58
Discovering Infrastructure 63
Discovery Settings 64
Discovery for Multi-Tenant Deployments 69
Setting up CyberArk 70
Setting Access Credentials for Device Discovery 72
Discovering Devices 74
Discovering Amazon Web Services (AWS) Infrastructure 75
Discovering Microsoft Azure Infrastructure 77
Associating Microsoft Azure with Credentials 77
Discovering Microsoft Azure Compute Nodes 78
Approving Newly Discovered Devices 79
User Guide 3
Fortinet Technologies Inc.
Inspecting Event Pulling Methods for Devices 80
Inspecting Changes Since Last Discovery 81
Discovery Range Definition Options 82
Scheduling a Discovery 84
Adding Devices to the CMDB Outside of Discovery 85
Decommissioning a device 86
Creating Dynamic CMDB Group Policies 86
Configuring Monitoring 88
Device Monitoring Settings 89
Managing Monitoring of System and Application Metrics for Devices 94
Setting Up Synthetic Transaction Monitoring Tests 95
Creating Business/IT Services 102
Data Update Subscription Service 103
Data Update Overview 104
Configuring Data Update 105
Creating Custom Parsers and Monitors for Devices 107
Creating Event Attributes, Event Types, and Device Types 108
Custom Parsers 112
Custom Performance Monitors 136
Custom Command Output Monitor 174
Custom File Monitor 188
Custom Configuration Change Monitoring 197
Configuring Event Handling 199
Event Dropping 200
Event Forwarding 201
Event Organization Mapping 202
Multi-line Syslog Handling 203
Managing FortiSIEM 205
General System Administration 206
FortiSIEM Backend Processes 207
Administrator Tools 209
Managing User Activity 210
Creating Maintenance Window for Devices 212
Creating Maintenance Window for Synthetic Transaction Monitoring jobs 213
Creating Reverse SSH Tunnels to Debug Collector Issues 214
Managing System Date Format and Logos 222
Viewing Cloud Health and System Information 223
Viewing Collector Health 224
Viewing License Information and Adding Nodes to a License 226
FortiSIEM Event Categories and Handling 227
4 User Guide
Fortinet Technologies Inc.
Changing Dashboard Theme 229
Installing OS Security Patches 230
Working with the Configuration Management Database (CMDB) 231
CMDB Categorization of Devices and Applications 232
Overview of the CMDB User Interface 235
Managing CMDB Objects 242
Reporting on CMDB Objects 293
Creating Event Database Archives 300
Managing Event Data Archive 302
Managing Online Event Data 302
Restoring Archived Data 305
Validating Log Integrity 306
Integrating with External CMDB and Helpdesk Systems 308
FortiSIEM CMDB/Helpdesk System Integration Overview 309
Configuring external helpdesk systems for FortiSIEM integration 310
Incident Outbound Integration 311
Incident Inbound Integration 313
CMDB Outbound Integration 315
CMDB Inbound Integration 317
Exporting Events to External Systems via Kafka 319
Backing Up and Restoring FortiSIEM Directories and Databases 320
Backing Up and Restoring SVN 321
Backing Up and Restoring the CMDB 322
Backing Up and Restoring the Event Database 323
Monitoring Operations with FortiSIEM 324
Dashboards - Flash version 325
Dashboard Overview 326
Customizing Dashboards 345
Creating Dashboard Slideshow 351
Exporting and Importing Dashboards 352
Link Usage Dashboard 353
Dashboards - HTML5 version 354
Viewing System Dashboards 355
Creating New Dashboards 356
Deleting Dashboards 357
Modifying Dashboards 358
Sharing Dashboards 360
Importing and Export Widget Dashboards 361
Analytics 362
Search 363
User Guide 5
Fortinet Technologies Inc.
Rules 411
Reports 442
Audit 460
Visual Analytics 466
Sample Incident Queries 486
Real Time Performance Probe 507
Incidents - Flash version 509
Viewing and Searching Incidents 509
Incident Notifications 518
Creating Tickets In FortiSIEM In-built Ticketing System 530
Creating Tickets in External Ticketing System 534
Using Incidents in Searches and Rules 535
Incidents - HTML5 version 536
Incident Attributes 537
Viewing Incidents 539
Searching Incidents 542
Managing Incidents 544
Device Risk Score Computation 545
Miscellaneous Operations 546
Exporting Events to Files 547
Dynamic Population of Location, User, and Geolocation Information for Events 549
Monitoring Custom Applications 552
IPS Vulnerability Map 553
6 User Guide
Fortinet Technologies Inc.
Change Log
Change Log
2017-09-25 Revision 3 with 'Common Vulnerabilities and Exposures' table added under 'Resolved
Issues'.
2017-09-26 Revision 4 with two new sections added 'License notes' and 'Upgrade notes'.
2017-10-17 Revision 5 with updated section Managing FortiSIEM > Integrating with External CMDB
and Helpdesk Systems. Installation and Upgrade information is available in a separate
manual under http://docs.fortinet.com/fortisiem/admin-guides.
User Guide 7
Fortinet Technologies Inc.
Features What's new in 4.10.0
This section describes the new and enhanced features in FortiSIEM version 4.10.0.
Features
Starting with 4.10.0 release, the concept of 'Managed' and 'Unmanaged' CMDB device is introduced. A device
directly sending log to FortiSIEM or being monitored by FortiSIEM for availability/performance/configuration
change is considered a Managed Device. The device license only affects Managed Devices, in other words, you
can have unlimited unmanaged devices in CMDB. During discovery, the user can choose the discovered devices
to be either managed or unmanaged. If a managed device is newly discovered but the device license is
exceeded, the device will be entered in the CMDB but as an Unmanaged device. The user can flip a device state
from Unmanaged to Managed and vice versa.
8 User Guide
Fortinet Technologies Inc.
What's new in 4.10.0 Enhancements
This feature enables customers to capture their entire infrastructure in FortiSIEM CMDB without necessarily
paying for a large license at the beginning. Customers can then incrementally convert devices from Unmanaged
to Managed and increase device license. This provides the customer greater deployment flexibility.
Enhancements
l Optimized Dynamic EPS Re-allocation Algorithm based on incoming EPS at the Collectors. Previously, this was
based on guaranteed EPS. This design change allows quicker re-adjustment and reduces event loss.
l HTML5 Incident and Dashboard is redesigned for better viewing via tablets.
l Query Engine is made robust to handle event database index corruptions.
l Data Manager and Indexing engine are now more robust and efficient and provides sustained EPS insertion. A new
report now captures the event database insert rate.
l Optimized Domain Generation Algorithm (DGA) by including white list and algorithmic optimizations. This
algorithm can detect connectivity to malware domains that are likely to have dynamically generated domain names.
l Fortinet-centric dashboard is added in Flex version. Similar dashboard already exists in the HTML5 version of
FortiSIEM 4.9.0.
New Rules
User Guide 9
Fortinet Technologies Inc.
New Rules What's new in 4.10.0
1. Windows Malicious Service Installed - Detects known malicious service installs that only appear in cases of
lateral movement, credential dumping, and other suspicious activity.
2. Windows DSRM Password Change - Detects password change of the Directory Service Restore Mode
(DSRM) account. This is a local administrator account on Domain Controllers. Attackers may change the
password to gain persistence.
3. Windows Suspicious Logon Failures - Detects suspicious logon failures for the following reasons - account
disabled, time of day violation, forbidden logon, error during logon, account locked out.
4. Windows Server Console Logon - Detects interactive console logon to windows server.
5. Windows Backup Catalog Deleted - Detects suspicious windows backup catalog deletions.If you delete the
backup catalog for a computer, you will not be able to access the backups created on that computer using the
Windows Server Backup snap-in.
6. Windows Password Dumper Activity - Detects process handle on LSASS process with certain access mask
and object type.
7. Windows Administrator User Reconnaissance Activity - Detects attempts to enumerate administrative
users via commands such as "net user administrator /domain" and "net group domain admins /domain".
8. Windows LSASS Process Access - Detects process access to LSASS which is typical for malware. This rule
requires Windows sysmon events collected via FortiSIEM Advanced Windows Agent.
9. Windows Remote Thread in LSASS - Detects remote thread creation to the lsass.exe process - likely an
attempt to collect passwords. This rule requires Windows sysmon events collected via FortiSIEM Advanced
Windows Agent.
10. Windows PowerShell Download from URL - Detects a PowerShell was launched containing download
commands in its command line string. This rule requires Windows sysmon events collected via FortiSIEM
Advanced Windows Agent.
11. Windows PowerShell Opening External Connections - Detects a PowerShell opening external connections
to external IP addresses. This rule requires Windows sysmon events collected via FortiSIEM Advanced Windows
Agent.
12. Windows PowerShell using Suspicious Parameters - Detects a PowerShell was launched containing
download commands in its command line string. This rule requires Windows sysmon events collected via
FortiSIEM Advanced Windows Agent
13. Windows Suspicious PowerShell Invocations - Detects suspicious powershell innovation from scripting
parent processes. This rule requires Windows sysmon events collected via FortiSIEM Advanced Windows Agent.
14. Malicious HTML Applications Spawning Windows Shell - Detects a Windows command line executable
started from Malicious HTML Applications. This rule requires Windows sysmon events collected via FortiSIEM
Advanced Windows Agent.
15. Windows Office Macro Spawning shell - Detects a Windows command line executable started from Microsoft
Office applications. This rule requires Windows sysmon events collected via FortiSIEM Advanced Windows Agent.
16. Suspicious Windows Driver Load from Temp Directory - Detects a windows driver load from a temporary
directory. This rule requires Windows sysmon events collected via FortiSIEM Advanced Windows Agent.
17. Windows Code Execution in Non-Executable Folder - Detects attempt to run code from uncommon folders.
This rule requires Windows sysmon events collected via FortiSIEM Advanced Windows Agent.
18. Windows Code Execution in Webserver Root Folder - Detects a suspicious program execution in a web
service root folder. This rule requires Windows sysmon events collected via FortiSIEM Advanced Windows Agent.
10 User Guide
Fortinet Technologies Inc.
What's new in 4.10.0 New Rules
19. Windows Command Line Processes Started by MMC - Command line processes started by MMC could be a
sign of lateral movement using MMC application COM object. This rule requires Windows sysmon events
collected via FortiSIEM Advanced Windows Agent.
20. Windows Net.exe Processes Started - Net.exe Processes started. This rule requires Windows sysmon events
collected via FortiSIEM Advanced Windows Agent.
21. Windows Network Connection from Suspicious Program Locations - Detects suspicious network
connections from suspicious program locations. This rule requires Windows sysmon events collected via
FortiSIEM Advanced Windows Agent.
22. Windows BITSAdmin download - Detects a BITSAdmin tool downloading a file. This rule requires Windows
sysmon events collected via FortiSIEM Advanced Windows Agent.
23. Windows DHCP Callout DLL installation - Detects the installation of a Callout DLL via CalloutDlls and
CalloutEnabled parameter in Registry, which can be used to execute code in the context of the DHCP server. This
rule requires Windows sysmon events collected via FortiSIEM Advanced Windows Agent.
24. Windows DNS ServerLevelPluginDll Install - Detects the installation of a plugin DLL via ServerLevelPluginDll
parameter in Registry, which can be used to execute code in context of the DNS server. This rule requires
Windows sysmon events collected via FortiSIEM Advanced Windows Agent.
25. Windows WScript or CScript Dropper - Detects wscript/cscript executions of scripts located in user
directories. This rule requires Windows sysmon events collected via FortiSIEM Advanced Windows Agent.
26. Windows Certutil Decode in AppData - Detects a Microsoft certutil execution with the decode sub command.
Sometimes this is used to decode malicious code with the built-in certutil utility. This rule requires Windows
sysmon events collected via FortiSIEM Advanced Windows Agent.
27. Windows Command With Suspicious URL and AppData String - Detects suspicious command line
execution with URL and AppData string in parameters. This rule requires Windows sysmon events collected via
FortiSIEM Advanced Windows Agent.
28. Suspicious Control Panel DLL Load - Detects suspicious Rundll32 execution from control.exe as used by
Equation Group and Exploit Kits. This rule requires Windows sysmon events collected via FortiSIEM Advanced
Windows Agent.
29. Windows Suspicious Command Line Reconnaissance Activity - Detects suspicious command line based
reconnaissance activity. This rule requires Windows sysmon events collected via FortiSIEM Advanced Windows
Agent.
30. Windows Suspicious Regsvr32 Activity - Detects suspicious Regsvr32 activity - this executable is used to
register and unregister OLE controls such as DLLs and ActiveX controls in the Windows registry. This rule requires
Windows sysmon events collected via FortiSIEM Advanced Windows Agent.
31. Windows Scheduled Tasks in User Session - Detects the creation of scheduled tasks in a user session. This
rule requires Windows sysmon events collected via FortiSIEM Advanced Windows Agent.
32. Windows Suspicious File Execution By Scripts - Detects suspicious file execution by wscript and cscript
executables
33. Windows Suspicious Password Hash Retrieval - Detects suspicious commands that could be related to
activity that uses volume shadow copy to steal and remotely retrieve hashes from the NTDS.dit file. This rule
requires Windows sysmon events collected via FortiSIEM Advanced Windows Agent.
34. Windows Suspicious WMI execution - Detects suspicious WMI commands to get information from the
system. This rule requires Windows sysmon events collected via FortiSIEM Advanced Windows Agent.
35. Windows User Account Control Bypass via Event Viewer - Detects User Account Control bypass method
using Windows event viewer. This rule requires Windows sysmon events collected via FortiSIEM Advanced
Windows Agent.
36. Windows User Account Control Bypass via sdclt - Detects User Account Control bypass method using
Windows backup tool sdclt.
User Guide 11
Fortinet Technologies Inc.
New Rules What's new in 4.10.0
37. Windows Java running with remote debugging - Detects a JAVA process running with remote debugging
allowing more than just localhost to connect. This rule requires Windows sysmon events collected via FortiSIEM
Advanced Windows Agent.
38. Windows Web shell Reconnaissance - Detects certain command line parameters often used during
reconnaissance activity via web shells. This rule requires Windows sysmon events collected via FortiSIEM
Advanced Windows Agent.
39. Windows Web Servers spawning command shell - Detects web servers spawning command shell - could be
the result of a successfully placed web shell or an other attack. This rule requires Windows sysmon events
collected via FortiSIEM Advanced Windows Agent.
40. Windows Wannacry ransomware activity - Detects Wannacry ransomware activity. This rule requires
Windows sysmon events collected via FortiSIEM Advanced Windows Agent.
41. Windows NotPetya ransomware activity - Detects NotPetya ransomware activity. This rule requires Windows
sysmon events collected via FortiSIEM Advanced Windows Agent.
42. Windows Application Audit log cleared - Detects an admin or an application has cleared the specified event
log. Clearing the event logs may indicate a malicious activity so the admin should make sure that this is indeed a
legit action.
1. Web Traffic to FortiSandbox Malicious URLs - Detects HTTP traffic where the URL matches the external
FortiSandbox Malicious URL list.
2. Web Traffic to FortiGuard Malicious URLs - Detects HTTP traffic where the URL matches the external
FortiGuard Malicious URL list.
3. FortiSandbox detects high/medium risk file malware - FortiSandbox claims that a file has malware.
4. FortiSandbox detects unknown risk file malware - FortiSandbox claims that a file has malware but the risk is
unknown and so needs to be investigated further.
5. FortiSandbox detects Botnet - FortiSandbox has detected a botnet.
6. FortiGate detects Botnet - FortiGate detected a botnet.
7. FortiSandbox detects Malware URL - FortiSandbox claims that a file has malware.
8. FortiSandbox detects Network Attack - FortiSandbox has detected a network attack.
9. FortiSandbox detects multiple attacks from same source - FortiSandbox detects multiple attacks from the
same source.
10. FortiSandbox detects multiple hosts with infected files - FortiSandbox detects multiple hosts infected with
the same infected file indicating an outbreak.
11. Virus found in mail - FortiMail and other mail gateways found a virus in mail attachment.
12. Host Quarantined by NAC - Detects hosts quarantined by FortiGate NAC.
12 User Guide
Fortinet Technologies Inc.
What's new in 4.10.0 New Rules
1. Dynamically generated host name - malware likely- Detects algorithmically generated host name in network
traffic - malware often uses algorithmically generated host names to communicate.
User Guide 13
Fortinet Technologies Inc.
FortiSIEM Basics
FortiSIEM Basics
These topics provide an overview of the FortiSIEM solution, including its component and various deployment
configurations.
User Guide 14
Fortinet Technologies Inc.
Features and Architecture FortiSIEM Basics
FortiSIEM provides an all-in-one, seamlessly integrated and service-oriented IT infrastructure monitoring solution
that covers performance, availability, change, and security monitoring aspects of network devices, servers, and
applications. It is offered in two versions:
l A VMware based virtual appliance, which you can deploy as a single appliance or a cluster of virtual appliances in a
highly available, scaled-out grid architecture. This is what we refer to as FortiSIEM Enterprise.
l Software-as-a-Service (SaaS), where you deploy a Collector virtual on-premises for a customer, and all of the
customer data is transmitted to FortiSIEM data center. This is what we refer to as FortiSIEM Multi-Tenant, since
collector deployments are commonly used by organizations such as Managed Service Providers to monitor the
services of their customers.
Some of the features of the FortiSIEM monitoring solution include:
A wide range of information is discovered including hardware information, serial numbers and licenses, installed
software, running applications and services, and router configuration. The discovered devices are automatically
categorized into detailed functional groups, such as Routers/Switches, Firewalls, and Network IPS, and this
information is maintained within an integrated configuration management database (CMDB). Some special
relationships are also discovered, for example WLAN Access Points to WLAN Controllers, VMware guests to
physical hosts, etc. The CMDB is kept up to date through user-defined scheduled discoveries and FortiSIEM
listening to changes as part of performance monitoring.
A novel aspect of FortiSIEM discovery is that those aspects of a device that can be monitored are also discovered
at the same time. For example, given SNMP, WMI, and JDBC credentials for a Windows server, FortiSIEM might
discover the following:
l System performance metrics that can be collected by SNMP, for example CPU, memory utilization, and disk space
utilization
l System performance metrics that can be collected by WMI, for example Disk I/O utilization, memory swap rates,
and process utilization
l Application specific metrics that can be collected by WMI, for example IIS, DNS, DHCP, and Exchange metrics
l Event logs that can be collected by WMI
l Database logs that can be pulled from the server by JDBC
You simply approve the discovered results and monitoring begins. This approach reduces human error, since
FortiSIEM learns from the true device configuration state.
15 User Guide
Fortinet Technologies Inc.
FortiSIEM Basics Features and Architecture
Analytics
FortiSIEM uses a unified event-based framework to analyze all data including logs, performance monitoring data.
Logs can either be sent to FortiSIEM via Syslog, SNMP traps, or other common log shipping methods, or
FortiSIEM can periodically access the system and collect the logs. Performance monitoring data is collected by
periodically probing the system. The data is parsed, indexed, and stored in a proprietary flat-file based database.
In contrast, the CMDB information is stored in a PostgreSQL relational database. FortiSIEM unified data
management architecture combines the two databases and presents a single view to the user.
FortiSIEM provides a broad range of metrics. First, it is possible to search all data based on keywords or in a
structured way using the attributes parsed by AcceOps. The search can be done in real time, in which the data
streaming in from devices is displayed, or the search can be based on historical data. Historical data is referred to
as Reports in FortiSIEM, and can be scheduled to run at intervals you set. A large number of reports are provided
in a categorized fashion, based on device type, and also based on functionality such as availability, performance,
change and security. Two novel aspects of FortiSIEM metrics include unification and drill-down capabilities. With
unification, all the data is analyzed and presented the same way, whether it be real time search, reports, rules or
performance, availability, or change or security data. By using drill-down you can start from a specific context,
such as Top Authentication Failed Users, and iteratively select attributes to further analyze data and get to the
root cause of a problem. As an example, the investigation of Top Authentication Failed users could follow a drill-
down of pick user and time range -> Top Destination IP, Ports for specific user and time range -> pick destination
IP and port -> Query all raw messages.
FortiSIEM also uses rules for real-time alerting - a real-time event correlation engine analyzes all data and
triggers alerts based on these rules. FortiSIEM ships with 500+ broad rules that cover a broad range of inter-
related performance, availability, change and security scenarios. Rules can vary from simple text search and
threshold conditions, to comprehensive logic supporting full Boolean operators and nested sub-patterns
referencing multiple elements including thresholds and defined services. Thresholds can be static or dynamically
derived from profiled network, system resource and user activity. You can add new rules, and customize existing
ones, as described in Creating Rules using GUI.
Business Services
A business service lets you view FortiSIEM metrics and prioritize alerts from a business service perspective. A
business service is defined within FortiSIEM as a smart container of relevant devices and applications serving a
business purpose. Once defined, all monitoring and analysis can be presented from a business service
perspective. It is possible to track service level metrics, efficiently respond to incidents on a prioritized basis,
record business impact, and provide business intelligence on IT best practices, compliance reporting, and IT
service improvement. What is also novel about FortiSIEM is how easily a business service can be defined and
maintained. Because FortiSIEM automatically discovers the applications running on the servers as well as the
network connectivity and the traffic flow, you can simply choose the applications and respective servers and be
intelligently guided to choose the rest of components of the business service. This business service discovery and
definition capability in FortiSIEM completely automates a process that would normally take many people and
considerable effort to complete and maintain.
Architecture
The FortiSIEM virtual appliance solution operates as a turnkey, guest host application running within the most
popular hypervisors with the option of using NFS or local storage. The implementation process is flexible and can
be accomplished in phases to support a variety of distributed and hybrid-cloud implementations The FortiSIEM
User Guide 16
Fortinet Technologies Inc.
Features and Architecture FortiSIEM Basics
virtual appliance is placed on a network where it can obtain operational data, as well as establish sessions with
the infrastructure. Remote sites can use the FortiSIEM Collector client to locally discover, collect, compress and
securely transmit of operation data back to the FortiSIEM virtual appliance. FortiSIEM' scale-out architecture
allows for virtual appliance clustering to increase processing capacity and availability. Additional virtual
appliances can be added on-the-fly with nominal configuration, which will automatically distribute workload
across cluster members to extend event analysis throughput and to reduce query response time.
17 User Guide
Fortinet Technologies Inc.
FortiSIEM Basics Supervisors, Workers, Collectors, and Organizations
An FortiSIEM deployment can be configured using either a single virtual appliance, or with multiple virtual
appliances that play different roles within the deployment. The Supervisor virtual appliance is the primary
component in both standalone and cluster deployments, and all deployments begin with the set up and
configuration of the Supervisor. As described in Supervisor and Worker Cluster Deployment for Enterprises, there
may be situations in which the single appliance cannot monitor all the data and devices in your infrastructure, and
so you can deploy Worker virtual appliances to take up the extra load. Finally, you may encounter situations in
which you need to deploy Collectors for the purpose of gathering data that will be processed by Supervisors and
Workers. As described in Supervisor with Collectors Deployment for Enterprises and Supervisor and Worker
Cluster Deployment for Multi-Tenancy, these are most likely situations where you need to monitor IT
infrastructure for different sites, as in the case of a large or distributed enterprise, or for different organizations, as
in the case of multi-tenant installations for Managed Service providers (MSPs). For these situations each
Organization is defined separately within FortiSIEM, so you can tailor your monitoring, analytics, and reports to
meet the specific needs of that organization.
User Guide 18
Fortinet Technologies Inc.
Deployment Options FortiSIEM Basics
Deployment Options
FortiSIEM architecture of workers, collectors, and supervisors offers a number deployment options for enterprises
at any level of scale, as well as deployment options for managed service providers who need Service Provider
solutions. Topics in this section describe these deployment options in detail, including use cases for each
deployment type as well as node and server configurations for each deployment type.
19 User Guide
Fortinet Technologies Inc.
FortiSIEM Basics Deployment Options
User Guide 20
Fortinet Technologies Inc.
Deployment Options FortiSIEM Basics
21 User Guide
Fortinet Technologies Inc.
FortiSIEM Basics Deployment Options
User Guide 22
Fortinet Technologies Inc.
Deployment Options FortiSIEM Basics
l There are monitored devices behind a firewall that will not allow monitoring protocols like Windows Management
Instrumention (WMI) to be used from the Supervisor
l The Supervisor can only reach the monitored devices through a high latency network like a Wide Area Network
(WAN), in which case monitoring like protocols like Simple Network Management Protocol (SNMP) or WMI do not
work well
In these cases, you can deploy Collectors to monitor the devices, and they will communicate to the Supervisor
over HTTP(S). The Collectors communicate with the devices, collect and parse events and logs, compress them,
and then send them to the Supervisor for monitoring and analysis. Collectors also can buffer the events, in case
transmission to the Supervisor is interrupted. As shown in the diagrams, you can use Collectors in a deployment
with a single Supervisor, or in a deployment that also includes Workers.
23 User Guide
Fortinet Technologies Inc.
FortiSIEM Basics Deployment Options
User Guide 24
Fortinet Technologies Inc.
Deployment Options FortiSIEM Basics
Visual Ana-
Deployment Supervisor Worker Collector NFS Server Report
lytics Description
Option Node Node Node Server
Server
This is also an
enterprise deployment
Supervisor covering multiple
Node with sites. Data collection
x x
Collectors is simplified by
deploying a collector
for the satellite sites.
This is also an
enterprise deployment
Supervisor covering multiple sites
Node with with added capability
Collectors for Visual Analytics
x
and Tableau x x x with Tableau. Data
Visual collection is simplified
Analytics by deploying a
collector for the
satellite sites.
25 User Guide
Fortinet Technologies Inc.
FortiSIEM Basics Deployment Options
Visual Ana-
Deployment Supervisor Worker Collector NFS Server Report
lytics Description
Option Node Node Node Server
Server
User Guide 26
Fortinet Technologies Inc.
Deployment Options FortiSIEM Basics
27 User Guide
Fortinet Technologies Inc.
FortiSIEM Basics Deployment Options
l Hosting service providers that host multiple customers in their own data center
l Managed service providers that manage a customer's data centers from their own data center
l Large enterprises that want to manage separate parts of the organization as individual customers
The simplest multi-tenancy deployment involves a single Supervisor, with organizations defined through the
splitting of IP address ranges. For example:
l 10.1.1.0/24 = Customer 1
l 10.1.2.0/24 = Customer 2
During the discovery process, FortiSIEM will tag a device with the right customer ID based on the IP address
definition.
User Guide 28
Fortinet Technologies Inc.
Deployment Options FortiSIEM Basics
In these deployments, you can define organizations by splitting IP address ranges. For example:
l 10.1.1.0/24 = Customer 1
l 10.1.2.0/24 = Customer 2
During the discovery process, the FortiSIEM Supervisor node will tag a device with the correct customer ID based
on the IP address definition.
29 User Guide
Fortinet Technologies Inc.
FortiSIEM Basics Deployment Options
Multi-Tenant x x x This is a
Cluster scalable service
provider
deployment
suitable for
deployments with
large compute and
storage needs. An
NFS Server is
required in the data
sharing architecture
between Supervisor
and Worker nodes.
Organizations are
created by splitting
up the IP address
space.
User Guide 30
Fortinet Technologies Inc.
Deployment Options FortiSIEM Basics
Multi-Tenant x x x x x This is a
Cluster with scalable service
Tableau Visual provider
Analytics deployment ,with
added capability for
Visual Analytics
with Tableau. An
NFS Server is
required in the data
sharing architecture
between Supervisor
and Worker nodes.
31 User Guide
Fortinet Technologies Inc.
FortiSIEM Basics Deployment Options
User Guide 32
Fortinet Technologies Inc.
Export-Restrictions FortiSIEM Basics
Export-Restrictions
Our product can not be exported, distributed, sold or used in: Cuba, Iran, Sudan, Syria and North Korea.
33 User Guide
Fortinet Technologies Inc.
Configuring FortiSIEM
Configuring FortiSIEM
User Guide 34
Fortinet Technologies Inc.
Initial System Configuration Configuring FortiSIEM
Before you can initiate discovery and monitoring of your IT infrastructure, you will need to configure several
general settings, add users, and add organizations for Service Provider deployments..
35 User Guide
Fortinet Technologies Inc.
Configuring FortiSIEM Initial System Configuration
User Guide 36
Fortinet Technologies Inc.
Initial System Configuration Configuring FortiSIEM
Related Links
l Scheduling Reports
l Incident Notifications
37 User Guide
Fortinet Technologies Inc.
Configuring FortiSIEM Initial System Configuration
Empty Reports
Sometimes a report may be empty because there are no matching events. If you don't want to send empty
reports to users, select Do not send scheduled emails if report is empty. If you are running a multi-tenant
deployment, and you select this option while in the Super/Global view, this will apply only to Super/Global
reports. If you want to suppress delivery of empty reports to individual organizations, you will have to configure
this option in the organizational view.
Related Links
User Guide 38
Fortinet Technologies Inc.
Initial System Configuration Configuring FortiSIEM
Related Links
l Incident Notifications
39 User Guide
Fortinet Technologies Inc.
Configuring FortiSIEM Initial System Configuration
User Guide 40
Fortinet Technologies Inc.
Initial System Configuration Configuring FortiSIEM
41 User Guide
Fortinet Technologies Inc.
Configuring FortiSIEM Initial System Configuration
A role defines two aspects of a user's interaction with the FortiSIEM platform:
l Which user interface elements a user can see and the ability to use the associated Read/Write/Execute
permissions. As an example, the built-in Executive role can see only the dashboard, while the Server Admin role
cannot see network devices. Role permissions can be defined to the attribute level in which, for example, a Tier1
Network Admin role can see network devices but not their configurations.
l What data can the user see. For example, consider a Windows Admin role and a Unix Admin role. They both
can run the same reports, but the Windows admins sees only logs from Windows devices. This definition can also
be fine-grained, for example one Windows admin sub-role can be defined to see Windows performance metrics,
while another Windows admin sub-role can see Windows authentication logs.
Topics in this section explain how to use the Default roles that come with FortiSIEM, and how to define new ones.
l Default Roles
l Creating Custom User Roles
User Guide 42
Fortinet Technologies Inc.
Initial System Configuration Configuring FortiSIEM
Default Roles
To perform any action with FortiSIEM, a user must be assigned a role with the required permissions. The roles
listed in this table are default roles. You can create custom roles and permissions by following the instructions in
the topic Creating Custom User Roles.
Role Permissions
Full Admin Full access to the GUI and full access to the data. Only this role can
define roles, create users and map users to roles.
Full access to the network device portion of the GUI and full access
Network Admin
to logs from network devices
System Admin Full access to the Server/Workstation/Storage part of the GUI and
full access to logs from those devices
Full access to the Server part of the GUI and full access to logs from
Server Admin
those devices
Windows Server Admin Full access to the Windows Server part of the GUI and full access to
logs from those devices
Full access to the Unix Server part of the GUI and full access to logs
Unix Server Admin
from those devices
Full access to the Storage device part of the GUI and full access to
Storage Admin
logs from those devices
DB Admin Full access to the database servers part of the GUI and full access
to logs from those devices
Access to the Admin, CMDB, and Dashboard tabs, with view and
Helpdesk
run permissions for the the Analytics and Incidents tabs
Read Only Admin View access to all tabs and permission to run reports
43 User Guide
Fortinet Technologies Inc.
Configuring FortiSIEM Initial System Configuration
Setting Description
If a Network Segment is marked as hidden for a user role, then users with that role will not be able to see any of
the devices whose IP addresses fall within that network segment, even if the CMDB folder(s) containing those
devices have not been hidden.
When a permission icon is shown within a grey box, that means that the permission was explicitly set. If the icon
is shown without a border, then it represents a node's effective permission. If a permission has not been set for a
node, then its effective permission is that of its nearest parent in the tree.
User Guide 44
Fortinet Technologies Inc.
Initial System Configuration Configuring FortiSIEM
45 User Guide
Fortinet Technologies Inc.
Configuring FortiSIEM Initial System Configuration
If more than one authentication profile is associated with a user, then the servers will be contacted one-by-one
until a connection to one of them is successful. Once a server has been contacted, if the authentication fails, the
process ends, and the user is notified that the authentication failed.
1. Log into your Supervisor node.
2. Go to Admin > General Settings > External Authentication.
3. Click Add.
4. If you are setting up authentication for an organization within a multi-tenant deployment, select the
Organization.
5. Select the Protocol.
6. Complete the protocol settings.
LDAP Access IP
Select Set DN Pattern to open a text field in which you can enter the
DN pattern if you want to override the discovered pattern, or you
want to add a specific LDAP user.
See Adding Users from Active Directory via LDAP for more
information about configuration settings for LDAP.
Access IP
Shared Secret
RADIUS
Select CHAP if you are using encrypted authentication to your
RADIUS server
Okta Certificate
See Configuring Okta Authentication for more information.
7. Click Test, and then enter credentials associated with the protocol you selected to make sure users can
authenticate to your deployment.
You can now associate users to this authentication profile as described in Adding a Single User.
User Guide 46
Fortinet Technologies Inc.
Initial System Configuration Configuring FortiSIEM
To use Okta authentication for your FortiSIEM deployment, you must set up a SAML 2.0 Application in Okta, and
then use the certificate associated with that application when you configure external authentication
1. Log into Okta.
2. In the Applications tab, create a new application using Template SAML 2.0 App.
3. Under General Settings, configure these settings:
Destination https://<FortiSIEMIP>/phoenix/okta
Recipient FortiSIEM
authnContextClassRef PasswordProtectedTransport
Request Uncompressed
4. Click Save.
5. In the Sign On tab, click View Setup Instructions.
6. Click Download Certificate.
7. Follow the instructions in Setting Up External Authentication and enter the downloaded certificate for Okta
authentication.
47 User Guide
Fortinet Technologies Inc.
Configuring FortiSIEM Initial System Configuration
Related Links
l Default Roles
l Creating Custom User Roles
User Guide 48
Fortinet Technologies Inc.
Initial System Configuration Configuring FortiSIEM
49 User Guide
Fortinet Technologies Inc.
Configuring FortiSIEM Initial System Configuration
Protocol Port
User Guide 50
Fortinet Technologies Inc.
Initial System Configuration Configuring FortiSIEM
If the number of users are less than 200, then Test Connectivity will discover all the users.
Okta API has some restrictions that does not allow FortiSIEM to pull more than 200 users. In this case, follow
these steps:
1. Login to Okta.
2. Download user list CSV file (OktaPasswordHealth.csv) by visiting Admin > Reports > Okta Password Health.
3. Rename the CSV file to "all_user_list_%s.csv". (%s is the placeholder of token obtained in Create an Okta API
Token - Step 3, e.g. 'all_user_list_00UbCrgrU9b1Uab0cHCuup-5h-6Hi9ItokVDH8nRRT.csv')
4. Login to FortiSIEM Supervisor node:
a. Upload csv file all_user_list_%s.csv to this directory /opt/phoenix/config/okta/
b. Make sure the permissions are admin and admin (Run "chown -R admin:admin
/opt/phoenix/config/okta/")
c. Go to Admin > Setup Wizard > Enter IP Range to Credential Associations. Select the Okta entry
and run Test connectivity to import all users.
51 User Guide
Fortinet Technologies Inc.
Configuring FortiSIEM Initial System Configuration
1. Sign up for a Duo Security account: signup. This will be admin account for Duo Security.
2. Log in to Duo Security Admin Panel and navigate to Applications
3. Click Protect an Application. Locate Web SDK in the applications.
4. Get API Host Name, Integration key, Secret key from the page. You will need it when you configure
FortiSIEM.
5. Generate Application key as a long string. This is a password that Duo Security will not know. You can choose
any 40 character long string or generate it as follows using python
import os, hashlib
print hashlib.sha1(os.urandom(32)).hexdigest()
This determines how the 2-factor authentication response page will look like in FortiSIEM and how user will
respond to the second factor authentication challenge
1. Log in to Duo Security as admin user
2. Choose the Logo which will be shown to users as they log on
3. Choose the super set of 2-factor Authentication Methods.
4. Optional - you can create the specific users that will logon via FortiSIEM. If the users are not pre-created here,
then user accounts will be created automatically when they attempt 2-factor authentication for the first time.
User Guide 52
Fortinet Technologies Inc.
Initial System Configuration Configuring FortiSIEM
Before logging in to FortiSIEM with 2-factor authentication, make sure that the three steps are completed.
1. Obtain keys for FortiSIEM to communicate with Duo Security.
2. Create and Manage FortiSIEM users in Duo Security.
3. Add 2-factor authentication option for FortiSIEM users.
53 User Guide
Fortinet Technologies Inc.
Configuring FortiSIEM Initial System Configuration
User Guide 54
Fortinet Technologies Inc.
Initial System Configuration Configuring FortiSIEM
Deleting Organizations
1. Log into your Supervisor node as a Super/Global user.
2. Go to Admin > Setup Wizard > Organizations.
3. Write down the ID of the organization you want to delete.
4. Go to Admin > Collector Health.
Note the IP Address and Collector Name of any Collectors associated with the organization you want to delete.
5. Log out of your Supervisor node.
6. SSH into the Collector hosts for the organization as root.
7. Using phTools, stop the Collector processes.
8. Power down the Collector.
9. Log back into your Supervisor node as an Admin user for the organization you want to delete.
10. Go to CMDB > Devices.
11. Delete all devices in both the Device View and the VM View.
12. Go to CMDB > Device View > Users, and delete all users except for the default admin account under which
you are currently logged in.
13. Go to Admin > Setup Wizard > Synthetic Transaction Monitoring and delete all STM tests.
14. Log out of your Supervisor node, and then log back in as the Super/Global user.
15. Go to Admin > Collector Health.
16. Delete the organization's Collectors.
Issues with Deleting Collectors Because of In-Memory Processes
You may encounter issues with deleting Collectors if there are processes in memory on the Supervisor
that are related to Collector status that are updated to the CMDB. If you encounter these issues, please
contact FortiSIEM Support.
17. Delete the organization.
18. Log out of your Supervisor node.
19. SSH into the Supervisor host machine as root.
20. In the /data directory, delete the eventdb database for that organization.
You can tell which EventDB belongs to the organization you want to delete based on the organization ID that
you wrote down in Step 3. For example, if the organization ID is 2005, you would look for
/data/eventdb/CUSTOMER_2005 as the database to delete. Be careful that you don't delete the EventDB for
a continuing organization.
55 User Guide
Fortinet Technologies Inc.
Configuring FortiSIEM Initial System Configuration
Guaranteed EPS Defined during the collector configuration process while setting up an
organization, FortiSIEM ensures that the collector can always send EPS
at this rate. This is a constant that never changes during the operation of
the algorithm, unless you edit the Collector definition.
This is the EPS that the Collector sees. This changes continuously. You
Incoming EPS
can view this metric for a Collector in Admin > Collector Health.
Allocated EPS This is the EPS that is currently allocated to the Collector by the
redistribution algorithm. Y ou can view this metric for a Collector in
Admin > Collector Health .
Each Collector periodically reports Incoming EPS to the Supervisor, which then determines the Allocated EPS and
pushes this control down to the collectors. Allocated EPS is set to Guaranteed EPS initially, but if for some
Collector, Incoming EPS is greater than Allocated EPS, the Supervisor examines all Collectors and determines
excess capacity as sum total of max (0,Allocated - Incoming) for all Collectors. If there is a Collector with excess
capacity, its Allocated EPS is reduced and the excess amount is given to the Collector that needs the excess EPS.
If the collector that gave up EPS, that is, Allocated EPS is less than Guaranteed EPS, subsequently needs the
EPS, then EPS is taken away from the collectors with Allocated greater than Guaranteed and given back. This
continuous readjustment is centrally coordinated by the Supervisor node.
User Guide 56
Fortinet Technologies Inc.
Initial System Configuration Configuring FortiSIEM
l For organizations with Collectors, discovery is carried out by the Collector, and the Collector assigns devices to the
organization with which it is associated. If organizations have an overlapping IP range, deploying Collectors and
assigning them to a specific IP range and organization will ensure that the device is added to the correct
organization.
l For organizations without Collectors, discovery is carried out by the Supervisor. In this case, the Include/Exclude
IP Range you defined when you set up the organization is used to add the device to the organization.
l If a device matches only one defined organization IP Range, then it is assigned to that organization
l If a device matches multiple defined IP Ranges, then it is assigned to the Super organization
You can change a device's assigned organization manually, and FortiSIEM will automatically update the
Include/Exclude IP Range for that organization. This updated IP range definition will then be used in the next
discovery process. However, this may create confusing IP range definitions for the organization, so you may want
to re-define the organization's IP range and rediscover devices.
57 User Guide
Fortinet Technologies Inc.
Configuring FortiSIEM Initial System Configuration
l Logon as super-global.
l Manually create the user as described in the manual user creation mode here.
l Choose the Default role.
l Choose the permitted organizations and also override the default role for a specific organization if needed. In the
example below, user1 is the Network Admin for every organization but System Admin for O-eng.
l Logon as super-global.
l Manually create the user as described in the manual user creation mode here.
l Choose the Default role.
User Guide 58
Fortinet Technologies Inc.
Initial System Configuration Configuring FortiSIEM
l Choose the permitted organizations. Override the default role for each specific organization, if needed. In the
example below, user1 is the Network Admin for every organization but System Admin for O-eng.
For the organizations-without-collector case, if the Active Directory Server belongs to super-local, then the
discovered users would be visible from the super-global view and any of these users can be made FortiSIEM user.
In this case the steps are
l Logon as super-global
l Create the user as described here - both manual and discovery-based approaches can be used
l Choose the Default role
l Choose the permitted organizations. And if needed, override the default role for specific organizations. In the
example below, user1 is the Network Admin for every organization but System Admin for O-eng.
59 User Guide
Fortinet Technologies Inc.
Configuring FortiSIEM Initial System Configuration
User Guide 60
Fortinet Technologies Inc.
Initial System Configuration Configuring FortiSIEM
61 User Guide
Fortinet Technologies Inc.
Configuring FortiSIEM Initial System Configuration
l Logon as super-global
l Create the user as described here - both manual and discovery-based approaches can be used
l Choose the Default role
l Choose the permitted organizations. And if needed, override the default role for specific organizations. In the
example below, user1 is the Network Admin for every organization but System Admin for O-eng.
User Guide 62
Fortinet Technologies Inc.
Discovering Infrastructure Configuring FortiSIEM
Discovering Infrastructure
FortiSIEM can automatically discover the devices, applications, and users in your IT infrastructure and begin
monitoring them. You initiate device discovery by providing the credentials that are needed to access the
infrastructure component, and from there FortiSIEM is able to discover information about your component such
as the host name, operating system, hardware information such as CPU and memory, software information such
as running processes and services, and configuration information. Once discovered, FortiSIEM will also begin
monitoring your component on an ongoing basis.
Though FortiSIEM is able to automatically manage device discovery, the pulling of event information such as logs
and IPS events from your device, and establishing what aspects of your device functionality it can monitor, you
can also manually configure the way FortiSIEM interacts with your infrastructure by creating custom event pulling
methods and monitoring profiles for your devices.
Windows servers can be discovered by either SNMP or WMI. or both. SNMP provides installed software
information, while WMI provides all application metrics, detailed system metrics, and logs.
l Discovery Settings
l Discovery for Multi-Tenant Deployments
l Setting up CyberArk
l Setting Access Credentials for Device Discovery
l Discovering Devices
l Discovering Amazon Web Services (AWS) Infrastructure
l Discovering Microsoft Azure Infrastructure
l Approving Newly Discovered Devices
l Inspecting Event Pulling Methods for Devices
l Inspecting Changes Since Last Discovery
l Discovery Range Definition Options
l Scheduling a Discovery
l Adding Devices to the CMDB Outside of Discovery
l Decommissioning a device
63 User Guide
Fortinet Technologies Inc.
Configuring FortiSIEM Discovering Infrastructure
Discovery Settings
Before you initiate discovery, you should configure the Discovery Settings in your Supervisor.
1. Log in to your Supervisor node.
2. Go to Admin > General Settings > Discovery.
3. Configure the settings as required for your deployment.
See Setting Device Location Information for information on how to manually enter locations for devices, or to
upload a CSV file of device locations.
Setting Description
Virtual IPs Often a common virtual IP address will exist in multiple machines for load
balancing and failover purposes. When you discover devices, you need to
have these virtual IP addresses defined within your discovery settings for
two reasons:
l Listing the virtual IP addresses ensures that two or more devices with the
same virtual IP will not be merged into one device during device discovery,
so each of the load-balanced devices will maintain their separate identity in
the CMDB
l The virtual IP will not be used as an access IP during discovery, since the
identity of the device when accessed via the virtual IP is unpredictable
Click the Edit icon to enter a Virtual IP address, and then click + to add
more.
An enterprise often has servers that share credentials, for example mail
servers, web proxies, and source code control servers, and a large number
of users will authenticate to these servers to access their services.
Providing a list of of the IP addresses for these servers allows FortiSIEM to
exclude these servers from user identity and location calculations in the
Excluded Analytics > IdentityandLocation report.
Shared
Device IPs For example, suppose user U logs on to server M to retrieve his mail, and
server M authenticates user U via Active Directory. If server M is not
excluded, the Analytics > Identity and Location Report will contain
two entries for user U: one for the workstation that U logs into, and also
one for server M. You can eliminate this behavior by adding server M to
the list of Server IPs with shared credentials.
User Guide 64
Fortinet Technologies Inc.
Discovering Infrastructure Configuring FortiSIEM
Setting Description
Allow With this setting you can control incident firings based on approved device
Incident status. If you select Approved Devices Only, then FortiSIEM will use
Firing On this logic to determine if an incident is triggered:
l If an incident reporting device is not approved, the incident does not trigger
l If an incident reporting device is approved, then there are two possible
cases: (a) at least one Source, Destination or Host IP is approved and the
incident triggers, or (b) none of the Source, Destination or Host IPs are
approved and the incident does not trigger
If you select Approved Devices Only, then when the discovery process
completes, you will need to approve devices, as described in Approving
Newly Discovered Devices, before incidents are triggered.
This setting allows you to limit the set of devices that the system
automatically discovers from logs and netflows. After receiving a log from
a device, the system automatically discovers that device, and then adds it
to CMDB. For example, when a Netflow analysis detects a TCP/UDP
service is running on a server, the server, along with the open ports, are
added to CMDB. Sometimes you may not want to add all of these devices
to CMDB, so you can create filters to exclude a specific set of devices from
being added to CMDB.
Click Add to add a new CMDB Device Filter, then click Apply.
65 User Guide
Fortinet Technologies Inc.
Configuring FortiSIEM Discovering Infrastructure
Setting Description
Application This setting allows you to limit the set of applications/processes that the
Filtering system automatically learns from discovery.
Click Add, then enter the Process Name and any Parameters for that
process that you want to filter.
User Guide 66
Fortinet Technologies Inc.
Discovering Infrastructure Configuring FortiSIEM
Prerequisite
Before you can upload it, you must first create a CSV file with this format.
latitude:;longitude:;")
67 User Guide
Fortinet Technologies Inc.
Configuring FortiSIEM Discovering Infrastructure
Example
"region:North America;country:United
States;state:California;
Fremont
"30.1.1.10" true city:Fremont;building:
Datacenter USA
10;floor:4;latitude:38.1747222;longitud e:-
121.2775;"
Procedure
User Guide 68
Fortinet Technologies Inc.
Discovering Infrastructure Configuring FortiSIEM
l For organizations with collectors, you must initiate discovery using the administrative account associated with the
organization. Every device discovered by a collector is automatically assigned to the organization that the collector
belongs to.
l For organizations without collectors, you must initiate discovery using the Super/Global administrative account.
Devices for all organizations are discovered at the same time, and are assigned to organizations based on the IP
address assignments you set up for the organization.
.
l If a device matches only one organization's IP address assignment, then it is assigned to that organization
l If a device matches multiple organization definitions, then it is assigned to the Super/Global organization.
These would typically be devices that are part of the Super/Global organization's network backbone.
Related Links
69 User Guide
Fortinet Technologies Inc.
Configuring FortiSIEM Discovering Infrastructure
Setting up CyberArk
This section specifies how FortiSIEM can be configured to fetch credentials from CyberArk.
User Guide 70
Fortinet Technologies Inc.
Discovering Infrastructure Configuring FortiSIEM
d. In the Business owner section, specify contact information about the application’s Business owner.
e. In the lowest section, specify the Location of the application in the Vault hierarchy. If a Location is not
selected, the application will be added in the same Location as the user who is creating this application.
f. Click Add; the application is added and is displayed in the Application Details
page
3. Check Allow extended authentication restrictions – this enables you to specify an unlimited number of
machines and Windows domain OS users for a single application
4. Specify the application’s (FortiSIEM) Authentication details. This information enables the Credential Provider to
check certain application characteristics before retrieving the application password.
a. In the Authentication tab, click Add; a drop-down list of authentication characteristics is displayed.
b. Specify the OS user as “admin” and Click Add.
c. Specify the application path as “/opt/phoenix/bin”. Make sure Path is folder and Allow internal scripts to
request credentials... check boxes are checked
d. Do not specify a hash
e. In the Allowed Machines tab, click Add and specify the IP/host name of the FortiSIEM Supervisor,
Workers and Collectors
5. Authorize FortiSIEM to retrieve accounts.
a. Go to Policies > Access Control (Safes)
b. For every Safe, Click on Members.
c. Click on Add Safe Member
d. Search for FortiSIEM. An entry will already exist. Select that entry.
e. Check Retrieve accounts.
f. Click Add
Now FortiSIEM should be ready to retrieve passwords from CyberArk via Test Connectivity and Discovery.
71 User Guide
Fortinet Technologies Inc.
Configuring FortiSIEM Discovering Infrastructure
SNMP, VM SDK (for VMware vCenter), or WMI (for Windows devices) must be one of the access protocols for
which you provide credentials in order for the devices associated with an IP address or range to be discovered. If
your device does not use one of these protocols, then you must configure it to communicate with FortiSIEM as
described in FortiSIEM External Systems Configuration Guide. As described in those topics, you may also need
to set up additional configurations within your devices to send logs and other information to FortiSIEM.
Associate Credentials Only with the IP Address Where They Will be Used
Credentials should only be associated with IP addresses where they can be used. Assigning multiple credentials
to IP addresses where they are not used will trigger discovery operations for each credential, and the system will
wait for a timeout to occur for each credential before it moves to the next one. This will cause the discovery
process to require much more processing time and processing power from the FortiSIEM system. You can,
however, associate the same credential (for example, a generic SNMP access credential) to multiple IP
addresses where it will be used to communicate with a device over that protocol.
Before starting the discovery process, credentials need to be defined and then associated to specific IP
addresses.
CyberArk configuration
If CyberArk is going to be used for Test Connectivity and Discovery, then first follow the steps defined here.
Define Credentials
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. Select a Device Type to associate with the credential.
6. Select the Access Protocol for which you want to enter credentials.
Note that the Device Type selection determines which Access Protocols are available.
Change the default destination ports only if needed
7. Choose Password Configuration method
1. Manual - means that you have to define credentials in FortiSIEM
2. CyberArk - means Accelps will fetch credentials from CyberArk
8. If you choose Password Configuration as Manual, then enter the credentials required for the Access Protocol.
9. If you choose Password Configuration as CyberArk, then choose CyberArk parameters
1. AppID must be set to FortiSIEM
2. Specify Safe, Folder, Object: This is the CyberArk Vault Safe, Folder, Object where the credential is
defined.
User Guide 72
Fortinet Technologies Inc.
Discovering Infrastructure Configuring FortiSIEM
A IP subnet specified in CIDR notation <IP Address>/<Maskbits> e.g. 192.168.0.0/16 to specify the IP
range 192.168.0.0-192.168.255.255
A combination of the three formats separated by comma, e.g. 192.168.1.1, 192.168.1.2, 10.10.0.0/16,
10.11.0.0-10.11.255.255
A host name
4. Click OK.
Test Connectivity
You need to perform a Test Connectivity to make sure that the credentials are correct.
1. Select the IP/credential association you just created, and click Test Connectivity. A ping will be performed first to
make sure that the host is alive. If ping is disabled in your network, then choose Test Connectivity without
ping.
A dialog will show you the results of your connectivity tests. Note that the connectivity tests can take several
minutes, so you may want to use the Run in Background option.
73 User Guide
Fortinet Technologies Inc.
Configuring FortiSIEM Discovering Infrastructure
Discovering Devices
Prerequisites
l Make sure you have configured the Discovery Settings for your deployment
l 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 Service Provider 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 Discovery for Multi-Tenant Deployments for more information
about how discovery works for Service Provider deployments with and without Collectors.
l A device is not online or not reachable via ping. FortiSIEM will attempt to ping devices before initiating a
full discovery to save time.
l A device is not responding to SNMP or WMI requests, or there is a firewall blocking these requests from
FortiSIEM
l The SNMP/WMI credentials are incorrect
l WMI may not have been set up correctly on the server. See the appropriate topic in FortiSIEM External
Systems Configuration Guide 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.
User Guide 74
Fortinet Technologies Inc.
Discovering Infrastructure Configuring FortiSIEM
75 User Guide
Fortinet Technologies Inc.
Configuring FortiSIEM Discovering Infrastructure
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.
User Guide 76
Fortinet Technologies Inc.
Discovering Infrastructure Configuring FortiSIEM
3. Login to the Azure old portal, upload the .cer to the Settings ->"Management Certificates" section.
77 User Guide
Fortinet Technologies Inc.
Configuring FortiSIEM Discovering Infrastructure
7. Click Test Connectivity to make sure you can reach your instance and that all credentials are entered correctly
before you initiate discovery.
User Guide 78
Fortinet Technologies Inc.
Discovering Infrastructure Configuring FortiSIEM
Related Links
l Discovery Settings
79 User Guide
Fortinet Technologies Inc.
Configuring FortiSIEM Discovering Infrastructure
Status Description
Successful If event information is being pulled from the device, you will see the name of the
event pulling method rendered in plain black text.
Added but If the name of the event pulling method has a Star icon next to it, event
Not information can be successfully pulled from the device, but the perfMonitor
Monitored module has not yet initiated monitoring.
Paused A Pause icon indicates that event information is not being pulled from the device
because it failed the verification check at the beginning of the monitoring cycle.
This is usually caused by an issue with the access protocol credentials. The
credential was valid when discovery succeeded, and so the event pulling method
was able to monitor the associated metrics, but the perfMonitor module failed
on the credential at a later time. You should check the access protocol credentials
associated with the devices and event pulling methods, and then re-initiate
discovery of the device.
An Alert icon and the name of the event pulling method in red indicates that
Failed
adding that event pulling method for the device failed.
3. Click Show Errors to view a more detailed description of any errors associated with an event pulling method.
4. Click Edit to change any of the event pulling methods associated with a device.
5. Click Apply to apply any changes to your event pulling methods.
6. Click Test Pull Events to test any changes you make.
User Guide 80
Fortinet Technologies Inc.
Discovering Infrastructure Configuring FortiSIEM
81 User Guide
Fortinet Technologies Inc.
Configuring FortiSIEM Discovering Infrastructure
Discover Routes Selected by default, if you clear this option then discovery will not use the route table to find next
hop devices. This can be useful if your network includes border routers, which can significantly
impact the time required for the discovery process.
Smart Scan Smart Scan is an optimized search method in which only the live devices
in the network are searched. To use Smart Scan, you first provide a root
device (typically the first hop Layer 3 router). FortiSIEM then discovers
the root device and learns of its first hop neighbors from the ARP table.
These devices are then discovered using existing credentials, and their
one hop neighbors are subsequently discovered. This continues until no
more devices are discovered. Often a single Layer 3 router, switch, or
firewall is sufficient to discover the entire network. However, if a firewall
that can block SNMP is installed, then devices on either side of the
firewall need to be provided as root devices. Smart Scan is usually faster
than Range Scan, but in rare cases discovery can miss a device when it
is quiet and not present in the ARP table of adjacent devices.
Discovery Type
In contrast to Smart Scan, Range Scan is a brute force method in which
Range Scan FortiSIEM attempts to discover all the devices in the IP ranges you
(default) provide. With Range Scan, FortiSIEM will first attempt to ping a device,
and if that succeeds, discovery will proceed.
AWS Scan AWS Scan is used to discover devices in Amazon Web Services.
See Discovering Amazon Web Services (AWS) Infrastructure for more
information.
Do Not Ping Before To save time, FortiSIEM first attempts to reach devices by ping before initiating discovery. You
Discovery should select this option if ping has been disabled for your network, otherwise discovery will fail.
Include Powered
By default, only powered on VMs are discovered.
Off VMs
User Guide 82
Fortinet Technologies Inc.
Discovering Infrastructure Configuring FortiSIEM
Click the Edit icon to select devices that you want to include or exclude from the discovery
Include/Exclude
process. Note that if you have entries for both of these option, the discovery process will
Device Types
prioritize included devices over excluded ones.
Include/Exclude Enter the domains you want to include or exclude from the discovery process.
Domains (AWS
Only)
Include/Exclude
Enter the IP addresses or host names you want to include or exclude from the discovery process.
Ranges
Include/Exclude Enter the zones you want to include or exclude from the discovery process.
Zones (AWS Only)
If you select this option, discovery will only find those devices whose IP addresses do not match
the address of any device in CMDB. To make an exception to this rule, specify a list of IP
Only Discover
addresses in the Exclude Ranges field. The primary use case for this is for indirect device
Devices not in
discovery such as VCenter-based VM discovery, or WLAN controller-based access point
CMDB
discovery. By specifying the VCenter IP address in the Exclude Ranges field, new guest VMs can
always be discovered even if the VCenter is already in the CMDB.
Ping Only Select this option if you are only interested in discovering whether a device or service is up or
Discovery down.
Root IPs For Smart Scan only, provide the root IPs from which you want the Smart Scan to start.
83 User Guide
Fortinet Technologies Inc.
Configuring FortiSIEM Discovering Infrastructure
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 + icon.
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.
User Guide 84
Fortinet Technologies Inc.
Discovering Infrastructure Configuring FortiSIEM
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
85 User Guide
Fortinet Technologies Inc.
Configuring FortiSIEM Discovering Infrastructure
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:
User Guide 86
Fortinet Technologies Inc.
Discovering Infrastructure Configuring FortiSIEM
Both the actions are taken, that is, if both a Group and a Business Service is specified, then the device will be
added to both the specified Group and Business Service.
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.
87 User Guide
Fortinet Technologies Inc.
Configuring FortiSIEM Configuring Monitoring
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 FortiSIEM External Systems Configuration Guide. 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.
User Guide 88
Fortinet Technologies Inc.
Configuring Monitoring Configuring FortiSIEM
89 User Guide
Fortinet Technologies Inc.
Configuring FortiSIEM Configuring Monitoring
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
3. Click Enable. This will stop all interface monitoring.
4. Click Add.
5. Select either Device View or Interface View.
6. Select a device to view and select its interfaces, or select an interface.
7. Click OK to add the selected interface to the list. The Critical and Monitor boxes would be automatically
checked.
8. 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.
9. Click Apply All. Now FortiSIEM will start monitoring only the selected interfaces in this tab will be monitored.
10. If you want to disable this behavior and return to ALL interface monitoring (as in releases prior to 4.8), then click
Disable.
User Guide 90
Fortinet Technologies Inc.
Configuring Monitoring Configuring FortiSIEM
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.
FortiSIEM continuously monitors every process on every server and network device for resource utilization and
up/down. By marking an process as Critical, (a) up/down was monitored for Critical processes only, but (b) all
processes were monitored for resource utilization. Since there are a large number of processes across all device
types, a large number of events can be generated.
FortiSIEM would monitor only the processes marked as Critical in this tab. It is important to define ALL
critical processes at once.
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 processes.
2. Go to Admin > General Settings > Monitoring > Important Processes
3. Click Enable. This will stop monitoring all processes.
4. Click Add.
5. Enter a Process Name and any Parameters, and then click OK.
6. Click Apply All. Now FortiSIEM will start monitoring only the selected processes in this tab.
7. If you want to disable this behavior and return to ALL process monitoring, then click Disable.
91 User Guide
Fortinet Technologies Inc.
Configuring FortiSIEM Configuring Monitoring
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.
User Guide 92
Fortinet Technologies Inc.
Configuring Monitoring Configuring FortiSIEM
Use this list to exclude read-only disk volumes or partitions that do not grow in size and are almost full. This will
prevent from these servers from always showing a CRITICAL status in dashboards.
93 User Guide
Fortinet Technologies Inc.
Configuring FortiSIEM Configuring Monitoring
Select Single Line Display to view each device, along with its list of application and system monitors,
on a single line.
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. You can also enable or disable the metrics for a device's monitor type by clicking on the System
Monitoring or Application Monitoring section for the 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.
User Guide 94
Fortinet Technologies Inc.
Configuring Monitoring Configuring FortiSIEM
Service Degraded - Slow Detects that the response time of an end-user monitored service is greater
Response to STM than a defined threshold (average over 3 samples in 15 minutes is more than
5 seconds)
Service Down - No Detects a service suddenly went down from the up state and is no longer
Response to STM responding to synthetic transaction monitoring probes.
Service Staying Down - No Detects a service staying down, meaning that it went from up to down and
Response to STM did not come up, and is no longer responding to end user monitoring probes
95 User Guide
Fortinet Technologies Inc.
Configuring FortiSIEM Configuring Monitoring
User Guide 96
Fortinet Technologies Inc.
Configuring Monitoring Configuring FortiSIEM
HTTP(S) - This test uses a Upload: select the java file you exported How to export:
Selenium Selenium script to from Selenium
play back a series l Make sure Selenium IDE is
Script
of website actions Total Timeout: the script must complete installed within Firefox browser
in FortiSIEM. by this time or the test will be considered l Open Firefox
failed l Launch Tools > Selenium IDE.
From now on, Selenium is
Step Timeout: each step must complete recording user actions
by this time
l Visit websites
l Once done, stop recording
l Click File > Export Test case as
> Java / Junit 4 /WebDriver
l Save the file as .java in your
desktop. This file has to be
inputted in FortiSIEM.
97 User Guide
Fortinet Technologies Inc.
Configuring FortiSIEM Configuring Monitoring
User Guide 98
Fortinet Technologies Inc.
Configuring Monitoring Configuring FortiSIEM
LDAP This test connects Base DN: an LDAP base DN You will need to have set up an access
to the LDAP you want to run the test against credential for the LDAP server before
server, and checks you can set up this test
the response time Filter: any filter criteria for the
and expected Base DN
results
Scope: any scope for the test
Timeout: t his is the primary
success criterion - if there is no
response within the time
specified here, then the test fails
99 User Guide
Fortinet Technologies Inc.
Configuring FortiSIEM Configuring Monitoring
TRACE This test issues a Timeout: If there is no response For the trace route from AO to
ROUTE trace route from the system within the time destination D via hops H1, H2, H3,
command to the specified here, then the test FortiSIEM generates 3 hop by hop PH_
destination and fails. DEV_MON_TRACEROUTE events.
parses the results First event: Source AO,
to create PH_ Protocol Type: Specifies the IP destination H1, Min/Max/Avg
DEV_MON_ protocol over which trace route RTT, Packet Loss for this hop
TRACEROUTE packets are send - current
events, one for options are UDP, TCP and Second event: Source H1,
each hop. ICMP destination H2, Min/Max/Avg
RTT, Packet Loss for this hop
Max TTL: Max time to live (hop)
value used in outgoing trace Third event: Source H2,
route probe packets. destination H3, Min/Max/Avg
RTT, Packet Loss for this hop
Wait Time: Max time in
seconds to wait for a trace route Fourth event: Source H3,
probe response destination D, Min/Max/Avg
RTT, Packet Loss for this hop
Related Links
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 >> to 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.
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.
l Prerequisites
l Procedure
Prerequisites
l Contact FortiSIEM support and make sure that your license includes Data Update Service.
l 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.
l Make sure you have license credentials.
Procedure
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.
l Vendor
l Model
l Version
Application Type l Device/App Group
l Biz Service group
l Application Package Group
l Description
4. Click Save.
All custom event types must begin with the prefix P H_DEV_MON_CUST_ .
You can clone an existing event attribute type to use as the basis for a new one. Select the event attribute type
you want to use, click Clone, and then modify as necessary.
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.
The basic template for a custom parser XML specification includes five sections. Click on the name of any section
for more information.
Section Description
Device Type The type of device or application associated with the parser
Format Recognizer Patterns that determine whether an event will be parsed by this
Specification parser
Pattern Definition Defines the parsing patterns that are iterated over by the parsing
Specification instructions
Parsing Instructions Instructions on how to parse events that match the format
Specification recognizer patterns
This section specifies the name of the parser, which is used only for readability and identifying the device type
associated with the parser.
<eventParser name="CiscoIOSParser"></eventParser>
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.
In the examples in this topic, <Version> is set to ANY because events are generally not tied to a particular
version of a device or software. You could of course set this to a specific version number if you only wanted this
parser to apply to a specific version of an application or device.
<Vendor> and <Model> entries must match the spelling and capitalization in the CMDB.
Hardware Appliances
In this case, the type of event being parsed specifies the device type, for example Cisco IOS, Cisco ASA, etc.
<deviceType> <Vendor>Cisco</Vendor> <Model>IOS</Model> <Ver-
sion>ANY</Version></deviceType>
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
<deviceType> <Vendor>Microsoft</Vendor> <Model>Windows</Model> <Ver-
sion>ANY</Version></deviceType>
In this case, the events being parsed specify the device and application types because Microsoft SQL Server can
only run on Microsoft Windows OS.
<deviceType> <Vendor>Microsoft</Vendor> <Model>Windows</Model> <Ver-
sion>ANY</Version></deviceType><appType> <Vendor>Microsoft</Vendor>
<Model>SQL Server</Model> <Version>ANY</Version> <Name> Microsoft SQL Server-
</Name></appType>
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.
<deviceType> <Vendor>Generic</Vendor> <Model>Generic</Model> <Ver-
sion>ANY</Version></deviceType><appType> <Vendor>Oracle</Vendor> <Model>Data-
base Server</Model> <Version>ANY</Version> <Name>Oracle Database
Server</Name></appType>
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.
FortiSIEM parser processes the files in the specific order listed in the file parserOrder.csv.
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.
Cisco IOS
Cisco ASA
All Cisco ASA events have the pattern ASA-severity-id pattern, for example ASA-5-12345.
<eventFormatRecognizer><![CDATA[ASA-\d-\d+]]></eventFormatRecognizer>
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,,,icm
p,vsys1,untrust,untrust,ethernet1/1,ethernet1/1,syslog-
172.16.20.152,2010/05/06
15:51:04,600,2,0,0,0,0,0x40,icmp,allow,196,196,196,2,2010/05/06
15:50:58,0,any,0
<eventFormatRecognizer><![CDATA[<:gPatTime>,\w+,
(?:TRAFFIC|THREAT|CONFIG|SYSTEM)]]></eventFormatRecognizer>
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.
If there is a pattern definition that you wan to use in multiple parser specification, you need to define it in the file
GeneralPatternDefintions.xml, and then refer to it from your s, then it needs to be defined in the
file GeneralPatternDefinitions.xml. The patterns in that file are named with a g prefix, and can be
referenced as shown in this example:
<generalPatternDefinitions>
<pattern name="gPatSyslogPRI"><![CDATA[<\d+>]]></pattern>
<pattern name="gPatMesgBody"><![CDATA[.*]]></pattern> <pattern name-
e="gPatMonNum"><![CDATA[\d{1,2}]]></pattern> <pattern name="gPatDay"><![CDATA
[\d{1,2}]]></pattern> <pattern name="gPatTime"><![CDATA[\d{1,2}:\d{1,2}:\d
{1,2}]]></pattern> <pattern name="gPatYear"><![CDATA[\d{2,4}]]></pat-
tern></generalPatternDefinitions>
Each pattern has a name and the regular expression pattern within the CDATA section. This the basic syntax.
<pattern name="patternName"><![CDATA[pattern]]></pattern>
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.
<pattern name="patSolarisMod" list="begin"><![CDATA[ssh-
d|login|]]></pattern><pattern name="patSolarisMod" list="continue"><![CDATA[inet-
d|lpstat|]]></pattern><pattern name="patSolarisMod" list="end"><![CDATA
[su|sudo]]></pattern>
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.
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.
Inbuilt Functions
Scale Function
This is accomplished by using the scale function.
<setEventAttribute attr="durationMSec">scale($_durationSec, 1000)</-
setEventAttribute>
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.
<setEventAttribute attr="destName">trimAttribute($destName, ".")</-
setEventAttribute>
Branching Constructs
Choose Construct
Switch Construct
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:
<collectAndSetAttrByRegex src="$inputString "> <regex><![CDATA[reg-
expattern]]></regex> </collectAndSetAttrByRegex>
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.
l Key=value structured
l Value list structured
In each case, two simpler specialized parsing constructs than are provided
When a key1 match is found, then the entire string following key1 up to the separatorString is parsed out
and stored in the attribute variableOrEventAttribute1.
Value Attribute
00 16 B6 DB 12 22 srcMACAddr
00 21 55 4D 66 B0 destMacAddr
2 wlanRadioId
00:1a:1e:c0:60:7a apMac
When the position offset1 is encountered, the subsequent values up to the separatorString is stored in
variableOrEventAttribute1.
As an example, consider this log fragment.
_body =
W3SVC1 ADS-PRI 192.168.0.10 GET /Document/ACE/index.htm - 80 - 192.168.20.55
HTTP/1.1 Mozilla/5.0+(Windows;+U;+Windows+NT+5.1;+en-US;+r-
v:1.8.1.11)+Gecko/20071127+Firefox/2.0.0.11 [http://wwwin/Document/] wwwin 200 0 0
5750 445 15
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.
Custom parsers can only be created from the Super/Global account in Service Provider FortiSIEM deployments.
l Prerequisites
l Procedure
Prerequisites
l You should have examples of the logs that you want to parse
l You should have created any new device/application types, event attribute types, or event types that you want to
use in your XML specification
l You should already have written the XML specification for your parser
l 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
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.
Parser Examples
l Cisco IOS Syslog Parser
Create the parser XML file with this content, and add the pattern definition patCiscoIOSMod for detecting IOS
modules such as SEC.
<eventParser name="CiscoIOSParser"> <deviceType> <Vendor>Cisco</Vendor>
<Model>IOS</Model> <Version>ANY</Version> </deviceType> <pat-
ternDefinitions> <pattern name="patCiscoIOSMod" list="begin"> <![CDATA
[FW|SEC|SEC_LOGIN|SYS|SNMP|]]></pattern> <pattern name="patCiscoIOSMod" list-
t="continue"> <![CDATA[LINK|SPANTREE|LINEPROTO|DTP|PARSER|]]></pattern> <pat-
tern name="patCiscoIOSMod" list="end"><![CDATA[CDP|DHCPD|CONTROLLER|PORT_SECURITY-
SP]]></pattern> <pattern name="patStrEndColon"><![CDATA[[^:]*]]></pattern>
<pattern name="patComm"><![CDATA[[^,]+]]></pattern> </pat-
ternDefinitions></eventParser>
Add this format recognizer for detecting %SEC-6-IPACCESSLOGP, which is a signature of Cisco IOS syslog
messages.
<eventParser name="CiscoIOSParser"> <deviceType> <Vendor>Cisco</Vendor>
<Model>IOS</Model> <Version>ANY</Version> </deviceType> <pat-
ternDefinitions> <pattern name="patCiscoIOSMod" list="begin"> <![CDATA
[FW|SEC|SEC_LOGIN|SYS|SNMP|]]></pattern> <pattern name="patCiscoIOSMod" list-
t="continue"> <![CDATA[LINK|SPANTREE|LINEPROTO|DTP|PARSER|]]></pattern>
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:
<generalPatternDefinitions> <pattern name="gPatSyslogPRI"><![CDATA
[<\d+>]]></pattern> <pattern name="gPatMesgBody"><![CDATA[.*]]></pattern> <pat-
tern name="gPatMon"> <![CDATA[Jan|Feb|Mar|Apr|May|Jun|Jul|Aug|Sep|Oct|Nov|Dec|\d
{1,2}]]></pattern> <pattern name="gPatDay"><![CDATA[\d{1,2}]]></pattern> <pat-
tern name="gPatTime"><![CDATA[\d{1,2}:\d{1,2}:\d{1,2}]]></pattern> <pattern name-
e="gPatInt"><![CDATA[\d+]]></pattern></generalPatternDefinitions>
This parser file XML fragment for parsing the example syslog message looks like this:
<parsingInstructions> <collectFieldsByRegex src="$_rawmsg"> <regex><!
[CDATA[<:gPatSyslogPRI>?<:gPatMon>\s+<:gPatDay>\s+<:gPatTime> %<_evIdPre-
fix:patCiscoIOSMod>-<_severity:gPatInt>-<_evIdSuffix:patStrEndColon>: <_
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-
r="eventSeverity">10</setEventAttribute> </when> <when test='$_sever-
ity = "2"'> <setEventAttribute
attr="eventSeverity">8</setEventAttribute> </when> <when test='$_
severity IN "3, 4"'> <setEventAttribute attr-
r="eventSeverity">5</setEventAttribute> </when> <when test='$_severity =
"5"'> <setEventAttribute attr="eventSeverity">2</setEventAttribute>
</when> </choose><parsingInstructions>
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 values.
2. Parsing the protocol, source and destination IP, port, and totalPackets.
3. Converting the protocol string to a protocol integer.
<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+<_pro-
to:gPatWord>\s+<srcIpAddr:gPatIpV4Dot>\(<srcIpPort:gPatInt>\)<:gPatMesgBody>-
>\s+<destIpAddr:gPatIpV4Dot>\(<destIpPort:gPatInt>\),\s+<totPkts:gPatInt>
<:gPatMesgBody>]]> </regex> </collectAndSetAttrByRegex>
<choose> <when test='$_action = "permitted"'> <setEventAt-
tribute attr="eventType">combineMsgId("IOS-", $_evIdPrefix, "-", $_evIdSuffix, "-
PERMITTED")</setEventAttribute> <setEventAttribute attr-
r="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> </when></choose>
Final Parser
<eventParser name="CiscoIOSParser"> <deviceType> <Vendor>Cisco</Vendor>
<Model>IOS</Model> <Version>ANY</Version> </deviceType> <pat-
ternDefinitions> <pattern name="patCiscoIOSMod" list="begin"> <![CDATA
[FW|SEC|SEC_LOGIN|SYS|SNMP|]]></pattern> <pattern name="patCiscoIOSMod"
list="continue"> <![CDATA[LINK|SPANTREE|LINEPROTO|DTP|PARSER|]]></pattern>
<pattern name="patCiscoIOSMod" list="end"><![CDATA[CDP|DHCPD|CONTROLLER|PORT_
SECURITY-SP]]></pattern> <pattern name="patStrEndColon"><![CDATA
[[^:]*]]></pattern> <pattern name="patComm"><![CDATA[[^,]+]]></pattern>
</patternDefinitions> <parsingInstructions> <!—parse header --> <col-
lectFieldsByRegex src="$_rawmsg"> <regex><![CDATA[<:gPatSys-
logPRI>?<:gPatMon>\s+<:gPatDay>\s+<:gPatTime> %<_evIdPrefix:patCiscoIOSMod>-<_
severity:gPatInt>-<_evIdSuffix:patStrEndColon>: <_body:gPatMesgBody>]]></regex>
</collectFieldsByRegex> <setEventAttribute attr="eventType">combineMsgId("IOS-
", $_evIdPrefix, "-", $_evIdSuffix)</setEventAttribute> <choose> <when
test='$_severity IN "6, 7"'> <setEventAttribute attr-
r="eventSeverity">1</setEventAttribute> </when> <when test='$_sever-
ity = "1"'> <setEventAttribute
attr="eventSeverity">10</setEventAttribute> </when> <when test='$_
severity = "2"'> <setEventAttribute attr-
r="eventSeverity">8</setEventAttribute> </when> <when test='$_sever-
ity IN "3, 4"'> <setEventAttribute
attr="eventSeverity">5</setEventAttribute> </when> <when test='$_sever-
ity = "5"'> <setEventAttribute attr="eventSeverity">2</setEventAttribute>
</when> </choose> <!—parse body --> <choose> <when
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
In Service Provider FortiSIEM deployments, custom performance performance have to be created by the
Super/Global account, and apply to all organizations. In enterprise deployments, custom performance monitors
can be created by any user who has access to the Admin tab.
l Prerequisites
l Procedure
Prerequisites
l 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.
l You should have created any new device/application types, event attribute types, or event types that you want to
use in your performance monitor
l You should have the IP address and access credentials for a device that you can use to test the monitor
Procedure
14. In the bottom pane of the dialog, select the custom performance monitor.
15. Click Save.
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.
When configuring JDBC as the access protocol for a custom performance monitor, use these settings. You may
also want to review the topic Custom JDBC Performance Monitor for a Custom Table as example of how to set up
a custom performance monitor using JDBC.
Field Setting/Notes
Method JDBC
This creates the mapping between columns in the database and FortiSIEM
List of Columns event attributes. See Mapping Monitoring Protocol Objects to Event Attributes
for more information.
Where Clauses This indicates whether the database table being queried has a fixed set of
rows, or whether it is growing over time. An example of this would be a table
containing logs, in which case FortiSIEM would keep track of the last entry and
only pull the new ones. There are three options here:
1. There is a fixed set of rows and all rows are needed.
Leave all options cleared.
2. There is a fixed set of rows and a fixed number of rows are needed.
Select Fixed Records and enter the number of required rows.
3. The table is growing and only new values are needed.
Select Retrieve all new values since last retrieve time of
column, and enter the name of the column that represents time in
the database. FortiSIEM will keep track of the largest value in this
column and only pull entries greater than that value during the next
polling interval.
When configuring JMX as the monitoring protocol for a custom performance monitor, use these settings. You
may also want to review the topic Custom JMX Monitor for IBM Websphere as an example of creating a custom
JMX performance monitor.
Field Setting/Notes
Method JMX
Enter the MBean interface that you want to monitor, or click the downward
arrow to browse the JMX tree and select it. Note that the option you select
MBean here will determine the objects that are available when you select an
Object Attribute for the List of Attributes. See the next section in this
topic for information on how to find
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 tab.
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.
When configuring SNMP as the access protocol for a custom performance monitor, use these settings. You may
also want to review the topics Custom 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.
Field Settings/Notes
Method SNMP
The parent Object Identifier (OID) is used to optimize the number of SNMP
GETs required for pulling the various individual OIDs. You can enter this
Parent OID directly, or click the downward arrow to select it from an MIB file. Several
different MIB files are available to select from, s ee Importing OID Definitions
from a MIB File for more information.
Parent ID is Select is table if the OIDs you want to monitor are in a table with at least one
table row. An example would be interface metrics, such as ifInOctets and
ifOutOctets, since there is an interface metric for each interface.
The OIDs you want to monitor mapped to FortiSIEM event attributes. The
List of OIDs selection you make for Parent OID determines the options available in the
OID menu when you select New.
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.
Field Description
group This is the number of MIB file group. MIB files need to be analyzed
as a group because of cross-references within them. The group
attribute specifies an ID for each group and needs to be unique for
every group.
Field Description
The name of the MIB file being analyzed. There can be multiple
mibFile
entries. Be sure to specify the path to the MIB files.
vendor The name of the device vendor for the MIB file
evtPrefix As SNMP trap notification definitions in the MIB file are parsed, an
event file is generated for each SNMP trap. This field specifies the
event type prefix.
Example
In this example, a set of MIB files from an Alcatel 7x50 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.
alcatel.cfg
3. Running mib2xml alcatel.cfg generates both an output and an mib2XML file.
alcatel.out
TIMETRA-TC-MIB.mib.xml
When configuring WMI as the monitoring protocol for a custom performance monitor, use these settings. You
may also want to review the topic Custom WMI Monitor for Windows Domain and Physical Registry as example
of how to set up a custom performance monitor using WMI.
Field Settings
Method WMI
WMI metrics are defined in the form of a parent class having multiple attributes.
Parent Class For example, the parent class Win32_ComputerSystem has the attributes
Domain and TotalPhysicalMemory.
Is Table If the parent WMI class is a table with one or more rows, select this option.
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 FortiSIEM event attribute.
Your options depend on the monitoring protocol you selected for Method.
Monitoring
Field Name Settings/Notes
Protocol
SNMP OID Select an MIB file from the MIB File List, and then select the
OID that you want to create the mapping for.
JMX Object The MBean you select determines the attributes you can select.
Attribute You will also have to enter a Name and Private Key for the
MBean attribute.
Enter the name of the column in the SQL Query that you are
JDBC Column Name
using to monitor the database.
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
l Planning
l Adding New JDBC Performance Objects
l Associating Device Types to Performance Objects
l Testing the Performance Monitor
l Enabling the Performance Monitor
l Writing Queries for the Performance Metrics
Planning
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.
create table HEALTH_DYNAMIC_DEMO
{
ID VARCHAR2 (200) not null,
HOST_NAME NVARCHAR2 (200) not null,
HEALTH NVARCHAR2 (50),
CREATE_TIME DATE not null
}
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
Field Setting
Name jdbc_static_perfObj
Type Application
Method JDBC
Where Clauses Not applicable, since the table doesn't grow over time
Field Setting
Name jdbc_dynamic_perfObj
Type Application
Method JDBC
Field Setting
Where Clauses retrieve all new values since last retrieve time of column create_time
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.
Field Settings
Name windows_oracle_perf_association
l Microsoft Windows
l Microsoft Windows 7
l Microsoft Windows 98
l Microsoft Windows ME
l Microsoft Windows NT
Device Types
l Microsoft Windows Server 2000
l Microsoft Windows Server 2003
l Microsoft Windows Server 2008
l Microsoft Windows Vista
l Microsoft Windows XP
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.
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 .
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.
l Planning
l Adding the D-Link SNMP Performance Object
l Associating Device Types to Performance Objects
l Testing the Performance Monitor
l Enabling the Performance Monitor
l Writing Queries for the Performance Metrics
Planning
To get the interface index, you would run snmpwalk -v 1 -c <community> <ip>
.1.3.6.1.2.1.2.2.1.1:
IF-MIB::ifIndex.1 = INTEGER: 1
IF-MIB::ifIndex.2 = INTEGER: 2
IF-MIB::ifIndex.3 = INTEGER: 3
IF-MIB::ifIndex.4 = INTEGER: 4
IF-MIB::ifIndex.5 = INTEGER: 5
...
To get interface queue length (the outQLen event attribute in FortiSIEM), you would run snmpwalk -v 1 -c
<community> <ip> .1.3.6.1.2.1.2.2.1.21:
IF-MIB::ifOutQLen.1 = Gauge32: 0
IF-MIB::ifOutQLen.2 = Gauge32: 0
IF-MIB::ifOutQLen.3 = Gauge32: 0
IF-MIB::ifOutQLen.4 = Gauge32: 0
IF-MIB::ifOutQLen.5 = Gauge32: 0
...
To get received bytes (the recvBitsPerSec event attribute in FortiSIEM), you would run snmpwalk -v 1 -
c <community> <ip> .1.3.6.1.2.1.2.2.1.10:
IF-MIB::ifInOctets.1 = Counter32: 0
IF-MIB::ifInOctets.2 = Counter32: 1247940872
IF-MIB::ifInOctets.3 = Counter32: 0
IF-MIB::ifInOctets.4 = Counter32: 0
IF-MIB::ifInOctets.5 = Counter32: 0
...
Finall,y to get sent bytes (the sentBitsPerSec event attribute in FortiSIEM ), you would run snmpwalk -v
1 -c <community> <ip> .1.3.6.1.2.1.2.2.1.16:
IF-MIB::ifOutOctets.1 = Counter32: 0
IF-MIB::ifOutOctets.2 = Counter32: 1271371281
IF-MIB::ifOutOctets.3 = Counter32: 0
IF-MIB::ifOutOctets.4 = Counter32: 0
IF-MIB::ifOutOctets.5 = Counter32: 0
...
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 FortiSIEM 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
Device Type
Field Setting
Vendor D-Link
Model DGS
Version Any
Event Types
All custom event types must begin with the prefix P H_DEV_MON_CUST_ .
In this case, you will create one performance object that will map the SNMP OIDs to the FortiSIEM 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. .
Field Setting
Name D-LinkIntStat
Type System
Method SNMP
Field Setting
Parent
.1.3.6.1.2.1.2.2.1
OID
Parent Selected
OID is
Table
sentBitsPe
.1.3.6.1.1.2.1.1 Count Count sentBitsPerS
rSect
.2.1.16 er32 er ect
Event PH_DEV_MON_CUST_INTF_STAT
Type
Polling
Frequen 60 seconds
cy
Type Formula
system toRate
system BytesPerSecToBitsPerSec
In this case you would only need to make one association with the D-Link DGS device you created.
Field Settings
Name D-LinkPerfObj
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.
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.
For
Filter Criteria Display Columns Time
Organizations
Structured
Host Name,Host Interface
Reporting IP IN <IP
SNMP Index,MAX(Out Intf
Range> AND Event Type =" Last 10
Queue), AVG(Intf Speed), All
PH_DEV_MON_CUST_INTF_ Minutes
AVG(Sent Bit Rate), AVG
STAT"; Group by: Host
(Received Bit Rate)
Name, Host Interface
l Planning
l Adding New IBM WebSphere Performance Objects
l Associating Device Types to Performance Objects
l Testing the Performance Monitor
l Enabling the Performance Monitor
l 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.
Display
Value
Name Display Name Format
Type
Type
WebSphere
websphere_heapCommitted INT64 Bytes
HeapCommitted
Display
Value
Name Display Name Format
Type
Type
WebSphere NonHeapMax
websphere_nonHeapMax INT64 Bytes
Event Types
Naming Custom Event Types
All custom event types must begin with the prefix P H_DEV_MON_CUST_ .
PH_DEV_MON_CUST_WEBSPHERE_NON_
IBM WebSphere App Server Low
HEAPMEMORY
Each of the event types requires creating a performance object for monitoring.
Field Setting
Name websphere_heapMemory_perfObj
Type Application
Method JMX
MBean java.lang:type=Memory
Field Setting
List of
Attributes
Object Private Form Event
Name
Attribute Key at Attribute
websphere_
HeapMemoryUs committ committ
Long heapCommitt
age ed ed
ed
websphere_
HeapMemoryUs used used Long
heapUsed
age
websphere_
HeapMemoryUs max max Long
heapMax
age
websphere_
Long
heapPCT
For the webSphere_threadPctEvent Attribute, you will enter a transform as shown in the second table.
Field Setting
Name websphere_thread_perfObj
Type Application
Method JMX
MBean java.lang:type=Threading
Field Setting
List of
Attributes
Object Privat Form Event
Name
Attribute e Key at Attribute
webspher
e_
ThreadCount ThreadCount Long
numThrea
ds
webspher
PeakThreadCo PeakThreadCo e_
Long
unt unt maxThrea
ds
webspher
Long e_
threadPC
T
Field Settings
Name <blank>
Format Long
Type Formula
Transforms
custom ThreadCount*100/PeakThreadcount
Field Setting
Name websphere_nonHeapMemory_perfObj
Type Application
Method JMX
MBean java.lang:type=Memory
List of
Attributes
Private Nam Form
Object Attribute Event Attribute
Key e at
NonHeapMemoryUs websphere_
used Long
age nonHeapUsed
websphere_
NonHeapMemoryUs committ
Long nonHeapCommit
age ed
ted
NonHeapMemoryUs websphere_
max Long
age nonHeapMax
Event
PH_DEV_MON_CUST_WEBSPHERE_NON_HEAPMEMORY
Type
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.
Field Settings
Name windows_oracle_perf_association
l Microsoft Windows
l Microsoft Windows 7
l Microsoft Windows 98
l Microsoft Windows ME
l Microsoft Windows NT
Device Types
l Microsoft Windows Server 2000
l Microsoft Windows Server 2003
l Microsoft Windows Server 2008
l Microsoft Windows Vista
l Microsoft Windows XP
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.
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.
Display For
Filter Criteria Time
Columns Organizations
Although D-link switches and routers are not supported in this release of FortiSIEM, 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
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:
SNMPv2-MIB::sysDescr.0 = STRING: DGS-1210-48 2.00.011
SNMPv2-MIB::sysObjectID.0 = OID: SNMPv2-SMI::enterprises.171.10.76.11
DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (157556100) 18 days, 5:39:21.00
SNMPv2-MIB::sysContact.0 = STRING:
SNMPv2-MIB::sysName.0 = STRING: SJ-Test-Lab-D-Link
SNMPv2-MIB::sysLocation.0 = STRING: San Jose
SNMPv2-MIB::sysServices.0 = INTEGER: 72
SNMPv2-MIB::sysORLastChange.0 = Timeticks: (157555949) 18 days, 5:39:19.49
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 FortiSIEM event attribute type library.
3. Create the mapping between the SNMP OIDs and the event attributes:
l OID .1.3.6.1.2.1.1.5 and hostName.
l OID .1.3.6.1.2.1.1.5 and SysUpTime.
Creating New Device Types, Event Attribute Types, and Event Types
Device Type
Field Setting
Vendor D-Link
Field Setting
Model DGS
Version Any
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.
Device
Name Severity Description
Type
In this case, you will create one performance object that will map the SNMP OIDs to the FortiSIEM event
attribute types hostName and SysUptime, and then associate them with the PH_DEV_MON_CUST_DLINK_
UPTIME event type. When you create the SysUpTime mapping you will also add a transform to convert system
time to centiseconds to seconds as shown in the second table.
Field Setting
Name D-LinkUptime
Type System
Method SNMP
Field Setting
Object Event
Name Format Type
Attribute Attribute
Host RawValu
List of OIDs .1.3.6.1.1.2.1.1 String hostName
Name e
.5
Type Formula
custom uptime/100
In this case you would only need to make one association with the D-Link DGS device you created.
Field Settings
Name D-LinkPerfObj
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.
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.
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.
Display For
Filter Criteria Time
Columns Organizations
Planning
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
AdminPass-
wordStatus::SEP::Auto-
maticManagedPagefile::SEP::AutomaticResetBootOption::SEP::AutomaticResetCapability::SEP::Bo
1::SEP::True::SEP::True::SEP::True::SEP::3::SEP::3::SEP::True::SEP::Normal
boot::SEP::WIN2008-ADS::SEP::3::SEP::Win32_ComputerSystem::SEP::-
420::SEP::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::VMware, Inc.::SEP::VMware Virtual Plat-
form::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_Domain_Con-
troller-
,Timesource,NT,DFS)::SEP::OK::SEP::NULL::SEP::0::SEP::NULL::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:
l WMI class attribute Domain and Domain.
l WMI class attribute TotalPhysicalMemory (Bytes) and memTotalMB (type INT64). Because
TotalPhysicalMemory returns in bytes, and memTotalMB is in INT64, a transform will be required
to convert the metrics.
Device Type
Since Microsoft Windows is supported by FortiSIEM, you don't need to create a new device type.
All custom event types must begin with the prefix P H_DEV_MON_CUST_ .
Device Severity
Name Description
Type
In this case, you will create one performance object that will map the WMI Class attributes to the FortiSIEM event
attribute types Domain and memTotalMB, 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.
Field Setting
Name WinMem
Type System
Method WMI
Event
Attribute Format Type
Attribute
List of Attributes
Domain String RawValue domain
Field Setting
Type Formula
custom TotalPhysicalMemory/1024/1024
In this example, you would need to associate Microsoft Windows device types to the performance object.
Field Settings
Name WinMisc
l Microsoft Windows
l Microsoft Windows NT
l Microsoft Windows Server 2000
Device Types l Microsoft Windows Server 2003
l Microsoft Windows Server 2008
l Microsoft Windows Vista
l Microsoft Windows XP
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.
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.
For
Filter Criteria Display Columns Time
Organizations
Planning
In this example, you want to monitor the output of the iostat command. On a Linux machine, the output would
look similar to this:
This is the event log that you will want to produce in FortiSIEM:
[PH_DEV_MON_CUST_CMD]:[hostIpAddr]=10.1.20.52,[hostName]=centos6-yu.FortiSIEM.net,
[readBytes]=17292116.00,
[readRate]=5.71,[tps]=1.49,[writtenBytes]=147500688.00,[writtenRate]=48.73,
[diskName]="sda2"
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, writtenBytes, 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.
Event Attributes
Event Types
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.
Field Setting
Name cmd-iostat
Type Application
Method Login
Command iostat
(^[^]+)\s+([0-9]+\.?[0-9]+|\d+)\s+([0-9]+\.?[0-9]+|\d+)\s+
Regular
([0-9]+\.?[0-9]+|\d+)\s+([0-9]+\?[0-9]+|\d+)\s+([0-9]+\.?
Expression
[0-9]+|\d+)
Field Setting
Matched Attribute 6
Count
Matched
Format Type Event Attribute
Position
RawValue
List of Attributes 3 DOUBLE readRate
RawValue
5 INTEGER readBytes
RawValue
4 DOUBLE writtenRate
Field Settings
Name cmd-iostat
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.
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.
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.
For
Filter Criteria Display Columns Time Organizations
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:
./winexe -U '<user>%<pwd>' //10.1.2.11 'powershell -NonInteractive -InputFormat
none -OutputFormat text -Command "& {Import-Module ActiveDirectory;Get-ADUser -
LDAPFilter {(useraccountcontrol:1.2.840.113556.1.4.803:=2)}}"'
DistinguishedName : CN=krbtgt,CN=Users,DC=sh-FortiSIEM,DC=com
Enabled : False
GivenName :
Name : krbtgt
ObjectClass : user
ObjectGUID : 13a3703b-185c-4208-98b5-0e65ff638593
SamAccountName : krbtgt
SID : S-1-5-21-2731518400-1375262604-1712717995-502
Surname :
UserPrincipalName :
DistinguishedName : CN=sshd,CN=Users,DC=sh-FortiSIEM,DC=com
Enabled : False
GivenName :
Name : sshd
ObjectClass : user
ObjectGUID : aec0ab40-647a-48ae-ba61-9cf31c08794d
SamAccountName : sshd
SID : S-1-5-21-2731518400-1375262604-1712717995-1225
Surname :
UserPrincipalName :
DistinguishedName : CN=ywang12,DC=sh-FortiSIEM,DC=com
Enabled : False
GivenName :
Name : ywang12
ObjectClass : user
ObjectGUID : df694fd2-cf44-49d1-9ecc-42d8a87102c3
SamAccountName : ywang12
SID : S-1-5-21-2731518400-1375262604-1712717995-1253
Surname :
UserPrincipalName :
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, SamAccountName, 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:
[PH_DEV_MON_CUST_DISABLED_USERS]:[hostIpAddr]=10.1.2.11,[hostName]=WIN2K8-SHRPNT,
[distName]="CN=krbtgt,CN=Users,DC=sh-FortiSIEM,DC=com",[samAccount]="krbtgt",[sid]-
]="S-1-5-21-2731518400-1375262604-1712717995-502"
Event Types
All custom event types must begin with the prefix P H_DEV_MON_CUST_ .
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.
Name WINEXE-AD-Disabled-Users-Output
Type System
Method WINEXE
Regular \nDistinguishedName\s+:\s+(.*?)\n.*?SamAccountName\s+:\s+
Expression (.*?)\nSID\s+(.*?)\n
Matched 3
Attribute
Count
Matched Event
Format Type
Position Attribute
STRING
3 RawValue sid
Polling
60 seconds
Frequency
Field Settings
Name DiscoverDisabledUsers
Field Settings
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.
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.
For
Display
Filter Criteria Time Organizations
Columns
l Planning
l Adding the show interfaces Command Output Performance Object
l Associating Device Types to Performance Objects
l Testing the Performance Monitor
l Enabling the Performance Monitor
l Writing Queries for the Performance Metrics
Planning
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
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, recvPacketsPerSec, 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.
Event Types
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.
Field Setting
Name ssh-multiline-CiscoIOS
Type System
Method Login
Field Setting
Matched Attribute 5
Count
Matche
d
Format Type Event Attribute
Positio
n
RawVal
1 STRING intfName
ue
INTEGE RawVal
2
R ue recvBitsPerSec
List of Attributes
RawVal
3 INTEGE recvPacketsPer
ue
R Sec
INTEGE RawVal
4
R ue sentBitsPerSec
RawVal sentPacketsPer
5 INTEGE
ue Sec
R
Field Settings
Name ssh-Cisco-Intf-Status
Field Settings
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.
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.
For
Display
Filter Criteria Time Organizations
Columns
Supported Servers
l Linux variants
l Unix variants
l 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.
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.
Event Type: PH_DEV_MON_CUST_FILE_CREATE
Thu Mar 27 16:33:27 2014 CO228SP222 FortiSIEM-FimLog
file="/home/admin/DirectoryMon/file4.txt"
hash="d41d8cd98f00b204e9800998ecf8427e" user="root" group="root"
access="rw-r--r--" size="0"
type="create" hostIp="192.168.64.228"
Event Type: PH_DEV_MON_CUST_FILE_CHANGE_ATTRIB.
For permissions changes, look for the preaccess and access attributes.
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.
Thu Mar 27 13:59:26 2014 CO228SP222 FortiSIEM-FimLog file-
e="/home/admin/TargetFileMon/tartget1.txt"
hash="cc3d5ed5fda53dfa81ea6aa951d7e1fe" user="root" group="root" access="rw-r--r--
" size="18"
targetfilehash="cc3d5ed5fda53dfa81ea6aa951d7e1fe" type="scan" hostIp-
p="192.168.64.228"
In Service Provider deployments, the performance object should be created by the Super/Global account, and will
apply to all organizations. For both Service Provider and enterprise deployments, the performance object can be
created for an organization by any user who has access to the Admin tab.
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.
Field Setting
Name LinuxFileMon
Type Application
Method Login
Field Setting
Name LinuxDirMon
Type Application
Method Login
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.
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.
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.
You can now use a simple query to make sure that that the metrics are pulled correctly.
Display For
Filter Criteria Time
Columns Organizations
Display For
Filter Criteria Time
Columns Organizations
Display For
Filter Criteria Time
Columns Organizations
Supported Servers
l Linux variants
l Unix variants
l Windows (with Unix tools installed that allow SSH)
Example Events
Two events that are generated by FortiSIEM when the target file is modified.
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.
[procName]=phPerfMonitor,[fileName]=phSvnUpdate.cpp,[lineNumber]=205,
[phCustId]=1,[hostName]=CO228SP222,
[hostIpAddr]=192.168.64.228,
[fileName]=/home/admin/TargetFileMon/tartget1.txt,[oldSVNVersion]=15,
[newSVNVersion]=20,
[deletedItem]=(none),[addedItem]=newline;,[phLogDetail]=
In Service Provider deployments, the performance object should be created by the Super/Global account, and will
apply to all organizations. For both Service Provider and enterprise deployments, the performance object can be
created for an organization by any user who has access to the Admin tab.
In this case, you will create one performance object in which you will upload the gold target file and enter the path
to the file 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.
Field Setting
Name LinuxTargetFileMon
Type Application
Method Login
Target Click Upload and browse to the location of the file that you want to use as the gold
File target
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.
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.
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.
When the monitor detects a difference between the files, it will trigger the rule Audited target file
content modified, and the rule will continue to trigger and generate incidents until the checksums of the
files match. You can compare the original monitored file against the new version in the CMDB.
This features provides a way for collecting configuration files for any device and monitoring changes.
Validation Check
The expect script will be executed and configuration will be discovered.
1. Go to Admin > Setup > Monitor Change/Performance. Search for the device and check the configuration
monitoring task under System Monitor
2. Go to CMDB. Search for the device and check for the configuration under Configuration tab for the selected
device.
This section describes certain event handling operations that happen at the moment events are received in
FortiSIEM.
l Event Dropping
l Event Forwarding
l Event Organization Mapping
l Multi-line Syslog Handling
Event Dropping
Some devices and applications generate a significant number of logs, which may be very verbose, contain little
valuable information, and consume storage resources. You can configure Event Dropping rules that will drop
events just after they have been received by FortiSIEM, preventing these event logs from being collected and
processed. I mplementing these rules may require some thought to accurately set the event type, reporting
device type, and event regular expression match, for example. However, dropped events do not count towards
licensed Events per Second (EPS), and are not stored in the Event database. Dropped event also do not appear in
reports, and do not trigger rules. You can also specify that events should be dropped but stored, so event
information will be available for searches and reports, but will not trigger rules. And example of an event type that
you might want to store but not have trigger any rules would be an IPS event that is a false positive.
1. Log in to your Supervisor node.
For Service Provider deployments you should log in to the Super/Global account if you want to set a system-wide
event dropping rule. If you want to set an event-dropping rule for a specific organization, either log in as an
administrator for that organization, or or log in using the Super/Global Account and then select the organization to
which the rule should apply when you are creating it.
2. Go to Admin > General Settings > Event Handling.
3. Under Event Dropping Rule, click Add.
4. Next to Reporting Device, click Edit, and use the CMDB Browser to find device group or individual device that
you want to create the rule for.
5. Next to Event Type, click Edit, and use the Event Type Browser to find the group of event types, or a specific
event type, that you want to create the rule for.
6. If the event type you select has an Source IP or Destination IP attribute, you can enter specific IP addresses to
which the rule should apply.
7. For Regex Filter, enter any regular expressions you want to use to filter the log files.
If any matches are made against your regular expression, then the event will be dropped.
8. For Service Provider deployments, select the Organization to which the rule should apply.
9. Select the Action that should be taken when the event dropping rule is triggered.
10. Enter any Description for the rule.
11. Click Save.
Implementation Notes
1. All matching rules are implemented by FortiSIEM, and inter-rule order is not important. If you create a duplicate of
an event dropping rule, the first rule is in effect.
2. If you leave a rule definition field blank, then that field is not evaluated. For example, leaving Event Type left
blank is the same as selecting All Event Types.
3. FortiSIEM drops the event at the first entry point. If your deployment uses Collectors, events are dropped by the
Collectors. If your deployment doesn't use Collectors, then the event will be dropped by the Worker or Supervisor
where the event is received.
4. You can use the report System Event Processing Statistics to view the statistics for dropped events. When you run
the report, select AVG(Policy Dropped Event Rate(/sec) as one of the dimensions for Chart For to see events that
have been dropped to this policy.
Event Forwarding
In systems management, many servers may need access to forward logs, traps and Netflows from network
devices and servers, but it is often resource intensive for network devices and servers to forward logs, traps and
netflows to multiple destinations. For example, most Cisco routers can forward Netflow to two locations at most.
However, FortiSIEM can forward/relay specific logs, traps and Netflows to one or more destinations. If you want
to send a log to multiple destinations, you can send it to FortiSIEM, which will use an event forwarding rule to
send it to the desired locations.
1. Log in to your Supervisor node.
2. Go to Admin > General Settings > Event Handling.
3. Under Event Forwarding Rule, for Service Provider deployments, select the organization for which the rule will
apply.
4. Click Add.
5. For Sender IP, enter the IP address of the device that will be sending the logs.
6. For Severity, select an operator and enter a severity level that must match for the log to be forwarded.
7. Select the Traffic Type to which the rule should apply.
The Forward To > Port field will be populated based on your selection here.
8. For Forward to > IP, enter the IP address to which the event should be forwarded.
9. Click OK .
1. Go to Admin > General Settings > Event Handling > Event Organization Handling
2. Click Add to add a rule
3. Select Enabled if this rule is to be enforced
4. Select the Device Type of the sender. This has to be a device that FortiSIEM understands and able to parse
events.
5. Select the Event Attribute that contains the external organization name. FortiSIEM will map the value in this
field to FortiSIEM organization.
6. Select the Collectors that are going to receive the events. By default any collectors would be able to do this but it
is possible to scope down if needed. This field is optional.
7. Specify the Reporting IP/Range of the Service Provider devices that are sending events. Format of this field is a
comma separated list of IP addresses intermixed with IP ranges, e.g. 10.1.1.1,10.1.1.2,10.10.1.1-10.10.1.250.
8. Specify the Org Mapping.
a. Click Edit
b. Select the System (FortiSIEM) organization on the left column
c. Click the Event Organization and enter the external Organization name corresponding to the System
Organization on the left column
9. Click OK to Save.
Implementation Notes
Do not define overlapping rules - make sure no overlaps in (Collector, Reporting IP/Range,Event Attribute)
between multiple rules.
User can write multiple multi-line syslog combining rules based on reporting IP and begin and ending patterns. All
matching syslog within the begin and ending pattern are combined into a single log.
l If a packet matches the Begin Pattern, FortiSIEM will hold it in memory and wait for the next packet.
l If the 2nd packet also matches the Begin Pattern, continue waiting.
l If the 3rd packet doesn't match the Begin Pattern, flush out the 2 events (1+2 and 3).
l If any packet matches the End Pattern, flush out.
l The Begin Pattern is in each packet of a multiline syslog. Remove them except the 1st packet.
For example, the receiver gets these packets:
If you set the Begin Pattern to a regular expression to match the <syslog header> and leave the End Pattern to
be empty, then the three syslogs are combined into a single syslog
If you set the Begin Pattern to a regular expression to match the <syslog header> and leave the End Pattern to
match work, then the first two syslogs are combined into a single syslog, while the third one is left alone.
l If the Begin Pattern is matched in the TCP stream, a multi-line syslog combination begins
l If the End Pattern is matched in the TCP stream, multi-line syslog combination ends
l If the Begin Pattern is again matched in the TCP stream, the previous multi-line syslog combination ends
TCP syslog stream: id=0,name=<1>name=a,id=1<2>name=b,id=2<3>
Begin pattern is <\d+> and end pattern is id=\d+. This results in 3 syslogs
id=0,name=
<1>name=a,id=1
<2>name=b,id=2
If the Begin pattern is <\d+> and end pattern is empty, this also results in 3 syslogs as before.
Managing FortiSIEM
Topics in this section contain information on monitoring the health of your FortiSIEM deployment, general system
settings such as language, date format, and system logos, and how to add devices to a maintenance calendar.
Collects IP identity
phIdentityWorker X X
information
Administrator Tools
This topic describes administration tools and scripts that are included with your FortiSIEM deployment, along with
information on where to find and how to use them.
phTools phTools is a simple tool for starting and Log in to the FortiSIEM host machine as
stopping backend processes, and for root.
getting change log information. When Usage
you upgrade your deployment, for
[root@FortiSIEM]#
example, you would use phTools to stop
phtools
all backend processes.
Commands: --change-
log, --start, --stop, --
stats
Target: ALL
1. In the upper-right corner of the FortiSIEM web interface, click the User Activity icon.
8. Add Folders or Items to the maintenance event by selecting them, and then using the Folder >> and Item >>
buttons to move them into the selection pane.
9. Click OK when you're done selecting Folders and Items.
10. Select Generate incidents for devices under active maintenance if you want incidents for devices that are
part of this maintenance event to be triggered.
11. Click OK.
12. You will now see your maintenance event listed on the calendar. Mouse over any calendar entry to view details of
the maintenance event.
If you have FortiSIEM Service Provider deployment and you log in as a Super/Global user, you can schedule
maintenance events for single organizations, the Super/Global organization, or add devices from multiple
organizations to the same maintenance event.
1. Log in to your Supervisor node.
2. Go to Admin > Maintenance Calendar.
3. Click Add.
4. Enter a Name and Description for the maintenance event.
5. Set the Time Range and Date Range for the maintenance event.
Recurring Maintenance Events: Select From start date on to set up recurring maintenance events.
6. Under Groups and Devices, click Edit.
7. If you have FortiSIEM Service Provider deployment, select the Organization that has the devices you want to add
to the maintenance calendar.
Multiple Organizations, One Maintenance Event: If you are the Super/Global user, it is possible to
add devices from different organizations to the same maintenance event.
8. Click Synthetic Transaction Monitor (STM) to see all the STM jobs under Items in the windows below.
9. Select the Items from the bottom left and then click Item >> to move them into the selection pane.
10. Click OK to Save the configuration.
11. Select Generate incidents for devices under active maintenance if you want incidents for devices that are
part of this maintenance event to be triggered.
12. Click OK.
13. You will now see your maintenance event listed on the calendar. Mouse over any calendar entry to view details of
the maintenance event.
The FortiSIEM solution to this situation is to build a reverse SSH tunnel between the Collector and the
Supervisor. The firewall already allows HTTP(S) sessions from Collector to Supervisor. After also being
configured to also allow SSH connections from Collector to Supervisor, FortiSIEM builds an on-demand reverse
SSH Tunnel initiated by the Collector. You can then use the tunnel to open a remote management session from
your browser to the remote managed endpoint. This blog post on The Geek Stuff describes the process for
setting up reverse SSH tunnels on Linux, and provides some additional technical details.
If the managed endpoint is directly accessible from your browser, FortiSIEM can open a direct session. The
devices have to be discovered first, and based on this information, FortiSIEM can determine whether to launch a
direct or Collector-based session.
l You can define the port of the reverse SSH tunnel. By default it is set to 19999, but it can be changed to any port.
l FortiSIEM automatically times out each tunnel after a day, although you can manually delete a tunnel at any time
l FortiSIEM provides full tunnel management auditing, such as a reporting on who creates and deletes a tunnel
l FortiSIEM supports a broad group of connectivity protocols protocols. You can can launch any connectivity
application by specifying the port, and FortiSIEM will create the tunnel.
l RBAC is supported at the Collector level - if the user can visit the Collector health page, then the user can open a
remote collector tunnel.
l FortiSIEM launches the FireSSH browser plugin and passes the managed endpoint IP
l You type in your user name and password, and if the authentication succeeds, then the shell appears
This table lists the browsers, and the protocols supported by their plugins, that you can use to connect to the
managed endpoint.
Note: Always type the end host/device credentials for direct connections over a reverse tunnel even though the
displayed IP/port belongs to the Supervisor.
Supported
Web Connectivity
Browser Integration
Browser Protocol
Plugin
Firefox SSH FireSSH The plugin launches. You need to provide your user name
and password for the end host/device
HTTP(S) None Another tab opens. You will need to provide your user
required name and password if the endpoint device requires it.
Supported
Web Connectivity
Browser Integration
Browser Protocol
Plugin
Chrome SSH FireSSH The plugin launches. You need to provide your user name
and password for the end host/device.
RDP Chrome A dialog opens for the Chrome RDP plugin. Make sure
RDP your popup blocker is disabled, or that you allow popups
from this site. Click Launch App to launch the plugin in a
new tab. A dialog shows the Supervisor's port/tunnel
endpoint to connect to. Enter <Supervisor-IP>:<Supervisor
Port> to connect. Alternatively, you can use your favorite
RDP client.
None Another tab opens. You will need to provide your user
HTTP(S)
required name and password if the endpoint device requires it.
Supported
Web Connectivity
Browser Integration
Browser Protocol
Plugin
Safari SSH Mac A new terminal window launches and connects via SSH to
(on OSX Terminal <Supervisor-IP> and <Supervisor-port>. Enter your user
only) name and password for the end host/device.
RDP None A dialog opens for the Chrome RDP plugin. Make sure
your popup blocker is disabled, or that you allow popups
from this site. Click Launch App to launch the plugin in a
new tab. A dialog shows the Supervisor's port/tunnel
endpoint to connect to. Enter <Supervisor-IP>:<Supervisor
Port> to connect. Alternatively, you can use your favorite
RDP client.
None Another tab opens. You will need to provide your user
HTTP(S)
required name and password if the endpoint device requires it.
Internet SSH, Telnet, No plugin Create the tunnel and then connect to the <Supervisor-
Explorer RDP, HTTP integration Port> that is displayed using an external application.
(S), VNC,
Other
Firewall Configuration
If there is a firewall between the Collector and the Supervisor, the firewall needs to allow SSH from the Collector
to the Supervisor. The default setting uses a non-standard port, 19999, so make sure you configure the firewall
between the Collector and the Supervisor to allow outbound TCP connections on port 19999.
Using Role-Based Access Control to Limit Access to Tunnel Creation, Viewing, and Closing
For security and management reasons, you may want to limit the ability of users to create tunnels. The easiest
way to do this is through user roles that have defined access capabilities. For example
l To prevent the creation of any tunnels for a role, disallow access to the CMDB tab for that role, or disallow access
to the particular device or device group. This second option lets you create fine-grained controls for tunnel creation,
for example:
l Admins who are able to view Network devices can only open tunnels to Network devices
l Admins who are able to view Servers can only open tunnels to Servers
l Admins who are able to view a custom-created device group can only open tunnel to that specific
custom group
l To prevent viewing and closing existing tunnels, disallow access to the Admin > Collector Health page.
Related Links
Prerequisites
l You should review the browsers and plugins that are supported for the connectivity protocol you want to use to
connect to the device.
Procedure
PID The process ID of the tunnel. If you kill this process, it will kill the tunnel
4. You can close a tunnel by selecting it and then clicking Close, or you can close all tunnels at the same time by
clicking Close All.
For Service Provider installs, UI Logos can also be set on a per organization basis.
1. SSH to Supervisor via root
2. Change user to admin 'su admin'
3. Change directory by running 'cd /opt/glassfish3/glassfish/domains/domain1/applications/phoenix/phoenix-web-
1.0_war/resources/header'
4. Create a logo per organization
a. mkdir org
b. cd org
c. Create Organizations IDs as directories. Eg: ‘mkdir 2001’ (To find Org ids, Goto Admin > Setup Wizard >
Organizations > ID)
5. Copy PNG files to respected Organizations as logo.png. For example:
/opt/glassfish3/glassfish/domains/domain1/applications/phoenix/phoenix-web-1.0_
war/resources/header/org/2001/logo.png
6. Logon to Organization e.g: Org1 (id: 2001) and make sure that UI logo is updated
You can view system errors from any page in the FortiSIEM user interface by clicking on the System Errors link
directly under the URI address window in your browser.
Health Displays the health of the Collector based on the health of the modules
running on it. If Health is Critical, it means that one of the modules is
not running on the Collector.
Last Performance The time when the collector last reported its performance status to the
Data cloud
Last Status Update The time when the collector last reported its status to the cloud
Last Event Data T he time when the collector last reported events to the cloud
Build Date The date on which the version of FortiSIEM the Collector is running on
was built
Upgrade Version If the Collector has been upgraded, the version it was upgraded to
Install Status If you upgrade the Collector, the status of the upgrade is shown here as
either Success or Failed
Allocated EPS The number of events per second (EPS) dynamically allocated by the
system to this collector. See Dynamic Distribution of Events per Second
(EPS) across Collectors for more information about how EPS is allocated
across Collectors.
EPS FortiSIEM calculates the EPS for your system using a counter
that records the total number of received events in a three minute
time interval. Every second, a thread wakes up and checks the
counter value. If the counter is less than 110% of the license limit
(using the calculation 1.1 x EPS License x 180) , then FortiSIEM
will continue to collect events. If you exceed 110% of your
licensed EPS, events are dropped for the remainder of the three
minute window, and an email notification is triggered. At the end
of the three minute window the counter resets and resumes
receiving events.
l Workstations
Number of
l Mobile Devices
Devices
l VoIP Phones
These devices are not counted against the number of
devices that are licensed for your deployment.
Event Categories
Counted in
System Event phstatus -a
Description EPS Stored in DB?
Category outout
License
Running "phstatus -a" command at various nodes provides the events handled by that node.The output shows the
statistics at 3min, 15min and 30 min averages.
EPS: 3 Min: 26.19 15 Min: 30.36 30 Min: 28.85
l If you run "phstatus -a" at a Collector, the output shows the events handled by that collector
l If you run "phstatus -a" at a Worker, the output shows the events handled by that Worker - includes events sent by
devices directly to that Worker or events sent by Collectors
l If you run "phstatus -a" at a Supervisor, you get the aggregated view across all nodes
l My Dashboard
l Availability/Performance > Avail/Perf Widgets
l Biz Svc Dashboard
l Dashboards By Function
To do this:
1. Log in to your Supervisor node.
2. Go to Admin > General Settings > UI.
3. Select the Dashboard Theme you want to use, and then click Change.
4. Refresh the browser.
Global Setting
Currently the dark theme setting is a global setting - so all users would have the same theme.
First check whether the CVEs you are interested in have already been patched by the current FortiSIEM version.
You can do this by running the following command.
rpm --changelog -q httpd
We use a headless chrome browser for STM but chrome is not supported by Google on CentOS6 or 7 platforms.
To upgrade that package to the latest version, we use a third party system.
l Discovered information about your IT infrastructure such as devices, networks, applications, and users
l Information derived from your discovered infrastructure, including network topology and inter-device relationships
such as the relationship of WLAN Access Points to Controller, and Virtual Machines to ESX Hosts.
l Information about system objects such as rules, reports, business services, event types, networks, and
ports/protocols
You can find and manage all this information under the CMDB tab.
When FortiSIEM discovers a device, it looks for keywords in the SNMP sysDescr attribute and also probes for
the SNMP sysObjectID attribute. Internal tables are then used to map a discovered device to one or more
CMDB device groups based on these attributes.
l Keywords from the sysDescr attribute are matched against the system table Device Vendor and Model
l Keywords from the sysObjectID attribute are matched against the system table Device Vendor and
Model
l Matches from the Device Vendor and Model table are then matched against the ApprovedDeviceVendor.csv
table that is used to create the categories in the CMDB Devices/Applications.
FortiSIEM discovers applications by discovering the processes that are running on a server. The
table AppMapping.csv maps process names to Applications, Application Groups, and application folders in
the CMDB.
From Logs
FortiSIEM includes a large number of log parsers, each of of which is associated with a Device Vendor/Model and
Application Vendor/Model. When the log is parsed by FortiSIEM, the Device/Application/Vendor information is
matched against the table ApprovedDeviceVendor.csv, which then assigns the application or device to the
appropriate CMDB Device/Application folder.
Special Cases
There are some special cases that cannot be categorized using discovery or log information. An example
is Microsoft Active Directory. It is an application, but there is no explicit process for i.t as it is part of the kernel or
big system service. In this case, specific logs are used: Windows Security logs 672, 673 to detect Microsoft
Domain Controller 2000, 2003, and Windows Security logs 4768, 4769 to detect Microsoft Windows Domain
Controller 2008, 2012.
Examples
This is an example of categorizing a device using discovery. In this case, the Cisco IOS substring in the SNMP
sysDescr attribute is used to detect a Cisco IOS device,
Then this entry in ApprovedDeviceVendor.csv maps the Device Vendor/Model Cisco IOS to the
Router/Switch category in the CMDB. PH_SYS_DEVICE_ROUTER_SWITCH is the internal ID of the category.
#id,Vendor,ModelOS,Version,Type,CMDB Folder Id,,Biz Service,Access Pro-
tocol,Parsed,Priority
301,Cisco,IOS,ANY,Appliance,PH_SYS_DEVICE_ROUTER_SWITCH,,,"TELNET,SSH",1,10
This is also an example of categorizing a device by discovery. In this case, the SNMPv2-
SMI::enterprises.12356 substring in the SNMP sysObjectId attribute is used to detect a Fortinet
Firewall device.
[desktop]$ snmpwalk -v 2c -c public 172.16.255.82 sysObjectID
SNMPv2-MIB::sysObjectID.0 = OID: SNMPv2-SMI::enterprises.12356.101.1.502
Then this entry in the ApprovedDeviceVendor.csv table maps the Device Vendor/Model Fortinet
FortiOS to the Firewall and Network IOS categories in the CMDB, since Fortinet is a UTM device. PH_SYS_
DEVICE_FIREWALL and PH_SYS_DEVICE_NETWORK_IPS are the internal IDs of the categories .
#id,Vendor,ModelOS,Version,Type,CMDB Folder Id,,Biz Service,Access Pro-
tocol,Parsed,Priority
21,Fortinet,FortiOS,ANY,Appliance,"PH_SYS_DEVICE_FIREWALL,PH_SYS_DEVICE_NETWORK_
IPS,PH_SYS_DEVICE_SEC_GW",,PH_SYS_BizSrvc_FW,"TELNET,SSH",1,10
This is an example of categorizing an application based on a running process. In this case, SNMP discovers a
process svchost.exe with the path -k iissvcs.
[desktop]$ snmpwalk -v 2c -c public 192.168.0.10 | grep 1148
HOST-RESOURCES-MIB::hrSWRunIndex.1148 = INTEGER: 1148
HOST-RESOURCES-MIB::hrSWRunName.1148 = STRING: "svchost.exe"HOST-RESOURCES-
MIB::hrSWRunParameters.1148 = STRING: "-k iissvcs"
This entry in the AppMapping.csv table is then used to map the process name svchost.exe with the path
name -k iissvcs to a Microsoft IIS application.
#Application group name,package signature,process name,process parameter,process
Description,Priority,Ports,Group
Microsoft IIS,,svchost.exe,"-k iissvcs",Microsoft IIS,10,"http,https",PH_SYS_APP_
WEB_SERVER,
This is an example of categorizing a device based on logs. The Cisco ASA parser has has a Device Vendor/Model
associated with it, and when a log from the Cisco ASA device is parsed by FortiSIEM, this entry in
ApprovedDeviceVendor.csv maps the Device Vendor/Model Cisco ASA to the Firewall and VPN
This is an example of categorizing an application based on logs. The Microsoft IIS (via Snare) parser has a Device
Vendor/Model associated with it, and when a log from Microsoft IIS is processed by FortiSIEM, this entry in
ApprovedDeviceVendor.csv maps the Device Vendor/Model Microsoft to the Windows Server and
Web Server categories in the CMDB. PH_SYS_DEVICE_WINDOWS_SERVER and PH_SYS_APP_WEB_
SERVER are the internal IDs of these categories.
the following entry in
#id,Vendor,ModelOS,Version,Type,CMDB Folder Id,,Biz Service,Access Pro-
tocol,Parsed,Priority
901,Microsoft,IIS,ANY,Application,"PH_SYS_DEVICE_WINDOWS_SERVER,PH_SYS_APP_WEB_
SERVER",Microsoft IIS,,None,1,10
l Tab Overview
l Inventory Management and Edit Details Controls
l User Interface Controls for Device View
l Data Collection Status
Tab Overview
This screenshot shows the Device view of the CMDB tab with Devices selected in the Device View of the IT
infrastructure hierarchy. For any type of object you select in the hierarchy, the CMDB will load a Summary view
of the objects in the top pane, and Details for any individual object you select from the summary in the bottom
pane. While the available details will change depending on the type of object you select, all objects in the CMDB
view will have Inventory Management controls in the summary pane, and an Edit Details control in the Details
pane.
UI Control Description
Edit Edit details about the selected object. You can also use the Edit Details
button in the Details pane for the same purpose. You can also set device-
specific properties to use in defining per-device thresholds.
Views l Inventory
A summary of all devices of that type in the CMDB
l Topo
Shows all devices of the selected type in a topology view
l Performance
Shows a Performance Summary dashboard for all devices of that type
Hover your mouse cursor over the IP address associated with a device to open the IP
Management menu
l Quick Info
Loads the Quick Info for the device, which you can also see by selecting Quick
Info in the Analysis menu
l Topology
Shows the device's location in the network topology, which you can also see by
IP clicking the Topology button in the device Details pane
Management
l Show Real-Time events on this IP
Loads a Real Time Search with the selected IP address in the search criteria
l Show Events on this IP for the Past 5 Minutes
Loads and Historial search with the selected IP address in the search criteria and
the Time filter set to Last 5 Mins
l Add to WatchList
Add that IP address to a WatchList
UI Control Description
More l Location
Displays any location information associated with the device
l ChangeOrg
For multi-tenant deployments, change the organization associated with the device
l Impacted Org
Shows organizations that device is associated with
l Maintenance
Displays the maintenance schedule for the device
l Export General Info
Exports a summary view of selected devices, or a detailed view of information for a
specific device, in PDF or CSV format
Analysis The Analysis menu contains a number of options for component analytics, depending on
the component selected. See Using the Analysis Menu for more information. You can also
access the Analysis menu for a component by hovering your mouse over the component's
Device IP menu until the blue Quick Info icon appears, and then clicking the icon.
UI Control Description
The Quick Info view of a device, which you can also access through the Analysis menu or
hovering your mouse cursor over the Device IP column, displays General and Health
information for the device, and when appropriate, Identity and Location information. It
also contains links to additional information about the device:
l Incidents
An exportable summary of incidents associated with the device
l Health
Availability, Performance, and Security health information for the device. You
can also access this information by clicking the Device Health user interface
control, or by selecting Device Health in the Analysis menu.
l BizService
Any business services impacted by the device. You can also access this information
by selecting Impacted Business Services in the Analysis menu.
l Applications
Displays a report on the top 10 applications associated with the device by Average
Quick Info CPU Utilization over the past hour
l Vulnerability and IP Status (Not used in the Dashboard view)
Displays the vulnerability status reports that are also available by selecting
Vulnerability and IPS Status in the Analysis menu
l Hardware Health (Used only for the CMDB/Storage view)
Displays health information for the hardware being used for storage
l Interfaces
Displays a report on the top 10 interfaces associated with the device by average
throughput
l Topology
Shows the device's location in the network topology. You can also access this
information by selecting Topology in the Analysis menu.
The Quick Info view also contains two links, Goto Config Item, which links to
the device entry in the CMDB, and Goto Identity, which links to Analytics >
Identity and Location Report, where you can edit this information for the
device.
UI Control Description
Device Info Each tab contains information about a specific aspect of the device, as well as an
Edit button to change information:
l Summary
General organizational and operational information about the device
l Health
Availability , Performance , and Security health reports for the device. You can
also access this information by selecting a device in the Summary dashboard, and
then click Health, or by going to Quick Info > Health after selecting the device . If
any Incidents are displayed, click the number to view the Incident Summary .
Depending on the reported metric, you can zoom in for a closer look at graphs and
reports by clicking the Magnifying Glass icon that appears when you hover your
mouse cursor over them.
l Monitor
Shows Event Receive Status and Performance Monitor Status - when data was last
collected and status
l Contact
Contact information for the device
l Interfaces
Interfaces connected to the device
l Software
Software running on the device. Categories include Installed Software, Running
Applications, Windows Services, and Installed Patches. In the Installed
Software category you can use the Diff... button to compare different versions of
software you've installed.
l Hardware
Information about the hardware associated with the device.Categories include
Processors, Storage, SAN Storage, System BIOS, Components, SAN
Ports, RAID Groups, LUNs, and Storage Groups.
l Configuration
Configuration files associated with the device. You can compare configuration files
by selecting two or more, and then clicking Diff...
l Relationships
Other devices that this device interacts with
Edit Details Click to edit the Summary, Contact Info, Interfaces, and Properties for the device
Performance Monitor Normal Performance Monitoring Time Gap LESS THAN Performance
Job Status Monitoring Time Gap Warning Threshold
Event Receive Job Event Receive Time Gap LESS THAN Event Receive Time Gap
Normal
Status Warning Threshold
Event Receive Job Warning Event Receive Time Gap GREATER THAN Event Receive
Status Time Gap Warning Threshold BUT LESS THAN Event Receive
Time Gap Critical Threshold
The following table shows how the various job types are classified into Performance Monitor or Event
Received types
Jobs defined in Admin > Setup wizard > Monitor Performance Monitor
Change/performance
Jobs defined in Admin > Setup wizard > Pull Events (e.g. Event Receive
The following rules trigger when certain data collection exceptions happen.
FortiSIEM Log Relay Triggers when Event Receive Job Status Clears when Event
Not Working - All is Critical for all devices to a specific Receive Job Status is
Devices delayed Worker/collector (that is acting as a Log Normal for all devices from
Relay) that Worker/Collector
When FortiSIEM discovers traffic destined to or originating from anonymity networks, it triggers these rules:
l Open Proxies: A set of open proxies in the internet. This is a static group.
l Tor Nodes : This group is dynamically updated from https://check.torproject.org/exit-addresses . You can
schedule regular updates for this group by clicking on the group name, then click Update and provide
update scheduling information.
4. Click Anonymity Network.
5. Select the group where you want to add the anonymity network.
6. Click New.
7. Enter IP, Port, and Country information about the anonymity network.
8. Click the Calendar icon to enter the date you created or updated this entry.
9. Click Save.
Instead of manually adding anonymity networks to a group individually, you can upload a CSV file with multiple
entries to the group by selecting the group and then clicking Upload. You will need to format the file with these
fields:
For example:
99.99.99.99,,USA,10:00:00 10/02/2014
You can easily add an anonymity network IP address to your watch lists. Hover you mouse cursor over the
anonymity network IP address until the icon for the Options menu appears, and then select Add to Watchlist.
This topic describes how to import anonymity networks information into FortiSIEM from external threat feed
websites. Anonymity networks are used by malware to hide their own identity. Two prominent examples of
anonymity networks are Open Proxies and TOR Nodes.
l Prerequisites
l Procedure
Prerequisites
Before proceeding gather the following information about a threat feed web site.
Procedure
1. In the CMDB > Anonymity Network, find the website you need to import data from.
2. Select the folder.
3. Click Update.
4. Select Update via API. The link should show in the edit box.
5. Enter a schedule by clicking on the "+" icon.
6. Enter the schedule parameters - when to start and how often to import. FortiSIEM recommends no more frequent
than hourly.
7. Select the type of template you want to create.
l file in comma separated value format (separator can be any special character such as space, tab, hash, dollar etc.)
l one entry is in one line
Note: Although many fields are possible, only the IP is required.
Applications
Applications in the CMDB are grouped at the highest level by Infrastructure and User apps, with further sub-
categorization in each of those two categories.
Adding an Application
Malware Domains
The CMDB Malware Domains page lists domains that are known to generate spam, host botnets, create DDoS
attacks, and generally contain malware. The three default groups included in your FortiSIEM
deployment, MalwareDomainList, Zeus Domains, and SANS Domains, contain malware domains that are
derived from the websites malwaredomainlist.com, zeustracker.abuse.ch, and isc.sans.edu. Because malware
domains are constantly shifting, FortiSIEM recommends maintaining a dynamically generated list of IP
addresses provided by services such as these that is updated on a regular schedule, but you can also add or
remove blocked IP addresses from these system-defined groups, and create your own groups based on manual
entry of IP addresses or file upload.
System defined groups are MalwareDomainList, Zeus Domains, and SANS Domains, which are updated by
their corresponding services. You can set these to update automatically on a schedule, or add or remove
individual IP addresses from them.
Setting Schedule
Adding/Removing entries
1. If you want to remove a domain or set of domains from the group, clear the Enable selection next to the domain
name, and then click Continue to confirm.
The domain will still be listed in the group, but it will no longer be blocked. Select Enable to resume blocking it.
2. If you want to add a blocked domain to the group, make sure the group is selected, click New, and enter
information about the blocked IP address.
Changing to STIX/TAXII
If the system defined threat feeds are available via STIX/TAXII, then check the STIX/TAXII box.
1. Create a group under Blocked Domains as described in Creating CMDB Groups and Adding Objects to Them.
2. Select the group you created and click New.
3. Enter information for the Blocked Domain you want to add, and then click Save.
This topic describes how to import malware domain information into FortiSIEM from external threat feed
websites.
l Pre-requisites
l Threat feed Websites with built in support
l Custom threat feed websites - CSV data - one-time manual import
l Custom threat feed websites - CSV data - programmatic import
l Custom threat feed websites - non-CSV data - programmatic import
l Custom threat feed websites - STIX formatted data and TAXII import
Pre-requisites
Before proceeding gather the following information about a threat feed web site.
1. In the CMDB > Malware Domains, find the website you need to import data from.
2. Select the folder.
3. Click Update.
4. Select Update via API. The link should show in the edit box.
5. Enter a schedule by clicking on the "+" icon.
6. Enter the schedule parameters - when to start and how often to import. FortiSIEM recommends no more frequent
than hourly.
7. Select the type of template you want to create.
This requires that the data to be imported is already in a file in comma separated value format. The required
format is
Domain Name, IP, Reverse Lookup, Malware Type, Confidence, Severity, ASN, Org,
Country,Description, Date Found(MM/DD/YYYY),Last Seen(MM/DD/YYYY)
Although many fields are possible, only the Domain Name is required
l file in comma separated value format (separator can be any special character such as space, tab, hash, dollar etc.)
l one entry is in one line
Although many fields are possible, only the Domain Name is required.
8. Select a import schedule by clicking + on the Schedule Summary. Select when to start the import and how often
to import to get new data from the website.
9. The imported data will show on the right pane after some time.
This is the most general case where the website data format does not satisfy the previous conditions. In this
case, user has to write a Java plugin class by modifying the default system provided one. Follow instructions in
the FortiSIEM ServiceAPI available at FortiSIEM support portal under FortiSIEM ServiceAPI section. After the
class has been written and fully tested for correctness, follow these steps.
Custom threat feed websites - STIX formatted data and TAXII import
In this case, the threat feed data is available formatted as STIX and follows the TAXII protocol.
Blocked IP Addresses
The CMDB Blocked IP Addresses page lists IP addresses that are known to generate spam, host botnets,
create DDoS attacks, and generally contain malware. The two default groups included in your FortiSIEM
deployment, Emerging Threats and Zeus, contain IP addresses that are derived from the websites
rules.emergingthreats.net and zeustracker.abuse.ch. Because malware IP addresses are constantly shifting,
FortiSIEM recommends maintaining a dynamically generated list of IP addresses provided by services such as
these that is updated on a regular schedule, but you can also add or remove blocked IP addresses from these
system-defined groups, and create your own groups based on manual entry of IP addresses or file upload.
System defined groups are Emerging Threats and Zeus, which are updated by their corresponding services.
You can set these to update automatically on a schedule, or add or remove individual IP addresses from them.
1. Log in to your Supervisor node.
2. Click CMDB.
3. Select a system-defined group.
4. Click Update.
5. Select Update Automatically to open the update scheduler and verify the URI of the update service.
6. Set the schedule for how often you want the list to update from the service.
7. Click Save.
8. If you want to remove an IP address or set of IP addresses from the group, clear the Enable selection next to the
IP address, and then click Continue to confirm.
The IP address will still be listed in the group, but it will no longer be blocked. Select Enable to resume blocking it.
9. If you want to add a blocked IP address to the group, make sure the group is selected, click New, and enter
information about the blocked IP address.
1. Create a group under Blocked IPs as described in Creating CMDB Groups and Adding Objects to Them.
2. Select the group you created and click New.
3. Enter information for the Blocked IP address you want to add, and then click Save.
This topic describes how to import Malware IP information into FortiSIEM from external threat feed websites.
l Prerequisites
l Websites with built in support
l Custom threat feed websites - CSV data - one-time manual import
l Custom threat feed websites - CSV data - programmatic import
l Custom threat feed websites - non-CSV data - programmatic import
l Custom threat feed websites - STIX formatted data and TAXII import
Prerequisites
Before proceeding gather the following information about a threat feed web site.
l Bot IP
l Actor IP
l APT Email
l APT IP
l Bruteforce IP
l Compromised IP
l Malware IP
l DDoS IP
l Phishing email IP
l Phish URL IP
l Scan IP
l Spam IP
To import data from these websites, follow these steps
1. In the CMDB > Malware IPs, find the website you need to import data from.
2. Select the folder.
3. Click Update.
4. Select Update via API. The link should show in the edit box.
5. Enter a schedule by clicking on the "+" icon.
6. Enter the schedule parameters - when to start and how often to import. FortiSIEM recommends no more frequent
than hourly.
7. Select the type of template you want to create.
This requires that the data to be imported is already in a file in comma separated value format. The required
format is
Name, Low IP, High IP, Malware Type, Confidence, Severity, ASN, Org, Country ,De-
scription,Data Found(MM/DD/YYYY),Last Seen(MM/DD/YYYY)
Although many fields are possible, only Low IP is required. If High IP is not provided, then it is set to Low IP.
l file in comma separated value format (separator can be any special character such as space, tab, hash, dollar etc.)
l one entry is in one line
Although many fields are possible, only Low IP is required. If High IP is not provided, then it is set to Low IP.
This is the most general case where the website data format does not satisfy the previous conditions. In this
case, user has to write a Java plugin class by modifying the default system provided one. Follow instructions in
the FortiSIEM ServiceAPI available at FortiSIEM support portal under FortiSIEM ServiceAPI section.
After the class has been written and fully tested for correctness, follow these steps.
Custom threat feed websites - STIX formatted data and TAXII import
In this case, the threat feed data is available formatted as STIX and follows the TAXII protocol.
Blocked URLs
The CMDB Blocked URLs page lists URLs that are known to host malware.
The Threat Stream Blocked URL group is included in your FortiSIEM deployment.
System defined groups are Threat Stream Blocked URL, which are updated by its own service. You can set
these to update automatically on a schedule.
1. Log in to your Supervisor node.
2. Click CMDB.
3. Select Threat Stream Blocked URL.
4. Click Update.
5. Set Schedule
1. Select Update Automatically to open the update scheduler and verify the URI of the update service.
2. Set the schedule for how often you want the list to update from the service.
3. Click OK.
4. Click Save
6. Set user name and password
1. Select the link (https://api.threatstream.com/api/v1/intelligence/)
2. Click Edit
3. Enter User Name and Password
4. Set Data Format to Custom and Incremental
5. Click Save
This topic describes how to import Malware URL information into FortiSIEM from external threat feed websites.
l Prerequisites
l Threat feed websites with built in support
l Custom threat feed websites - CSV data - one-time manual import
l Custom threat feed websites - CSV data - GUI import
l Custom threat feed websites - non-CSV data - programmatic import
l Custom threat feed websites - STIX formatted data and TAXII import
Prerequisites
Before proceeding gather the following information about a threat feed web site.
1. In the CMDB > Malware URLs, find the website you need to import data from.
2. Select the folder.
3. Click Update.
4. Select Update via API. The link should show in the edit box.
5. Enter a schedule by clicking on the "+" icon.
6. Enter the schedule parameters - when to start and how often to import. FortiSIEM recommends no more frequent
than hourly.
This requires that the data to be imported is already in a file in comma separated value format. The required
format is
URL, Malware Type, Confidence, Description,Last Seen(MM/DD/YYYY)
This requires that the web site data has the following structure.
l The file in comma separated value format (separator can be any special character such as space, tab, hash, dollar
etc.)
l One line has only one entry
Follow these steps.
This is the most general case where the website data format is not CSV. In this case, user has to write a Java
plugin class by modifying the default system provided one. Follow instructions in the FortiSIEM ServiceAPI
available at FortiSIEM support portal under FortiSIEM ServiceAPI section.
After the class has been written and fully tested for correctness, follow these steps.
3. Enter Group and add Description. Click OK to create the folder under Malware URLs.
4. Select the folder just created.
5. Select Update via API
6. For Website, Click Add.
7. In the Data Mapping dialog:
a. Enter the URL of the website
b. Enter User Name and Password (optional)
c. For Plugin class, the custom Java class for this case
d. Select Custom as the Data Format.
e. Click Save
8. Select a import schedule by clicking + on the Schedule Summary. Select when to start the import and how often
to import to get new data from the website.
9. The imported data will show on the right pane after some time.
Custom threat feed websites - STIX formatted data and TAXII import
In this case, the threat feed data is available formatted as STIX and follows the TAXII protocol.
Country Groups
The Country Groups page contains a list of all the country names in the FortiSIEM geolocation database. You can
also create folders that represent different organizations of countries for use in Analytics.
Default Passwords
The CMDB Default Password page contains a list of default vendor credentials. These well-known credentials
should never be used in production. During device discovery FortiSIEM checks if the device credentials are still
set to default , and the system rule Default Password Detected by System triggers an incident if they
are.
You can upload a CSV file with multiple entries to the a default password group by selecting the group, clicking
Import, and then browsing to a CSV file. You will need to format the file with these fields:
Vendor,Model,Access Protocol,User Name,Password
For example:
Microsoft,Windows,WMI,Administrator,Administrator
Devices
You would typically add devices to the CMDB through the Discovering Infrastructure process. However, there may
be situations in which you want to add devices to the CMDB manually. For example, you may not have access
credentials for a device but still want to be able to include network information about it so that logs received by
FortiSIEM can be parsed properly. These topics describe those situations and provide instructions for how to
successfully add a device to the CMDB:
Event Types
The CMDB Event Types page lists the types of events that are collected for supported devices.
Malware Hashes
The CMDB Malware Hash page can be used to define a list of malware files and their hash functions. When
FortiSIEM monitors a directory, it generates these directory events:
When FortiSIEM scans a file and collects its hash, it uses the system rule Malware Hash Check to check the
list of malware hashes, and triggers an alert if a match is found.
You can upload a CSV file with multiple entries to the a default password group by selecting the group, clicking
Import, and then browsing to a CSV file. You will need to format the file with these fields:
BotNet name, Algorithm, Hash Code, Controller IP, Country, Confidence, Last
Seen Time
For example:
MyBotnet,SHA,aaecdrgt0987995dae567812,101.1.1.2,87,China,100,10/20/2014
l Click Update.
l Select Update Automatically to open the update scheduler and verify the URI of the update service.
l Set the schedule for how often you want the list to update from the service.
l Click Save.
l If you want to remove an IP address or set of IP addresses from the group, clear the Enable selection next to the IP
address, and then click Continue to confirm.
l The IP address will still be listed in the group, but it will no longer be blocked. Select Enable to resume blocking it.
l If you want to add a malware IP address to the group, make sure the group is selected, click New, and enter
information about the blocked IP address.
1. Create a group under Malware Hash as described in Creating CMDB Groups and Adding Objects to Them.
2. Select the group you created and click New.
3. Enter information for the Malware Hash you want to add, and then click Save.
Instead of manually adding a blocked domain to a user-defined or system group individually, you can upload a
CSV file with multiple entries to the group by selecting the group, clicking Update, and then selecting Import from
a file. You will need to format the file with these fields:
Botnet Name, Algorithm, Has Code, Controller IP, Malware Type, Confidence,
Severity, Asn, Org, Country, Description, Data Found(MM/DD/YYYY), Last Seen
(MM/DD/YYYY)
This topic describes how to import Malware Hash information into FortiSIEM from external threat feed websites.
l Prerequisites
l Threat feed websites with built in support
l Custom threat feed websites - CSV data - one-time manual import
l Custom threat feed websites - CSV data - programmatic import
l Custom threat feed websites - non-CSV data - programmatic import
l Custom threat feed websites - STIX formatted data and TAXII import
Prerequisites
Before proceeding gather the following information about a threat feed web site.
1. In the CMDB > Malware Hash, find the website you need to import data from.
2. Select the folder.
3. Click Update.
4. Select Update via API. The link should show in the edit box.
5. Enter a schedule by clicking on the "+" icon.
6. Enter the schedule parameters - when to start and how often to import. FortiSIEM recommends no more frequent
than hourly.
7. Select the type of template you want to create.
This requires that the data to be imported is already in a file in comma separated value format. The required
format is:
Botnet Name, Algorithm, Hash Code, Controller IP, Malware Type, Confidence, Severity,
Asn, Org, Country, Description, Data Found(MM/DD/YYYY), Last Seen(MM/DD/YYYY), High IP,
Malware Type, Confidence, Severity, ASN, Org, Country ,Description,Data Found
(MM/DD/YYYY),Last Seen(MM/DD/YYYY)
Note: Although many fields are possible, only Botnet Name and Hash Code are required.
1. Select CMDB > Malware Hash.
2. Click on the "+" button on the left navigation tree to bring up the "Create New Malware Hash Group" dialog.
3. Enter Group and add Description. Click OK to create the folder under Malware Hash.
4. Select the folder just created.
5. Select Import from a file.
6. Click Browse; enter the file name and click Upload.
7. The imported data will show on the right pane.
l file in comma separated value format (separator can be any special character such as space, tab, Hash, dollar etc.)
l one entry is in one line
Note: Although many fields are possible, only Botnet Name and Hash Code are required.
Follow these steps.
This is the most general case where the website data format does not satisfy the previous conditions. In this
case, user has to write a Java plugin class by modifying the default system provided one. Follow instructions in
the FortiSIEM ServiceAPI available at FortiSIEM support portal under FortiSIEM ServiceAPI section. After the
class has been written and fully tested for correctness, follow these steps.
Custom threat feed websites - STIX formatted data and TAXII import
In this case, the threat feed data is available formatted as STIX and follows the TAXII protocol.
Networks
The CMDB Networks page lists the defined networks in your IT infrastructure
Protocols
The CMDB Protocols page lists the protocols used by applications and devices to communicate with the
FortiSIEM virtual appliance.
Adding a Protocol
User Agents
The CMDB User Agent page lists common and uncommon user agents in HTTP communications. The traditional
use case for a user agent is to detect browser types so the server can return an optimized page. However, user
agents are often misused by malware, and are used to communicate the identity of the client to the BotNet
controller over HTTP(S). FortiSIEM monitors HTTP(S) logs and the system rule Blacklist User Agent
Match uses regular expression matching to detect blacklisted user agents.
Instead of manually adding user agents to a user-defined or system group individually, you can upload a CSV file
with multiple entries to the group by selecting the group, clicking Update, and then selecting Import Manually.
You will need to format the user agent password with regular expression notation:
^Really\s+Bad\s+User\s+Agent
Users
The CMDB Users page contains information about users of your system. For more information about adding
users, see Adding a Single User.
Watch Lists
A Watch List is a smart container of similar items such as host names, IP addresses, or user names, that are of
significant interest to an administrator and need to be watched. Examples of watch lists that are already set up in
FortiSIEM are
Related Links
Related Links
FortiSIEM includes several pre-defined watch lists that are populated by system-defined rules.
Attribute
Watch list Description Triggering Rules
Type
Attribute
Watch list Description Triggering Rules
Type
Attribute
Watch list Description Triggering Rules
Type
Availability Servers, networks or Host Name Network Device Degraded - Lossy Ping Response
Issues storage devices or (STRING) Network Device Down - No Ping Response
Applications that are
exhibiting availability Server Degraded - Lossy Ping Response
issues Server Down - No Ping Response
Attribute
Watch list Description Triggering Rules
Type
Denied Countries that are seeing Destination Excessive Denied Connections From An External Country
Countries a high volume of denials Country
on the firewall (STRING)
Attribute
Watch list Description Triggering Rules
Type
Host Scanners Hosts that scan other Source IP Heavy Half-open TCP Host Scan
hosts Heavy Half-open TCP Host Scan On Fixed Port
Malware Hosts where malware Host Name Virus found but not remediated
Found found by Host IPS /AV (String) Malware found but not remediated
based systems and the
malware is not Phishing attack found but not remediated
remediated Rootkit found
Attribute
Watch list Description Triggering Rules
Type
Port Scanners Hosts that scan ports on Source IP Heavy Half-open TCP Port Scan: Single
a machine Destination
Attribute
Watch list Description Triggering Rules
Type
Attribute
Watch list Description Triggering Rules
Type
Attribute
Watch list Description Triggering Rules
Type
Attribute
Watch list Description Triggering Rules
Type
Vulnerable Systems that have high Host Name Scanner found severe vulnerability
Systems severity vulnerabilities (STRING)
from scanners
If you have FortiSIEM Service Provider deployment, the Organization column in the CMDB report table will show
whether the report is defined for a specific organization. If it is, then that report is available for both the
organization and Super/Global users.
CMDB Report
Object to Report On Report Name
Folder
l Discovered Users
l Externally Authenticated
FortiSIEM Users
Users
l Locally Authenticated FortiSIEM
Users
l Manually Defined Users
CMDB Report
Object to Report On Report Name
Folder
You can modify user-defined reports by selecting the report and clicking Edit. However, you cannot directly edit a
system-defined report. Instead, you have to clone it, then save it as a new report and modify it.
1. Log in to your Supervisor node.
2. Go to CMDB > CMDB Reports.
3. Select the system-defined you want to modify, and then click Clone.
4. Enter a name for the new report, and then click Save.
The cloned report will be added to the folder of the original report.
5. Select the new report, and then click Edit.
6. Edit the report, and then click Save.
1. Go to Report listing page and select the CMDB Report folder where the report is to be imported.
2. Click Import and paste the report into the window
3. Click Import and see the report showing up in the correct folder.
The FortiSIEM virtual appliance includes a data archiving function that enables you to define an offline storage
location, and a policy for the number of days that events will be kept in online or offline storage. This archiving
function also includes the ability for compliance auditors to validate logs to ensure that they haven't been
tampered with in the offline storage. The data is cryptographically signed (SHA256) at the point of entry, and the
checksums are stored in the database. The check sums can be re-verified on demand at any point of time, and if
the data has been tampered with, then the check sums will not match. The data integrity reports can be exported
in PDF format. If the events in offline storage need to be queried at some point in the future, they can be restored
to the FortiSIEM virtual appliance.
For Service Provider deployments, you can set archive policies for each organization. If one organization requires
30 days of storage, and another customer requires 90 days of storage, then FortiSIEM will attempt to enforce
these policies in relation to the amount of storage available. For the first organization, events will be deleted from
the archive storage location on the 31st day to free up capacity for the organization that has longer storage
requirements.
As with the online EventDB data, every 30 minutes FortiSIEM will check the capacity of the offline archive
storage, and when the remaining storage capacity reaches a 20GB threshold, it will begin to purge data from the
archive location, beginning with the oldest data, and purging it in daily increments, until the remaining storage
capacity is above 20GB.
Alert Description
Online event database When the database reaches a point where the remaining
close to full (below 20GB) storage capacity is below 20GB, its contents will be purged
or archived, depending on whether an archive storage
location has been defined
Event Archive failed The archive process has failed, likely due to a lack of
capacity in the offline storage location
Event Archive purged The contents of the event archive have been purged from
because it is full offline storage due to capacity issues
Related links
Prerequisites
l Make sure you read the section on Setting Archive and Purge Policies in the topic Creating Event Database
Archives before you set up your policy. It is very important that you understand how FortiSIEM moves data into the
archive, and purges archived data when the archive destination storage reaches capacity, before you create your
policy.
l Make sure that your Archive Destination has sufficient storage for your event data + 20GB. When the archive
storage reaches 20GB of capacity, FortiSIEM will begin to purge archived data, in daily increments, starting with the
oldest data, to maintain a 20GB overhead.
l Calendar View - This view shows you how much storage is used by each organization on a day by day basis
l Top (Event Type, Reporting Device) View - This view shows you the top (Event Type, Reporting Device) tuples
consuming most storage for each organization on a month-by-month basis
Column Description
Start Time The earliest time of the messages in this file. The file does not contain
messages that were received by FortiSIEM before this time.
The latest time of the messages in this file. The file does not contain
End Time
messages that were received by FortiSIEM after this time.
Category l Internal: these messages were generated by FortiSIEM for its own
use. This includes FortiSIEM system logs and monitoring events such
as the ones that begin with PH_DEV_MON.
l External: these messages were received by FortiSIEM from an
external system
l Incident: these corresponds to incidents generated by FortiSIEM
Checksum
The checksum algorithm used for computing message integrity
Algorithm
l Not Validated: the event integrity has not been validated yet
l Successful: the event integrity has been validated and the return
was success. This means that the logs in this file were not altered.
Validation Status
l Failed: the event integrity has been validated and the return was
failed. This means that the logs in this file were altered.
l Archived: the events in this file were archived to offline storage
l Incident Outbound Integration: This creates a ticket in an external ticketing system from FortiSIEM incidents.
l Incident Inbound Integration: This updates FortiSIEM incident ticket state from external system ticket states.
Specifically, when a ticket is closed in the external ticketing system, the incident is cleared in FortiSIEM and the
ticket status is marked closed to synchronize with the external ticketing system.
l CMDB Outbound Integration: This populates an external CMDB from FortiSIEM CMDB.
l CMDB Inbound Integration: This populates FortiSIEM CMDB from an external CMDB.
FortiSIEM provides a Java based API that can be used to integrate with ticketing systems. Out of the box
integration is available for ServiceNow, ConnectWise and Salesforce. Integration with other systems can be built
using the API. Contact Fortinet support for assistance.
Configuring ServiceNow
1. Login to ServiceNow.
2. For Service Provider Configurations, create Companies by creating Company Name.
Configuring ConnectWise
1. Login to Salesforce.
2. Create a custom domain.
3. For Service Provider Configurations, create Service App > Accounts.
FortiSIEM will use the Account Name.
c. For Salesforce:
a. Go to Service App > Accounts.
b. Use Account Name.
11. For Run For, choose the organizations for whom tickets will be created.
12. Click Save.
This will update FortiSIEM following incident fields when ticket state is updated in the external ticketing system.
12. For Groups, select the FortiSIEM CMDB Groups whose member devices would be synched to external CMDB.
13. For ConnectWise, it is possible to define a Content Mapping.
a. Enter Column Mapping values:
i. To add a new mapping, click on the + button.
ii. Choose FortiSIEM CMDB attribute as the Source Column.
iii. Enter external (ConnectWise) attribute as the Destination Column.
iv. Specify Default Mapped Value as the value assigned to the Destination Column if the Source
Column is not found in Data Mapping definitions.
v. Select Put to a Question is the Destination Column is a custom column in ConnectWise.
b. Enter Data Mapping values:
i. Choose the (Destination) Column Name.
ii. Enter From as the value in FortiSIEM.
iii. Enter To as the value in ConnectWise.
14. Select Run after Discovery if you want this export to take place after you have run discovery in your system. This
is the only way to push automatic changes from FortiSIEM to the external system.
15. Click Save.
This section describes procedures for exporting FortiSIEM events to an external system via the Kafka message
bus.
Prerequisites
l Make sure you have set up a Kafka Cloud (here) with a specific Topic for FortiSIEM events.
l Make sure you have identified a set of Kafka brokers that FortiSIEM is going to send events to.
l Make sure you have configured Kafka receivers which can parse FortiSIEM events and store in a database. An
example would be Logstash receiver (see here) that can store in a Elastic Search database.
l Supported Kafka version: 0.8
Procedure
1. Go to Admin > General Settings > Kafka Configuration.
2. Select Enable Kafka.
3. Select a Topic.
4. Add Brokers by clicking on + icon.
l Enter IP address or Host name of the broker.
l Enter Broker port (default 9092).
5. Click Save.
Note: Enter multiple broker addresses for redundancy. If one broker is not available, FortiSIEM is going to try the
next broker in the list. The full list of brokers does not need to be specified.
Backup
The SVN files are stored in /data/svn. Copy the entire directory to another location.
# cd /data
# cp -r svn /<another>/<mount>/<point>
Restore
Copy the entire /data/svn from the backup location and rename the directory to /data/svn.
# cd /<another>/<mount>/<point># cp -r svn /data
Backup
The database files are stored in /data/cmdb/data. FortiSIEM automatically backs up this data twice daily and the backup files
are stored in /data/archive/cmdb. To perform a backup, move these files to another location. For example:
If your /data disk is on an external NFS mount then your CMDB backup is already separate from the VM
infrastructure.
[root@SaaS-Sup cmdb]# pwd
/data/archive/cmdb
[root@SaaS-Sup cmdb]# ls -lt
total 1213952
-rw-rw-rw- 1 root root 95559457 Apr 20 03:02 phoenixdb_2011-04-20T03-00-01
-rw-rw-rw- 1 root root 93010144 Apr 19 13:04 phoenixdb_2011-04-19T13-00-02
-rw-rw-rw- 1 root root 91142941 Apr 19 03:02 phoenixdb_2011-04-19T03-00-01
-rw-rw-rw- 1 root root 89686080 Apr 18 13:03 phoenixdb_2011-04-18T13-00-02
Restore
If your database becomes corrupted, restore it from backup by performing these steps on you Supervisor node.
1. Stop all processes with this phTools command:
#phtools --stop all
3. Copy the latest phoenixdb_<timestamp> file to a directory like /tmp on the Supervisor host.
4. Go to /opt/phoenix/deployment.
5. Run db_restore /tmp/phoenixdb_<timestamp>.
6. When this process completes, reboot the system.
#reboot
Backup
The event data is stored in /data/eventdb. Since this data can become very large over time, you should use a
program such as rsync to incrementally move the data to another location. From version 4.2.1 the rsync program
is installed on FortiSIEM by default.
Restore
To restore eventdb there are two options:
l Mount the directory where the event database was backed up.
l Copy the backup to the /data/eventdb directory.
These instructions are for copying the backup to the /data/eventdb directory.
1. Stop all running processes.
#phtools --stop all
3. Copy the the event DB to the event DB location /data/eventdb If you use the cp command it may appear that
the command has hung if there is a lot of data to copy
#cp -a /backup/eventdb /data/eventdb
Alternatively you can use rsync and display the process status.
#rsync -a --status /backup/eventdb /data/eventdb
FortiSIEM includes several different types of dashboards and views to monitor your IT infrastructure. Topics in
this section provide an overview of the General and VM View dashboards available in the Dashboard tab, along
with their user interface controls and customization options.
l Dashboard Overview
l Customizing Dashboards
l Creating Dashboard Slideshow
l Exporting and Importing Dashboards
l Link Usage Dashboard
Dashboard Overview
FortiSIEM includes two types of component dashboards: General, which are used to monitor IT infrastructure
components, and VM View, which focus specifically on information about virtual machines in your infrastructure.
These two types of component dashboards also include two types of dashboads for collecting different types of
information:
l Summarydashboards that provide single-line entries for IT infrastructure components based on their system
status (Critical, Criitcal + Warning, All) in operational time
l Widget-based dashboards that provide metrics and analytics for functional areas using historical data
In addition to the summary and widget-based dashboards, FortiSIEM also includes a specialized Incident
dashboard, with features that are detailed in the Incidents - Flash version section.
Topics in this section provide an overview of the Summary and Widget dashboards, as well as how to use the
Analysis menu to gain more information about your IT infrastructure components.
Dashboard Overview
Summary dashboards are best used for gathering information about individual infrastructure components in
operational time. Summary dashboards include the Exec Summary dashboard, and all the dashboards in
the Summary Dashboards and Availability/Performance folders of the Dashboards > General pane. In
the Dashboards > VM View pane, summary dashboards include the ESX Host Type dashboards (All ESX
Hosts and Standalone ESX Hosts, for example). Metrics for these dashboards are displayed either on a real-
time basis, or as an average of ten minute intervals.
This screenshot shows an example of a Biz Service Summary dashboard for a multi-tenant deployment. It
contains all the standard user interface controls found in summary dashboard, though some additional UI controls
are found in other summary dashboards as described in the table Columnar Dashboard UI Controls.
Selecting a business service in the top pane loads all the components associated with that service into the panes
below.
UI Control Description
Status Filter Filters the view of the components based on component status: Critical, Critical + Warning, All
Organizations
For multi-tenant deployments, filter components based on the organization they belong to
Filter
Service Info For the Business Services summary dashboard, shows the Quick Info for the business service. For
other components, an Info link is provided in the same location in the UI.
The Analysis menu contains a number of options for component analytics, depending on the
component selected. See Using the Analysis Menu for more information. You can also access the
Analysis Menu
Analysis menu for a component by hovering your mouse over the component's Device IP menu until
the blue Quick Info icon appears, and then clicking the icon.
Customize The Custom Columns control lets you change the columns that are displayed in the dashboard. See
Columns Adding Custom Columns to Dashboards for more information.
Most columns contain a summary or trend view of their display information. Hover your mouse over
Performance the metric until a trend line icon appears, and then click to view the summary or trend information.
Summaries Note that many of these summary pop-ups have their own navigational controls, for example to set
the time interval for the summary.
Incident The incident summary shows the number and type of incidents associated with the component. Hover
Summary over the number to view a quick summary of the incidents, click on the incident number to view
incident details.
UI Control Description
The Quick Info view of a device, which you can also access through the Analysis menu or
hovering your mouse cursor over the Device IP column, displays General and Health
information for the device, and when appropriate, Identity and Location information. It
also contains links to additional information about the device:
l Incidents
An exportable summary of incidents associated with the device
l Health
Availability, Performance, and Security health information for the device. You can also
access this information by clicking the Device Health user interface control, or by selecting
Device Health in the Analysis menu.
l BizService
Any business services impacted by the device. You can also access this information by
selecting Impacted Business Services in the Analysis menu.
l Applications
Quick
Displays a report on the top 10 applications associated with the device by Average CPU
Info
Utilization over the past hour
l Vulnerability and IP Status (Not used in the Dashboard view)
Displays the vulnerability status reports that are also available by selecting Vulnerability and
IPS Status in the Analysis menu
l Hardware Health (Used only for the CMDB/Storage view)
Displays health information for the hardware being used for storage
l Interfaces
Displays a report on the top 10 interfaces associated with the device by average throughput
l Topology
Shows the device's location in the network topology. You can also access this information by
selecting Topology in the Analysis menu.
The Quick Info view also contains two links, Goto Config Item, which links to the device
entry in the CMDB, and Goto Identity, which links to Analytics > Identity and Location
Report, where you can edit this information for the device.
Component Availability , Performance , and Security health reports for the device. You can also access this
Health information by selecting a device in the Summary dashboard, and then click Health, or by going to
Quick Info > Health after selecting the device . If any Incidents are displayed, click the number to
view the Incident Summary . Depending on the reported metric, you can zoom in for a closer look at
graphs and reports by clicking the Magnifying Glass icon that appears when you hover your mouse
cursor over them.
Location Filters components by their geographic locations. See Setting Device Location Information for more
Selection information.
Time View and The Time View has two options for whether you want to view Real Time or Average-10 mins
Refresh metrics for your component, and for the interval and which you want them to refresh.{to
Interval
This screenshot shows the All ESX Hosts summary dashboard, which includes a summary pane for All ESXs at
the top, and a summary pane for individual VM instances for selected ESXs at the bottom. The user interface
controls for the Virtual Infrastructure summary dashboards are very similar to those in the General summary
dashboards.
Ui Control Description
Organizations For multi-tenant deployments, filter components based on the organization they
Filter belong to
The Quick Info view of a device, which you can also access through the
Analysis menu or hovering your mouse cursor over the Device IP column,
displays General and Health information for the device, and when
appropriate, Identity and Location information. It also contains links to
additional information about the device:
l Incidents
An exportable summary of incidents associated with the device
l Health
Availability, Performance, and Security health information for the
device. You can also access this information by clicking the Device
Health user interface control, or by selecting Device Health in the
Analysis menu.
l BizService
Any business services impacted by the device. You can also access this
information by selecting Impacted Business Services in the
Analysis menu.
l Applications
Quick Info
Displays a report on the top 10 applications associated with the device
by Average CPU Utilization over the past hour
l Vulnerability and IP Status (Not used in the Dashboard view)
Displays the vulnerability status reports that are also available by
selecting Vulnerability and IPS Status in the Analysis menu
l Hardware Health (Used only for the CMDB/Storage view)
Displays health information for the hardware being used for storage
l Interfaces
Displays a report on the top 10 interfaces associated with the device by
average throughput.
l Topology
Shows the device's location in the network topology. You can also
access this information by selecting Topology in the Analysis menu.
The Quick Info view also contains two links, Goto Config Item, which links to
the device entry in the CMDB, and Goto Identity, which links to Analytics >
Identity and Location Report, where you can edit this information for the
device.
Ui Control Description
Device Health Availability , Performance , and Security health reports for the device. You
can also access this information by selecting a device in the Summary
dashboard, and then click Health, or by going to Quick Info > Health after
selecting the device . If any Incidents are displayed, click the number to view
the Incident Summary . Depending on the reported metric, you can zoom in
for a closer look at graphs and reports by clicking the Magnifying Glass icon
that appears when you hover your mouse cursor over them.
Locations Filters components by their geographic locations. See Setting Device Location
Information for more information.
The Custom Columns control lets you change the columns that are displayed
Customize
in the dashboard. See Adding Custom Columns to Dashboards for more
Columns
information.
When you select an individual ESX Host in the Virtual Infrastructure hierarchy, the ESX Health tab will be selected
and you will see a widget dashboard with reports for ESX Statistics, Active Incidents, Performance Metrics,
Memory Utilization, and Disk Rate. Additional tabs are VM Summary and Top VMs.
Top VMs A widget dashboard with reports for Top VMs by CPU Utilization, Top
VMs by Memory Utilization, Top VMs by Disk Write Request Rates,
Top VMs by CPU Ready Percentage, and Top VMs by Disk Read
Request Rate, all updated hourly
When you select an ESX or VM in the Virtual Infrastructure hierarchy, you will see a widget dashboard that
contains reports for VM Statistics, Active Incidents, and Performance Metrics.
This screenshot shows the Event Info menu that you open by hovering your mouse cursor over an event within a
widget until the menu icon appears.
UI Control Description
Resize You can resize the widget by clicking on this control, and then indicating how many tile
spaces you want that widget to use in the dashboard
Hover your mouse cursor over the right upper corner of the widget to access this control.
Select a line displayed in the widget to drill down to the historical search associated with
Drill Down that metric. You can then run or modify the search. See Refining the Results from
Historical Searchfor more information. This is also the same functionality as the Drill
Down option in the Event Info menu.
Edit Settings Hover your mouse cursor over the right upper corner of the widget to access this
control. Edit the settings associated with the widget. These include:
Hover your mouse cursor over the right upper corner of the widget to access this control.
Remove
Click this control to remove the widget from the dashboard
Event Info Hover your mouse cursor over a line in a report to view the Quick Info for the associated
Event Type, or select Drill Down to view, edit, and run the associated historical search.
See Refining the Results from Historical Search for more information.
Add Report At the bottom of each widget dashboard is a button to add more widgets to the dashboard.
Related Links
FortiSIEM discovers network topology at two levels, layer 3 and layer 2. Layer 3 connectivity involves IP
addresses, while Layer 2 connectivity
The layer 3 topology is discovered by obtaining network interface IP address and masks for all devices via SNMP
(RFC 1213). The local networks e.g. loopback (127.0.0.0/8), link local addresses (169.254.0.0/16) are filtered out
and the distinct networks segments are identified.
l Only the network devices are drawn by default. A network device is one that belongs to row Network Device tab in
the CMDB.
l Only those networks are drawn that have devices discovered by FortiSIEM (and are in CMDB). There is a “ ” button
next to those networks. Clicking on the “” button displays those hosts in the topology graph. Clicking on the “-“
button hides those hosts.
When an enterprise network has Layer 2 switches and hubs, a layer 3 topology misses the connectivity between
servers to layer 2 switches and the trunk port connectivity between layer 2/3 switches. Layer 2 discovery is difficult
and, more importantly, vendor dependent as vendors have different implementations of the Spanning Tree
Protocol (STP).
For Cisco switches, the layer 2 topology is obtained via SNMP (IEEE spanning tree MIB as found in RFC1493 and
CISCO-VTP-MIB) as follows:
The Layer 2 topology is visualized on the FortiSIEM topology diagram by choosing the layer 2 mode. Then by
clicking the “+” next to a device, the VLANs on that switch are displayed. Also, the trunk port connectivity is shown
in an orange color and a tool tip provides the VLANs over this trunk link.
Then by clicking on the “+” of a VLAN, the hosts belonging to that VLAN and also the switch ports they connect to
are displayed.
The host to switch port connectivity can also be seen in a tabular form by first clicking the switch and then clicking
the “Port Mapping Table”.
This screenshot shows the CMDB tab selected, and in the Device View, Topology is selected. This topology
map shows all the devices for the selected organization, and provides controls for editing the topology views that
will be available to users from that organization.
UI Control Description
Zoom Use the slider to increase or decrease the zoom level of the map
Organizations For multi-tenant deployments, filter devices based on the organization they
Filter belong to
View Select the layers, connection types, and number of hops from the host to
display in the map
UI Control Description
Search Search for specific devices based on name, IP, or Business Service
View Options Set the display options, including severity levels, for the map
Set the type of topological map to display, as well as the length of links
Layout Options
between devices
You can access the device group view of the topological map by selecting a group of devices in the Device View,
and then clicking the Topo button in the Summary pane. Select an individual device, and then click the Topo
button in the Details pane to view that device within the topological map.
UI Control Description
Zoom Use the slider to increase or decrease the zoom level of the map
Click on the arrow icon in the upper-right corner of the map to open
these controls. Options to enable/disable node dragging, incident
View Controls
display, connection layer display, and the number of hops from the
host to display.
Map Explorer Click o the arrow icon in the lower-right corner of the map to open the
Map Explorer. As you zoom into the map, the map explorer will show
you the area that you are currently viewing. You can move to another
area by clicking and dragging the highlighted section of the map
explorer to that area.
Devices within the topological map have additional icons to represent information about the device.
Icon Name Description
Column
Description Value for System CPU Utilization
Attribute
PH_DEV_MON_SYS_CPU_UTIL
The type of event that provides
Event Type PH_DEV_MON_EC2_METRIC
the attributes for the metric
PH_DEV_MON_CLARION_SP_UTIL
Column
Description Value for System CPU Utilization
Attribute
Column Type The type of information that will Device IP (system generated name) - hostIpAddr -
be displayed in the column for Host
each attribute CPU Name - cpuName - Object
Storage Processor - spName -Object
CPU Util - cpuUtil - Reading
With this information, you can see that CPU Util metric is derived from the cpuUtil attribute of the PH_DEV_
MON_SYS_CPU_UTIL event, and that the display column is a reading that uses the calculation Average over
time and then Average over the object being reported on. Now apply this to the event reports for a host with two
CPUs, and you can see how the calculation works.
[PH_DEV_MON_SYS_CPU_UTIL]:[eventSeverity]=PHL_INFO,[fileName]=phPerfJob.cpp,
[lineNumber]=3137,
[cpuName]=CPU x 1,[hostName]=win2k8.FortiSIEM.net,[hostIpAddr]=192.168.0.40,
[cpuUtil]=2.000000,[pollIntv]=176,[phLogDetail]=
[PH_DEV_MON_SYS_CPU_UTIL]:[eventSeverity]=PHL_INFO,[fileName]=phPerfJob.cpp,
[lineNumber]=3137,
[cpuName]=CPU x 1,[hostName]=win2k8.FortiSIEM.net,[hostIpAddr]=192.168.0.40,
[cpuUtil]=4.000000,[pollIntv]=176,[phLogDetail]=
PH_DEV_MON_SYS_CPU_UTIL]:[eventSeverity]=PHL_INFO,[fileName]=phPerfJob.cpp,
[lineNumber]=3137,
[cpuName]=CPU x 2,[hostName]=win2k8.FortiSIEM.net,[hostIpAddr]=192.168.0.40,
[cpuUtil]=20.000000,[pollIntv]=176,[phLogDetail]=
[PH_DEV_MON_SYS_CPU_UTIL]:[eventSeverity]=PHL_INFO,[fileName]=phPerfJob.cpp,
[lineNumber]=3137,
[cpuName]=CPU x 2,[hostName]=win2k8.FortiSIEM.net,[hostIpAddr]=192.168.0.40,
[cpuUtil]=40.000000,[pollIntv]=176,[phLogDetail]=
This output shows two samples of cpuUtil taken over three minutes for each CPU running on the host
192.168.0.40. According to the Aggregator for this column, FortiSIEM should first average the samples over
time for each CPU, and then average those together to derive the metric for the host. The average for the CPU 1
is 3.000000, and the average for CPU 2 is 30.000000. These values are combined and averaged again to get
the overall metric for the host, which is 16.500000.
Quick Info The Quick Info view of a device, which you can also access through the
Analysis menu or hovering your mouse cursor over the Device IP column,
displays General and Health information for the device, and when
appropriate, Identity and Location information. It also contains links to
additional information about the device:
l Incidents
An exportable summary of incidents associated with the device
l Health
Availability, Performance, and Security health information for the
device. You can also access this information by clicking the Device
Health user interface control, or by selecting Device Health in the
Analysis menu.
l BizService
Any business services impacted by the device. You can also access
this information by selecting Impacted Business Services in the
Analysis menu.
l Applications
Displays a report on the top 10 applications associated with the
device by Average CPU Utilization over the past hour
l Vulnerability and IP Status (Not used in the Dashboard view)
Displays the vulnerability status reports that are also available by
selecting Vulnerability and IPS Status in the Analysis menu
l Hardware Health (Used only for the CMDB/Storage view)
Displays health information for the hardware being used for storage
l Interfaces
Displays a report on the top 10 interfaces associated with the device
by average throughput
l Topology
Shows the device's location in the network topology. You can also
access this information by selecting Topology in the Analysis
menu.
The Quick Info view also contains two links, Goto Config Item, which links
to the device entry in the CMDB, and Goto Identity, which links to Analytics
> Identity and Location Report, where you can edit this information for the
device.
Device Health Availability , Performance , and Security health reports for the device.
You can also access this information by selecting a device in the Summary
dashboard, and then click Health, or by going to Quick Info > Health after
selecting the device . If any Incidents are displayed, click the number to view
the Incident Summary . Depending on the reported metric, you can zoom in
for a closer look at graphs and reports by clicking the Magnifying Glass icon
that appears when you hover your mouse cursor over them.
Device Displays reports for Availability Trend Status, Ping Response Time, and
Availability Ping Packet Loss for the device over the past hour, and Device Uptime for
the device over the past thirty minutes
Interface Status Displays reports for Interface Utilization Percentage, Interface Error
Percentage, Interface Traffic, and Interface Error Count over the past
hour for the device
Event Status Displays reports for Events per Second, Top Network Connections, Top
Events by Severity, and Top TCP/UDP Ports over the past hour for the
device
All Events by
Group for the Opens an Historial Search for the selected device using these criteria
Last 10 Minutes
Traffic Status Displays reports for All Permitted Traffic Sourced From or Destined to
the selected device, and All Denied Traffic Sourced from or Destined to
the selected device over the previous hour
Vulnerability and Displays reports for All Vulnerabilities for Last 1 Day and All Warning +
IPS Status Critical IPS Events for the device over the past 24 hours
Historical Events Opens an historical search for all events associated with the device over the
for Last 5 Mins past five minutes
Customizing Dashboards
FortiSIEM includes several dashboards for device types and IT functional areas, but you can also customize and
create new dashboards and widgets.
Prerequisites
Procedure
1. Find the event that contains the attribute you want to use.
In this case, you want to create a hardware temperature reading. The event PH_DEV_MON_HW_TEMP contains
the attribute envTempDegC.
[[PH_DEV_MON_HW_TEMP]:[eventSeverity]=PHL_INFO,[fileName]=deviceJunOS.cpp,
[lineNumber]=619,[hostName]=JunOS-3200-1,
[hostIpAddr]=172.16.5.64,[hwComponentName]=FPC- EX3200-24T- 8 POE @ 0/*/*,
[envTempDegC]=33,[phLogDetail]=
Attributes : hwComponentName
Aggregator : N/A
Display Name : N/A
Object
Format : N/A
Trend Chart : N/A
Type : Object
1. In the Dashboard view, select the dashboard you want to set for your home page.
2. At the top of the General view of the dashboards, click the Home icon.
The Home icon will be filled in rather than greyed out, and the next time you log into FortiSIEM, the page you
selected will be your home page.
l A check box appears next to each dashboard in the dashboard tree under the General tab
l For each folder, expand the folder to see the check box for each dashboard
l Select the dashboards for slideshow
l Select the Interval for switching between dashboards
l Click Start to enter Slideshow mode. Click Cancel to not save the current slideshow configuration
l Once in Slideshow mode, click Escape button to stop the slideshow
Note: Slideshow configuration is saved on a per user basis. When the user logs back on, same slideshow can be
used.
l My Dashboard
l Availability/Performance > Avail/Perf Widgets
l Biz Svc Dashboard
l Dashboards By Function
To export a dashboard
l Go to CMDB > Devices > Firewall or CMDB > Devices > Router/Switch
l The default is Inventory View. Click Link Usage to change to this special view
l A three level panel appears on right
l Top pane: Device level view: System level metrics such as CPU, Memory, Connections, Sent/Receive
Traffic, Received EPS. Source is SNMP.
l Middle pane: For the selected device in Top pane, it shows metrics for each interface. Source is SNMP.
l Bottom pane: For the selected device in Top pane and interface in middle pane, it shows
l Application Usage: Top Applications, Top Sources, Top Connections. Source is Netflow.
l QoS Statistics: QoS statistics. Source is SNMP - Fortinet only
Note: Slideshow configuration is saved on a per user basis. When the user logs back on, same slideshow can be
used.
l Summary dashboards that shows multiple metrics for the device in a single line. This enables users to see
multiple metrics of the same device in one view.
l Widget dashboards that provide separate views of each metric. This enables to see critical devices for a metric at
a time.
Multiple dashboards can be grouped into a folder. User first needs to choose the dashboard folder and then select
the dashboard within that folder.
l Infrastructure level
l Network Dashboard
l Server Dashboard
l VMWare Dashboard
l Web Server Dashboard
l Application Server dashboard
l Cloud Infrastructure level
l Amazon Web Services Dashboard
l Security Dashboard
l Storage level
l NetApp Dashboard
l VNX Dashboard
l Application level
l Salesforce Dashboard
l Office 365 Dashboard
l Google Apps Dashboard
l FortiSIEM Dashboard
To view these dashboards
1. Logon to FortiSIEM
2. Switch to the right organization (for Service Provider version)
3. Click Dashboard tab on the main user interface
4. Select the appropriate dashboard folder from the drop down. The dashboards belonging to the selected folder will
show and the contents of the first dashboard will display automatically.
5. Select the appropriate dashboard to see its contents.
2. Select the device(s) and move them to the right pane by clicking the button
3. Click OK
4. To customize the columns, see here
Deleting Dashboards
Note that built-in dashboard folders and dashboards can not be deleted.
Modifying Dashboards
Saving changes
User settings changes are saved - both for built-in and user created dashboards. If the user logs back in, then the
changes will be seen. System upgrades will also preserve these customizations.
1. To select Tile layout, select Tile option from the menu next to on top. Tile layout allows you
to place widgets of several sizes on the dashboard.
2. To select a column layout, choose the number of columns from the menu next to .
Sharing Dashboards
l User created dashboard folders and its contents are only visible to the user who created it. If this folder need to be
visible to other users, then we recommend:
l using a shared account or
l using export/import mechanism to create the folder for that user.
l System dashboard folders are owned by FortiSIEM. Any changes to those dashboards may be lost during upgrade,
if FortiSIEM also decides to change those dashboards.
2. Click Import .
3. Select the file from local desktop. It must an XML file suitable for import. Typically this is exported from another
FortiSIEM system.
4. Click Import.
5. The dashboard will display
2. Click Export
Analytics
Search
FortiSIEM search functionality includes real time and and historical search of information that has been collected
from your IT infrastructure. With real time search, you can see events as they happen, while historical search is
based on information stored in the event database. Both types of search include simple keyword searching, and
structured searches that let you search based on specific event attributes and values, and then group the results
by attributes.
Rules
Because FortiSIEM is continuously monitoring your IT infrastructure, you can also set rules so that when specific
conditions are met, it triggers an incident, and, in some cases, sends a notification.
Reports
Reports are pre-defined search queries. FortiSIEM includes a large catalog of reports for common devices and IT
analysis tasks that you can use and customize, and you can also save searches that you've run as reports to use
again later.
l Search
l Rules
l Reports
l Audit
l Visual Analytics
l Real Time Performance Probe
Search
Historical and Real Time search is the core functionality of FortiSIEM analytics, enabling you to analyze, report
on, and further improve your IT infrastructure.
l Historical Search
l Real Time Search
l Structured Search Operators
l Selecting Attributes for Structured Searches, Display Fields, and Rules
l Using Expressions in Structured Searches and Rules
l Keywords and Operators for Simple Searches
l Using Geolocation Attributes in Searches and Search Results
l Creating Filter Criteria and Display Column Sets
Historical Search
With the Historical Search feature, you can go back in time and retrieve events from the event database. By using
either a simple keyword-based search or a more detailed structured search, you can get quick and valuable
insights into events that have occurred over any selected time period.
You can run two types of historical searches on FortiSIEM data: simple searches, in which you use a keyword
search, and structured searches, in which you can specify search conditions and how the results should be
grouped.
When you use simple historical search, you enter a keyword to search for in the logs collected by FortiSIEM,
specify any filter criteria, and then run the search, which will produce a chart and a list of results matching your
search criteria. You can then use additional user interface controls to change the chart display, filter or find more
information about events in the result list, and export or share results.
This screenshot shows the results of simple search using the keyword TCP.
UI Control Description
Search Criteria For simple historical search, use the search box to find keywords in raw event
logs. You can also load an existing historical search report to use for your
search criteria, or create a rule from your search results.
UI Control Description
List Display
Select which columns will be displayed in the search results
Columns
Filters Set the time interval over which you want to search, and, for multi-tenant
deployments, which organization's logs you want to search
l Save
Saves the report to Generated Reports where it will be retained for
the time period you specify. You can also select whether you want
the search criteria to be saved as a report that you can use in the
future.
l Export
Report Export the report, with the option of including the chart, as a PDF or
Management CSV file
l Email
Email the report as a CSV or PDF file, with the option of including the
chart
l Copy to a new tab
Load the search into a new tab within FortiSIEM
ChartDisplay You can set both the data you want to display, and how it should be
displayed. See Overview of Historical Search Results and Charts for more
about the different chart types.
Select an event from the results, and add its attributes to structured search
Event Filter
conditions.
Event Information Select an event, and view Quick Info about it, or view Location information
about it such as source or destination IPs.
With historical structured search, you can enter conditions for your search based on event attributes, and set
which attributes will be used to group the search results in a way that is similar to the use of the of the Group By
command in SQL.
This screenshot shows a structured historical search for All Non-Reporting Modules selected from the system
Reports > Event Status. The screenshot below it shows a close-up of the the Conditions and Group By
options dialog. See Creating a Structured Historical Search and Structured Search Operators for more
information about these options.
When you run a structured historical search, all events within the specified time window are examined and added
to the result set following these steps:
1. The system fetches the next event within the search time window and applies the filtering criteria. If the event
does not pass the filtering criteria, the system fetches the next event.
2. If the event passes the filtering criteria, the system then compares the attributes of this event against the other
entries in the result set. If the current event contains an attribute that is included in the Group By attribute set,
then the results for that attribute are updated. Otherwise, a new entry is created in the result set.
3. After all the events in the search time window are processed, the system sorts the results to produce the final
result set.
As an example, consider these events in the event database, and running a search for Top Firewall Recorded
Conversations Ranked By Total Connections (Descending) and Total Bytes (descending) over them .
Top Firewall Recorded Filtering criteria: Reporting Device IP IN Firewall AND Event Type IN
Conversations Ranked By Permit Traffic
Total Connections Group-By attributes: Source IP, Destination IP, IP Protocol, Destination
(Descending) and Total Bytes Port
(descending) Display attributes: Source IP, Destination IP, IP Protocol, Destination Port,
SUM(Matched Events) DESC, SUM(Total Bytes) DESC
Query window: Between 1/2/10 and 1/5/10
Result
Destination Destination COUNT (Matched
Source IP Protocol SUM(Total Bytes)
IP Port Events)
Top Destination IPs Ranked Filtering criteria: Reporting Device IP IN Firewall AND Event
By Total Connections Type IN Permit Traffic
(Descending) and Total Bytes Group-By attributes: Destination IP
(descending) Display attributes: Destination IP, SUM(Matched Events)
DESC, SUM(Total Bytes) DESC
Query window: Between 1/2/10 and 1/5/10
Result
202.1.1.4 4 7 KB
202.1.1.5 1 2 KB
202.1.1.6 1 2KB
Raw Event Log CONTAINS "login Simple Only events that contain both the keywords
AND failed" (keyword) "logon" and "failed" are part of report
search
Simple
Only events that contain the keyword "denied"
Raw Event Log CONTAINS "denied" (keyword)
are part of report
search
Reporting Device IP = 10.1.1.1 Structured Only events from the device that is reporting
search with IP address 10.1.1.1 are part of the report
Reporting Device IP IN Firewall AND Structured Only firewall deny events from firewall devices
Event Type IN Deny Traffic search in CMDB are part of the report
The following examples illustrate how to write a search using the FortiSIEM GUI.
Top Firewall Denied Source Filter Criteria: Reporting Device IP IN Firewall AND Event Type IN Deny
IPs ranked by the total Traffic
number of attempts in the last Group By attributes: Source IP
hour Display attributes: Source IP, COUNT(Matched Events) DESC
Query window: 1 hour
l Prequisites
l Procedure
Prequisites
If you need to familiarize yourself with how historical search works or the historical search interface, you should
read these topics:
Procedure
1. Log in to your Supervisor node.
2. Go to Analytics > Historical Search.
3. For Filter Criteria, select Simple.
4. Enter the keywords you want to search for in the raw event logs.
See Keywords and Operators for Simple Searches for information on keyword searching.
5. Under Display Fields, select the attributes you want to use as the columns in your results list.
See Selecting Attributes for Structured Searches, Display Fields, and Rules and Creating Filter Criteria and
Display Column Sets for options for selecting display field attributes and sets.
6. For Time, set the interval over which you want the search to run.
7. For Service Provider deployments, select the Organization you want to run the search against.
8. Click Run.
The results of your search will be displayed in the chart and search results list.
l Prequisites
l Procedure
Prequisites
If you need to familiarize yourself with how historical search works or the historical search interface, you should
read these topics:
Procedure
FortiSIEM includes a number of pre-defined reports that you can use as the basis for historical searches.
l Viewing Available Reports
l Using System-Defined Reports in Historical Searches
Viewing Available Reports
Tab Description
Summary Includes name, description, and all the criteria used in constructing the
historical search for the report
Any scheduled runs for the report. See Scheduling Reports for more
Schedule
information.
When your search runs, you will see both a Results List in the bottom pane of the screen, and a chart in the
middle pane. The types of charts that are displayed depend both on the data being analyzed, and whether or not
you have specified any Group By conditions in your search. You can also add dimensions to your search results
and change the chart display type for further analysis.
Non-aggregated searches are searches that don't use any Group By conditions to process the results. These
types of searches produce two views of the results:
Shows the
results of the
Results search based on
List the Search
Display fields
you selected
Aggregated searches are those that use a Group By condition to process the results.
Pie Chart Shows the proportion For any set of results where you are charting
for the COUNT Count (Matched Events), click the Pie
(Matched Events) Chart icon to view a proportional
attribute representation of the results.
Overview of Historical Search Results and Charts describes the charts that you can use to visualize historical
search results, but there are also a variety of methods you can use to drill down into search results and refine your
queries.
When your chart loads, the top five items are displayed as color-coded stack charts, as show in the example of
this screenshot. However, you may want to remove results from the chart to get a clearer view of what is
happening with a specific result. Here, for example, there are spikes for 192.168.19.65 that are clearly visible at
various intervals, but the chart results for the other IPs obscure much of what is happening with this source IP.
The solution is to remove the other Source IPs from the chart. In the Chart column of the Results List, click on
the items you want to remove from or add to the chart. In this example, all four of the other IPs have been
removed from the chart to obtain a clearer visualization of the activity for 192.168.19.65.
Charting Multiple Aggregation Attributes on the Same Historical Search Results Chart
When you run a query, the resulting chart typically displays the first aggregated attribute in the Results List.
However, if there are other aggregated attribute values in the search results, you can add those to the chart as a
second dimension.
This screenshot shows the results for the report Top Router Network Intf By Util, Error, Discards, which
includes the values for a single aggregated attribute, AVG(In Intf Util), for incoming interface utilization.
In this case, it could also be informative to understand more about the outbound interface utilization. In the
second Chart For menu, AVG(Out Intf Util) is selected, and this is added as a second dimension to the chart
beneath the 0 line, as shown in this screenshot.
When you run a search, the chart displays results for the time interval you set in your original query. However, you
can also drill down to 5 minute, 10 second, and 1 second time intervals for a closer inspection of the results.
1. Hover your mouse cursor over the result and time interval you want to drill down on until the information pop-up
appears, as shown in the first example screenshot.
2. Click to drill down and view the results for a 5 minute interval.
3. Follow the same process to drill down to the 10 second and one second intervals.
This series of screenshots illustrates starting from the original search results, and then drilling down to the 5
minute interval.
In this screenshot of search results you can see a small but sudden spike in the SUM(Total Bytes) for
Destination TCP/UDP Port 20756, which is represented by the color purple in the chart. In order to understand
what is happening in this time interval, you can select this port and the time period of interest, and use these as
filter criteria for a deeper investigation.
1. In the Results List, select the row containing the item of interest.
2. Click the Filter menu, and you will see the attributes of the selected item as filter options.
3. Select the attribute you want to use for your filter.
In this case, you would select Destination TCP/UDP Port = 20756.
Adding a Specific Attribute Value to a Filter
You can also click in the cell of the Results List that contains the attribute value you want to use in your
filter, and then select Add to Filter from the pop-up menu that appears when you hover your mouse
cursor over the attribute value.
8. Click in the Raw Event Log column for an event to view the event details.
See Selecting Attributes for Structured Searches, Display Fields, and Rules for more information on how to view
the attributes for reported events and add them to the display fields for your results.
There may be occasions when you want to be able to run and compare the results of multiple searches.
1. Run your first search.
2. In the upper-left corner of the search screen, click +.
A new tab will open up in the Analytics Window.
3. Run your second search in the new tab.
New Tabs for Drill-Down and Refined Searches
If you refine an existing search, zoom in on a time period, or use the time interval drill-down to examine search
results, new tabs are automatically generated for each level of drill down, and for each refined search. When you
select an attribute to use in a refined search, you can also select Add to Filter in New Tab from the Options
menu.
In the course of running an historical search, you may produce results that you want to examine in real time. For
example, suppose that an historical search shows that yesterday there was an excessive amount of outgoing
traffic from your home country or countries that you do business with. You may want to know if this same traffic
pattern is happening right now, in real time. You can answer this question from within the same historical search
that raised your suspicions.
Example
While using historical search, you may observe a pattern that you want to use as a rule so if the pattern recurs, it
will trigger an alert. For example, in an historical search you may notice excessive traffic going outside your
country or the countries you do business with. You can generate a rule to watch for this traffic pattern from within
the historical search.
These screenshots show the conditions and results for the example of an historical search for excessive outgoing
traffic.
Following this example, you may now want to create a rule that will send you an alert when a particular source
sends more than 1000 connections, or more that 5MB of traffic, in five minutes.
Procedure
1. In the historical search that you want to use as the basis for your rule, click Create Rule.
The Rule Editor will load, with most information for the rule auto-populated from the search. You can also read
the topics under Rules for more information about creating rules.
2. Enter a Rule Name and Description.
3. Set the Severity to associate with incidents generated by this rule.
4. Set the Incident Category to associate with incidents generated by this rule.
5. Set the number of seconds for the Time Window that this rule should apply to.
In the example of excessive outgoing traffic over a five minute period, this would be set to 300.
6. Under the Conditions, click the Edit icon for Filter_1.
You will see that all your filter conditions for the search have been populated into this sub pattern.
7. You can now edit the Filter and Aggregate conditions for your original search, or change the Group By conditions.
8. Click Save when you're done editing the rule.
This screenshot show editing the rule sub pattern Filter_1 from the original rule conditions, with the Aggregate
Conditions for COUNT(Matched Events) and SUM(Total Bytes) to 1000 and 5242880 to match the new alert
conditions from the example historical search, and the AND operator changed to OR.
The real time search interface is very similar to the interface for historical search, with the exception that real time
search doesn't have an option to set a search time period. As with historical search, you can also run simple or
structured search queries. The main difference between historical and real time search is that real time search
displays your results as they are occurring in your IT infrastructure, with a scrolling chart and summary of the
results.
When you use simple real time search, you enter a keyword to search for in the logs collected by FortiSIEM, set
any columns you want to display in the Raw Event Log Results Summary, and, for multi-tenant deployments,
select any organizations you want to filter the results for. You can then select results in the real time chart to use
for historical searches, or you can select results in the Raw Event Log Results Summary to learn more information
about them or use them as filters in refining your search.
This screenshot shows the results for searching the raw event logs for occurrences of TCP.
Ui Control Description
Filter Criteria For simple real time search, use the search box to find keywords in raw
event logs. You can also create a rule from your search results.
Set Summary
Select which columns will be displayed in the Raw Event Log Results
Display
Summary
Columns
Organizations For multi-tenant deployments, select which organizations you would like
Filter to filter the results for
Real Time Displays results as they occur in real time. Use the Pause, Fast
Chart Forward, Stop, and Clear buttons to control the display.
Raw Event Displays a summary of the raw event logs for your search results in real
Log Results time. Click Pause in the real time chart and then select an item in the
Summary summary results to view attributes such as Reporting and Destination
IP, add an IP address to a watch list, add an attribute as a search filter,
or get topological information about network devices. Selecting a result
from the summary list also enables the Filter, Quick Info, and
Locations buttons.
For structured real time search, you only enter the filter conditions that you want to use, instead of having to also
specify aggregation and group by conditions as you would in a structured historical search.
This screenshot shows the Conditions dialog for structured real time search. You can select attributes and
create expressions to use in structured real time search the same way you would in structured historical search.
This screenshot shows the Conditions dialog after having selected Structured in the search controls, with two
search conditions set.
Related Links
When your real time search runs, you will see the results represented as a scrolling chart across the top of the
search results window, and as a scrolling list in the bottom of the window that include the raw event log
information for events matching your search criteria. You can select items in the scrolling chart to use in historical
search, view more information about individual items in the results list, and add attributes from your search
results to your search filters or display fields.
1. When you see a time interval of events that you want to use for historical search appear in the scrolling chart, click
Pause or Stop.
2. Hover your mouse cursor over the bar that represents the time interval until you see the time interval information
appears, and then double-click on the bar.
3. The time interval and Event Type will be added to the criteria for an historical search.
Complete the other criteria you want to use for the search as described in Historical Search.
1. When you see an event appear in the search results list that you want more information about, click Pause or
Stop.
2. Select the event row and click Quick Info to view the Reporting IP, Event Type, Source IP, and Destination
IP for that event.
3. To view information about specific attributes of an event, click in the attribute display field and click Quick Info.
For attributes associated with devices, this will open the Quick Info view of the device as described Overview of
the Summary Dashboard User Interface. For events types, it will show info such as the severity and device
associated with the even type.
4. To view information about a device's location in the network topology, select it in the display field and then select
Topology.
l With a search result selected in the results list, click Filter to select event attributes to add to the search filter.
l In the expanded Raw Events Log, click on items in the text string to include or exclude them as search filter
criteria.
l To add a specific result to the search criteria, in the results list, click on an item in a display field to open the options
menu, and then select Add to Filter.
l To add an IP address to a watch list, click on it to open the options menu, and then select Add to Watch List.
See Watch Lists for more information.
l See the section on Selecting Attributes from the Raw Event Log Column in the Results Lists in the topic
Selecting Attributes for Structured Searches and Display Fields for information on how you can view and select the
attributes associated with events to use as search filters or display fields from the real time search results list.
IN, NOT IN Determines whether an All except DATE System Event Category IN (3,6)
attribute belongs or does type
not belong to a set of Event Type IN ("PH_DEV_MON_
values. For string valued Allows CMDB SYS_CPU_UTIL","PH_DEV_MON_
attributes, the match is Groups SYS_MEM_UTIL")
case insensitive.
Event Type IN ("PH_DEV_MON_
SYS_CPU_UTIL",Event
Types:Login Failure)
Source IP IN Devices:Windows,
Devices:Unix
Destination IP IN Networks:VPN
Pool
This documentation includes an Event Dictionary that describes events and their attributes, and an attribute
master list, which lists the primary event attributes and their data type, along with a brief description of what
values FortiSIEM expects to see when that attribute information is returned.
This screenshot shows the Common Attributes menu open in the Conditions Builder for an Historical search.
Open the menu by clicking the downward arrow next to an Attribute text field. You can scroll through the list of
event attributes to select the one you want, or begin typing an attribute name and the menu will sort based on
your entry.
You also have the option to browse all the attributes listed in the CMDB to find the one that you want. These two
screenshots show the CMDB attribute browser, which you can access by clicking ... next to the Attribute text
field.
The first screenshot illustrates browsing the CMDB attributes based on Device Type and Feature Type:
Availability, Change, Performance, Security, and All. In this example, Security has been selected for
Feature Type, and Cisco IOS has been selected for Device Type. This loads all the security attributes
associated with the Cisco IOS into the Attribute List.
The second screenshot illustrates browsing the CMDB Event Types to find an event attribute. In this example,
Cisco ASA is selected for Device Type. Clicking in the Event Type window opens an Event Browser for the
CMDB. Select any group in the browser, and you will see the event types within that group that are applicable to
the Device Type you selected.
Selecting Attributes from the Raw Events Log Column of the Results Lists
All real time search results lists include a Raw Event Log column, and you can add a a Raw Event Log column to
the list of results for historical searches. In addition to providing detailed information from the raw event logs, you
can also use this column to view all the attributes associated with a reported event and add them to the display
fields in your results list or to your filters for structured searches.
1. Cilck in the Raw Event Log column of your results list to collapse the view.
The raw event log text will collapse into an information icon with a blue +.
2. Click on the blue + icon to open the Event Details.
You will see the raw event log text and list of all the attributes associated with that event type.
3. Select Filter or Display to add an attribute to the search filters or display fields for that search.
4. Click X to close the Event Details window when you're done making your selections.
You can enter an expression manually, paste it in, or build it dynamically using the Expression Builder. If you use
the Expression Builder, you will have to enter parentheses or arithmetic operators in the expression.
You can access the Expression Builder by clicking the e icon next to the Attribute or Value field when creating a
structured search or rule.
This screenshot shows the Expression Builder open for creating a rule.
Creating Expressions
Adding a Function
To add a function to the expression, select it from the Add Function menu, and then click the + icon. The
available functions depend on whether you are are creating an expression to use as part of a filter condition for a
search or rule, or as part of the aggregation conditions for a rule.
When you select any type of function, the function and a set of parentheses will be added to the expression. If
you place your cursor within the parentheses and then open the Event Attribute menu, you will see event
attributes that are relevant for that function. For example, if you select COUNT as the function, (MATCHED
ITEMS) will automatically appear between the parentheses, and will be selected in the Event Attribute menu. If
you select a function like AVG for an aggregation condition, you will see options such as CPU UTIL and Apache
Uptime. If you select a function like HourOfDay for a filter condition, you will see options like Access Time and
Vulnerable Since. You can search through the options in either situation by beginning to type a keyword in the
Event Attribute menu. Selecting Attributes for Structured Searches, Display Fields, and Rules has more
information about ways to search for and select event attributes.
If you select HourOfDay or DayOfWeek for the function, the Event Attributes menu will contain date and time-
related event attributes, while if you select DeviceToCMDBAttr, it will contain device-related attributes.
Function Description
This screenshot shows the beginning of creating an expression to use as the Attribute in a condition for an
historical search. HourOfDay is selected as the Function, and Access Time is selected as the Event
Attribute.
You use these functions to perform operations on numerical event attributes such as Sent Bytes, Received
Bytes, CPU Utilization, or Memory Utilization.
Function Description
Function Description
Count
Count the number of distinct items returned
Distinct
STAT_AVG Statistical average. This function is used in conjunction with creating baseline
reports.
STAT_ Statistical standard deviation. This function is used in conjunction with creating
STDDEV baseline reports .
This screenshot shows the beginning of creating an expression to use as an aggregation condition in rule. Max is
selected as the Function, and CPU Util is selected as the Event Attribute.
l Keyword Operators
l Quotes and Backslash Characters in Search Terms
Keyword Operators
You can use the operators AND , OR, AND NOT between keywords. If you enter more than one keyword,
then AND is assumed as the operator between them. You can also use parentheses () to change the precedence
of the operators.
TCP 80 Finds all events with TCP and 80 in the event logs
TCP AND (80 OR 443) Finds all events with TCP and 80 or 40 in the event logs
TCP AND NOT 80 Finds all events with TCP but not 80
If the search string contains quotation marks or back-slash characters, you must escape them by prefixing them
with a backslash character. For example, if you wanted to search for [location]="United States" then
you would need to enter [location]=\"United States\" as your search string.
l Destination Country
l Destination City
l Destination State
Destination IP
l Destination Organization
l Destination Longitude
l Destination Latitude
l Reporting Country
l Reporting City
l Reporting State
Reporting IP
l Reporting Organization
l Reporting Longitude
l Reporting Latitude
You can use geolocation attributes in both real time and historical structured searches. For example, setting a
search attribute to Source Country != United States will remove all Source IPs with a geolocation of United
States from the search results.
This screenshot shows the results of using Source Country != United States and Event Severity = 1 as the
search criteria. The Source IP display field contains only IP addresses associated with countries other than the
United States, as indicated by the national flags next to each IP address in the Source IP column.
If you use a geolocation attribute such as Source Country as a Display Field or Group By condtion, then the
results will include name information for that attribute, rather than a national flag.
This screenshot shows the results of the same query used previously, but with Group By = Source Country.
If your search results contain geographic information, click the Locations button to view that information on a
map.
This screenshot shows the results for the first example query presented in a map. Clicking on a number in the
map will provide you with an overview of incidents for that location.
Related Links
Rules
FortiSIEM continuously monitors your IT infrastructure and provides you with information you can use to analyze
performance, availability, and security. There may also be situations in which you want to receive alerts when
exceptional, suspicious, or potential failure conditions arise. You can accomplish this by using rules that define
the conditions to watch out for, and which trigger an incident when those conditions arise. This incident will
appear on the Incident Summary dashboard, and you can also configure a notification policy that will send email
and SNMP alerts that the incident has occurred. FortiSIEM includes over 500 system-defined rules, which you
can see in Analytics > Rules, but you can also create your own rules as described in the topics in this section.
l Creating Rules
l Activating and Deactivating Rules
l Adding a Watch List to a Rule
l Cloning a Rule
l Running Historical Searches to Test Rule Sub Patterns
l Setting Rules for Event Dropping
l Setting Rules for Event Forwarding
l Setting Global and Per-Device Threshold Properties
l Using Geolocation Attributes in Rules
l Using Watch Lists as Conditions in Rules and Reports
l Viewing Rules
Creating Rules
FortiSIEM constantly monitors your IT infrastructure for events and collects information about them, but you can
also set rules that will trigger incidents from events and send notifications when they occur. These topics describe
the concepts and processes for creating rules.
l Creating a Rule
l Defining Rule Conditions
l Defining the Incident Generated by a Rule
l Defining Rule Exceptions
l Defining Clear Conditions
l Testing a Rule
Creating a Rule
Creating a new rule involves defining the attributes of the incident that is triggered by the rule, as well as the
triggering conditions and any exceptions or clear conditions.
Restriction on names
Do not use certain keywords in subpattern names
l regexp
1. Log in to your Supervisor node.
2. Go to Analytics > Rules.
3. Select the group where you want to add the new rule.
4. Click New.
5. Enter a Rule Name and Description.
6. For Status, keep the rule Inactive.
You can activate the rule after you're finished creating and testing it.
7. Select an Incident Category for the incident triggered by the rule.
You can click Add and enter a custom incident category.
8. Select a Severity to associate with the incident triggered by the rule.
9. Select Update the Perf Status column on summary dashboard if you want the incident to display in the
Performance Status column of the Exec Summary dashboard.
10. For Attributes, enter the functional area, such as Security, that you want to associate the rule with.
11. Enter a Notification Frequency for how often you want notifications to be sent when an incident is triggered by
this rule.
12. Under Conditions, click Add Subpattern to create the rule conditions.
See Defining Rule Conditions for detailed information on selecting event and aggregation attributes to use with
rules. You can also see examples of rules with a single subpattern and multiple sub patterns.
13. Enter the time interval during which the rule conditions will apply.
The minimal interval is 120 seconds.
14. Next to Actions, click Edit to define the incident that will be generated by this rule.
See Defining the Incident Generated by a Rule for more information.
One Incident Definition Required to Save: You must have at least one incident defined before you
can save your rule.
15. Next to Watch Lists, click Edit to add a watch list to the rule.
See Adding a Watch List to a Rule for more information.
16. If you want to define any Exceptions for the rule, click Edit.
See Defining Rule Exceptions for more information.
17. If you want to define any Clear Conditions for the rule, click Edit.
See Defining Clear Conditions for more information.
18. Click Save.
Your new rule will be saved to the group you selected in an inactive state. Before you activate the rule, you should
test it.
Rule conditions define the event attributes and thresholds that will trigger an incident. Rule conditions are built
from sub-patterns of event attribute filters and aggregation functions. You can specify more than one subpattern
and the relationships and constraints between them.
l Specifying a Subpattern
l Setting the Relationship between Subpatterns
l Setting Inter-subpattern Constraints
Specifying a Subpattern
A subpattern defines the characteristics of events that will cause a rule to trigger an incident. A subpattern
involves defining event attributes that will be monitored, and then defining the threshold values for aggregations
of event attributes that will trigger an incident.
Event Filters
Event filter criteria determine which event attributes and values will be monitored by the rule, and are set in a way
that is similar to the way you set event attributes for structured historical searches and real time
searches. See Selecting Attributes for Structured Searches, Display Fields, and Rules for more information on
finding attributes to use in your event filters.
Event Aggregation
While you could have a rule that triggers an incident on a single instance of a particular event, it is more likely that
you will want your rule to trigger an incident when some number of events have been found that meet your event
filter criteria.
Group By Attributes
This determines which event attributes will be used to group the events before the group constraints are applied,
in a way that is similar to the way the Group By attribute is used to aggregate the results of structured searches.
Aggregate Conditions
The group aggregation conditions set the threshold at which some aggregation of events will trigger a rule to
create an incident. You create an aggregation condition by using the Expression Builder to set a function, and
then enter the Operator and Value for the aggregation condition.
Connections to 100 or more Source IP,Destination COUNT (DISTINCT destination IP) >= 100
distinct destination IPs from Port
the same source IP on the
same destination port
Logins from the same source Source IP, Destination COUNT(DISTINCT user) >= 5
workstation to 5 or more IP
accounts on the same target
server
Operator Meaning
You may want to relate attributes of a sub-pattern to the corresponding attributes of another sub-pattern, in a way
that is similar to a JOIN operation in an SQL, by using the relationship operators <, >, <=, >=, =, !=.
Sub- P1 - P1 Inter-P1-
Sub- P2- Inter-P1-P2
pattern Group-by Group P2 group P2
Scenario pattern group-by relationshi
P1 - attribute constrai constraint constrain
P2 filter attribute ps
filter set nt ts
Sub- P1 - P1 Inter-P1-
Sub- P2- Inter-P1-P2
pattern Group-by Group P2 group P2
Scenario pattern group-by relationshi
P1 - attribute constrai constraint constrain
P2 filter attribute ps
filter set nt ts
An security
attack to a
server
followed by
the server
scanning
the
network, Event COUNT
P1's
that is, COUNT Type = (DISTINC
Event P1 Destinati
attempting (Matche Connecti T
type = Destinati Source IP FOLLOWE on IP =
to d Event) on Destinatio
Attack on IP D_BY P2 P2's
communica >0 Attempte n IP) >
Source IP
te to 100 d 100
distinct
destination
IP
addresses
in 5 minute
time
windows
This topic shows an example of how to create a rule with a single sub-pattern based on the condition that Average
CPU on a server is more than 95% over 3 sample measurements.
Group By
Attribute Aggregate Conditions
Attribute
Option Setting
Operator >=
Value 95
9. Under Aggregate Conditions, click the Expression Builder icon next to the Attribute field, select COUNT
(Matched Events) from the Add Function menu, and then click OK.
10. Under Aggregate Conditions, select = for Operator and enter 3 for Value.
11. Under Group By, select Host IP.
12. Click Save.
13. Enter 5 for the time interval during which the conditions will apply.
14. You would now complete the rule by Defining the Incident Generated by a Rule, and any exceptions or clear
conditions. You could also associate it with a notification policy.
This screenshot shows the subpattern settings for this example.
The following steps describe how to create a rule that matches the above example 1:
1. Enter a name for the rule in the 'Rule Name' text box.
2. Enter a description for the rule in the 'Description' text box.
3. Use the drop down menu to choose a 'Severity' for the rule.
4. Click on the '+ Add Condition' button.
a. Chose the 'Function' for the rule. In this case 'AVG' is chosen.
b. Choose the 'Attribute' for the rule. In this case 'CPU Util' is chosen.
c. Chose the 'Operator' for the rule. In this case '>=' is chosen.
d. Enter the 'Value' for the rule. In this case '95' is entered.
5. Select the devices to apply the rule to.
6. Enter the number of events that must occur for the rule to fire. In this case '3' is used.
7. Enter the time frame for the rule. In this case '600' seconds is used.
This topic provides an example of a rule with two sub-patterns, and also how to use the Event Type attribute as a
filter.
l Rule Conditions
l Creating Sub-Pattern P1
l Creating Sub-Pattern P2
l Defining the Relationship Between Patterns
l Defining the Incident to be Generated by the Rule
Rule Conditions
The purpose of this rule is to trigger an incident when five login failures from the same source to a server are not
followed by a successful login from the same source to the same server within one hour. This requires two sub-
patterns, the first one to detect "five login failures from the same source to a server," and a second one to detect
"a successful logon from the same source to the same server." The two sub-patterns need to be interrelated to
make the complete rule.
Sub-pattern 1 (P1)
Sub-pattern 2 (P2)
Group By Aggregate
Event Filter Attribute
Attributes Conditions
Interrelationships Constraints
P1 NOT_
P1's Source IP = P2's Source IP, P1's Destination IP =
FOLLOWED_BY
P2's Destination IP
P2
Creating Sub-Pattern P1
The following steps describe how to create a rule that matches the above example 2:
1. Log in to your Supervisor node.
2. Go to Analytics > Rules.
3. Click New.
4. For Rule Name, enter Suspicious Login Failure.
5. For Description, enter the rule conditions stated in the introduction to this topic.
6. For Severity, select 10 - High.
7. For Attributes, select All.
8. Next to Conditions, click Add Subpattern. You will now create the first subpattern for "five login failures from
the same source to a server.".
9. For Subpattern Name, enter LogonFailures.
To create this sub pattern you will want to specify that all types of logon failures should be monitored. For this
reason, you will want to specify an entire folder of event types as the rule condition, rather than a single attribute
of a event.
10. For Attribute, select Event Type.
11. For Operator, select IN.
12. For Value, click ... to open the CMDB Browser.
13. In the CMDB Browser, go to Event Types > Security > Logon Failure, and click Folder >> to select the
Logon Failure events group.
Your filter condition, as shown in the screenshot, can be read as "For any type of event in the Logon Failure event
group . . ."
14. Under Aggregate Conditions, click the Expression Builder icon next to Attribute and select COUNT(Matched
Events).
15. For Operator, enter >=.
16. For Value, enter 5.
17. Under Group By, enter Source IP for Attribute, and then click + to add another Group By attribute.
18. Enter Destination IP.
19. Click Save.
This screenshot shows the complete entry for sub-pattern P1.
Creating Sub-Pattern P2
1. In your rule, next to Conditions, click Add Subpattern.
1. Makes sure that LogonFailures is selected as the first pattern under If this Pattern occurs, and under Next
Op, select NOT_FOLLOWED_BY.
2. Select LoginSuccess as the second subpattern.
3. Click AddSubpattern Relationship.
4. For the first relationship definition, select LogonFailures for Subpattern, Source IP for Attribute, and = for
Operator.
5. For the second subpattern, select LogonSuccess for Subpattern, Source IP for Attribute, and AND for Next
Op.
6. Under Row, click +.
7. For the second relationship definition, for the first subpattern, select LogonFailure for Subpattern, Destination
IP for Attribute, and = for Operator.
8. For the second subpattern, select LogonSuccess for Subpattern, and Destination IP for Attribute.
6. Under Triggered Event Attributes, make sure that Event Receive Time, Event Type, Reporting IP, and
Raw Event Log are listed in the Selected Attributes.
7. Click OK.
Defining an incident involves setting attributes for the incident based on the subpatterns you created as
conditions for the rule, and then setting attributes for the incident that will be used in analytics and reports.
You must have at least one incident defined before you can save your rule.
1. In the rule you want to define an incident for, click Edit next to Actions: Generate Incident.
2. Enter an Incident Name, Display Name, and Description.
3. Under Incident Attributes, you will define attributes for the incident based on the Group By and Aggregate
Conditions attributes you set for your sub patterns. Typically you will set the Incident attributes to be the same as
the Group by attributes in the subpattern.
a. Select the Event Attribute you want to add to Incident.
b. Select a Subpattern.
c. This will populate values from the Group By attributes in the subpattern to the Filter Attribute menu.
d. In the Filter menu, select the attribute you want to set as equivalent to the Event Attribute.
Incident Definition Settings for the Single Subpattern Example
In the single sub pattern example, Pattern1 has the Group By attribute set to Host IP, and
the Aggregate Conditions attribute set to COUNT(Matched Events). You can then select
these to set as the incident attributes as shown in this screenshot.
4. Under Triggered Event Attributes, select the attributes from the triggering events that you want to include in
dashboards and analytics for this event.
This is pre-populated with typical attributes you would want included in an incident report.
5. Click OK.
Once you activate a rule, it continuously monitors your IT infrastructure for conditions that would trigger an event.
However, you may also want to define exceptions to those conditions. For example, you may know that a server
will be going down for maintenance during a specific time period and you don't want your Server Down - No
Ping Response rule to trigger an incident for it.
1. In Analytics > Rules, select the rule you want to add the exception to, and click Edit.
2. Next to Exceptions, click Edit.
3. Select an Attribute and Operator, and enter a Value, for the conditions that will prevent an incident from being
generated.
The values in the Attribute menu are from the Event Attributes associated with the incident definition.
4. Click the + icon to set an effective time period for the exception.
You can set effective time periods for single and recurring events, and for durations of time from hours to days.
5. Enter any Notes about the exception.
6. Click OK.
Clear conditions specify conditions in which incidents will have their status changed from Active to Cleared. You
can set the time period that must elapse for the clear condition to occur, and then set the conditions based on the
triggering of the original rule, or on a sub pattern based on the Incident Attributes.
1. In Analytics > Rules, select the rule you want to add the clear condition to, and click Edit.
2. Next to Clear Condition, click Edit.
3. Set the Time Period that should elapse for the clear condition to go into effect.
4. If you want the clear condition to go into effect based on the firing of the original rule, select the Original Rule
Does Not Trigger.
For example, if you wanted the clear condition to change the status of Active incidents to Cleared after the
original rule had not been triggered for ten minutes, you would set Cleared Within to 10 Minutes and select this
option.
5. If you want to base the clear condition on a sub-pattern of the incident attributes, select the following
conditions are met.
The incident attributes from your rule will load and the clear condition attributes will be set to match.
6. Define the pattern to use by clicking the Edit icon next to the clear sub pattern.
7. Click Save.
This screenshot shows the exception condition settings for the example of a rule with a single subpattern. In the
original rule, an incident was generated if there were three events over 10 seconds where Avg CPU Util
exceeded 95% on a single host. In this example, those incidents will change status from from Active to Cleared
if there are three events over 10 seconds where Avg CPU Util is under 100%.
Testing a Rule
After you've created or a edited a rule, you should test it to see if behave as expected before you activate it. This
topic describes how to test a rule using synthetic events.
l Procedure
l Test Results
l Test Example
l Troubleshooting for Rule Testing
Procedure
1. Go to Analytics > Rules, and deactivate the rule you want to test.
Cloning Active Rules for Testing: You cannot test an active rule. If you can't deactivate a rule for
testing, you can clone an inactive version of it.
4. Under Raw Event, enter the raw event log text that contains the triggering conditions for the rule.
5. Under Pause, enter the number of seconds before the next test event will be sent, and then click + under Action
to enter additional test events.
You will need to create as many events as are necessary to trigger the rule conditions.
6. Click Run Test.
If the test succeeds you are now ready to activate the rule.
Test Results
The test will run through a four stage process, which you can observe in the Test Results tab of the rule. A yellow
icon will also appear in the Status column for the rule to indicate that the test is running.
1. Rules are checked for syntax errors.
2. Events are parsed and sent to Rule Workers.
If there are errors in the rule syntax or event parsing errors, see the examples under Troubleshooting for Rule
Testing for suggestions on how to correct them. As events are being parsed, you can view their Event Details by
clicking on the Raw Event Log icon next to the event.
3. Rule Worker nodes evaluate the events against the rule conditions, and if they match, they are sent to the Rule
Master.
4. The Rule Master creates incidents, which then appear in the Incidents dashboards.
When the test successfully completes, a green icon will appear in the Status column next to the rule name.
Test Example
This screenshot shows the example of a test for the rule Multiple Admin Login Failures: Net Devices. The
conditions for this rule are that the the Reporting IP must belong to a network device, and there must be 3 login
failure events from the same IP and user.
If the test fails, a red icon will appear under the Status column next to the rule name, and you will see the error
message in the Test Results tab for the rule.
This means that the conditions of the rule were not met by the event. For example, if five events were required to
meet the condition, but only one was sent.
This means that some text in the raw event log did not pass the event parser. For example, if "denied" is the term
expected by the parser in the test example, but the raw event log contains the term "deny," then the event will not
pass the parser.
For Service Provider deployments you can activate or deactivate rules for individual organizations, and also set
default rules for all organizations.
1. Navigate to the rule that you want to activate, deactivate, or set as default.
2. In the Summary tab of the rule, click Edit.
3. Next to Status, click Edit.
4. To set this rule as a default rule for all organizations, select Activation Default.
5. Select an organization to activate the rule for, or clear its selection to deactivate the rule.
6. Click OK.
7. Click Save.
Cloning a Rule
You can clone a rule to use it as the basis for creating another rule, or to use in testing.
1. Log in to your Supervisor node.
2. Go to Analytics > Rules.
3. Search or browse to select the rule you want to clone.
4. Click Clone.
5. Enter a new name for the cloned rule and click OK.
The cloned rule will be added to the same group as the original rule but will be inactive.
If the search includes results that you want to share or investigate further, you can save the rule as a report.
Procedure
Notes
l All matching rules are implemented by FortiSIEM, and inter-rule order is not important. If you create a duplicate of
an event dropping rule, the first rule is in effect.
l If you leave a rule definition field blank, then that field is not evaluated. For example, leaving Event Type left blank
is the same as selecting All Event Types.
l FortiSIEM drops the event at the first entry point. If your deployment uses Collectors, events are dropped by the
Collectors. If your deployment doesn't use Collectors, then the event will be droppedby the Worker or Supervisor
where the event is received.
l You can use the report System Event Processing Statistics to view the statistics for dropped events. When
you run the report, select AVG(Policy Dropped Event Rate(/sec) as one of the dimensions for Chart For to see
events that have been dropped to this policy.
If you want the same sender IP to forward events to multiple destinations, create a rule for each destination.
FortiSIEM will implement all rules that you create and enable, so if you create a duplicate of an event forwarding
rule, two copies of the same log will be sent to the destination IP.
Overview
In many cases when you create a rule, you set values for device thresholds that should trigger an incident. The
example of a rule with a single sub-pattern, for example, contains a condition where if the average CPU utilization
of a server exceeds 95% over 3 samples, an incident should be triggered. This is an example of setting an
absolute value for the threshold in the rule itself.
Instead of setting an absolute value for the threshold, you can define global threshold properties that you can use
as functions within a rule, and also define these threshold properties on a per-device basis. The advantage
of this approach is that if you want to change the threshold values in a rule, you can edit the threshold property,
rather than having to edit the rule. This is accomplished by using the DeviceToCMDBAttr function to return the
value set for that device in the rule.
This table illustrates the difference between using an absolute value, shown in the first column, and threshold
property, shown in the second column, in the aggregation conditions for a rule. For the threshold property, the
function takes the form of DeviceToCMDBAttr(Host IP, Threshold Property), while it takes the form
of DeviceToCMDBAttr(Host IP, Component, Threshold) for devices with components as shown in the
second example.
Server CPU AVG(CPU Utilization) > 95 AVG(CPU Utilization) > DeviceToCMDBAttr (Host
Critical IP,Server CPU Util Critical Threshold)
Server Disk
AVG(Disk Utilization) > DeviceToCMDBAttr(Host
Space AVG(Disk Utilization) > 99
IP,Disk Name,Disk Space Util Critical Threshold)
Critical
In the first example, when the rule evaluates the function, the Server CPU Critical rule will return the value of
Server CPU Util Critical Threshold for the host IP if that has been defined for the reporting device, otherwise
the global threshold value will return. In the second example, i f the Disk Space Util Critical Threshold is
defined for a (Host IP,Disk Name) tuple, then the function returns that value, otherwise the global threshold value
returns. This is an example of a Map threshold, in which there is one threshold value for each component, and
which apply only to disk and interface components.
FortiSIEM includes over 30+ pre-defined global threshold properties that you can edit and use in rules, but you
can also create custom threshold properties.
3. Click Add.
4. Enter a Name and Display Name for the new threshold property.
5. Enter the Default Value for the threshold.
6. Select the Type of threshold value.
For most global threshold values you will select Double. For Map thresholds, which apply to disks and interfaces,
select the Item Type for the threshold value, and then select the Component Type to which it applies.
7. Click Save.
Using the example of the Server CPU Critical rule, you would use the DeviceToCMDB function to set a threshold
for the aggregation conditions of the rule in this way:
1. In the sub pattern of the rule, under Aggregation Conditions, click the expression builder icon next to the
Attribute field.
2. In the expression builder, under Add Function, select AVG.
3. In the Add Event Attribute field, select CPU Utilization.
4. Click OK.
The expression builder will close, and you will see the function and event attribute you selected listed as the
Attribute for the Aggregate Conditions.
5. For Operator, select =.
6. Click the expression builder icon next to the Value field.
7. In the Add Function menu, select DeviceToCMDBAttr.
8. In the Select Function Pattern dialog, select DeviceToCMDBAttr(EventAttr,CMDBAttr).
9. Under Add Event Attribute, select Host IP.
10. Under Add CMDB Attribute, select Server CPU Util Critical Threshold.
11. Click OK.
12. Click Save.
Viewing Rules
FortiSIEM includes a large set of rules for Availability, Performance, Change, and Security incidents in addition to
the rules that you can define for your system.
Summary This tab provides an overview of the rule's logic, its status, and its notification
settings.
An XML definition of the rule. This is what will be copied to your clipboard if
Definition
you Export a rule.
Test Results If you are testing a rule, you can view the results here.
Reports
You can think of reports as saved or pre-defined versions of searches that you can load and run at any time.
FortiSIEM includes over 2000 pre-defined reports that you can access in Analytics > Reports. Topics in this
section describe how to access and view information about reports, how to create baseline reports, and how to
use specialized reports like the Identity and Location report. You can refine the results of your reports in the
same way that you would refine the results of an historical search or a real time search.
l Baseline Reports
l Creating a Report or Baseline Report
l Identity and Location Report
l Report Bundles
l Running System and User-Defined Reports and Baseline Reports
l Scheduling Reports
l Viewing Available Reports
Baseline Reports
l How FortiSIEM Sets Baselines
l Evaluating Rules and Detecting Deviations
When you are setting up FortiSIEM to monitor your IT infrastructure, you may want to define what is "normal"
activity within your systems, and have incidents triggered when a a deviation from that normal activity occurs. For
example, you can always assume that there will be some logon failures to a server on a daily basis. Rather than
creating a rule that will trigger an incident when a certain hard-coded number of failures occurs, you can set up
baseline reports that will trigger an incident when the total number of logon failures over a time period is twice the
average over the same time period, or when the deviation from the average is threee times the standard
deviation over a specific time period.
By creating a baseline report, you can set mean and standard deviations for any metric and use them in rule, and
FortiSIEM will evaluate the current monitored values against the mean and standard deviation for that time
period.
Establishing a baseline means recognizing that data center resource usage is time dependent:
l Usage is different during weekdays and weekends, and may also be different depending on the day of the week or
month
l Usage is dramatically higher during business hours, typically 8am-5pm
FortiSIEM maintains distinct baselines for weekdays, weekends and for each hour of day - a total of 24*2 = 48
buckets. Baselines for days of the week or month are not maintained to save memory usage, as this would
require 31*24 = 1764 buckets, a 15 fold-increase of memory.
A baseline report is a set of Keys that represent the baselined metrics, and a collection of Values. You can see
examples of these Keys and Values in the System-Defined Baseline Reports. These are then used in this process
to build the report:
1. During the current hour, the Supervisor and any Worker nodes operate in parallel to save a baseline report in
memory by analyzing the report events as a stream.
2. When the hour finishes:
1. The report is written to disk (on NFS for FortiSIEM cluster).
2. The Supervisor module summarizes individual baseline reports from all nodes and forms the baseline for
the current hour.
3. The baselines are stored in a SQLite database on a local Supervisor.
4. The Supervisor module reads the previous baseline for the current time interval from the SQLite
database. Then it combines the previous values with the current values to create a new baseline.
5. The new baseline is then stored in SQLite database.
3. For the new hour, a new baseline is created following this process
As this process illustrates, baselining is continuous in FortiSIEM, and new baseline values are learned adaptively.
A baseline rule contains expressions that involve using the functions STAT_AVG() and STAT_STDDEV() to set
dynamic thresholds.
These examples show how STAT_AVG() and STAT_STDDEV() would be used to evaluate the conditions for
the example of logon failures in the introduction to this topic.
Two sample points are needed to avoid premature triggering of a rule before a baseline is set and becomes
active.
l If the first data is received for a subject on Monday, then the rules will start triggering for that subject for that
baseline starting Wednesday
l If the first data is received for a subject on Saturday, then the rules will start triggering for that subject for that
baseline starting next Saturday
l Logon Activity
DNS Request This report baselines DNS 113 Key: Source IP Values: Number of Requests,
Profile requests on a per client basis: Distinct Destination Count - means and
the number of requests and standard deviation for each
distinct destinations it
attempted to resolve
Destination Traffic This report baselines traffic 126 Key: Destination IP Values: Distinct Source IP,
Profile destined to a server. The data Distinct Destination Ports, Total Flows - mean
is reported by network flow and standard deviation for each
(Netflow, Sflow) and firewall
logs. For each destination IP,
the number of distinct peers,
the number of distinct ports
opened on the server and the
total number of flows are
tracked.
Firewall Connection This report provides baseline 112 Key: Firewall Name, Firewall IP Values:
Count Profile of permitted firewall Firewall Connection Count - mean and
connection count typically standard deviation for each
gathered by SNMP.
ICMP Traffic Profile This report baselines 114 Key: Source IP Values: Distinct Destinations,
generated ICMP traffic by Total Flows, Total Bytes - mean and standard
each source: number of ICMP deviation for each
packets and number of
distinct destinations
Inbound This report provides baseline 104 Key: Destination Protocol, Port Values: Distinct
Firewall of permitted inbound Source IP, Distinct Destination IP, Total Flows,
PermittedTCP/UDP TCP/UDP port usage. The Total Bytes - mean and standard deviation for
Port Usage Profile data is reported by firewall each
logs. For every inbound
destination port and protocol
combination, the total
number of unique sources,
destinations and the total
bytes and flows are profiled
Outbound This report provides baseline 105 Key: Destination Protocol, Port Values: Distinct
Firewall of permitted inbound Source IP, Distinct Destination IP, Total Flows,
PermittedTCP/UDP TCP/UDP port usage. The Total Bytes - mean and standard deviation for
Port Usage Profile data is reported by firewall each
logs. For every inbound
destination port and protocol
combination, the total
number of unique sources,
destinations and the total
bytes and flows are profiled
Device CPU, This report provides baselines 109 Key: Host Name Values: CPU Utilization,
Memory Usage cpu, memory usage - the data is Memory Utilization, Virtual Memory Utilization
Profile collected by SNMP or WMI. For - mean and standard deviation for each
every host, CPU, real and virtual
memory utilization are profiled
Network This report provides baselines 110 Key: Host Name, Interface name Values:
Interface Traffic network interface traffic. The data Sent Bytes, Received Bytes - mean and
Profile is collected by SNMP. For each standard deviation for each
network interface, the total sent
and received bytes are profiled.
Server Process This report baselines the number 123 Key: Host name Values: Process Count -
Count profile of processes running at a server. mean and standard deviation
The data is collected by SNMP.
Reported Event This report provides baselines for 119 Key: Host Name, Host IP Values: Distinct
Type Profile distinct event types reported by a Event Type - mean and standard deviation
device.
STM Response This report baselines Synthetic 123 Key: Host Name, Monitor Name Values:
Time Profile Transaction Monitoring response Response Time - mean and standard
times deviation
Logon Activity
Successful This report baseline successful log 115 Key: Host Name, Host IP Values: Successful
Logon Profile on activity at a host. The data is Logons, Distinct Source IP, Distinct Users -
collected from logs. mean and standard deviation
This report baseline failed log on Key: Host Name, Host IP Values: Failed
Failed Logon
activity at a host. The data is Logons, Distinct Source IP, Distinct Users -
Profile
collected from logs. mean and standard deviation
Privileged This report baseline successful log 118 Key: Host Name, Host IP Values: Privileged
Logon Profile on activity at a host. The data is Logons - mean and standard deviation
collected from logs.
Cloning an Existing Rule: You can clone an existing rule to use as the basis for a new rule by
selecting the existing rule, and then click Clone.
1. Log in to your Supervisor node.
2. Go to Analytics > Reports, and select the category for your new report.
Select Baseline for baseline reports.
3. Click New.
4. Enter a report Name and Description.
5. For baseline reports, select Anomaly Detection Baseline.
6. Enter the Conditions to use in your report.
See Selecting Attributes for Structured Searches, Display Fields, and Rules and Using Expressions in Structured
Searches and Rules for more information on setting conditions. For creating baseline reports, see Baseline
Reports for information on how to use the STAT_AVG and STAT_STDDEV functions in creating expressions for
baseline reports.
7. Select the Group By attribute to use in processing the search results.
The topic Example of How a Structured Historical Search is Processed explains how the Group By attribute is used
in search results.
8. Set the Display Fields to use in your search results.
See Selecting Attributes for Structured Searches, Display Fields, and Rules for more information on using event
attributes in display fields.
9. Click Save.
Your report will be saved into the selected category, and you can now run it or schedule it to run later.
Related Links
Overview
The Identity and Location report is constructed by associating a network identity like an IP address, or MAC
address, to a user identity like a user name, computer name, or domain, and tying that to a location, like a wired
switch port, a wireless LAN controller, or VPN gateway. When any element of these associations changes, a new
entry is created in the report.
The associations between IP addresses, users, and locations are obtained by combining Windows Active
Directory events, DHCP events, and WLAN and VPN logon events, with discovery results to produce a report
combining all of this information into a comprehensive listing of users and machines by their identity and location.
IP Address IP adress of a host whose identity and location is recorded in this result. You can view IP
addresses with country flags in a map by clicking Locations.
User User associated with this IP Address. Obtained from one of these event types:
Windows Domain Logon, WLAN Login, VPN Logon, AAA Authentication. See
the section on Report Information and Event Types on this topic for more information.
Obtained from the Windows Domain Logon and WLAN Authentication event
Host Name
types.
Domain Information displayed here depends on the logon event type it was obtained from:
l Windows Domain Logon: the Domain name
l VPN Logon: the reporting IP address of the VPN gateway
l WLAN Logon: the reporting IP address of the WLAN controller
l AAA Logon: the reporting IP of the AAA server
VLAN ID For hosts directly attached to a switch, this is the VLAN ID of the switch port
Location For h osts attached to a switch port, this is the switch name, reporting IP address, and
interface name
The time at which this entry was first created in the FortiSIEM Identity and Location
First Seen
table
Last Seen The time at which some attribute of this entry was last updated. If there is a conflict, for
example a host acquiring a new IP address because of DHCP, then the original entry is
closed and a new entry is created. A closed entry will never be updated.
This table lists the events and event types that contribute to information in the Identity and Location Report, as
well as what information is collected for each type of event.
DHCP x x l WIN-DHCP-IP-LEASE-
Renew RENEW
Events
l WIN-DHCP-IP-
ASSIGN
l Linux_DHCPACK
l Generic_DHCPACK
x
AD (resolvabl
Successful e by DNS x (if in l Win-Security-540
x x
Login or in Event) l Win-Security-4624
Events FortiSIEM
CMDB)
AAA x x x l Win-IAS-PassedAuth
Successful
Login
l CisACS_01_
Events PassedAuth
l Cisco-VPN3K-IKE/25
VPN l ASA-722022
Successful
x x x l ASA-713228
Login
Events l ASA-713049-Client-
VPN-Logon-success
l PH_DISCOV_CISCO_
x (if WLAN_HOST_
WLAN
in x (if in LOCATION
Discover x x
Even Event) l PH_DISCOV_ARUBA_
y Events
t) WLAN_HOST_
LOCATION
x (if
resolvabl
FortiSIE e by
M L2 DNS or l PH_DISCOV_HOST_
x x x x
discovery in LOCATION
Events FortiSIE
M
CMDB)
There may be a situation in which a new event type is added to FortiSIEM, and you want to use the parsed
attributes of that event in the Identity and Location report. Once you have made sure that the event will parse
correctly, you will need to edit the identityDef.xml file for your Supervisor and any Worker nodes in your
deployment.
1. Log in to your Supervisor host machine as admin.
2. Change the directory to /opt/phoenix/config/xml.
3. Logon to FortiSIEM Super as admin
4. Edit the identityDef.xml file:
1. Create a new <identityEvent>.
2. For <eventType>, enter the ID of the event containing the identity attribute.
3. For <eventAttributes>, enter the name of the event attribute and its corresponding identity
attribute. For reqd, enter yes if the event must have this event attribute for use in the identity and
location report.
Possible location attributes include:
l ipAddr
l macAddr
l computerName
l domain
l domainUser
l aaaUser
l vpnUser
l geoCountry
l geoState
l geoCity
l geoLatitude
l vlanId
l netEntryPt
l netEntryPort
2. Restart identityMaster and identityWorker
3. Repeat for any Worker nodes.
This code sample is an example of a new <identityEvent> entry in the identityDef.xml file
<identityEvent> <eventType>PH_DISCOV_CISCO_WLAN_HOST_LOCATION,PH_DISCOV_ARUBA_
WLAN_HOST_LOCATION</eventType> <eventAttributes> <eventAttribute name-
e="hostIpAddr" identityAttrib="ipAddr" reqd="no"/> <eventAttribute name-
e="hostMACAddr" identityAttrib="macAddr" reqd="no"/> <eventAttribute
name="user" identityAttrib="domainUser" reqd="no"/> <eventAttribute name-
e="domain" identityAttrib="domain" reqd="no"/> <eventAttribute name-
e="nepDevName" identityAttrib="netEntryPtName" reqd="yes"/> <eventAttribute
name="nepDevIpAddr" identityAttrib="netEntryPt" reqd="yes"/> <eventAt-
tribute name="nepDevPort" identityAttrib="netEntryPort" reqd="yes"/>
<eventAttribute name="wlanContrIpAddr" identityAttrib="wlanContrIpAddr" reqd-
d="yes"/> <eventAttribute name="wlanContrHostName" iden-
tityAttrib="wlanContrHostName" reqd="yes"/> <eventAttribute
name="hostGeoCountry" identityAttrib="geoCountry" reqd="no"/> <eventAt-
tribute name="hostGeoState" identityAttrib="geoState" reqd="no"/> <eventAt-
tribute name="hostGeoCity" identityAttrib="geoCity" reqd="no"/>
<eventAttribute name="hostGeoLatitude" identityAttrib="geoLatitude" reqd="no"/>
<eventAttribute name="hostGeoLongitude" identityAttrib="geoLongitude" reqd-
d="no"/> </eventAttributes> </identityEvent>
Report Bundles
Report bundles are groups of reports for common IT infrastructure analytics, such as Windows Server Health.
Be defining a bundle and placing reports into it, you can run all the reports at the same time, and apply the same
filter conditions to all reports. You can view system and user-defined report bundles under Analytics > Report
Bundles.
l Creating a Report Bundle
l Running a Report Bundle
Creating a report bundle involves naming and describing the bundle, adding reports to the bundle, and then
setting what you want to include in the report results.
1. Log in to your Supervisor node.
2. Go to Analytics > Reports > Report Bundles.
3. Click the + icon at the top of the Analytics navigation pane.
4. For Group, enter the name of the bundle, and then enter a Description.
5. Under Select Group Members, select the report category that contains the report you want to add to the bundle.
When you select a category, all the reports in that category will be added to the selection window.
6. Select a report and use the >> button to add it to the bundle.
7. Select Show Table if you want all reports to include tables by default.
You can set individual reports to show tables by selecting the report under Show Reports, clicking Edit, and then
selecting Show Table.
8. Enter the number of Rows per Table.
9. Click OK.
This screenshot shows the UI controls for working with report bundles.
Related Links
l Scheduling Reports
l Using Search Results to Refine Historical Searches
l System-Defined Baseline Reports
l Overview of Historical Search Results and Charts
l Using the Analysis Menu
l Using Geolocation Attributes in Rules
l Refining the Results from Historical Search
Scheduling Reports
You can schedule reports to run once or on recurring periods in the future. When the test runs, the results will be
saved to the Results tab for the report, and in Analytics > Generated Reports.
Prerequisites
l When you schedule a report, you can specify notifications that should be sent for that report. In addition, you should
make sure that the default settings for notifications for all scheduled reports have been set up.
Procedure
11. Specify the amount of time the report should be retained after it has run.
12. Click OK.
The report will run at the time you scheduled.
Related Links
Summary Includes the Filter and Group By conditions for the report, and the report's Display
attributes
Information about when the report is scheduled to run. See Scheduling Reports for more
Schedule
information. You can click the + icon to set a schedule for the report to run.
Results The results from any scheduled runs of the report, or results you have saved from running the
report.
Audit
Audit Reports can be used to determine if a device is running the recommended OS and installed software
versions, performance metrics are within bounds and harmful events have not triggered.
1. Go to Analytics tab
2. Expand Audit node on the left tree and go to the folder to which the new report will belong. You can also create a
new folder first by clicking on the + on top of the left tree.
3. Click New.
4. Enter the following information for an Audit Report
1. Name: Name of the Audit Report
2. Description: Description of the Audit Report
3. Vendor: Select a specific device vendor from the drop down list. The Audit Report will be specific to the
chosen device vendor and model
4. Model: Select a vendor specific model from the drop down list. The Audit Report will be specific to the
chosen device vendor and model
5. Specify Failed Criteria for the Audit Report. A device will fail the audit if any of the specified criteria is
matched.
1. OS Version Condition:
1. Choose an operator: possible choices are IN, NOT IN, CONTAINS, NOT CONTAINS
2. Specify value to be matched: this can be a comma separated list
2. Install Software Condition:
1. Specify Condition name. This is just for reference purposes.
2. Specify Install software name - the name has to be exactly identical to the
discovered installed software in CMDB > Devices > Installed Software > Name
3. Choose an operator: possible choices are IN, NOT IN, CONTAINS, NOT CONTAINS
4. Specify value to be matched: this can be comma separated list
3. Rules Condition:
a. Click ... and the Rule selector dialog appears
b. Select the appropriate Rule folder from the left most tree. If you do not know the
specific folder, then choose the top level Rules folder.
c. Select the rules from the middle section. You can also type a search string. You can
expand the window and shrink the left most section to see more of the rule
descriptions. The rules in the selected folder will appear in the middle section.
d. Click Items >> to place the selected rules on the rightmost section
e. Click OK.
4. Report Condition:
a. Click ... and the Report selector dialog appears
b. Select the appropriate Report folder from the left most tree. If you do not know the
specific folder, then choose the top level Reports folder. The reports in the selected
folder will appear in the middle section.
c. Select the reports from the middle section. You can also type a search string. You can
expand the window and shrink the left most section to see more of the report
descriptions.
d. Click Items >> to place the selected reports on the rightmost section
e. Click OK.
1. For each criteria, only devices in CMDB with vendor and model specified in the Audit Report is considered
2. If any of the criteria matches, then the device fails the audit
3. IN and NOT IN are exact match while CONTAINS and NOT CONTAINS are case insensitive sub-string match
4. For OS Version match, the entered value is compared with the Version column in CMDB > Device.
5. For Installed Software Version match, the entered value is compared with the Version column in CMDB > Device >
Installed Software
6. For Rule match, the specified rule must trigger during the time interval specified in the Audit Report. Organization
id and access IP of the device is compared to the Organization Id and Host IP in an incident.
7. For Report match, the specified reports run for the time duration specified in Audit Report must have data.
Running an Audit
To run an Audit,
1. Select an Audit Policy
2. Click Run Now
3. In the follow up dialog,
a. Select the organizations for which to run the audit (meaningful for Service Provider version)
b. Choose a time window - absolute or relative
c. Click OK
The Audit Policy check results are displayed in the right bottom pane.
Summary tab shows a high level overview of the Audit Policy check.
l Audit Result Distribution chart shows the device pass/fail distribution for every selected organization.
l Failed Criteria distribution chart shows the contribution of each audit criteria to the devices that failed the audit.
l Detail tab shows the Audit Policy check for each device matching the vendor, model specified in the policy.
l Organization specifies the entity to which the device belongs
l Device Name is the host name of the device in CMDB
l Audit Status is the Pass/Fail flag
l Details specifes the reasons for Audit Policy check failure
Scheduling an Audit
To schedule a report to run at a later time
1. Choose between one of two options
l Run this report for - If the 'Run this report for' button is selected, a report will be scheduled for the super
user, containing data from the organizations selected. The super user will be the owner of the report. The
recipients of the report may be defined in the 'Send Notifications' section below or in Admin -> General
Settings -> Analytics.
l Schedule this report for - If the 'Schedule this report for' button is selected, multiple reports will be
scheduled -- one for each selected organization -- and containing only that organization's data. The reports
will be owned by the respective organizations. The recipients of the report are taken from Admin ->
General Settings -> Analytics. When multiple reports are run in this way the notification recipients cannot
be indicated in the 'Send Notifications' section below.
2. Select all the Organizations for which to run the Audit Report
3. Select the Report time range
4. Specify Schedule settings - when to run this report
5. Choose Output Format - PDF or CSV
6. Select notification - report recipients and method
l If you choose Send default notification, then the settings in Admin > General Settings > Analytics
> Alerts to be sent when scheduler runs any REPORT, is used.
l If you choose Specify custom notifications, then you can specify email addresses.
l If you choose Copy to a remote directory, then the settings in Admin > General Settings >
Analytics > Reports to be copied to this remote location when scheduler runs any REPORT, is
used.
Visual Analytics
Visual Analytics is an add-on for FortiSIEM that lets you create custome visualizations of FortiSIEM report data,
as well as dashboards containing multiple visualization charts. FortiSIEM Visual Analytics has three components:
l The FortiSIEM Report Server, which syncs with and replicates FortiSIEM reports in near-real time.
l Tableau Server from Tableau Software, which enables the publication and distribution of your visualizations.
l Tableau Desktop, also from Tabeleau Software, which is your primary tool for creating visualizations.
See Installation and Configuration of FortiSIEM Visual Analytics for information about setting up FortiSIEM
Report Server. For more detailed information about Tableau Server and Desktop, including installation,
configuration, and examples of creating sheets and workbooks, you should consult the Product Support section of
the Tableau Software website.
With FortiSIEM Visual Analytics, you can now create visual representations of the data that is stored in
FortiSIEM. This includes:
l Structured data stored in the FortiSIEM CMDB relational PostgreSQL database, such as:
l Discovered information about devices, systems, applications and users
l Identity and location information
l Incidents and notifications
l Unstructured data such as logs, events, performance metrics etc. that are monitored by FortiSIEM and stored in
the EventDB NoSQL database, which is accessible by Supervisors and Workers over NFS.
In order to provide near real-time visual analytics without compromising the performance of your FortiSIEM
deployment, both structured and unstructured data is exported to a separate virtual machine, the FortiSIEM
Report Server, running PostgreSQL. The Report Server contains two databases that are queried by FortiSIEM
Visual Analytics:
l phoenixdb
This database contains the entire FortiSIEM CMDB and is populated via asynchronous PostgreSQL replication
(slony) in near-real time.
l reportdb
This database contains the results of event queries
You can find more information about FortiSIEM Report Server in the topic Report Server Architecture: phoenixdb
and reportdb and its related topics.
FortiSIEM Report Server integrates with Tableau Software to provide the interface for creating and publishing
your data visualizations. Workbooks containing visualizations based on FortiSIEM data are created using Tableau
Desktop, and then are published to Tableau server, where they can be accessed on any Windows or OS X device
by users how have been granted permission for viewing or editing them. FortiSIEM provides some workbooks for
visualizations, but you can construct others for custom analytics. You can find more information about workbooks
in the section Creating and Managing Workbooks.
You install Visual Analytics Report Server as FortiSIEM node, and these requirements assume that you have
already set up and installed FortiSIEM. If you are working with a fresh install of FortiSIEM that includes Report
Server, see the topics under Installation for complete requirements and installation instructions for the FortiSIEM
Virtual Appliance.
Dedicated Machine for Report Server: You must install Visual Analytics Report Server on a dedicated
machine.
You can find full information about setting up all components of FortiSIEM Visual Analytics in the
section Installation and Configuration of FortiSIEM Visual Analytics
These topics cover the installation of Report Server in various hypervisor enviroments.
Follow the instructions for setting up FortiSIEM virtual appliance as described in Setting Up Supervisor, Worker
and Collector Nodes in AWS, and then register the Report Server to the Supervisor as described in Installing and
Registering FortiSIEM Report Server in VMware ESX.
1. Mount a NFS shared directory on both Super and report server and make sure that this mount can survive system
reboot. For example:
2. Make this shared directory own by postgres.postgres:
3. On Super, edit postgresql.conf under /cmdb/data to turn on archive mode by uncommenting (removing # in the
first column) the following lines and make sure archive_command points to the correct directory which is created in
step 1.
archive_mode = on # allows archiving to be done
# (change requires restart)
archive_command = 'cp %p /data/replication/archive/%f'
4. On Report Server, edit /cmdb/data/recovery.conf and uncomment the following lines and make sure restore_
command and
restore_command = 'cp /data/replication/archive/%f %p'
archive_cleanup_command = 'pg_archivecleanup
/data/replication/archive %r
Follow the instructions for installing FortiSIEM virtual appliance as described in Importing a Supervisor, Collector,
or Worker Image into KVM, and then register the Report Server with the Supervisor as described in Installing and
Registering a Report Server Node in ESX.
1. Mount a NFS shared directory on both Super and report server and make sure that this mount can survive system
reboot. For example: /data/replication/archive
2. Make this shared directory own by postgres.postgres
3. On Super, edit postgresql.conf under /cmdb/data to turn on archive mode by uncommenting (removing # in the
first column) the following lines and make sure archive_command points to the correct directory which is created in
step 1.
archive_mode = on # allows archiving to be done
# (change requires restart)
archive_command = 'cp %p /data/replication/archive/%f'
4. On Report Server, edit /cmdb/data/recovery.conf and uncomment the following lines and make sure restore_
command and archive_cleanup_command are pointing to the directory created in step 1:
restore_command = 'cp /data/replication/archive/%f %p'
archive_cleanup_command = 'pg_archivecleanup /data/replication/archive %r
Follow the virtual appliance installing instructions in Installing in Microsoft Hyper-V, and then register the Report
Server node with the Supervisor as described in Installing and Registering FortiSIEM Report Server in VMware
ESX.
1. Mount a NFS shared directory on both Super and report server and make sure that this mount can survive system
reboot. For example: /data/replication/archive
2. Make this shared directory own by postgres.postgres
3. On Super, edit postgresql.conf under /cmdb/data to turn on archive mode by uncommenting (removing # in the
first column) the following lines and make sure archive_command points to the correct directory which is created in
step 1.
archive_mode = on # allows archiving to be done
# (change requires restart)
archive_command = 'cp %p /data/replication/archive/%f'
4. On Report Server, edit /cmdb/data/recovery.conf and uncomment the following lines and make sure restore_
command and archive_cleanup_command are pointing to the directory created in step 1:
restore_command = 'cp /data/replication/archive/%f %p'
archive_cleanup_command = 'pg_archivecleanup /data/replication/archive %r
These instructions are for installing Report Server on VMWare ESX, and assume that you have already installed
and configured FortiSIEM environment. For instructions for a complete FortiSIEM install, see the topics
under Installation.
Follow the instructions for installing FortiSIEM virtual appliance as described in the topics under Installing a
Supervisor, Worker, or Collector Node in ESX and Configuring the Supervisor, Worker, or Collector from the VM
Console.
1. Mount a NFS shared directory on both Super and report server and make sure that this mount can survive system
reboot. For example: /data/replication/archive
2. Make this shared directory own by postgres.postgres
3. On Super, edit postgresql.conf under /cmdb/data to turn on archive mode by uncommenting (removing # in the
first column) the following lines and make sure archive_command points to the correct directory which is created in
step 1.
archive_mode = on
4. On Report Server, edit /cmdb/data/recovery.conf and uncomment the following lines and make sure restore_
command and archive_cleanup_command are pointing to the directory created in step 1:
restore_command = 'cp /data/replication/archive/%f %p'
archive_cleanup_command = 'pg_archivecleanup /data/replication/archive %r
Using FortiSIEM Visual Analytics involves first syncing reports contained in the primary FortiSIEM application to
the FortiSIEM Report Server.
1. Log in to your Supervisor node.
2. Go to Analytics > Reports > Synced Reports.
3. Select a report.
Currently only reports that contain a Group By condition can be synced. Both system and user-created reports
can be synched as long as the contain a Group By condition.
4. Select Sync.
When the sync process initiates, the Supervisor node dynamically creates a table within the Report Server
reportdb database. When the sync is established, it will run every five minutes, and the last five minutes of data in
the synced report will be pushed to the corresponding table. This lets you run Visual Analytics on event data
stored in the Report Server reportdb database.
l phoenixdb
This database contains the entire FortiSIEM CMDB and is populated via asynchronous PostgreSQL replication
(slony) in near-real time.
l reportdb
This database contains the results of event queries.
Topics in this section describe how to view the tables in these databases, and how those tables are organized.
For viewing the tables, we recommend using the pgAdmin PostgreSQL database utility, which you can download
from the pgAdmin website.
Data from the FortiSIEM CMDB database is populated to the FortiSIEM Report Server and stored in the Report
Server phoenixdb. This section contains information on how to view the organization of phoenixdb, and write
queries against the data it contains.
This database contains the contents of the entire FortiSIEM CMDB database, including incidents.
There are two ways to look at the incident data inside FortiSIEM Report Server:
first_seen_time integer The time when the incident was first seen. The format is
UNIX time but with milliseconds granularity. It is defined as
the number of milliseconds that have elapsed since
00:00:00 Coordinated Universal Time (UTC), Thursday, 1
January 1970
The time when the incident was last seen. The format is
UNIX time but with milliseconds granularity. It is defined as
last_seen_time integer the number of milliseconds that have elapsed since
00:00:00 Coordinated Universal Time (UTC), Thursday, 1
January 1970
incident_count integer The number of times this exact incident (with the same
parameters: source, destination etc has happened)
orig_device_ip string IP address of the device that reported the incident
src_device_ (Geo) Location display name string for the object specified
string
location in incident_src
src_country string (Geo) Country name string for the object specified in
incident_src
src_state string (Geo) State name for the object specified in incident_src
src_building string (Geo) Building name for the object specified in incident_src
dest_device_ (Geo) Location display name string for the object specified
string
location in incident_target
dest_country string (Geo) Country name string for the object specified in
incident_target
dest_state string (Geo) State name for the object specified in incident_target
dest_building string (Geo) Building name for the object specified in incident_
target
host_device_ string (Geo) Location display name string for the object specified
location in incident_target - populated if incident_target contains
hostIpAddr
host_state string (Geo) State name for the object specified in incident_target
- populated if incident_target contains hostIpAddr
Data from the FortiSIEM EventDB database is populated to the FortiSIEM Report Server and stored in the Report
Server reportdb. This section contains information on how to view the organization of reportdb, and write queries
against the data it contains.
This database contains the reports that are synched from the FortiSIEM cluster.
1. Log in to FortiSIEM.
2. Go to Analytics > Reports.
3. Select a report.
Any reports with a Sync checkbox can be synced. Run the report to make sure it contains some data.
4. For each report you want to sync, select the Sync checkbox.
AO-SP: In the Sync Details dialog, select the organizations whose data needs to be synced.
5. Click OK.
6. After several minutes, follow the instructions in Viewing reportdb Organization to view the reportdb database.
7. Under Tables, you should now see the synced reports.
When you sync FortiSIEM report to FortiSIEM Report Server, two pairs of tables are created in reportdb, one pair
for each organization in the case of AO-SP. For each organization, multiple tables are created:
1. A parent table containing data for all months: the table name is of the form <Report Name>_<ID>_
<custId>
2. A child table for the current month: <Report Name>_<ID>_<custId>_<yYYYYmMM> where YYYY is the
year and MM is the month.
Queries should be written using the parent table. To see data in the parent table, follow the instructions in
Viewing reportdb Organization . The reportdb database fields are generated from the display fields in FortiSIEM
report definitions. Only the field report_time is added to the Report Server table definitions to capture the
time when the particular report is generated. For example, if you synced the report Network Devices by CPU,
Memory, you would see these fields:
Field Description
report_time UNIX time at which the report is generated. Unix time (or POSIX time or Epoch
time) is a system for describing instants in time, defined as the number
of seconds that have elapsed since 00:00:00 Coordinated Universal Time (UTC),
Thursday, 1 January 1970 not counting leap seconds.
hostName Host Name of the device for which CPU and memory are being measured
hostIpAddr Access IP of the device for which CPU and memory are being measured
Average of all the CPU utilization metrics within the last 5 minutes ending with
AVG(cpuUtil)
report_time
AVG(memUtil) Average of all the CPU utilization metrics within the last 5 minutes ending with
report_time
1. Log in to FortiSIEM.
2. In Analytics > Reports > Synced Reports, select the report you want to delete.
3. In the Sync Details dialog, clear the Sync option for the report, and then click OK.
The report will no longer be synced with Report Server. You can verify this by making sure the Sync option is not
selected for the report on the Analytics > Reports > Synced Reports page. You can now delete the report
from FortiSIEM Report Server.
4. Log in to FortiSIEM Report Server via SSH and navigate to the
directory /opt/phoenix/deployment/jumpbox.
5. Run the phreportdbmanager.py command, along with the table name and date as arguments, to delete the
report.
phreportdbmanager.py --remove tablenames='"Network Devices By CPU, Memory_
1278492569_1"'reporttimes=2014-10
Viewing the Names of Reports in Report Sever: Use the pgAdmin utility to view the names of all
tables and reports in Report Server, as described in
When the deletion process completes, you will see a command line output like this:
6. After you have deleted the table containing the report information, you will need to delete the parent table, which
will now be empty of content, using the same phreportdbmanager.py command.
Suppose a system report is synced and exported to FortiSIEM Report Server. When you modify that report in
FortiSIEM, you must rename it, at which point it becomes a user report. When you then sync that report for
FortiSIEM Report Server, a new table is created on the FortiSIEM Report Server.
Suppose now that you have a user-defined report that is already synced to the FortiSIEM Report Server, but you
modify it inline in FortiSIEM, which means that you have changed the report conditions without changing the
report name. This will cause a change in the table, but a new table will not be created. Here are some examples
of inline modifications, and how they affect the structure of the table as well as the data collected in the table:
Modification Effect
GROUP BY field added The corresponding table has the new GROUP BY field, but only
newer data populates the field
GROUP BY field changed For example, the field srclpAddr is changed to destlpAddr.
Both fields are retained, but newer data populates destlpAddr.
The corresponding table has the new field, but only newer data
Aggregated fields added
populate that field
Aggregated field removed There is no change in the corresponding table, and newer data
does not populate the field
Prerequisites
Before you begin installing Tableau Server, make sure you have read the section on Tableau
Server in Requirements for Visual Analytics Report Server. This contains information on the Administrator
Account and Ports that you will need during the configuration process. You may want to also consult the Tableau
Server Administration Guide before you begin the installation process.
Installation
Activation
1. If you are evaluating Tableau Server, click Start trial now. Otherwise, click Activate the product to enter a
license key.
2. If you enter a license key, click Activate.
3. Click Continue to launch the Tableau Server configuration process.
Configuration
1. In the Configuration dialog, enter a User Name and Password for the domain admin account that you will use to
administer the Tableau Server.
2. If necessary, enter a Gateway port through which you will connect to the server over HTTP.
3. Click OK.
The initialization process will launch and complete within several minutes.
4. Click Finish to complete the configuration process.
5. Launch the Tableau Server user interface by entering the URI for the server in a browser window.
The URI will be be in the format of http://<Windows_Server_IP_Address>:<Port_Number_Used_
In_Step_2>
6. Sign in to the server by entering the credentials for the domain admin account that you created in Step 1, and then
click Sign In.
l Viewing Workbooks
l Creating and Publishing Workbooks
l Adding Users to Workbooks
Viewing Workbooks
Workbooks are collections of FortiSIEM reports that have been synced to FortiSIEM Report Server, and which are
then the basis for charts and dashboards that can be published to Visual Analytics Server for access by other
users. Information in this section describes how to create single and multiple sheets of report information, and
then make them accessible to other users.
These instructions demonstrate how to create a single-sheet workbook that will chart the CPU and memory
utilization trend for various servers. This example uses the Servers by CPU, Memory report and its associated
table, but any report with a table in the reportdb database can also be used. The Tableau Desktop online Help
also contains extensive information about building sheets and workbooks with the Tableau Desktop editor, which
powers the FortiSIEM Visual Analytics Desktop.
l Prerequisites
l Procedure
Prerequisites
l Follow the instructions in Syncing FortiSIEM Report with Report Server to sync the report you want to use for your
worksheet.
l You will need to know the name of the parent table for your synced report. Follow the instructions in Viewing
reportdb Organization to find the table that corresponds to your report.
Procedure
Connecting to Port 30000: It's important to make sure you enter the correct port to connect to
the reportdb database. If you leave this option blank you will connect to the default PostgreSQL
database port, which will connect you with phoenixdb instead of reportdb. For more information
about the databases contained in Report Server, see Report Server Architecture: phoenixdb and
reportdb.
1. Click the Dashboard tab on the bottom of the Sheet editor to open the Dashboard editor.
2. Under Dashboard, select an appropriate Size and screen resolution.
3. Under Dashboard, select the sheet and drag it into the display pane.
4. Open the Dashboard options menu and select Rename.
Change the name of the dashboard from Server CPU/Memory Trend to Server Performance.
5. In the File menu, select Save.
These instructions demonstrate how to create a multiple-sheet workbook that will contain a set of charts related
to Network Health. This example uses the Network Devices by Ping RTT, Network Interfaces By
Utilization, and Network Devices By CPU, Memory reports, but any report with an associated table and
views in the reportdb database could be used. The Tableau Desktop online Help also contains extensive
information about building sheets and workbooks with the Tableau Desktop editor, which powers the FortiSIEM
Visual Analytics Desktop.
l Prerequisites
l Procedure
Prerequisites
l Follow the instructions in Syncing FortiSIEM Report with Report Server to sync the reports you want to use for your
worksheet.
l You will need to know the name of the parent table for your synced reports. Follow the instructions in Viewing
reportdb Organization to find the table that corresponds to your report.
Procedure
Create a View
Each report you want to include in your workbook corresponds to a table in the FortiSIEM reportdb. These tables
need to be joined to cross-link the information that will appear in your workbook. In the case of a Network Health
workbook that includes the sheets Network Devices by Ping RTT, Network Interfaces By Utilization, and Network
Devices By CPU, Memory, the joining keys are host name and time.
1. Follow the instructions in Viewing reportdb Organization to find the parent tables for the reports you want to join.
For each report there is one parent table and multiple child tables containing data for a particular month.
2. Create a SQL statement in pgAdmin to join the tables.
In this example data is captured for one day. This enables quick generation of the data visualization.
SELECT cpu.report_time, cpu."hostName", cpu."hostIpAddr", cpu."AVG
(cpuUtil)", cpu."AVG(memUtil)",
uptime."SUM(sysDownTime)", uptime."AVG(avgDurationMSec)",
uptime."LAST(sysUpTime)",
uptime."SUM(pollIntv)", util."intfName", util."intfAlias",
util."AVG(inIntfUtil)" AS "totalAvgInIntfUtil", util."AVG
(outIntfUtil)" AS "totalAvgOutIntfUtil",
util."AVG(recvBitsPerSec)" AS "totalAvgRecvBitsPerSec",
util."AVG(sentBitsPerSec)" AS "totalAvgSentBitsPerSec",
util."AVG(outQLen)", util."AVG(intfSpeed64)"
FROM "Network Devices By CPU, Memory_1278492569_1" cpu,
"Network Devices by Ping RTT_2021056235_1" uptime,
"Network Interfaces By Utilization_382117475_1" util
3. Under Tables, enter the name of the view you created in the search box to locate the view.
4. Drag the view into the Join pane and click Update Now.
The data in the view will load into the pane below.
5. For Connection, select Live.
6. Click Go to Worksheet.
In the worksheet view you will see that a set of Dimensions and Measures are populated for the view.
An example worksheet showing CPU and Memory Utilization with several Dimensions and Measures populated
from the original table.
7. For each report in your workbook you can now create an individual sheet, as described in Creating a Single Sheet
Workbook.
6. Click Publish.
Using FortiSIEM Workbooks with Tableau Visual Analytics Desktop and Server
You can use any of the workbooks provided by FortiSIEM, which are attached to this page, to create
visualizations of FortiSIEM data.
1. Download a workbook attached to this page to your local device where Tableau Visual Analytics Desktop is
installed.
2. In Visual Analytics Desktop, go to File > Open....
Only the workbook publisher can give access to specific users during report creation time. As the FortiSIEM Visual
Analytics Server Administrator, you can add users to the system and view which workbooks users can access.
l Available metrics
l GUI launch locations
l Running a real time probe
l Example - Real time Interface Statistics Display
Available metrics
l CPU utilization
l Memory utilization
l Network interface statistics
l Uptime
l Disk utilization
l SNMP Ping Statistics
l Process Utilization
Implementation Note
FortiSIEM uses the same event framework to collect data from the devices and display them in the GUI. However
these events are neither stored in the database, nor do they trigger incidents.
Incidents are a category of events that are are triggered when a set of rule conditions have been met. When an
incident occurs, it appears in both the Dashboard > Incident Dashboard and in the Incidents tab, and, in
some cases, a notification is sent based on the notification policies you have set. You can also create tickets from
FortiSIEM incidents. Topics in this section cover the incident information that is available in the dashboard, how
to create incident notification policies, how to create tickets for FortiSIEM and other ticket-handling systems, and
how to manage the IPS Vulnerability Map.
l Incident Information
l The IPS Vulnerability Map
l Incident Notifications
l Creating Tickets
l Using Incidents in Searches and Rules
l The Incidents tab, shown in the screenshot for this topic, where you can view incidents and incident details
l Dashboard > Incident Dashboard, which includes the same incident summary and user interface controls found
in the Incidents tab, but which also provides other views of incidents, including a fishbone view of incidents in your
infrastructure, a topology view with the number and severity of incidents overlaid on devices, a calendar view, and a
location view that includes both a summary view of incident source and target IP locations and a map view, along
with the number and severity of incidents for that location overlaid on the map.
In both locations you can filter the incidents in the dashboard, find out more information about sources and
targets of incidents, customize the dashboard layout, and manage the rules associated with incidents.
l Incident Attributes
l Incident Dashboard User Interface Controls
l Incident Details
Incident Attributes
An Incident has the following attributes.
Event Severity Category The severity of the incident, High, Medium, or Low
Last Seen Time The last time that the incident was triggered
First Seen Time The first time that the incident was triggered
Incident Name The name of the rule that triggered the incident
Incident Source The source IP or host name that triggered the incident
Status The status of the incident, Active, Cleared, Cleared Manually, System
Cleared
For manually cleared incidents, this displays the reason the incident was
Cleared Reason
cleared
Comments Any comments that users have entered for the incident
Ticket User The person assigned to any tickets generated by the event
External User If the ticket was cleared in an external ticket-handling system, this lists the
name of the person the ticket was assigned to
If the ticket was cleared in an external ticket-handling system, this lists the
External Cleared Time
time it was cleared.
External Resolved Time If the ticket was resolved in an external ticket-handling system, this lists the
time it was resolved.
External Ticket State The state of the incident ticket in an external ticket-handling system
Incident Notification Status Status of any notifications that were sent because of the incident
Incident Count How many times the incident has occurred during the selected time interval
The filter controls let you control which incidents are shown in the dashboard.
Severity Use these options to only see incidents with the selected severity level
Filter incidents based on the status of their associated tickets. See Creating
Ticket Status
Tickets In FortiSIEM In-built Ticketing System for more information.
Time Selection Select the time interval during which incidents should have occurred. The default
is Last 2 Hours.
For Service Provider deployments, select the organization you want to view
Organization
incidents for.
Impacts For multi-tenant deployments, select an organization to view the incidents that
are impacting it
Edit the rule associated with the incident. See the topics under Rules for more
Edit Rule
information.
Exception Create an exception to the rule associated with the incident. See Defining Rule
Exceptions for more information.
Create a ticket from the incident. See Creating Tickets In FortiSIEM In-built Ticketing
Ticket
System for more information.
Clear the incident. See Defining Clear Conditions for more information on how to set
rule conditions that will automatically clear incidents. All non-security related
incidents are cleared from the system every night at midnight local time, and will
Clear
show a status of System Cleared. A status of Manual Clear means that a user
cleared the incident from the Incident Dashboard, while Clear means it was cleared
by a rule condition.
Email Select one or more incidents from the incident view and send email using any specific
email template.
Columns Change the columns displayed in the summary table. Incident Columns describes all
the columns that can be added to the Incident Dashboard.
Locations View geolocation information about the incidents. Pin colors on the map
indicate incident severity:
Contextual Menus
Clicking on an item within a column of the incident summary will open a contextual menu, with options depending
on whether the incident attribute you selected includes an IP address (Source IP or Target IP, for example), or
some other kind of incident attribute. Shared between both menus are an Add to Filter option, which enables
you to select a result attribute and add it to the Filter By conditions. Both menus also include most of the same
options available in the Incident Management controls to edit and add exceptions to rules. The IP address
contextual menu provides options to view more information about the associated device, with many of the same
options you would find in the Analysis menu used in search summary dashboards.
This screenshot shows the IP contextual menu open after selecting an IP address in the Incident Source
column of the Incidents tab.
The Dashboard > Incident Dashboard contextual menu includes an option not found in the Incident tab view
of incidents. Click in any column for an incident in the Incident Dashboard to open the contextual menu, and you
will see the option Show incident details. If you select this option the Incidents tab view of incidents will load,
and you will see detailed information about the incident you selected in the Incident Details pane.
Incident Details
The Incident Details pane at the bottom of the Incidents Dashboard provides you with information about a
selected incident in three areas: Incident Details, Triggered Events, and Related Incidents.
Incident Details
The Incident Details include the ID of the incident, specific details about the event that triggered the incident,
and the definition of the rule associated with the incident.
Triggered Events
The list of events that triggered the incident. For columns containing an event type, or host or IP information,
click on an item to open a contextual menu and view more information about it.
If the rule that triggered the incident has multiple sub patterns, you can select a sub pattern to see which events
met its conditions.
Related Incidents
Use this menu to view related incidents based on the Source, Target, Rule Name, or Reporting IP associated
with the selected incident.
As your review incidents in your dashboard, you may want to build searches based on attributes from selected
incidents. For example, you may want to use the value for the Incident Target attribute in an incident as a
filter condition to find similar or related incidents, and then add more conditions based on the results of that
search.
1. Log in to your Supervisor node.
2. Go to Incidents.
3. In the Incident Dashboard, select an incident.
4. Click on the attribute value for the selected incident that you want to add to the Filter By condition to open the
Options menu, and then select Add to Filter.
The type of search will change to Advanced, and the attribute value you selected will be added to the Filter By
conditions.
5. Click in the Filter By Conditions field to open the Conditions Builder and add other incident attributes.
6. Click Refresh when you're done creating filter conditions to see the results.
The Incident Dashboard presents a view of all incidents based on the filter conditions you select. However, there
may be situations in which you want to view incidents grouped on incident attributes like Incident Source,
Incident Target, Severity, or Incident Name. Once incidents are grouped by their attributes, you can view
Incident Details for the entire group.
1. Log in to your Supervisor node.
2. Go to Incidents.
3. In the Group By menu, select the attributes you want to use to group the incidents, and then click Refresh.
The Incident Dashboard will refresh and display incidents grouped according to the attributes you selected, with
a COUNT(Matched Events) column that indicates how many incidents are in each group.
4. Select a group and then click on it to open the Options menu.
5. In the Options menu, select Show Incident Details for This Group.
The Incident Dashboard will refresh to show all incidents in the selected incident group, and you can use the
Contextual Menus to find out more information about them.
calendar day, grouped by severity. Clicking a group loads a summary of those incidents.
This screenshot shows the calendar view of incidents for the month of February 2015.
l Clicking on an incident number will show you a summary of those incidents. Clicking on Last Seen, First Seen,
Incident Name, or Incident Details in that summary will let you select Incident Details to view more
information. Clicking on any IP addresses associated with the device will open a contextual menu that will let you
find out more information about that device.
l Clicking on an IP number or hostname in the fishbone view will let you view the Quick Info for that device, or you
can select Topology to view it within the context of your network topology.
l Hovering your mouse cursor over a device or incident number will show you the IP address and host name for that
device, as well as the type of device.
This screenshot shows an example fishbone view of network segments, devices, and associated incidents.
Incident Notifications
The sending of notifications when an incident occurs is handled by Notification Policies, which you can see listed
in the Analytics > Incident Notification Policies page. Instead of having notifications set for each rule, you
can create a policy and have it apply to multiple rules.
When viewing the notification policies, think of the columns on the page as representing a series of "If ... and ...
then" statements that lead to the notification action. For example, you could read the table columns as a
sentence:
When FortiSIEM evaluates whether a notification action should be triggered based on the notification conditions,
it evaluates all notification policies, and will trigger the actions of all policies that meet the condition, instead of
just the first policy that meets the conditions. This means that the order of policies in the list doesn't matter, and
that you can write policies with overlapping conditions that could also, for example, include different actions.
See also the topics under Incident Notification for more information about the methods that are available for
sending notifications from FortiSIEM, including the FortiSIEM API.
Prerequisites
l Make sure you have enabled the settings for sending email or other notification actions as described in Setting Up
Routing Information for Reports and Incident Notifications.
l You should read the introductory topic on incident notifications to understand how policy conditions are processed..
Procedure
l Prerequisites
l Procedure
l Related Links
Prerequisites
l Make sure the email gateway has been configured for your deployment.
l You should also have set up any email templates that you want to use for notifications.
Procedure
8. Under Notification Actions, select the Method, Email or SMS, that you want to use sending the notification.
9. Select an Email Template if you are sending an email notification.
If you leave this blank, the default email template will be used.
10. Click Save.
Run On
The Run On column only applies if your notification action is to execute a script. For email and SMS
notification actions, it will be auto-populated with Super.
You can send incident notification emails for multiple incidents based on customer requirements by selecting
multiple incidents and clicking Email button.
Related Links
l Setting Up the Email Gateway
l Setting Scripts as Notification Actions
Email templates for incident notifications are based on incident variables that you put into the subject and body of
the template, which are then populated with the actual attribute values in the incident.
These are the incident attribute variables you can use for your email template.
l $organization
l $status
l $hostName
l $incidentId
l $incidentTime
l $firstSeenTime
l $lastSeenTime
l $incident_severityCat
l $incident_severity
l $incident_incidentCount
l $ruleName
l $ruleDescription
l $incident_source
l $incident_target
l $incident_detail
l $affectedBizService
This example first shows a template with the incident attribute variables, and then an email based on this
template with the variables populated from an incident.
Template
Email Subject:
$ruleName was triggered at $incidentTime
Email Body:
The host, $incident_target, was being scanned by $incident_source starting at $firstSeenTime and ending at
$lastSeenTime. There were $incident_incidentCount hits.
Generated Email
Subject: Server Memory Warning was triggered at Jan 10 22:43 UTC
Body: The host, Host IP: 192.168.1.23 Host Name: QA-V-WIN03-ORCL, was being scanned by 10.1.1.1
starting at Jan 10 22:05 UTC and ending at Jan 10 22:11 UTC. There were 2 hits.
1. When a notification policy is triggered, the policy actions are handled in sequential order. That means, if there are
multiple script actions, the first one will be processed before the second.
2. When you specify the notification action as a script, you must provide the full path to the script in the notification
policy settings, for example /tmp/Myscript.py
3. When the script action is processed,
a. FortiSIEM notification module will first generate an incident XML file and put it in the same directory as
the script.
b. FortiSIEM will then call the script with the XML file name as an argument. The full incident XML file path
will be passed as the first command line parameter to the script, e.g. $1 for shell and sys.argv[1] for
Python.
4. You must write the script so it expects the incident XML file to be located in the same directory as the script, for
example /tmp if the script location is /tmp/Myscript.py. Use absolute path to refer to the incident XML file.
5. When the script returns, the incident XML file that was created by FortiSIEM is deleted, so there is no confusion
with the next script action which involves a new incident XML file and is processed only after the previous script
action is complete.
See here for an example of a notification script.
If your deployment includes Collectors, you can specify the Collector where the script will run.
1. Prepare the script on the Collector(s) and make sure they run properly.
2. When incident triggers, Collector will download the incident XML from the Supervisor and run the script with
incident XML as argument.
3. The Collector will then return the results to the Supervisor.
In the Notification Actions table, select the Collector from the list in the Run On menu after you have added
the script to the notification actions.
This topic provides an example of a script that could be used as a notification action, following the example of re-
starting a Windows service that has stopped an triggered an incident as described in Setting Scripts as
Notification Actions.
This example requires two scripts: one located on the Windows server that hosts the service, and a script on the
FortiSIEM Supervisor host machine that will be triggered by the incident notification and will execute the
Windows server script.
Windows Script
1. Create a script named installWinexeSvc.bat for starting the remote winexe provider service.
sc create AoWinexeSvc binPath= C:\WINDOWS\WINEXESVC.EXE start= auto
DisplayName= AoWinexeSvc
sc description AoWinexeSvc "Remote command provider for FortiSIEM
monitoring"sc start AoWinexeSvc
2. Run installWinexeSvc.bat on the monitored Windows server and make sure that the AoWinexeSvc
service starts.
C:\>installWinexeSvc.bat
You should see an output similar to this as Windows installs the service and verifies that it is running.
C:\>sc create AoWinexeSvc binPath= C:\WINDOWS\WINEXESVC.EXE start= auto
DisplayName= AoWinexeSvc
[SC] CreateService SUCCESS
C:\>sc description AoWinexeSvc "Remote command provider for FortiSIEM
monitoring"[SC] ChangeServiceConfig2 SUCCESS
C:\>sc start AoWinexeSvc
SERVICE_NAME: AoWinexeSvc
TYPE : 10 WIN32_OWN_PROCESS
STATE : 2 START_PENDING
(NOT_STOPPABLE, NOT_PAUSABLE, IGNORES_
SHUTDOWN)
WIN32_EXIT_CODE : 0 (0x0)
SERVICE_EXIT_CODE : 0 (0x0)
CHECKPOINT : 0x0
WAIT_HINT : 0x7d0
PID : 1580
FLAGS :
FortiSIEM Script
This script, restartWinService.py, reads the incident XML file, parses out the target IP and stopped
service, and issues a winexe command to restart the service.
#!/usr/bin/python
importos, re, sys, time
importxml.dom.minidom
iflen(sys.argv) != 2:
print "Usage: parseTargetIP.py incident.xml" exit()
else:
fileName = sys.argv[1]
print "parsing incident xml file : ", fileName
#os.system("cp "+ fileName + " "+ fileName + ".txt")
# /incident/incidentTarget/entry[@attribute='hostIpAddr']
doc = xml.dom.minidom.parse(fileName)
nodes = doc.getElementsByTagName('incidentTarget')
ifnodes.length < 1:
print "no incident Target found!"else:
targeNode = nodes[0]
targetIP = ""fornode in targeNode.childNodes :
ifnode.nodeType == node.ELEMENT_NODE:
ifnode.getAttribute("attribute") == "hostIpAddr":
targetIP = node.firstChild.data
iftargetIP == "":
print "no incident target found!"# trim IP, e.g. 10.1.20.189(SH-Quidway-SW1)
targetIP = re.sub(r'\(.+\)', "", targetIP)
print "restart service for target IP: ", targetIP
# parse process name
nodes = doc.getElementsByTagName('incidentDetails')
ifnodes.length < 1:
print "no incidentDetails found!"else:
targeNode = nodes[0]
fornode in targeNode.childNodes :
ifnode.nodeType == node.ELEMENT_NODE:
ifnode.getAttribute("attribute") == "serviceName":
targetService = node.firstChild.data
#################################################################################-
###############
# NOTE: You need to replace the user and password with an account on your Windows
server that #
# has permissions to run thiswindows command.
#
#################################################################################-
###############
# stop the service
stopCmd = "winexe --user Administrator --password ProspectHills! //"+ targetIP + "
'sc stop "+ targetService + "'"ret = os.system(stopCmd)
print "stop service with return code ,", ret
print "waiting service stop"time.sleep(10)
#################################################################################-
###############
# NOTE: You need to replace the user and password with an account on your Windows
server that #
# has permissions to run thiswindows command.
#
#################################################################################-
###############
## start the service
startCmd = "winexe --user Administrator --password ProspectHills! //"+ targetIP +
" 'sc start "+ targetService + "'"print "start command: ", startCmd
ret = os.system(startCmd)
print "start service with return code ,", ret
This topic includes an example of the XML file that is generated for incidents, and descriptions of its contents.
<incident>
<incidentDetails> The event attributes associated with the rule definition that
triggered the incident
<rawevents> The contents of the raw event log for the incident.
This topic describes how to configure Remedy to accept tickets as notification actions from FortiSIEM.
Prerequisites
l Make sure you have configured the Remedy server settings in FortiSIEM.
Procedure
1. In Remedy, create a new form, FortiSIEM_Incident_Interface, with the incident attributes listed in the table at
the end of this topic as the form fields.
2. When you have defined the fields in the form, right-click on the field and select the Data Type that corresponds to
the incident attribute.
3. After setting the form field data type, click in the form field again to set the Label for the field.
4. When you are done creating the form, go to Servers > localhost > Web Service in Remedy, and select New
Web Service.
5. For Base Form, enter FortiSIEM_Incident_Interface.
6. Click the WSDL tab.
7. For the WSDL Handler URL, enter http://<midtier_
server>/arsys/WSDL/public/<servername>/FortiSIEM_Incident_Interface.
8. Click the Permissions tab and select Public.
9. Click Save.
You can test the configuration by opening a browser window and entering the WSDL handler URL from step 7,
substituting the Remedy Server IP address for <midtier_server> and localhost for <servername>. If
you see an XML page, your configuration was successful.
cleared_events text
cleared_reason text The reason for clearing the incident if it was cleared,
first_seen_time bigint Time when the incident occurred for the first time
last_seen_time bigint Time when the incident occurred for the last time
incident_detail text Incident Detail attributes that are not included in incident_
src and incident_target
notification_action_
text
status
orig_device_ip text
character varying
ticket_id Id of the ticket created in FortiSIEM
(2048)
view_status integer
view_users text
1. In the Incident Dashboard, select the incident you want to create a ticket for.
2. Click Ticket.
The Incident ID, Summary and Description for the ticket will be populated from the incident information.
3. Select the person you want to assign the ticket to.
4. Enter a Due Date for the ticket.
5. Set a Priority for the ticket.
6. Click Save.
Closing a ticket
Exporting a ticket
Searching tickets
Incident Attributes
This topic describes all the columns that can be used to create views in the Incident Dashboard. You can add or
remove columns from the dashboard by clicking the Columns icon.
Last Occurred The last time that the incident was triggered
First Occurred The first time that the incident was triggered
Status The status of the incident, Active, Cleared, Cleared Manually, System
Cleared
For manually cleared incidents, this displays the reason the incident was
Cleared Reason
cleared
Comments Any comments that users have entered for the incident
Ticket User The person assigned to any tickets generated by the event
External User If the ticket was cleared in an external ticket-handling system, this lists the
name of the person the ticket was assigned to
External Cleared If the ticket was cleared in an external ticket-handling system, this lists the
Time time it was cleared
External Resolved If the ticket was resolved in an external ticket-handling system, this lists
Time the time it was resolved
External Ticket State The state of the incident ticket in an external ticket-handling system
Incident Notification
Status of any notifications that were sent because of the incident
Status
How many times the incident has occurred during the selected time
Incident Count
interval
Viewing Incidents
l Device Risk View of all incidents
l Viewing incident details
l Grouped View of all incidents
To see the incidents for a device, click that device. The incidents show up in a time line view.
l Active
l Cleared
l Cleared Manually
l System Cleared
By default only Active Incidents are shown. To show Incidents in other states
l Name, Source, Target, Business Service - Ranks Incident Name, Incident Source, Incident Target and
Business Services By Count
l Name, Source, Target, Business Service, Organizations - Ranks Incident Name, Incident Source, Incident
Target, Business Services and Organizations By Count
To get a grouped view
l Choose the desired view from Group By drop down
Group view works with Search
Grouped view works with Search filters. In other words, Grouped view includes the incidents where the search
conditions are satisfied.
Searching Incidents
l Searchable Incident Attributes
l Constructing Search Condition
Time Range In
ID Incident ID
Incident Status Possible values are Active, Cleared, Cleared Manually, System Cleared
Ticket Status Possible values are New, Open, Closed, External, reopened, None.
External means opened in an external system.
l Click on the Add filter edit area. Three fields are displayed
l Incident Attribute
l Operator
l Value
Managing Incidents
l Adding Comments
l Clearing Incidents
l Exporting Incidents to a PDF document
Adding Comments
1. Click on an Incident in the un-grouped view
2. From Actions drop down, select Add Comments
3. Write the comment and click OK.
Clearing Incidents
1. Click on an Incident in the un-grouped view
2. If you have more incidents to clear, then press Shift and click on the second incident. This will will select all
incidents between the first one and this one. To get this approach to work effectively,
l Create a filter to get all the incidents to be cleared in view
l Select the first incident
l Press Shift and click on the last incident - all incidents are now selected
3. From Actions drop down, select Clear
4. Click OK
Risk computation algorithms are proprietary and this section presents only the knobs that user is able to tweak to
change the score.
The algorithm also reduces the score for earlier vulnerabilities that are now patched. Such vulnerabilities have a
weight of 0.7 while new and old but existing vulnerabilities have weight 1
Miscellaneous Operations
DESTINATION_ Destination directory where the exported event files are saved
DIR
RELATIVE_ Must be used together with END_TIME. Starting time of events to be exported
START_TIME relative backward to the end time as specified using --endtime END_TIME. The
format is
{NUM}{d|h|m}
END_TIME Ending time of events to be exported. The format is the same as START_TIME.
RELATIVE_END_ Must be used together with START_TIME. Ending time of events to be exported
TIME relative forward to the start time as specified using START_TIME. The format is
same as RELATIVE_START_TIME.
phExportEvent
Description
Command
Host name or IP address of the device with the events to be exported. Use a
DEVICE_NAME comma-separated list to specify multiple IPs or host names, for example, --dev
10.1.1.1,10.10.10.1,router1,router2. Host name is case insensitive
ORGANIZATION_ Used only for Service Provider deployments. The name of the organization with the
NAME events to be exported. To specify multiple organizations, enter a commandeach for
one organization, for example, --org "Public Bank" --org "Private
Bank". The organization name is case insensitive.
Specifies the time zone used to format the event received time in the exported event
TIME_ZONE files. The format is {+|-}TZ, for example, -8 means Pacific Standard Time,
+5:30 means India Standard Time.
For each IP address (Host IP, Source IP, Destination IP, Reporting IP):
1. FortiSIEM checks the CMDB for an associated host name, and if one is found, then the host name is added to the
event.
2. If the host name is not found in then CMDB, then FortiSIEM checks the Identity and Location Report for the host
name, and if one is found, then it is added to the event.
3. If the host name is not found in either the CMDB or Identity and Location Report, then FortiSIEM runs DNS lookup
for the host name, and if one is found, then it is added to the event. For performance reasons the DNS result is
cached, and because excessive DNS lookups can cause event processing delays, FortiSIEM has an algorithm to
dynamically bypass DNS lookup if it begins falling behind in event processing.
For Source IP, FortiSIEM checks for user information in the Identity and Location Report, and if anything is
found, it is added to the event.
Geolocation Attribute
For each IP address (Host IP, Source IP, Destination IP, Reporting IP), FortiSIEM checks the geolocation
database. If geolocation information is found for that IP, then Country, State, City, Organization, Longitude, and
Latitude information is added to it.
Because the FortiSIEM approach to populating event attributes is dynamic and change driven, it is always able to
map the right IP address to host names and users in the face of dynamic changes in the IT infrastructure.
IP Type Attributes
IP Type Attributes
Column Description
IPS Event Types The event types associated with the vulnerability
Found in Device Type Specific devices or applications that have the vulnerability
Found in Version The version of the device or application that has the vulnerability
Fixed via Patches The patch version in which the vulnerability was fixed