Arjan Kievits
The Internet of Troubles
Het is inmiddels een echte kreet geworden: het Internet of Things, IoT. Of moeten we zeggen Internet of Terror. Misschien zelfs Internet of Trouble. Zeker deze laatste is niet onterecht, met de explosie van ‘dingen’ die aan het internet gekoppeld worden. En dan ook nog vooral via het Wi-Fi netwerk.
Meer apparaten op een netwerk is op zich geen probleem, maar security wordt daarmee nog belangrijker. Zeker als het om die ‘dingen’ gaat die zich over het algemeen niet zo druk maken om security wordt het hoog tijd hier wat aan te doen.
Een open deur
De tijd van alleen laptops en smartphones is wel voorbij. Inmiddels is IoT een onderdeel van het dagelijkse leven geworden. IoT gaat niet meer alleen over sensoren die wat data verzamelen en versturen. Inmiddels zijn er ‘slimme’ koelkasten, camera’s, deur- en raamsensoren, scanners, een matras, deurbel, lampen, gordijnen en zelfs een aquarium. Het zijn zomaar wat voorbeelden van wat nu de IoT bubble vormt. En over het algemeen zijn het apparaten die een lagere standaard in beveiliging en beheer hanteren. Bovendien is de vraag hoe ‘slim’ ze dan echt zijn, want het is niet zozeer óf een IoT-apparaat een keer gehacked wordt, maar wanneer.
Zowel de beveiliging van de informatie en verbinding van een IoT apparaat als de toegang tot het apparaat maakt deel uit van de risico’s die aan IoT kleven. Steeds vaker gebruiken IoT apparaten wel een zekere mate van sterke encryptie, maar is het beheer hierop lastig. Dat zeggende, als een apparaat 802.1X ondersteund, gebruik het dan! Maar wat als er alleen een simpele PSK-sleutel kan worden ingesteld?
Het gevolg is al vaak gezien: ieder apparaat maakt gebruik van dezelfde sleutel, want dat is voor nu even handiger. Dat even is in de meeste gevallen permanent. Bovendien is beheer van de apparaten veelal extern belegd, waardoor het risico bestaat dat een gedeelde sleutel op veel verschillende plekken bekend is en lastig wordt om aan te passen. Natuurlijk is een PSK-sleutel beveiliging nog altijd beter dan geen beveiliging, maar hoe meer apparaten gebruik maken van dezelfde sleutel, hoe lager de beveiliging in zijn geheel wordt. Als iedereen dezelfde sleutel heeft, kun je net zo goed de deur open zetten.
Radio-blabla
Tot voor kort was het niet zo’n probleem om een klein draadloos netwerkje op te zetten voor wat IoT apparaten. Bovendien was het in veel gevallen de enige manier om dit te doen. Simpelweg een nieuw SSID maken met een PSK-sleutel en dat was het dan wel zo’n beetje. Met de groei van het aantal apparaten die vaak ook nog eens niets met elkaar te maken hebben werden er steeds meer unieke SSID’s aangemaakt zodat iedere toepassing zijn ‘eigen’ netwerkje had. Met een eigen sleutel, en dat is toch goed? Geen gedeelde sleutel meer dus alles veilig. Nou, niet dus. Het probleem bij deze aanpak is het groeiende aantal SSID’s. Simpel gezegd: ieder SSID wat wordt uitgezonden genereert radioverkeer. Zelfs als het SSID niet gebruikt wordt. Door het uitzenden van steeds meer aparte SSID’s onstaat er een strijd om zogenaamde airtime: de tijd die geclaimd wordt om te mogen zenden op een Wi-Fi netwerk. Een hoop blabla dus. Het resultaat is een steeds verder degraderende performance. En dat treft ook je meest belangrijke zakelijke netwerkdiensten!
Als vuistregel houden we aan om niet meer dan 4 tot 5 SSID’s te gebruiken. Ok, dat is per radio-band maar toch. Veel IoT apparaten zitten nog op de 2,4GHz band, maar dit is zeker niet altijd het geval en dus is het goed aan te wennen niet nog meer SSID’s aan te zetten, anders staat het netwerk vooral zichzelf bezig te houden met onnodige data en zit je eindeloos te wachten tot je teams-sessie stopt met haperen.
Maar ja, hoe doe je dat dan? Misschien zijn er wel 4, 5 of meer groepen nodig om de verschillende toepassingen van elkaar te scheiden. Dan loop je dus vast met die vuistregel.
De oplossing!
Wat als je nu één SSID met PSK-beveiliging toch kan opsplitsen in meerdere domeinen. Oftewel: al die verschillende IoT-toepassingen die alleen maar met een PSK-sleutel om kunnen gaan toch onderling van elkaar scheiden.
Door gebruik te maken van een techniek die iPSK heet is het mogelijk per groep apparaten een unieke sleutel te maken, zonder deze te hoeven delen met andere partijen. Zo kan bijvoorbeeld de leverancier voor camera’s gebruik maken van sleutel 1 voor zijn 10 camera’s terwijl de leverancier van de handscanners alleen afweet van zijn eigen sleutel 2. Bovendien kan het camera-netwerk niet bij de data in het scannernetwerk en vice versa. En dat alles terwijl er maar 1 SSID uitgezonden hoeft te worden en het probleem van de radio-blabla daarmee is voorkomen (of opgelost!).
Credits: Cisco Meraki
Het principe achter de iPSK oplossing is het autoriseren van een uniek apparaat (mac-adres). Apparaten kunnen in groepen geplaatst worden die gezamenlijk een sleutel delen. Elke groep heeft zijn eigen unieke sleutel. Zo heeft de camera-leverancier geen weet van de sleutel van de scanners. Bovendien kan het netwerk waar de camera’s zich in bevinden (het VLAN) gescheiden worden van de andere netwerken. Ook dat kan per groep iPSK-gebruikers ingeregeld worden en verhoogt de verdere beveiliging van het netwerk.
Wat nu?
Bij Veducon werken we met Cisco en Cisco-Meraki die de iPSK oplossing volledig ondersteunen. In geval van Cisco-Meraki is dit zelfs zonder Radius server in te richten. Het eerdere plaatje toont wat hiervoor nodig is en dat is slechts iets meer dan het standaard SSID met een PSK wat je thuis ongetwijfeld ook al hebt. Met Cisco ISE is een volledig geïntegreerde oplossing met het Cisco WLAN portfolio op te zetten, inclusief Meraki. Binnen de Meraki dashboard is het mogelijk zonder externe Radius server een iPSK oplossing op te zetten tot 5000 unieke apparaten.
In principe kan elke Radiusserver die de Cisco attributen ondersteund gebruikt worden. Een Microsoft NPS of FreeRadius server werkt dus ook, maar er zit wel een addertje onder het gras. Eigenlijk meer dan 1 addertje en die worden vaak ‘vergeten’ om het allemaal wat mooier te laten lijken. Zo is er, los van de profielen die aangemaakt moeten worden, bij Microsoft de eis dat voor elk MAC-adres een user-account aangemaakt moet worden in Active Directory. Plus een AD groep met minimale instellingen. De user-account is opgemaakt uit een naam en wachtwoord en dit is geval van iPSK allebei het MAC-adres. Jawel, je leest het goed. Tot zover je password-restricties want daar voldoet een MAC-adres in de meeste gevallen niet aan. Naast dit kleine detail moeten de accounts ook beheerd worden en dit gebeurt vaak door andere beheerders dan waar dit thuis zou moeten horen. Er zijn dus wat verbeterpunten in AD, in het bijzonder bij gebruik van iPSK. Maar het kan werken. Als je de schaal van de uitrol beperkt en niets geeft om logging.
Gebruikmakend van ISE is vaak de eerste gedachte: ‘hoe zit dat dan met beheer? Is een ISE beheerder straks verantwoordelijk voor het registreren van elk MAC-adres wat langskomt?’
Ja en nee. Er zijn mogelijkheden om het aanmaken van accounts te vereenvoudigen zonder tussenkomst van een netwerkbeheerder. Het hangt af van de schaal, hoe statisch de omgeving is, wie welke verantwoordelijkheden heeft, kortom meer de OT kant van IoT. Door in gesprek te gaan kunnen de mogelijkheden verder worden doorgesproken om tot een schaalbare oplossing te komen. Feit is, niets doen is geen optie want vroeg of laat groeit het IoT-netwerk je boven het hoofd en is het omzetten naar een veilige oplossing een enorm karwei.
