Category Archives: medical device security

Bridging the security IT gap with BI

Encryption and medical device cyber security

I have written pieces here, here, here and here on why encryption should be a required security countermeasure for network medical devices – but curiously, the HIPAA Security rule – Appendix A does not specifically require encryption.

The final FDA guidance on cyber security for medical devices takes a similar position that we’ve adopted over the years – namely analyzing threats (“Hazards”) and implementing a prioritized security countermeasure plan.

In our security and privacy compliance practice for biomed in Israel – we always take a position that the first step in determining the best and most cost-effective security countermeasures for your medical device is to develop a threat model and perform a threat analysis.  Encryption may or may not be the first security countermeasure you must implement in your mobile medical device (think about fixing interface bugs first…) but it will probably be in your top 5

Regardless of why the authors of the HIPAA security rule did not require encryption – it is instructive to take a look at the history of encryption and how we arrived at where we are today – where encryption is widely considered to the silver bullet of security.

History of EncryptionLearn about key cryptology events throughout
the ages with the Egress History of Encryption infographic. Egress
Software Technologies are providers of email encryption software and file encryption & large file transfers.

Tell your friends and colleagues about us. Thanks!
Share this
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
dilbert Data Security

3 things a medical device vendor must do for security incident response

You are VP R&D or CEO or regulatory and compliance officer at a medical device company.

Your medical devices measure something (blood sugar, urine analysis, facial anomalies, you name it…). The medical device interfaces to a mobile app that provides a User Interface and transfers patient data to a cloud application using RESTful services over HTTPS.

Sound familiar?

The Medical device-Mobile app-Cloud storage triad is a common architecture today for many diagnostic, personal well-being and remote patient monitoring indications.

We have numerous clients with the Medical device-Mobile app-Cloud storage system architecture and we help them address 4 key security issue –

  1. How to ensure that personal data and user authentication data is not stolen from the mobile medical app,
  2. How to ensure that the mobile medical app is not used as an attack pivot to attack other medical device users and cloud servers,
  3. How to comply with the HIPAA Security Rule and ensure that health data transferred to the cloud is not breached by attackers who are more than interested in trafficking in your users’ personal health data,
  4. How to execute effective security incident response and remediation – its a HIPAA standard but above all – a basic tenet for information security management.

How effective is your security incident response?

The recent SANS Survey on Security Incident Response covers the challenges faced by incident response teams today—the types of attacks they detect, what security countermeasures they’ve deployed, and their perceived effectiveness and obstacles to incident handling.

Perceived effectiveness is a good way of putting it – because the SANS Survey on Security Incident Response report has some weaknesses.

First – the survey that is dominated by large companies: over 50% of the respondents work for companies with more than 5,000 employees and fully 26% work for companies with more than 20,000 employees.    Small companies with less than 100 employees – which cover almost all medical device companies are underrepresented in the data.

Second – the SANS survey attempts, unsuccessfully, to reconcile reports by the companies they interviewed that they respond and remediate  incidents within 24 hours(!) with reports by the PCI (Payment Card Industry) DSS (Data security standard) Association that retail merchants take over 6 months to respond.       This gap is difficult to understand – although it suggests considerable variance in the way companies define incident response and perhaps a good deal of wishful thinking, back-patting and CYA.

Since most medical device companies have less than 100 employees – it is unclear if the SANS findings (which are skewed to large IT security and compliance organizations) are in fact relevant at all to a medical device industry that is moving rapidly to the medical device-App-Cloud paradigm.

3 things a medical device vendor must have for effective incident response

  1. Establish an IRT.  (Contact us and we will be happy to help you set up an IRT and train them on effective procedure and tools).  Make sure that the IRT trains and conducts simulations every 3-6 months and above all make sure that someone is home to answer the call when it comes.
  2. Lead from the front. Ensure that the head of IRT reports to the CEO.   In security incident response, management needs to up front and not lead from behind.
  3. Detect in real time. Our key concern is cloud server security.    Our recommendation is to install OSSEC on your cloud servers. OSSEC sends alerts to a central server where analysis and notification can occur even if the medical device cloud server goes down or is compromised.
