Medical Device Madness. No Excuses


Manufacturer’s Cannot Use the “Re-certification” Excuse to Dodge Security Patching Responsibilities.

In my last post, I touched on the issue of cybersecurity vulnerabilities in medical devices and how the healthcare industry struggles to manage this risk.  We also mentioned the June 2013 FDA Safety Memo that outlined what it perceived as the new responsibilities for manufacturers, healthcare entities and the FDA itself regarding the securing of these devices.

Recently I published an online course in collaboration with the Financial Times / ExecSense on this topic.  I covered quite a bit of the problematic history of medical device security as well as some strategies on how to address this issue on the technology and business fronts.  Healthcare leadership push-back on recalcitrant medical device vendors  will be key in addressing this problem.   Painful cultural change will also be necessary.

Review the June 2013 safety communication, the FDA broke down the responsibilities of the healthcare organization, medical device manufacturer and the FDA itself. If you are in the healthcare arena, the document is short and well worth the read (Link Above), but I’ll put up some highlights:

Healthcare Providers
• Monitoring network activity for unauthorized use.
• Making certain appropriate antivirus software and firewalls are up-to-date.
• Protecting individual network components through routine and periodic evaluation, including updating security patches and disabling all unnecessary ports and services

Device Manufacturers
• Take steps to limit unauthorized device access to trusted users only, particularly for those devices that are life-sustaining or could be directly connected to hospital networks. Appropriate security controls may include: user authentication, for example, user ID and password, smartcard or biometric; strengthening password protection by avoiding hard-coded passwords and limiting public access to passwords used for technical device access; physical locks; card readers; and guards.
• Protect individual components from exploitation and develop strategies for active security protection appropriate for the device’s use environment. Such strategies should include timely deployment of routine, validated security patches and methods to restrict software or firmware updates to authenticated code. Note: The FDA typically does not need to review or approve medical device software changes made solely to strengthen cybersecurity.

• The FDA released a draft guidance on how manufacturers should address cybersecurity in their pre-market submissions. The FDA also has guidance on how manufacturers should address cybersecurity issues related to products that use off-the-shelf software.

The most interesting sentence in the document and the most powerful is The FDA typically does not need to review or approve medical device software changes made solely to strengthen cybersecurity . Of course the inclusion of the word “typically” provides device manufacturers with some significant wiggle room. However this statement begins to take the air out of the standard vendor re-certification argument when it comes to patching and endpoint protection.

Adding more fuel to the fire is the recent release of the Health and Human Services (HHS) Office of Inspector General (OIG) Fiscal Year 2014 Work Plan, which outlines their intent of focusing on medical device security. The work plan states that OIG “will determine whether hospitals’ security controls over networked medical devices are sufficient to effectively protect associated electronic protected health information – ePHI – and ensure beneficiary safety.” The document then clarifies that “Computerized medical devices … pose a growing threat to the security and privacy of personal health information. Such medical devices use hardware, software, and networks to monitor a patient’s medical status and transmit and receive related data using wired or wireless communications.

With both the FDA and HHS OIG now in the act, healthcare clinical project managers and security professionals may finally get the ammunition they need to bend the ear of medical device manufacturers. At present it is primarily the healthcare organization that has to contort its requirements and security concerns to ensure they receive vendor support for their devices.

I’d like to hear some feedback from other healthcare PMs and security professionals on this topic. So please feel free to drop me a line in the comments below!

Medical Device Madness. Security Suffering

Critical Risks

Poorly Protected Medical Devices are a Serious Cybersecurity Threat

“We can’t add a virus scanner to our device or we’ll have to get re-certified by the FDA.” If you have any time in the trenches as a healthcare project manager, you have heard those words spoken by a medical device rep. Famous for falling back on the “FDA re-certification” argument, these words have clipped the wings of many a project security and usability requirement. Since many of these devices are sold by a few key players (Phillips, GE) healthcare providers had little choice but to grit their teeth and allow insecure hardware and software to be attached to their network. Then the real challenge begins as the quirky device(s) begins to show unexpected behaviors and generally fails to play well with standardized enterprise systems. If the healthcare organization deploys an operating system patch or places their standard endpoint protection on the device, they run the risk of the vendor halting support during a device issue until the offending patch or software is removed. This can quickly escalate into a patient safety issue, so many times organizations accept the risk and keep their medical devices unpatched and under-protected.

For years medical providers have petitioned the FDA to clarify the rules around cybersecurity and medical devices. Do device manufacturers have to re-certify every time they apply an operating system patch or install endpoint protection? The issue gained more urgency as HIPAA penalties for patient data breaches became more common. Organizations rightly questioned the re-certification argument from vendors since some of the most sensitive protected health information (PHI) is passed through or collected by these devices. How can organization’s effectively manage their security risks and protect against breaches if their key devices remain vulnerable to the most common security issues; outdated patches and endpoint protection? So healthcare IT had to get creative about protecting these devices. Separate medical VLANs, additional physical security, hamstrung endpoint protection and a lot of reluctant risk acceptance. While these steps help mitigate the risk of a breach, organizations still have to contend with similar issues that led to the recent Target credit card breach; default admin passwords, patching issues and third party system access.

Clarity on these concerns may finally be on the horizon. While not a strongly worded as some healthcare security and IT practitioners would like, the FDA has recently released (June 2013) a Safety Communication on the topic of medical devices and cybersecurity. It is the first series of memos and articles that point toward the FDA beginning to crack down on the issues of medical device security.

In my next post I will summarize the FDA Medical Device Safety memo as well as provide some additional thoughts on how to address this thorny problem.  As always please feel free to leave comments below!

