This week, I'd like to highlight the GTI feature of our MEG appliance.  This feature has been implemented since EWS version 5.6, but many people don't understand what it does or how it does it.  In the interest of improving the understanding of this feature, let's dig into some of its capabilities.


GTI, or Global Threat Intelligence, was borne out of a product McAfee acquired from Secure Computing called TrustedSource.  Originally, TrustedSource was designed to handle message reputation filtering of email, and that was its sole applicability.  Then, as now, TrustedSource looked at the message's source IP and a number of hashed fingerprints of the message.  As with all hashes, these are one-way, and the actual message content cannot be derived from them.  The TrustedSource servers would take the IP address and the fingerprints, do a lookup in the reputation database we have, and assign a score based upon the results of the lookup.  Scores range from -150 or so to +220, and the larger the score in a numerically positive direction, the higher the likelihood that the message was a spam message.  Any message with a TrustedSource score of 80 or more can safely be considered spam.


As TrustedSource was being rebuilt into a major part of GTI, McAfee added URI capabilities to the basic features of TrustedSource.  Now, in addition to the source IP and a list of fingerprint hashes, the appliance also sends a list of URIs found in the message.  These URIs are now included in the lookup, and contribute to the GTI score.  As before, any message receiving a score of 80 points or more in GTI can be safely assumed to be spam. 


But we didn't stop there.  As mail continues to evolve, Anti-Virus tools have to adapt more and more quickly to the evolving threat landscape.  Here we have a powerful tool which is able to take fingerprints of files and emails and check the frequency and reputation of those hashes.  So we asked ourselves, "why not leverage this technology to improve our AV accuracy?"  So we did.  Now, if the MEG sees an attachment which it considers suspicious, it can send fingerprints of that attachment to our GTI servers.  They can then look up the reputation of that collection of fingerprints.  If we have seen that particular collection of fingerprints before, and they seem to have a strange or malicious behavior associated with them, we can trigger AV to take action against the file in question.


But in order to do all this, we need your help.  In your MEG appliance, there is a feature enabled to submit GTI feedback back to us.  This provides us with generalized information about the mail coming through your appliance.  While it doesn't send us things like email senders, recipients, etc., it does send us things like the final disposition (delivered, dropped, quarantined, etc.) of a particular message signature when the appliance finished processing it, whether any viruses were found, and the like.  All of this is used it to help improve the accuracy of the IP reputation list we maintain as well as the message fingerprints reputation database. 


All that said, what are our recommended settings here?  For feedback, we definitely recommend enabling the GTI feedback feature.  That helps us help you eliminate malicious email.  As for the Sender Authentication feature, we strongly recommend only enabling this feature to function against inbound mail.  To do this, create a policy called something like Outbound in your policy set, and define it with the rule "Source IP" "is" "<your internal mail server IP>".  Obviously, if you have more than one internal mail server, either add the whole list of IPs individually, or add the list as a subnet.  Then, on this new Outbound policy, disable the GTI feature (really, there's no good reason to use any of the Sender Authentication tools here, so you can safely disable them all for outbound mail).  This will ensure that the GTI feature doesn't run against your internal mail server, and, more importantly, ensure that a malicious worm or something which does manage to make it into your environment doesn't cause the MEG to stop taking mail from your internal network for the outside world.