Vertical Summary - Security in Medical Facilities

Regulations in the Medical space require medical facilities to secure communications and protect patient data. As more facilities utilize connected devices and remote work to transmit patient data, it is important to implement proper mechanisms to encrypt data for both devices and users.

Medical devices and users continue to be a significant target for cybersecurity threats. Some examples:

1. FDA Alerts: The FDA has issued multiple alerts regarding cybersecurity vulnerabilities in medical devices. For instance, the Medtronic MiniMed 600 Series Insulin Pump System was found to have a potential cybersecurity risk that could allow unauthorized access, potentially compromising patient safety by altering insulin delivery. Similarly, vulnerabilities were identified in Illumina's NextSeq sequencing instruments and the Axeda agent used in various medical devices, which could allow full system access to attackers.

2. Surge in Vulnerabilities: A joint research report by Health-ISAC, Finite State, and Securin discovered nearly 1,000 vulnerabilities in 966 medical products and devices in 2023, representing a 59% increase from the previous year. This includes 43 vulnerabilities classified as remote code execution (RCE) or privilege escalation (PE) exploits, making them particularly attractive to hackers.

3. FBI Warnings: The FBI has warned about the growing number of vulnerabilities in unpatched medical devices running outdated software. These insecure devices pose risks to patient safety, data confidentiality, and operational functionality within healthcare facilities.

4. Impact of Cyberattacks: Cyberattacks on healthcare providers are increasingly common, with the average healthcare delivery organization (HDO) experiencing 43 attacks in the past year. These attacks result in significant operational and financial burdens, including increased patient mortality and extended hospital stays.

Regulatory Framework

Typical regulations influencing hospital and medical facility network communications include:

• HIPPA (Health Insurance Portability and Accountability Act):

  • For security, this regulation requires medical facilities to implement technical safeguards to protect electronically transmitted health information. This includes ensuring data integrity, confidentiality, and availability.

• HITRUST CSF (Health Information Trust Alliance Common Security Framework):

  • This framework includes specific controls for providing secure and authenticated network access.

• NIST (National Institute of Standards and Technology) Guidelines:

  • NIST SP 800 - 53 provides a framework for managing information security risk. It recommends implementing strong authentication and encryption mechanisms.

  • NIST SP 800 - 66 provides specific recommendations for securing health information and aligns with HIPPA requirements. This also includes securing network communications.

• GDPR (General Data Protection Regulation):

  • A European Union (EU) specific directive. GDPR requires both organizational and technical measures to protect the security of personal data. Authentication and encryption can be a part of the measures utilized to protect data.

• ISO/IEC 27001:

  • This international standard applies to information security management systems (ISMS). It requires implementing access to controls and encryption to protect assets.

Securing to Regulatory Standards

The common themes in all of the above standards are authentication and encryption. By utilizing Transport Layer Security (TLS) in all device communications, any user data between a device and a back office system is encrypted during transmission.

However, just securing the data in transit is not enough. Medical facilities must also assure valid devices and users are the only ones allowed to connect to the system. Mechanisms such as mutual transport layer security (mTLS) and Card Verifiable Certificates (CVC) are leveraged to prevent invalid devices and users from accessing the network and systems in medical facilities.

Generating trust with PKI

Public Key Infrastructure (PKI) is a set of Policies and Procedures and Software that can securely provision identities. The policies and procedures set up the rules for identity vetting. Creating a strong enough identity vetting procedure allows us to trust the authority approving an identity request. A part of this trust model and processes is leveraging a robust PKI software.

EJBCA (Enterprise Java Beans Certificate Authority) by Keyfactor is one such example. EJBCA Enterprise Edition’s PKI software solution incorporates enhanced features and enterprise-grade capabilities. It offers high availability, enhanced security modules, multiple/hybrid deployment options, and dedicated support, ideal for large-scale deployments. The Enterprise Edition provides compliance with industry standards and regulations, making it ideal for organizations in regulated sectors. Additionally, it includes advanced management tools and integration options that cater to the complex requirements of large enterprises. With its robust performance, scalability, and dedicated support services, EJBCA Enterprise Edition is an essential part of a comprehensive and reliable PKI solution tailored for mission-critical environments.

