Email incidents show do not end up getting quarantined as expected
search cancel

Email incidents show do not end up getting quarantined as expected

book

Article ID: 371003

calendar_today

Updated On:

Products

Data Loss Prevention Network Monitor and Prevent for Email

Issue/Introduction

As part of the investigation, we initially verified that timeouts for DLP Email processing were occuring, such that messages were being released (sent downstream) before DLP Prevent was able to generate an incident that otherwise would have resulted in a Block or Quarantine Response.

Thus, we implemented a header add for messages that do time out, as per the following KB:

Event code 1213 "Messages timed out in detection" (broadcom.com)

The allowed us to confirm which messages were timing out, and to analyze them against the DLP Prevent logs.

Environment

DLP Network Prevent for Email

Cause

Timeout errors indicated need to tune the Email Prevent environment in response to demand.

Resolution

Several steps might be taken to improve email performance due to resource constraints and volume of email traffic.

The below is a list that proved useful in this case:

  1. OOXML extraction was consistently showing errors, so we disabled that in favor of the main extraction engine (Verity). For workaround, see Issues with Office app hung or abnormal behavior when DLP services are running. (broadcom.com).
  2. The customer also upgraded DLP from 15.8 MP3 to 16.0.1, which greatly improved content extraction behavior and performance.
  3. Finally, we increased timeouts for the following settings on each Prevent Server, which allowed more emails to be inspected without timeouts occurring:
ContentExtraction.ShortTimeout -- 5000 [default, in MS] ==> increased this to 30000
ContentExtraction.LongTimeout -- 30000 [default, in MS] ==> increased this to 120000
MessageChain.MaximumComponentTime -- 40000 [default, in MS] ==> increased this to 240000
MessageChain.MaximumMessageTime -- 60000 [default, in MS] ==> increased this to 240000

Note that the vaslues above need to be determined by trial and error, but the ratios given are recommended to ensure that the following relationships are preserved:

  • ContentExtraction.ShortTimeout < ContentExtraction.LongTimeout 
  • ContentExtraction timeouts are < MessageChain timeouts 
  • MaximumComponentTime < MaximumMessageTime 
  • MessageChain.MaximumMessageTime timeouts above are < RequestProcessor.RPLTimeout [default = 360000 ms]

Additional Information

For more information on timeout values and errors, see In an overloaded environment, detection process is timing out (broadcom.com).

For more information on settings for Detection Servers, see Advanced Server Settings (broadcom.com).