Tell your friends and colleagues about us. Thanks!
Share this
Security is not fortune telling

Back to basics with HIPAA – 3 things you must do.

Before you start spending money on regulatory consultants get back to basics.  Do you or do you not need to comply with the HIPAA Security Rule?  If you do – what is the very first thing you should do?   In this post – we will get back to basics with 3 practical ways of complying and reducing your regulatory risk.

I specialize in cyber security and privacy compliance consulting for medical device companies in Israel.  While this may sound like a niche, it is actually a very nice and not so small niche – with over 700 biomed vendors and a market growing 7-8% / year.

Israeli biomed startups are incredibly innovative and it’s fun working with smart people.  Here are 3 ways to improve your HIPAA risk analysis in just a few minutes:

Check # 1 – Maybe you are not a HIPAA Business associate

If you are a medical device vendor and you connect to a hospital network or share data  with doctors, you are automatically a BA; a Business associate according to the HIPAA Business Associate definition.   If you are a BA – you need to comply with the HIPAA Security Rule. But maybe you are not a BA.

By law, the HIPAA Privacy Rule applies only to covered entities – health plans, health care clearinghouses, and certain health care providers. A “business associate” is a person or entity that performs certain functions or activities that involve the use or disclosure of protected health information on behalf of, or provides services to, a covered entity.  If an entity  does not meet the definition of a covered entity or business associate, it does not have to comply with the HIPAA Rules.  See definitions of “business associate” and “covered entity” at 45 CFR 160.103.

So – if you developed a consumer mobile app that monitors stress  with a cool dashboard to visualize data stored in the cloud enabling your users to reduce their stress and compare themselves with other people like them; so long as the software doesn’t share data with a covered entity (like their doctor) – you are not a BA. Check.

 Check # 2 – Maybe you don’t even need to comply with HIPAA

HIPAA applies to storage of EPHI (electronic protected health information).   Simply put – EPHI is the combination of PII (personally identifiable information – such as a name, email and social security number) and healthcare / clinical data.

So – getting back to our hypothetical mobile medical app for personal stress tracking, let’s suppose that the stress data includes heart rate and respiratory rate in addition to how many times/day the consumer called their girl friend to make sure she still loves them  (when they are freaking out with stress before a big exam). If your mobile medical app for stress management doesn’t store personal information with the clinical data, then you don’t have to comply with HIPAA because you don’t you don’t create, store or transmit EPHI in the cloud. Check.

Check # 3 – Using contractors for software development? Vet them and oversee them

There is commonly-used expression in Hebrew – “launch and forget” (שגר ושכח).  I believe that this is a Hebrew translation of the American English term “Fire and forget” that refers to a type of missile guidance which does not require further guidance after launch.

When it comes to contractors you do not want to “launch and forget”.

Maybe you are a BA and you have to comply with HIPAA – just because the HIPAA Security Rule does not have a standard safeguard for vetting contractors, can you afford to gloss over this area?

This is a big one boys and girls.   If you use contractors for code development, make sure you thoroughly vet them before engaging with them on upwork.  I am not talking about quality of work – it is a given that you need someone highly competent in whatever problem problem domain you are trying to crack (your girl-friends brother-in-law may not be your best fit).  I am talking about the threat of a contractor stealing your code, dropping Android malware into your app, or enabling tap-jacking to steal personal data).

Even if they don’t steal your code, consider the threat of your contractor working for a competitor, leaking your IP or being hired by a business partner who click-jacks your entire business model.

It’s tempting to work with software developers in Ukraine or China but be careful. Consider the case of Russian programmers who wrote code for U.S. military communications systems or the  DOJ accuses firm that vetted Snowden of faking 665,000 background checks. 

In the Federal space, it is sad but true that there is huge a Federal procurement machine that enables these kinds of attacks to happen because of organizational complexity ( a nice way of saying that accountability falls between the cracks) and greed  ( a not so nice way of saying that big contracts are a challenge to morality and governance).

