Cybersecurity for Medical Devices: Three Threads Intertwined Presented to MedSun audio conference...

Cybersecurity forMedical Devices:

Three Threads Intertwined

Presented to MedSun audio conference

Cybersecurity of Medical Devices

on April 12th, 2005by

Scott Bolte([email protected])

Product Security Program Manager

GE Healthcare

mailto:[email protected]

First, the Patient’s Thread

3 /Scott Bolte /2005-04-12

Copyright © 2005 by General Electric Company

What Really is at Risk?

Common focus on individual medical devices is important… but misleading.

Most medical systems can be secured simply by disconnecting them from the network.

Unfortunately what would be lost, and what really needs to be protected, is the secure transfer of clinical information between medical systems.

The right information, before the right people, at the right time, improves patient treatment. Security improvements must not impede that information flow.

Next, A Manufacturer’s Thread

5 /Scott Bolte /2005-04-12


Constraints on Manufacturers

Manufacturers rarely need to get approval from FDA with regards to Cybersecurity fixes. However, they always need to validate safe & effective operation after changes, including 3rd party patches.

No one can predict impact of 3rd party changes on clinical operations in advance. Therefore, verifying and validating seemingly minor changes may take significant time.

Determining impact of patch, or any other design change, usually requires deep understanding of medical device.

Everyone would like to move faster, but there is no magic way to avoid necessary validation.

6 /Scott Bolte /2005-04-12


GE Healthcare Initiatives in a NutshellProduct Development Changes:• Eliminating default but unnecessary network services to reduce the opportunities for future attacks.

• Objective & automated vulnerability assessments at each product release.

• Formal design requirements system augmented with new security requirements.

Organizational Capabilities Changes:• Enhancing remote service technology to improve response times.

• Optimizing validation & verification of corrective and preventive actions.

• Established incident response and threat assessment processes spanning the globe.

Improved Communication:• Ongoing security education & awareness training throughout GE Healthcare.

• Improved channels of communication with customers.

Finally, the Healthcare Provider’s Thread

8 /Scott Bolte /2005-04-12


Proceed with Caution

Traditional IT assumptions and procedures need to accommodate unique medical device realities.

Generic IT security best practices, indiscriminately applied to medical devices without manufacturer coordination, can pose patient safety risk. For example:• automatic patching can and has broken medical devices,• network vulnerability scans can disrupt clinical operations,• antivirus software can disrupt time-sensitive clinical operations,• misidentification of clinical data as a virus may interfere with

clinical care,• authentication schemes must fail-open (let the user in) instead of

fail-closed (lock the user out).

9 /Scott Bolte /2005-04-12


Long Term Perspective Required

Unlike most IT systems, medical devices life cycles can be 10, 15, 20 years or longer!

While general purpose hardware & software need to be replaced regularly to keep up with evolving needs, medical devices will continue to perform their focused purpose adequately for many years.

Need to assume underlying operating systems may be used years longer than IT managers typically expect.

10 /Scott Bolte /2005-04-12


The Sky is NOT Falling

All security problems are not equal.

Threat prioritization, with a phased remediation plan, is required.

Response to specific threats should be based on threat assessment.

Cornerstones of threat assessment are likelihood & severity. Some factors include:• impact on host (severity of compromise/infection),• immediate attack vs. potential exploit,• manual vs. automatic propagation of malicious attack (expected virulence),• expected use profile of system,• proactive external controls already in place.

Both manufacturers and healthcare providers can and should proactively take steps to reduce likelihood of problems.

11 /Scott Bolte /2005-04-12


Ongoing Communications

Cooperation between hospital IT staff and clinical personnel is critical since both parties have essential knowledge. It is dangerous when they work independently.

Cooperation between healthcare providers and equipment manufacturers is also critical; for the exact same reasons.

Treat security problems and concerns like any other problem with a medical device. They are hazards that need to be appropriately addressed.

Don’t reinvent the wheel or set up special channels -- use established support mechanisms.

12 /Scott Bolte /2005-04-12


Secure Network Designs

Medical devices are provided with filtered power, filtered air, filtered water, etc. Why not filtered networks?

Defense-in-depth network designs proven and effective at reducing risks. For example, Department of Veteran Affairs' Medical Device Isolation Architecture Guide.

