Contracting is a good place to shore up defenses against cyber criminals
Had you been at the big healthcare technology expo – HIMSS 2019 – this winter, you would have noticed a few things. For example, about 400 people attended the all-day Cybersecurity Forum on Monday, Feb. 11. You would have seen that the Cybersecurity Command Center – where vendors of technologies designed to protect your organization against cyber adversaries – was much bigger than last year’s. And you would have had your pick of about 70 sessions on cybersecurity, some with unsettling titles, including:
- “Dealing with the tsunami of unmanaged devices.”
- “Levers of human deception.”
- “Buried under an avalanche of medical device special snow flakes.”
- “I will hack your laptop in 30 seconds.”
“We’re seeing more awareness and resources going to the Internet of Things,” says Kevin McDonald, director of clinical information security for Mayo Clinic (and presenter of the “avalanche” session at HIMSS 2019). Medical devices are at the center of it, which means supply chain executives are too.
In addition to his work at Mayo, McDonald is co-chair of the Joint Cybersecurity Working Group, a standing group of the Healthcare and Public Health Sector Coordinating Council. In January 2019, the group published its “Medical Device and Health IT Joint Security Plan.”
No silver bullets
Technology no longer exists in a silo, says McDonald. Rather, it interacts intimately with clinical processes – often multiple processes. Think of infusion pumps, ventilators or ICU telemetry. That’s a lot of technology, and a lot of devices and equipment.
“There are no shortcuts [to achieving cybersecurity],” he says. “This is really one of those people, processes and technology things,” which demands ongoing cooperation among those in contracting, IT, biomed and the clinical staff, not to mention vendors.
“Integrating cybersecurity into an organization necessitates organizational and process changes that come with considerable time and monetary investments,” the Working Group concluded. Its Joint Security Plan is intended to provide a framework for making necessary organizational and process-related changes.
It’s true that some software firms have developed tools to help providers identify the devices and equipment that present risks. But these tools aren’t silver bullets, says McDonald.
“The main thing that the software does is to listen to the communications on your network and, from the messages the devices send, infer what the device is. Some of the more mature companies that are doing this can have a pretty high identification rate based upon what they have ‘profiled’ in the past, but specialized devices may come back with no or limited information.
“These are good tools and serve a purpose, but they are limited by what is in the network messages sent and the communication patterns,” he continues. “The rest of the value comes from how the company can augment it with additional data from other sources.”
Your priorities
Nor will such software prioritize devices based upon risk, he adds. “Risk needs to be based upon the inherent risk of the device, what additional compensating controls you can put in place, the threats the hospital may have, and what the patient impact of a vulnerability would be.”
No facility has the resources to thoroughly assess and monitor the cybersecurity risk associated with every piece of equipment and every device in its possession. Only by developing a robust prioritization program can inroads be made. And common sense can help, says McDonald. For example, a piece of equipment that produces ionizing radiation, which has the potential to harm patients, would be a higher priority than, say, an automated blood pressure cuff.
Resources are available to help with prioritizing a facility’s cybersecurity activity. One example is the Australian Cyber Security Centre, which is the Australian government’s lead on national cybersecurity. It has identified what it calls the “Essential Eight,” that is, eight activities which, if implemented, can eliminate a large portion of a facility’s cybersecurity risk. These “Essential Eight” can be implemented even by smaller facilities:
- Application whitelisting, to control the execution of unauthorized software.
- Patching applications, to remediate known security vulnerabilities.
- Configuring Microsoft Office macro settings, to block untrusted macros.
- Application hardening, to protect against vulnerable functionality.
- Restricting administrative privileges, to limit powerful access to systems.
- Patching operating systems, to remediate known security vulnerabilities.
- Multifactor authentication, to protect against risky activities.
- Daily backups, to maintain the availability of critical data.
Other examples include the work done by the Center for Internet Security (https://www.cisecurity.org) and the Healthcare Sector Coordinating Council (https://healthsectorcouncil.org).
Contracting
A strong, well-thought-out contract with medical device and equipment vendors can be an important, early line of defense against cyber criminals.
Monitoring cybersecurity “should be built into your purchasing process,” says McDonald. It needs to be another bullet point in the process, just as an RFP. “Make sure the tollgates or controls are in place. That’s the only way I’ve seen it work well.
“It doesn’t work with individual heroics.”
The Joint Security Plan urges vendors of devices and equipment to create and distribute to customers what it refers to as “customer security documentation,” which describes all pertinent security information related to their products, including a software “bill of materials,” data flow diagrams and patch management plans.
“Customers … are responsible for processing vendor-provided customer security documentation to complete questionnaires, agreements, and/or risk assessments during product procurement phases, and incorporating results into a risk management platform as well as an asset management platform for ongoing management,” according to the authors of the Plan.
When researching device and equipment purchases, providers can narrow down their cybersecurity-related questions using various standards that are available, including that from the ISO, says McDonald.
Often-used standards are ISO 80001(Application of risk management for IT-networks incorporating medical devices, https://www.iso.org/standard/44863.html) and AAMI TIR 57 from the American National Standards Institute (https://www.aami.org/productspublications/ProductDetail.aspx?ItemNumber=3729). The latter standard was developed by the Association for the Advancement of Medical Instrumentation and is called Principles for Medical Device Security.
“It’s doable, but it can’t be fit it in over someone’s lunchtime,” says McDonald. “The way to make it work is to make someone responsible for the outcomes.” At Mayo Clinic, these are the people working in McDonald’s areas of information security and specialized areas in clinical equipment.
“You really need to fit this into your institution’s processes.”
How about that legacy equipment?
Addressing the cybersecurity of medical devices and equipment at the time of acquisition is one thing. But monitoring and minimizing the risks over the life of that equipment is another. In its “Medical Device and Health IT Joint Security Plan,” published in January 2019, the Joint Cybersecurity Working Group summed up the dilemma:
The relatively short lifespan for operating systems and other relevant platforms such as commercial off-the-shelf software is inherently misaligned in health care, as medical devices and EHRs may be utilized for 10, 15, 20, or more years. This misalignment may occur for a variety of reasons. Hospitals operate on thin budgets and cannot replace capital equipment like MRIs as quickly as new operating systems are released. Product vendors have a product development lifecycle that may take several years, and they may start development using one operating system and by the time the product comes to market, newer operating systems may be available. Creative ways of addressing the aforementioned challenge areas may be found by engaging key clinical and cybersecurity stakeholders, including software vendors.
Ask your vendor
Vendors of medical devices and equipment should provide customers with security documentation to enable risk assessments, to identify security controls, and to better protect their systems. The following are examples of the types of information that may be included in documentation of security for medical devices or health IT:
- Product description. (Basic description of function.)
- Hardware specifications. (List of hardware components and specs.)
- Operating systems. (List of hardware operating systems and versions.)
- Third-party software. (Also referred to as a “bill of materials,” includes a list of third-party software and version numbers. Should be provided upon purchase and after significant software or hardware upgrades.)
- Network ports and services.
- Sensitive information and data transmitted (including personally identifiable information and protected health information.)
- Sensitive information and data stored (including personally identifiable information and protected health information.)
- Network and data flow diagram (showing system components, types of connectivity, types of data in transit and rest, and how these are secured).
- Malware protection. (Anti-malware measures available.)
- Patch management. (Describes and recommends method by which vendor maintains, provides and deploys patch updates.)
- Authentication and authorization. (Describes and recommends the controls that customers have with user’s authenticating and granting permissions to features and functionality, including the ability to disable user accounts.)
- Network Controls. (Firewall rules, browser Internet access restrictions, etc.)
- (Describes and recommends where and how encryption is applied on the system.)
- Audit logging. (Describes audit logging process, who has access to audit logs, etc.)
- Remote connectivity (e.g., ports, protocols, URLs).
- Service handling. (Describes routine maintenance performed by service personnel, including security policies and procedures they follow.)
- End-of-life and end-of-support. (Describes when product will no longer be sold, updated and supported.)
- Secure coding standards.
- System hardening standards.
- Risk summary. (Summary of risks found within a penetration test, remediation report, or other topics and compensating controls that correspond to additional risks outlined in the product security white paper.)
Source: Medical Device and Health IT Joint Security Plan, Healthcare & Public Health Sector Coordinating Councils, January 2019 (https://healthsectorcouncil.org/wp-content/uploads/2019/01/HSCC-MEDTECH-JSP-v1.pdf)