Kiberbiztonság guruló számítógépeken
Frissítve: 2023. máj. 20.
A virtuális vírusok és a tervezett működést befolyásoló, megváltoztató, leállító támadások elleni védekezés alapvető. Személyi számítógépeken, táblagépeken, okostelefonokon, szervereken vírusírtók, beépített kártevőkeresők, és további algoritmusok óvnak és védenek a felhasználói szemszögből kártékony behatolások ellen. Az ipari számítógépek jellemzően zárt hálózatban üzemelnek, specifikus operációs rendszerekkel és programokkal. Gyár, üzem, erőmű, kormányzati és közigazgatási központok, energiaelosztás, közlekedés mind – régiónként eltérő mélységben – számítógépek által felügyelt, szabályzott, vezérelt rendszerek.
Nem különbek manapság a buszok sem: guruló számítógépek lettek hajtóanyagtól függetlenül. Temérdek kisméretű ipari számítógéppel felvértezve az egyes alrendszerek működéséért: fékezés, energiaellátás, motorvezérlés, klimatizálás, ajtóvezérlés, szintezés, becsuklásgátlás; további aktív és passzív vezetéstámogató rendszerekkel kiegészítve. Ezek mindegyike hálózatban van különböző struktúrák és kommunikáció szerint - javarésze a bő húsz éve bevezetett CAN-Bus kommunikációs protokoll valamely változata, LIN-Bus, FlexRay, vagy egyéb szabványok szerint. Ezen rendszerek többségének információi csomópontosodnak a telemetriában, mely legalább egy távoli szerverrel van online összeköttetésben, ezáltal a jármű adatai, viselkedése, tulajdonságai folyamatosan nyomon követhetők.
Az EU reagál a megnövekedett bájtmennyiségre a járműveken, 2021-ben kiadták a 155-ös és 156-ös előírást:
155: általános rendekezések járművek típusjóváhagyásáról a kiberbiztonság és annak kezelésének tekintetében
avagy: Uniform provisions concerning the approval of vehicles with regards to cyber security and cyber security management system
156: általános rendelkezések járművek típusjóváhagyásáról szoftverfrissítések és kezelésük tekintetében
avagy: Uniform provisions concerning the approval of vehicles with regards to software update and software updates management system
Úgy a beszállítóknak, mint a járműgyártóknak bizonyítani kell a technikai vizsgálóbizottság/jóváhagyó hatóság irányába, hogy a jóváhagyásra jelölt jármű szoftverarchitektúrájában, és a kiszolgáló háttérszervereken mindent megtettek a behatolások, adatlopás és -módosítás felderítésére, elhárítására, kezelésére. Mi ebben a bonyolult?
Hogyan védekezzünk a holnap kibertámadása ellen?
Az emberi leleményesség, kreativitás határtalan. Eddig rengeteg kibertámadás került napvilágra, és nagyrészüket – idővel, de – kezelni, hárítani, javítani, kármenteni tudta az elszenvedő. Ismert tudásként a szakmai továbbképzéseken ezeket tanítják, a sebezhető szoftverrészeket foltozták, a strukturálisan gyenge szoftverek elterjedt használatát (pl. Java) megszüntetik, leváltják mással. Tehát jó eséllyel nem hajthatók végre újra ugyanabban a formában, viszont az indíttatás nem hagy alább; vélhetően most is világszerte több ezer támadás zajlik, melyekből megfelelő előkészülettel sokat idejekorán elhárítanak, és nem is kerülnek nyilvánosság elé.
Az elektronikai vezérlővel ellátott rendszerek beszállítóinak biztosítania kell a megrendelőt, hogy mindent elkövettek a sebezhetőség minimalizálása érdekében. Ezt a járműgyártónak igazolnia kell jóváhagyáskor egy kockázatelemzéssel kiegészítve. Adatrögzítéssel és -elemzéssel kell védekezni, hogy egy behatolási kísérlet visszaverhető, majd utólag lekövethető legyen a javítás érdekében.
Talán a legérdekesebb része az előírásnak (5.1.2.), hogy a jóváhagyó hatóságnak teszteléssel (!) kell meggyőződnie a járműgyártó által dokumentált védelmi rendszerek működőképességéről. Természetesen ezt meg kell előznie a járműgyártó által végzett belső tesztelésnek. Ennek a gyakorlati megvalósítása egyelőre tejsűrű köddel fedett. Támadást kell indítani a kiszolgáló szerverek ellen? Adatolvasás vagy -felülírás jelenti a nemmegfelelőséget? Vagy meg kell támadni a buszt? Melyik rendszerét? Hány sikertelen támadást követően felelt meg a rendszer? Milyen jellegű támadásokkal kell próbálkozni? Etikus hekkereket toboroz az ÉKM/NKH, TÜV, AUTOKUT?
Az időbeliségre is kitér, így megkülönböztet fejlesztési, gyártási, és gyártás utáni intervallumokat. Itt a gyártás utáni rész érdekes, hogy meddig, és milyen mélységű szoftvermódosításokat és -frissítéseket fognak a gyártók kiadni.
A rébuszos előírást az 5-ös melléklet hozza közelebb a gyakorlathoz, hogy a kockázatelemzés folyamán milyen lehetséges támadásfajtákat kell tekintetbe venni, legsúlyosabbtól a ködös jövőig:
a) A jármű biztonságos üzemeltetése érintett,
b) A jármű nem működik tovább,
c) Szoftvermódosítás, teljesítményváltozás,
d) Szoftvermódosítás, melynek nincs kihatása az üzemre,
e) Adatok és áramlásuk zavarása,
f) Adatok elérhetetlenné tétele,
g) Más, beleértve a bűnözést.
A g) pont alatt értendő a holnap trükkjei, és a rendszer még nem ismert hiátusai. S mivel emberek írják, a hiba lehetősége kódolt. Tovább közelítve a valósághoz a melléklet ’A’ része oldalakon keresztül taglalt lehetséges rizikókat és konkrét támadásfajtákat említ, néhány magyarra ferdítve:
Említ olyan eshetőségeket, mint:
a jármű tulajdonos, üzemeltető, szerelő rászedése/átverése, ezzel tudtán kívül egy kibertámadásban segédkezik (pl. nem kívánt fájlok feltöltése)
interferencia keltése a rövidhullámú jelkibocsátásban (pl. töltőoszlop, riasztó, távirányító)
harmadik fél által beszállított szoftvereken keresztül behatolás,
járműtulaj személyes adataihoz (fizetési információk, cím- és névjegyzék, etc) hozzáférés,
töltési paraméterek (áramerősség, töltöttségi szint, szigetelés-ellenállás, etc) módosítása,
hálózattervezés hordozta támadhatóság,
…és még sok további.
A melléklet 'B' része a fenyegetések és kockázatok mérsékléséről helyez képbe, részlet ebből:
A második oszlop javaslatai olykor igen kézenfekvők, rövidre fordítva és összegezve: vigyázd jobban az adatod. A gyakorlatba mindezt átültetni körülményes: emberi képesség és kreativitás válogatja, hogy a védelem mennyire kiterjedt és alapos, illetve ellenoldalról nézve mennyire sebezhető. Az előírás szükségessége egyértelmű, megvalósítása az egyes járművek és gyártók esetén viszont egyelőre kevésbé. Egységesebb, gyártófüggetlen szoftverarchitektúra, így a Windows-hoz hasonlóan szélesebb körben elterjedt, ismert rendszer révén jobb és kiterjedtebb védhetőség? Viszont így hiba, sebezhetőség, támadás esetén még nagyobb az érintettek köre. Ha az elaprózódott, járműgyártónként – és akár típusonként is különböző – architektúra marad, a személyi állományok legalább fele szoftvermérnök kell legyen.
A fentebb taglalt részletek jelzik, hogy gyakorlatilag mindenre tekintettel kell lenni, az egészen apró részletektől (pl. egy szervizes laptop hozzáférhetősége, jelszava, védettsége) a kézenfekvő dolgokon keresztül (pl. gyártómű belső szerverparkjának védelme, hozzáférési jogosultságok, többszörösen biztosított VPN-kapcsolatok, stb.) a beszállítói lánc, és harmadik fél által kezelt adatokra, szoftverekre (pl. telemetria-rendszerek adattömege, vezetéstámogató rendszerek által generált és használt adatok biztonságos kezelése, továbbítása). Nem kell a legrosszabb forgatókönyvre gondolni, egészen apró adatmódosítások (pl. egy over-the-air szoftverfrissítés apró módosítása, és ezáltal az összes jármű mozgásképtelenné válik) is kiterjedt hatással bírhatnak.
A szabályzás rendeleti szintre történő adaptálása (hogy mindez pragmatikusan milyen vizsgálatokat, teszteket, dokumentációt igényel) bizonyosan kevésbé lesz rébuszos, megalkotása fokozott körültekintést igényel. Gondolok itt arra, hogy:
a beszállítók milyen reprezentatív tesztekkel kell igazolják a megfelelőséget a járműgyártó felé?
a járműgyártó milyen mélységű és kiterjedtségű tesztekkel kell igazolja a jóváhagyó hatóság felé, hogy az általuk fejlesztett és összeépített jármű védett?
mi ellen kell igazán védeni, súlyosság vagy előfordulási gyakoriság szerint osztályzott támadásfajtákat határoznak meg?
a jóváhagyott jármű örökidőkre megfelel, vagy rendszeres ismétlő vizsgálatok kellenek?
ha incidens ért egy járművet, újra kell vizsgálni, netán az esetről és javításáról be kell számolni a hatóság felé?
megfelelt, gyártásba került jármű esetén egy sebezhetőség javítása nem sikerült adott időn belül, parkolópályára kell tenni az adott típus összes elkészült darabját?
hogyan veszi figyelembe az utólag, például a felhasználó/üzemeltető által beszerelt eszközöket?
milyen IT-biztonsági protokollt kell létrehozni a gyártóművön belül?
mi a helyzet az üzemeltetőkkel, szervizekkel; milyen jogosultsággal bírnak; milyen adatkezeléssel dolgoznak...?
...és még sok más...
Bő egy évvel a hatályba lépése előtt annyi bizonyos, hogy érdekes fejlesztési irányok és változások várhatók.