Szemléletmódváltás vagy halál?

A legkülönbözőbb területeken lassan már nem is az lesz a kérdés, hogy egy-egy eszköz okoseszköz-e, valamint csatlakozik-e valamilyen módon a nethez, hanem az, hogy mennyire képes egyáltalán működni smart-funkciók és net nélkül, már ha ezek egyáltalán elválaszthatók.

Az egészségügyben az egészen egyszerű vagy annak tűnő eszközöktől az egészen bonyolult diagnosztikai eszközökig minden gyártó követte vagy egyenesen diktálta a trendet, legyen szó vezeték nélküli kapcsolattal ellátott pacemakerekről és inzulinpumpákról, amikkel kapcsolatban a biztonsági aggályok már évekkel ezelőtt bejárták a világsajtót. Nem kérdés, hogy egy-egy ilyen eszközön még a firmware frissítés is rejt magában rizikót. Az orvosi képalkotó diagnosztikában természetesen adta magát az igény arra, hogy a kapott adattenger minél egyszerűbben elérhető legyen PC-n is, ahogy pedig az lenni szokott ilyenkor a gyártók egyrészt nem szeretnének lemaradni a versenytársaikhoz képest, szeretnének minél több kényelmi fícsört beépíteni, igen, még olyan áron is, ha a fejlesztés közben a biztonságból kell engedni.
Nemrég jelent meg a TheHackerNews cikke, ami szerint a támadók kimondottan röntgen-gépeket és MRI gépeket támadtak, ezen kívül sejthetően a gyártók IT-infrastruktúráját.
Több fejlesztő és fehér kalapos hekker előszeretettel hülyézi le azokat a fejlesztőket, akik egyszerűen nem szokták meg, hogy a secure coding valóban fontos, pontosabban lassan más típusú fejlesztésről nincs is értelme beszélni kicsit is komoly helyen.
A programozás, ha úgy tetszik nyelvhasználat. A natív nyelvhasználatnak, azaz ember-ember kommunikációnak pedig általános sajátossága, hogy nem kérdőjelezzük meg más szavahihetőségét, amíg erre nincs alapos okunk. A programozáskor a fejlesztő meghatározza, hogy a gépnek mit kell vagy kellene csinálnia, részletkérdés, hogy bizonyos programozási nyelvek esetén ugyanazt a feladatot minél kevesebb féle módon lehet lekódolni, mint a Pythonban vagy éppenséggel nagyon sokféle módon, mint a Perl-ben. De az eredeti paradigma szerint a fejlesztő fejleszt, tesztel, majd elhiszi, hogy a kód csak úgy működhet, ahogyan azt megírták. Miért? Mert a bizalomközpontú ember-ember kommunikációból indult ki a fejlesztő, amikor lefejlesztette azt, amit kellett.
A metaforát folytatva, a fejlesztésre alkalmazva sokáig azért nem foglalkoztak egyáltalán azzal a fejlesztők, hogy az alkalmazás vagy szolgáltatás megfelelő bemenetet kap-e, mert nem feltételezték, hogy esetleg lesz valaki, aki majd olyan bemenetet küld, amin keresztül akár az operációs rendszer szintjén valami nagyon kellemetlen dolog történik, például.
Csakhogy az éles szoftverfejlesztés és az internet természete más, bizonyos értelemben éppen fordítottja az ember-ember kommunikációnak.  Az elektronikus levelezés nagyon jó példa a netes szolgáltatások természetének megértésére. A spamek és phishing ellen vívott küzdelemben eredeti formájához képest technikai téren az emailezés teljesen megfordult: egészen addig feltételezik a levelezőrendszerek, hogy az email hamis, amíg sok-sok kifinomult lépésen keresztül nem bizonyosodik meg róla címzett, hogy hiteles.
Hasonló trend, ami szerint ha gépekről van szó, semmi sem hiteles, amíg nincs hitelesítve avagy a megfelelősége tesztelve, a fejlesztés és üzemeltetés területén markánsabban vagy kevésbé, de mindenhol ott van ugyanez.
Azaz az információáramlás natív természetével, az ember-ember kommunikációval ellentétben amikor az ember mondja meg a gépnek, hogy mit csináljon a fejlesztésen keresztül,  mindegy, hogy egy apró webappról, egy levelezőrendszerről az internet valamelyik elemi szolgáltatásáról van szó, a gépeknek, a fejlesztőnek és az üzemeltetőnek azt kell feltételezniük, hogy az információ vagy egy működés nem fogadható el hitelesnek, amíg több mechanizmus nem igazolta, hogy valóban az.
Alighanem mindenki találkozott már azzal a védhetetlen véleménnyel, hogy “hozzánk minek akarnának betörni” vagy éppen egy szoftverrendszer jó úgy, ahogy van, elkészült időre, holott annak kellene általános gyakorlatnak lennie, hogy a fejlesztést követően több tesztelési metodikát is bevetve igazolható legyen az elvárható szintű stabilitás és biztonság.
Persze, hogy lesznek többen a piacon, akik függetlenül attól, hogy inzulinpumpát, röntgengépet vagy lélegeztetőgépet gyártanak, amik a maguk módján okoseszközök, például lehetővé teszik a vezeték nélküli firmware-frissítést, a gyártók engedve a kisebb ellenállásnak, fejlesztés közben a biztonságra és a tesztelésre fognak a legkevesebb figyelmet fordítani.
Természetesen függően attól, hogy milyen eszközről van szó, más előírásoknak kell megfelelnie egy inzulinpumpának és egy intenzív betegellátásban vagy aneszteziológiában használatos lélegeztetőgépnek, a lényeg viszont ugyanaz: ha a fejlesztők nem szakítanak a korábbi megszokással és a kódolás nem lesz eleve biztonságos kódolás, annak beláthatatlan következményei lesznek.
Kevesen tudják, hogy ami sokak számára sci-fi, az a gyógyszergyártásban már a jelen, a gépek szemet kápráztató sebességgel és pontossággal teszik a dolgukat, egyre kevesebb emberi felügyelet mellett. Ahogy az az iparágnak megfelelően megkövetelhető, rendkívül szigorú szabályok vannak ugyan, de az elvi lehetőségét nem zárhatjuk ki annak, hogy sosem hakkolnak meg egy robotot például egy patkolt filmware-rel. Márpedig ha egy high-tech robot egy-egy hatóanyag ezerszeresét adagolja a készülő gyógyszerkészítménybe, ráadásul úgy, hogy azt ne is lehessen észrevenni rutinszerűen, tragikus következményekkel járhat.
Végül megjegyzem, még ha eléggé biztonságosan is működnek az atomreaktorok PLC-i, a légi forgalomirányításban használt valós idejű rendszerek, sokkal gyorsabban árasztanak el az okoseszközök, minthogy ahhoz a végfelhasználók hozzá tudnának szocializálódni vagy a jogalkotók eléggé gyorsan tudnának megfelelő kontrollokat beépíteni.

J. A. után szabadon azt írnám, hogy programozni és tesztelni csakis szépen, ahogyan a csillag megy az égen, úgy érdemes, úgy szabad.

kép: Alibaba

Szerző: bardóczi ákos

ORCID, Google Scholar ID, ResearcherID, ResearchGate, MTMT.hu? Find me!