Mimecast Partner - Managed Service Provider Process for the Mimecast Security Team

This article provides an outline for Managed Service Providers (MSP) which should be considered when sending an Escalated Case to the Mimecast Security Team (MSOC).

Before escalating to MSOC make sure you have completed your investigation and determined that there are no further actions from Service Delivery required (Customers might ask multiple questions in the same case and some of them may not be related to MSOC.).

Summary of Requirements

• MTA, API, and RSPAMD logs no longer required for escalation 
• Provide clear information via case / escalation notes on what needs to be investigated (a specific URL, the message headers, etc – see chart below) 
• Confirm no configuration issues. (auto allow, permits, blocks, disabled policies, etc) 
• Confirm reported sample 
• Provide information per chart below 
• (False Positive = Unwanted detection on a legitimate message)
• (False Negative = Missed detection on a malicious or otherwise undesirable message)

Requirements Checklist

The table below lists the various types of cases, whether a message sample is required, what to report the case as, what to investigate, and what supporting information is required in the case notes. 

URL False positives should be raised through the URL reporting function in the URL logs. If a customer raises a case, escalate the case, but also encourage the use of this new tool. More details on this can be found in Reporting URLs.

Case Type	Message Sample	Report As	Investigate	Add to Case Notes  (Copy from the Mimecast Administration Console)
False Positive Spam/Phishing (Hold)	Y	Spam	N/A	Message Headers
False Positive Spam/Phishing (Reject)	N	MSOC to address if necessary	Managed Sender, Blocked Sender Entries.	Date, GUID and MTA Information
False Negative Spam	Y	Spam	Auto Allow or Permits letting a high scoring message through, Disabled Spam Scanning.	Message Headers
False Negative Phishing	Y	Phishing	Auto Allow or Permits letting a high scoring message through, Disabled Spam Scanning.	Message Headers
URL False Positive	N	Spam	Managed URL blocks. Customers are encouraged to raise these via the Reporting in the URL Logs.	Full Click Log
URL False Negative (Only use if No Message is involved)	N	Phishing (Recommended, however, a sample is not required)	Managed URL Permits (Disabled or Bypass Policies)	Full Click Log
Attachment Protect False Positive/False Negative	Y	Malware (Please Report Multiple FP Samples if these are mentioned.)	Misconfigured Attachment Protect or Bypass Policies.	Message Headers
False Positive Virus	N	MSOC to address if necessary.	N/A	Date, GUID and MTA Information
False Negative Virus	Y	Malware	N/A	Message Headers
Impersonation Protect Managed Dictionary False Negative	Y	Phishing	For Managed Dictionary issues only. SD is to address Impersonation Protect configuration issues and bypass policy related issues.	Message Headers
API Integration Hash False Positive	Y	Malware (See below notes for more information.)	N/A	Threat Remediation Incident ID and File
Web Security Mis-categorization	N	Report Incorrect Category via Domain and URL Category Lookup under Web Security	Web Security policy issues (i.e. blocking accurate productivity categories via policy.)	Activity Report if further explanation is required
QR Code False Positive	N	MSOC to address if necessary. The URL responsible will show in the Administration Console or MTA Logs.	Customers can add to the Managed URL's as a temporary solution. All cases should be escalated for route cause resolution.	Detected URL, Date, GUID and MTA Information
QR Code False Negative	Y	Phishing	Managed URL allowing the URL	Message Headers

Examples of Information to be Copied 

The following screenshots display the information that you will need to copy and include that is listed in the table above:

1. Message Headers

2. Date, GUID and MTA Information 

3. Full Click Log 

4. Threat Remediation Incident ID and File

5. Activity Report 

NOTE:

For URL FP and Web Security Cases: MSOC does not require message samples for these to update detection. Confirm the result is not due to a config issue such as a customer-managed block and that the issue has not already been addressed, then escalate. 

