Ultrasound Cybersecurity – Comprehensive Notes

Objectives

  • Gain knowledge of key terminology involved in the security of ultrasound and imaging.

  • Understand key principles in cybersecurity applied to ultrasound workflow.

  • Understand the role of IT and the processes in place that are applied for new software and equipment purchases.

Introduction

  • Benefits of diagnostic ultrasound deployment come with cybersecurity risks; hospitals must allocate resources to establish robust cybersecurity measures to safeguard patient data and prevent unauthorized access to hardware, ultrasound applications, and sensitive data.

  • Consequences of privacy breaches include privacy violations, legal liabilities, operational disruptions, and potential patient safety concerns if ultrasound systems or software are compromised.

  • Balancing technological advancement with cybersecurity readiness is critical for hospitals deploying ultrasound at scale.

  • Chapter overview: key aspects to consider when implementing and maintaining an ultrasound program regarding cybersecurity, including:

    • Ultrasound modalities and connected peripheral devices

    • Cybersecurity risks

    • Hospital review and approval processes

    • System access

    • Ultrasound workflow solutions and access considerations

    • Privacy matters

Ultrasound Modalities and Connected Peripheral Devices

  • Ultrasound imaging has evolved from bulky machines to portable devices, increasing connectedness and data exposure.

  • Risks include remote tampering with ultrasound images, potentially leading to misdiagnosis and patient harm.

  • Healthcare cyberattacks highlight the need for secure ultrasound technology now, not in the future.

  • Goal: describe potential risks and mitigations for each component of ultrasound devices to provide a full cybersecurity picture when acquiring, using, or managing ultrasound systems.

  • Objective: protect patient data, ensure image integrity, and safeguard overall ultrasound system functionality.

  • Ultrasound device formats vary; key components and vulnerabilities depend on the format.

  • Table 20.1 summarizes key components.

Table 20.1 Ultrasound device components

  • Component / System

    • Cart-based, compact, portable, or handheld ultrasound devices

  • Transducers or probes

    • The transducer is attached to the patient and connected to the ultrasound system to generate images

  • Smart device

    • Smartphones/tablets running required mobile apps for handheld devices

  • Display monitor(s)

    • High-resolution color monitors for real-time images

  • Printer or digital outputs

    • Ability to print or generate digital copies of patient reports

  • Peripherals

    • USB media, barcode readers, or proprietary data-exchange ports

  • Network card

    • Enables wired/wireless connectivity to PACS, Modality Worklist, etc. via DICOM

  • Notes on handheld ultrasound:

    • Managed via an associated mobile app on a smart device

    • Security focus shifts to the smart device and its management via Mobile Device Management (MDM)

    • MDM ensures approved devices connect to network resources (PACS, Modality Worklist, ultrasound management systems)

    • Benefits: HIPAA and privacy regulation compliance; mitigates reputational and financial risk from data breaches

  • Risk assessment:

    • Conduct a thorough risk assessment for each component with manufacturer assistance

    • Focus on potential threats, vulnerabilities, and impact on patient safety and data privacy

    • Security assessments align with Tables 20.2 and 20.3

Handheld devices and mobile device management (MDM)

  • For handheld devices, the healthcare system’s MDM governs the smart device; devices must be approved to connect to required networks and applications (Modality Worklist, PACS, ultrasound management systems).

  • Benefits of MDM: compliance with privacy laws (e.g., HIPAA) and data protection, reduces reputational and financial risk from breaches.

  • Critical: threat modeling and controls extend to the mobile device ecosystem (app, OS, network connectivity).

Risk assessment and security considerations

  • A healthcare provider should perform a risk assessment with manufacturer assistance for each component (Table 20.2 and 20.3 focus).

  • Mitigation planning should be data-driven, with transparency about design mitigations and exposed vulnerabilities.

Cybersecurity assessment aspects (Table 20.2)

  • The table outlines key cybersecurity aspects and their descriptions:

    • Access control: User authentication, authorization, accounting; least privilege; critical control; discussed in System Access.

    • Data in transit encryption: Encrypt data transmitted between ultrasound device and other systems (PACS, image analysis, EHR).

    • Data at rest encryption: Encrypt short-term or temporary storage (e.g., patient data on device storage).

    • Secure USB storage: Some devices transfer data to USB; manufacturers may lack universal USB encryption; recommended AES-256-bit encryption for USB storage as feasible.

    • Software updates (patching): Regular updates to mitigate vulnerabilities; manufacturers should perform risk assessments and disclose in-design mitigations.

    • Physical security: Protect devices from tampering; critical in POCUS handheld use.

    • Remote services: Telehealth, remote collaboration, or cloud integrations must use TLS ≥ 1.2 for data in transit; mitigations against MITM attacks; privacy considerations for data sharing.

    • Network security: Secure network connections, minimize attack surface via segmentation, protect DICOM/LDAP/HTTP with TLS 1.2 or 1.3.

    • Secure disposal: Proper disposal to prevent data breaches; securely wipe/destroy data storage per vendor guidance.