Exploit predictable medical device network communications:• restrict medical device connections to known peers (e.g. patient monitor with central nurses station, scanner and a PACS, HIS, RIS, lab, etc.),• prevent connections with general purpose systems (e.g. uncontrolled laptops),• use network intrusion detection systems (NIDS) to detect unexpected patterns, but be cautious triggering automatic responses.

Healthcare providers restricting medical device communications to defined peers is non-invasive yet can be incredibly effective.

http://www.himss.org/ASP/topics_FocusDynamic.asp?faid=101

Weaving the Threads Together

14 /Scott Bolte /2005-04-12


We Must Work Together

Interoperability is essential as with DICOM, HL7, and other clinical standards.

Manufacturers must continue to work together and with healthcare providers on security standards, otherwise clinical interoperability may be undermined.

Industry forums should be used to develop and/or publicize standards & best practices. (See NEMA, HIMSS, etc. pages in Additional Information appendix.)

15 /Scott Bolte /2005-04-12


MDS2: A Pattern for Things to Come?Looming April 2005 HIPAA security regulations were driving a lot of churn for manufacturers and healthcare providers throughout 2004.

The HIMSS Medical Device Security Workgroup recognized the opportunity to simplify through standardization and rose to the challenge.

The Manufacturer's Disclosure Statement for Medical Device Security (MDS2) was developed in just a couple of months last fall is already a de facto industry standard.

MDS2 is a model of how collective wisdom can streamlining effective communication between all parties.

More information on the MDS2 may be found in the Additional Information appendix.




16 /Scott Bolte /2005-04-12


Conclusion

Everyone has things they can do on their own to manage risk, both immediately and long term.

Industry forums should be used to share knowledge and develop common solutions.

GE Healthcare will continue to work with our customers and our peers to develop better products, standards, and practices for the industry.

Medical device cybersecurity risks can be managed without interfering with patient care… if we work together.

Additional Information

18 /Scott Bolte /2005-04-12


GE Healthcare

The ever growing security portal http://www.gehealthcare.com/usen/security/index.html includes:• Manufacturer’s Disclosure Statement for Medical Device Security (MDS2) for GE Healthcare products

• FAQs

• Product vulnerability information

19 /Scott Bolte /2005-04-12


NEMA Security & Privacy CommitteeSPC’s material at http://nema.org/prod/med/security/ includes:• Break-Glass – An Approach to Granting Emergency Access to Healthcare Systems

• Patching Off-the-Shelf Software Used in Medical Information Systems

• Defending Medical Information Systems Against Malicious Software

20 /Scott Bolte /2005-04-12


HIMSS Medical Device Security WGHIMSS work group’s material at http://www.himss.org/ASP/topics_medicalDevice.asp includes:• original Manufacturer’s Disclosure Statement for Medical Device Security (MDS2),

• Department of Veterans Affairs’ Medical Device Isolation Architecture Guide,

• links to current issues, trends and tools,

• contact information to join work group.

21 /Scott Bolte /2005-04-12


Original MDS2 a Huge Step ForwardIn the style of DICOM conformance statements and IHE integrations profiles the MDS2 has:• standard set of questions and instructions,

• objective yes/no type questions required with optional notes,

• all users benefit from knowledge of MDS2 authors,

• standard format eases manufacturer burden,

• standard, objective format eases burden on device users.

22 /Scott Bolte /2005-04-12


Enhanced MDS2 as New Model?

Sponsor

Manufacturer

User

Three organizations work together to efficiently share information.• Sponsor first identifies widespread need and then creates

standard profile with fixed questions & instructions (e.g. HIMSS creating MDS2).

• Manufacturer, in turn,adds answers and notesto device profile for eachof their product lines.

• Users optionally augmentmanufacturer’s documentswith site specific notes andinstructions to guideinstallation and operationof medical device.

23 /Scott Bolte /2005-04-12


Device Profiles in the Future?

https://sourceforge.net/projects/device-profile/ is a brand new effort to automatecommunication suchas the MDS2 • Sponsors (e.g. HIMSS) create standard questions.

• Manufacturers document each product.

• Users augment manufacturer information with local guidance.

Date post:	18-Dec-2015
Category:	Documents
View:	218 times
Download:	1 times

Cybersecurity for Medical Devices: Three Threads Intertwined Presented to MedSun audio conference...

Documents