Yearly Archives :

2016

How safe are HTTPS connections? Not as safe as you think. 1024 403 Alex Mushkin

How safe are HTTPS connections? Not as safe as you think.

One of the pillars of internet security has fallen, and until it’s universally fixed, hackers will have the upper hand.

When making an online purchase, any reputable website will require a secure HTTPS connection before requesting payment information and completing the transaction.  HTTPS is the ubiquitous method used by browsers and websites to securely exchange sensitive data.  Its underlying encryption has historically been provided by SSL, which is a familiar term to many Internet users.  SSL uses digital certificates and strong encryption to create a secure tunnel between a web browser and web server.  For online purchases, it allows you to safely enter your account details, provide your credit card payment information and complete the transaction.

Unfortunately, weaknesses have been discovered in SSL encryption. Hackers have used these exploits to break through its security projection.  So that sensitive data you exchanged over an HTTPS connection may not be as protected as you think.  Fortunately, HTTPS can use additional encryptions algorithms that don’t have the weaknesses uncovered in SSL.  Specifically, the TLS or Transport Layer Security algorithm can be used, and it’s already supported by a wide range of web browsers and websites.

But which web sites support TLS, and better yet, which ones have disabled SSL altogether so that only more secure TLS algorithms can be used?  Unfortunately, without running complicated third-party cryptography tools, it’s almost impossible to tell.

In many ways, you place your trust in those vendors that you do business with.  DataMotion specializes in data security and compliance with privacy regulations.  Being a trusted supplier to thousands of organizations over the past 16 years, we do not take that trust lightly.  As part of our continuous security operations, we stay informed of emerging threats like the SSL vulnerability and apply immediate corrective action.  While the security changes occurs behind the scenes, invisible to our users, the relationships we form with our customers are visible in everything that we do.

Opportunistic TLS – Two Good Ways to Put Your Email at Risk 1024 403 maxon1212

Opportunistic TLS – Two Good Ways to Put Your Email at Risk

Email encryption allows organizations to protect sensitive messages and increase their compliance with privacy regulations.  One common encryption method, known as opportunistic TLS, automatically tries to secure the path that messages take when they travel to recipient email systems.  Since this type of encryption is completely transparent to users, organizations often utilize opportunistic TLS to comply with privacy and security regulations.

Unfortunately, compliance strategies based on opportunistic TLS result in frequent breaches where sensitive data is sent over the public internet without encryption.

There are two main scenarios where breaches can occur.

First, and the most common case, is when recipient email systems do not support TLS encryption.  As a result, encrypted paths are not established for sensitive messages to travel.  Opportunistic TLS systems will then step down to standard delivery, and send messages to those systems without any encryption.

The second case, also frequently encountered, is when the recipient utilizes a cloud-based anti-virus and anti-spam service.  These services often support TLS when receiving email, so a sending system configured for opportunistic TLS believes it has delivered the message securely to the recipient’s email server.  Actually, the message was delivered securely to an intermediary.  There is no way for the sending system to know if the next leg of the message’s journey, from the cloud service down to the recipient’s email system, is actually secure.  Unfortunately, in most cases, this leg of the message’s journey is not TLS enabled, so messages travel over the public internet in unencrypted form.  And as a result, a breach in compliance regulations has occurred.

Despite the problems of opportunistic TLS, when possible, delivering messages by TLS is still a good method to protect sensitive data.  However it should only be enabled on a case by case basis when end to end encryption between email systems can be confirmed.  As the holistic secure data delivery system, DataMotion SecureMail ensures that all of your messages are delivered with end to end security.  It does this by supporting a variety of delivery methods including TLS.  This allows your organization to easily exchange sensitive data with the widest range of customers, partners and vendors while maintaining compliance with privacy regulations.

Best Practices: Emailing Patient Records in Compliance with HIPAA 1024 403 Hugh Gilenson

Best Practices: Emailing Patient Records in Compliance with HIPAA

In January 2016, the HIPAA regulation got more teeth in the area of providing patients their medical records on request (files, notes, diagnostic images, lab results, C-CDAs). The US Department of Health and Human Services published detailed FAQs regarding patients rights with respect to requesting their medical records from their care providers:

  • Request full medical records from all HIPAA-covered entities, e.g.
    • labs, imaging and surgery centers
    • insurance plans, hospitals, pharmacies, and physicians
  • HIPAA covered entities have 30 days to respond
  • Provide in the format requested by the consumer
    • Electronic format
    • Specific messaging format

Under 45 CFR § 164.524, available at http://www.hhs.gov/hipaa/for-professionals/privacy

The department of Health and Human Services has generated some educational videos for consumers (patients) – instructing them of their rights, and showing some role play at the doctor’s office. There’s also a HHS infographic, which you can find below, that explains the rule as well.

