Omit scanning headers in outgoing content filter ESA C100V

[keithsauer507]

Hello,

A VP of Marketing asked why an Outlook calendar invite he sent out went securely.  Upon futher investigation it hit our outgoing content filter rule ABA Numbers.  The system thought there was an ABA number in the hidden header of the message and hit on this property:

X-MICROSOFT-CDO-OWNERAPPTID: 279017436

According to MSDN the property information is as follows:

2.1.3.1.1.20.35 Property: X-MICROSOFT-CDO-OWNERAPPTID

RFC Reference: N/A

Number of Instances Allowed: 0, 1

Format: Integer ([RFC2445] section 4.3.8)

Brief Description: Provides an identifier for the appointment which is unique in the scope of the organizer'sprimary calendar.

Importing to and Exporting from Calendar objects

This property SHOULD<223> be directly imported to and exported from PidTagOwnerAppointmentId ([MS-OXPROPS] section 2.845).

This is out of our control so let me run this by the community on ways to mitigate this unwanted hit on our content filter...

Currently the condition is Message Body or Attachment contains smart identifier ABA Routing Number.  If I modify this condition I see there is a seperate test for just the Message Body, which likely (hopefully) would not include the header in the message.  But this would not mitigate an actual need to encrypt lets say an attached excel spreadsheet containing a wealth of confidential information.  I do see a check for Attachment Content and the description says "This rule attempts to scan only content which the user would view as being an attachment."  So do you think if I changed this to two separate policies, ABA Numbers-Body (checking just the body) and ABA Numbers-Attachment (just checking an attachment) it would mitigate this issue?

SInce there is no advanced logic in a content filter (its only if ALL conditions match or if one or more conditions match), we cannot combine it, because we also have If Subject does not begin with !m  (this is our internal over-ride code we publish to our employees as a last resort to ensure a message is NOT encrypted if the end user is having serious issues, or the system continually encrypts something it shouldn't).

[keithsauer507]

SR: 635498525 created.  I'll update the post with whatever the Cisco engineer finds.  

[Mathew Huynh]

Hello Keith,

From the content filter rules of message body or attachment, it would not be looking into the headers of the emails.

(as per my tests using the similar rule).

As you have a case open with a Cisco Engineer, please let us know what is found -

Regards,

Matthew

[keithsauer507]

Ok the cisco analyst gave me the following bit of information.  I have yet to implement it though.

Here is a new filter that you can create just above the ABANumber filter, to get it skipped-

Go to CLI:

--------

skip_ABANumber: if (header("X-MICROSOFT-CDO-OWNERAPPTID") == "[0-9]{9}")

{

skip-filters();

}

.

Commit the changes.

[Mathew Huynh]

Hello Keith,

This filter will work to allow the email to bypass other message filters.

But from what I've read you're currently using a content filter with ABA smart identifier is that correct?

If you tested an email without any message attachment and just with the header; does it still trigger on the content filter?

The content filter rules would not look into these custom X headers to be matched.

There may be something else within the email that is matching it.

If you could edit your content filter with an additional action "Add Log Entry" and the text box put "$MatchedContent"

Then submit and commit this and attempt to replicate it.

It may show us what bit of the email is matching it.

Regards,

Matthew

[keithsauer507]

Its difficult to recreate the issue.  This occurred from a calendar invite sent outside from Outlook.  Exchange server applies a random id number to that property in the header.  I guess the ID number for the VP (It's ALWAYS upper management with these kind of issues!) happened to be some banks ABA number.  I'm not sure how it knows its an ABA number, like if it uses some kind of online service to see if its owned by any particular financial institution. 

So to test I would have to send basically thousands of calendar invites out and hope one of the counters or message ID's ends up being the same as some banks' ABA number.

I verified in message tracking that it was this header value triggered.  It shows the number triggered and when you download the entire message, all parts and do CTRL+F for that number in only hits in that one place, X-MICROSOFT-CDO-OWNERAPPTID.

[Mathew Huynh]

Hello Keith,

From testing I was unable to get message headers to trigger on my filters.

If these calender emails had any form of additional attachments, the filters (should it be scanning in attachments or files that is not plain text on the body) will look into the actual source coding of the files which may be the trigger.

Are you able to get a sample of this calender invite that triggered in it's original format for me to have a quick look?

Thanks,

Matthew

[keithsauer507]

He just sent it as a calendar invite using Outlook 2010.  Nothing in the body except our standard email signature and disclaimer that is applied from CodeTwo exchange rules.

Attached is the message part containing the matched content '279017439'.  In Message tracking there are three message parts.  This is the third one called [unnamed&nbsp;file] at 2.83 K text/plain.

The first one [message&nbsp;body] is simply the text format of the signature / confidentiality statement in text/plain.  The second one [message&nbsp;body] is the HTML version of the signature / confidentiality statement.  So it was the third message part which I guess is a part of a calendar invite.

Its luck of the draw though because you never know if the random number that Exchange generates for the ID in the calendar invite is going to end up becoming the same as some financial institutions ABA number.  Its almost like winning the lottery.

[Mathew Huynh]

Hello Keith,

I would suggest enabling a log-entry action on your content filter with $MatchedContent so we can see the exact string that caused the match as well

And if possible obtain the original email that was matched with all it's contents, change it to .eml so you can open the raw source of the email and locate this string if it's apart of the text body of the calender or if it was within the embedded mime coding of the calender attachment.

If it's the latter where the actual MIME source is causing the match, we can alter the scanning procedures on your ESA to not look into the MIME source if required for attachments, but you'll need to speak with microsoft for the MIME type or fingerprinting of the calender to bypass scanning

(From a google search)

The type for vCalendar seems to be text/x-vcalendar (source: original standard.)

For iCalendar (the newer format), the answer is text/calendar (source: RFC5545).
 

Or if this is not known, there is a setting to not scan the fingerprinting/mime structure of all attachments (But not recommended)


These changes can be done in CLI > scanconfig > setup > And skip by MIME type.