Video Screencast Help
Symantec to Separate Into Two Focused, Industry-Leading Technology Companies. Learn more.

MTA Integration for SMTP Prevent

Created: 06 Apr 2010 • Updated: 13 Oct 2010 | 11 comments

1. What are the advantages\disadvantages of REFLECT vs FORWARD MTA integrations?  Is one configuration better, more robust and optimal than the other to handle large volume of daily outbound e-mails (over 150,000 emails)?  Let's say the e-mail architecture in my organization would allow either one configuration.  Which one would be the recommended\preferred solution?

2. Should ALL outbound e-mails be routed via the DLP SMTP Prevent (including application, mainframe, system-generated mail), or only e-mails created by the users should undergo complex DLP analysis and all other should be passed via some other, less sophisticated content monitoring MTA product?

Comments 11 CommentsJump to latest comment

Naor Penso's picture

About your questions:
1) By concept, Forward MTA integration should be better because the MTA has to deal with mails once, and then he forwards the mails to the Mail Prevent Server (DLP) and his job is done. I have used REFLECT mode on a large corporate and there were no performance issues.
In order to handle a large quantity of mails, considering that you have multiple MTA and a Management that supports redundancy you could use multiple DLP Mail Prevent Servers (3 MTA's using 3 DLP servers in REFLECT mode) to reduce the data overflow.

2) I do not know which MTA you use but most MTA's have Active Directory integration, which you could use for your advantage.
You can ignore system alerts (I would not recommend such a act because if someone finds out about that he will be able to establish a local SMTP and send mails impersonating the Alerting device and avoid DLP scan. another thing you could do is to add safe domains that you allow Mails to be transferred freely. there are more ways to reduce the amount of mails like scanning only mails with attachments, Still the safest way is to route all mails through the Mail Prevent Server.

Kind Regards,
Naor Penso
 

For Forum threads, please click "Mark as Solution" if answered.
For all content, please give a thumbs up if you agree with or support the post.
Thanks :)

Margaret_M's picture

1.  The logical concept makes sense for the message to be processed only once; however, I'm looking for the case scenarios when REFLECT has been implemented over FORWARD.  I know of SMTP Prevent users who switched between both configuration (we are one of them) and I'm trying to better understand why.  Sometime real life scenarios dictate one configuration over the other and that's what I'm looking for.  Aside from the hardware\architectural constrain, would anyone implement REFLECT over FORWARD purely from the functional perspective? And if yes, why?

2.  We are sending ALL outbound e-mails via SMTP Prevent, including system, bulk, application etc.  and collect over 5000 incidents a day, which not only fill up the table space and require frequent maintenance, but also bury true violations in this huge volume of mostly normal business mails (i.e. flag message to be encrypted).  As I agree that every e-mails generated by the user should be inspected, what is the added value of inspecting system or bulk e-mails with the known content?  Usually in a large enterprise there is some other MTA with a simple content-inspection capability, sufficient for keyword and RegEx matching that can be applied to system mass-mailings with approved known content.  What is the added value of sending for example monthly mainframe generated e-mails to go under the EDM or IDM inspection? The only way to avoid that would be to create multiple policy exceptions, which adds maintenance and processing overhead.  How can the DLP function be made most effective with minimal resources (1-2 FTEs to do all:  maintain, implement, monitor and remediate)? We already expierienced a processing delay with time-sensitive bulk mail that was undergoing DLP inspection (10 SMTP Prevent rules, some of them using EDM or IDM).  What are the best industry practices? 

Neil Christie's picture

Naor is correct.  I leaned on the forward MTA integration for the reason of the complications it would create by sending it back to the original MTA in reflect mode.  The argument that the engineer from Vontu gave me for "Reflect Mode" was that it would be more fail safe.  I just built in redundancy into the inline setup and that issue went away.

