Proprietary

15 October 2015

MEDICAL DEVICE DESIGN: DO YOU WANT TO FOCUS ON INTEGRATION OR INNOVATION?

Malte Mundt, Field Application EngineerQNX Software Systems

Proprietary2

DO YOU WANT TO FOCUS ON INTEGRATION OR INNOVATION?• Medical Devices trends

– Medical device cybersecurity– Challenges for healthcare organizations– Adoption of wireless connectivity

• Do-it-Yourself Design vs Partnering• What’s involved with building a medical device today?

Proprietary3

CYBERSECURITY VULNERABILITIES

Report issued June 2015• Highlights current

vulnerabilities and risks in medical devices

Proprietary4

MEDJACK: HIGH VALUE, LOW BARRIERS TO INTRUSIONMEDJACK: medical device hijack• Medical devices are the key pivotal points of attack in a hospital network• Visible points of vulnerability• Hardest endpoints to remediate, even when malware is detected

Healthcare network:• Replete with internet-connected systems and medical devices• All inter-connected to Electronic Medical Records (EMR) systems

• A highly connected community that brings the most vulnerable devices together with some of the highest value data

• Example: 2014 breach of Community Health Services (USA) network:– 4.5 million names, addresses, birth dates, telephone numbers, social security numbers

4

Proprietary5

CHALLENGES FOR HEALTHCARE ORGANIZATIONSHealthcare IT teams typically cannot address malware on medical devices

– Detection and remediation tools don’t exist– Don’t have the product knowledge to access memory dumps on specific medical

devices– Majority of the IT cyber-defense software products do not run on medical devices

• Anti-Virus products run on open Windows, Linux IT servers– Any software beyond a patch provided by the manufacturer might negatively

impact FDA approval• Medical devices being treated as ‘black boxes’

• Healthcare organizations reverting to stronger language in Support Agreements from the device vendors

– Support Agreements typically pertain only to product functionality, not cyber-security

– Support technicians typically not trained or skilled sufficiently to handle complex security issues within an installed unit and prefer to replace the unit

5

Proprietary6

MEDICAL DEVICE DESIGN: DO-IT-YOURSELF (DIY)

• If you spend the time and the effort required to:• Integrate middleware• Integrate operating system components • manage all of the suppliers that provide these

• you are acting as an integrator rather than an innovator

• Why follow a DIY approach?• “It’s cheaper” - Is it really? Let’s use the example of a OS

– Linux has no licensing cost but is “Free” like a puppy– Linux OS is higher total cost of ownership when you consider:

» development cost » maintenance cost» support cost » certification cost

“We are what we repeatedly do.” –Aristotle

Proprietary7

MEDICAL DEVICE DESIGN: PARTNERING

• Partnering has higher upfront costs but leads to:– faster time to market– easier pre-market approval– lower total cost of ownership

• When you follow a DIY approach, you can dilute your ability to focus on innovation or core competencies

• Partnering brings a greater focus on Innovation YOUR core capability and what you do best

Proprietary8

WHAT’S INVOLVED WITH BUILDING A MEDICAL DEVICE TODAY?

Proprietary9

PRESSURE FOR THE DEVICE MANUFACTURERBuilding a device that meets the market demands

– Time to market– Differentiating feature set– Safety certifications– Security requirements– Connectivity (Wi-Fi, Cellular, Ethernet, USB)– HMI (Qt or HTML5 graphics, touch screen, video playback)

• Developed by a small team focused only on core intellectual property specific to the application– Not security experts– Not Cellular, Wi-Fi experts– Not graphics experts

Internal Use Only

9

Proprietary10

FDA LOCKING DOWN MEDICAL DEVICES• Content of Premarket Submissions for Management of Cybersecurity in

Medical Devices• Issued Oct. 2, 2014

• guidance provides recommendations to consider and information to include in FDA medical device premarket submissions for effective cybersecurity management

General Principles:• Manufacturers should:

– Develop a set of cybersecurity controls – Address cybersecurity during the design and development of the medical

device– Establish design inputs related to cybersecurity– Provide justification for the security chosen functions