US Federal agency purchasing managers who sign purchase orders without appropriate contractor vetting and oversight are not a justification for a privately-held Israeli medical device company to sin…

The calls for more legislation are a knee-jerk reaction to the horses having left the barn years ago but when common sense and good business practices yield to greed then perhaps we do need a tail wind. Vetting software development contractors should be a standard requirement in the core security guidance such as HIPAA, PCI and FDA cyber security but in the meantime – don’t wait for the US Federal Government to tell you to vet your contractors and oversee their work. Put an accountability clause into your contracts.

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

The importance of risk analysis for HIPAA compliance

A chain of risk analysis

The HIPAA Final Rule creates a chain of risk analysis and compliance from the hospital, downstream to the business associates who handle / process PHI for the hospital and sub-contractors who handle / process PHI for the business associate.

And so on.

The first thing an organization needs to do is a risk analysis.   How important is a risk analysis?  Ask Cancer Care Group who were just fined $750,000 for non-compliance with the Security Rule.

$750,000 HIPAA settlement emphasizes the importance of risk analysis and device and media control policies

Cancer Care Group, P.C. agreed to settle potential violations of the Health Insurance Portability and Accountability Act of 1996 (HIPAA) Privacy and Security Rules with the U.S. Department of Health and Human Services (HHS), Office for Civil Rights (OCR). Cancer Care paid $750,000 and will adopt a robust corrective action plan to correct deficiencies in its HIPAA compliance program. Cancer Care Group is a radiation oncology private physician practice, with 13 radiation oncologists serving hospitals and clinics throughout Indiana.

On August 29, 2012, OCR received notification from Cancer Care regarding a breach of unsecured electronic protected health information (ePHI) after a laptop bag was stolen from an employee’s car. The bag contained the employee’s computer and unencrypted backup media, which contained the names, addresses, dates of birth, Social Security numbers, insurance information and clinical information of approximately 55,000 current and former Cancer Care patients.

OCR’s subsequent investigation found that, prior to the breach, Cancer Care was in widespread non-compliance with the HIPAA Security Rule. It had not conducted an enterprise-wide risk analysis when the breach occurred in July 2012. Further, Cancer Care did not have in place a written policy specific to the removal of hardware and electronic media containing ePHI into and out of its facilities, even though this was common practice within the organization. For more information see the HHS Press Release from Sep 2, 2015 $750,000 HIPAA settlement emphasizes the importance of risk analysis and device and media control policies

Risk analysis is the first step in meeting Security Rule requirements

I have written here, here, here and here about the importance of risk analysis as a process of understanding the value of your assets, the impact of your threats and the depth of your vulnerabilities in order to implement the best security countermeasures.

The HIPAA Security Rule begins with the analysis requirement in § 164.308(a)(1)(ii)(A). Conducting a risk analysis is the first step in identifying and implementing safeguards that comply with and carry out the standards and implementation specifications in the Security Rule. Therefore, a risk analysis is fundamental to the entire process of HIPAA Security Rule compliance, and must be understood in detail by the organization in order to specifically address safeguards and technologies that will best protect electronic health information. See Guidance on Risk Analysis Requirements under the HIPAA Security Rule. Neither the HHS Guidance nor NIST specify a methodology – we have been using the Practical Threat Analysis methodology for HIPAA Security risk analysis with Israeli medical device companies since 2009 and it works smoothly and effectively helping Israeli medical device vendors comply and implement robust security at the lowest possible cost.

§ 164.308(a)(1)(ii)(A) Risk Analysis (R1): As part of the risk management process, the company performs information security risk analysis for its services (see company procedure XYZ) analyzing software application  security, data security and human related vulnerabilities. Risk analysis is performed according to the Practical Threat Analysis methodology.

1 A refers to addressable safeguards, and R refers to required safeguards.

Do it.  Run Security like you Run your business

Tell your friends and colleagues about us. Thanks!
Share this
skin mounted medical devices

On Shoshin and Software Security

I am an independent software security consultant specializing in medical device security and HIPAA compliance in Israel.   I use the state-of-the art PTA – Practical Threat Analysis tool to perform quantitative threat analysis and produce  a bespoke, cost-effective security portfolio for my customers that fits their medical device technology.