As a secure messaging company, there was some initial dismay at the videos and written guidance HHS provides patients:

“…..covered entities must safeguard the information in transit, and are responsible for breach notification and may be liable for impermissible disclosures of PHI that occur in transit.  The only exception arises when an individual has requested that the PHI be sent to the third party by unencrypted e-mail or in another unsecure manner, which the individual has a right to request.  As long as the individual was warned of and accepted the security risks to the PHI associated with the unsecure transmission, the covered entity is not responsible for breach notification or liable for disclosures that occur in transit.”

Wow – unsecure email is OK for sending PHI (Protected Health Information) as long as the healthcare provider warns the patient that there is a security risk, and the patient accepts that risk. How do you track that? Is it realistic to think both sides of that transaction will be truly cognizant of the requirement to inform, and the real security risk?

I turned to our CMO, Dr. Peter Tippett for some guidance and perspective. What’s the best practice for a physician’s office to comply with HIPAA when emailing medical records to a patient?

His response – so practical, and sensible:

Covered entities should always use some form of secure messaging when emailing medical records to patients for several reasons.

  1. Email encryption, logging and other HIPAA requirements are expected and required UNLESS the patient EXPLICITLY is warned, and EXPLICITLY agrees to unencrypted mail.  Keeping these warnings and permissions straight and getting the right message to the right patient via the right modality will fall in the “too hard” category for most covered entities.
  2. Covered entities will worry because they will be sued anyway if a patient, for example agrees to receive blood test results one week; and a few months / years later, gets sent something truly private, which is exposed because it was regular email.
  3. Most patients will not answer the question at all as to whether or not it would be ok after a warning to send the message via regular email – which could lead to errors, so a hard stop in the workflow, and risk of not meeting the 30 day delivery window.
  4. The fact that at least some patients will want the message securely, will require all covered entities to have a solution.

Given that email is such a convenient way to exchange files, and email encryption solutions such as DataMotion SecureMail is so affordable and easy to use by senders and recipients – this new HIPAA measure is another driver for adoption by covered entities. It also enables files up to 2GB – perfect for diagnostic images. It’s a small price to pay for compliance (and happy patients)!

One response to “Best Practices: Emailing Patient Records in Compliance with HIPAA”

[…] person at the center of their care, and in patient-centered HIT, as will a heightened awareness of HIPAA rules for requesting and receiving patient records. For the mobile app developer, RESTful APIs for secure health information delivery services help […]

Salesforce Service Cloud and HIPAA Compliance 1024 403 Hugh Gilenson

Salesforce Service Cloud and HIPAA Compliance

Q: My company sells to the healthcare industry.  Is it a HIPAA violation when my Customer Service Rep replies to a support ticket on Service Cloud?  I mean, Salesforce is HIPAA compliant, right?

A: You very well may be in violation of HIPAA standards.  Here’s why.

Yes, the Salesforce platform itself can be made HIPAA compliant.  Salesforce will sign a Business Associates Agreement (BAA) and if you connect Shield you’ll get monitoring, encryption, and auditing functionality of your Salesforce instance.  But that’s only part of the compliance story because it only covers the data while it’s residing within the Salesforce ecosystem – the data at rest.

HIPAA also applies to data in motion.  Simply stated; data containing protected health information traveling over a public network (like the Internet) must be encrypted in transit.

So let’s take a look at your scenario:  Suppose you’re a CSR using Service Cloud to view a new support ticket.  A customer sends an inquiry explaining that his doctor wants him to get additional testing to rule out prostate cancer and he wants to know if his insurance covers the new tests.  The customer’s contact information plus a medical condition equals Protected Health Information (PHI) and needs to comply with HIPAA.

While you’re viewing the information on Service Cloud, it’s covered by HIPAA (see the first paragraph above).  But when you reply to that ticket the PHI is almost always copied as part of the ongoing dialogue thread and is sent from your company to the customer via email or other messaging format.  It’s now data in motion traveling over the Internet, and your company (not Salesforce) is responsible to encrypt the message before it’s sent.

Luckily, there are solutions, like DataMotion SecureMail, that integrate easily with Salesforce, and have the ability to filter by policy rules and keywords and automatically encrypt messages containing PHI.  Our solution also adds logging and tracking for better visibility and governance (proof you need in the event of a HIPAA audit by the feds)!

Summary

Yes, the Salesforce Platform can be made HIPAA compliant.  But when you reply to a Service Cloud ticket, that’s data in motion and it’s not Salesforce’s responsibility.  Your company needs to ensure those messages are encrypted between Salesforce and your customers.  If not, you’re subject to fines, penalties and loss of reputation.