92% of malware spread through the email system. This is not a surprise if we consider that the email delivery system breaks almost all the rules defined in Zero Trust. Even though there are several ways to apply security policies to email transfer, these methods are not nearly as widely declared and enforced as they should be. In this article, I’ll describe how an organization should transform its email delivery to ensure it conforms to the Zero Trust model.
The email has remained the most essential and the most overused communication method throughout its 40-year history, and still forms the basis of countless business processes. However, the fact that it uses one of the oldest and least securely designed communication protocols makes it the most exploitable and vulnerable area of the internet. The existence of phishing, spoofing, and other fraud techniques has demonstrated that the email system can be the weakest point of even a Zero Trust network and offers a path for attackers to introduce malware into a corporation. Why is this so? The issue is largely due to a lack of adherence to the Zero Trust principles.
Email is the Zero Trust Antipattern
Zero Trust principles state that you should handle everything as a resource, handle them equally, communicate securely, authenticate access, and provide only the least-privilege access. In general, nobody would grant access to a corporate resource from the internet without robust authentication and encryption. It is especially true if someone could copy files on that resource that the users of the resource can run later. Sadly, this is how email delivery works by default. Without modern techniques extending the original delivery protocol, anybody can send an email with a malicious attachment on anybody else's behalf. For this reason, it is essential to follow the Zero Trust motto; Never trust, always verify! So, how can you verify an email?
Step One: Authenticate the Server
The recipient mail server can verify the sender mail server by its network address. A domain owner can publish a policy – known as a Sender Policy Framework (SPF) – declaring which servers are allowed to send emails on behalf of the domain. The recipient side can use the published policies to check whether the incoming mail is being sent by an authoritative server. According to Balasys’s research, approximately 78% of the one million most-visited domains publish a policy. This is a particularly high ratio, but we should not forget about two related factors.
The first issue is that, as part of the policy, a domain owner can declare what should be done when the recipient realizes that there is no explicit rule that matches the IP address of the actual sender. Less than 35% of domain owners have published a policy that is specific enough to declare the sender as unauthorized. As so often, business continuity is chosen over security – despite the maintenance cost of this policy is low, as mail server addresses rarely change. According to Zero Trust, you should consider all mail servers that send emails in the name of your domain as your resources (e.g., Mailchimp and others). Zero Trust requires the use of the least privilege principle, meaning as few servers should be allowed to send mail as possible without using permissive default values.
The second issue is that whatever the policy states, it can only be enforced by the recipient server. If there is no support in the recipient server to enforce the policy, it is worth nothing. Though big email providers motivate domain owners to use the mechanism, without publishing a policy, or by publishing a failing one, our emails quickly end up in the spam folder.
Step Two: Use Encryption
Zero Trust encourages the encryption of all traffic to internal and external locations in order to prevent eavesdropping and content manipulation. The standard for mail transferring states that a publicly referenced server must not require encrypted communication. The standard approach sought to prevent causing damage to the interoperability of the internet mailing infrastructure in this way 20 years ago. Since then, the encryption of mail delivery communications has only been opportunistic. Mail delivery is exposed to an attacker with man-in-the-middle capability that can enforce unencrypted communication, independently from the fact that both parties intend to encrypt. Without initiating encryption, the recipient cannot authenticate the sender, and vice versa. Beyond this, mail transfer is vulnerable to eavesdropping or content modification, meaning an attacker could potentially forge malware into a mail.
To deal with this challenging situation, the domain owner can publish that the mail server supports encryption. The SMTP MTA Strict Transport Security (MTA-STS) method uses the domain name system (DNS) to propagate this information. Unfortunately, only 0.1% of the top one million domains take this opportunity to ensure the sender that there is encryption support. Barely half of the top 1,000 domains are only in the testing phase now, and the other half want to enforce the encryption. These statistics indicate that domain owners neglect the Zero Trust principle of using encryption whenever possible.
Step Three: Verify the Mail
Checking the server address using the method mentioned above cannot be considered a satisfying method of authentication and affects neither the confidentiality nor the integrity of the sent mail. However, encryption could provide confidentiality, integrity, and authenticity, and the aforementioned challenges make it necessary to ensure at least integrity and authenticity in order to avoid content modification made by a malicious third party. The Zero Trust authentication requirement could be satisfied by verifying the mail sender using digital signatures. A domain owner could publish one or more public keys, which the authoritative servers can use to sign each sent mail digitally, identifying the mail by these domain keys. This mechanism exists and is named DomainKeys Identified Mail (DKIM). In some cases, more than one server participates in the delivery of an email. This mechanism is essential because it can grant authenticity and integrity during the complete delivery process. Furthermore, the email client can notify the user when the verification fails that they should be careful even though the mail has not been identified as spam.
Although this mechanism cannot guarantee confidentiality, it has a significant added value. The user can be sure that the attacker cannot impersonate the sender and cannot modify the content of the email during the delivery. It prevents several email fraud techniques, such as the attacker sending misinformation or disinformation to a victim. CEO fraud is a great example. The attacker impersonates the organization's CEO to get the victim – the finance department of the CEO’s company – to perform a transfer to their bank account or run a malicious email attachment. Despite its importance, this mechanism has a relatively low prevalence, something which is considered to be another Zero Trust antipattern.
Step Four: Monitor the System
The methods mentioned above can prevent or mitigate security issues but require support on the recipient (SPF, DKIM) or the sender (MTA-STS) side. When there is support for these methods, a question arises. What should a server do when it verifies the address of the sender, the digital signature of a mail, or the encryption capability of the server, and it experiences issues? Zero Trust requires continuous monitoring of the network to prevent or notify you of any suspicious behavior. This is even more important in the case of the aforementioned methods when the other party may experience issues and can monitor your system and notify you. As a result, there should be a technique that automates authentication, reporting, and conformance. This technique is Domain-based Message Authentication, Reporting, and Conformance (DMARC), which enables the domain owner to publish what the other party should do when experiencing issues and how to report such an issue.
It would be evident that domain owners who use SPF also use DMARC to declare how a recipient should act when the sender policy check failures. This assumption is still not fully valid if we talk about the top 1,000 domains. Almost all domains in the top 1,000 publish a sender policy framework, and nearly 74% still publish DMARC. In the case of the top 1 million, approximately 78% publish a sender policy, but just 22% publish DMARC. Most domain owners communicate how to handle policy failures, but only a minority strives to monitor whether these policy failures actually occur, which constitutes a failure to adhere to Zero Trust principles.
Step Five: Enforce the policies
The ratio of the required actions dramatically shows how heavily business depends on the email system and how much more critical business continuity is than security. Except for the top 1,000 domains, only a minority of domain owners are brave enough to ask mail receivers to quarantine or reject policy-breaker mails. In other cases, the majority asks the mail receivers to take no action, which raises the question of whether the usage of DMARC has any sense at all. We can find similarly permissive settings in the case of SPF. Just under 35% of the published SPFs in the top 1 million domains declare that a policy violation should be handled as a failure, meaning that the received email should be placed in the spam folder. However, another 55% require the server to take these emails with due care by forwarding them to a spam folder or marking them as suspicious. The situation is the most disappointing in the case of MTA-STS, independently of the fact that only this mechanism can guarantee the confidentiality of an email that is not end-to-end encrypted. Usage is under 1% in the top 1 million domains, and almost half of them are in the testing phase.
The Result: Your Email Will Conform to Zero Trust
According to the Zero Trust principles, you should
- Authenticate any resource access, where the first step is to require SPF and check the IP address of a sending server before granting access to your mailing system, and the second step is to validate the mail authenticity using DKIM
- Use encrypted communication whenever possible, especially on the internet, so MTA-STS should be published and required
- Authorize access by using the least privilege principle, meaning that you require the integrity of any emails to avoid the malware injection by using DKIM
- Monitor your systems and any policy violations by asking for reports in DMARC and TLS-RPT
- Use the mentioned mechanisms continuously and strictly in a session-based manner
For as long as we have to live with the plain old email system, which has not been designed for being secure, we should use and enforce as many of the above-mentioned mechanisms as possible. We should handle domains that do not publish policies (SPF, DMARC, MTA-STS) and servers that fail the policies with mistrust and suspicion. This approach is essential to avoid the compromise of our network by using the least Zero Trust compliant system on the internet: email.
Author
Latest Articles
New Edition