Proprietary11

FDA LOCKING DOWN MEDICAL DEVICESThings to consider:• Identify and protect

– Limit access to trusted users only• User ID, smartcard, biometric

– Ensure trusted content• Detect, Respond, Recover

– Implement device features that protect critical functionality

Implementation options:• TPM: hardware solution

– Increases BOM cost• Remote attestation: networked solution • Advances in operating systems are needed!

– Fundamental improvements in security– IMA: Integrity Measurement Architecture

Proprietary12

IEEE CYBER SECURITY: BUILDING CODE FOR MEDICAL DEVICE SOFTWARE SECURITY

• Set of guidelines are meant to help companies “establish a secure baseline for software development and production practices of medical devices.”

• The code applies to software which runs in a wide range of medical devices

• Issued May 2015• Similar to a ‘building code’ for

houses and structures, this provides guidance on building safe and secure software for medical devices

Proprietary13

BUILDING CODE FOR MEDICAL DEVICESOFTWARE SECURITY

• The Building Code Report recommendations include using:– memory-safe programming languages– following secure coding standards– generating secure random numbers– keeping a whitelist of safe software applications that can only be updated

by authorized administrators– logging security-linked events

• Also highlighted elements intended to impede attacker analysis or exploitation (but not necessarily remove flaws)– Non-executable data pages in memory– Least operating system privilege (least-privilege principle)

• Minimize the amount of time spent executing at elevated privilege levels (Administrator, root)

• Provide better control and granularity of OS privilege levels

Proprietary14

THE OS NEEDS TO INCREASE ITS FOCUS ON SECURITY:LEAST-PRIVILEGE PRINCIPLE

• The OS needs to provide more protection against hackers in connected networks

• Permitting a thread to elevate to ‘root’ permission to do an operation is too coarse– Processes and threads need access to system-level resources – Sure.– We know to which system resources a process or thread needs access

• User-input needs access to keyboard driver and interrupts• File I/O needs access to the filesystem• Neither of these need access to mmap() or fork() (for example)

• System Architect knows the system-level privileges to which each process and thread needs access

Proprietary15

THE OS NEEDS TO INCREASE ITS FOCUS ON SECURITY:LEAST-PRIVILEGE PRINCIPLE

• The OS should provide much more fine-grained control of system privilege levels – control settings that govern and protect which operations a process can

perform, with granularity down to the system-call level– no longer have to give processes ‘root’ access to the entire system

• Breaks ‘root’ into multiple separate capabilities that comprise root authority

• Individual capabilities can be assigned to processes that need access to each specific resource– But no other resources

• Compromised processes only have a tiny subset of privileged operations available – Even if they become ‘root’

Proprietary16

GRANULAR CONTROL OF PRIVILEGE LEVELS:LEAST-PRIVILEGE PRINCIPLE

HMI Networking PulseOx

Privilege Level 1 2 3

SystemResource:

mmap ✔ ✖ ✖

exec ✖ ✔ ✔

fork ✖ ✖ ✖

ioctl ✖ ✖ ✔

sockets ✔ ✔ ✖

shmem ✖ ✔ ✖

Proprietary17

Security Research Group (SRG)– 20 hired full-time hackers– job is to break into the system– have compete access to full source code, so can

look for any vulnerabilities or holes– QNX OS has also undergone a large amount of

static analysis performed by the SRG

• All the incidence reports generated by SRG have been fixed in the latest QNX OS

• All market verticals • US DOD network

EXHAUSTIVE HACKINGBLACKBERRY SECURITY RESEARCH GROUP

Proprietary18

CHALLENGES OF INTEGRATING MIDDLEWARE TECHNOLOGIES

Connectivity,Graphics,andMiddlewareComponents

CoreOS

GraphicsSubsystem

HL7

BTLE

Medicalapplication

QtCellular

Java

ECG BP PulseOx

DeviceManagement

IAP

CameraVideo IEEE1588

Networking HAManagerUtilities DriversDatabase

microkernel scheduler Adaptivepartitioning libc multicore

FilesystemsConnectivity

HTML5

