Email is a crucial tool for exchanging business-related information.
However, when it comes to exchanging sensitive types of information, such as confidential documents, commercial contracts, or financial data of employees and customers, security measures have to be taken.
Taking into consideration that our mailboxes have effectively become storages that comprise big amounts of confidential data, they are subjected to sophisticated cyberattacks. In the long run, it can lead to a potential data breach.
With that in mind, the task of securing sensitive data narrows down to a simple yet effective solution — encryption.
One of the encryption standards used to encrypt emails in Outlook is S/MIME, Secure/Multipurpose Internet Mail Extensions.
Although it is not widely utilized, S/MIME prescribes end-to-end email encryption and allows email clients to digitally sign the contents of an email before it is sent over the Internet.
For S/MIME to work correctly, some preliminary work has to be carried out: both sender and recipient have to configure certificates in their mail applications.
In order for S/MIME to encrypt emails in Outlook, two communication parties must install a digital certificate and obtain public keys to validate those certificates. Suchwise, the digital certificate guarantees to the recipient that you are the true sender of the email.
Those certificates can be obtained either from a public Certificate Authority (CA) or a security administrator of an organization. In Public Key Infrastructure, or shortly PKI, CAs are the ones who provide, store, revoke, create and issue digital certificates.
PKI is crucial in terms of protecting sensitive data because it facilitates e-commerce operations, secures electronic transfers and helps emails to stay confidential.
Public key infrastructure implies generation of a pair of keys, where the one is public and the other one is private. These two keys are linked to each other mathematically and in essence are numbers with certain properties.
In the PKI, the recipient's public key is used to encrypt the sender's outgoing messages. The private key, on the other hand, is used to decrypt the messages.
The sender uses the recipient's public key for message encryption. In case an attacker had intercepted the public key, it still would have been useless, because to decrypt the message he or she needs to possess a private key (that belongs to the recipient).
Digital certificates, issued by CA, are used to sign a message to prove sender’s authorship. This ensures a message has not been forged in transit. If, for example, the signed document was somehow changed afterwards, the digital signature will not pass the validation. Such a warning should be a red flag to any user — a potential man-in-the-middle attack might have taken place.
In essence, signing emails in Outlook using S/MIME narrows down to these three steps:
Once done, two parties can send each other’s public keys to start secure email communication.
Although options and UIs of different versions of Outlook vary, the main principle of enabling email encryption stays pretty much the same.
Generally, email encryption in Outlook includes encryption features that let you share sensitive information (patient health information, bank account details, etc.). After you have obtained your digital certificate and exchanged public keys with the intended recipients, you need to set Outlook to encrypt messages:
Office 365 Message Encryption (OME) is a built-on Azure Rights Management service that allows you to send and receive encrypted email messages between contacts inside and outside of your company to any email address.
There’s no need in special client-side software.
Recipients from the same organization can read messages using different Outlook mail clients. Recipients with Outlook.com and Office 365 accounts can download the attachments from outlook.com. Also, content and attachments can be protected with the Do Not Forward option, making it impossible for recipients to forward such messages.
If you are not an Office 365 user (except Gmail, Yahoo, and Microsoft accounts), you will be prompted to sign into Office 365 via a one-time password to view the message content and download the attachments from the Office 365 Message Encryption Portal.
Must be noted, when replying to an encrypted message via the Office Message encryption portal, you will use the same encryption setting as the original message.
There are some nuances though to consider before using built-in email encryption options of Outlook:
Other specifics are the following:
SMTP transfers sensitive data in plain text. This protocol wasn’t designed to secure data. Therefore, such a way of transmitting data could be considered as compromised by default.
Email clients use SMTP to send a message to the mail server. The mail server, in its turn, uses SMTP to relay that message to the correct receiving mail server, leaving copies of plain text on all mail servers along all the path through to the recipient inbox.
In this case, an attacker can get access to an email relay server to overtake confidential messages in transit.
The situation is getting worse when a sender's email address in the email header doesn't match its real address. This is because SMTP doesn't authenticate the sender's email domains. In fact, this security flow is a subject to human-based attacks such as phishing.
The crucial part of partial encryption is emails have to be decrypted and re-encrypted every time they pass between mail servers.
The scope of vulnerability is partial end-to-end encryption may differ depending on the used transport protocol. If the session key is compromised, then the encrypted data can be exposed as well.
When an outdated session ends, a new session should be set up with another email server, so that the message is transferred to the end user’s email server. If the next hop (and email server) doesn’t support transport level security protocol, the data can travel unencrypted.
In May 2018, a bug was discovered in the S/MIME standard which allowed attackers to exfiltrate email plain text by embedding the previously obtained ciphertext into unreadable parts of an email and combining it with HTML.
What EFAIL did was abuse active HTML emails’ content (could be any external content, for instance, images or styles) or JavaScript, to exfiltrate plain text through requested URLs.
Cybercriminals could perform such an attack by ‘listening’ to the network's traffic, compromising email accounts, email servers, backup systems, or client computers.
Attackers could then alter an encrypted email and send it to the victim. The victim's email client would decrypt the email and load up external content, — thus exfiltrating the plain text to the attacker.
One way to mitigate the vulnerability is to disable HTML. Though exfiltrating plain text (even with disabled HTML) could be performed by attaching malicious PDF or Word documents that exfiltrate malicious code when opened.
The condition that an attacker already has possession of an encrypted message is important. It means that the attacker:
To protect your emails, encryption should be implemented. It can reduce the risks of cyber thefts of confidential data.
We’ve already figured it out.
Withal, in order to perform email encryption properly though, you should not only implement encryption software that will protect content from being read by third parties, but also outline your major key points, or musts, which will help you to achieve email security for your corporate data.
Drawing on 14 years of experience in developing software solutions to protect critical infrastructure in telecommunications, the StealthMail team has defined email security criteria, which cybersecurity software solutions have to meet:
StealthMail is a multi-level software solution for email security.
The solution is transparent to its users. This means that employees can continue using Microsoft Outlook as their primary email client: StealthMail service is installed as an Outlook add-in.
In an environment where mail servers or network hops between sender and recipient are compromised, StealthMail protects emails against unauthorized access, preserves data confidentiality, saves integrity and authenticity of information.
StealthMail eliminates any manipulations through secure email communication by:
StealthMail solution not only gives you comprehensive privacy while emailing, but guarantees the full confidentiality of your business email correspondence by preserving sensitive information on your side.
The main goal of StealthMail is to ensure privacy and security of confidential email data.
StealthMail uses a distributed server architecture which means there is no single server that processes users’ data.
Moreover, data is always transmitted in an encrypted state, and encryption/decryption algorithms vary from one SDNP node to another, and depend on the previous state of the data and time it was being encrypted.
Instead of sending the data directly via open communication channels, the solution sends a Stealth link that only refers to them. In such a way your content remains intact and preserves its integrity (remains secured in the protected perimeter of a company).
With StealthMail, email communication goes through the dedicated secure channels: contents of the message come to the users’ inbox in an encrypted state and get decrypted after users’ authorization (and gets encrypted again right after they have finished working with emails).
StealthMail aims to eliminate existing email threats and protect your business from newer ones.
All communication takes place in a secure perimeter of your company, stating that:
StealthMail would be an ideal for:
Download StealthMail’s Technical Datasheet to learn about the StealthMail email security solution in more detail.
Ссылка скопирована!