The MailStore Customer Security Awareness Initiative: Why Security Is Our Top Priority

In an increasingly networked world, data protection has a crucial role to play – and not just since the introduction of the GDPR. As we’ve seen from the malware Emotet, which has resurfaced with a spate of new attacks after a five-month absence, email security remains critically important. As a rule, this form of “mal-spam” shows up in legitimate-looking emails that entice users to open macro-enabled Microsoft Word documents. To give the impression of trustworthiness, the malware will often try to join current email conversations. Another major threat is what is known as spear phishing, which recently hit the headlines in the Twitter hack.

The common feature linking both forms of attack is that they will exploit any knowledge of conversations, topics, and the relationship between contacts to gain the victims’ trust: the latter end up unwittingly helping the perpetrators to achieve their aims.

In the following article, we explain why it’s so important to protect mailboxes and email archives from unauthorized access, and discuss the technical precautions we’ve implemented in recent years to provide installations with the highest level of protection from the get-go.

Security

The Value of Information

Have you ever asked yourself what the content of your mailbox reveals about you? Probably not. Today’s mailboxes are a colorful, almost unmanageable agglomeration of quotes, documents, conversations, memories, worksheets and much more besides. Sophisticated search functions and assistance systems are always on hand to help us locate the exact information we’re desperate to find.

But viewed from a distance, it’s clear that a mailbox is a kind of logbook charting the digital lives we lead – whether at home or in the office. For example, confirmation emails permit conclusions to be drawn about when and where we placed an order, messages from the social networks reveal our contacts in the digital world, while “welcome mails” or requests to “kindly reset your password” provide insight into other services we might be using.

If many of these everyday emails seem important when they arrive, we’ve usually forgotten that they even existed a few days later. Hackers, on the other hand, rate this treasure trove of data very differently: once a mailbox has been accessed, these details furnish precisely the valuable information needed to launch targeted attacks on companies or individuals.

Protection on All Levels

The same applies to information stored in an email archive, and this poses a whole series of challenges for an email archiving solution when digital data in the three “states” listed below has to be protected adequately and on an ongoing basis:

  • Data in transit: data sent between various computer systems
  • Data in use: data processed on non-persistent storage resources (e.g. RAM, CPU cache, etc.)
  • Data at rest: data stored permanently on persistent storage resources

Since MailStore products store and process data locally, security-related requirements can be complied with relatively easily either by the product itself, or with the aid of local hardware and software components. However, when data is being transferred (data in transit), at least one other remote station is always involved, which is why providing adequate protection during transmission is always a team effort.

Having significantly improved the way in which MailStore 10 protects data at rest (for example, by fully encrypting the databases used to store the email metadata), we have since turned our attention to developing methods for protecting data in transit.

A deciding factor here were announcements four years ago by various browser manufacturers, including Google, on how pages accessed via unencrypted connections would be treated in the future. As early as April 2015, Mozilla announced its intention to phase-out support for non-secure HTTP, without, however, setting a specific date for the change.

Warning Form Fields
At first, warnings were given only for form fields.
Source: https://security.googleblog.com/2016/09/moving-towards-more-secure-web.html

 

Warning HTTP pages
Later, any website called via HTTP was branded non-secure.
Source: https://blog.cloudflare.com/https-or-bust-chromes-plan-to-label-sites-as-not-secure/

 

Consequently – unless the administrator had taken steps to secure the MailStore service, e.g. by deactivating access via unencrypted HTTP connections – users of MailStore products would have received warnings that they were about to enter a non-secure website each time they visited MailStore Web Access, and possibly also while using the Outlook Add-in.

The only logical consequence for us was to dispense with unencrypted connections altogether and examine all our existing software to ensure that this approach was feasible.

The MailStore Customer Security Awareness Initiative

At the end of 2016, therefore, we put together a multi-level catalog of measures that featured, among other things, a threat model for analyzing potential risks and outlining appropriate solutions. Both inbound and outbound connections were considered equally. We then analyzed the potential impact on the users of our email archiving products. Quite early on, it became clear that a purely technical approach to managing the necessary changes would not be enough to “get customers on board” and join us on the road toward security by default.

