Kódolt probléma

Feltörték, meghackelték, ellopták, kiszivárogtatták, elérhetetlenné tették – nincs olyan hét, hogy ne szerepelne címlapon valamelyik e kifejezések közül. Ha ennek alapján akarunk konklúziót levonni, akkor elég siralmas az IT-rendszerek helyzete úgy általában. De miért van ez így, és miért nem változtatunk rajta?

Jogos a felvetés, hiszen már nem csak másokat érintő, tőlünk távoli történések ezek, az átlagembert ugyanúgy sújtják, mint a nagyvállalatokat, kormányokat.

Nem kell túl messzire menni, ha más nem, a zsarolóvírusok mindenképp ebbe a kategóriába sorolhatók (e sorok szerzőjének is van olyan ismerőse, akinek a teljes családi fotó- és videóarchívuma vált zsarolás tárgyává), de sok esetben a saját személyes irányításunk körén kívül álló, mások által menedzselt rendszerekből kerülnek ki személyes vagy érzékeny adataink, jelszavaink, bankkártya-információk.

Sajnos már halálesetek is történtek ilyen események következményeként – elég az Ashley Madison-ügyre gondolni, ahol a kiszivárogtatott információk öngyilkosságokhoz vezettek.

Nem kérdés, hogy így vagy úgy, de mind érintettek vagyunk.

De akkor miért nem építenek biztonságos rendszereket a szakemberek? Különösen fontos és indokolt kérdés ez, ha olyan rendszerekre gondolunk, amelyek kritikus infrastruktúrát üzemeltetnek. Városok, országrészek maradhatnak víz- vagy áramszolgáltatás nélkül egy kibertámadás következtében, ami például kórházak esetében már pár óra alatt is katasztrófát okozhat.

A helyzet az, hogy sokszor igenis biztonságos – vagy legalábbis annak gondolt – rendszereket építenek. Akkor mégis miért törnek fel mindent a hackerek?

Az IT-biztonsági problémák nagy része ugyan konfigurációs, implementációs hibákból fakad, ám a másik jelentős hányad valójában egy pontra vezethető vissza:

a szoftverfejlesztési fázisra.

Egyes programozók tudtukon és szándékukon kívül hagynak olyan réseket a szoftverekben, operációs rendszerekben, amelyeket megfelelő szakértelemmel és elszántsággal fel lehet tárni, majd hasonló mértékű kapzsisággal és-vagy ártó szándékkal fel lehet használni mások kárára.

A helyzeten az sem segít sokat, hogy az ilyen jellegű hibakereséssel is foglalkozó kormányzati szervek szeretik ezeket a megtalált réseket titokban tartani

– még a rendszer készítője előtt is, akadályozva a hiba kijavítását –, mivel ez egy helyzeti előny, ezekre a hibákra, a hibák kihasználására építenek úgynevezett kiberfegyvereket, amelyeket aztán előszeretettel vetnek be egymás ellen.

Hogy ezek – és ez az egész helyzet – mennyire veszélyes tud lenni, mennyire érintheti az átlagember életét is, azt 2017 májusában és nyarán megtapasztalhattuk, amikor először a WannaCry miatt kellett többek közt műtéteket elhalasztani brit kórházakban, majd nagy testvére, a NotPetya miatt álltak le olyan cégóriások, mint a Maersk konténerszállítmányozó, számos más cég logisztikáját is megbénítva.

Az NSA által kifejlesztett, majd onnan ellopott, aztán kiszivárogtatott kiberfegyverek nélkül ezt megúsztuk volna. Olyan eszköz volt ez, amely villámgyors gépről gépre terjedést tett lehetővé felhasználói interakció nélkül.

Ez már csak azért is különösen tanulságos és aktuális, mert jelenleg is fennáll egy hasonló jellegű sérülékenység, amelyre már van működő támadó kód, és várhatóan támadás áldozatai lesznek a rendszereiket különböző okok miatt kevésbé karbantartani tudó cégek, szervezetek.

Tehát az egyik alapprobléma a fejlesztés során keletkező biztonsági rések jelenléte. Ez önmagában is komplex kérdés. Azzal kezdődik, hogy a szoftverek, rendszerek fejlesztői a funkcionalitás és a határidők kettősének szorításában a legtöbb esetben nem tudnak kellő figyelmet fordítani a biztonsági kérdésekre – ez régebben még jellemzőbb volt –, pontosabban a biztonsági problémák tudatos, fejlesztés közbeni keresésére, javítására, a biztonságos fejlesztési munkamódszer követésére.

A helyzetet tovább bonyolítja, hogy a sérülékenységek sokszor olyan elemekből fakadnak, amelyek korábban, akár mások által megírt komponensek. Az is gondot okoz, hogy egyes sérülékenységeket úgy építenek be a szoftverekbe, hogy minden egyéb szempontból tökéletesen megfelelnek mind a funkcionális, mind a fejlesztői elvárások követelményeinek. Ez a rész nagy hányadot tehet ki, és ismeretlen a fejlesztők előtt.

A válasz erre a problémára a biztonságos fejlesztési folyamat, amely – ahogy az IT-biztonság egyéb területén is – a technológia, a folyamatok és a szaktudás hármasát igényli. A technológia itt a biztonságos fejlesztést támogató rendszer, olyan eszköz, amely folyamatosan, fejlesztés közben tárja fel a lehetséges sérülékenységeket. Természetesen a szakértő közreműködése is elengedhetetlen.

Egy fejlesztőnek nem feltétlenül feladata, területe az IT-biztonsági kérdések kezelése. A biztonságos fejlesztésért felelős szakember – akárcsak egy etikus hacker – pont ezért, a speciális tudásával tudja segíteni az ellenállóbb szoftvertermék előállítását.

És ha már az etikus hacker szóba került, az ő bevonása a folyamatba – legkésőbb az éles üzembe állítás előtt – szintén elengedhetetlen, ha minimalizálni szeretnénk a kockázatot, a fennmaradó sérülékenységek számát.

Természetesen a fentebb már említett konfigurációs, implementációs problémák további lehetőséget biztosítanak a támadóknak, de egy operációs rendszerben vagy adatbázisszerver-szoftverben vagy akár csak egy mobilalkalmazásban „kódolt” biztonsági rés tud igazán nagyszámú, kampányszerű fertőzéshullámot, támadáscunamit előidézni.

És bár a már nyilvánosságra került sérülékenységekre sokszor gyorsan megérkezik a korrekció, a probléma következő láncszeme, a rendszerek folyamatos karbantartása – vagy ennek hiánya – sokszor még hosszú hónapokig (netán évekig) lehetőséget ad a támadóknak, ahogy ezt már számtalanszor láthattuk, például az említett WannaCry és NotPetya esetében.