" s/mime Archives - HIPAA News, Web & Email Security Tips & News - Plus More | LuxSci

Posts Tagged ‘s/mime’

Creating Secure Web Pages and Forms: What You Need to Know

Monday, September 25th, 2017

Fred is a busy small business CEO.  He hired a cheap developer online to setup his secure medical web site for him.  The developer got an SSL certificate and setup pages where patients can make appointments and the doctor can receive patient requests and notices, “securely”.  However, the developer didn’t have any real training in security, none in HIPAA, and as a result, PHI was being sent in the clear, there were no audit trails or logs, SSL security was not enforced, and may other serious issues plagued the site.  The worst part — No one knew.

Luckily, Fred was made aware of the situation before a serious security breach happened (that he knew of); however, he had to re-do the site from scratch, more than doubling his time and money costs.

Creating secure web pages and forms

Creating a web site that has “secure” components requires more than slapping together some web pages and adding an SSL Certificate.  All such a certificate really does is create a thin veneer of security — one that does not go very far to protect whatever sensitive data necessitated security in the first place.  In fact, naive attempts at security can ultimately make the data less secure and more likely to be compromised by creating an appetizing target for the unscrupulous.

So, beyond paying big bucks to hire a developer with significant security expertise, what do you do? Start with this article — its purpose is to shed light on many of the most significant factors in secure web site programming/design and what you can do to address them.  At a minimum, reading this article will help you to intelligently discuss your web site security with the developers that you ultimately hire.

Read the rest of this post »

Email Encryption Showdown: SMTP TLS vs PGP vs S/MIME vs Portal Pickup

Monday, May 29th, 2017

While messaging apps may have become more popular over the last ten or so years, email remains an important method of communication, particularly for business. Despite its common use, there are many security problems associated with regular email:

Message Tampering

False messages are a significant threat, particularly when it comes to business and legal issues. Imagine someone else sends an email from your account – how can you prove it wasn’t you? There are many viruses that spread in this way, and with regular email, there is no concrete way to tell whether a message is false or not.

Email Encryption

Normal emails can also be modified by anyone with system-administrator access to the SMTP servers that your emails pass through. They can alter or completely delete the message, and your recipient has no way of knowing if the message has been tampered with or not.

In the same way, messages can be saved by the SMTP system administrator, then altered and sent again at a later time. This means that subsequent messages may appear valid, even if they are actually just copies that have been faked.

Read the rest of this post »

Self-Addressed Spoofed Email: How to Shut Down Spam

Thursday, May 11th, 2017

Spam messages coming from… your own email? This may sound like a cheesy movie plot, but this form of spam, known as “spoofing,” can have horrifying consequences if they result in compromised security, stolen data, or malware on your company’s machines. Read on to find out how to snuff out spoofing and help everyone avoid these attacks in the future.

Forged Email

Read the rest of this post »

Next Generation Data Loss Prevention (DLP) with LuxSci Secure Email

Tuesday, September 29th, 2015

Data Loss Prevention (DLP) describes a plan for companies to control the sending of sensitive data.  E.g. this can include controls to stop the flow of sensitive data or to ensure that sensitive data is always well-encrypted (for compliance) when sent.

In the context of email, DLP is usually achieved through the following formula:

  1. Construct a list of words, phrases, or patterns that, if they are present in an email, signify an email message that may contain sensitive information.
  2. Have all outbound email scanned for these words, phrases, or patterns
  3. For messages that match, take action:
    1. Block: Refuse to send the message, or
    2. Encrypt: Ensure that the message is encrypted
    3. Audit: (and maybe send a copy of the message to an “auditor”)

This classic DLP system is available through many email providers and has been available at LuxSci for many years as well. However, it does have a glaring limitation — no matter how complete and complex your DLP pattern list is, it is almost certain that some messages containing sensitive information will not quite match (or the information will be embedded in attachments that can’t be searched properly).  If they do not match, then they will escape in a way that may be considered a breach.

Read the rest of this post »

Are you Minimizing your Risk by using the Next Generation of Opt In Email Encryption?

Friday, September 11th, 2015

We have long held that leaving it to each sender/employee to properly enable encryption for each sensitive message (a.k.a “Opt In Encryption”) is too risky.  Why? Any mistake or oversight immediately equals a breach and liability.