Therefore, alongside our development work, we decided to launch an internal Customer Security Awareness Initiative with the aim of raising awareness of IT security and data protection among customers. This gave rise to a series of publications, such as MailStore Is Keeping an Eye on Security: Enhanced IT Security for SMEs, and Admins enjoy more Secure Mobile Access to Email Archives using TLS Encryption, which aimed to underline the rationale and user benefits based on examples from everyday working practice.

The Road Toward “Security by Default”

Based on our knowledge of what needed to be done to attain the goal of “security by default”, the necessary changes were carried out at what we considered reasonable minimum intervals. Over time, these became specific release versions, and the change history below shows which changes were implemented when:

Version Appeared Change Rationale
10.1 03/29/2017 STARTTLS as default in new archiving and export profiles Most contemporary email servers offer encryption by default.

Many email providers no longer permit unencrypted logins.

10.2 10/18/2017 New, responsive MailStore Web Access available only via HTTPS

 

In accordance with our corporate policies, new product developments must comply with the latest security standards.
Highlight Legacy Web Access as non-secure Legacy Web Access still permits logins via unencrypted HTTP.
11.0 04/18/2018 Integrated IMAP server does not permit logins via unencrypted connections Email clients usually test for encrypted connections during set-up. For this reason, impact on customers expected to be minor.
11.1 07/18/2018 Password policy The password policy guards against the use of overly simple passwords.
12.0 04/10/2019 HTTP for Legacy Web Access and Outlook Add-in deactivated by default in all new installations Option of sending login data to MailStore Server in unencrypted format to be prevented in new installations.
Support for importing own certificates and requesting Let’s Encrypt™ certificates during installation and service configuration During installation of MailStore Server, there should be a simple means of enabling trusted certificates to be used to avoid users receiving warnings when using Web Access or the Outlook Add-in.
Admins to be alerted on the admin dashboard and in profiles to the fact that their outbound connection settings were not secure Alert level “Information”: the initial aim here was to raise awareness for the problem of login data for MailStore products being sent unprotected to third-party systems.
13.0 07/15/2020 Support of unencrypted HTTP connections fully discontinued After a three-year transition period, the objective was to ensure that MailStore products would accept only encrypted inbound connections from now on.
Alerts that non-secure outbound connection settings were being used changed to actual warnings Alert level “Warning”: the new alert level aimed to motivate administrators to ensure that login data was transmitted securely.

Shift of Responsibility

In many respects, the “security by default” approach will see responsibility shifting away from the administrator (in the past, it was the admin who was responsible for ensuring that software solutions were secure enough) toward the software manufacturer. Having dealt with security matters from all angles throughout the entire development process, the software manufacturer will inevitably know much more about potential threats and how to repel them and, thus, be in a perfect position to deliver software with secure default settings.

Also, far from operating inside a bubble, we as manufacturers of email archiving solutions are constantly having to respond to global trends and changing requirements, something that is becoming increasingly noticeable with the latest security demands placed on cloud services. Support of modern authentication for Microsoft 365 and Google G Suite was implemented in MailStore 13 for good reason!

That being said, this paradigm shift does not absolve IT managers of their obligation – especially when different systems are interacting – to regard their own network as part of a global network to a greater extent than was perhaps usual in the past and, thus, to implement up-to-date security measures as a matter of principle.

In our upcoming blog articles, we want to take a closer look at some typical threats and show you how MailStore 13 can provide effective protection with just a few tweaks.

More Information

If you’d like to learn more about security, we recommend the following blog articles on our products and product strategy:

Product-related articles on the subject of security:

More articles on the subject of security:

About theDaniel Weuthen, Director of Engineering Author:

This article was written by Daniel Weuthen. Daniel is Director of Engineering at MailStore Software GmbH.

Sharing


Leave a Reply