There are over 700 medical device companies in Israel – all doing totally cool and innovative things from My Dario (diabetes management), to Syneron (medical esthetics),  to FDNA (facial dysmorphology  novel analysis at your fingertips) to Intendu (Brain Rehabilitation).

This is a great niche for me because I get to do totally cool projects and  work with a lot of really smart people at Israeli medical device vendors helping them implement cost-effective  security and privacy compliance + it’s fun learning all the time.

One thing I have learned is that there is very little connection between FDA medical device risk assessments and a software security risk assessments.   This somewhat counter-intuitive for people who come from the QA and RA (regulatory assurance) areas.

Security is an adversarial environment very unlike FDA regulatory oversight.

FDA medical device regulatory oversight is about complying in a reliable way with standard operating procedures and software standards.

FDA believes that conformance with guidance documents, when combined with the general controls of the Act, will provide reasonable assurance of safety and effectiveness…

FDA recognizes several software consensus standards. A declaration of conformity to these standards, in part or whole, may be used to show the manufacturer has verified and validated pertinent specifications of the design controls. The consensus standards are:

  • ISO/IEC 12207:1995 Information Technology – Software Life Cycle Processes
  • IEEE/EIA 12207.O-1996 Industry Implementation of International Standard ISO/IEC12207:1995 (ISO/IEC 12207) Standard for Information Technology – Software Life Cycle Processes

Barry Boehm succinctly expressed the difference between Verification and validation:

Verification: Are we building the product right?

Validation: Are we building the right product?

Building the right product right is no more a guarantee of security than Apple guaranteeing you that your Mac Book  Pro  will not be stolen off an airport scanner.

Medical device security is about attackers and totally unpredictable behavior

Medical device security is about anticipating  the weakest link in a system that can be exploited by an attacker who will do totally unpredictable things that were inconceivable last year by other hackers, let alone 20 years ago by an ISO standards body.

You cannot manage unpredictable behavior (think about a 2 year old) although you can develop the means for anticipating threats and responding quickly and in a focused way even when sleep-deprived and caffeine-enriched.

The dark side of security is often hubris and FUD.

For security consultants, there is often an overwhelming temptation to show clients how dangerous their security vulnerabilities are and use that as a lever to sell products and services.   I’ve talked about hubris and FUD here and here and here and here and here.   A good example of exploiting clients with security FUD are the specialty HIPAA-compliant hosting providers like Firehost that are masters of providing expensive services to clients that may or may not really need them.

However, I believe that intimidation is not necessarily a strategy guaranteed to win valuable long-term business with clients.

Instead of saying – “that is a really bad idea, and you will get hacked and destroy your reputation before your QA and RA departments get back from lunch“,  it is better to take a more nuanced approach like:

I see that you are transferring credentials in plain-text to your server in the cloud.   What do you think about the implications of that?“.   Getting a client to think like an attacker is better than dazzling and intimidating them which may result in  the client doing nothing, hunkering down into his current systems or if the client has money – going off and spending it badly.

How did I reach this amazing (slow drum roll…) insight?

About 3 years ago I read a book called Search Inside Yourself and I learned an idea called – “Don’t take action, let action take you“.    I try to apply this approach with clients as a way of helping them learn themselves and as a way of avoiding unnecessary conflict.  The next step in my personal evolution was getting acquainted with a Zen Buddhist concept  called Shoshin:

Shoshin (初心) means “beginner’s mind”. It refers to having an attitude of openness, eagerness, and lack of preconceptions when studying a subject, even when studying at an advanced level, just as a beginner in that subject would.

