Group’s Guidance Helps Healthcare Entities Meet Device Makers’ Demands For Security
By Marianne Kolbasuk McGee (HealthInfoSec)
New guidance by the Healthcare and Public Health Sector Coordinating Council provides healthcare delivery organizations and vendors with recommendations for contract language pertaining to cybersecurity in procurements of medical device products and related services.
In a statement issued on y, HSCC recentlysays the purpose of the new Model Contract-Language for Medtech Cybersecurity is to offer “a reference for shared cooperation and coordination” between healthcare delivery organizations and medical device makers regarding the security, compliance, management, operation and services of medical devices, as well as vendor-managed medical device products and connections.
HSCC says the guidance is intended to help minimize security risks and ensure the confidentiality, integrity and availability of healthcare technologies, infrastructures and information used by healthcare entities. The document serves “as a scalable template for large, medium and small organizations,” HSCC says.
“This Model Contract Language articulates adequate security of healthcare delivery organization information being stored, transferred, or accessed and provides that all network access, medical devices, services, and solutions satisfy the mission, security, and compliance requirements of the HDO,” HSCC says.
HSCC is a private-sector critical infrastructure advisory council to the Department of Health and Human Services. The coalition’s cybersecurity working group represents more than 300 healthcare sector organizations, including patient care delivery networks, health plans, laboratories and health IT vendors, as well as several federal and state government agencies.
Guidance Details
The topics covered by the guidance, for inclusion in procurement contracts, include:
Security requirements that should apply to all customer locations, supplier infrastructure and subcontractors;
Assurances that suppliers support a program for pre-market and post-market penetration and vulnerability testing and maintain awareness of the Open Web Application Security Project;
Demonstration of accountability that suppliers validate security patches of their software and third-party software used in their products;
Best practices for storage, availability, backup and handling of data and logs, including at the time of product disposal.
The guidance also details recommended security controls to include in procurement contracts for medical devices. Those include:
• Network controls;
• Physical security;
• Anti-malware;
• Auditing and logging;
• Intrusion detection;
• Data encryption;
• Access management;
• Security patching;
• Malicious code protection;
• Privilege escalation;
• Document reference;
• Remote access.
The Model Contract-Language for Medtech Cybersecurity document also says healthcare delivery organizations’ contracts should state that medical device makers provide a complete software bill of materials and that the minimum elements of the SBOM contain specifics as defined by the Food and Drug Administration or other industry guidance, standard or regulation.
A ‘Place to Start’
Executive director for cybersecurity at HSCC, Greg Garcia tells Information Security Media Group that the contract clause examples contained in the guidance recommendations are voluntary because it is “model language.”
“Organizations are encouraged to use the model language and modify it as appropriate to the negotiating parties, but the intent is to give HDOs and MDMs a ‘pre-negotiated’ place to start,” he says.
“One of the ongoing issues in healthcare cybersecurity has been differing expectations between healthcare delivery organizations and medical device manufacturers about responsibility and accountability for cybersecurity.”
Garcia says, “Misunderstandings often occur because of unclear or variable terms and conditions in contracts.” The Model Contract-Language, he says, will “bring more uniformity to cybersecurity contract language in order to improve clarity and reduce the time, cost and confusion associated with contract negotiations.”
The guidance took two years to draft, Garcia says, and was developed by an HSCC task group made up of individuals representing a cross-sector coalition of healthcare delivery organizations, medical device makers and group purchasing organizations, including Mayo Clinic, Siemens Healthineers and Premier Inc.
Raising the Bar
Senior privacy and security consultant at consultancy tw-Security, Susan Lucci says that the guidance could be useful for both healthcare delivery organizations and medical device makers.
“Any additional security protocols that could be implemented ahead of development and production of medical devices would be helpful to prevent protected health information loss if a system is breached,” she says.
Lucci says medical device companies can update their practices to reflect healthcare’s more stringent security practices. “Model contract language will help empower healthcare organizations and medical device manufacturers to demonstrate a higher standard of security protections with its devices,” she says.
The guidance could be helpful to any organization acquiring and using medical devices and raises the overall cybersecurity bar for those products, says former healthcare CIO David Finn, vice president of the College of Healthcare Information Management Executives and its Association for Executives in Healthcare Information Management, a healthcare CISO professional organization.
“It really begins to standardize and send a message to medical device manufacturers – hardware and software – that the sector will not accept products that do not align and comply with known best practices for security, management, operations, compliance and services,” he says.
Finn says the “common, standard terminology” in the guidance will improve communication among and between care delivery organizations, purchasing organizations, service outsourcers and the device makers. “Communications and clarity are the first step to responsibility and accountability in the security space,” he says.
Finn says SBOMs should be a standard requirement in contracts between delivery organizations and manufacturers, and not just for medical devices.
“We learned from the Log4j vulnerability late last year that embedded software can bite us in many ways. Medical devices perhaps have the highest risk as they may be directly connected to the patient and be directly involved in diagnostics or treatment.
“But embedded open-source software is everywhere, and you cannot protect against those vulnerabilities if you do not know you have them,” he says.
Recent Medical Device Flaw Findings
The new HSCC guidance comes as some security researchers and vendors this week disclosed recent findings about vulnerabilities in certain medical device products.
That includes researchers at cybersecurity firm Palo Alto’s Unit 42 stating in a new report that 75 per cent of the 200,000 smart infusion pump networks they scanned contained known security gaps. Also, medical device maker Becton Dickinson on Thursday issued two security vulnerability bulletins about the use of hard-coded credentials in certain products. That includes certain BD Pyxis medication management products and BD Viper LT, a tabletop analyzer used for molecular diagnostic testing.
BD says that the hard-coded credentials are not used directly by customers or end users to access these systems. For the vulnerability to be exploited, an unauthorized user would need to gain access to the hard-coded credentials, infiltrate the facility’s network and/or gain access to individual devices and bypass additional security control, BD says. There have been no reports of this vulnerability being exploited in a clinical setting, it adds.
The BD vulnerabilities in affected BD Pyxis products and BD Viper LT are also the subject of two alerts issued on Thursday by the Cybersecurity and Infrastructure Security Agency.
CISA says exploitation of the hard-coded credential vulnerability in affected Pyxis products could allow an attacker to gain access to electronic protected health information or other sensitive information.
Exploitation of the Viper LT vulnerability could allow an attacker to access, modify or delete sensitive information, CISA says.https://www.databreachtoday.com