As for your second question, that is a matter of policy.  If you are under strict PCI requirements I would say you should send all email through.  Preferably, since these are in theory all non-user emails you could just monitor that traffic.  Work with the teams creating the emails if they are sending information automatically in a non-secure manner.  Then, just setup active alerting or monitor closely for any new setups that are sending info in a non secure manner.

Good luck.

Paul Aho's picture

Before deciding you need to take a look at your specific use case for looking at emails and the emails that you want to target and the limitations of the email gateways that you are using.  Not all gateways support reflecting.  In my case I implemented forwarding since I'm primaly concerned about external mail flows and only those that are going directly out to the internet.    By using load balancing technology you can create clusters of the forwarding monitors which will allow you to add capacity as necessary. (we run in a N-1 based on peak load, and the monitors run on VM's so adding additional machines is easy). 
One thing that I have noticed is that when you enable blocking with the forwarding method is that the system holds back part of the header while the message is being examined.  I haven't seen this cause any issues but when you are doing a packet-in packet-out compare you will see some differences.

For the second part we made the decision to look at all outbound messages and have found that by doing so we have a better understanding of what people are actually sending out.  Looking at things like the number of attachments in a message(as far as I am aware vontu can't do this and we have our email gateway tag the messages with an attachment count) and message size has resulted in our adding polices for both block and education as a result of seeing what people are sending from their business email address.  

Make sure that you keep stats on any educational work that you do with the vontu tool to look for repeat offenders and to see if you are actually correcting the problem. 

Lastly tuning the policies will help to cut down on the number of messages that you see.   This I find to be the most difficult part since its hard to know what you are going to see before you turn a policy on.  Don't enable additional polices until you can handle the alerts being generated from the last policy. 

Naor Penso's picture

I have to say, 5000 incidents per day is not normal (not by any standards i know of), and it suggests that you need to refine your policies.
I recommend that you disable (not delete) the policy that creates the most incidents (most probably "confidential words" policy).
You can view a report that will suggest which policy is causing the enormous amount of incidents.
It seems that you are in the first stage of implementation am i correct?
If you are in an advanced implementation stage i would recommend you re-examine the methodology used, because over time there should be less incidents, for sure not 5000 incidents a day, which is impossible to work with (you wont be able to examine 10% of the incidents per day).

About the analysis of the All mails as opposed to the analysis of "work" mails only, I still believe that you should inspect all mail, what i can recommend is that you create another Mail Prevent Server and send all of the bulk mail through there, it would ease the pain on the more essential server but would still inspect the alert mails. The issue with these "Bulk Mails" is (as said), that people could take advantage of the fact they are not inspected by impersonation methods.

Kind Regards,
Naor Penso

For Forum threads, please click "Mark as Solution" if answered.
For all content, please give a thumbs up if you agree with or support the post.
Thanks :)

Margaret_M's picture

Naor, we are in the advanced stage of the implementation and the reason we have so many incidents is because we followed the recommendation to pass ALL emails via DLP (including the application and system mail) and not to use a secondary content inspection MTA for a simple keywords and pattern matching.  As result SMTP Prevent became a "safety net" for catch all, rather than a true DLP implementation.  At this point we monitor every outbound message for content that may resemble DL number, SSN number etc. (PII - no PCI data). By starting this discussion I'm looking for used case scenarios outlining the most optimal configuration for implementing DLP content monitoring.  The goal is to protect ALL emails (mark for encryption, redirected to TLS or VPN, etc), but at the same time be able to benefit from the true DLP features - EDM, IDM, DGM, senders\recipient criteria etc. 
I know exactly which policies are generating the most alerts for us and would gladly suspend them, but if I disable them or exclude certain senders, I will be introducing potential risk of e-mails containing PII to go out in clear text.  I can't use the EDM feature  to reduce the incident volume  as we do not have resources to create and maintain the EDM file at this time.  What I was thinking to do, was tho use a secondary MTA for basic keyword and pattern matching to handle the volume of normal business correspondence to ensure the PII is protected, and reserve the DLP features for true monitoring policy violations, reporting, etc.  However, I've been hearing a lot of mixed opinions about using the secondary content-inspection system in addition to SMTP Prevent, thus my posting to this forum.
We have 4 Prevent servers, but all emails are distributed equally via load balancer.  I have no way to dedicating one box to system e-mails only.  Can anyone think of other network controls to prevent a physical employee from tapping to the mailer application to circumvent the normal e-mail flow?

