IoT Security
Na dit hoofdstuk kan je:
- De specifieke uitdagingen van IoT-security benoemen (low-cost, long-life, fysieke toegang, firmware, default credentials).
- Aan de hand van de Mirai-aanval illustreren waarom zwakke IoT-toestellen een systemisch risico vormen voor het hele Internet.
- De rol van een TPM (of gelijkwaardig) en andere hardware-mitigaties situeren in de IoT-verdediging.
- De McCumber-kubus toepassen op IoT-data, rekening houdend met data in rust, transport én verwerking.
- De wet van diminishing returns toepassen: welke basismaatregelen (KISS, geen defaults, updates) leveren de grootste veiligheidswinst op?
We spraken in het eerste hoofdstuk al over de problemen die inherent zijn bij Internet-of-Things (IoT) apparaten en netwerken. Zo had je in 2016 het Mirai-botnet dat aantoonde hoe krachtig een botnet van IoT-apparaten kan zijn, puur door de grote hoeveelheid potentiële zombies. Eén botnet van gekaapte camera’s en routers volstond om via een DDoS-aanval op DNS-provider Dyn grote delen van het Internet plat te leggen (zie botnets). Zwakke IoT-toestellen zijn dus niet enkel een probleem voor hun eigenaar, maar voor iedereen.
Het is niet toevallig dat het laatste technische hoofdstuk van dit boek over IoT Security gaat: alles (en meer) wat je in de voorgaande hoofdstukken hebt geleerd heb je namelijk nodig om IoT-netwerken te beveiligen. Er zijn zoveel manieren voor digitale stropers om misbruik te maken van een slecht beveiligd IoT-apparaat of netwerk dat het complexe probleem van netwerken beveiligen nog ingewikkelder is geworden, namelijk:
- Van nature werken IoT-apparaten op low-power, daar ze vele dagen of weken moeten voortkunnen zonder te veel verbruik. Ingebouwde security protocollen mogen dus geen grote percentages van het vermogen opsouperen, zeker niet als dat ten koste is van de hoofdbestaansreden van het apparaat.
- Meestal, ook weer om een laag energieverbruik te behouden, hebben ze ook een beperkte bandbreedte ter beschikking (daarbij: beeld je de miserie op een wifi-netwerk in wanneer honderden kleine sensoren aan hoge bandbreedtes het netwerk mee gebruiken).
- Zowel de fysieke dimensies en bovenstaande twee eigenschappen zorgen er ook voor dat IoT-apparaten meestal maar een beperkt aantal zaken kunnen. Het heeft niet altijd de netwerkverbindingsmogelijkheden die je nodig hebt (meestal heeft een apparaat een draadloze aansluiting zoals wifi, Zigbee of LoRaWAN, of een bedrade, maar zelden beiden) en ook qua opslag en processormogelijkheden zijn de apparaten uiteraard vaak veel beperkter dan de kracht van computers en mobiele telefoons. Het grootste probleem hiervan is echter dat IoT-apparaten by nature vaak niet evident zijn om te updaten. Sommige apparaten kunnen bijvoorbeeld enkel geüpdatet worden door fysiek met het apparaat te zijn verbonden (en dan door de firmware te flashen bijvoorbeeld). Vanuit een fysieke beveiligingsconcept is dat goed, maar niet als jouw honderden apparaten een kritieke beveiligingslek hebben die dringend gepatcht moet worden.
- IoT-apparaten zijn low-cost en long-life: ze moeten zo goedkoop mogelijk zijn (en dus wordt er bespaard op alles wat de klant niet ziet, zoals beveiliging), maar eens opgehangen blijven ze vaak tien jaar of langer hangen. Veel langer dan de fabrikant er updates voor voorziet (zie verder).
- Vaak bevinden IoT-apparaten zich op de koop toe op onbeschermde locaties die maar moeilijk fysiek te beveiligen zijn. Hierdoor kunnen digitale stropers, zonder schrik om betrapt te worden, ongezien met de apparaten knoeien (tamperen).
We gaan nogal vrij om met de term IoT-apparaat, waarbij we ook negeren dat er grote verschillen zijn tussen “Enterprise IoT” en “huis-tuin-en-keuken IoT”. Die eerste categorie heeft meestal bijvoorbeeld wel zeer doordachte updatestrategieën en dergelijke, terwijl de slimme koelkast in je huis dat vermoedelijk niet zal hebben.