Blog

This is a continuation of a previous post on Basic Cybersecurity Hygiene.   These are common, simple mistakes that many device developers still make today.

As a reminder, the tips from Part I are:

  • Do NOT use hard-coded user credentials
  • Sanitize any inputs from outside your software (e.g. check your XML processing libraries for vulnerabilities!)

Let's continue!

Don't roll your own crypto

Never, ever, create your own cryptographic scheme or implementation.   Always use established cryptography libraries for password protection, authentication, encryption, etc.  

Need to encrypt data sent over a network?  Need to encrypt it on disk?   Need an authentication scheme to be sure users are who they say they are?    Don't try to make your own!  Cryptography is extremely difficult to design and implement correctly.  There are established methods and off-the-shelf libraries available for any conceivable cryptographic task.

There is a well-known saying in the cryptography community:

Anyone can create a crypto-system that they themselves cannot break.

Limit your networking attack surface

Determine all network services running on your device, and disable any that are not explicitly necessary.   Got a SSH server on your device for development?   Remember to turn it off before you release for production!

You can run a port scan on your device to determine what TCP and UDP ports it has open.  You should understand and approve of any open ports on your device. See https://nmap.org/book/man-port-scanning-techniques... for more detailed information on using the popular open-source tool “nmap” to perform port scans.

Monitor software components for known vulnerabilities

It is often the case that devices are vulnerable because they include software libraries that have publicly known (and patched) vulnerabilities.   The vulnerability has been published, which means that hackers know about it.  A fix for the software is available, which means that if the device has the fix, it isn’t vulnerable.  However, the device developers aren’t aware that there is a vulnerability, so the vulnerability goes unfixed, and now hackers have a roadmap to compromise the device.

For example, the National Vulnerability Database lists this critical flaw in OpenSSL 1.1.0a that can allow a hacker to completely take over a device.  Do you have the OpenSSL library on your device?  Which version?  Are you sure?

The answer is that you must create a "Software Bill-of-Materials (BOM)" for your device.  This is a list of all software packages, and their versions, that are installed on the device.    Then, you should monitor the National Vulnerability Database for vulnerabilities that affect any item on your Software BOM.  

Does your organization have a Coordinated Vulnerability Disclosure Process as advised by the FDA's Postmarket Cybersecurity Guidance? 

MedISAO can take care of that for you!   We recently launched a Coordinated Vulnerability Disclosure (CVD) program that can get you started, or augment your already established process.        

What does it mean to be a part of this program?

MedISAO will act as a Coordinator for your Organization as defined in ISO/IEC 29147. It will host a form here where security researchers can submit vulnerability reports, and will forward those reports to your organization. On your organization's website and in documentation, you should direct users to this form as one of the accepted ways of submitting vulnerability information. Once the vulnerability has been verified and resolved or rejected by your organization, MedISAO will inform the reporter of actions taken, and disseminate advisories about the fix through its standard advisory process.

How can I sign up? 

Email  members@medisao.com with your MedISAO username to start the process. 

Are there any costs associated with this program? 

The Coordinated Vulnerability Disclosure program is free for all organizational members.        

Does this mean I don't need to set up a Vulnerability Handling Program at my organization? 

You still need to set up an internal vulnerability handling program at your organization that will handle vulnerability verification and response. For reference see  ISO/IEC 30111:2013 or  MedISAO's guide for how to set up a policy at your organization. If you need more help you can email us at  members@medisao.com any time. 

My organization already has an established Coordinated Vulnerability Disclosure Process. Should I still join MedISAO's program? 

Yes! In addition to your already established process, MedISAO can serve as an additional avenue for receiving vulnerability information.

Daniel Beard
Jun 22, 2017

Let's take a moment to get back to the basics of cybersecurity in medical product design. The goal is to prepare a solid list of things to be on the lookout for when doing a cybsecurity risk analysis.

Don't use hard-coded credentials

Hard-coded usernames and passwords are still one of the most pervasive trends in medical device design. It's not hard to see why they are so tempting. They are easy to implement and easy to keep track of. The problem is that they are hard to keep secret. All it takes is one leak and your entire product line is instantly insecure. Passwords need to be device-specific and easily changed in case something happens.

Sanitize your inputs

There was a time when it could be assumed that all input came from a trusted, knowledgable and non-malicious sources (e.g. a doctor or nurse). With the rise of connected medical devices, this is no longer the case. Any input from the network could be malicious and must be sanitized. Even rarely-looked-at standards need to be carefully examined.  For example, does your medical device accept HL7 v3 XML as part of LIMS communication? There are numerous XML vulnerabilities related to arbitrary XML document parsing that can cause your device to crash, potentially leak PHI, or be used to attack a hospital network. All of these attacks leverage standards compliant XML and can be used to abuse systems that don't authenticate before parsing. Many can be prevented by just disabling uneeded XML parser features.  All external input, no matter how trivial, even if it's "just XML", should be sanitized and evaluated for potential risk. 

Update: See Part 2 of this series...

In an uncharacteristically quick move, the FDA released this official guidance less than a year after the draft was released for comments. This guidance for medical device manufacturers "recognizes today’s reality – cybersecurity threats are real, ever-present,  and continuously changing."

For more information on the FDA Postmarket Cybersecurity Guidance, see the below post from Dr. Suzanne B. Schwartz

http://blogs.fda.gov/fdavoice/index.php/2016/12/managing-medical-device-cybersecurity-in-the-postmarket-at-the-crossroads-of-cyber-safety-and-advancing-technology/

