Email Security: A Privacy Introduction

DISCLAIMER: 100% of the content in this blog post is original and has been created by humans, including its research, writing, images, and graphics.  No AI (Artificial Intelligence) was used to create any portion of the content.

TL;DR: Email privacy is a component of email security.  It prevents email security failures from becoming a catastrophe by making email unusable to unauthorized persons.  Email security (and email privacy) can fail at any time, without notice, making it impossible to know when failures occur.  Only continuous testing of email security (and email privacy) can ensure that email system administrators are notified when an email security (and email privacy) failure occurs.  CheckTLS offers continuous email security (and email privacy) that can continuously report the status of email security (and email privacy) to email system administrators.

Introduction

How email is kept private is a critical component of email security and is the focus of this email privacy introduction.  This introduction will impart a basic understanding about how email privacy is accomplished and how privacy relates to the broader topic of email security.

Email is a surprisingly complex technology — especially email security.  Trying to gain a working knowledge of email security can be a frustrating experience, especially when using the Internet.  Websites and blogs (and even many technical books) focus only on specific email security technologies.  Trying to "assemble" all of the information available about email security into a working knowledge of the overall topic leaves most people confused, frustrated, and discouraged.  Most people feel like they've never "gotten a handle" on the topic of email security.

Email privacy is the bedrock of email security. The remainder of this introduction will explain the technology behind email privacy, how it is used to keep email private, and the role that email privacy plays as the "last line of defense" against the many threats arrayed against email.  The following explanation of email privacy has been created at an introductory level, so even non-technical readers will be able to gain a a working knowledge of email privacy and the critical role it plays in email security.

What Is Email Security?

It is the resources required to protect against every one of the threats shown in this illustration.  These resources include the hardware, software, and expertise (technical personnel) required to understand, configure, and support the multiple systems that prevent each of these threats from exposing email to unauthorized persons.  Email security is expensive and resource intensive.

What Happens When Email Security Fails?

The entire email infrastructure, along with its email, may become available to unauthorized persons.  Not only can these persons read the email, they can use the email infrastructure to embarrass, blackmail, extort, steal money, steal intellectual property, compromise national security, commit insurance fraud, securities fraud, identity theft, and a host of other serious crimes.

What Makes Email Security So Challenging?

It's important to realize a few things about the nature of email security that makes it so difficult to implement, operate, and maintain over time:

• You only have direct control over your own email system.  Remember that every one of the persons you exchange email with is connected to their own email system and that you have no control over the level of email security (if any) that has been implemented on their system.
• Even individuals and small businesses may exchange email with thousands of persons.  The scale of the email security challenge you face from other persons' email systems is orders of magnitude greater that the challenge you face in keeping your own email system secure.  That's because every email system you exchange email with has the exact same challenges you do in keeping their own email system secure.
• The quality (strength) of email security is up to the owner of each email system.  With few exceptions (e.g., finance, healthcare, government, military, etc.) there are no laws that require email system owners to implement a minimum level of email security.  In fact, there are no laws (with the exceptions noted) that define a minimum, acceptable level of email security.  This means that you never know whether or not any email system is secure until you attempt to exchange email with them.
• To guarantee your own email system's security, you must assume every other email system is insecure.  This is not a rhetorical or theoretical assumption given that there is no legal governance regarding the implementation of email security (with the exceptions noted) to which every email system owner must adhere.  If you don't assume that every email system is insecure, and prepare accordingly, you are guaranteed to suffer an email security failure that happens on the other person's email system but adversely affects you.
• An email system's security can lapse at any time without the knowledge of the email system administrator.  There are so many single points of failure throughout every email system, that if any one of them fails, the entire system's security can fail.  Expired security certificates, hardware and software upgrades, improved hacker tools that can defeat current email security, and unknown vulnerabilities in email security components (especially software) that hackers discover and exploit without the email system administrator's knowledge, are but a few of the "moving parts" that are present in every email system that can cause email security to fail at any time.

What Is Email Privacy?

