Így fognak frissülni az okoskütyűk

Egy fontos lépéssel kerültünk közelebb ahhoz, hogy az internetképes eszközök végre megfelelő biztonsági frissítéseket kapjanak.
 

Az dolgok internete, azaz az IoT (Internet of Things) egyre gyakrabban igazolja azt, hogy nagyon komoly biztonsági hiányosságok vannak e területen. Mind több IoT-botnetről hull le a lepel, amelyek esetenként akár komolyabb támadásokba is lendülhetnek, és elosztott szolgáltatásmegtagadások révén béníthatnak meg vállalatokat, szolgáltatásokat, webes alkalmazásokat.
 
Az IoT fenyegetettségek egy jelentős része arra épít, hogy a netes készülékeket (routereket, kamerákat, okoseszközöket stb.) a felhasználók gyakorta a beépített, gyári jelszavakkal működtetik. A kockázatokat pedig tovább fokozza, hogy sokszor a gyártók is hadilábon állnak a biztonsággal. Már a tervezéskor számolniuk kellene a biztonsági kockázatokkal, és azok kezelését a fejlesztések során kiemelt szempontnak kellene tekinteniük. Ennek ellenére elég sűrűn igencsak sok hibával kerülnek le a gyártósorokról ezek az eszközök. Ami még nagyobb probléma, hogy a frissítések, hibajavítások is háttérbe szorulnak. A pörgős termékciklusok miatt pedig hamar támogatásukat vesztik e készülékek.
 
Szabványos foltozgatás
 
Az IETF (Internet Engineering Task Force) illetékes munkacsoportja és biztonsági szakértői megelégelték, hogy nem lehet rendesen kezelni az IoT-kockázatokat. Kidolgoztak egy olyan tervezetett, amelynek célja, hogy szabályozottá tegye az internetképes eszközök frissítését. Noha a szabványtervezet még messze van a véglegesítéstől, de azért már körvonalazódnak a követelmények. Néhány ezek közül:

• A frissítési mechanizmusoknak egységesen kell működniük Bluetooth, WiFi, UART, USB stb. alapú verzióváltások esetén is.
• Végponttól végpontig terjedő titkosításra van szükség.
• A frissítő állományokat, kódokat opcionálisan titkosítani kell.
• A firmware frissítéseket ellenőrizni és validálni kell megfelelő integritásvizsgálattal.
• Biztosítani kell, hogy a frissítési folyamat megszakadása esetén (például áramszünetkor) a frissítés az eszköz használhatatlanná válása nélkül folytatható vagy újrakezdhető legyen.
• Meg kell akadályozni a jogosulatlan rollback/downgrade eljárásokat.
• Különféle kockázati szinteket kell bevezetni, és a kritikus infrastruktúrák esetén biztosítani kell, hogy mind a szoftver (firmware) fejlesztője, mind az eszköz gyártója (ha különbözőek) digitálisan aláírják az új verziókat.
• Ügyelni kell a megfelelő dokumentáltságra.

 
Ken Munro, Pen Test Partners biztonsági kutatója úgy vélte, hogy a fenti törekvések egyértelműen jó irányba mutatnak, de még sok munka van hátra. Kifogásolta például azt, hogy a szabványtervezet csak opcionálisan írja elő a firmware frissítések titkosítását. A rollback folyamatok korlátozását is jó ötletnek tartja, de véleménye szerint itt pontosabban kell definiálni az elvárásokat, hiszen előfordulhatnak olyan esetek, amikor egy firmware hibás működése miatt kell visszaállni egy korábbi verzióra. Vagyis nem feltétlenül csak az a forgatókönyv létezik, amikor hackerek akarnak visszaállítani egy készüléket egy korábbi, sebezhető állapotra.
 
Munro végül kifejtette, hogy az ellenőrzési és compliance feltételeket is ki kell dolgozni, vagyis pontosításra van szükség abban a tekintetben, hogy a gyártók miként igazolhatják majd az új előírásoknak való megfelelőségüket.