NIST SP 800-177: New Email Security Guidelines To Combat Phishing Threats

By / / Cryptography, Messaging Security, Standards & Guidelines / Crypto, Cryptography, DKIM, DMARC, NIST, SHA-256, SP 800-177, SPF, SSL, TLS
hacking, security, cyber-4038037.jpg

The NIST standard, SP 800-177 Revision 1, Trustworthy Email was released February 2019 and offers up-to-date security guidance to include SPF, DKIM, DMARC, and email digital signatures and encryption (via S/MIME), among others.

Update: SP 800-177 Revision 1 is the first revision to SP 800-177 that was published on September 7, 2016.

Highlighted below are good security recommendations from SP 800-177 that can be used by your organization to fight spoofed email and unwanted email (or spam) often used in phishing attacks. These guidelines should also complement a strong security awareness program needed to help educate your users on avoiding phishing emails. 
 

Sender Policy Framework (SPF)

SPF specifies which IP addresses are authorized to transmit email on behalf of domain. NIST says that SPF should be deployed with DNS security (or DNSSEC) for all DNS name servers to ensure source authentication and integrity and protection of DNS data.

Why use SPF? SPF is designed to address phishing and spam sent by unauthorized senders, similar to the other methods described in the next sections.
 

Implement DKIM

DKIM, short for DomainKeys Identified Mail, provides a method for validating the domain name identity that is associated with an email through cryptographic authentication or “signing” the email with a digital signature. DKIM is also used by organizations to detect spoofing and prevent phishing and email spam.

NIST recommends using DKIM with the following crypto key parameters: RSA/SHA-256 (note: not SHA1) with 2048 bits and lifetime of 1-2 years.  Similar to SFP, also deploy DNSSEC.

Mailing list software should verify DKIM signatures on incoming mail and re-sign outgoing email with needed DKIM signatures.

Mail sent to broadcast lists from “do not reply” or unmonitored mailboxes should also be signed with S/MIME signatures.

Do you use any third parties for sending your email? If you do, NIST recommends that DKIM pair should be used for each third party that sends email on your organization’s behalf.
 

Implement DMARC

DMARC, or Domain-based Message Authentication Reporting and Conformance, allows the email sending domain owner, such as your company, to specify how receivers can verify the authenticity of the sender organization’s email, as well as how your organization (or the receiver) can handle email that fails to verify.

DMARC basically adds a link between the domain of the sender with the authentication results for SPF and DKIM.

According to the SP 800-177 guidelines, the sending domain owners who deploy SPF and/or DKIM are recommended to publish a DMARC record signaling to mail receivers the disposition expected for messages purporting to originate from sender’s domain.

NIST also recommends that mail receivers should dispose of received messages according to sending domain’s published DMARC policy. Initiate failure reports according to sending domain’s DMARC policies as well.
 

Protect email confidentiality

Organizations are highly recommended to migrate from TLS 1.1 to TLS 1.2 “with all practical speed” and to ensure email transferred between servers and end-to-end email is encrypted. See SP 800-52 for more information. On a related topic, PCI changed their deadlines and guidance last year to move to more secure protocols by 2018. However, they too still recommend new implementations use TLS 1.2. 

TLS capable  servers should prompt clients to invoke STARTTLS command (for SMTP) and also use S/MIME with a certificate signed by a known CA (preferred over OpenPGP).

Other useful guidance include blocking outbound port 25 (except for authorized mail servers) and block inbound port 25 (use firewalls and IDS to alert when an unauthorized hosts are accepting mail).
 

End-user email security

NIST recommends IMAP and POP3 clients are used to connect to servers using TLS. Don’t forget to never connect with unencrypted TCP used for authentication with usernames and passwords.

Finally, crypto keys used for encrypting data in persistent storage (such as mailboxes) should be different from keys used for transmission of email messages.

Author’s update: this article was originally published on September 9th of 2016, but has been updated March 16, 2022 with reference to new revision 1 of the SP 800-177 guidelines that includes latest up-to-date NIST recommendations for email security.