Tag Archives: FDA

Federal Healthcare Chart

The chasm between FDA regulatory and cyber security

 

When a Risk Analysis is not a Risk analysis

Superficially at least, there is not a lot of difference between a threat analysis that is part of a software/hardware security assessment and a risk analysis (or hazard analysis) that is performed by a medical device company as part of their submission to the FDA.    In the past 2 years, FDA added  guidance for cybersecurity for medical devices and the format and language of the guidance is fairly similar.

The problem is that hazard analysis talks about patient safety and relates to the device itself as a potential attacker whereas software  security talks about confidentiality of patient data, integrity of the code and its data and credentials and system availability and relates to the device as a black box.

So in fact – medical device risk analysis and cyber security assessments are 2 totally different animals.

Some of my best friends work in medical device regulatory affairs. I admire what they do and I like (almost) all of them on a personal basis.

But – over the past year, I have been developing a feeling of deep angst that there an impossible-to-cross chasm of misunderstanding and philosophy that exists between medical device regulatory people and medical device security analysts like me.

But I can no longer deny that even at their best – regulatory affairs folks will never get security.

Why do I say this?   First of all – the empirical data tells me this.  I  interface with several dozen regulatory professionals at our medical device security clients in Israel and the best of them grasp at understanding security.  The worst cases hang on to their document version controls for dear life and claim earnestly even as they are hacked that they cannot modify their device description because their QA process needs several weeks to approve a 3 line bug fix. (This is a true story).

We intend to implement encryption of EPHI in our database running on a cloud server since encryption uses check sums and check sums ensure integrity of the data and help protect patient safety.
True quote from a device description of a mobile medical device that stores data in the cloud…the names have been concealed to protect the innocent.  I did not make this up.

The chasm between FDA regulatory and cyber security

The second reason I believe that there is an impossible-to-cross chasm between medical FDA device regulatory people and medical device security is much more fundamental.

Systems like mobile medical devices live in the adversarial environment of the Internet and mobile devices. Unlike traditional engineering domains like bridge-building that are well understood and deal with winds that obey rules of physics and always blow sideways; security threats do not play by set rules. Imagine a wind that blows up and down and then digs underground to attack bridge pylons from 50m below earth and you begin to understand what we mean when we say “adversarial environment”.

General classes of attacks include elevation of privilege, remote code execution, denial of service and exploits of vulnerable application interfaces and network ports. For example:

  • Attacker that steals personal data from the cloud by exploiting operating system bugs that allow elevation of privilege.  Zero-days that were unknown when your QA people did V&V.
  • Attacker that exploits vulnerabilities in directory services that could allow denial of service. What ?  We’re using directory services???
  • Attacker that tempts users to download malicious mobile code that exploit mobile APIs in order to steal personal data. What?  This is just an app to measure blood sugar – why would a patient click on an add that injects malicious code into our code while he was taking a picture of a strip to measure blood sugar??

We talk about an attacker in an abstract sense, but we don’t know what resources she has, when she will attack or what goals she has. Technology changes rapidly; a system released 2 years ago may have bugs that she will exploit today. Our only recourse is to be paranoid and think like an attacker.

Thinking like attackers not like regulators

By being extremely paranoid and thinking like attackers, medical device security requires us to systematically consider threat models of attacks, attack vectors, assets at risk, their vulnerabilities and appropriate security countermeasures for prevention, detection and response.

While this approach is not a “silver bullet” it lends structure to our paranoia and helps us do our job even as the rules change.

And this where the chasm begins.   The rules change.   There is no QA process. There are no rules.   We are not using IEEE software engineering standards from 40 years ago.  They are useless for us.

Dorothy – we are not in Kansas anymore. And we are definitely not in Washington DC in a regulatory consulting firm of high-priced lawyers.

 

 

Tell your friends and colleagues about us. Thanks!
Share this
hipaa cloud security

How do you know that your personal health data is secure in the cloud?

