Posts Tagged ‘end-to-end encryption’

This week, we feature the second part in our series with Shahid Shah, an enterprise software analyst that specializes in healthcare IT with an emphasis on e-health, E M Rs, data integration, and legacy modernization.  He is also founder of the popular Healthcare IT Guy blog.

VPN Haus: Let’s talk about data encryption, security, and safety.  What role does that play with mhealth?

Shah: Security and safety both play key roles in healthcare generally and mHealth specifically because trust is paramount. Companies like RIM, considered the best in mobile security, use what’s called “end point encryption” on the devices and centralize management of that encryption. With end-point security like RIM’s, it’s very nice because everything is fully encrypted both at rest on the mobile device and in transit so it’s not easy to eavesdrop on those messages.

Other common devices iPhone and Android (of course non-smartphones) don’t have encryption typically set on the highest settings and do not have centralized enterprise-wide security policy settings which means they are likely not very secure. Unsecure and non-encrypted mobile phones are actually quite dangerous and unless you have a good system administrator who understands a heavy smartphone use environment and sets up the right policy it can lead to unintended data leakage if a phone is stolen or lost.

From my perspective, encryption at rest and encryption at transit are being handled really well. But it’s important to remember, while the phone may support it, it doesn’t mean that every application is using it that way. Another thing to keep in mind is that security and privacy are not the same thing: government regulations require both.

VPN Haus: What about simple human error? How do you protect against this?

Shah: This is where system and phone administrators struggle. When you have central administration, like with BlackBerry or Windows, it’s easy to say “everybody needs a pin or an access code to get on your phone.” But with Android or the iPhone, you have to tell users, “always make sure your phone has password protection.”

Even with remote wipe, having password protection for your phone is important. This way, you can go to your administrator and say, “hey, I lost my phone, can you please erase it?” Knowing that it’s password protected, both you and your administrator know you’ve bought some time. Those two things alone can do a world of good. But to a lot of people , it’s too hard to require a PIN for each use so they just leave it off. People don’t want to put in a four-digit code on their iPhones every time they want to use it. This is a policy, unfortunately, that you can’t enforce without some centralized tools and it’s imperative to use them.

Stay tuned, next week we’ll continue our conversation with Shah, discussing HIPAA and the future of mobile health security. For part 1 of the series, click here.

Editor’s Note: Due to popular demand, we’ve bumped Dr. Ruchi Dass’ next post earlier than it was originally scheduled.

As the Mobile Health Expo 2010 gets underway this month, we’ll feature experts on the topic of mobile health. This week, we continue our conversation with Dr. Ruchi Dass, mHealth champion and council member for the Gerson Lehrman Group, in the second of a three-part series on mhealth. Dass has been involved in specific healthcare IT, e-learning and ICT projects for the public/private sector in India.

VPN  Haus: Are there a security risk in healthcare mobility that is overrated or underrated? What are they?

Dass: Not overrated actually. Healthcare mobility is the key. As manpower is scanty in hospitals, therefore in scenarios where large volumes of background traffic needs to be sent from automated programs talking to other automatic programs, IPsec here serves the best. End-to-end security is, however, required in several government health missions where there are a lot of private partners in the value chain and secured/encrypted communication is a must. SSL-enabled VPN is useful here. With SSL, a secure tunnel is established directly from the client to the resource the client is accessing. With true end-to-end security, no data is sent in the clear, either on the internal network or on the Internet. Everything from the client to the resource is securely authenticated and encrypted.

VPN Haus: What are the security concerns around sensor technology, portable medical devices and wireless health applications – and how will they be mitigated?

Dass: There are several security concerns, and hence, before we deploy mobility we need to understand that fully automated Remote Access VPN Management is necessary. Solutions should be easy to use and efficient, as well. A holistic remote access solution is required to integrate all essential technologies regarding security and communication. Hospitals and healthcare enterprises are looking to upgrade, and hence, low switching costs is the major driving force coupled with greater efficiency and ease to use and deploy.

Stay tuned, next week we’ll continue our conversation with Dass, discussing the IPsec’s role mobile health security. For part 1 of the series, click here.

We continue our conversation with Martin McKeay, a seasoned IT security professional dedicated to spreading awareness about security and privacy through his “Network Security Blog” and podcast series.

On whether PCI standards will strengthen:

I think the standards are going to change, but slowly. They’ll change faster than a federal mandate could, and I think that’s their strength. The PCI standards 2.0 should be released in October, but from what we’re seeing right now, there are no major changes.

I’m hoping some of the other special interest groups working behind the scenes will provide some clarity and some guidance on new technologies. But even that’s going to take awhile, so I don’t see any major changes in the next few years.

On the technologies he’d like to see recommended in the PCI standards:

Hopefully, we’re going to see tokenization and end-to-end encryption as technologies the PCI Council recognizes and encourages more people to use and implement. Both of those are still nascent technologies.  They are technologies that a lot of people are trying to figure out and implement. But neither has an accepted industry definition or an accepted industry implementation.

On his definition of end-to-end encryption and tokenization:

End -to-end encryption is when you encrypt a credit card from the moment you take the information to the end. I feel that unless you’re encrypting from the moment you take the credit card, it’s not end-to-end encryption. But that’s open to interpretation. There are technologies that call themselves end- to-end [but don’t do that]. But it’s a nascent technology that is still being defined, and it hasn’t been implemented fully,  except in a few cases.

Tokenization is a form of encryption. You have a tokenization server that would encrypt the credit card number and give you back a number that you can use in your database. This number would look like a credit card number, but it would have no actual real relation to the credit card number.  You have the credit card information available in your server, but in your more public-facing databases, you have a number with no direct relation.

For Part 1 of this series, click here.

With more than a decade of experience in the IT and security field, Martin McKeay is a seasoned professional dedicated to spreading awareness about security and privacy through his “Network Security Blog” and podcast series.  Given McKeay’s background in QSA, he offered us deep insights into the PCI standards. Here, we’ll share them with you.

On the way the PCI Standards have been implemented:

The PCI standards are definitely meant to be a minimum standard, that’s all they were meant to be. The standards have brought a lot of [compliance] laggards to at least a minimum level of security.  And it’s given a lot of security professionals a leverage point to actually put into their corporations what they [wanted] from the beginning. And that’s one of the strongest points of PCI.

The weaknesses are, if you’re using PCI for all the tools and security and in your network – you’re going to be leaving a lot of things out. Because PCI is dealing with a single swath industry, it’s generic enough that most companies are going to have  one or two, if not multiple areas of insecurity that PCI isn’t going to do anything at all for.

On his recommendation for strengthening the standards:

The biggest risk for companies dealing with credit card information is the sheer amount of data that they’re keeping.  The fact is, most companies are keeping it for historical purposes or they are using a credit card number as in their databases for tracking customers. That’s a practice that has to stop. Quite frankly, as tokenization or end-to-end encryption are used more, there are very few reasons for merchants to store and keep credit cards numbers in the long term. We’re seeing a gradual move away from that, but it needs to accelerate. It means the bad guys will continue to attack businesses, but if you don’t have that credit card information to begin with, they won’t be going after that. But instead, it’ll be  something else.

On whether security matters to consumers:

We know for a fact that people aren’t even thinking about security because [consumers] are only responsible for the first $50 of credit card fraud and most banks will waive that in most cases. So the consumer isn’t really thinking about it until they get the breach notification letter from one of their companies with their credit card information with it.

Stay tuned next week for more from Martin McKeay, including on the fluid standards of tokenization and end-to-end encryption.