Periodically, users need to send things which may be of a sensitive nature to people at partner organizations. Sometimes, they don't realize that what they are sending needs to be encrypted, or they realize, but are trying to get around the system. For those cases, the MEG Content filtering and DLP features are key. Sometimes, however, users need to be able to send something encrypted and want to do it the right way. To that end, how can we help users to do the right thing with our data? There are a couple of ways to set up an encryption flag that the MEG can read. This article will go into two such methods.
The first of these mechanisms is via the implementation of a keyword in the subject of the email. Customers who previously had IronMail will recognize this as the [SECURE] flag at the beginning of the subject line. Users who want to send an email and ensure that it gets encrypted can simply add [SECURE] (or some variant thereof, as defined by the organization) to the beginning of the subject line and that message will go securely. To enable this, it is ncessary to configure a Compliance dictionary to search for [SECURE] in the message subject, like this:
Next, create a Compliance policy under Email Policies to look for this dictionary to be triggered and cause mail to go with Encryption based upon that flag.
By doing this, we have set up the appliance to handle secure delivery. Note, however, that the recipient of this message will also receive the subject line tag, as the MEG has no facility to strip content from the subject, only to add to it. This is in contrast to the IronMail appliance which could strip this sort of thing out. Thus, tags configured in this way should be designed to be as innocuous and/or professional as possible.
The second way to do this requires a little more complicated setup on the front side but, depending on how it is done, may be easier for users to use in the long term. As many of our customers are aware, the MEG appliance is now capable of Hybrid operation. This means that we integrate with the McAfee SaaS service for initial inbound scanning. Many SaaS customers also used outbound compliance scanning, and to do this, the SaaS team produced a new tool. This is a plugin for Microsoft Outlook which is initially intended to be used with SaaS, but which the MEG could also use. It's worth noting that MEG support does not provide support for this Outlook plugin, and the plugin is provided as-is. To get this plugin, go to http://download.mcafeesaas.com/encryption_addin/ and follow the links from there.
Once the plugin is installed, an X-Header will be added to the message by this plugin and that header will be used by the MEG to determine whether or not to encrypt. Again, we'll need to create a Compliance dictionary (for 7.6.1 and earlier). This dictionary should be set to scan All Headers in Email Messages and the only term should be as follows:
From there, we'll create an appropriate rule in the appropriate outbound policy, and configure this to require encryption as described above. This is pretty easy, and has the added benefit that this plugin creates a new button in Outlook for email delivery:
Thus, when a user wants to send a message Encrypted, they just click that button instead of the standard Send button below it. Additionally, this is handled via a header on the message, rather than via a tag in the subject line which could end up getting stripped if subject lines get too long or the like.
In MEG 7.6.2, this gets even easier. Instead of going through compliance, go to the Outbound policy appropriate for this purpose and create a policy exception for the Policy-Based action feature. This exception should check for the x-mfe-encrypt: header, and verify that it is set to Yes. Note that this is the only value it should ever have:
On that policy exception, set the MEG to allow the message through and deliver using encryption as a secondary action:
In both of these cases, use the Encryption settings to specify what sort of encryption should be used for sending mail.
Either of these options will allow admins to sleep a little better at night, knowing that users can relatively easily select to send email using encryption when it's needed.
Some of the information and screenshots here came from Ralf Haas in our EMEA team. My thanks to them for the information and screenshots.