For Attachment Protect FP Cases: In the event a customer is experiencing issues with multiple files being blocked by Attachment Protect, please report and pull logs on as many samples as possible. This provides our scanner teams with a broader swath of samples to help identify FP issues with their services and helps MSOC identify points to allowlist. 

For CrowdStrike or similar API Integration FPs: In the event of a Malware FP result being passed via API integration to the customer, treat the case as a Malware FP so MSOC may address the inaccurate detection. Keep in mind that while Mimecast can update the result on our end, the updated scanner results may not be automatically passed back to the customer until the same file is re-scanned at the gateway. As such, the customer may need to remove the result from their end as well.

Escalation Steps

• The MSP is responsible for preliminary investigation  
  • Examples: Permitted Sender allowing a message with high spam score through, mis-configured anti-spoofing, insufficient Impersonation Protect hits, URL Protect Bypass, etc 
  • Confirm there are no configuration issues  
• The MSP is responsible for confirming a sample is reported via the Administration Console whenever possible 
  • Reporting a message also generates an audit log entry, search for ‘reported’.
  • If an attachment, report as Malware.
  • If a malicious URL, report as Phishing. 
  • If neither, report as Spam. 
    • Please see ‘Reporting Rejected Samples’ below for guidance on how customer can provide a rejected sample.
  • Samples attached to the case are not valid for escalations. 
  • Reported message samples for non-MIER customers can be viewed by searching for messages sent to mimecast.org in Message Tracking.
  • Service Delivery should only report samples when the customer gives explicit written permission to prevent liability issues 
  • When reporting, please ensure samples are reported to the correct inbox.
• Service Delivery is responsible for ensuring no other outstanding issues are present within the case 
  • If the customer has other issues, please create a separate case for them.
• The MSP is responsible for providing clear escalation notes regarding what is being investigated by MSOC 
• Once the above steps have been confirmed, you may escalate the case to MSOC.
• MSOC escalations no longer require a message sample for URL mis-categorizations or URL FPs, however, MSOC would still like reported message samples for URL FNs as those are phishing messages so we can make anti-spam detection updates.
• MSOC escalations do not require MTA or RSPAMD logs. 

Requesting a Sample 

Most MSOC Escalations require a sample of the message in question, and most de-escalations are due to no sample. Please make sure you have asked the customer to report the email, even if they have attached the samples in the case.  

Below is a basic Canned Response that you can use to request that they submit the sample via the Administration Console: 

Hi , 

In order for us to investigate this issue in more detail, I would ask you to report the message in question via the Administration Console if you have not done so already for our Messaging Security team to review further. Reporting samples through the Administration Console provides Messaging Security with a copy of the original message as it was received by Mimecast to make detection updates and reported samples can only be accessed by our Messaging Security team. This may be done by pulling up the email in Message Tracking, and reporting this as spam, phishing, or malware using the Report dropdown menu. 

Thanks, 

Reporting message samples directly via the Administration Console ensures Messaging Security receives the sample in an unmodified .EML format, which is required to make detection updates. Samples attached to the case (even in a password-protected archive) are not acceptable for escalation. 

Once the customer states the message sample has been reported, confirm we received it via Message Tracking on the customer's Administration Console: 

• Search for messages sent 'from' and 'to' mimecast.org.
  • i.e. messages sent 'from' [e-mail] and 'to' [e-mail].
  • These messages will show as received via forwarded to support.
  • In the event a reported sample was Bounced, request the customer report as Malware or get their permission to do so on their behalf.

Escalation Notes

Write a short description of the reason for the escalation, a description of the customer's issue (what do they think is wrong/why they would like us to investigate?), and if you have taken any steps to mitigate it (eg., Adding the sender to the permitted senders) or any other information you think may help. Also include which mailbox the message was reported to, either Spam, Phishing, Malware or Virus Reports. 

Ensure that once the case is Escalated, you have sent an update to the Customer informing them that they should hear back from the Messaging Security Team when their investigation has been completed.