The US government's technology agency has updated its secure email guide for the first time in a decade and put it out for a month of public comment.
The National Institute of Standards and Technology (NIST) guide [PDF] is 81 pages long and provides a surprisingly useful rundown on what to do to get your email secure.
Its top-line point: email can be made sufficiently secure for important and confidential communications, but it will require adding multiple aspects to your networks and ensuring they work together.
Email communications cannot be made trustworthy with a single package or application. It involves incremental additions to basic subsystems, with each technology adapted to a particular task.
This is not exactly going to strike sysadmins as news, but nevertheless the document is a handy and practical guide. It's also a smart idea to refresh these sorts of documents, especially since the previous advice was published back in February 2007.
Key among the pieces of advice comes the simple note: don't just use a username and password with unencrypted TCP for email. Those days are long gone and the approach is "strongly discouraged." If you're using IMAP or POP3, TLS is a must.
Instead, it's time to build out a cryptographic key management system (CKMS) and use keys to protect email sessions.
Despite the past decade being filled with compromises of the domain name system – upon which most email security continues to rely – NIST is still comfortable with the DNS being used for storing vital information mostly because of the DNSSEC security protocol giving people more faith that DNS records have not been tampered with.
It's a big fan of S/MIME (Secure Multipurpose Internet Mail Extensions) and recommends it as the key protocol for protecting email contents, particularly in mass mailings.
The big plus of S/MIME is that it doesn't require the sender to provide their public key certificate in advance. The paper notes that use of S/MIME is "not common at the present time" but recommends that people move to it. It also notes that it may soon be possible to use the DNS to act as a "lightweight publication infrastructure" for S/MIME certificates.
It adds a "special warning" to those who use cloud services for their email: be aware that you are relying on a third party to keep your information secure. It gently suggests that it might be better to go for an Infrastructure-as-a-Service (IaaS) system over an Email-as-a-Service (EaaS) system since in the former, you can typically gain access rights to configure email servers how you see fit.
It then has some pretty pragmatic advice on how to avoid, or more accurately limit, spam. And it notes that when it comes to people actively trying to break into your system through email, "the final line of defense ... is an educated end user."
The guide [PDF] is out until the end of April for public comment, after which it will be finalized. The report is not anything starkly new, but for sysadmins it might serve as a useful reminder and potential checklist – and prod – to check out the security of your own email systems. ®