Protecting Information Flow: The Importance of Email Security for Business
If a tree falls in the forest and people are around to hear it but someone’s been hiding in the forest for months playing loud, fake recordings of falling trees with a Bose speaker, did a tree really fall?
Information flow is arguably the lifeblood of a successful business. Moreover, as explored in a previous article about the role of digital signatures in business, the security of (and shared trust in) that flow is critical. Information by itself doesn’t offer much value to a business — it’s the action taken in response to information that provides value, and information is only actionable if it is trusted. With that in mind, an obvious implication of lost trust in information is lost productivity, but perhaps more importantly, trust maintained in a compromised communication channel implies continued action on compromised information, or even disinformation, which can potentially be much more detrimental to a business than no action at all.
Email is The-mail
Email is perhaps the most common communication channel used in business contexts, offering a quick and easy way for employees to correspond with fellow employees, with clients, with contacts at other businesses, with their supervisors, and so on. We see emails used across the board for purposes like sharing files, scheduling meetings, discussing projects, and generally sharing information — even sensitive or protected information despite organizational policies against such email use. From my own experience working in digital communications at a university, I can confidently say the role that email plays in higher education, in both internal business processes and external marketing, cannot be overstated, especially in the wake of the remote work surge following the 2020 onset of the COVID-19 pandemic.
As what generally amounts to a default communication tool provided to each employee within a business, email presents a quite a large attack surface for scammers to potentially exploit — especially in cases where the employee onboarding process doesn’t involve training on email security, and even in cases where it does. Luckily, there are well-known and established protocols for verifying the authenticity and integrity of emails that can be put in place such that this email attack surface has multiple layers rather than just one — the outermost layers being the backend protocols and the innermost being the users, where the users tend to have varying degrees of proficiency with email security.
A Concrete Example
To move away from abstract terms for a moment, imagine an employee of a payroll services office for an organization. The employee helps to set up pay distribution to the bank accounts of the organization’s employees. The office has a PDF form publicly listed on the organization website for employees to download, fill out and submit to set up direct deposits for their bank accounts. The forms — which only ask for one somewhat-secret identifying attribute of the submitting employee — can be submitted over email due to the time-saving nature of convenience taking priority over a policy which would instead require use of a secure file sharing application for such a purpose. Of course, there’s a kaleidoscope of problems in this situation, such as the use of a public website for sharing the form rather than an intranet behind authentication for the organization, the divergence of practice from policy for convenience, the use of a not-so-secret attribute on the form to identify the requesting party, and arguably even the use of a PDF file rather than a more secure digital form behind multi-factor authentication (e.g., a Microsoft Form only available to members of the organization). In this case, let’s accept those problems and focus on the problem of email security.
Assume the organization (more specifically, the organization’s IT department) doesn’t have any mechanisms in place for protecting email security. They haven’t set up an SPF DNS record (Sender Policy Framework, not sunscreen — although one can consider SPF as a screen against the sun of scammers), meaning messages can be sent by anyone on behalf of the organization’s domain without raising any red flags (i.e., without being rejected or flagged as spam). They also have not set up DKIM (Domain Keys Identified Mail) which means there’s no active mechanism for receivers to verify through message signatures that received messages have not been forged or altered (DKIM is similar to the digital signatures discussed in a previous article). Lastly, they also haven’t set up the DMARC (Domain-based Message Authentication, Reporting & Conformance) protocol for their domain to handle the reporting of fraudulent emails; this makes sense, since DMARC builds on top of SPF and DKIM which the organization hasn’t set up. Without any of these well-known backend protocols handling the flagging, blocking, and reporting of fraudulent emails, the organization is placing that responsibility into the hands of each individual user with an email account under its domain. Moreover, the absence of these protections is easily recognizable and exploitable by any interested attacker, because if enabled, they are set up using DNS records with specific formats whose presence or absence can be quickly detected with simple queries at a command line.
Now assume that an attacker, knowing the organization’s domain is not protected by SPF, DKIM, or DMARC, downloads the direct deposit setup form from the organization website and happens to know the not-so-secret identifying attribute (e.g., an ID number) of one of the organization’s employees in addition to their email address and name, and perhaps their common email signature (e.g., Name/Department/Website). The attacker prints and fills out the form with that identifier and the name of the employee it identifies, and then populates all the direct deposit bank account fields with their own bank account information. Next, they forge the hand-written signature of the impersonated employee at the bottom of the form and scan it. They begin crafting an email (with the employee’s commonly used email signature at the bottom for that extra personalized spice) to say something to the effect of “Hi, I recently had to change banks…”, etc. The attacker then uses a free email spoofing tool like Emkei’s Fake Mailer to send the crafted email with the attached form to one of the payroll service employees’ email addresses (also listed publicly on the website, which is common but problematic) from the email address of the employee being impersonated. At the click of a button, the email is sent, and ends up in the target inbox with no flags thrown. From here, the payroll services employee, seeing that the new email is from the address of the same person supposedly requesting the change, could perhaps simply act on the request and make the account change. Alternatively, as a separate protective measure, they could call the phone number of the “requesting” employee to verify that they are indeed requesting a direct deposit update, but unless this kind of practice is mandated in the payroll office, that likely would not happen. In the worst-case scenario, the impersonated party’s deposit goes to the fraudulent account on the next payday, at which point the attack would probably be noticed and ideally reported to an information security team. This is sort of like when that scammer stole millions of dollars from Facebook and Google in that business email compromise (BEC) attack, except in those cases, Facebook and Google’s vulnerabilities were more human-centric than auth-protocol-centric.
A Flattened Hierarchy
The above is just one specific attack vector among many that could be exploited when email security is not treated as a priority by a business. Now, keep in mind that while different levels of authority within an organization’s hierarchy may be acknowledged and treated differently by the employees, that hierarchy is flattened in the face of an email attack like the above; a CEO’s email account is just as unprotected as a new hire’s account if the domain is not set up with any system-wide protocols for flagging, blocking, and reporting fraudulent emails in the domain. This gives attackers a significant advantage since they can impersonate and leverage the authority of an authoritative figure within a vulnerable target domain and cause a much greater degree of chaos using the same amount of effort they would use for impersonating a regular employee. For example, assume the same attacker from before, aware of the email vulnerabilities, were to send an email from the company’s CEO to, say, many company email addresses (again, scraped from their public website), requesting that they open a link to some new and improved web application they’re about to launch; instead, the link actually points to a fraudulent-but-official-looking site that collects confidential information entered at will by the employees. Even though the CEO isn’t necessarily at fault for the attack, chances are employees whose accounts were compromised won’t necessarily trust future emails from that account — or any account, for that matter. And they shouldn’t, as long as the domain isn’t being protected.
Widening the Scope: External Audiences
So far, we’ve just focused on attacks affecting the internal units of the organization being targeted, but the organization’s external relationships are just as vulnerable when emails from the domain can be arbitrarily spoofed by an attacker. Taking higher education as an example, targeted email marketing (e.g., with automation platforms like Pardot) plays a major role in creating and maintaining relationships with prospective students (this can be generalized to future customers for non-higher-ed businesses). If the primary marketing email address in the organization’s domain can be spoofed by an attacker due to domain protections not being put in place, that attacker can potentially negatively sway decisions of many prospective students, which can amount to thousands, or even millions, of dollars lost by the organization. This same financial risk applies to the potential spoofing of addresses used for email newsletters (e.g., with platforms like Mailchimp), which may be used to maintain relationships with alumni and potential donors to the organization. Of course, in both of these cases dealing with a large list of target email addresses, there is the added requirement that the attacker first obtains those addresses which offers some protection.
Let’s add one more layer of “uh-oh” to this already significant problem of email spoofing. Suppose that an attacker has indeed identified one of those common marketing or newsletter email addresses used by the organization. Rather than crafting some sneakily malicious content and trying to specifically target certain people from that spoofed address hoping they take some specific action, the attacker instead just crafts one simple, blatantly spammy email and begins rapid-firing it to lists upon lists of target email addresses collected from the internet. Chances are, that spoofed email address will eventually get added to a blacklist, after which emails from that address no longer get delivered to the intended recipients (or they do get delivered but are sent to the recipient’s spam folder). The fun part (that is, the least fun and most worrying part) of blacklists is that they can either be based on the IP address of the offending sender (which is somewhat narrow), or they could apply to the full domain from which the spoofed email was sent. In this case, not only is trust lost and the organization reputation potentially damaged, but the channel of email communication itself is potentially lost for the domain and needs to be recovered through correspondence with whichever company manages the affecting blacklist(s).
Conclusion
As arguably the most load-bearing communication channel for most businesses, email deserves to be protected. While this can (and should) come in the form of strong policy enforcement and security training around email usage within the business (e.g., what should and should not be sent over email, what to check for when receiving emails, etc.), the protections offered by DNS-based protocols like Sender Policy Framework (SPF), DomainKeys Identified Mail (DKIM), and Domain-based Message Authentication, Reporting & Conformance (DMARC) are undeniably critical for businesses wishing to maintain a positive reputation, and more generally, trust in the communications sent from its domain. Without protecting shared trust in such a heavily used communication channel, a business puts at risk the health of relationships both internal and external, and thus its ability to be functional and productive.
