Általános elfogadott vélemény, hogy hibátlan kód nem létezik. Ez azonban meglehetősen nagy probléma, mert a hackerek egyik gyakori módszere, hogy a kódban lévő hibákat – olykor csak következetlenségeket – kihasználva törnek be rendszerekbe.
Bár nagyon sok módszer van arra, hogy a fejlesztés folyamatában minimalizálják a hibalehetőségeket, egy-egy bonyolultabb kódban nagyon nehéz minden pontot ellenőrizni. A kritikus rendszereknél azonban létfontosságú, hogy valamilyen módszerrel minden olyan hiba napvilágra kerüljön, ami később a rendszert veszélyezteti. Katonai eszközöknél, közműveknél, közlekedésirányításnál (különös tekintettel a légi irányításra) például katasztrofális következményei lehetnek olykor egy apróbb hibának is, ha az alkalmas a rendszer törésére.
Állítólag van megoldás
A Boeing egyik projektjénél vetettek be olyan ellenőrzési mechanizmusokat, melyek mintegy a matematikai tételek bizonyításának módszerével ellenőrizték a kód helyességét. A Boeing fejlesztett egy vezető nélküli helikoptert, majd felkértek egy hackercsapatot, hogy teszteljék a Little Bird H-6U típusú gép fedélzeti irányító rendszerét. Annak feltöréséhez azonban nagyjából akkora erőfeszítés kellett, mint bejutni egy otthoni wifi routerbe.
A DARPA (Defense Advanced Research Projects Agency) ezek után átvizsgálta és módosította a kódot. Egy olyan ellenőrzési mechanizmust használtak, amely olyan módon ment végig a kódon, mintha az egy matematikai tétel bizonyítása lenne, és ahol következetlenséget talált, azt a programozók kijavították. A javított kódot ismét a hackerek vették kezelésbe. Másfél hónapig hozzáférést kaptak a drónhoz és a hálózatához, de ez idő alatt nem sikerült kihasználható biztonsági rést felfedezniük.
A rendszert, ami a feltörhetetlen kódot biztosította HACMS-nek (High-Assurance Cyber Military Systems) hívják. Amivel a kutatók próbálkoztak, nem új: a formális ellenőrzést (formal verification) a hardvertervezésnél már régóta használják, mivel ott egy hibának lényegesen nagyobb gazdasági következménye lehet, mint a szoftvereknél. (Hogy mennyire így van, azt jól mutatja, hogy annak idején a legendásan megbízható hálózati operációs rendszert, a Windows NT egyik kiadását állítólag több tíz ismert kritikus és több száz nem kritikus hibával dobták piacra, mert a Microsoftot sürgette a határidő. Ezeket aztán a javítócsomagokban később korrigálták.)
A módszer jól hangzik, miért nem alkalmazzák széles körben? Vagy talán mégsem működik olyan tökéletesen?
Egy szakértő véleménye
A Balasys fejlesztési vezetőjének, Pfeiffer Szilárdnak biztonsági szakemberként és fejlesztőként ambivalens érzései vannak a témával kapcsolatban.
Azt mondja, egyrészről kifejezetten fontos lenne a bizonyítottan hibátlan szoftverek előállítása – különös tekintettel a kritikus rendszerekre –, ugyanakkor kérdéses, hogy erre a szakma érett-e, illetve üzleti szempontból ezen igény kielégítése milyen előnyökkel jár, illetve milyen formában tud profitként realizálódni.
Meg kell jegyezni, hogy mára a kritikus rendszerek fogalma teljesen átértékelődött, lévén a szoftverek az élet minden területén egyre nagyobb teret hódítanak meg maguknak. Ma már nem csak az anyagi biztonságunkkal összefüggésben létezik ez a kérdés, egy-egy banki tranzakció hitelessége kapcsán, nem csak a magánszféránk esetén egyre fontosabb, hiszen ki szeretné, ha a magánlevelezése, beszélgetési lehallgathatóak lennének. A fizikai biztonságunk is múlhat rajta, napjainkban ugyanis szoftver vezérli az ABS-t, a tolatóautomatikát, a vonatok fékrendszerét, az atomreaktorokat és így tovább.
Ugyanakkor a szoftveripar évtizedek óta termeli az olyan forráskódokat, melyek nagyon jelentékeny részénél nemhogy formálisan nem bizonyították a helyes működést, de még teszteléssel sem feltétlenül. Vegyük példaként a széles felhasználói bázis révén meglehetősen jól tesztelt Linuxot. Az operációs rendszer magját képező kernel 25 éves története alatt oly méretűvé vált, hogy az kinyomtatva nagyjából ezer Bűn és bűnhődést tenne ki. Erősen kétséges, hogy az internetre kötött kliensek és szerverek harmadán, az okostelefonok kétharmadán futó szoftvert – vagy annak legalább bizonyos részeit – lehet-e, és ha igen, akkor kinek áll majd érdekében matematikai bizonyításnak alávetni.
Az üzletnek pörögnie kell
A helyzetet számos egyéb probléma is tetézi – folytatja Pfeiffer. Egyrészt létezik egy piaci nyomás, miszerint a szoftvereknek egyre többet kell tudniuk, mindezt egy táguló piacon, ahol újabb és újabb területen jelennek meg a szoftverek. A már most is súlyos szakemberhiánnyal küzdő szoftverfejlesztői szakma vajon képes erre a kihívásra felelni?
Ha bevezetnék a formális ellenőrzést, az átmenetileg mindenképp csökkentené a fejlesztők teljesítőképességet, ami egyben ennek a húzóágazatnak a visszaesését is jelenthetné. Másrészről az a szaktudás, ami a bizonyításhoz szükséges, nem is feltétlenül áll rendelkezésre. Helyenként a biztonságtudatosság sem feltétlenül elég erős ehhez, lévén a szoftverek olyan területeket is meghódítanak, ahol korábban az IT-biztonságnak egyáltalán nem volt hagyománya.
A helyzetet tovább bonyolítja, hogy a szoftverek jellemzően nem monolitikusak, hanem számos – egymástól teljesen függetlenül fejlesztett – összetevőből állnak, melyek egyikének hibája a teljesen rendszert sebezhetőségét okozhatja, így ezen módszertan szigetszerű alkalmazásának megvannak a maga korlátai.
Fentiekkel együtt is kétségtelen, hogy a szoftverek hibátlan működésének biztosítása annak arányában válik egyre jelentősebb tényezővé, minél inkább elfoglalják a korábban teljesen szoftvermentes területeket is. Az autógyártás néhány évtizede jobbára a gépészeti problémákról szólt, ma viszont ez a problématérnek csak egy része. A szoftverek betörése az iparág szakembereit teljesen új kérdések elé állítja. Például milyen biztonsági kockázatot jelent ugyanazon rendszeren futtatni egy médialejátszót, mint egy kormánymű vezérlését? Az egyik sebezhetősége milyen befolyással bír a másikra?
De máshol is hasonlók lesznek a problémák. Az eddig teljesen elszigetelten működő ipari rendszerek esetén milyen változásokat hoznak majd az új technológiák? Egy-egy biztonsági hiba a webes fizetési portálokban milyen mértékben kockáztatja ezen rendszerek hitelességét? Csupa olyan kérdés, amiket teljes egészében csak a jövő oszlat majd el.
Akit kíváncsi a HACMS történetére és a kutatások jelenlegi állására kattintson ide.
A NIS2-megfelelőség néhány technológiai aspektusa
A legtöbb vállalatnál a megfeleléshez fejleszteni kell a védelmi rendszerek kulcselemeit is.
CIO KUTATÁS
TECHNOLÓGIÁK ÉS/VAGY KOMPETENCIÁK?
Az Ön véleményére is számítunk a Corvinus Egyetem Adatelemzés és Informatika Intézetével közös kutatásunkban »
Kérjük, segítse munkánkat egy 10-15 perces kérdőív megválaszolásával!
Nyílt forráskód: valóban ingyenes, de használatának szigorú szabályai vannak