So, what can be done to address these email security issues?  Make sure that email privacy is implemented correctly on your email system.  Information Security Testing defines "email privacy" as the ability of a specific set of email-related software tools to prevent any email security failure from becoming a catastrophe, whether the failure happens on your email system or someone else's.  These software tools don't prevent email security failures, per se, — they simply ensure that any email that gets exposed to unauthorized persons as the result of an email security failure is unusable.  Email privacy reliably defeats all three email threats — eavesdropping, modification, and impersonation — whenever any of these threats is used against an email system as the result of an email security failure.

How Email Privacy Works

Email privacy software makes every email unusable to anyone but the intended recipient(s) using a combination of Message Encryption and Email Authentication.  Email privacy software technology and processes are complicated, but their results are straightforward.  Every email message is scrambled (encrypted) and the authenticity of every part of the email (more on this later) is validated before the email is allowed to be delivered.

Message Encryption

Message Encryption, by itself, is a very complicated topic.  For the purposes of this introduction to email privacy, it is only necessary to know where email messages can be encrypted.  In the email privacy illustration above, there are three "network sections" where email messages can be encrypted:

• The sender's local network section.  Located at the left of the illustration, this includes the sender's computer and the network (shown in dashed green/black lines) to which the computer is attached.
• The email servers network section.  Located along the bottom of the illustration, this network section includes the sender's email server(s), the email relay servers that exist on the public Internet, and the recipient's email server(s).
• The recipient's local network section.  Located at the right of the illustration, this includes the recipient's computer and the network to which it is attached.

Application-Level Message Encryption (local network sections)

For both the sender and recipient local network sections, email Message Encryption can be performed on each end user's computer.  In order to perform encryption, an email Message Encryption application must be installed on each computer.  Most importantly, in order for senders and recipients to be able to reliably exchange encrypted email messages, the same email Message Encryption application must usually be installed on every sender and recipient computer (there are some rare exceptions).  This imposes a significant burden on sender and recipient IT departments because they have to ensure that every sender and recipient person has the same Message Encryption application installed on each of their computers.  For an in-depth discussion of this IT burden, please see the section of our Public Key Encryption: A Beginner's Guide blog post titled, The Challenges of Using Encryption Applications.  Encrypting email messages on each section computer means that they will be stored on the computer's hard drive as encrypted files and will be transmitted across all three network sections encrypted.  Using local network section encryption is usually only done in the most sensitive environments where the risk of an email security failure, no matter how small, can never be tolerated.

Network-Level Message Encryption (email servers network section)