Instead, LuxSci has always promoted use of “Opt Out Encryption,” in which the account default is to encrypt everything unless the sender specifically indicates that the message is not sensitive.  The risk with Opt Out Encryption is very much smaller than with Opt In.  (See Opt-In Email Encryption is too Risky for HIPAA Compliance).

The problem is: many companies use Opt In Encryption because it is convenient when sending messages without sensitive information — you just send these messages “as usual,”  without forethought.  These companies are trading large risks in return for conveniences.

LuxSci has solved the “Opt In vs. Opt Out” conundrum with its SecureLine Email Encryption Service.  You could say that SecureLine enables the “Next Generation” of Opt In Email Encryption — combining both usability and security.

Read the rest of this post »

Toggling Between TLS-Only and More Secure Encryption Methods

Thursday, September 10th, 2015

There are many ways to send an email securely.  These range from the super-easy-to-use but less secure “TLS” method (see About SMTP TLS) to the universal “pick it up on a secure portal method” (that we call Escrow), to the very secure but harder to deal with PGP and S/MIME methods.

Many people like to use just TLS for email transmission security whenever possible, simply because it is so easy for everyone to use — you can encrypt everything, using TLS when possible and Escrow when TLS is not supported by your recipients.

However, if you have compliance needs or deal with sensitive information, there are many situations where you may like to “jack up” the level of encryption from just enforced TLS to TLS if possible plus one of the other methods … one that is more secure and which provides for encryption at rest.  (See: Is Email Encryption via Just TLS Good Enough for Compliance with Government Regulations?)

Disabling “Just TLS” on a per-message basis is quite easy with LuxSci.

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 »

The Case For Email Security

Tuesday, March 31st, 2015

Section 1: Introduction to Email Security

You may already know that email is insecure; however, it may surprise you to learn just how insecure it really is. For example, did you know that messages which you thought were deleted years ago may be sitting on servers half-way around the world? Or that your messages can be read and modified in transit, even before they reach their destination? Or even that the username and password that you use to login to your email servers can be stolen and used by hackers?

This article is designed to teach you about how email really works, what the real security issues are, what solutions exist, and how you can avoid security risks.

Information security and integrity are centrally important  as we use email for personal and business communication: sending confidential and sensitive information over this medium every day. While you are reading this article, imagine how these security problems could affect your business or personal life and your identity…. if they have not already.

Read the rest of this post »

Can S/MIME be trusted when SSL has had so many security issues?

Thursday, March 26th, 2015

SSL and TLS have had a lot of security issues over the past 1-2 years.  While these have been patched quickly, they have been very bad and have changed our view of and trust of the Internet.  S/MIME is really just aspects of SSL/TLS applied to secure email messages (we looked at this previously).  So …. can S/MIME be trusted?  Does it suffer from the same vulnerabilities as SSL?  Is S/MIME a good thing to use for secure email or should it be avoided with a 10-foot pole?

As we shall see, S/MIME is impervious to the majority the issues with SSL due to the fact that there is no real-time negotiation of cryptographic algorithms and there can be no man-in-the-middle.

Lets see…

Read the rest of this post »

Did You Know? S/MIME is like SSL for Email Encryption

Tuesday, March 24th, 2015

S/MIME is a popular technology for end-to-end email encryption and is analogous to PGP in the way that it works.  It is commonly available in most modern email programs and in many server-side email and WebMail encryption services like LuxSci SecureLine.

Folks are used to thinking about Internet security and encryption in terms of web site security. E.g. the “https://” that secures our everyday life working in our web browsers is the signal that SSL/TLS is being used to encrypt traffic between ourselves and the web server.  People are even becoming used to the fact that TLS (with SMTP) is also commonly used to secure the transport of email messages from server-to-server.

These are all good things!

S/MIME (like PGP) is different — it encrypts the email message before it is sent and the message stays encrypted until the recipient opens it.  It “doesn’t matter” how this message is transported to the recipient … its secure the whole way.[1]  But did you know that S/MIME is really just an application of the same SSL/TLS technology that secures your traffic to securing your messages?

[1] S/MIME (and PGP) do not secure your message headers (e.g. the subject, recipients, etc.), it only secures the message body and attachments.  So, the added security of SMTP over TLS does serve to protect those things that S/MIME does not protect.

Read the rest of this post »