Cybersecurity for

Medical Devices:
Three Threads Intertwined
Presented to MedSun audio
conference
Cybersecurity of Medical
Devices
on April 12th, 2005
by
Scott Bolte
(Scott.Bolte@ge.com)
Product Security Program
Manager
GE Healthcare

First, the Patients Thread

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.
Copyright 2005 by General Electric
Company

3/
Scott Bolte /
2005-04-12

Next, A Manufacturers Thread

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.

Copyright 2005 by General Electric

Company

5/
Scott Bolte /
2005-04-12

GE Healthcare Initiatives in a
Nutshell
Product 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.

Copyright 2005 by General Electric

Company

6/
Scott Bolte /
2005-04-12

Finally, the Healthcare Providers

Thread

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).

Copyright 2005 by General Electric

Company

8/
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.

Copyright 2005 by General Electric

Company

9/
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.

Copyright 2005 by General Electric

Company

10 /
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.
Dont reinvent the wheel or set up special channels -- use
established support mechanisms.

Copyright 2005 by General Electric

Company

11 /
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.
Copyright 2005 by General Electric
Company

12 /
Scott Bolte /
2005-04-12

Weaving the Threads Together

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.)

Copyright 2005 by General Electric

Company

14 /
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 Securit
y
(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.
Copyright 2005 by General Electric
Company

15 /
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.
Copyright 2005 by General Electric
Company

16 /
Scott Bolte /
2005-04-12

Additional Information

GE Healthcare
The ever growing security portal

http://www.gehealthcare.com/usen/security/index.html

includes:

Manufacturers Disclosure Statement

for Medical Device Security (MDS2)
for GE Healthcare products
FAQs
Product vulnerability information

Copyright 2005 by General Electric

Company

18 /
Scott Bolte /
2005-04-12

NEMA Security & Privacy

Committee
SPCs 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

Copyright 2005 by General Electric

Company

19 /
Scott Bolte /
2005-04-12

HIMSS Medical Device Security

WG
HIMSS work groups material at

http://www.himss.org/ASP/topics_medicalDevice.asp

includes:

original Manufacturers
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.
Copyright 2005 by General Electric
Company

20 /
Scott Bolte /
2005-04-12

Original MDS2 a Huge Step

Forward
In 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.

Copyright 2005 by General Electric

Company

21 /
Scott Bolte /
2005-04-12

Enhanced MDS2 as New Model?

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 notes
to device profile for each
of their product lines.
Sponsor
Users optionally augment
manufacturers documents
with site specific notes and
instructions to guide
installation and operation
Manufacturer
of medical device.
User
Copyright 2005 by General Electric
Company

22 /
Scott Bolte /
2005-04-12

Device Profiles in the Future?

https://sourceforge.net/projects/device-profile/ is a
brand new effort to automate

communication such
as the MDS2

Sponsors (e.g. HIMSS) create

standard questions.
Manufacturers document
each product.
Users augment manufacturer
information with local
guidance.

Copyright 2005 by General Electric

Company

23 /
Scott Bolte /
2005-04-12