Door: Redactie - 18 juli 2022 |
Het IoT is ontstaan en al snel gegroeid voordat men ontdekte hoe ze die infrastructuur konden beschermen of veilig gebruiken. Als gevolg daarvan zijn er honderden miljoenen IoT-apparaten op de markt gebracht zonder vooraf voldoende na te denken over de cyberveiligheid ervan. Eind 2021 waren er wereldwijd al zo’n 12,2 miljard IoT-apparaten in gebruik, volgens het ‘State of IoT—Spring 2022‘ rapport van het Duitse marktonderzoeksbureau IoT Analytics.
Het IoT bestaat zowel uit medische apparatuur, Programmable Logic Controllers (PLC), Engine Control Units (ECU’s), printers, robots en sensoren in de maakindustrie, als domotica voor thuis. Steeds meer huishoudens bezitten tegenwoordig met Internet verbonden camera’s, horloges, keukenapparatuur, televisies, verlichting, robotgrasmaaiers en -stofzuigers.
Als gevolg van de snelle groei van het IoT draait er inmiddels een compleet sterrenstelsel aan apparaten met beveiligingsissues. Natuurlijk is er al wel regelgeving bedacht en van kracht om potentiële cyberrisico’s te voorkomen, maar nog veel te langzaam en zonder terugwerkende kracht voor de enorme installed base van te zwak beveiligde apparaten.
De cyberrisico’s zijn divers en talrijk: sommige IoT-apparaten hebben standaardwachtwoorden die niet te wijzigen zijn, maar wel in online handleidingen op te zoeken. Andere worden geleverd met firmware die niet te updaten is. Veel apparaten zijn onvoldoende veilig te updaten, gaan onveilig om met gebruikersgegevens en communiceren via zwakke netwerkprotocollen.
Zelfs de beveiligingsmogelijkheden die op een IoT-apparaat aanwezig zijn, worden in de praktijk niet altijd goed gebruikt. Ontwikkelaars gebruiken regelmatig een processor op hun systeem, terwijl ze niet eens weten dat ze sterke algoritmen zoals AES kunnen benutten. Het enige wat ze daarvoor hoeven te doen, is informatie opzoeken in de datasheet van het apparaat.
Het reële gevaar van deze kwetsbaarheden kan variëren van het vermogen om privé-informatie van de gebruiker te stelen, tot het overnemen van IoT-apparaten in een DDoS-botnet. Beide voorbeelden kunnen een reëel en actueel gevaar voor mensen opleveren, als ze voorkomen in industriële machines, medische apparaten of voertuigen.
De meeste potentiële cyberrisico’s beginnen bij fabrikanten. Velen van hen denken in het ontwerpstadium nog te weinig na over de beveiligingsmaatregelen die je kunt toevoegen bij de ontwikkeling van een IoT-product. De integratie van Internet-technologie in producten is voor een aantal fabrikanten nog een nieuwe ontwikkeling die ze onvoldoende begrijpen. Nog te vaak krijgt de beste strategie voor marktintroductie meer aandacht dan de kritische beveiliging.
Als fabrikanten van industriële en medische apparatuur voor de eerste keer te maken krijgen met beveiligingsproblemen in hun producten, kan de imagoschade groot zijn. De begeleiding die ze dan inschakelen om een apparaat beter te beschermen, maakt veel verschil uit. Veelal ondersteunt de hardware wel moderne beveiligingsoplossingen, zoals Public Key Infrastructures (PKI), maar gebruiken ontwikkelaars zwakke combinaties van gebruikersnaam en wachtwoord.
Een representatief voorbeeld van een IoT-apparaat dat mensenlevens in gevaar kan brengen is de insulinepomp voor diabetes. In 2011 toonde een groep onderzoekers aan dat deze slecht beveiligd zijn. Ze waren namelijk op afstand te hacken en te besturen om te veel of te weinig insuline toe te dienen. Die interventies kunnen de gezondheid van diabetespatiënt aanzienlijk verslechteren, of ze in het ergste geval zelfs doden.
Tijdens het afstuderen voor mijn master las ik alle documentatie over de infuuspomp om te leren welke beveiligingsrichtlijnen de Food & Drug Administration (FDA) en Federal Communications Commission (FCC) vereisten voor die kritische apparaten. Het weinige dat ik vond was vaag, namelijk verwijzingen naar het nodig hebben van bepaalde soorten beveiliging, maar ging zelden in detail over hoe het toe te passen, of in een product in te bouwen.
Zo’n vage beschrijving biedt fabrikanten onvoldoende houvast. Uiteindelijk kan dit er zelfs toe leiden dat sommige fabrikanten een eenvoudigere oplossing kiezen en besluiten om minder veilige maatregelen te implementeren. Zoals de beveiliging beperken tot authenticatie met alleen een gebruikersnaam en wachtwoord, in plaats van veilige digitale certificaten. De FDA heeft inmiddels gelukkig al een stap voorwaarts gezet met specifieker beschreven richtlijnen.
Een andere optie die fabrikanten en ontwikkelaars van IoT-apparaten hebben is nauwer te gaan samenwerken met leveranciers van beveiligingsoplossingen. De experts van deze bedrijven kunnen waarschijnlijk adviezen en inzichten geven waar je als apparaatleverancier zelf misschien niet aan denkt en tevens helpen bij het integreren ervan in de ontwikkelingscyclus.
PKI-certificaten zijn bijvoorbeeld in IoT-processors te integreren met behulp van API-verzoeken aan de beveiligingsleverancier, zonder dat een ontwikkelaar ze handmatig hoeft toe te voegen, laat staan veel over digitale certificaten te weten. Dat is inmiddels een ruimschoots bewezen en door veel fabrikanten van industriële en medische apparatuur toegepaste beveiligingsoplossing.
De hiervoor beschreven integratie van PKI-certificaten vereist natuurlijk wel dat cryptografische ondersteuning in het gebruiksproces wordt geïmplementeerd, of dat er een extra processor zoals Trusted Platform Module (TPM) op hetzelfde apparaat wordt gebruikt. Dat is één van de keuzes die het beste in overleg met de leverancier te maken zijn.
De belangrijkste sleutel tot het beter beveiligen van IoT-apparatuur is ‘security-by-design’. Oftewel beveiliging vanaf het begin van het ontwikkelingsproces meenemen. Dat is wellicht een nieuwe aanpak voor fabrikanten die nog weinig ervaring hebben met ‘connected devices’ en informatiebeveiliging. Met het juiste advies, oplossing en begeleiding beginnen cyberrisico’s dan niet meer bij de apparatuurfabrikant, omdat ze al in de ontwerpfase worden voorkomen.
Auteur: Avesta Hojjati, Vice President R&D bij DigiCert.
Lees ook:
Dit artikel delen op je eigen website? Geen probleem, dat mag. Meer informatie.