I'm in the midst of NDLP + MWG + MEG + HDLP saga. I'm also ostensibly local to you if your monicker is accurate.
If you want to inspect IM traffic, I don't think MEG is what you want, though I could be wrong. While I've heard MEG 7 did grow out of the web and email security appliance, I've never done anything with the "web" portion of my new MEG 7 boxes. I've only played in the email config piece.
At least as far as I know, you'll want an SSL middling web gateway product (McAfee web gateway, Bluecoat w/ the SSL inspection license, Websense) that proxies IM, and can crap it out via ICAP to an NDLP Prevent appliance. NDLP Prevent will take a ICAP feed, analyze it and respond back to the ICAP request with a go/no go, and the web proxy can selectively block it or pass it.
After further reading and a discussion with McAfee team finally. You are correct. For all IM / WEB you do need an ICAP compliant proxy to work with DLP Prevent to work. I am going to hopefully be able to test squid for this. We are attempting to reduce additional costs.
I want to understand the benefits of MEG however as well. Someone previously bought 2 appliances but we have an interesting messaging infrastructure to deal with as well.. hybrid cloud / on-premise.
It seems that MEG is an extraneous hop for just DLP needs only, since we have other scanning and MTA solution in place.
I an in the Chicago land
Thanks for input.
Can your existing scanning MTA be configured to do things like selectively block, forward, or quarantine messages based on the values of, say,
X-RCIS-ACTION: headers (ALLOW, BLOCK, BOUNCE, ENCRYPT)?
If so, no you don't need MEG to do constructive email DLP with NDLP Prevent. NDLP Prevent can work with a variety of commercial email gateways so long as they are policy configurable to do things based on a header that NDLP Prevent will add after analyzing an email message.
yes it does.thanks