Click here for more information

The Medical Device Security 101 Conference, hosted by the University of Michigan’s Archimedes Center for Medical Device Security, is a 2-day educational workshop taking place in Lake Buena Vista, Florida from January 15-17, 2017 for medical device manufacturers, industry regulators, and healthcare providers to learn and speak frankly about medical device security threats and solutions.

This conference is a great way to learn about state of the art cybersecurity programs, and get hands on advice from industry experts on setting up your own.

The Hippocratic Oath for Connected Medical Devices, by IamTheCavalry, is a must-read for anyone involved with connected medical device design.

The Hippocratic Oath is a symbolic attestation by physicians to provide care in the best interest of patients. Medical devices are key instruments of delivering this care. It stands to reason that the design, development, production, deployment, use, and maintenance of medical devices should also follow this symbolic spirit. Our Hippocratic Oath for Connected Medical Devices describes commitments to capabilities that preserve patient safety, as well as trust in the process of care delivery itself.

Click here to read the full oath.

(Image by Isarra via Wikimedia Commons)

Embedded Linux is all around us. It’s in our routers, our IoT devices, and our medical devices. Recent events , however, have shown that the Internet of Things gives us just as many new vulnerabilities as new opportunities.  

Embedded “IoT” devices are a more serious security risk than typical consumer computers because of their slow update cycles. Some don’t allow remote upgrade. This means that if a vulnerability is found, there is no cost effective way for the manufacturer to update the device with a patch. Even if the manufacturer can remotely update it, they may not be keeping up to date with the latest security vulnerabilities or updates.

Regulatory agencies are taking notice. The FDA’s premarket and postmarket guidances make it very clear that they are concerned with medical device cyber security. It’s up to medical device manufacturers to be on top of the problem through joining ISAOs, setting up coordinated disclosure programs, and issuing security updates.

In this post, we’re going to show how to run automated checking of 3rd party packages for known vulnerabilities via the National Vulnerability Database (NVD) and how to integrate that into your Continuous Integration System (CI). This is just one part of monitoring your device’s security effectively.  However, this process is easy to do. If you’re building an embedded device, there is no excuse for not having something like this in place.

Tools Needed:

  • Continuous Integration Framework:  We use Jenkins for projects at Promenade Software, but any CI will do.
  • Build and Version Management Framework:  Examples include Yocto, rpm or a SWID generator. We use Yocto for our embedded linux devices. Your package manager or SWID tool should be able to generate a list of all installed packages and their dependencies. (You do know every package and its version number that’s installed on your device, including dependencies … right?)
  • Vulnerability Analysis Tool:  We built a tool called CVE Checker that compares your list of packages and versions to the list of Common Vulnerabilities and Exposures (CVEs) in the National Vulnerability Database. We’re releasing it under the GPL license so that everyone can benefit. You can clone it here.
    (Side Note: If you’re building a web application check out the OWASP Dependency-Check Jenkins plugin)

The following steps should be performed by the CI after every build of the system, preferably right after your unit tests.

Step 1) Get the list of packages (including all dependencies) on your device

  • Using yocto: See the manual for enabling build history. The package list is in a file called installed-packages.txt
  • Using rpm:  you can get the list by running `rpm -qa`
  • Other: You need to generate a list of  ISO/IEC 19770-2:2009 compatible SWID tags. Choose a tool that matches your operating system and workflow best.

Step 2) Run the CVE checker on that list

  • Clone the checker from github.
  • Run download_xml.sh to download the latest NVD from NIST.  Do this the first time and then at regular intervals to keep up to date.
  • Run cli.py on the package version list.  If you need help formatting the command you can view the help with the “-h” flag.  
    example: ~/tools/LibScanner/cli.py --format yocto -i "ignored_cves.txt" "installed-packages.txt" ~/tools/LibScanner/dbs/ > cve_test.xml
Example test result showing CVEs as failed tests in included packages in a demo device

The output from this step is a JUnit-style XML document. Run the output from the tool through the same reporting mechanism used by the unit tests.  Address any failures through updates, patches, or other mitigations as necessary.  If a CVE has been sufficiently mitigated through alternative means, and it is still causing the tests to fail, you can add it to the ignore list using the -i option.

The ignore list is a simple text file with a comma delimited list of CVEs to ignore and why. (e.g. mitigating control taken or false positive) All tests that are in the ignored lists will show up as “skipped” in the report.

Example :

CVE-2016-9318 , Device shall not allow arbitrary xml parsing under any circumstance
CVE-2016-6354 , False Positive - Flex not actually on device

Have your CI run this build every time someone checks in a change and at a regular interval (e.g. once a month) after the device is in production.  That way, you’ll be alerted by a failing unit test if there are any new vulnerabilities added to the NVD in the future.  Every failure needs a mitigating control, regardless of how small.

This automated process will help you keep up to date on new vulnerabilities that impact your devices and respond faster and more effectively.

Frances Cohen
Nov 25, 2016

Discuss the latest news in medical device cyber security with like-minded individuals. Frances Cohen, CEO of Promenade Software, will be giving a talk on monitoring vulnerabilities post-market and how to leverage MedISAO's tools and resources to meet the FDA's cybersecurity guidelines.

Time: 

Tuesday, January 17th
5:00PM - 8:00PM PST

Location:

16 Technology Drive
STE #100
Irvine, CA 92618

Learn about medical device cybersecurity

Subscribe to our email list for lessons, guides, and news.

We won't send you spam. Unsubscribe at any time.