Data encryption standards reference

  • Data at rest: AES-256 ext{, }AES-192, RSA, 3DES}

  • Data in transit: TLS versions TLSext1.2TLS ext{ }1.2 or TLSext1.3TLS ext{ }1.3

Relevance matrix for cybersecurity risk assessments (Table 20.3)

  • Provides a cross-reference of how each risk control maps to device components:

    • Transducers or probes

    • Display monitor(s)

    • Printer or digital outputs

    • Access control

    • Data at rest encryption

    • Data in transit encryption

    • Secure USB storage

    • Software updates (patching)

    • Physical security

    • Third-party integrations

    • Network security

    • Secure disposal

  • System classifications in Table 20.3 include:

    • Smart devices

    • Peripherals (traditional)

    • (handheld)

  • Emphasizes that the system (especially the main ultrasound system or the handheld device’s control) is the most critical component, but all other components contribute to the overall risk surface.

Cybersecurity Risks

  • Risks arise from the need to associate patient data with exams and the connected nature of ultrasound systems.

  • Key themes:

    • Protect patient data from unauthorized access; mitigate breaches.

    • Human element: culture of cybersecurity is essential; training reduces lapses like sharing credentials or phishing susceptibility.

    • A mature medical device cybersecurity program requires people and processes in addition to technology; misallocation of investment without proper processes is a common challenge (HIMSS white paper).

  • Robust protections include encryption and access controls to mitigate risks.

  • Interconnected ultrasound devices introduce privacy and security risks across the healthcare ecosystem.

Specific risks highlighted (Table 20.4)

  • Unauthorized access: potential data theft or manipulation if access controls are weak; risks of ransomware and C2 code if security is poor.

  • Data breaches: encryption at rest and in transit, plus strong access controls.

  • Ransomware attacks: devices may be encrypted or locked, disrupting care; connected systems increase exposure.

  • Firmware/software vulnerabilities: timely patching and vulnerability assessments are essential.

  • Lack of encryption: inadequate protection during transmission or storage can lead to exposure of ePHI.

  • Insider threats: misuse or leakage by authorized personnel; logging and auditing required.

  • Interoperability issues: data leakage or integrity problems when interfacing with other systems.

  • Device tampering: physical access risks and tampering with device functionality/data.

Healthcare System Review and Approval Process

  • Before deployment, ultrasound hardware and software must meet rigorous approval processes:

    • Regulatory compliance (FDA 510(k) clearance)

    • Internal policies and standards

    • Legal agreements between vendors and healthcare systems to define responsibilities

  • Purchasing considerations:

    • Verify manufacturer security processes; regular security assessments and mitigations for exposed risks

    • Request Manufacturer Disclosure Statement for Medical Device Security (MDS2) for each product; contains security/privacy inputs/outputs for intended use

  • IT review role:

    • Define integration with existing infrastructure and clinical workflows; consider modernization and retirement of older servers/databases

    • Vendors handling sensitive data (ePHI) should have certifications (ISO27001, SOC 2 Type 2, HITRUST)

  • Certifications and framework references:

    • Common certifications: ISO27001, SOC 2 Type 2, HITRUST

    • U.S. government mentions standard frameworks: NIST, ISO, PCI, HITRUST CSF; NIST provides white papers on certification benefits

  • Decision criteria:

    • Healthcare systems determine which certifications are required; SOC 2 Type 2 may suffice, but additional evidence may be requested

