De zoektocht naar een universele IoT-beveiligingsstandaard

“Waarom is er geen universele beveiligingsstandaard voor IoT?” Het is een vrij veel voorkomende vraag die onze IoT-oplossingengroep nogal wat hoort van IoT-ontwikkelaars, besluitvormers en deskundige onderzoekers, ongeacht het expertiseniveau dat ze over het onderwerp hebben. En het is een eerlijke, er zijn tenslotte normen voor zowat elke technologische omgeving die er is, dus waarom geen IoT?

Het gemakkelijke antwoord is dat IoT te divers is om een ​​vaste standaard te hebben. Hoewel waar, verklaart dat het onderwerp niet voldoende met het niveau van subtiele details dat gerechtvaardigd is. We hebben ontdekt dat er minstens drie beïnvloedende factoren zijn die van invloed zijn op universele IoT-standaarden:heterogeniteit van apparaten, verticale specifieke standaarden en opkomende architecturale concepten. Laten we naar elk kijken.

Heterogene karakter van IoT-apparaten

IoT-apparaten zijn divers. Hoewel de meeste mensen een IoT-apparaat zien als iets dat ze kunnen zien, aanraken en gebruiken, zoals een smartphone, zijn ze in feite zoveel meer. Vaak hebben ze helemaal geen menselijke interactie. Het zijn sensoren die communiceren met hun omgeving om de temperatuur in gecontroleerde omgevingen te rapporteren, door te geven wanneer een deur open of dicht is in een afgelegen faciliteit, of om te informeren over de aan/uit-status van een lichtschakelaar in een slim gebouw. Het zijn gateways die de communicatiepaden beveiligen die gegevens van een eindpunt naar de cloud overbrengen of actuatoren die die lichten uitdoen als er niemand aanwezig is. Het zijn ook cruciale infrastructuuractiviteiten die energie leveren, productieomgevingen onderhouden of telecommunicatiehubs bedienen.