Alex Foley's picture

I would echo some of the comments above -- 5000 incidents a day isn't out of the question for us (I think the last day I looked was 3500), but we have both dozens of Symantec DLP servers and dozens of analysts.  An earlier email mentioned 1-2 FTEs maintaining all aspects of the DLP environment... if you're looking for what a good baseline # of incidents is, you should figure out how many incidents the average person can handle in a day (50-100?) and build your policies to generate no more than that amount.

That being said, if you have the least number of policies turned on to comply with regulations or adequately protect your environment and you still have more than 200 incidents a day, perhaps it is time to consider implementing EDMs or conduct a false positives analysis to remove common FPs or a sender analysis to automatically dismiss any machine sender email but retain the content.

If you don't have the resources to process all of your incidents but think you're generating the right number of incidents, you have to use an outliers analysis until you can get the resources to analyze every incident or reduce your false positives.

---
Alex Foley

Naor Penso's picture

The recommendation  weather to send all mails or not does not relate to the fact that you get 5000 incidents a day.
I would recommend you remove any word DCM rule you have associated to the mail prevent server.
I think that there are only 2 DCM rules that should be applied:
1) DI (Data Identifiers) such as: SSN,Credit card number, Swipe card number and more.
2) code-names/project names (for example: nemesis. the possibility that a standard mail would contain such a word is small, and you can narrow down your search for confidential data). 
try basing all your rules on IDM or EDM. I saw that you do not use EDM profile at the moment, but i suppose you have IDM at your disposal.
I think that if you minimize the amount of policies and minimize the usage of DCM rules you will have no trouble scanning all of the corporate mails.

In your implementation, did you refine your policies for less false-positives?
From the 5000 incidents you get per day, how much per cent of them would you define as "False-Positive"?

Kind Regards,
Naor Penso

For Forum threads, please click "Mark as Solution" if answered.
For all content, please give a thumbs up if you agree with or support the post.
Thanks :)

Margaret_M's picture

Let me rephrase my question: would it be against DLP best practices to send predefined, automated daily business correspondence containing KNOWN elements of PII directly to the NEXT MTA for further action i.e encryption, secure mailing etc?  How other DLP users are handling automated daily customers notifications if these notifications contain any PII elements?  In the MTA Integration guide, in section describing the REFLECT mode I found a statement recommending NOT to send system\application mail through DLP.  Would this be the same for FORWARD configuration?

Alex Foley's picture

Instead of monitoring for these messages and steering them to a different MTA if they contain PII, we instead generate a daily report and notify the owners of the automated mailboxes that they need to encrypt these messages -- usually the easiest option is for them to use our secure messaging appliance by appending a predefined trigger word to the front of the subject line of future messages.  We decided not to automatically encrypt these messages because unless the end user is prepared to accept an encrypted message, he or she might be confused and we would be to blame.  In this way, the owner(s) of the message(s) can develop their own plan, take responsibility for encrypting not only this PIIbut future PII, and keep us in the loop.

And by "system mail", did the writers of the MTA integration guide mean undeliverables, etc.?  These make sense to ignore to me -- basically any system message that is simply autoforwarding another...

---
Alex Foley

Margaret_M's picture

I'm not sure what they meant, but I'm assuming any automated application\system messages.

"Vontu recommends you configure outbound messages automatically generated by the Prevent-integrated MTA to bypass the Network Prevent Server (Email)."

Thanks for your input.  That was exactly my thought - to flag the known application mailing for encryption at the source and direct them straight to the encryption appliances, rather than DLP.