System Access

  • Ultrasound systems have different access methods; purpose is to restrict access to authorized users while enabling legitimate use.

  • Key principles:

    • Access control is essential for regulatory compliance (HIPAA, CCPA, GDPR) and security frameworks (NIST, CMMC, NIS, SAC in China).

    • Implement authentication, authorization, and accounting (AA) features; apply RBAC (role-based access control).

    • Consider centralized SSO to minimize passwords and simplify access management; barcode-based SSO is possible if authenticated centrally.

    • For immediate-access needs (e.g., POCUS), devices should have accounting, device hardening, and whitelisting for all off-cart communication.

    • Device hardening includes: disabling unnecessary services/ports, removing obsolete components, adhering to least privilege, applying timely security patches; application-layer hardening (input validation, encryption of data at rest/in transit); firmware/BIOS security measures (secure boot, firmware activity logging).

  • RBAC and access methodologies (Fig. 20.1 summarizes):

    • Roles defined (e.g., user, systems administrator, field service engineer) with permissions aligned to roles

    • Central user management via repositories (e.g., Active Directory) where ultrasound devices inherit credentials

    • MFA considerations for high-risk access (e.g., field service personnel)

  • Table 20.5: User access and authentication methods (summary)

    • Open access: free access without credentials (not recommended)

    • Usernames/passwords: standard credentials; strong policies advised

    • RBAC: access based on role; supports least privilege

    • SSO: single sign-on; centralizes login; reduces password burden; useful for large facilities

    • MFA: two or more authentication factors; improves security

    • Biometric authentication: fingerprint, iris/face recognition, voice; adds convenience but requires robust privacy safeguards

    • Ultrasound usage: quick access in some contexts but lower security; use alongside other controls

    • Device Software: RBAC enforcement on ultrasound systems; central management can override local credentials

    • Smart cards/tokens: physical authentication tokens; certificate-based

    • Time-based access: access restricted to specific time windows

    • Remote access: access from remote locations; requires strong controls

    • Barcode access: scans to identify user; used in handheld contexts with strong controls

    • IP whitelisting/blacklisting: restrict access by source IP; whitelisting often tied to DICOM AE titles and ports

  • Notes on POCUS environments:

    • Physical environment protection is critical to prevent casual tampering

    • Telemedicine/remote support features must be initiated from the device and terminate after sessions; remote access should be narrowly scoped to the study

  • Handheld/mobile device considerations (EMR/clinical workflow integration):

    • Mobile devices used with handheld systems should be FIPS and Common Criteria (CC) certified

    • Protect devices from being unlocked/jailbroken/rooted; security features must remain intact

    • Strong authentication methods (face, fingerprint, PIN, or combinations) should be configured

    • Ensure encryption is enabled on devices to protect data if lost or stolen

    • Consider Secure DICOM or encrypted transmission for remote transmission of patient data

    • IP whitelisting with DICOM AE title and port configuration; port non-standardization recommended to IT for optimal setup

    • Whitelisting embedded in device/manufacturer code ensures that only intended code runs

  • Overall: system access is a foundational protection mechanism and essential for investment protection in ultrasound systems

Ultrasound Workflow Solutions and Access Considerations

  • Two workflow diagrams illustrate how ultrasound devices connect and transmit data to achieve access control and improved clinical workflows:

    • LDAP/SAML for user authentication; HL7 for interfaces with EMR/PACS; DICOM for imaging data transmissions; POCUS Manager (ultrasound management system)

    • MITM attacks are a central concern; data integrity and confidentiality must be preserved

  • Security considerations for integration with PACS, ultrasound management systems, EMRs, and other networked solutions:

    • Centralized SSO capable; encrypted communications (Secure LDAP or Secure SAML)

    • DICOM standard usage for communication; DICOM AT with IP configuration that avoids standard DICOM ports when possible; coordinate with IT for optimal IP setup

    • Secure DICOM implementation based on TLS 1.21.2 or 1.31.3 for encryption in transit

    • Active Directory / LDAP / SAML-based authentication and SSO for streamlined login across systems

  • Steps in Order-based imaging workflow (Fig. 20.2):
    1) User Authentication using AD/SSO to access EMR, modalities, and PACS
    2) Ultrasound Order placed in EMR prior to image acquisition
    3) Patient Association where demographics flow to Modality Worklist
    4) Imaging Source: ultrasound device used for imaging
    5) Ultrasound Worksheet: report finalization within PACS
    6) Procedure Codes (CPT) sent to billing

  • Steps in Encounter-based imaging workflow (Fig. 20.3; EB IW with ultrasound management system):
    1) User Authentication via AD/SSO to access EMR, modalities, and ultrasound management system
    2) Patient Demographics populated from EMR to ultrasound management system
    3) Imaging Source: ultrasound device
    4) Patient Association: ultrasound device queries management system for demographics from EMR
    5) Ultrasound Worksheet: report finalized and transmitted to EMR
    6) Procedure Codes (CPT) used for billing

  • Minimum access methodologies for workflow solutions:

    • Open access should never be permitted

    • RBAC must be embedded and differentiate data vs. configuration access by role

    • Usernames/passwords with complex policies, timeouts, and MFA are required

    • SSO is preferred for enterprises with multiple ultrasound devices; supports centralized authentication, auditing, and logging; enforces complex passwords and MFA when available

  • For integration with EMR and workflow: ensure encryption and standard interfaces (LDAP/SAML, DICOM) are used; Secure DICOM preferred to mitigate MITM risks

