Waarom u moet overstappen op Connext DDS Secure

sive care-afdelingen (ICU) of het verminderen van valse alarmen in systemen voor patiëntgestuurde analgesie (PCA). In beide voorbeelden zorgt communicatie tussen verschillende apparaten tussen leveranciers voor een aanzienlijke vermindering van vermijdbare medische fouten. OpenICE is een open source referentie-implementatie van het ICE-platform dat DDS gebruikt als het onderliggende connectiviteitsmechanisme.

OpenICE – Ontwikkeld door MD PnP Lab, maakt connectiviteit mogelijk tussen verschillende soorten medische apparaten.

Zonder inzet van expliciete beveiligingsmaatregelen is een medisch IIoT-platform zoals ICE vatbaar voor beveiligingsaanvallen die de veiligheid en privacy van patiënten in gevaar kunnen brengen. Een voorbeeld van een aanval is te zien in de volgende video waarin de aanvaller optreedt als man-in-the-middle. Ze maskeert metingen van een echt oximeterapparaat en fabriceert valse oximetermetingen met de kwaadaardige bedoeling om de potentieel kritieke toestand van de patiënt te verbergen voor de verpleegpost.

Is beveiliging op transportniveau voldoende om de connectiviteit in ICE te beschermen?

Zoals beschreven in een meer gedetailleerd aanvalsscenario in dit artikel, kan een gecompromitteerd insider-apparaat, ook al is alle communicatie versleuteld en geverifieerd met beveiliging op transportniveau (bijv. TLS/DTLS), toch systeembrede schade aanrichten, simpelweg omdat wat het kan of kan niet publiceren is niet afdwingbaar zonder gedetailleerde toegangscontrole. DDS Security maakt een fijnmazige toegangscontrole per apparaat mogelijk, waardoor de impact van dit significante type aanval van binnenuit grotendeels wordt beperkt.

Bovendien is het kunnen finetunen van beveiligingsmaatregelen op basis van risico vooral belangrijk voor apparaten met beperkte middelen of grootschalige ICE- of medische IoT-systemen met bandbreedte- of vertragingsgevoelige toepassingen. Verder zou een dergelijke fijnafstemming idealiter moeten gebeuren met minimale of eventuele wijzigingen in de codebasis, aangezien de code mogelijk niet beschikbaar is voor wijziging of te duur is om te wijzigen. Zoals hierboven vermeld, is het ontbreken van multicast-ondersteuning, die uiterst nuttig is gebleken voor efficiënte en schaalbare ontdekking en informatie-uitwisseling, een aanvulling op deze tekortkomingen.

Dit wil natuurlijk niet zeggen dat op TLS/DTLS gebaseerde oplossingen helemaal niet mogen worden gebruikt. RTI heeft al klanten die onze op maat gemaakte TLS- of DTLS-transporten met DDS gebruiken omdat ze beter passen bij hun specifieke gebruikssituaties. Bij RTI helpen we u graag een weloverwogen beslissing te nemen over het maken van dergelijke keuzes op basis van risico- en prestatie-eisen tijdens onze Architectuurstudies.

Conclusie en verwijzingen

We raden ten zeerste aan om RTI Connext DDS Secure en de standaard waarop het is gebaseerd, OMG DDS Security, te overwegen, vooral als u toepassingen voor kritieke infrastructuur ontwikkelt. Mogelijk vindt u de volgende referenties nuttig:

[1] OMG DDS-beveiligingsspecificatie vindt u hier.[2] De nieuwste versie van de Industrial Internet Reference Architecture (IIRA) is hier te vinden.[3] Industrial Internet Connectivity Framework (IICF) is hier te vinden.[4] Het Industrial Internet Security Framework (IISF) is hier te vinden.[5] Informatie over het beschermen van Integrated Clinical Environments (ICE) vindt u in dit document.

上一页  [1] [2]