How to Boost Federal Email Security

Following the Office of Personnel Management breach in 2015, there was a big call to increase the security of government websites. Then-President Barack Obama issued Executive Order M-15-13, which required the use of the HTTPS protocol for all federal websites within 18 months. And it seems like almost every agency has complied with that. Now, the government is looking to do the same thing with the other huge vulnerability within their system: email.

Boosting the security of government email systems is going to be much more difficult than fixing websites. For websites, switching to HTTPS adds Transport Layer Security, or TLS, to the Hypertext Transfer Protocol. It does this by using digital certificates to verify the websites that are being contacted, and then encrypting all traffic between the server and client. It helps that all modern browsers support using HTTPS, so the only fix needed was at the servers.

In a very general sense, government email needs to implement the same two things that its websites now routinely accomplish. First, email must verify that senders and recipients are who they say they are, and then encrypt communications between them. For email, encryption and authentication of the message content could be done using S/MIME (Secure/Multipurpose Internet Mail Extensions) and the associated certificate and key distribution protocols. But above all else, the transport layer must be secured.

The National Institute of Standards and Technology has just released Special Publication 800-177 (Revision 1) entitled Trustworthy Email, to help agencies make sense of how to accomplish this task. The report recommends continuing to use the existing Simple Mail Transfer Protocol (SMTP) and the current Domain Name System for recognizing domains, because without them, the government would basically need to reinvent the wheel. But they need to be enhanced with Sender Policy Framework (SPF), Domain Keys Identified Mail (DKIM), and Domain based Message Authentication Reporting and Conformance (DMARC). It also stresses the need for TLS.

I’m glad that the report emphasizes the need for TLS. Regardless of anything else the government does to protect its email, securing the transport layer will be the most critical step. Without that, hackers won’t even need to try and penetrate agency email security. They can simply find an insecure communications channel and read all the email going through it, which is transmitted completely in the clear. That problem is known in cybersecurity circles as insufficient transport layer protection, and it’s a huge deal.

Insufficient transport layer protection enables attacks at two vulnerable points within the data stream. The most exploited point sits between an outside user and the email server, that uncontrolled wasteland known as the internet. Even if an agency is able to secure some of that chain by owning the infrastructure, there will always be a jumping off point where a message is handed over to public networks. And the uncontrolled area that mail must traverse is almost always bigger than whatever assets an agency locks down internally. It almost doesn’t matter if an agency mail server itself is secure if it’s sending out all its mail in the clear.

But there is also another point where an insufficient email transport layer can be harmful, and it’s not one that is often considered. After mail comes into a server, it’s then sent out to a user’s inbox on the internal network. But that layer is almost never secure, especially in terms of email. If that channel isn’t encrypted, then it's practically child’s play for a skilled insider who already has some level of network privileges to intercept anyone’s, or even everyone’s, full mail stream. While (I hear) that it’s quite an advantage to be able to read all of your boss’s emails every day, within government, having open email communications within a network can constitute a threat.

I’m impressed that the full NIST report—intended as a guide for agencies to figure out how to start securing their email though the private sector may also find it useful—goes into a lot of depth about how that can happen. It also points out that this is a complicated process, much more so than securing websites, but also advises that not every change needs to happen right away. Different agencies have different security needs, and may be able to take on various levels of risk, staging their security upgrades accordingly.

“Email communications cannot be made trustworthy with a single package or application,” SP 800-177 notes. “It involves incremental additions to basic subsystems, with each technology adapted to a particular task. Some of the techniques use other protocols such as DNS to facilitate specific security functions like domain authentication, content encryption and message originator authentication. These can be implemented discretely or in aggregate, according to organizational needs.”  

Basically, there is no quick fix or so-called silver bullet for this battle. But it’s one that agencies will need to fight regardless because continuing to operate using an unsecure, ubiquitous technology is not an option.

John Breeden II is an award-winning journalist and reviewer with over 20 years of experience covering technology. He is the CEO of the Tech Writers Bureau, a group that creates technological thought leadership content for organizations of all sizes. Twitter: @LabGuys