Starting in Engine Update 7.3, support for Policy Granularity Manager was added to Threat Prevention. PGM allows you to configure Threat Prevention behavior when you encounter errors or specific flows. The outcomes of the errors can be configured to error, continue, fail-close policy or fail-open policy.
- Error - will behave according to general policy. If fail-close the file is declared as malicious and dropped with a log entry, if fail-open the file is declared as benign and passed
- Continue - Behaves like the error did not occur and continue in the flow. E.g. if "max files in archive" attribute is set to continue, the archive will be extracted and analyzed even though there are more files than permitted.
- Fail-Close Policy - In case of an error, the file is declared as malicious and dropped with a log entry.
- Fail-Open Policy - In case of an error, the file is declared as benign and passed.
Support for this feature on a Security Gateway is included in Engine Update 7.3
A file that the Threat Emulation blade failed to emulate can be treated as a malicious file (fail-close policy) or as a benign file (fail-open policy). The configuration is performed through the Threat Emulation Command Line Interface - the tecli command.
- To show the current status of an error, run:
[Expert@HostName:0]# tecli advance error show
- To treat an error as a malicious file (fail-close policy), run the following command in Expert mode:
Expert@HostName:0]# tecli advance error set "Error type" fail_close
- To treat an error as a benign file (fail-open policy), run the following command in Expert mode:
[Expert@HostName:0]# tecli advance error set "Error type" fail_open
Supported error types
- File exceeds size limit (supported on R80.10 and above, Threat Emulation must be in Hold mode).
- Password protected archives cannot be emulated (refer to sk112821 for limitations).
- Max number of files in archive reached
- Archive extraction error
- Max decompression rate limit reached in archive
- Password protected document
Note that the description and Error State match the reason and verdict in the log. By altering the Error State for a specific error type, you can alter the verdict to Accept or Drop.
This solution has been verified for the specific scenario, described by the combination of Product, Version and Symptoms. It may not work in other scenarios.