Securing medical IoT layer by layer
Cloud and apps
At the top layer, an IoHT cloud typically stores and analyses data sent from connected devices while also managing certain application parameters and access permissions. Without adequate cloud security, hackers could steal large volumes of personal data or disrupt proper functioning of IoHT platforms where health insights and care decisions are translated to providers and patients. They could also work backwards from the cloud to assume control over devices.
Effective security at the cloud level requires two actions on the part of healthcare organisations’ security teams: Data at rest in cloud databases and data transmitted out of the cloud must be encrypted. Going the other way, devices or users (doctors, patients, customer support teams, etc.) accessing cloud apps or data must be verified with strong authentication procedures.
Encryption in general is relatively accessible for any organisation today. Cloud service providers (CSP) offer encryption services of varying strengths, depending on price points. IT administrators can tap their CSP to encrypt only data at rest, just data in transit, both or neither – though the latter option is definitely not recommended.
Devices, gateways and apps may also feature their own encryption capabilities, so to keep costs and complexity in check, security teams will want to assess the ground cover provided by encryption at other parts of the IoHT stack before deciding on cloud encryption tools.
Where encryption protects this complex infrastructure of apps, devices, users and data from theft or malicious access, strong authentication procedures are needed to prevent fraudulent access or accidental data leakage from the cloud and the IoHT systems it supports. Organisations can simplify authentication security across the cloud, apps and devices from multiple vendors by instituting their own public key infrastructure (PKI) for creating, distributing and verifying digital signatures.
These signatures are generated via cryptographic processes, so each signature is unique. To limit energy costs and better protect the decryption key used to verify digital signatures, PKI processes are best carried out in dedicated, protected and optimised processing enclaves often called hardware security modules (HSMs). Despite the name, HSMs are available in virtual form (“as a Service”), too.
Once created, keys issued to devices or apps need to be stored in a tamper-resistant way –such that any unauthorised attempt to change or copy a key will make it invalid – so devices and apps can be trusted as authorised pieces of the IoHT stack when users log into cloud networks, record or retrieve data from the cloud.
Together, encryption and digital signature authentication controls help ensure that only authorised people are seeing information about a certain case. They will also secure against data manipulation that could damage networks or physically harm people, and will prevent data theft by “eavesdropping” hackers.
Securing the cloud helps ensure only authorized users and devices can access medical data or make changes to the databases that power IoHT apps. Between the cloud and devices often sit gateways, and this middle section of the IoHT stack has an important role to play as a mediator for communications between devices and the cloud.
Again, strong access controls are important at this level. Gateways like routers or even mobile devices (like tablets) that act as a bridge between IoHT devices and the cloud must also implement strong authentication controls to prevent unauthorized access. In addition to protection of the gateway itself via passwords or biometric locks, it would be valuable to implement a PKI check at the gateway level too. That would allow, say, a router to verify the authenticity of a device’s cryptographic key, and only then connect the device to the cloud where another key verification would be performed.
Moving past access control, gateways may be the best environment in which medical data itself can be securely packaged for transmission. Medical sensors often can’t provide enough processing power for advanced encryption, leaving data vulnerable as it’s sent to the cloud. Healthcare IT professionals can seek out specialised gateways to add an encryption step between devices in their local network and the cloud.
Devices and Users
At the edge of today’s IoHT stack, devices and users present real challenges to secure management. There are dozens, even hundreds of different types of IoHT devices and each device may be designed to a different level of security. On top of great variety in device security, it’s become very clear in recent years that users’ security habits vary greatly from person to person.
The goal for healthcare organisations is to keep devices useful for patients while making them useless for hackers. That means step one in securing IoHT endpoints is locking down the “easy” attack vectors by encrypting device IDs; avoiding default passwords and keeping devices updated; and maintaining secure network connectivity, whether via cellular or shortrange connections.
Encrypting devices and resetting passwords can be done before deployment, helping doctors and patients start their IoHT use securely. Given the breadth of healthcare IoHT networks it may be more cost and time effective to purchase devices from vendors who preemptively encrypt device IDs and provide randomly-generated passwords for initial logins, after which users can be prompted for a password reset.
Like device IDs, user identities and other personal information should also be encrypted, and – together with cryptographic keys – should be further protected in secure enclaves on devices, much like hardware security modules protect cryptographic processes at the cloud level.
If any device system outside one of these chip-level secure elements is breached, cryptographic keys “zero,” meaning the key stored on a device will not match the key in the cloud and network access won’t be granted to infected endpoints.
Using cryptography to protect data and access to information at every level leaves hackers with little opportunity to inflict harm on IoHT networks, but there is one final level of vulnerability that healthcare IT teams need to close: code.
Applications and firmware must be kept up-to-date. In vetting software or device vendors, IT teams should seek out those who provide automated firmware and software updates. This can simplify patching of security vulnerabilities, and will protect against hackers looking to take control of devices or find ways to fraudulently access the cloud through a compromised device.
It should be clear that from top to bottom, the security techniques needed to keep devices and applications useful without risking the integrity of healthcare data, or the data itself, are quite similar. But each piece must be as resilient against attacks as the next to keep hackers from exploiting any vulnerability of “the weakest link”. Building strong authentication controls and encryption into each layer of the IoHT stack can help organisations create the end-to-end security needed to keep cyberattacks at bay without hindering the performance of IoHT platforms.
Manfred Kube is Director of Business Development, mHealth at Gemalto M2M based in Germany. He is convinced that secure, wirelessly-enabled devices can assist with chronic care management, ambient assisted living, fitness and wellness monitoring and more.