PKI leverages asymmetric cryptography. In asymmetric cryptography, there are two mathematical keys generated. There is a private key and a public key. Knowing the private key allows the generation of the public key. However, having the public key does not allow derivation of the private key. Therefore, protecting the private key is of utmost import.

A robust solution like EJBCA integrates with a Hardware Security Module (HSM) to protect private keys. HSMs are specially designed pieces of hardware that perform all cryptographic operations (key generation, signing, encryption, hashing, etc.) inside of them. The HSMs are also designed so that you cannot extract the private keys without special procedures.

Preventing outages or unplanned downtime

While not a part of a security posture per se, the prevention of unintended down time for instruments and users is critical for a medical facilities bottom line. Planned downtime is something that is managed and quantifiable. Unplanned downtime happens during critical times & requires troubleshooting before determining root cause and applying remediation.

A good PKI places limits on device and user certificate lifetimes (e.g., 90 or 30 days). Therefore, knowing when device and user certificates will expire is critical in preventing any unplanned downtime associated with identities. Modern RFID/NFC cards and medical equipment can leverage middleware for this purpose. Middleware is device (card or medical) control plane software to configure and manage devices. In the mobile domain these are known as MDM (mobile device management) solutions. Similar solutions exist in the medical device/badge arena.

Some solutions allow for rotating certificates automatically. A new keypair is generated & an associated certificate is signed by the PKI. Of particular note, a PKI is a passive thing. It responds to requests for certificates, follows the vetting process set up, and issues a certificate accordingly. Devices and Software that can request certificates, can interface with EJBCA using common protocols.

However, some control plane software and older devices in general, do not have the ability to manage certificates. Keyfactor has a software Command for IoT that was designed to assist in these cases. For devices that utilize control plane software, Command for IoT can integrate with this software to control the re-enrollment rules. For devices that don’t have certificate management capabilities, Command for IoT can generate reporting and automate ticket creation into software like Service Now. The ticket can be something like “EKG Cart xzy has a certificate that is expiring within the next 30 days, please renew.”

In all cases (control planes that can rotate certificates and use cases without), Command for IoT can organize certificates into buckets called collections. A collection could be “user badges”, “EKG carts”, “Manually rotated certificates”, etc. Rules for when to rotate the keys and certificates is set per collection. How to rotate the certificates is also set per collection. So, for control plane software that already rotates certificates, Command for IoT becomes a reporting tool. For devices or software without this ability, Command for IoT becomes an automation tool - either direct automation or automating ticket generation in IT or Maintenance software.

Conclusion

Creating policies and procedures that leverage state-of-the-art PKI software along with state of the art cryptography hardware support a medical facilities security posture. That security posture, when properly sponsored, documented, maintained, and audited can be used to support the argument that a medical facility is compliant to any cybersecurity regulation.

Keyfactor’s EJBCA software streamlines implementing these policies and procedures with a robust set of configurations, scalability, audit logging, security mechanisms, and hardware integrations. This makes EJBCA a perfect solution for small to large medical facilities.

When it comes to unplanned downtime prevention, adding Keyfactor’s Command for IoT brings additional functionality that goes beyond a PKI. Integrations into ticketing systems, reporting, control plane integrations and the like are available to prevent outages. If a control plane integration does not yet exist, Keyfactor’s Integrations team is on the case.

Overall, medical facilities need to meet existing laws and regulations when it comes to cybersecurity and patient confidentiality. A robust solution relies on structured policies and procedures. Keyfactor has partnered with many Fortune 100 companies to do this in the Enterprise space, and has products to assist the requirements in the Medical Facility space, too.