Of Portals and Patient Care: Education and the Healthcare PM

Patient Education, Literacy and Patient Portals are Making Healthcare InroadsPatient Education and Literacy are among the key topics that are bandied about in the Preventative Medicine discipline and its quest to reduce healthcare costs.  Of course the fact that 42 percent of patients do not understand “empty stomach” guidelines for medication is a cause for concern and a data point for how effective healthcare and wellness education has been to date.With that in mind  AtTask  has published a short piece of mine that covers Patient Education and how it impacts healthcare professionals and the project managers tasked with implementing Patient Education-based projects.

Here’s a bit of the post and then follow the link for the remainder of the article:

I had mentioned in my last post, Hazards on the HIE Road – A Map for Project Managers, that I was going to discuss Patient Education and what projects that PMs were going to be exposed to in this space.

Like most things in healthcare, patient portals and education are linked to HIPAA, Meaningful Use and the Joint Commission. Project Managers must understand the various technological, business and healthcare related drivers that are moving these tools to the fore.

Patient Learning and the tools associated with that discipline have gained considerable traction in the healthcare field. Driven by regulatory, technological, and patient forces, healthcare providers are launching suites of tools that allow patients to access their medical records online, order tests and interact with providers. Medical professionals are relying more on patient portals and other tools to drive better results for their practice and efficiently facilitate patient visits.

Not only do patient learning tools and portals educate the client, they provide risk management and business process management benefits. These tools help coordinate the distribution of clinical, administrative, and financial activities including multi-disciplinary and multi-care settings, plans of care, active care coordination, and the automation of compliance management with a healthcare provider.

– See more at: Of Portals and Patient Care: Education and the Healthcare PM

Plugging Breaches with Bureaucrats

The Paperwork Makes Your Interwebz Secure.

Filling Out These Forms Will Make You Secure....Really.

Breaches within the Sony’s and Epsilon’s networks  in recent months has shone a light on a very real concern in the Age of Stolen Information.  The government believes that more legislation and regulation will solve the security problems that plague our interconnected networks and systems.

One only has to take a quick glance the latest regulations from the Food and Drug Administration (FDA) on Medical Device Data Systems (MDDS) or the new Cyberwarfare Doctrine from the Pentagon to see the trend toward greater regulation.

But rules dictated by government fiat always lags far behind technological advances and creates a “security by compliance” culture.  So what is the solution?

In my opinion, additional Federal legislation on the subject of information security breaches is unnecessary.  Currently there are multiple industry regulatory regimes that cover information security best practices.  At a high level here are a few:

I have recently contributed to three  articles that tie into my opinion on security by regulation.  One was for the Chicago Tribune entitled “Security Breaches Highlight Need for Consumer Vigilance.  It covered the impact of the Walgreens, McDonald’s, Gawker security breach.  Another was published for PCWorld on the Playstation Network security breach.  The title of the article was “Experts on the PSN Hack: Sony Could Have Done More.  Finally, a piece just ran in InfoWorld entitled “10 Hard Truths IT Must Learn to Accept” where I discuss the security by compliance issue and how the pursuit of 100 percent compliance and security is a folly.

Legislation will not address enterprise security problems.  However, if you look at what caused the PSN security breach, there were multiple issues that lead to the compromise.  The chief cause appears to be that Sony was lax about routine maintenance of the infrastructure and the complete lack of internal and external communication.  This includes:

  • Server patching and hardening
  • Monitoring the network and servers for suspicious activity
  • Disjointed or missing breach response procedures
  • Lack of security leadership in the organization
  • Lack of breach communication plan
If We Hit it Harder It Might Fit!

Government Regulations at Work.

The best way to minimize the risk of a breach for an organization is to stay on top of standard maintenance and monitoring procedures.  Keep the organizations servers patched and make sure they are hardened before putting them on the production network.

Ensure there is a security breach response plan that has been tested and communicated to the highest levels of the company.  Have a single point of contact that directs communication regarding the breach to the appropriate parties.  Also, ensure that the breach plan includes a robust communication plan for potentially effected customers.

Finally, there is always going to be a risk for a security breach or data loss.  Systems and software are designed by humans and there will be flaws that can be exploited.  Plus, social engineering will always provide a path to compromising the most secure systems due to the fallibility of the human element.  Legislation will not address these factors.

Security practitioners understand that there is always a risk for a security breach.  Therefore, risk assessment and risk management are a key component of a security professional’s job.  Identify the most critical systems and data and implement the most robust safeguards around them.  Focus monitoring efforts on these critical areas and ensure the organization’s senior leadership understands the risks, mitigation strategies and internal/external communication plans.

In my experience, compliance with multiple frameworks and regulations creates a belief in security by compliance. Organizational leadership buys into the mindset that if they have all the check-boxes marked, then they are secure and additional policies, programs and monitoring are wasted efforts.  This is a critical mistake in an age when your adversaries can turn on a time and exploit your inflexibility.

Dr. House, EHR and Consulting: The Case of the Unpopular Mandate

EHR, HIPAA, HITECH and its Impact on Successful Implementations

Consulting and the Fictional TV Doctor.

At a high level, information technology professionals are like physicians.  They recommend new treatments (EHR software) to address conditions (HIPAA).  Unfortunately IT pros don’t get paid nearly as well, but at least we both worry about outsourcing to some degree.

The stereotype of the IT professional can also be compared to a doctor, or at least a fictional one, Dr. Gregory House.  Sullen, anti-social, with a high regard for his own knowledge, Dr. House avoids all contact with his customers (patients).  He only swoops in to provide a solution to a problem (condition) before he retreats once more to his solitude. [Read more…]