🔥 Find me at MedicalDevicesGroup.net 🔥
3 min reading time
Any bets on which group member will “pull an Anthem?”
Anthem Blue Cross, America’s second-biggest health insurer, did not encrypt the 80-million customer and patient records now in the hands of hackers.
Encryption would have rendered the stolen data useless.
The Wall Street Journal understates the damage and impact:
“Anthem didn’t encrypt the data taken in the theft as a short-term cost savings measure, that will likely cost them dearly in the long run.”
Your security is only as strong as your weakest link. In this case, the hackers tricked five Anthem employees into downloading malicious software, thereby revealing their passwords.
Marc Goodman, author of http://medgroup.biz/Future-Crimes, February’s #1 recommended nonfiction book in Apple’s iBook store, said, “Here are three ways Anthem’s cautionary tale is immediately relevant to medical device players:
First, a data breach (where customer, financial, or health information is leaked) is enough to seriously compromise a company’s long-term viability.
Second, devices can be compromised – for example, hacker devices like the Bluetooth cannon can subvert diabetic pumps and dump too much insulin into a patient’s body.
Third, most wearables sync with a user’s mobile phone, via either Bluetooth or Wi-Fi connectivity. When they do, personal health information joins the Internet of Things, and can be hacked just like other IoT objects.
52 percent of fitness apps have no available privacy policies. How is that data being secured? How can it be shared with third parties? What are the liabilities and risks?”
Marc added, “Joe, some readers may consider your post alarmist but if they saw what I’ve seen, they might revisit their data security policies and techniques right away. It’s not a matter of ‘if’ a medical device company will implode over data, it’s a matter of ‘when.'”
So what do you think, Group?
Alarmist or a needed wake-up call?
That was just seven weeks ago.
Target? Home Depot?
I wonder if some of us think we’re safe because we’re small and Anthem, Sony, Target, and Home Depot are huge (and worthwhile?) targets.
Medical device cybersecurity is a major initiative at CDRH/FDA.
See http://medgroup.biz/CDRH-security. We invited FDA to cover this topic at the 10x Medical Device Conference in May.
Will Sony finally scare you into action?
Siemens, Pfizer, Hospira, and You (89 comments)
Is it Time for the Management Review Already?
How is 3D printing impacting the design and manufacture of medical devices?
Have you received a FOIA request for de novo reclassification order and/or decision summaries? How long did it take?
Make it a great week.
In building out the content for our [http://ClearRoadmap.com|leo://plh/http%3A*3*3ClearRoadmap%2Ecom/3-No?_t=tracking_disc] mHealth guidance solution I got to dive in to some of the standards that apply here. Its not true that
>>Expecting every company to take the time to develop a rocksolid secure system, is probably doomed to failure.<< 21 CFR 11, HIPAA and other regulations do require that companies pay close attention to such security. Perversely it is the competiveness of the marketplace that undermines this. The competitiveness drives companies often to ship products before they have been fully tested - this is particularly true of startups, which means more opportunities for " 'sploits" (security vulnerabilities). But the real issue is not so much new systems as it is integration with older systems (which is why a modular backbone based system is probably not a good idea). A great example is the now somewhat infamous "Heartbleed Bug" [http://heartbleed.com/|leo://plh/http%3A*3*3heartbleed%2Ecom*3/_xjT?_t=tracking_disc] in the open source SSL libraries. For non-techies, this is the code that implements the encryption that is part of HTTPS connections. And this bug has been in the code since the late 1980s.
So this is code that has been looked at by very many folks, used by millions and still roughly 1% of all software systems on the internet have not fixed the bug. One reason in some cases is that the ability to recompile and redeploy the existing solution is not possible: the tools no longer are 100% available, the developers are gone or it was integrated into your system via a component from a company that is no longer in business.
This argues strongly for a return to the somewhat discredited SOA (Service Oriented Architecture) approach of building healthcare systems. To some extent Apple’s Healthkit and Microsoft’s HealthVault do take this approach. They are both “secure” services that your component applications can connect to. And similarly by building your components as services (though not the “legos plugging into a backbone” approach) that then are explicitly interconnected to other services you have validated as trustworthy – you enable the ability to swap out the components at minimal cost if they cease to be functional.
Yehuda Zicherman D.Sc.
Here’s the link to that prior discussion:
About 5 months ago there was a good discussion here titled “Will allowing patients access to EHRs pose a security risk?”, and after those high level discussions, all the different opinions, we saw the domino effect of these corporations in the “hacking block”, where these cyber-punks were successful in gaining control of their data for the misuse of their cyber-punk-peers.
Now (unfortunately for the 80+ million that trusted their more intimate data to Anthem) the hacking-block chopped ever so closely to that discussion (should I rub it in with an “I told you so”?), showing once more that if these large mammals are falling prey to these minute organisms, imagine how would any sane human pretend to take care of the security of their own health-data, nevertheless create another “entity” where to store, manage, view and edit the data. One entity that needs to come from the ground up solely based on “better than bank or NYSE” grade security (notice I left the DoD and NSA out), then think how the service will be deployed.
By the way, a health data set is more lucrative than stealing a little credit card, SSN/BD/Address combo. More lucrative you ask?, the answer is yes!, because now instead of making a little charge for porn here, and a little charge for 4 tires there, the cyber-punks and their peers can bill and get paid in larger sums, where they will float and get paid way before someone figures it out.
Wake up all, everyone holding large amounts of profitable data will be and is, as we speak, under attack. Do not wake up, do not heed the word “security” and what it implies in your daily cyber-connected life, do not create a long complicated password for each of your online accounts, continue using the same password for all your online accounts, do not use backups, click on every ad or attachment you see, do not even think to read/learn/act about what encryption is, continue feeding your immature narcissism posting your life for everyone to see and read, so everyone (friend and/or foe) know where you are, where you are going, when you will be back, how many bathroom stops you made along the way, continue shedding little by little small pieces of information that will enable someone out there with ill intent to attack you directly, and continue feeding the ones that exploit Social Engineering, the classical method used to gain entry to Anthem’s servers, as Joe said: “the weakest links”, to which I add: times 5.
Social Engineering is only a small part of that dark business, there are countless other ways these cyber-punks can gain entry to a large system (imagine how easy would be to hack yours), reason why those holding my data, your data, everyone’s data, need to be held accountable for more than what Anthem will suffer. A simple free credit monitoring and alert for a year is not enough to stop a breach of my data. If you all do not demand more accountability and satisfaction then we all will be served with a lollipop after been told “oopppss!, we did it again, this time even your Fruit-of-the-Looms were exposed to a breach, but any way, what flavor you wish your lollipop to be?”
This is and will continue to be a very expensive mistake for all those companies and every single individual affected by these attacks, many will continue to fall. The question is: what every single one of you is doing now, today, to protect your own data, control your access and privileges to the systems you most access. Once the weakest links are not hardened, these attacks will continue and will get bigger. Do not say “it will not happen to me”, as I might have to title you as delusional, not an alarmist.
Now, I will go back to work because someone has to, have a great one.
In a recent blog post, I spoke about treating EMRs as Lego projects. A central medical authority could decide on all of the components that belong in an EMR, and then open up the system to module developers. These module developers could develop anywhere from one to hundreds of modules that would be plugged into the EMR backbone. Competition would exist at the level of the modules.
Basic features like storing and retrieving personal patient information could be part of the backbone, and be implemented with all of the necessary security. All EMR module developers would use this backbone API for security sensitive activities. For example, if you wish to transfer a chart to another EMR, a backbone utility would handle the anonymization and securing of the data before transfer. Of course, companies could compete over the development of these backbone facilities. The point is that there would tend to be much less duplication of work. Also, the basics like security would be included as part of the basic package of the EMR backbone.
I personally think that designing monolithic systems that are so huge that they are hard to control, has proven itself to be far too problematic. It also denies users the opportunity to use best of breed options for each component of an EMR. Perhaps one company has a top-of-the-line OB/GYN module and another company has a top-of-the-line ER module. EMR designers would no longer have to choose a single system that might or might not excel in both of these areas.
There’s no doubt that EMR would add value. The risks and exposure need to be addressed before this can truly happen. In the IoT world, and with all of the unsecure BYODevices out there, there’s huge exposure right now.
I’m looking forward to grabbing that bull by the horns and shutting down those not authorized to the extent that’s possible. It can be done.
Sabrina De Marzi
Marked as spam