Er zijn talloze soorten IoT-apparaten en hoe ze elk in hun omgeving – de use case – worden gebruikt, is ook uniek. Elk heeft verschillende technische mogelijkheden en kan mogelijk worden geïntegreerd met een aantal IoT-platforms. IoT-omgevingen en apparaten zijn soms beperkt in bandbreedte of beperkt in apparaatcapaciteit (batterij, opslag, rekenkracht). IoT-apparaatplatforms hebben ook een enorme diversiteit in hun softwareplatforms, in vergelijking met desktopcomputing. Bij desktopcomputing heb je het over slechts een handvol besturingssystemen (OS's), terwijl aan de kant van het apparaat het aantal embedded systemen veel groter is, gezien het aangepaste karakter van veel platforms.

Het vinden van gemeenschappelijke standaarden tussen zoveel diversiteit is een uitdaging en belemmert de ontwikkeling van universele IoT-standaarden.

Industriële leiders met verticale specifieke normen

Ondanks de talloze apparaten en hun brede scala aan use-cases, werken brancheverticalen samen om use-case-specifieke IoT-beveiligings- en connectiviteitsstandaarden te creëren. Er worden normen voorgesteld.

Soms evolueren die normen in de loop van de tijd. We kunnen die evolutie zien als we kijken naar op PKI gebaseerde implementaties binnen IoT en deze vergelijken met hoe PKI tegenwoordig is gestandaardiseerd binnen de web-PKI-wereld. In web-PKI hebben we openbare Certificaatautoriteiten (CA's), het Certificaatautoriteit/Browser (CA/B) Forum en de webbrowsers zelf. Er is een gevestigde en traditionele manier om webservers te beveiligen. Dat is een algemeen aanvaarde standaard en standaard use-case voor PKI, waarbij de basisvereisten van het CA/B-forum daarvoor leidend zijn. De behoefte aan een standaard voor browsers wordt aangedreven door een open ecosysteem van clients in de omgeving - alle webbrowsers en gebruikers moeten verbinding maken met een open en brede reeks servers.

Als we kijken naar PKI voor IoT-ecosystemen, verandert een deel daarvan. Terwijl web-PKI voornamelijk openbare vertrouwensmodellen gebruikt, gebruikt PKI voor IoT meestal meer gesloten, private ecosystemen. In IoT-ecosystemen zijn de vertrouwensmodellen in veel van deze ecosystemen veel meer gesloten in vertrouwen, omdat het zich nog zo vroeg in de implementatiefase bevindt. Over het algemeen levert een OEM de volledige stack van het apparaat tot aan de cloud. Ze gaan de cloud runnen of, waarschijnlijker, werken samen met iemand om de cloud te runnen, zoals Microsoft of Amazon. Deze vertrouwensmodellen voor ecosystemen zijn momenteel gesloten en in silo's.

Die configuratie is nog in ontwikkeling. We zien evoluties van identiteitsnormen en IoT-identiteitsnormen in meer verticale specifieke ecosystemen. We zien bijvoorbeeld standaarden ontstaan ​​bij groepen waarvan we lid zijn, zoals de Wi-SUN Alliance, een organisatie die de adoptie van Interoperable Smart Ubiquitous Networks stimuleert, en LXI Consortium (LAN eXtensions for Instrumentation), een groep van internationale toptesters en meetbedrijven die samenwerken om de communicatiestandaard voor test- en meetinstrumenten te ontwikkelen en te sturen.

Er zijn tal van andere voorbeelden van deze branchespecifieke use-cases die zorgen voor consistentie binnen hun eigen domeinen, zoals in de auto-industrie of thuis bij de consument. Dit is iets waarvan we voorspelden dat het zou gebeuren en iets waar we rekening mee hebben gehouden toen we de IoT-ruimte begonnen te betreden. We wisten dat we een aanvankelijke afwijking zouden zien van waar identiteitsmodellen tegenwoordig op internet worden geïmplementeerd. Dat het zou verhuizen naar gesloten ecosystemen en dan zou gaan groeien naar semi-private of semi-publieke ecosystemen, en uiteindelijk zou uitgroeien tot iets dat breder en gelijkwaardiger is als een algemene authenticatie- of identiteitsstandaard voor die ecosystemen. Branches in de branche helpen bij het vaststellen van basisnormen die waarschijnlijk als bredere normen naar voren zullen komen naarmate het IoT volwassener wordt.

Opkomende architecturale concepten

Elke IoT-verticaal en use-case heeft verschillende architecturale patronen. We zien echter ook daar enige gemeenschappelijkheid ontstaan, die is ontstaan ​​uit de IEEE 802.1 AR-specificatie en ingang vindt in IoT-ecosystemen. Het gaat om de brede en algemene conceptuele componenten van een IDevID en LDevID. Deze worden toegepast in architecturale concepten die wat meer use case agnostisch of verticaal agnostisch zijn.

Een IDevID (initiële apparaatidentiteit) heeft doorgaans een lange levensduur en wordt idealiter beschermd door veilige hardware en representatief voor de kernidentiteit van het apparaat, zoals een geboorteakte. Een LDevID (lokale apparaatidentiteit) is een lokaal belangrijk certificaat op toegangsniveau dat van kortere duur is en toegang geeft tot de omgeving, wat kan worden beschouwd als vergelijkbaar met een rijbewijs.

Dit is een van de meer verticale agnostische architecturale identiteitspatronen die we bij verschillende van onze bestaande klanten hebben gebruikt. Er is zorgvuldige afweging van uw toeleveringsketen nodig om deze te implementeren. Eerst bekijken we waar en hoe de IDevID's veilig in dat apparaat of onderdeel of chipset worden geplaatst - op welk niveau van het apparaatplatform je het ook wilt bedenken, en in welke fase van het productieproces. Vervolgens bekijken we hoe we mogelijk gebruik kunnen maken van enkele van die IDevID-vertrouwensattributen die idealiter veilig werden geleverd tijdens de productie in een lokaal significante, operationele LDevID die kan worden gebruikt om het apparaat in staat te stellen verbinding te maken en te werken in het IoT-ecosysteem. Deze LDevID's worden over het algemeen vaker geroteerd gedurende de levenscyclus van het apparaat.

Dit IDevID/LDevID-patroon is een van die architecturale identiteitsblauwdrukken waarop PKI begint te leunen in IoT, en we gebruiken een aantal van deze concepten om apparaten en toeleveringsketens te beschermen tegen opkomende bedreigingen.

Dus het antwoord op de vraag "Waarom is er geen universele beveiligingsstandaard voor IoT?" is een beetje vaag en verdient meer dan een antwoord in één regel. IoT is niet alleen te divers om één enkele standaard te hebben, hoewel dat een legitieme verklaring is, maar het is ook nog steeds in opkomst, groeit en vindt de rode draad die uiteindelijk kan leiden tot iets homogeners.