Technical Tip: FortiEDR Application Control mechanism and why behavior may differ

Application Control in FortiEDR is designed to prevent processes from starting based on file attributes such as hash, file name, path, and/or signer. The enforcement happens before process creation. Once a process is already running, Application Control does not terminate it.

Application Control operates in parallel with other protection modules. There is no precedence over security policies (Execution Prevention, Exfiltration Prevention, etc).

Expected behavior:
If a file starts after the rule is applied, the Application Control incident will trigger and block execution.
If a file was already running before the rule is applied, the Application Control incident will not trigger.

Example scenario (why behavior may sometimes look different):

Consider the following real-world scenario:
A malicious file, App_A.exe, launches another malicious process, App_B.exe.
From the Investigation View, in the process tree, App_A.exe occurs before App_B.exe.
App_A.exe is added to the Application Control block list.

What can be observed:

This difference is expected and is caused by the timing of process execution:

For Device 1, App_A.exe was already running before the Application Control rule was created, and Application Control does not affect already running processes.

Later, when App_B.exe is triggered, the Execution Prevention security policy blocks it.

For Device 2, App_A.exe starts after the Application Control rule is in place, so Application Control blocks it.

Key takeaway:
Application Control does not stop processes that are already running.