Network-level email Message Encryption (and decryption) is performed on sender and recipient email servers.  For email that does not use Application-Level Message Encryption (which is the majority of today's email systems), the email message is stored on the sender's computer hard drive as readable text (known as "plaintext") and is also transmitted as plaintext across the local network to the email server.  When the plaintext email message arrives at the sender's email server, the email server encrypts the plaintext email message and sends it as encrypted text (known as "ciphertext") onto the public Internet using the Transport Layer Security ("TLS") security protocol (very rarely is TLS not used as the email transport security protocol).  Once on the public Internet, the ciphertext email message is relayed by one or more email relay servers across the public Internet until it arrives at the recipient's email server.  The recipient email server decrypts the ciphertext email message to plaintext and transmits the plaintext email message across the recipient local network to the recipient's computer where it is stored on the hard drive as plaintext.  The recipient then accesses the plaintext email message stored on their hard drive using an unencrypted email application.

Network-level email Message Encryption is the minimum level of encryption that should be configured for any email system given that the risk of an email security failure is significantly higher on the public Internet that it is on a local network.  Network-level email Message Encryption doesn't require the ongoing involvement of the IT department to install and support encryption applications (other than testing to ensure that Message Encryption continues to work over time).  Because network-level email Message Encryption ensures email privacy for every email message that is sent across the public Internet (which is where the highest risk of email security failure exists), many organizations are willing to accept the low risk of suffering an unencrypted email security failure on their local network section in exchange for not having to deal with the cost and complexity of managing encrypted email applications.

Email Authentication

Authenticating email is a complex process that is governed by the configuration of Email Authentication settings on both sending and receiving email servers.  When each server's settings have been configured correctly, each server can perform the following Email Authentication tasks:

• Sending Email Server
  — Validate the identity of every email recipient's organization
• Receiving Email Server
  — Validate the identity of the email sender's organization
  — Validate that the received email hasn't been tampered with

Why is "organization" underlined above?  Email Authentication can only validate the "organization portion" of an email address (which is the part that includes the "@" symbol and everything thereafter) — it can't validate the user part of the email address (which is everything before the "@" symbol).  The "organization portion" of an email address is known as the "domain name."

Successful completion of the three validation tasks listed above, by both the sending and receiving email servers, defines Email Authentication.  When Email Authentication has successfully taken place, the following email privacy protections are confirmed to exist:

• Every recipient domain name that has been validated as legitimate is not being impersonated.  This means that the validated domain name(s) contained in individual recipient email address(es) can safely be sent email.  Unvalidated recipient domain names cannot be confirmed to safely be sent email.
• The sender's domain name has been validated as legitimate and is not being impersonated.  This means that the sender's validated domain name is safe to receive email from.  Unvalidated sender domain names cannot be confirmed to safely receive email from.
• The contents of the email have been validated as unmodified since it was sent.  This means that the received email is identical to the email that was sent and that the reader is reading exactly what the sender sent.

Unless all three of the validation tasks listed above are completed successfully, Email Authentication has not taken place.  There are no warnings that are sent to email administrators, senders, or recipients that Email Authentication isn't working.  The only way that email administrators can know for certain that Email Authentication is working properly is to continuously test the operation of their Email Authentication.

Is there a good example that illustrates why email administrators should go to the trouble to setup and maintain Email Authentication?

There is.  Anyone can impersonate the "FROM:" portion of an email message using a domain name that doesn't belong to them.  Unless Email Authentication is configured correctly on both the sender and recipient email servers, anyone can fake (referred to by email techies as "spoof") the domain name in the "FROM:" portion of an email message.  This means that anyone could send you an email message whose "FROM:" was impersonating someone you trust and whose emails you open without question because you know and trust them.

For example, you could receive an email message whose "FROM:" was john.waters@ups.com.  You probably don't know a john.waters who works at UPS, but you know and trust the UPS brand.  Because you trust the brand, and assume that it is from the UPS that you trust, you click on the email message to read it.  Unfortunately for you, the "FROM:" portion of the email message has been spoofed but there's nothing in your email application that warns you about this. What you just experienced was the beginning salvo of an email phishing attack whose ultimate goal is to use you as a pawn to gain access to your entire corporate network for the purpose of launching ransomware.  According to digital security experts, over 90% of all hacking activity begins with an email phishing attack.  Just so you know, this UPS email phishing scam has been around for years and is particularly prevalent around the Christmas holiday.

Information Security Testing recommends that nine email software tools be used in combination to deliver reliable and accurate Email Authentication that defeats the threats of domain name impersonation and email content modification.  Many email providers choose not to use all nine software tools to deliver Email Authentication, either because they don't understand the complex technical interactions between the tools, or because they consciously choose to use only those tools that they believe produce reliable and accurate Email Authentication.

Information Security Testing has years of experience using these nine software tools in various combinations to deliver Email Authentication.  Based upon this experience, Information Security Testing has concluded that using all nine software tools together produces the most accurate and reliable Email Authentication.  However, using only a few of these software tools will dramatically improve Email Authentication over doing nothing.  Our minimum recommendation is to use TLS and SPF.  These are the easiest software tools to implement and provide a significant amount of domain name and content validation.

So, what are these nine software tools and what do they do to deliver Email Authentication?  A listing of these tools is shown below.  Each tool's name is an acronym, whose full name is shown in parentheses.  Because this blog post is an introduction to email privacy, how each tool works is not presented due to the highly technical nature of each tool.  These software tools are listed in their order of significance in providing reliable and accurate Email Authentication, with TLS (Transport Layer Security) being the most significant, then SPF (Sender Policy Framework), and so on. 

• TLS (Transport Layer Security)
• SPF (Sender Policy Framework)
• DKIM (DomainKeys Identified Mail)
• MTA-STS (Mail Transfer Agent — Strict Transport Security)
• DMARC (Domain-based Message Authentication, Reporting, and Conformance)
• DNSSEC (Domain Name System Security Extensions)
• DANE (DNS-based Authentication of Named Entities)
• TLS-RPT (TLS Report)
• BIMI (Brand Indicators for Message Identification)

For a technical introduction to these tools and how they work together to deliver reliable and accurate Email Authentication see this page.

The Need for Continuous Email Privacy Testing

As pointed out earlier in this article, an email system's security (and its associated email privacy) can lapse at any time without the knowledge of email system administrators.  This can happen when:

• An email server's security (SSL) certificate expires or is revoked.  Encryption between email servers can no longer take place (TLS fails).  Emails are sent and received as plaintext.
• An email server's hardware or software fails.  The extent of the email security failure depends upon what fails.  In a worst-case scenario Message Encryption and Email Authentication both fail.  Emails are sent and received as plaintext, the identity of senders and receivers is not validated, and email contents may be modified.
• An email server's software isn't patched in a timely manner.  This is one of the major causes of email server vulnerabilities that hackers exploit.  Once a vulnerability has been announced publicly, if the email server administrators don't patch it immediately, it becomes an open door for hackers.  Depending upon what gets exploited, Message Encryption and/or Email Authentication can fail. Emails are sent and received as plaintext, the identity of senders and receivers is not validated, and email contents may be modified.
• An email server's hardware or software support contract lapses.  The extent of the email security failure depends upon how long the support contracts have lapsed.  The longer the lapse, the more likely that hackers will have discovered hardware and/or software vulnerabilities that they can exploit.  Depending upon the vulnerability(s) that get exploited, Message Encryption and/or Email Authentication can fail or be circumvented.  Emails are sent and received as plaintext, the identity of senders and receivers is not validated, and email contents may be modified.
• An email server's Domain Name System ("DNS") configuration is hacked.  DNS functions as the public Internet's address book.  Just like the address of a building (number, street, city, etc.) each email server has a unique DNS configuration ("address").  If this gets hacked and changed, an email server's traffic can be re-routed to the hacker, then processed however they want.  Both Message Encryption and Email Authentication are circumvented.
• The network to which an email server is connected is hacked.  Typically a Man-In-The-Middle ("MITM") attack, network traffic is read by a packet sniffer and can be redirected to malicious websites.  Depending upon the sophistication of the MITM attack, emails can be read as plaintext and modified and the identity of both the sender and receiver can be impersonated (spoofed).
• The network to which an email server is attached fails.  This is an obvious, but not uncommon, issue that would prevent the exchange of data between email servers.

The critical nature of the information that is exchanged between email servers requires that the information remain private at all times and only be accessible to authorized persons.  The only way to ensure that email information remains private is to continuously test that Message Encryption and Email Authentication is operating properly between your email server and EVERY recipient's email server.  How often you perform these tests will vary by organization, will be based upon the sensitivity of the email information, and whether or not the protection of the information is regulated by government authorities (and subject to fines if breached).

Whatever the nature of your email information, Message Encryption and Email Authentication testing should be conducted with a frequency that is appropriate for the sensitivity of your information (this is what is meant by the term "continuous testing").  Based upon the experience of Information Security Testing's customers, the minimum testing frequency we recommend is once per day for every domain name with whom you exchange email on both your sending and receiving email servers.  This minimum testing frequency provides adequate proof that your email security is working correctly for email information that is not subject to regulation by government authorities.  For email that is regulated by government authorities, each organization will need to determine the testing frequency that they feel provides adequate proof to regulators that their email security is operating correctly (this is usually often enough to act as an "early warning" so that email administrators can fix problems sooner than later — some of our healthcare customers test once per hour).

Conclusion

Understanding the difference between email security and email privacy (which is a component of email security) is critically important because when email security fails (and it will) email privacy will prevent breached email information from being used against you and your organization (because your email has been encrypted).  This introduction to email privacy has been created to help you gain a complete picture of the role that email privacy plays in overall email security.  More importantly, this introduction has called to your attention the fact that email privacy can't be trusted unless it is continuously tested to prove that it is operating correctly.  We invite you to learn about our testing products and services and how you can determine if your email privacy is secure by visiting our home page.