A sérülékenységvizsgálat jogi megítélése

A napokban vált elérhetővé (szokatlanul hosszú szünet után) a Katonai Nemzetbiztonsági Szolgálat Szakmai Szemléjének legújabb száma, melyben több érdekes kibervédelmi írás is helyet kapott. Ezek közül is különösen izgalmas témát feszeget Koczka Ferenc: Egy egyetemi informatikai rendszeren végzett sérülékenységvizsgálat módszere és néhány tapasztalat című írása.

A tanulmányában egy igen érdekes hipotézist járt körbe: azt feltételezte – a személyes tapasztalatai alapján -, hogy az egyetemi informatikai rendszerek üzemeltetői a központi rendszerek menedzselésére nagyobb időráfordítás mellett alaposabb felügyeletet biztosítanak, így a perifériális elemek védelmének szintje alacsonyabb marad. Másként: „a felsőoktatási informatikai rendszerek nem központi telephelyen működtetett elemeinek védelmi szintje elmarad a központi infrastruktúráétól.”

A gondolatkísérlet egyáltalán nem tekinthető szokatlannak, hiszen a feltételezést többféle szubjektív élmény is erősíteni tudja. Mindazonáltal a hipotézis a vizsgálat eredményeként végül nem volt bizonyítható, bár az alkalmazott metodika lényegében „rámutatott, hogy megfelelő szoftveres háttértámogatással egy már meglevő rendszer sérülékenységei azonosíthatók, melynek eredményei beépíthetők az informatikai rendszerek üzemeltetési eljárásrendjébe.”

Én ezt annyival árnyalnám, hogy a CVE/CVSS alapú vizsgálat kapcsán talán érdemes a tanulmányban egyébként a szerző által is jelzett kritikát erősíteni, miszerint „a pontszámai nem veszik figyelembe a sebezhetőség kihasználhatóságának időbeni változásait, így például azt sem, hogy a gyártó biztosított-e már javítócsomagot, vagy, hogy a sérülékenység milyen régóta áll fenn, vagy, hogy az adott környezetben egyáltalán az kihasználható-e.”

Állami megrendelő számára végzett, hasonló alapokra helyezett vizsgálataim kapcsán lehetőségem volt a feltételezett sérülékenységeket később a fejlesztői területtel együttműködve is megvizsgálni, ami alaposan árnyalta a sérülékenységek tényleges kihasználhatóságát az adott környezetben, továbbgondolva pedig az ilyen értékek szoros korrelációjának feltételezését a kockázatokkal.

Mindazonáltal nyilvánvalóan – jobb eszköz híján – jó közelítést jelenthet, különösen, ha más értékekkel együtt, nem kizárólagosan veszik azt figyelembe. Esetleg érdekes lehetne az alkalmazott metodika eredményének összevetése (például egy másik tanulmányban) egy párhuzamosan vagy legalábbis függetlenül végzett, más metodikájú sérülékenységvizsgálattal, és az azon alapuló kockázatértékeléssel.

Node a lényeg talán nem is ez, hanem a szerző azon gondolatmenete, hogy „szakmai körökben is általánosan vitatott kérdés egy hálózat sérülékenységeinek megállapítására irányuló adatgyűjtési eljárás törvényes keretek közt történő lefolytatása. Bár nemzetközi viszonylatban találhatók eltérések, a kutatásban alkalmazott mérés elvégzését a magyar jogszabályok nem tiltják.” A szerző szerint ugyanis „a 2012 évi C. törvény a Büntető Törvénykönyvről (BTK) szellemisége nem akadályozza meg a sérülékenységek tudományos célú mérését.”

A témámra rátérve, hasonló problémaként jelentkezhet, amikor bizonyos jogi kérdések vagy épp  sérülékenységek vizsgálatához például mobilalkalmazások dekompilációjára vagy deobfuszkálására van szükség. Az ilyen jellegű vizsgálatoknak például szerzői jogi korlátai is lehetnek, még akkor is, ha a szoftver felhasználására vonatkozó engedéllyel egyébként rendelkezünk.

A szerzői jogi törvény szerint, aki a szoftver valamely példányának felhasználására jogosult, a szerző engedélye nélkül is megfigyelheti és tanulmányozhatja a szoftver működését, továbbá kipróbálhatja a szoftvert annak betáplálása, képernyőn való megjelenítése, futtatása, továbbítása vagy tárolása során abból a célból, hogy a szoftver valamely elemének alapjául szolgáló elgondolást vagy elvet megismerje.

