Posts Tagged ‘s/mime’

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 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.

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.

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.

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.

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:

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.

Have all outbound email scanned for these words, phrases, or patterns

For messages that match, take action:

Block: Refuse to send the message, or

Encrypt: Ensure that the message is encrypted

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.

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.