Modern system architecture for medical devices is a triangle of Medical device, Mobile app and Cloud services (storing, processing and visualizing health data collected from the device).  This creates the need for verifying a chain of trust: patient, medical device, mobile app software, distributed interfaces, cloud service software, cloud service provider.

No get out of jail free card if your cloud provider is HIPAA compliant.

We specialize in medical device security and as I’ve written here and here and here – and there is no silver marketing bullet.

Medical device vendors must implement robust software security in their device, app and cloud service layers and implement regulatory compliance in people and technical operations. If you are a medical device vendor, you cannot rely on regulatory compliance alone, nor can you rely on your cloud provider being HIPAA compliant.  I’ve written here and here how medical devices can be pivot points for attacking other systems including your customers’ and end users devices.

Regulatory compliance is not security

There are two notable regulatory standards relating to medical devices and cloud services – the HIPAA Security Rule and the FDA Guidance for Management of cybersecurity in medical devices. This is in addition to European Data Protection requirements and local data security requirements  that a particular country such as France, Germany or New Zealand may enforce for protecting health data in the cloud.

The American security and compliance model is unique (and it is typically American in its flavor) – it is based on market forces – not government coercion.

Complying with FDA Guidance is a requirement for marketing your medical device in the US.

Complying with the HIPAA Security Rule is a requirement for customers and covered entity business associates to buy your medical device.   You can have an FDA 510(K) for your medical device and still be subject to criminal charges if your cloud services are breached.   HHS has announced  in the Breach Notification Rule and here that they will investigate all breaches of 500 records and more. In addition, FDA may enforce a device recall.

But – compliance is not the same as actual enforcement of secure systems

Verifying the chain of trust

Medical device vendors that use cloud services will generally sign upstream and downstream business associate agreements (BAA) but hold on:

There is an elephant in the room:  How do you know that the cloud services are secure?  If you have a data breach, you will have to activate your cyber-security insurance policy not your cloud providers sales team.

Transparency of the cloud provider security operations varies widely with some being fairly non-transparent ()and others being fairly transparent (Rackspace Cloud are excellent in their levels of openness before and after the sale) in sharing data and incidents with customers.

When a cloud service provider exposes details of its own internal policy and technology, it’s customers (and your medical device users) will tend to trust the provider’s security claims. I would also require transparency by the cloud service providers regarding security management, privacy and security incident response.

One interesting and potentially extremely valuable initiative is the Cloud Trust Protocol.

The Cloud Trust Protocol (CTP) enables cloud service customers to request and receive data regarding the security of the services they use in the cloud, promoting transparency and trust.

The source code implements a CTP server that acts as a gateway between cloud customers and cloud providers:

  • A cloud provider can push security measurements to the CTP server.
  • A cloud customer can query the CTP server with the CTP API to access these measurements.

The source code is available here on Github.

 

 

Tell your friends and colleagues about us. Thanks!
Share this
Security is not fortune telling

The top 5 things a medical device vendor should do for HIPAA compliance

We specialize in software security assessments, FDA cyber-security and HIPAA compliance for medical device vendors in Israel.

The first question that every medical device vendor CEO asks us is “What is the fastest and cheapest way for us to be HIPAA-compliant”?

So here are the top 5 things a medical device vendor should do in order to achieve HIPAA compliance:

1. Don’t store EPHI

If you can, do not store EPHI in your system at all.  That way you can side-step the entire HIPAA compliance process.    (This is not to say that you don’t have to satisfy FDA cyber-security requirements or have strong software security in general but that is a separate issue).

