1
2	IVD Instrument Cyber-security IVD Instrument evolution Regulatory Guidance & Standards Risk-based approach Summary
3	IVD Instrument Evolution – Computing platforms
4	Typical IVD Instruments
5	Typical IVD Instruments
6	Typical IVD Instruments
7	IVD Instruments evolution – Risks
8	IVD Instruments evolution – Benefits
9	Typical IVD Networked Instruments
10	Networked Instruments
11	IVD Instrument Cyber-security IVD Instrument evolution Regulatory Guidance & Standards Risk-based approach Summary
12	IVD Instrument Cyber-security
13	IVD Instrument Cyber-security
14	IVD Security – Regulatory Guidance Strong linkage between cyber-security and Off-the-Shelf software Directive: IVD instrument manufacturers must assume ownership of cyber-security issues related to COTS Several guidance documents cover some aspect of network security: “General Principles of Software Validation; Final Guidance for Industry and FDA Staff” “Guidance for Industry, FDA Reviewers and Compliance on Off-the-Shelf Software Use in Medical Devices” “Guidance for FDA Reviewers and Industry, Guidance for the Content of Premarket Submissions for Software Contained in Medical Devices” “Guidance for Industry – Cyber-security for Networked Medical Devices Containing Off-the-Shelf (OTS) Software”
15	IVD Security – Regulatory Guidance “Guidance for Industry, FDA Reviewers and Compliance on Off-the-Shelf Software Use in Medical Devices” “Off-the-shelf operating systems are commonly considered for incorporation into medical devices as the use of general purpose computer hardware becomes more prevalent. The use of OTS operating system software allows device manufacturers to concentrate on the application software needed to run device-specific functions.” “However, an OTS operating system software is intended for general purpose computing and may not be appropriate for a given specific use in a medical device.”
16	IVD Security – Regulatory Guidance “Guidance for Industry, FDA Reviewers and Compliance on Off-the-Shelf Software Use in Medical Devices” 5.3.1 Network Requirements Analysis 1. Speed - The response time …. should be appropriate so that bottlenecks do not occur. 2. LAN Architecture - The size of the LAN (the number of user nodes) and the topology of the LAN should be specified. 3. Network Operating System (NOS). Whether off-the-shelf or proprietary, this selection should consider the trade-off between robustness and flexibility. 4. Data Integrity - One of the most important issues for any medical device operating in a network is data integrity. The manufacturer should insure that the network system software and hardware incorporate error checking, handling, and correction measures commensurate with the level of concern of the device. Transmission of data packets and files should include error detection and correction. Error detection methods include parity, checksum, and cyclic redundancy check (CRC). Transaction rollback after non-committed changes or network failure, supports data integrity in medical device LANs. Critical data and files may be stored in duplicate at separate locations. 5. Network Management and Security - User authorization and authentication should precede accesses to sensitive patient information.
17	IVD Security – Regulatory Guidance “FDA Guidance for the Content of Premarket Submissions for Software Contained in Medical Devices” Virus Protection Software “Software applications designed to protect information systems, including software devices, from harmful or malicious code (“viruses,” “worms,” etc.) are becoming more commonplace as devices become increasingly interconnected and therefore exposed to the external information environment.”
18	IVD Security – Regulatory Guidance “FDA Guidance for the Content of Premarket Submissions for Software Contained in Medical Devices” Interfaces, Networking, and Network Infrastructure “Software Devices are increasingly interconnected, both through point-to-point interfaces for exchange of specific data with specific devices and by connection to local and wide area networks and the Internet. While data exchange and communication infrastructure such as telephone lines, local area networks, and broadband connections are not regulated as medical devices, connection to these carriers affects the operation of Software Devices, sometimes adversely. An example is a Software Device that is connected to a local area network and ceases to operate properly when a problem occurs with the network interface. We recommend that your software design should take into account both the capabilities and liabilities of the interfaces provided with your device, and in particular that your hazard analysis and mitigations encompass these issues.”
19	IVD Security – Standards “Remote Access to Clinical Laboratory Diagnostic Devices via the Internet”, Auto9-P Remote Access to IVD instruments becoming more common-place Main drivers: eBusiness and eService Connecting to Internet over Hospital LAN far more effective than using dedicated modem and ISP provider Remote Access standardization effort initiated to provide common security protocols and guidance for both IVD manufacturers and hospital IT staff
20	IVD Instrument Cyber-security IVD Instrument evolution Regulatory Guidance & Standards Risk-based approach Summary
21	Cyber-security Hazard Analysis 1. Hazard: no result when needed for critical care Cause 1.1: Instrument not operating due to compromised control program or operating environment due to cyber-security breach. Cause 1.2: …..
22	Cyber-security – Risk Mitigation Isolate instrument computer on a private network – no direct Internet connection. Firewalls, restricted IP addresses. Limit protocols and ports to ‘http’ and ‘https’ (encrypted). Other protocols with known security risks (FTP, Telnet) are closed or routed through https. Virus protection software and mechanism to keep current. All “User” access is password protected. Utility to recognize un-authorized process detection, CPU usage monitoring. No user-access to Operating System, ‘Desktop launch’, Control Panel, etc. Redundant storage of critical data, ‘fail-safe’ backup and restore process. No auto-configuration for “new hardware found”. Monitor any access / change to instrument file systems.
23	Cyber-security – Risk Mitigation Internet connection firewalls .. “double-hull” concept: Instrument isolated from Hospital LAN Instrument and ‘middleware’ connected via ‘private’ 10.10 network
24	Cyber-security – Risk Mitigation Cyber-security issues with IVD instruments, although critical for proper system operation, are less complex than IT desktop scenarios or personal computing. No games!! Known hardware configuration Limited 3^rd party applications No “MS Outlook” address book, pop-up windows, cookies, etc. Conclusion: IVD instruments using OTS software can restrict usage of many Operating System features, and thereby reduce risk.
25	Cyber-security – Anti-virus software Large body of scientific research papers * Virus Bulletin 2010: A Retrospective by Steve R. White, presented at the Virus Bulletin Conference, September 2000 [pdf version] An Undetectable Computer Virus by David Chess and Steve White, presented at the Virus Bulletin Conference, September 2000 [pdf version] Virus Writers - The End of the Innocence? by Sarah Gordon, presented at the Virus Bulletin Conference, September 2000 [pdf version] Is Java Still Secure? by Dave Chess & John Morar, presented at the Virus Bulletin Conference, October 1999 [pdf version] Where There's Smoke There's Mirrors: The Truth About Trojan Horses on the Internet, Virus Bulletin Conference, October 1998 by David Chess and Sarah Gordon. The Future of Viruses on the Internet by David Chess Hoaxes & Hypes by Sarah Gordon, Richard Ford and Joe Wells Computer Viruses: A Global Perspective by Steve White, Jeffrey Kephart and David Chess How Prevalent are Computer Viruses? by Jeffrey Kephart and Steve White * IBM Research, http://www.research.ibm.com/antivirus/SciPapers.htm
26	Cyber-security – Anti-virus software Commercial Anti-virus software design requirements: Norton AntiVirus™ .. basic operating mode is to “scour for threats” Algorithms to discriminate normal programs from viruses Requires full access to computing environment, Disk, CPU usage Requires timely automatic update process, usually via Internet (itself the source of most viruses and worms!)
27	Cyber-security – IVD Instrument risk control
28	Summary Cyber-security risks are an inherent result of expanding the capabilities of IVD instruments to capitalize on information-age technology. Essential that IVD manufacturers address cyber-security issues to satisfy both regulatory and customer concerns. Risk Management approach can be extended to address hazards associated with cyber-security. IVD cyber-security risk mitigation can take advantage of the limited usage scenarios and known configurations to enhance security against the universe of threats.