FortiEDR
FortiEDR automates the protection against advanced threats, pre and post-execution, with real time orchestrated incident response functionality.
kwernecke
Staff
Staff
Article Id 192490
Description
This article discusses about:
- Questions and concerns regarding Communication.
- Questions and concerns regarding Collectors running Autonomously.

Solution
- V4 Collectors running autonomously are not an issue with regarding to protection, events reporting and performance. 
- In fact, in V5 protection is done on Collectors independently by what we call a “Local Core” and without the need for the external system Core by default. While Cores serve mostly for processing communication control and threat hunting data.
- The Collector is protected and reports events directly to the Manager (Aggregator). 
- There could be many reasons for Autonomous Collectors. 
- For example: missing Firewall rule, problematic networking due to the device itself, Laptop out of the office, network issues, Core and Collectors in far away networks, and issues on the Manager side or the Core side. 

How the Collector Communicates.

1) How often does a collector talk to an Aggregator?

- Collector establishes connection with the Aggregator and keeps it open.
- It approaches the Aggregator every 5 seconds for reporting its status, checking whether it has to be upgraded and check whether its configuration should be updated.
- In a case that a Collector, following a response from the Aggregator, discovers that it should perform an action (e.g. update its configuration) it establishes another temporary connection for such action.
 
2) When a Collector is marked as being in Autonomous mode, who marks it that way (the Core, the Aggregator, or the Collector)?

- Autonomous mode refers to a status where the Collector cannot connect to the Core either entirely or its Connection to the Core suffers from multiple timeouts/errors.
- When a Collectors fails to connect both to the Core and the Aggregator it will show in the Manager as Disconnected. This will be the state also when the Collector communicates with the Core but fails to communicate with the Aggregator.
- In all the scenarios detailed above the Collector continues to run and protect the device.
- Collector is the one setting its status as "Running Autonoumsly" in case it can't communicate with the Core for 1 minute.
 
3) Once marked as 'autonomous', what process is followed to allow the Collector to return to 'running' state?

- When the Collector fails to establish a connection with either the Core or the Aggregator it keeps trying to establish a connection every few seconds to few minutes. Time varies according to the amount of errors on previous tries.
 
4) Regarding the persistent connection from the Collector to the Core on TCP port 555, what is the keep-alive interval?

- The keep alive interval is 30 seconds from either the last keep alive request or the last event sent form the Collector to the Core.
 
5) Who sends the keep-alive?

- The Collector.
 
6) Regarding the maximum number of Collectors per Core, what resource can be exceeded if we go beyond the maximum (e.g., Core CPU exceeded, Core state table exceeded, bandwidth saturation, excessive number of requests, etc.)?

- Each Core is assigned to an Aggregator. Aggregator and Core are limited to support up to 10k Collectors.
- When Core will handle more than 10k Collectors its CPU will be higher.
- Network saturation can be a result of a combination of the app link to the Core and excessive number of events.
 
7) What happens when a PC first starts up and the Collector makes its first contact with the Aggregator and the Core server?  Also, once a Collector is assigned to a Core, will that Core be the only Core that it works with, or is it possible that it may change cores?  If so, what would cause the move?

- When collector service starts, it loads the drivers and the last configuration it had. Then it connects to all Cores and picks the one that responds fastest as the preferred core and starts sending events to it. In parallel the service registers to the manager via the Aggregator and starts sending status messages every 5 seconds. 
- When the collector can’t connect to its preferred core or it gets errors from this core (such as timeouts) it does the process of searching for a new preferred core. If core configuration changes, for example the preferred core is deleted from the manager console collector, the collector also looks for a new preferred core.
 
8) How does the Management Console get the Status from the Collector, if it is not communicating with a Core?  Does the Aggregator Update the Console?


The collectors and Cores communicate with their assigned Aggregator. The Aggregator passes aggregated information to the Manager.

- For example, in the case of status, each collectors sends the status to the Aggregator every 5 seconds. The Aggregator passes to the Manager only the status changes.
- Is there an algorithm for how a collector decides when it cannot talk to a core? If so, what is the trigger point? Once that point is reached, what is the collector supposed to do?  
- Does it ask the aggregator who else it can talk to?  Does it try to connect to all cores again? 
- There is an algorithm whether to try to connect back to the previous core or remain with the current one. The algorithm takes into consideration several aspects, including the number and type of errors that occurred (connection error, timeouts etc.), the events ratio etc.
- The collector makes sure events don’t get lost. If the core does not reply fast enough, events are handles autonomously. From a security (protection) perspective, it is the same processing.
       
Traffic information from Admin Guide:
 
- When using FortiEDR automatic updates to Collectors via the Central Manager, make sure to update the master image too. Otherwise, every time that a new environment is created from the master image, an automatic update is performed, which can overload network traffic.
- FortiEDR collects OS stack data, thread and process-related data and conducts executable file analysis to determine the nature of every connection request, as follows.
- When working in prevention mode, all the connection establishment requests in your organization must be authorized by the FortiEDR Core that is embedded in the FortiEDR Collector, thus enabling it to block each outgoing connection establishment request that is malicious.
- When the FortiEDR local Core receives a connection establishment request, it comes enriched with metadata collected by the FortiEDR Collector that describes the operating system activities that preceded it.
- The FortiEDR Core analyzes the flow of events that preceded the connection request and determines whether the connection request was malicious. The system then enforces your organization’s policy by blocking (or only logging) the connection request in order to prevent/log exfiltration, encryption or other malicious activity.
- The collection of the flow of events that preceded the connection request enables FortiEDR to determine where the foul occurred.
- One or more FortiEDR Cores are required, according to the size of your network based on deployment size (up to 50 FortiEDR Cores). 
- To the FortiEDR Aggregator: The FortiEDR Core sends registration information the first time it connects to the FortiEDR Aggregator and then sends events and ongoing health and status information.
- From the FortiEDR Aggregator: The FortiEDR Core receives its configuration from the FortiEDR Aggregator.
- The FortiEDR Core is located on exit points from your organization. It only reviews FortiEDR Collector metadata; it does not see the outgoing traffic. It is a central Linux-based software-only entity that can run on any workstation or VM that is assigned with a static IP address.
       
Negligible Footprint

- The FortiEDR Collector retains only a limited amount of metadata on the device in order to keep CPU usage to virtually zero and the storage requirements to a minimum.
- FortiEDR’s traffic consumption requirements are low since FortiEDR only processes the initial connection establishment.
- V4 The amount of metadata sent to the FortiEDR Core is so minimal that the latency on the Core’s decision point is negligible.
- V5 Collectors use the local Core by default so latency is even lower as there is no network latency.
- Additionally, FortiEDR uses message compression in order to further reduce the traffic sent to the network. 
     
Core.

- V4Rough Average: the average bandwidth consumption is approximately 3Mbps to 6Mbps per 1000 Collectors.
- V5 it highly depends on whether threat hunting is licensed and what threat hunting data profile is in use. Need to get an updated approximation w/o threat hunting and with an Inventory profile per 1000 Collectors.

Aggregator.
 
- Most of the time it is negligible (status sending). When there is a Collector upgrade the consumption is much higher as the installer is sent. The same goes for configuration changes – when full configurations are sent to Collectors the consumption can be higher as well and depends on the environments configuration (e.g number of policies, number of exceptions)
- Also note that, if required by a special situation, the network bandwidth can be capped by changing some settings on the back end. If you encounter a situation where you need this done, we would need to contact our support team to make the changes.

Contributors