By Jason Winkler & Rob Dobson
Whether it be a patient monitoring device or a surgical robot; any connected device is a potential entry point for a malicious cyber-attack. With IoT devices reaching 75 billion by 2025, IoMT (~38.9B) growing at 25.6% CAGR , yesterday’s status quo for enterprise protection will not be enough to protect and prevent cyber-attacks at IoT scale. Mainly because of the device scale and the headless anatomy of these devices limits the effectiveness of the detect and respond protocols of the past.
Combine this with the statistics of 45 million individuals being affected by healthcare breaches in 2021 alone and the average cost of per breach of $9.23M per incident the healthcare industry must address medical device security head on and from multiple fronts.
The FDA has provided premarket guidelines for device security in 2014 (foundational- 9 pages) and 2018 (~50 pages). And most recently (April, 8 2022) they updated their draft guidance for public comment.
The FDA introduces newer terms such as “device lifecycle”, and “SBOM (Software Bill of Materials)” signaling the need for device OEMs to factor in not only authentication, authorization but decommission, recommission of devices in the market, and continuous checking, validating, and updating SBOMs. “A lack of cybersecurity information, such as information necessary to integrate the device into the use environment, as well as information needed by users to maintain the device’s cybersecurity over the device lifecycle, has the potential to affect the safety and effectiveness of a device,” the guidance states. “In order to address these concerns, it is important for device users to have access to information pertaining to the device’s cybersecurity controls, potential risks, and other relevant information.”
The latest iteration however adds to that by asking sponsors to think about cybersecurity in the context of the agency’s quality system regulation (QSR) and consider using a secure product development framework (SPDF) to achieve that goal.
“An SPDF encompasses all aspects of a product’s lifecycle, including development, release, support, and decommission,” the draft guidance states. “Additionally, using SPDF processes during device design may prevent the need to re-engineer the device when connectivity-based features are added after marketing and distribution, or when vulnerabilities resulting in uncontrolled risks are discovered.”
Med Device OEMs need a bifurcated, but synchronous approach to device and data security (Greenfield vs. Brownfield strategy) and the ability to manage all their devices from a singular platform. Design and enforce cyber-security policies by device groups and automate device certificate lifecycles. To meet the Executive Order for SBOMs, OEMs and their HDO customers must also consider enabling continuous verification of device SBOMs and automate the quarantining and blacklisting of device based on these validations.
When it comes to new medical devices (greenfield), OEMs need to lead product design with a secure first “zero trust” mindset. Equally OEMs have to consider the wider security architecture, encompassing cloud applications, communications, access control and more. A secure by design approach is a must and clearly vendors need to consider how best to secure devices from chip to cloud. Some fundamental considerations need to be taken with regard to:
1) What is the security of the MCU, do I need a TPM/SE
2) What kind of root of trust is needed for our device
3) What kind of software, agents or libraries should be either connected downstream.
4) Will the device/robot operate in an offline or on-line environment
5) What are the data privacy and confidentially regulations and are there privileged access requirements
6) Is granular control of encryption of data at rest & in motion important or mandated
7) What security controls does the cloud application have in place
8) How to manage software updates to the device securely
9) Where will I host my cloud apps and how will I secure them?
10) What’s the access control for the devices and services?
11) What identity model do I need to support?
Brownfield devices already deployed have similar considerations to the aforementioned but often different constraints. It’s important for these types of devices to consider what vendors can do to improve the security posture on these devices. Clearly some discovery is needed to understand:
We needn’t dismiss improving security on brownfield devices, as there are potential avenues to pursue which can help here.
What is abundantly clear is that OEMs need to automate their IoT device identities, certificate management, secure updates, data encryption and can manage all device types from a singular dashboard.
For more information and solutions to address some of device use cases please reach out to jason.winkler@deviceauthority.com
Mirai, the first IoT botnet which was discovered in 2016 took down popular websites and services including Twitter, Airbnb and Netflix. Since then we were introduced to more advanced versions of Mirai like Persirai, Reaper, Satori and Okiru.
As predicted, botnet enabled malware attacks continue. The latest discovered is Okiru (meaning Wake Up in Japanese). Okiru has the potential to reach BILLIONS of Internet of Things (IoT) devices due to its implementation! Okiru’s release specifically highlights the exposure of unsecure IoT devices again and continues to show the sophistication of hackers in utilizing IoT connected devices in orchestrating significant attacks.