Hardwareplatforms

TIAM335 TIAM437 TIAM572 FSLi.MX6 x86

Infusion

Wi-Fi

Compliance Documentation• Hazard & Risk Analysis

• Failure Analysis• Testing records• High level design• Safety Case

Proprietary19

AN OS IS SOUP?• IEC 62304:

• a) assumes that off-the-shelf software (commercial or otherwise) will be used, and

• b) offers two definitions of SOUP, which can be either (or both of)• software not developed for a medical device, or • software with unavailable or inadequate records of its development

processes

• Distinction is not between COTS vs. SOUP

• More useful distinction is between opaque SOUP and clear SOUP• Depends on what artifacts are available to support a safety case for the

software• These artifacts are necessary to support your claims of safety

Proprietary20

SOUP: CLEAR? OPAQUE?For example:• Microsoft Windows OS is opaque SOUP:

• well-documented development process• its vendor adheres to a development processes• is in possession of the source code • has tracked and documented the software’s failure history• But not available for public scrutiny

• Open source (Apache or Linux) is clear SOUP• source code and fault histories freely available• software’s characteristics are well-known• can be scrutinized with code symbolic execution and path coverage analysis• the software’s long (and freely available) histories make findings from

statistical analysis particularly relevant• Clear SOUP: Software that we can examine

Proprietary21

SOUP: CLEAR? OPAQUE?• Clear SOUP: May not be the best solution for medical devices• Processes for open source development are neither clearly defined nor

well documented• A precise concern of IEC 62304

• SOUP or COTS software may include more functionality than is needed• leaves dead code in the system, a practice that functional safety

standards, such as IEC 61508 and IEC 62304, expressly discourage• Device drivers for devices that are not in the medical product• Support for filesystem types that are not in use

• Removing dead code from the system can be a significant burden• Initial removal• Maintenance and patches over the product’s in-service life

Proprietary22

PROVENMIDDLEWARE –WHAT’S AVAILABLE?

Proprietary23

QNX SDK FOR APPS AND MEDIA 1.1QT 5.3.1 INTEGRATION

• Qt based navigator• Qt based reference applications• Launch Qt, HTML5, APK, and native

OpenGL ES apps

QNX Neutrino RTOS

Qt FrameworkQt QuickQMLScripting

ActiveQtUnit TestsBenchmarking

ToolsCross-platform IDEQt CreatorI18N toolsHelp SystemBuild tool

Embedded Application

Apps and Media

Startup ControlApp Framework

CoreGUIGraphic View

MultimediaNetworkMobility

BrowserNetwork ManagerAudio Manager

Camera Video Soft Keyboard

Proprietary24

QT FOR MEDICAL DEVICES - EXAMPLE

Proprietary25

QNX WIRELESS FRAMEWORKMODULAR, SCALABLE, CONFIGURABLE

Proprietary26

UNMODIFIED RUNTIME BEHAVIOURHYPERVISOR

Reduce Safety-certification scope and efforts– Significant activity in Automotive

• Separate and isolate the Apps:– Hypervisor runs directly on the hardware,

isolating multiple operating systems – Individual OS resources are configured by

the hypervisor– Minimal performance implications– Better isolation than a shared kernel

solution– Can add a firewall between OSes– Leverage the security features in the OS

General Purpose

OS

Hypervisor

Safety-Critical

OS

Hardware

Proprietary27

SUMMARY• Medical device connectivity: it’s happening, it’s the future

– It’s also a challenge - cybersecurity– QNX has integrated solutions

• Building a medical device requires more: – Middleware– Integration & certification efforts– Disparate devices– Lifecycle maintenance efforts

• Medical device software integration– Putting it all together on your hardware platform can take man-years– Graphics, security, Wi-Fi, cellular, Open*, databases, encryption, …

• Do you want to be an integrator or do you want to be an innovator? Focus on what you do best and partner for everything else

• Pick an operating system vendor that offers the components, certifications, and has a 30+ year trusted heritage in Medical devices

Proprietary28

www.qnx.com | @QNX_Newswww.qnx.com | @QNX_News

THANK YOU.