Már nem utópia az autók IT-biztonsági töréstesztje (x)

Az IT- vagy kiberbiztonság kapcsán a legtöbben valószínűleg előbb gondolnak a számítógépeiket fenyegető, rosszindulatú szoftverekre, vagy épp az ipari titkokra vadászó hackerekre, mint az autógyártókra és azok beszállítóira - pedig mára ebben az iparágban is legalább olyan fontossá vált a megfelelő szoftveres védelem, mint az IT "hagyományosabb" területein.

Pedig nem új keletűek a járműveket fenyegető kiberbiztonsági kockázatok: az autók nem megfelelő szoftveres védelmében rejlő veszélyeket már 2015-ben kitűnően illusztrálta Charlie Miller és Chris Valasek legendás tanulmánya, amelyben egy Jeep Cherokee felett vették át az irányítást. A szakértők akkor az autó mobilinternetes kapcsolatot használó Uconnect rendszerén keresztül jutottak be be a járműbe - a rendszer a Wi-Fi hotspotot hivatott biztosítani a járműben, illetve a navigációs és szórakoztatórendszerekhez csatlakozott. A biztonsági kutatóknak a fejegység egyik mikrokontrollerén sikerült a firmware lecserélésével hozzáférni a belső rendszerekhez, így az autó CAN buszán, azaz belső hálózatán keresztül az olyan fizikai komponenseket is irányíthattak, mint a kormány vagy a fékek. Az eset végül összesen 1,4 millió jármű visszahívásához vezetett, és nem kis csorbát ejtett a gyártó renoméján.

A FEJLESZTÉS V MOTORJA

A hasonló esetek és persze a valódi, éles támadások megelőzésére elengedhetetlen, hogy már a fejlesztés kezdeti szakaszában nagy hangsúlyt kapjanak a biztonsági szempontok – nincs ez máshogy az elektromechanikus kormányrendszereket fejlesztő thyssenkrupp magyarországi ágazata esetében sem. A fejlesztési folyamat a vállalatnál a "V" modellt követi, amely lényegében a klasszikus, vízesés fejlesztési modellt viszi tovább: az új felállás vízszintes tengelye az időt, a függőleges pedig az absztrakciós szintet jelöli. A "V" betű bal oldali ága a fentről lefelé haladó tervezési folyamatot reprezentálja, kezdve az adott fejlesztés követelményrendszerének felállításával, a rendszer, illetve az architektúra megtervezésével - "csúcsot" pedig maga az implementáció, a kódolás jelenti. A "V" másik, jobb oldali szára a lentről felfelé haladó tesztelést mutatja be, a unit tesztektől az integrációs és rendszertesztelésen át az átadásig.

A thyssenkrupp esetében ez azt jelenti, hogy a szoftverdizájn alapján a csapat elkészít egy architektúrát, majd annak mentén jönnek létre az elvárt funkcionalitás különféle aspektusait lefedő komponensek, amelyek egymással interfészeken kommunikálnak.

Ezt követik a tesztelési folyamatok - ha pedig utóbbiak alapján a termék elég érettnek bizonyul, elkezdődik a szoftverkomponensek integrációja, amelyből megszületik az immár teljes funkcionalitással rendelkező végeredmény. Ez az elkészült szoftver megy aztán tovább az elektronikai és mechanikai alkotóelemeket is tartalmazó termékhez, amelynek legrugalmasabb komponenseként lényegében a teljes vezetési rendszer összehangolásáért felel.

KÍVÜLRŐL-BELÜLRŐL TESZTELVE

A megfelelő biztonsági szempontok, bevált gyakorlatok ezen folyamat teljes egészén végighúzódnak, már a legalacsonyabb szinttől: a fejlesztők határozott coding guideline-ok, fejlesztési irányelvek mentén dolgoznak, hogy az elkészült kód igazodjon a kijelölt IT és közlekedésbiztonsági célokhoz, megfelelően robusztus, stabil legyen és minimalizálják benne a hibák megjelenésének esélyét.  A kódolási szabályokhoz való igazodást a cég vissza is ellenőrzi, ezt követően pedig további, statikus kódellenőrzésnek is alávetik a szoftvert. Ezt követik a funkcionális tesztek, hogy az adott komponens valóban a tőle elvárt működést produkálja-e, továbbá az interfészek kapcsán is folytat ellenőrzést a cég, hogy megfelelően zajlik-e az egyes szoftveres alkotóelemek közötti kommunikáció. Mindezt további vizsgálatok követik a rendszertesztelési fázisban, ahol több, speciális kiberbiztonsági teszteseten is végigmegy a csapat, mint a sérülékenység-szkennelés, az autentikációs és inputvalidációs tesztek.

