Technical Tip: FortiEDR Exclusion Manager Tips

[Luke_FTNT]

Description	This article covers noteworthy tips on the new Exclusion Manager feature.
Scope	FortiEDR v5.2 and above.
Solution	FortiEDR v5.2 and above offers a new feature called Exclusion Manager. This feature allows administrators to exclude specific files and/or directories from pre and post-execution prevention policies. This can be useful in scenarios where an executable or directory is trusted and may otherwise encounter performance anomalies when running alongside FortiEDR. Read the official administration guide here https://docs.fortinet.com/document/fortiedr/5.2.0/administration-guide/642314/exclusion-manager as well as our Community article on Exclusion setup here https://community.fortinet.com/t5/FortiEDR/Technical-Tip-FortiEDR-exclusions-setup/ta-p/259897 before proceeding. Tip #1: Using the advanced section of Exclusion Manager and selecting 'Do not monitor the files for other functionalities as well': This feature will disable all of FortiEDR’s inspection and protection on the configured executable and/or directory. This option introduces an element of risk which the administrator should be aware of before implementing. If this option is not enabled, FortiEDR will still monitor the configured executable and/or directory and only exclude it from protection if specific conditions are met. This offers an additional layer of security however if an application is suffering from performance degradation, enabling ‘Do not monitor the files for other functionalities as well’ may be required. Tip #2: Understanding why a security event may trigger when an exclusion is in place. There are three main items to explore here: Is the excluded executable and/or directory correctly configured based on the security event? You can compare the security event details through the ‘Forensics’ tab if available, Investigation View or by choosing ‘Export’ > ‘JSON’. Exclusions work on the process that is performed by the 'bad' action and not necessarily the parent. In cases where a security rule is pre-execution, this would mean the process before the block happened. In terms of post-execution, this is the last process in the chain. It is important to note that the triggered event listed under 'Process Path' in Event Viewer may not be the process where the blocked activity occurred. The last process in the chain of events under 'ADVANCED DATA' is the process that should be excluded. We will use an example where Dropbox’s ‘Dropbox.exe’ is excluded along with ‘Do not monitor the files for other functionalities as well’ being enabled, however, a process called ‘netsh.exe’ is being blocked: In this event, the actual process being blocked is ‘netsh.exe’. Despite being a process called by Dropbox, the exclusion configured on ‘Dropbox.exe’ will not apply to this new process. If desired, the exclusion would be required for ‘netsh.exe’. Has enough time elapsed since creating the exclusion and when was the security event triggered? Fortinet recommends waiting for at least fifteen minutes before testing. This will ensure the updated configuration is downloaded by the Collector and loaded into its driver. Is the advanced option ‘Do not monitor the files for other functionalities as well’ enabled? If not, the executable may not be technically excluded by design depending on what activity it is performing such as loading unexpected or tampered code in memory. As touched on above, this is an additional security layer. You can enable this option and test again to validate this.