Product Homepage: click here
Free Trial: click here
It has happened to most of us at least once. Either because we are rushing or simply not paying enough attention, we end up sending an email to the wrong person. In many cases, this happens because of Outlook’s AutoComplete feature (also known as nickname cache): we start typing a recipient’s name in the To field, Outlook displays all the recipients we have previously emailed that match the name or letters we typed, and we press enter without paying much attention, causing Outlook to use the wrong, but sometimes very similar, recipient.
Rare are the times this is not an issue. Most of the times it is embarrassing, but for some organizations it can be disastrous. I personally know of several cases where private information regarding a company or a business deal was mistakenly sent to the wrong client. All it takes is a quick search online and dozens and dozens of high profile cases come up where private and confidential data was sent to the wrong recipient, all due to human error.
In this product review, we will be evaluating SafeSend (v4.1.29), a tool that claims to help avoid these situations and prevent the accidental emailing of confidential data outside a company’s domain, by detecting external recipients and attachments in outgoing emails or meeting invites. Using a pop-up message, it requires the user to confirm the external recipient(s) and file(s) before the email can be sent, thereby preventing accidental data leakage, improving security awareness and preventing attacks like spear phishing.
SafeSend is developed by a privately held software company named SafeSend AS based in Olso, Norway. Its main target are enterprises with over 1,000 users that work with sensitive data and, according to SafeSend, it is currently used by hundreds of thousands of users with some well-known and global organizations as their clients.
SafeSend is an add-in for Microsoft Outlook. Being purely a client-side software means that it is installed on each client PC and that no server is required. Its settings are managed centrally using Group Policy that pushes out new configuration to each client PC.
SafeSend works with both 32 and 64-bit versions of Outlook 2007, 2010, 2013 and 2016. According to SafeSend’s documentation, Office 365 ProPlus is also supported as long as click-to-run is not used as some add-ins do not work on Outlook click-to-run installations. However, during my tests all features of SafeSend seem to have worked just fine with a click-to-run installation of Office 365 ProPlus (Outlook 2016).
As to the Operating System, Windows 2000, XP, Vista, 7, 8, 8.1 and 10 are all supported.
The last requirement to keep in mind is Microsoft .NET Framework 4.0 or above. Without it, the installation will fail as SafeSend chose not to automatically install or upgrade .NET in order to not change the system configuration without administrators being aware.
SafeSend is supplied as a ZIP file that includes one MSI file and a set of ADMX/ADML files used to manage settings centrally via Group Policy. The MSI file is generated based on the customer’s preferred settings so, initially, no extra configuration should be required. The same MSI file works for both 32 and 64-bit versions of Outlook. Configuring SafeSend is covered in the next section.
Since an MSI is used to install SafeSend, we can manual install it on user’s PCs, or we can deploy it via Group Policy, System Center Configuration Manager (SCCM), MSIexec or any other packaging or installation tool.
Please be aware that the SafeSend MSI file is a per-machine installation file that requires administrative rights. Being a per-machine installation means that all users who log into the same machine and start Outlook will be using SafeSend.
For this review, let’s manually install SafeSend on a test virtual machine using an Office 365 account. To do this, we run the MSI provided by SafeSend:
Once we accept the license agreement and click Install, the installation will begin. There are no options available to configure during the installation:
Simple as that!
Using and Configuring SafeSend
Once the installation is complete, we can start Outlook and we should be ready to go. By running a quick and simple test, we can see that SafeSend is indeed doing its job:
With SafeSend, we are forced to acknowledge/confirm that the email is definitely intended to [email protected], as this address is considered an external and unsafe address by SafeSend. Once we confirm this is our intended recipient by selecting the check-box next to the external email address, we are allowed to press Send.
In case an email is sent to multiple recipients, SafeSend gives us the option to easily acknowledge all at the same time by using the Select all check-box:
The Select all option can be disabled completely, or configured so that users are forced to acknowledge every recipient individually for emails with less than X amount of recipients (after all, we wouldn’t want them to have to manually acknowledge 50 recipients, for example):
So how do we configure this and other SafeSend options? Let’s take a look at that now.
The MSI file I was given came pre-configured with a single safe/internal domain of companydomain.com and the default SafeSend logo. In a real scenario, this would be pre-configured with a customer’s internal domain(s) and the customer’s own logo. Instead of asking SafeSend to re-package the software for me, we can easily change this ourselves.
As I have mentioned previously, ADXM/ADML files are also provided by SafeSend which allow us to centrally control settings using Group Policy:
For organizations with restrictions on using ADMX/ADML files, SafeSend can still be configured by deploying registry keys directly through SCCM or Group Policy Object (GPO). All settings, including the license key, can be deployed this way.
Please be aware that a Domain Controller running Windows Server 2008 R2 or later is required in order to use the ADMX/ADML files provided by SafeSend.
To start centrally configuring SafeSend, we need to copy the ADMX file to C:\Windows\PolicyDefinitions and the ADML file to C:\Windows\PolicyDefinitions\en-US. If you are suing a central store, please use the SYSVOL directory instead.
Once these files have been copied, we can create a new GPO (or use an existing one) and we should be able to see SafeSend’s settings under User Configuration -> Administrative Templates -> SafeSend Email Security for Outlook:
To start with, I am interested in configuring the safe domains list so that my lab’s domain (nunomota.pt) is not treated as an external or unsafe domain, like in the following example:
To do this, we navigate to the Commonly used folder and update the SafeDomains setting with our internal domain(s). Once again, this is usually done by SafeSend when a customer buys the product, but since adding accepted domains in Exchange is not that rare, organizations might need to do the same eventually.
Once the user receives the updated GPO, sending an email to an internal user will not trigger SafeSend (notice how Nuno was not included in the popup):
This feature is also useful to whitelist certain trusted partners an organization might regularly do business with.
An easy way to verify if a policy got applied to a user, is to check all the settings currently applied to the user by navigating in Outlook to File -> Options -> Add-ins -> Add-in Options -> SafeSend:
Clicking on View settings... will display all the SafeSend settings applied to this particular user. In this case, we can see that nunomota.pt is now a safe domain:
The Overrides HKCU/Policies tab shows all the settings we have configured so far that deviate from the default settings (most of which we will be discussing shortly):
We can also view this same information using the Registry. The default settings of SafeSend are stored in HKLM/SOFTWARE/WOW6432Node/SafeSend:
Whereas the per-user settings are stored in HKCU\Software\Policies\SafeSend:
There is also an Edit settings… option that allows us to manually configure settings on the local machine for testing purposes. However, please be aware that these are reset when Outlook is restarted.
Most users might not be too happy if they are forced to acknowledge every single email they send to external recipients. A useful approach to minimize or prevent user’s dissatisfaction towards SafeSend is, in my opinion, to only trigger SafeSend when an email is sent to an external recipient that contains an attachment, which should provide a good balance between usability and security for most organizations. To do this, we enable the OnlyPopupForAttachments setting:
We can also configure SafeSend to only trigger when users compose a new email. After all, if a user is replying to an email, it is unlikely they will send it to the wrong person, unless they start including new recipients in the email. This can easily be done with the OnlyPopupForNewEmailThreads setting:
SafeSend currently supports an impressive 30 languages. To set SafeSend to use the same language that Outlook is configured with, all we need to do is enable the advanced option UseLocalizedLanguage:
Now SafeSend will use the same language as Outlook!
Users typically ignore the company’s email usage policy and, most of the times, are not aware of how corporate email should be used. You might have noticed from previous screenshots that SafeSend can include a policy message stating, for example, that email should comply with the organization’s email and security policy and include a link to the organization’s policy on email. This feature is disabled by default, but can be easily configured by enabling the PolicyLink option and specifying a URL for the organization’s email/security policy:
SafeSend will show, by default, the following line of text:
As all other text in SafeSend, this can also be customized using several settings, such as StringMainPolicy, giving organizations great customization flexibility:
Distribution Groups and High Profile Mailboxes
It is common for organizations to have some internal Distribution Groups restricted so only particular users can email them, or have these configured with moderation so that emails have to be reviewed before being sent to the group. SafeSend can also be used to provide another alternative and force users to acknowledge they intend to email a certain distribution group. By configuring the TreatMatchingExchangeDLNamesAsExternal setting, we can configure the group(s) that will trigger SafeSend:
Now, any group whose display name starts with “Dept – “ will trigger SafeSend. In the following screenshot, notice how the departmental groups triggered SafeSend, but not the IT ServiceDesk group:
It is also possible to trigger SafeSend before sending to specific email addresses using the TreatMatchingEmailsAsUnsafe setting. Useful to alert users when emailing VIPs for example.
Software will always be software, and sometimes things do not work exactly the way we expect them to. To help administrators troubleshoot any possible issues, SafeSend includes several logs. The following log file describes the SafeSend’s add-in loading process that occurs when Outlook starts: C:\Users\<username>\AppData\Local\SafeSend\adxloader.log. This can be useful in situations where SafeSend is not loading or simply to see what happens when the plugin is loaded:
Talking about Outlook loading SafeSend, this add-in seems to load quickly even in my lab’s test workstation. This is important to both avoid user frustration and Outlook from disabling the add-in (which can happen if an add-in takes too long to load):
Besides this log, SafeSend can also log all the actions taken by a user to both a physical file and to the Windows Event Log. This can be important in compliance or auditing scenarios where an organization needs to prove that a user was presented with a popup but decided to send the email nonetheless.
These two options are configured using the LoggingFileLogEnabled and LoggingWindowsEventLogEnabled settings respectively:
The log file is stored under C:\Users\<username>\AppData\Local\SafeSend\ and contains who sent the email, the email subject, the email addresses of the external recipients and the files attached, if any.
The event in the Application log has an EventID of 0 and a Source of SafeSend and contains the same information:
Preventing users from disabling SafeSend
By default, users can enable or disable Outlook add-ins as they see fit:
As a security tool, it is imperative that users are not able to circumvent SafeSend. For Outlook 2007 or 2010, SafeSend cannot prevent users from disabling the add-in, but it can re-enable it each time Outlook starts. With Outlook 2013 and 2016, we can use Group Policy. To do so, first we need the Office 2013/2016 Administrative Templates. Once we have that in place, we enable the List of managed add-ins policy setting and add zzz.SafeSend with a value of 1, meaning that SafeSend cannot be disabled by users:
Now SafeSend cannot be disabled or removed, and users are presented with a notification informing them of that:
Data Loss Prevention and Encryption
Although outside of the scope for this review, I fell it is important to mention SafeSend’s DLP Content Scanning capabilities. With this feature, SafeSend scans email content (including attachments) for specific keywords or data patterns using regular expressions. If a match is found, we can choose to notify the user, require a confirmation from the user, or deny sending the email altogether:
Another possible action for when a match is found, is to ask the user if they want to encrypt the email when sensitive content is found by using the TriggerEncryptionMode setting:
Additionally, the same setting can be used to ask users if they want to encrypt any email, or only ask them when attachments are found.
It is important to note that SafeSend does not perform the actual encryption. Instead, it adds a configurable string to the email’s subject which can then trigger the encryption itself by Exchange, ProofPoint, HPE SecureMail or other mail devices or services. Nonetheless, this is a great feature that reminds users to encrypt emails, making it easier and more convenient to do so.
SafeSend is a great product that does exactly what it says it does, and more. The fact that it can be easily deployed to multiple users using a GPO, SCCM or other packaging tool, plus the fact it can be centrally managed using GPOs makes it extremely easy to deploy, configure and maintain.
As we all know, most users don’t like change, and some organizations might have a hard time convincing users of the benefit of a few more clicks before sending an email. However, in some organizations security is paramount and I believe SafeSend can be configured to establish a good balance between security and usability, and still help protect an organization’s private and sensitive data.
MSExchange.org Rating 4.8/5