A biztonsági vizsgálatok között különösen hangsúlyos szerep jut a penetrációs tesztelésnek, amit a thyssenkrupp házon belül, majd külső, független partnerrel egyaránt elvégez, utóbbira egy biztonsági szempontból már erősen felkészített terméket adva át. A belső pentesting során ugyanis nem csak a korábbról ismert hibák meglétét ellenőrzik ismételten a delta tesztelés során, de whitebox vizsgálatot is végeznek, valamint különböző reverse engineering eszközökkel, illetve a hálózati kommunikáció ellenőrzésével, sőt támadásával is górcső alá veszik a készülő szoftvert. Ezután adják csak tovább a külső partnernek, aki maga is rigorózus ellenőrzésnek veti alá a terméket.

Mindez nem kevés erőforrást igényel, amit tovább tetéz, hogy az egyes termékeket a különböző autóipari gyártópartnerek igényeihez sokszor külön-külön, erősen testre kell szabni. Persze volt rosszabb is a helyzet, a különböző földrajzi régiókban ugyanis sokáig teljesen más IT- és közlekedésbiztonsági elvárásokat támasztottak az autógyártók beszállítóik felé - míg a keleti régiókra megengedőbb biztonsági gyakorlatok voltak jellemzők, addig a nyugati, európai térségben már szigorúbb megkötéseket alkalmaztak, akárcsak az Egyesült Államokban, persze ott megint más irányelvek mentén. Szerencsére az ENSZ az UN ECE R 155-ös rendeletével már szabályozza a területet, amelyet az EU a 2019/2144-es rendeletével emel be az Uniós jogrendbe - mindezek alapját pedig az ISO 21434 szabvány képezi. A rendeletek, illetve a szabvány a biztonságos autógyártás megfelelő kereteit írja le – és potenciálisan az utólagos „tuning” lehetőségeit is szűkebb mederbe terelheti.

A JÁRMŰVEK EGYRE VONZÓBB CÉLPONTOKKÁ VÁLNAK

Mára tehát egyrészt a Charlie Millerékéhez hasonló tapasztalatoknak, másrészt a szabályozói nyomásnak hála az autógyártók és beszállítóik rendkívül szigorú biztonsági követelményeknek kell, hogy megfeleljenek világszerte - amelyek várhatóan csak szigorodni fognak, főként az egyre "okosabb", egyre szélesebb körű funkcionalitást biztosító, hálózatra csatlakozó járművek terjedésével. Minden új funkció, vezetéssegítő és kényelmi rendszerek, illetve az utat rovó autók közötti kommunikáció is új támadási felületet jelent, amelyek kihasználására az "okos" járművek terjedésével a támadók oldalán is egyre nagyobb a gazdasági motiváció. Ilyen lehet az alapértelmezetten tiltott, a gyártótól külön megvásárolható szoftveres funkciók "kalóz" feloldása - vagy épp a hírhedt ransomware-ek, zsarolószoftverek átültetése az autós környezetekre, amelyek a váltságdíj kifizetéséig nem engedik elindítani a tulajdonos gépjárművét.

A hasonló veszélyek megelőzésére az autóipar is elkezdte tempósan felszívni különböző IT ágazatokból a biztonsági szakértőket - persze még a tapasztalt szakemberek esetében is szükség van nem kevés ismerkedésre az autóipari környezettel, hiszen erősen biztonságkritikus, ráadásul korlátozott erőforrásokkal dolgozó rendszerekről van szó, amelyek védelmét több absztrakciós szinten kell megoldani.

A kollégák ismereteinek naprakészen tartásáért a thyssenkrupp is mindent megtesz, képzésekkel, IT biztonsági eseményekkel, amelyek nem csak a mérnökök és fejlesztők, de a háttérkollégák számára is nyitva állnak. Az egészen biztos, hogy az autós IT biztonság szegmense a következő időszakban komoly pezsgés elé néz - aki a kiberbiztonságban izgalmas területet keres, az autóiparban egészen biztosan meg fogja találni.

[A thyssenkrupp megbízásából készített, fizetett anyag.]