Privacy Matters

  • Ultrasound images must be encrypted both in transit and at rest

  • At-rest encryption should use strong algorithms (e.g., AES−256AES-256, AES−192AES-192, RSA, 3DES)

  • In-transit protection should use TLS 1.21.2 or 1.31.3; avoid older TLS versions

  • Privacy compliance is central to ultrasound programs; patient data must be protected and de-identified when necessary

  • Data anonymization/de-identification: ultrasound devices should support removing or anonymizing PII from images and study records, replacing identifiers with unique identifiers for non-diagnostic use (training, exports, collaboration)

  • Global privacy laws and regulations (Table 20.6):

    • HIPAA (US)

    • CCPA (US, California)

    • CMIA (California, US)

    • PHIQUA (New York)

    • GDPR (EU) / UK GDPR (UK)

    • PIPEDA (Canada)

    • MHRA (UK) / PDPB / PDSG / POPIA and related acts in various countries (Australia, India, Germany, South Africa, etc.)

  • Privacy considerations for cross-border data sharing, training datasets, and collaboration features require anonymization and de-identification as appropriate

  • Patient data workflow must ensure consent, minimization, and secure handling across all modalities and workflow solutions

Audit Trails

  • Ultrasound devices must maintain detailed audit logs of access and actions related to ultrasound images and patient data

  • Audit trails enable monitoring, accountability, and investigations; logs can be exported to central systems (syslog, SIEM); encryption of transmitted logs recommended

Secure Image Sharing

  • Telemedicine, remote collaboration, and expert review enable sharing of images and studies beyond the local facility

  • Secure channels must be used; verify recipient identity; automatic anonymization of data from other patients when remote parties access studies

  • MITM protection is essential via authorization and encryption; ensure that remote sessions are tightly controlled and auditable

Key Recommendations: Closing Summary

  • FDA recognizes cybersecurity as a shared responsibility among stakeholders (healthcare facilities, patients, providers, manufacturers)

  • Growing connectivity and data exchange raise cybersecurity vulnerabilities; active investment in cybersecurity is essential

  • Consequences of underinvestment include privacy violations, legal liabilities, and potential operational disruption or patient safety risks

  • Balance technological advancement with cybersecurity readiness to enable scalable deployment of diagnostic ultrasound devices

Global and Regulatory Context (Key References)

  • AHA: Cybersecurity and risk management in patient safety; emphasis on culture of cybersecurity within patient safety framework

  • HIMSS: Building a Mature Medical Device Cybersecurity Program; people and process challenges; importance of holistic program

  • NIST: Certification and cybersecurity frameworks; prescriptive controls across information security programs

  • FDA: Cybersecurity in Medical Devices; quality system considerations and premarket submissions

Notable Terms and Concepts Summary

  • MB/MDM: Mobile Device Management for handheld ultrasound devices

  • MDS2: Manufacturer Disclosure Statement for Medical Device Security

  • ePHI: electronic Protected Health Information

  • HIPAA / GDPR / CCPA: major privacy/regulatory frameworks

  • DICOM / HL7 / HL7 ORU / ADT / CPT: standard data formats and codes in imaging workflows

  • TLS 1.2 / TLS 1.3: secure transport protocols; TLS versions determine handshake strength

  • MITM: Man-in-the-Middle attacks; mitigation via TLS, certificate validation, and secure channel establishment

  • RBAC / SSO / MFA / Biometrics / Smart Cards: layered access control mechanisms

  • Secure DICOM: TLS-protected DICOM communication

  • POCUS Manager: ultrasound workflow management system for data orchestration

  • PII: Personally Identifiable Information

  • AES-256 / AES-192 / RSA / 3DES: encryption standards for data at rest

  • AE title (DICOM): DICOM network identification for devices/services

  • NIST / ISO27001 / SOC 2 Type 2 / HITRUST: cybersecurity/privacy certifications and frameworks

Connections to Foundational Principles and Real-World Relevance

  • Security-by-design: embed security controls in devices and software from development through deployment (device hardening, cryptography, access control)

  • Defense-in-depth: combine access control, encryption, auditing, network segmentation, and secure telemedicine practices

  • Data privacy by design: anonymization, de-identification, and consent management in data sharing and training datasets

  • Regulatory alignment: ensure compliance with HIPAA, GDPR/UK GDPR, CCPA, and other regional laws; leverage recognized standards and certifications

  • Operational resilience: robust cybersecurity reduces risk of downtime, protects patient safety, and maintains trust in healthcare systems

Formulas and Notable Notations

  • Encryption standards (examples):

    • Data at rest: AES−256,extAES−192,RSA,3DESAES-256, ext{ AES-192}, RSA, 3DES

    • Data in transit: TLSext−1.2,extTLS−1.3TLS ext{-}1.2, ext{ TLS-}1.3

  • TLS and encryption references are used throughout for securing data in transit; AES and RSA refer to encryption schemas used for data at rest and in certain cryptosystems

End of notes