details from ethical hacking assessments and industry ... · details from ethical hacking...
TRANSCRIPT
Medical Device SecurityDetails from Ethical Hacking Assessments and Industry Leading Guidance for Medical Device Security Programs
1
Agenda
• Introductions
• Medical Devices: The Weakest Security Link
• Real-world Examples from Ethical Hacking Testing
• How to Build an Effective Medical Device Security Program
• Questions
2
INTRODUCTIONS
3
IntroductionsBrian Selfridge, Partner, Meditology Services
• 13+ years experience in healthcare IT security and compliance leadership
• Previously CISO of a large health system and healthcare security consultant at PricewaterhouseCoopers
• Advisor to ONC on ethical hacking security for healthcare; conducted numerous medical device assessments and strategic plans
• Leads Meditology’s IT Risk Management practice including Medical Device Security, Risk Assessment, and Ethical Hacking services
Meditology is dedicated to delivering expertise and leadership in information privacy and security, compliance, and audit, specifically for healthcare
4
MEDICAL DEVICES: THE WEAKEST SECURITY LINK
5
Defining Medical DevicesA medical device may be defined as any component(s)
[hardware, software] that is/are:
• FDA 510K certified
• Any device that is used in patient healthcare for
diagnosis, treatment or monitoring
• Any ancillary support device including but not limited
to external disk storage, database servers, gateway or
middleware interface devices -that are required for the
medical device to function properly
Networked medical device: Any medical device that is
connected to the organization’s network
12
/5/2
01
6
6
Definition source: VA Medical Device Protection Program (MDPP)http://docplayer.net/4411952-Va-medical-device-protection-program-mdpp.html
The Weakest Link• Medical devices are increasingly network connected
• Healthcare data is increasing in value for cyber criminals
• Default passwords, missing patches, remote access, and other
weaknesses make devices a prime target for entry
• Incidents with medical devices can impact patient safety and can also
lead to data breach and regulatory action
• Device security has direct impact to patient safety for both targeted
and indiscriminant attacks
7
Common Challenges• Vulnerability and patch management rigor is often not applied
• Medical devices are vulnerable to targeted hacking and also to
indiscriminate malware infection
• Lack of clearly defined ownership and accountability for patching
• Medical devices often run on unsupported platforms
• Dependence on third parties to manage and secure devices
• Lack of coordination of industry segments and stakeholders leaves a lot of
finger pointing
• Medical device and IT departments have historically been separate
business units and often did not include security oversight of biomed
8
FDA
NIST
CSF, 800-39, & 800-53
Presidential Directives &
Executive Orders
ISO
NH-ISAC
National Cybersecurity
Center of Excellence
MDISSHIPAA / HITECH
DTSec MITRE
Joint Commis-
sionHIMSS MDS2
Regulations & Frameworks
9
REAL-WORLD EXAMPLES FROM ETHICAL HACKING TESTING
10
Ethical Hacking ExamplesThe following represent real-world scenarios identified during ethical
hacking testing at healthcare providers
• Common administrative username and password for medical
device vendors used across clients
11
Accessed millions of
PHI records
Obtained domain admin rights
Obtained cached admin
passwords
Logged into
remote access portal
Found known admin
account
Ethical Hacking Examples• Medical devices often serve as the gateway or entry point into the
rest of the network
• Able to use VNC remote access technology installed on medical
equipment for maintenance purposes, no password required
12
Ethical Hacking Examples• Physical access: able to access unauthenticated patient monitoring
systems, lab device consoles, pre-natal tracking systems, and
radiology systems
• Cracked wireless networks with outdated WEP encryption; able to
access the rest of the clinical network and systems from the parking
lot
• Accessed pharmacy automated dispensing cabinets and were able
to break out of the application, create local windows accounts, and
access the system directly
13
INDUSTRY LEADING GUIDANCE FOR MEDICAL DEVICE SECURITY PROGRAMS
14
Medical Device Security Program
15
Objectives
16
• Design and develop a formalized and documented medical device
security risk management program (MDSP)
• Define roles and responsibilities
• Align the medical device security risk management program with one
or more applicable industry standard frameworks
• Align the MDSP with Clinical Engineering and IT department strategies
• Identify metrics or key performance indicators (KPIs)
• Outline the tools and technologies to support the MDSP
• Develop a multi-year road map to improve the maturity of the MDSP
over time
Maturity Model
17
Step 1: Communications
18
• Define stakeholders
• Clinical engineering
• Information security
• IT
• Manufacturers and vendors
• Legal
• Compliance
• Procurement
• Departments (e.g. Radiology)
• Formalize policies and
procedures
• Establish governance
Step 1: Communications
19
Define Metrics and KPI’s
Step 2: Asset Inventory &
Scanning
20
Asset Inventory RFID Tagging
21
Image source: http://rfiddiscovery.com/rfid-discovery-solutions/asset-tracking/
• Radio Frequency Identification
(RFID)
• Allows real-time tracking of
medical device inventory
• Improves accuracy of a medical
device asset inventories
Step 2: Vulnerability Scanning
22
Vulnerability Scanning
Step 2: Vulnerability Scanning
23
• Ensure vulnerability management scope includes medical devices, this
includes scanning and patching expectations.
• Update vulnerability management plans/procedures to include med
devices
• Leverage existing vulnerability scanning tools and processes where
available
• Limit scanning tools to perform more conservative scan settings (e.g.
disable DOS, limit number of concurrent connections, turn off unrelated
plugins and checks)
Step 3: Virus / Malware Protection
24
• Two models:
o Customer provided anti-virus solution
o Vendor provided anti-virus solution
• Define the following processes:
o Document the date, time and version number of the install in the medical
device asset inventory sheet
o Virus pattern update schedule
o Frequency of scanning (full system scans)
o Reporting functionality and method for communicating incidents/alerts
o Incident management expectations and communication
o Track and document formal scanning exceptions
Step 4: Patching
25
• Two models:
o Patches implemented by customer
o Patches implemented by vendor
• Define the following processes:
o Roles and responsibilities
− Medical device vendors and
manufacturers
− Clinical engineering
− Information Security
− IT• Establish Reporting mechanisms
and associated metrics
• Document tools and procedures
used for patching
Step 5: Technical Security
Controls
26
• Change or disable default vendor login accounts and passwords
• Segment medical devices from the rest of the network and limit to
minimum necessary traffic, this protects the devices and also
protects other critical systems from damage from infected medical
devices
• Ensure internet-facing systems are incorporated into a DMZ model
• Require multi-factor authentication for remote access to medical
devices
Step 5: Technical Security
Controls
27
• Ensure IDS/IPS capability is in
place for network segments
containing medical devices
• Incorporate medical devices
into audit log aggregation and
monitoring solutions
• Implement restrictions on USB
functionality to limit malware
infection and data loss
exposures
Step 6: Validation
28
• Incorporate medical devices into a formal
third party vendor risk management
program
• Maintain a repository of medical device
security evaluations, risk assessments, and
results
• Ensure that there is a checkpoint in place
for a security risk analysis to be conducted
prior to the purchase or implementation of
new biomed equipment or software
• Align questionnaires and assessment
methodology with industry standard
frameworks
Step 6: Validation
29
Step 6: Validation
30
MDS2
Step 7: Training
31
• Create and deliver specialized medical device security training for
the following groups:
o Clinical Engineering
o IT / Information Security
o Purchasing
o Legal
o Clinical staff and end users of medical devices
o Oversight and steering committee(s)
• Deployment methods
o Existing Computer Based Learning (CBL) software
o Email blasts or newsletters
o Awareness campaigns (posters, flyers etc.)
o Annual training or seminars
o Quarterly meetings, Lunch & Learn presentations, etc.
Step 7: Training
32
• Example training topics:
• MDSP overview and roles and responsibilities
• Definition of medical devices
• Patient safety implications of medical devices
• Applicable regulations and standards
• Examples and case studies of medical device security incidents
• Common security challenges with medical devices
• Third party medical device vendor technical and security validation
• Technical limitations of devices – password limitations, WiFi
protocol limitations (WEP or WPA), user account separations etc.
• Remote access model for medical device vendors
• Day to day operational impact upon device malfunction or failure
• Security incident response procedures
• Awareness of operational policies and procedures
Step 8: Network Isolation
33
Source: http://s3.amazonaws.com/rdcms-himss/files/production/public/HIMSSorg/Content/files/MedicalDeviceIsolationArchitectureGuidev2.pdf
Implementation Roadmap
34
Implementation Roadmap
35
36
Example Deliverables
