Exchange 2013 introduced, among other features, the feature known as DLP – Data Loss Prevention (http://technet.microsoft.com/en-us/library/jj150527%28v=exchg.150%29.aspx). I did some tests of this feature and would like to share with you the results I’ve got.
Document Fingerprinting (http://technet.microsoft.com/library/dn635176%28v=exchg.150%29.aspx) added the ability to create user-based templates wich could help define sensitive types of documents used in an organization – that was what I was keen to test in my test lab. Here’s my first scenario: suppose there’s a highly sensitive document (or documents that are created based on it) that an organization would never permit to be sent as an attachment (.docx file). So my goal is to ensure a user can not send that sensitive docx file (and any docx files derived from it as well) while having the ability to send other docx files (the ones not containing sensitive information).
First of all please take a look at my sensitive document SensitiveDOC.docx
…and on the docx file that’s similar to the SensitiveDOC.docx but with completly different wording (NonSensitive.docx):
Now we must “fingerprint” the SensitiveDOC.docx and create a DLP policy that prevents users from sending such information. Here I’d like to draw your attention to the following:
1) as this page (http://technet.microsoft.com/en-us/library/dn635176%28v=exchg.150%29.aspx) says “The patent template contains the blank fields “Patent title,” “Inventors,” and “Description” and descriptions for each of those fields—that’s the word pattern. When you upload the original patent template, it’s in one of the supported file types and in plain text. The DLP agent uses an algorithm to convert this word pattern into a document fingerprint, …”
– the words being used in a template DO MATTER !!! According to this explanation I’m expecting to have sending of SensitiveDOC.docx prohibited while sending of NonSensitiveDOC.docx allowed.
“The transport rule agent that enforces DLP policies does not differentiate between email message attachments, body text, or subject lines while evaluating messages and the conditions within your policies. ” – that’s why sensitive information contained in an attachment must be examined by the transport rule agent: it does not matter whether it is contained in a email body or in an attachment.
Let’s start Exchange ECP and go to the “data loss prevention” page:
…and add the Policy Tip (although in this configuration it won’t show up):
Now let’s create a custom DLP policy:
…create the rule:
We must choose “The message contains sensitive information” in the “Apply this rule if…” field:
Here’s the dialog that allows us to load our template:
We’ve completed adding the DLP policy and can proceed to testing this policy in Outlook 2013:
I compose a message to Administrator with the template itself as an attachment:
The result: delivery has failed as expected:
The result: DLP policy has prevented this message from being sent too!
Despite the fact that NonSensitive.docx file has completely different wording it was subject to be processed by our DLP policy!!!
Now I’ll try to send a file (Test.docx) that has a different formatting, not just different wording:
Conclusion: Document fingerprinting in Exchnage 2013 SP1 can be not as accurate as it should be and, as we can see, it may not take into consideration the words containing in the template, although Exchnage documentation states it should.
Here should come the artcile titled Exchange Server 2013 Mailbox Auditing Part III, but for now I have serious doubts that I would ever venture to deploy Exchnage Server 2013 in my company, at least Exchage 2013 -2013/CU3. Why? Let me explain.
I’ve been using Exchange Server for about 15 years: the first version I deployed was Exchange Server 5 for Windows NT and this and all subsequent versions, of course, had various bugs – that’s normal for any software, especially for a just released software (frankly speaking I can’t remember any bug in Exchange 5 – it worked just fine in my company – but I think it’s hardly possible for any software not to have them), but it’s normal only in case something doesn’t work as expected! I mean when some feature is designed well but its implemention has some issues – it’s normal. But it’s not normal when a new feature itself starts producing issues on a server! I’m talking about Managed Availability – a new feature that must continiously monitor a server and take appropriate actions should any failures occur.
First of all, the way the Managed Availability works is rather strange for me:
“When something is unhealthy its first action is to attempt to recover that component. Managed Availability provides multi-stage recovery actions – the first attempt might be to restart the application pool, the second attempt might be to restart service, the third attempt might be to restart the server, and the final attempt may be to offline the server so that it no longer accepts traffic. If these attempts fail, managed availability then escalates the issue to a human through event log notification.”
– please pay attention to the fact that even the third step in this procedure is not serious enough to notify an administrator of a server problem, so MS suppose Exchange Server itself must decide whether to restart a server or not… What if there’s some other software working on the same machine that should not be restarted? Why not let an administrator know that something is going wrong on a server PRIOR TO rebooting???
But the things that suprised me the most in Managed Availability are 1) the lack of the official information (at least by the time Exchange Server 2013 was released) on the origin of the messages coming to/from the following address : inbound@inboundproxy .com 2) the problems that arise because of these messages.
When for some reason a message from inbound@inboundproxy .com (the address used by the Exchange Server 2013 Health service) does not reach a monitoring mailbox Exchange Server generates an NDR message to inbound@inboundproxy .com that can not be delivered because this address does not exist. So these messages get piled up in the corresponding queue. Of course, we can circumvent this issue by adding
Add-ContentFilterPhrase –Influence BadWord –Phrase “Inboundproxy”.
ass written here http://social.technet.microsoft.com/Forums/en-US/171b518d-1503-4230-a844-531432c290f9/undeliverableinbound-proxy-probe?forum=exchangesvrgeneral
…but trying to get rid of messages that Exchange itself generates for monitoring purposes… I don’t understand it… And I don’t understand why there was no any information on this “feature” on MSDN or technet by the release time: a lot of administrators were puzzled by the traffic from/to inbound@inboundproxy .com on their servers and were not able to find corresponding info, for example:
One more “field of interest” in Exchange 2013 is its interactions with DNS service: as far as I see a lot of different issues may arise from unexpecting behaviour of Exchange Server when it uses dns:
In my case (the first two posts) all these weird errors in Event Viewer (ID 36874, …) are gone as soon as I add Exchange Server machine to its Hosts file (please note that ID 36874 means there’s a TLS error, but Outlook by default uses HTTP connections internally so how there could be SSL-related error?).
Yes, you can say “disable Health service, add Exchange server to Hosts file and enjoy Exchange 2013”, …but there appears to be an apprehension that there can be some other strange issues or even features in this version of Exchange.
Furthemore, I find it rather strange when MS first introduces separate roles in Exchange Server 2007, continues using the same roles in Exchange Server 2010 and suddenly rolls back in Exchange 2013 by reducing the number of roles just to CAS and Mailbox. And in spite of having just two roles Exchange 2013, for example, still has “implicit” Hub role with its own log folders. It looks like MS doesn’t know in wich way their mail product should develop.
So I think the current release (even with CU3) is not stable enough to be deployed in production environment. I very much hope a new version (or SP) will be better.