A Szerzői jogi törvény magyarázata (Complex, 2006) alapján azonban a „betáplálása, képernyőn való megjelenítése, futtatása, továbbítása vagy tárolása” felsorolás szigorúan taxatív jellegű, és a véleményem szerint egyikbe sem érthető bele a dekompiláció vagy deobfuszkálás cselekménye. Annál inkább ide vonatkozik a szerzői jogi törvény következő szakasza.

A szerző engedélye ugyanis nem szükséges a kód olyan többszörözéséhez vagy fordításához, amely elengedhetetlen az önállóan megalkotott szoftvernek más szoftverekkel való együttes működtetéséhez szükséges információ megszerzése érdekében, feltéve, hogy e felhasználási cselekményeket a jogszerű felhasználó vagy a szoftver példányának felhasználására jogosult más személy, vagy az ő megbízottjuk végzi,  az együttes működtetéshez szükséges információ az nem vált könnyen hozzáférhetővé és e felhasználási cselekmények a szoftvernek azokra a részeire korlátozódnak, amelyek az együttes működtetés biztosításához szükségesek.

Az ilyen jellegű cselekménynek azonban elengedhetetlen kell lennie egy önállóan megalkotott szoftvernek más szoftverekkel való együttes működtetéséhez szükséges információ megszerzéséhez. Ezt az engedély pedig nem lehet kiterjesztően értelmezni, tehát teljesen nyilvánvalóan nem áll meg abban az esetben sem, ha a dekompiláció célja ettől bármilyen módon eltér (például sérülékenységvizsgálat történik).

De, még ha ennek eredményeként tudomására is jutna valamilyen sérülékenységre utaló információ a felhasználónak, az így megszerzett információ nem használható fel az önállóan megalkotott szoftverrel való együttes működtetésen kívüli célra, mással nem közölhető, kivéve, ha az önállóan megalkotott szoftverrel való együttes működtetés ezt szükségessé teszi és nem használható fel a kifejezési formájában lényegében hasonló másik szoftver kifejlesztéséhez, előállításához és forgalomba hozatalához, sem pedig a szerzői jog megsértésével járó bármely más cselekményhez.

Érdekes megközelítés lehet belekapaszkodni abba, hogy eltérő megállapodás hiányában a szerző kizárólagos joga nem terjed ki a többszörözésre, az átdolgozásra, a feldolgozásra, a fordításra, a szoftver bármely más módosítására – ideértve a hiba kijavítását is –, valamint ezek eredményének többszörözésére annyiban, amennyiben e felhasználási cselekményeket a szoftvert jogszerűen megszerző személy a szoftver rendeltetésével összhangban végzi. De ettől a törvényi rendelkezéstől a jogosult a felhasználás engedélyezésekor bármikor eltérhet, és általában el is tér, vagyis a jogosult azokat eleve kizárja.

Ráadásul a Szerzői jogi törvény magyarázata (Complex, 2006) ezt még tovább szűkíti azzal az értelmezéssel, hogy „a kivétel csak annak érdekében alkalmazható, hogy a jogszerű felhasználó az engedélyezett felhasználási célt (=számára a szoftver rendeltetése) maradéktalanul meg tudja valósítani.” Márpedig egy vagy több sérülékenység megléte nem feltétlenül, és nem minden esetben gátolja önmagában a szoftver rendeltetésszerű, maradéktalan használatát, ráadásul a vizsgálatig azok meglétét legfeljebb feltételezni lehet.

A maradéktalan használat talán könnyebben értelmezhető tömegesen használt szoftver esetében, de ugyanúgy igaz lehet egyedi alkalmazásfejlesztések kapcsán is, ha szoftver, mint szellemi alkotás létrehozására irányuló szerződés, annak műszaki melléklete, követelményspecifikációja eleve nem fogalmaz meg kritériumokat az információbiztonság területéről, és a megalkotott mű egyébként funkcionálisan megfelel az információbiztonsági szempontból hiányos specifikációnak (vesd össze: a követelményspecifikációnak nem megfelelő, sőt, a feladatát ellátni képtelen, nem működő szoftver is szerzői jogi védelem alatt áll).

Mindenesetre érdekes lenne egy komplex jogi vizsgálatot, tanulmányt készíteni arról, hogy az „engedély nélkül végzett” sérülékenységvizsgálatoknak milyen jogi vetületei vannak és milyen módon lehetne adott esetben ezt a területet megnyugtató(bb)an szabályozni, ha egyáltalán szükséges.

Érdekes lehet még