CYBERSECURITY IN HEALTHCARE

Collaborating across the supply chain

Author

Anura Fernando

More about Author

Anura Fernando is the global head of medical device security at UL Solutions. He has twenty-five years of experience at UL Solutions with safety critical software and control systems certification and safety research across multiple application domains. He has contributed to research and industry publications in Predictive Modeling and Risk analysis, cybersecurity, Systems of Systems, Health IT, and medical device safety and security. Anura has participated in project collaboration with numerous Fortune 500 companies and has contributed to the development of several domestic and international consensus standards for software, security, and functional safety. His current focus looks at the intersection of cybersecurity and safe medical device interoperability.

Cybersecurity is a shared responsibility — this sentiment has resounded within healthcare circles around the world over the past decade. But what does it really mean for different groups to share the responsibility for cybersecurity in healthcare?
If you represent a healthcare delivery organisation (HDO), it might mean that you understand your organisation can’t fully control the cybersecurity posture of the devices that you acquire and plan to deploy within your hospital IT networks.
If you’re a medical device manufacturer, it might mean that you need to make certain assumptions about the network environment into which your product could be placed and then design the product accordingly.

How can different perspectives be brought together?

One common approach is for the HDO to try to get the device manufacturers to make all technical details about the product available to them.

There are certainly some pros to this approach, such as:

The opportunity to have fine-grained control over device deployment in a hospital IT network based on product design details
The ability to compensate for residual risk remaining at the endpoint (medical device), based on a detailed understanding of technical debt and risk at the product level
The potential to reduce the security burden on hospital network infrastructure by relying on product level security controls.

However, there are also some cons, such as:

Device manufacturers may not be comfortable releasing their sensitive design details and other intellectual property (IP) outside of the security controls of their organisation. The compromise of such IP could be crippling to the business of a medical device manufacturer if it leads to industrial espionage or low-priced counterfeit products

Device patches generally need to be validated by the manufacturers to maintain safety, effectiveness and security before being deployed within a clinical network

HDOs may not always have the technical expertise in-house to fully utilize such information, even if it is freely shared.

Another approach is to structure hospital IT networks in a way that allows for the safe and secure integration of ‘untrusted’ devices. This approach offers some pros, including:

A consistent baseline of security capabilities based on network architecture alone
A single point of control when dealing with security events or new threats
The possibility to treat vetted device-level security controls as “backup” controls in case of network compromise, as appropriate.

However, just like with the device-centric approach to security, the network-centric (‘zero trust’) approach also has cons, such as:

The need to hire and maintain in-demand and difficult-to-find cybersecurity experts
The potentially high initial investment needed for tools for intrusion detection and protection, vulnerability scanning, asset management, etc.
The reduced flexibility when network reconfiguration is needed.

What is the best way to move forward with security planning?

A hybrid approach, leveraging both the network security posture and product security, can be advantageous in providing the best of both worlds. To overcome some of the challenges of each, using third-party attestations or certifications to technical product security standards in conjunction with standards’ compliant, defensively designed hospital IT network architectures can be an ideal middle ground.

Reputable third parties that operate testing and certification programs are typically accredited to and conform to standards such as ISO 17065 – “Conformity assessment — Requirements for bodies certifying products, processes and services”, ISO 17025 – “Testing and calibration laboratories,” and ISO 17024 – “Conformity assessment — General requirements for bodies operating certification of persons.” Such accreditations help demonstrate the competency, consistency, and impartiality of the third-party and a baseline of independently assessed trustworthiness or quality when leveraging the testing, inspection and certification services of such a third-party.

One significant benefit of having an independent third party as part of this ecosystem is that sensitive information can be shared by different supply chain stakeholders with the third party while maintaining the confidence that such information will be handled and maintained as confidential, remaining subject to strong technical and procedural security controls. This level of rigor in handling sensitive data allows medical device manufacturers to share very detailed information about product design with an accredited third- party while also allowing healthcare delivery organisations to share information such as personally identifiable information (PII) and protected health information (PHI) with the same third party as needed for system evaluation. Thus trusted third-parties can serve as a technology transfer and claim verification bridge between supply chain stakeholders.

Third-party testing, inspection and certification organisations are also required, per their own accreditations, to establish and maintain the necessary technical competencies and properly calibrated and managed equipment to effectively and consistently deliver any services (including cybersecurity) that they offer. The existence of such third-parties can help medical device manufacturers and HDOs overcome the workforce shortages in areas like cybersecurity that we see today. Having such quality attributes can also make the delivery of support services measurable, repeatable and reproducible. Additionally, this means that supply chain relationships can establish metrics for continuous improvement. There can be standardisation of practices and procedures, and when problems or anomalies arise, they can be tracked and reproduced to support remediation.

What types of issues can standards address?

For example, when following the ANSI/CAN/UL 2900 cybersecurity standards, many security concerns can be addressed through compliance. These include:

Establishing that manufacturers have characterised and documented the technologies used in their products that could constitute an ‘attack’ surface
Requiring threat modeling based on intended use and relative exposure
Demonstrating the effective implementation of security controls protecting both sensitive data (e.g., PII or PHI) and assets, such as command and control data
Providing objective evidence that software weaknesses and vulnerabilities have been appropriately dispositioned and further verified via penetration testing
Promoting defensive design (e.g., defense-in-depth, partitioning, etc.)
Helping ensure system robustness (e.g., fuzz testing/malformed input testing)
Supporting monitoring of security events
Addressing logging of security events
Defining approach for managing security logs
Covering updating of software to address safety, essential performance and security issues
Requiring the handling of failures in the software update process (e.g., roll-back).
Controlling component purchasing
Helping with management of sensitive data (including passwords and cryptographic keys)
Facilitating remote product management
Examining decommissioning (e.g., purging of PII/PHI).

As a cybersecurity leader in my organisation, what should I do next?

There are many options when it comes to standards, certifications, third-party cybersecurity service providers, implementation strategies, testing approaches, etc. But some basic concepts need to be applied no matter what options you choose:

Identify an accountable top management representative. If no one is accountable, tasks are less likely to get done, so this is a good first step
Make security part of the company culture. Security is often opposed to usability. This tends to contribute to a common perception that cybersecurity is an added cost and complication, sometimes an annoyance, and in some cases, even a hazard. For example, what could happen if you had to enter a 13-character password before being allowed to use an Automated External Defibrillator (AED)?
Establish cybersecurity policies and procedures as part of a quality management system
Perform pre- and post-deployment cybersecurity risk assessments, which include having cybersecurity as part of the procurement process and the decommissioning or service termination process. There are many aspects to cover between those two lifecycle endpoints, such as threat modeling, determination of necessary security controls, verification and validation, coordinated vulnerability disclosure, problem resolution, change management, etc.

Many best practice guidelines and standards are available in the healthcare ecosystem that can help. All UL Standards are freely available to the public online, and all NIST standards are also available for free. Organisations like the Healthcare Sector Coordinating Council provide free tools and resources to help improve the global cybersecurity posture of critical healthcare infrastructure.

--Issue 61--