What is EPHI? EPHI (electronic protected health information) is any combination of PII (personally identifiable information and any clinical data.   OK – you ask so what is the definition of PII from the perspective of HIPAA?   Basically – PII is any combination of data that can be used to steal someone’s identity – in a more formal sense – here is a list of PHI identifiers:

  1. A name
  2. An address. The kind that FedEx or USPS understands
  3. Birth dates – age does not count.
  4. Phone numbers including (especially) mobile phone
  5. Email addresses
  6. Usernames of online services
  7. Social Security numbers
  8. Medical record numbers
  9. Health plan beneficiary number
  10. Account numbers
  11. Certificate/license numbers – any number that identifies the individual. A certificate on winning a spelling bee in Junior High doesn’t count.
  12. Vehicle identifiers and serial numbers, including license plate numbers;
  13. Device identifiers and serial numbers that can be tied back to a person
  14. URLs – that can be tied back to a person using DNS lookups
  15. IP address – for example the IP address of a home router that can be used to lookup an identify a person
  16. Biometric identifiers, including finger and voice prints;
  17. Full face pictures

2. If you store EPHI do a threat analysis of your medical device

The HIPAA Security Rule and the FDA cyber security guidance are very clear on this point. You can learn more about threat modeling and analysis here, here and here. Regarding encryption and medical device security, read this.

3. Implement software configuration management and deployment tools

The best advice I can give a medical device vendor is to use Git.   If you use Azure or are a Microsoft shop (our condolences – read here and here why Windows is a bad choice for medical devices) then TFS is a great solution that is integrated nicely in Azure. Note that Azure is a great cloud solution for Linux as well. Don’t get me wrong – Microsoft does a lot of things right.  But using Windows for medical devices is a really bad idea.

4. Implement log monitoring

Monitoring your logs for peaks in CPU, memory or disk usage is a great way to know if you’re being attacked.  But – if you have medical device logs and no one is home to answer the phone then it’s a waste of time.

5. Make sure the lights are on and some one is home

You’ve done a great job on your medical device software.   You did Verification and Validation and you implemented threat modeling in your development process and you have logs.  Just make sure that it’s someone knows that it’s their job to keep on eye on security events.   If you get a notice from a customer or a ping from your log manager, or an email from your cloud provider that they’re gonna reboot your services because of VENOM – just make sure the lights are on and some one is home.

 

 

 

In summary

Robust security for your medical is not fortune telling but neither is it an organizational construct.  The best way to think about your medical devices is to think about something you would give a child (or a soldier on the battle field). It has to totally reliable and safe for the patient even under the most adverse conditions.

 

Tell your friends and colleagues about us. Thanks!
Share this
risk-driven medical device security

Health Information Technology Patient Safety Action & Surveillance Plan

This is a quick update on two new documents released by the HHS and the IMDRF:

 Health Information Technology Patient Safety Action & Surveillance Plan

The US Department of Health and Human Services published on July 2, 2013 the Health Information Technology Patient Safety Action & Surveillance Plan. The FDA belongs to the HHS.

The plan defines several types of action in three categories: Learn, Improve, Lead.

·       Learn – focuses primarily on monitoring of safety of Health IT in the field.

·       Improve – includes investigating adverse events and taking corrective action. Also included are setting safety priorities and incorporating safety into certification criteria for Health IT.

·       Lead – encourages the private sector leadership for Health IT Safety and develops a risk-based regulatory framework for Health IT.

The plan is found at http://www.healthit.gov/sites/default/files/safety_plan_master.pdf .

 Standalone Medical Device Software: Key Definitions

The International Medical Device Regulators Forum, a medical device-focused regulators-only successor group to the Global Harmonization Task Force (GHTF), has released a new document for consultation regarding the definition of standalone software used for medical purposes.

The document, Standalone Medical Device Software: Key Definitions, was released on 1 July 2013 and is being coordinated by the FDA.

As the document explains, “Software for medical purposes is becoming increasingly important and … can appear in many forms and on many computing platforms.” For example, some software is embedded into a type of medical device, while others are sold as stand-alone software meant to work on a variety of devices (e.g. mobile devices) or settings (e.g. cloud-based computing or local networks).

A major issue with respect to regulators is the fast pace at which the technology is progressing. Accordingly, this leads to problems in understanding what is required and what is expected (note: what is required is not necessarily what is expected and what is expected is not necessarily what is required).

The document provides a detailed analysis and definition of standalone medical device software (SMDS). According to the IMDRF, medical device software – which is defined as a medical device — “may include but are not limited to” the following characteristics:

·       capable of running on general purpose (non-medical purpose) computing platforms

·       not necessary for a hardware medical device to achieve its intended medical purpose

·       may be used in combination (e.g., as a module) with other devices

·       may be interfaced with other medical devices, including hardware medical devices and other standalone medical devices software

Software that meets the definition of SMDS and is part of another software, regardless if the other software has a medical purpose or not, is still considered as a SMDS.

The document is found at http://www.imdrf.org/docs/imdrf/final/consultations/imdrf-cons-sskd-130701.pdf.

If there are any questions, please contact us.

 

Tell your friends and colleagues about us. Thanks!
Share this

Risk assessment for your medical device

We specialize in  cyber-security and privacy compliance for medical device vendors in Israel like you.

We’ve assissted dozens of Israeli software medical device that use Web, mobile, cloud and hospital IT networks achieve cost-effective HIPAA compliance and meet FDA guidance on Premarket Submissions for Management of Cybersecurity in Medical Devices.

As part of our service to our trusted clients, we provide the popular PTA  threat modeling tool, free of charge – with 12 months maintenance included and unlimited threat models.

If you’re not a client  – contact us now for a free phone consultation.

Software Associates threat models are used by thousands of professional security analysts all over the world who use PTA Professional in their risk and compliance practice.

Download the  free risk assessment software now.

What you get with the PTA Software:

  • It’s quantitative: enables business decision makers to state asset values, risk profile and controls in familiar monetary values. This takes security decisions out of the realm of qualitative risk discussion and into the realm of business justification.
  • It’s robust: enables analysts to preserve data integrity of complex multi-dimensional risk models versus Excel spreadsheets that tend to be unwieldy, unstable and difficult to maintain.
  • It’s versatile: enables organizations to reuse existing threat libraries in new business situations and perform continuous risk assessment and what-if analysis on control scenarios without jeopardizing the integrity of the data.
  • It’s effective: helps determine the most effective security countermeasures and their order of implementation, saving you money.
  • It’s databased: based on a robust threat data model with the 4 dimensions of threats, assets, vulnerabilities and countermeasures
  • It’s management level: with a few clicks, you can product VaR reports and be a peer in the boardroom instead of staffer waiting in the hall.

 

Tell your friends and colleagues about us. Thanks!
Share this

Why Microsoft Windows is a bad idea for medical devices

I’m getting some push back on LinkedIn on my articles on banning Microsoft Windows from medical devices that are installed in hospitals – read more about why Windows is a bad idea for medical devices here and here.

Scott Caldwell tells us that the FDA doesn’t rule “out” or “in” any particular technology, including Windows Embedded.

Having said that, Microsoft has very clear language in their EULA regarding the use of Windows Embedded products:

“The Products are not fault-tolerant and are not designed, manufactured or intended for any use requiring fail-safe performance in which the failure of a Product could lead to death, serious personal injury, severe physical or environmental damage (“High Risk Activities”).”

Medical device vendors  that  use Windows operating systems for less critical devices, or for the user interface are actually increasing the threat surface for a hospital, since any Windows host can be a carrier of malware that can take down the entire hospital network, regardless of it’s primary mission function, be it user-friend UI at a nursing station or intensive care monitor at the bedside.

Medical device vendors that use Microsoft IT systems management “best-practices” often  take the approach of “bolting-on” third party solutions for anti-virus and software distribution instead of developing robust, secure software, “from the ground up” with a secure design, threat analysis, software security assessment and secure software implementation.

Installing third-party security solutions that need to be updated in the field, may be inapplicable to an embedded medical device as the MDA (Medical Device Amendments of 1976) clearly states:

These devices may enter the market only if the FDA reviews their design, labeling, and manufacturing specifications and determines that those specifications provide a reasonable assurance of safety and effectiveness. Manufacturers may not make changes to such devices that would affect safety or effectiveness unless they first seek and obtain permission from the FDA.

It’s common knowledge that medical device technicians use USB flash drives and notebook computers to update medical devices in the hospital. Given that USB devices and Windows computers are notoriously vulnerable to viruses and malware, there is a reasonable threat that a field update may infect the Windows-based medical device. If the medical device is isolated from the rest of hospital network, then the damage is  localized, but if the medical device is networked to an entire segment, then all other Windows based computers on that segment may be infected as well – propagating to the rest of the hospital in a cascade attack.

It’s better to get the software security right than to try and bolt in security after the implementation.Imagine that you had to buy the brakes for a new car and install them yourself after you got that bright new Lexus.

It is not unusual for medical device vendors to fall victim to the same Microsoft marketing messages used with enterprise IT customers – “lower development costs, and faster time to market” when in fact, Windows is so complex and vulnerable that the smallest issue may take a vendor months to solve. For example – try and get Windows XP to load the wireless driver without the shell.   Things that may take months to research and resolve in Windows are often easily solved in Linux with some expertise and a few days work. That’s why you have professional medical device  software security specialists like Software Associates.

With Windows, you get an application up and running quickly, but it is never as reliable and secure as you need.

With Linux, you need expertise to get up and running, and once it works, it will be as reliable and secure as you want.

Yves Rutschle says that outlawing Microsoft Windows from medical devices in hospitatls  sounds too vendor-dependant to be healthy (sic) (Seems to me that this would make the medical device industry LESS vendor-dependent, not more vendor-dependent, considering the number of embedded Linux options out there.)

Yves suggests that instead, the FDA should create a “proper medical device certification cycle. If you lack of inspiration, ask the FAA how they do it, and maybe make the manufacturers financially responsible for any software failure impact, including death of a patient“. (The FDA does not certify medical devices, they grant pre-market approval).

I like a free market approach but consider this:

(Held)The MDA’s pre-emption clause bars common-law claims challenging the safety or effectiveness of a medical device marketed in a form that received premarket approval from the FDA. Pp. 8–17.

Maybe the FDA should learn from the FAA but in the meantime, it seems to me if the FDA pre-market validation process had an item requiring a suitable operating system EULA, that would pretty much solve the problem.

Tell your friends and colleagues about us. Thanks!
Share this

Why outlawing Windows from embedded medical devices is a good idea

In a previous post The Microsoft Monoculture as a threat to national security, I suggested that the FDA might consider banning Windows as an operating system platform for medical devices and their accompanying information management systems.

One of my readers took umbrage at the notion of legislating one monoculture (Microsoft) with another (Linux) and how the Linux geeks are hooked on the CLI just like Windows users are hooked on a GUI.

The combination of large numbers of software vulnerabilities,  user lock in created by integrating applications with Windows,  complexity of Microsoft products and their code and Microsoft predatory trade practices are diametrically different than Linux and the FOSS movement.

One of the biggest threats to medical devices in hospitals is the widespread use of USB flash disk drives and Windows notebooks to update medical device software. With the infamous auto-run feature on Microsoft USB drives – flash memory is an easy attack vector for propagating malware via Windows based medical devices into a hospital network. This is one (and not the only) reason, why I am campaigning against use of Windows in medical devices.

This  has nothing to do with the CLI or GUI of the operating system and personal preferences for a user interface.

This has everything to do with manufacturing secure embedded medical devices that must survive in most demanding, heterogeneous and mission critical environment one can imagine – a modern hospital.

I never advocated mandating Linux by law for medical devices.

It might be possible to mandate a complex set of software security requirements instead of outlawing Windows in embedded medical devices as a more politically-correct but far more costly alternative for the the FDA and the US taxpayer.

Regardless of the politics involved (and they are huge…) – if the FDA were to remove Windows from an approved list of embedded medical device operating systems – the costs to the FDA would decrease since the FDA would need less Windows expertise for audits and the threat surface they would have to cover for critical events would be smaller.

Tell your friends and colleagues about us. Thanks!
Share this