Shoshin means doing the exact OPPOSITE of what you (the high-powered, all-knowing, medical device security consultant) would normally do in the course of a security threat assessment:

  1. Let go of the need to add value – you do not have to provide novel security countermeasures all the time. Sometimes, doing the basics very well (like hashing and salting passwords) is all the value the client needs.
  2. Let go of the need to win every argument – you do not have to show the client why their RA (regulatory assurance) manager is making fatal mistakes in database encryption after she took some bad advice from Dr. Google.
  3. Ask the client to tell you more – ask what led them to a particular design decision.  You may learn something about their system design alternatives and engineering constraints. This will help you design some neat security countermeasures for their medical device and save them some money.
  4. Assume you are an idiot –  this is a corollary of not taking action.   By assuming you are an idiot, you disable your ego for a few moments and you get into a position of accepting new information  which in the end, may help you anticipate some threats and ultimately take your client out of potentially dangerous adversarial threat scenario.

Thank you to James Clear for his insightful post – Shoshin: This Zen Concept Will Help You Stop Being a Slave to Old Behaviors and Beliefs

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

Why anti-virus doesn’t work for medical devices

Are you checking off medical device security in your hospital with anti-virus:  falling for security theater; feeling secure and enjoying the show,  but in fact being less secure?

A medical device is not an office PC

The most commong security countermeasure in use today is anti-virus software for Windows-based workstations  to protect the Windows PC from malicious software from removable devices, email, and Web channels. ( I will refrain from religious debate on Mac vs. Windows vs. Linux).

However – the traditional consumer/IT enterprise anti-virus is  not an effective security countermeasure for medical devices in a hospital.

The majority of medical devices on a hospital network don’t have network connectivity.

Without network connectivity, ongoing update of AV software and signatures is impractical for the medical device vendor since it require regression testing and update of  units in the field.

Without network connectivity, the devices cannot be managed by a central system like McAfee ePO and in a best case  run outdated engine and AV signatures. In these cases the anti-virus is worthless, and the result is security theater: feeling secure and enjoying the show,  but in fact being less secure. Without central endpoint  or network monitoring we do not even know if the medical device was infected.

What do hospitals and medical device vendors do?

It depends.

Some hospitals are sticky about a particular AV package and as a result big device vendors like GE have gone to the trouble to validate all major AV vendors on their networked devices. 

Other hospitals take a more calculated and risk-driven approach with their medical device vendors and evaluate the threats and vulnerabilities.

A risk-driven approach, based on achieving cost-effective medical device security is precisely what the FDA requires in it’s latest draft guidance for medical device cyber security

However, the business case for a customized security countermeasure portfolio for each medical device vendor is weak to say the least and it is a fair assumption that both medical device vendors and hospital security and compliance groups  prefer a vendor-neutral standards-based solution for preventing malicious software that attacks the medical device on their hospital network.

While an anti-virus is standard, it is not vendor-neutral and even when installed it is probably worthless since the medical device doesn’t have network connectivity.

In broad terms – there are 2 key use cases for medical device security:

Embedded medical devices such as bedside monitors

An embedded medical device vendor may select Linux (for example Debian or Ubuntu) as the target operating system and by deactivating USB access and controlling the code carefully – may create a secure medical device which is extremely hardened to Windows-based  malicious software. In this case – medical device security doesn’t require an anti-virus.

System level medical devices such as MRI that run Windows

These are many larger Windows-based medical devices that integrate a large software application with special hardware and integrated  interfaces to other systems on the hospital network (such as PACS) – examples are MRI.

A medical device that runs Windows will definitely need to deal with threats of malicious software attacking the medical device via USB and launching an attack on the hospital network – attacking patient privacy and availability of resources such as PACS servers.  

Manual anti-virus updates are a threat to medical devices

Since the device doesn’t have Internet or enterprise hospital network access, IT administration will need to manually update the devices’ anti-virus engine and signature file using removable media – which creates an additional vulnerability of a infected Flash disk devices infecting the device and propagating malicious software back into the hospital network. So – manual updates are a bad idea.

Summary

Effective protection against malicious software in medical devices should work without requiring centralized network connectivity (unrealistic for the hospital) and installation of anti-virus agents (unrealistic for the medical device).

If you are developing an embedded device – you are better off with Linux.  

If you unfortunately are stuck with a Windows-based system – you will need to find a non anti-virus solution whether application white listing or future solutions such as WattsUpDoc.

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