FortSIEM has 4 main components:
Collectors
Workers
Supervisor
Backend Lg DB
Events come from the log sources into the collectors.
The list of the log types FortiSIEM can process and directions for how FortiSIEM processes those events are in the FortiSIEM External Systems Configuration Guide.
Three of the most common log types from log sources are:
Windows server logs
Linux server logs
VMWare esxi server logs
FortSIEM collectors support the collection of these types of logs in the following ways:
Windows
FortiSIEM agent installed on server (Push to collector)
WMI (Pull from collector)
LInux Server
FortiSIEM agent installed on server (Push to collector)
rsyslog (Push from server to collector)
VMWare server
VM sdk (Pull from collector)
rsyslog (Push from esxi server to collector)
The installed agent on the server registers with the super.
The Super has Agent Template that tell the agent:
What collector to send logs to
What to log
Firewall logs can also be sent to the collector by syslog, but also sent to another syslog server that then either has a FortiSIEM agent installed on it or rsyslog configured to push the logs to the FortiSIEM collector.
FortiNet also has a log server for FortiNet network devices (firewalls, switches, etc) called FortiAnalyzer. The FortiAnalyzer can then send network device logs to FortiSIEM.
Example, FortiAnalyzer collection logs from firewalls at remote sites and then sending those logs to FortiSIEM collectors which then forward them to FortiSIEM workers.
The analyzer does not naturally load balance logs to collectors. The analyzer can send logs to multiple destinations via rsyslog or send to a load balancer which then alternating sends the logs round robin to backend worker servers.
Whether its server logs from agents or firewall logs from a syslog server or fortianalyzer he collectors then send the log to workers. The collector has a natural load balance function where it can alternate logs between separate workers. If you don't specify the workers the collectors will use they will round robin sending logs between all the workers.
The workers examine the logs to see if they match the FortiSIEM defined rules.
The diagram below shows the FortiSIEM supervisor syncing the SIEM rules to the workers. Having multiple log injest workers allows the SIEM to scale.
This diagram shows the defined FortiSIEM rules and how the FortiSIEM super pushes them to the FortiSIEM workers which do the rule matching on the logs.
The SIEM rules than have defined actions for rules matches.
Rule computation happens in a streaming mode using distributed in-memory computation involving Super and Worker nodes. Latest Rule definitions are distributed to Super and Worker nodes. Worker nodes evaluate each Rule based on the events it sees and periodically sends partial Rule results to the Supervisor node. Supervisor node keeps the global rule state machine and creates an incident when the Rule conditions are met. When a rule involves a statistical attribute (for example: mean or standard deviation), a baseline report is created which computes the statistics and updates the rule conditions. The baseline report also runs in a streaming mode using in-line distributed computation. When a CMDB Object changes, an App Server module on the Supervisor node sends a change signal to the Worker nodes, which then download the changes. This distributed in-memory computation enables FortiSIEM to scale to near real time performance with high EPS and large number of rules.
Each rule also has other conditions defined if it triggers.
The FortiSIEM backed database has three options:
Local disk
Elastic
FortiSIEM NoSQL on NFS server (FortiNet Proprietary. Supervisor and Workesr maintain db indexes)
FortiSIEM is licensed based on the following:
Number of devices FortiSIEM monitors or receives logs from
Number of Windows Agents and Linux Agents
Aggregate Events per Second (EPS) it receives
FortiSIEM SOC Monitoring
When you logon to FortiSIEM and git the top "Incidents" tab there will be a list of different categories of incidents.
When events match on rules they trigger an alert in the SIEM as either.
High
Medium
Low
FortiSIEM also defined types of incidents:
Security
Availability (The FortiSIEM agents can also collect availability info on servers)
Performance
Change
Security incidents
SIEMs have scoring algorithms to help provide SOCs some fidelity on what the most serious events are. Most SIEM scoring algorithms are on a 1-10 scale or a 1-100 scale, with 10 or 100 being the most critical events. These models combine values with different weights to formulate a total threat score. Common weight factors include:
Asset Severity - For example is this your Domain Controller? (This is why integrating asset models and asset information from CMDBs is so crucial to SIEM deployments)
Asset vulnerabilities - Is the alert log related to a vulnerability the asset has? or is the asset just a plain vulnerable system? (This is why integrating vulnerability data into your SIEM is so crucial to SIEM deployments)
Alert Severity & Frequency - Most alert logs from point security products (EDRs, IPS, Firewalls, etc) have a severity value within the log itself. The frequency differentiates between a single log versus multiple log alerts.
Other values - This can be performance monitoring values, and other things.
An issue with SIEM threat scoring is they can sometimes be inaccurate leading to a false sense of emergency. SOAR playbooks can be designed to take data from the SIEM alerts and do additional investigation like CTO enrichment.
Investigating Incidents
Reviewing the log that matched the rule that generated the incident.
f
Resolving FortSIEM Incidents
Searching FortiSIEM
CMDB
Rule Tuning
Rule tuning by exceptions (incdent/action/edit rule exception)
Rule tuning by modification
Rule tuning by drop
Rule tuning by threshold
event dropping
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. Implementing these rules may require some thought to accurately set the event type, reporting device, 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 events 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. An 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. Go to ADMIN > Settings > Event Handling > Dropping tab.
Other notes
https://fortinet116.rssing.com/chan-67445900/all_p49.html
コメント