" nist Archives - LuxSci FYI Blog: Learn about HIPAA email encryption, secure email encryption, and more
LUXSCI

Posts Tagged ‘nist’

TLS 1.0 to 1.2 and NIST TLS Cipher Updates: Email Program and Web Browser Compatibility Issues

Thursday, June 7th, 2018

It happens at least every few years: system administrators need to update the security configuration of their servers to keep up with the latest best practices and to close newly found security issues(i.e., via changes to recommended TLS ciphers and protocols).  These updates can be rocky. Change often introduces incompatibilities that prevent certain systems or programs from being able to connect to the updated systems.

TLS Encryption Compatibility

In this article we are going to look at what email program an web browser incompatibilities arise when you migrate from using the “old standard:” TLS v1.0+ and the ciphers recommend by NIST 800-52r1 to using either TLS v1.0+ and the new NIST 800-52r2 ciphers or TLS v1.2+ and the new NIST 800-52r2 ciphers.

Why?

  1. PCI requires that servers that need to be PCI complaint use only TLS v1.1+ (which really means v1.2+) by the end of June, 2018.
  2. NIST 800-52r2 is in draft, but its updated cipher list removes many ciphers from revision 1 that are now considered “weak” and introduces a number of new, better ciphers.  Administrators should be moving towards NIST 800-52r2 cipher support as a best practice.
  3. Organizations that require HIPAA compliance should also follow the NIST guidelines and prepare NIST 800-52r2 support and, where possible, eventually eliminate pre-TLS 1.2 support. See: What level of TLS is required for HIPAA compliance?

Read the rest of this post »

Don’t Make Me Change My Passwords!

Friday, October 27th, 2017

2017 NIST changes affect the need to require period periodic password changes…yay!

Read the rest of this post »

Is Email Encryption via Just TLS Good Enough for Compliance with Government Regulations?

Monday, August 24th, 2015

There are many ways to encrypt email, TLS being the simplest and most seamless.  With SMTP TLS (the use of TLS encryption to secure the “SMTP Protocol” used for the transmission of email between computers), messages are transported between the sender, recipient, and all servers securely.  TLS is a layer that fits seamlessly over “regular email” to ensure transport email encryption when supported by both the message sender and the recipient.  With SMTP TLS, sending a secure message works and feels the same as sending any other email message.

“It just works.” That is the ideal combination of security and usability.

SMTP TLS for Email Encryption

However, SMTP TLS only solves the problem of email encryption during transmission from sender to recipient.  It does not in any way secure an email message while it is at rest, whether while in the sender’s “sent email” folder, queued or backed up on the email servers of the sender or recipient, or saved and stored in the email recipient’s folders.  While SMTP TLS is really easy to use, it is important to consider if use of SMTP TLS alone is “good enough” for companies to comply with the many U.S. government laws which apply to email.

When it  is “good enough,” organizations may opt for the seamless simplicity of TLS over the added complexity of other modes of secure email communication.

In this article, we shall examine the security afforded by SMTP TLS and compare that to other modes of email encryption such as PGP, S/MIME, and Escrow (i.e. picking up your message from a secure web portal).  We shall then look at many of the most important laws (HIPAA, GLBA, Sarbanes-Oxley, SB1386, NASD 3010, FRCP, SEX 17a-4, FINRA, and PCI DSS)  to see what is said or implied about using “Just TLS” vs. other, stronger forms of encryption.  We won’t spend a lot of time explaining each law; if you are interested there are innumerable articles on the web for that.  We  focus only on what they say or imply about encryption for email transmission and storage.

The short answer is that many of these laws outline various requirements for email storage, archival, and retrieval for legal proceedings without specifically delineating requirements for the encryption of those messages.  So, use of TLS is just fine with respect to those.

For PCI compliance, avoid email if at all possible; however, if you must use email for sending credit card data, “Just TLS” is not sufficient.

For the rest, the burden ends up being on each individual organization to decide for itself the level of encryption appropriate to protect sensitive data.  Use of encryption methods that provide protection for data at rest can mitigate liability in the case of a breach, but they are not mandated.  There are also ways of protecting data at rest that do not involve more onerous methods of email encryption.

Indeed, your internal risk analysis may find that “Just TLS” is best in some cases and methods that provide explicit data-at-rest email encryption are warranted in others.

Read the rest of this post »

LUXSCI