Data Loss Prevention

 View Only
  • 1.  Endpoint Agents Monitoring SMTP

    Posted Jan 25, 2012 12:27 PM

    I have a deployment where we have Network Monitor, SMTP Prevent, and Endpoint Protect deployed.  One of the requirements for the Endpoint deployment is to monitor Outlook.  The reason for this is due to zone-based security requirements, where we need to be able to inspect internal email traffic between internal users.  However, one of the effects of this is that we see duplicate email incidents for any externally delivered email, as we are running the same policy set on Endpoint as we are on SMTP Prevent.  When an incident occurs, we get one Network incident from the SMTP Prevent servers, and one Endpoint incident from the endpoint.

    What I am trying to accomplish is eliminating the Endpoint incident when the mail is destined to an external recipient, since I know it has to go through SMTP Prevent anyway; and in conjunction with that, I would like to avoid creating duplicate policies for Endpoint and Network.  I can't think of a way to accomplish this other than creating separate policies, where one would be deployed only to the Network servers, and the other (which would be deployed only to the Endpoint servers), would have a compound exception for SMTP (protocol) AND recipient matches pattern "mydomain.com" (all recipients must match).

    The Agent Configuration doesn't allow you to create a "domain" type exception for SMTP, which is where I would hope to be able to do this.

    Any good ideas out there?

    Thanks in advance.

    ~Keith

     



  • 2.  RE: Endpoint Agents Monitoring SMTP

    Posted Jan 25, 2012 01:00 PM

    How about addind a policy exception for when:

    the sender matches the local domain
    AND
    the recepient does NOT match the local domain
    AND
    (the endpoint location is on the network OR endpoint location is off the network)

    Maybe the endpoint condition will just filter out the endpoint incidents?

    ~Xavier



  • 3.  RE: Endpoint Agents Monitoring SMTP

    Posted Jan 25, 2012 01:02 PM

    I guess you'd have to create two rules now that I think about it because the policy engine doesn't make embedded OR's easy =/. At least it's still one policy!

    the sender matches the local domain
    AND
    the recepient does NOT match the local domain
    AND
    the endpoint location is on the network

    ++++++++++++++

    the sender matches the local domain
    AND
    the recepient does NOT match the local domain
    AND
    endpoint location is off the network



  • 4.  RE: Endpoint Agents Monitoring SMTP

    Posted Jan 25, 2012 01:28 PM

    Good thought, will have to try that out.  I think you're right, the "Endpoint Location" should limit the exception itself to just Endpoint incidents, which is the part I was missing. As I'm sure you noticed, there's no way to specify the difference between an Endpoint SMTP message and a Network SMTP message...but you might be onto something there.

    Will try to post up on here after I've had a chance to test it out.

    Thanks!

    ~Keith



  • 5.  RE: Endpoint Agents Monitoring SMTP

    Posted Jan 25, 2012 01:50 PM

    Yeah I had picked that up. I thought to myself "but that's the obvious solution...but Keith would know better than that" so I had to check for myself. It would be better if they split them up but I guess Symantec wanted to make the policy building easier?

    Hope it works out

    ~Xavier



  • 6.  RE: Endpoint Agents Monitoring SMTP

    Posted Jan 26, 2012 04:58 PM

    Sounded good at first...but that won't work.  Just went to configure it in an exception and realized the flaw.  There's no way to say "the recipeint does NOT match local domain".  The recipient rule only allows for the match condition, not a "does not match" condition.

    That's one of those things...you read it and it sounds like it would work, but then when you go to put it in you remember it doesn't work that way.  And to do what I want, it has to be an exception.

    Oh well, back to the drawing board.  Thanks for the input though.

     

    ~Keith