Üzletfolytonossági terv zsarolóvírusra?

Egyre több vállalat készít üzletmenetfolytonossági terveket. Ezek a tervek tradicionálisan az emberi erőforrások kiesésére (pl. járvány, közlekedési problémák), épület kiesésre (tűz, természeti katasztrófa), hardver, szoftver problémákra koncentrál. Sajnos nem túl rég megjelent egy új katasztrófa-típus, amely a korábbi kategóriákba nem fér bele. Ez a zsarolóvírus, ismertebb nevén ransomware támadás. Szerencsére általánosságban a magyar vállalatok eddig nem tűntek elég vonzó célpontnak, de sajnos már volt magyar érintett is, így fontos a felkészülés. Jelen írásom az üzletmenet folytonosságnak csak az IT biztonsági vonatkozását tárgyalja, de véleményünk szerint IT nélkül nem sok cég van, amely képes manapság mondjuk egy hónapot túlélni.

A zsarolóvírus támadások teljesen egyedi védekezést, helyreállítást igényelnek.

Felteheti bárki a kérdést, hogy miben más ez, mint egy természeti katasztrófa? A merevlemezeken levő fájlok mindkét esetben elérhetetlenné válnak, sőt, a zsarolóvírus esete még jobb is, mert a hardver legalább megmarad. A kérdés persze jogosnak tűnik, hiszen (bár más okból) itt is, ott is, a merevlemezen levő rendszerek és adatok válnak elérhetetlenné. Azonban van néhány lényeges különbség is.

A zsarolóvírus támadás során sok esetben a fájlok titkosítása mellett a támadók az adatokat le is másolják, és az adatok publikálásával is fenyegetőznek. Ami a tapasztalatok alapján sok esetben akkor is bekövetkezik, ha az áldozat fizet. Ez duplán is rossz: egyrészt titkos (szenzitív) vállalati anyagok láthatnak napvilágot, másrészt a hatóság részéről egy komoly adatvédelmi eljárásra is lehet számítani a GDPR előírásainak megsértése miatt.

Mindez azt jelenti, hogy komplexebb katasztrófa elhárításra lesz szükség. A technikai helyreállítás mellé bejön egy speciális válság kezelés, válság kommunikáció is (lásd később). Meg persze a NAIH vizsgálat is, hiszen incidens történt, be kell jelenteni.

Nézzük meg egy kicsit részletesebben, hogy mi a teendő abban az esetben, ha zsaroló vírus támadás áldozatai lettünk:

1. Elkezdünk pánikolni, hogy most mi lesz.
2. Tovább pánikolunk, hogy hogyan mondjuk meg a főnöknek.
3. Elkezdjük keresni a biztonsági eseménykezelési tervünket. Rájövünk, hogy azt még nem csináltunk.
4. Most már nagyon pánikolunk.

Innentől egy kicsit komolyabban:

5. A KÜRT a felkészülésben, megelőzésben hisz, még akkor is, ha a megelőzés sohasem jelenthet száz százalék biztonságot. Emiatt csatlakozott a „No More Ransom” kezdeményezéshez is, melynek legfontosabb üzenete az, hogy „Sosem javasolt kifizetni a váltságdíjat, főleg azért, mert ez nem jelent garanciát a probléma megoldására.”. Bűnözőkkel állunk szemben, így nem lehetünk benne biztosak, hogy ha fizetünk, meg fogjuk kapni a visszafejtéshez szükséges kulcsokat (ha egyáltalán azok léteznek) és abban sem, hogy nem fognak minket újra megzsarolni mondjuk az ellopott adatok nyilvánosságra hozásával. Ennek ellenére előfordulnak olyan esetek, ahol nincs más út. Ezt mindenkinek mérlegelnie kell. Azaz meg kell hozni egy súlyos döntést, ki kell választani, hogy melyik úton induljunk el. Ehhez először meg kell vizsgálni, hogy képesek vagyunk-e helyreállni: van-e használható mentés, esetleg létezik-e helyreállító kulcs. Ez utóbbi furcsának tűnhet, de időnként elérhető helyreállító szoftver, mivel sérülékenységek a vírusokban is előfordulnak, így lehet írni visszafejtő programot rá. Ezek azonban csak a rendvédelmi szerveken keresztül elérhetők, hiszen ellenkező esetben a készítői azonnal patch-elnék a vírust. Ilyen szoftver meglétének kiderítéséhez jó kiindulópont lehet a „org”.
   1. Ha úgy döntünk, hogy fizetünk, akkor
      1. Egyeztetni kell a CFO-val, hogy honnan szerzünk pénzt. Alapvetően probléma lehet, hogy valószínűleg nincs NAV állásfoglalás arról, hogy hova kell a bűnözőknek Bitcoinban kifizetett váltságdíjat könyvelni.
      2. Vásárolni kell Bitcoint (vagy igény szerint valami hasonló cryptovalutát), ami szintén utánajárás, főleg egy ebben a témában nem járatos csapatnak.
      3. Fizetés után (esetleg meg lehet próbálni alkudni), szerencsés esetben tényleg elküldik a dekriptálót, amivel szépen helyre lehet állítani a rendszereket. Ha nem küldik el mégsem, akkor így jártunk, és át kell térni a b) megoldásra.
      4. El kell döntenünk, hogy mennyire bízunk meg egy bűnözőktől kapott szoftverben. Ha nem (ami a logikusabb lépés), kell valaki, aki nagyon sürgősen visszafejti a kapott szoftvert, hogy tényleg csak azt teszi, amit ígértek. Tegyük fel, sikerrel jártunk és megvannak az adataink.
      5. Ha nem szeretnénk a nyilvánvalóan meghekkelt és rosszindulatú szoftverekkel fertőzött rendszerünkön tovább dolgozni (és nyilván nem) akkor fel kell fogadni egy biztonsági csapatot, akik átvizsgálják a rendszerekeinket, valamint a hálózatot, majd adnak egy riportot, hogy mit kell kijavítani, újra telepíteni, cserélni, hiszen egy kifinomultabb kártevő akár az eszköz firmware-ben is el tud rejtőzködni. Firmware pedig a merevlemezekben is van, de még sok tápegységben is.
      6. Szinte készen is vagyunk. Megvesszük (bár ez chiphiányos korszakunkban nem is olyan egyszerű) és újra telepítjük, amit javasoltak, majd visszatöltjük a korábban helyreállított adatainkat. Ne felejtsük el, hogy jó eséllyel most a vállalat ÖSSZES számítógépéről beszélünk (és értsük a számítógépet nagyon tágan), nem csak a szerverekről, hiszen akár egy valódi vírus, ha egy példány túlél, ismét megfertőződhet a rendszer.
      7. Miután mindent helyre állítottunk már csak abban kell reménykedni, hogy az esetlegesen ellopott adatokkal nem zsarolnak meg minket még egyszer vagy nem publikálják.
   2. Ha az a döntés, hogy nem fizetünk, akkor
      1. Elő kell kotorni az offline biztonsági mentéseket.
      2. Itt egyből megkereshetjük a számunkra elérhető legjobb ’Incident Response Team’-et, (most tudunk egy kicsit több pénzt szánni rá, hiszen a váltságdíj nálunk maradt), akik az előbb részletezettek szerint átvizsgálják a rendszereket, javaslatot tesznek annak javítására. Fontos, hogy a mentéseinket is át kell nézni, hiszen azok is tartalmazhatják a kártevőt, amit valószínűleg nem szeretnénk helyreállítani.
      3. Itt is telepítünk, vásárolunk, helyreállítunk. A fő eltérés a reménykedésben van, hiszen itt, mivel nem fizettünk, ha el tudták vinni az adatokat, akkor azt biztos, hogy publikálni is fogják.
6. Akár fizettünk, akár helyreálltunk, kommunikálni kell az érintett felek (ügyfelek, hatóságok, részvényesek stb.) felé a történteket. Azt, hogy számunkra roppant fontos a biztonság, de egy nagyon szofisztikált támadás áldozatai lettünk (azt nyilván nem ismerhetjük be, hogy Jolika VPN jelszava a Password123 volt). Ha személyes adat is kikerült (márpedig hol nem kerül ki?), akkor az érintetteket értesíteni kell, szükség esetén a jelszavakat megváltoztatni stb.
7. Készülni kell a NAIH vizsgálatra, ahol be kell tudni bizonyítani, hogy mi valóban mindent tőlünk telhetőt megtettünk.
8. Mivel bűncselekmény történt, meg kell tenni a feljelentést a rendőrségen. Ezt akkor is érdemes megtenni, ha úgy gondoljuk, hogy ilyen ügyekben önállóan a magyar rendőri szervek nem tudnak semmit sem tenni. Ez persze általában igaz is, de egyrészt szerencsére léteznek nemzetközi szerveződések, amelyek azért nem egyszer sikerrel járnak, másrészt a feljelentés jól jöhet később egyes kormányhivatalok irányában is, ha esetleg a zsarolóvírus miatt bizonyos kötelezettségeknek nem tudtunk eleget tenni.
9. Természetesen még nagyon sok feladatot fel lehetne sorolni, de ezt mindenki maga kell végig gondolja.

Térjünk vissza egy kicsit a részletekre területenként. Először a technikai helyreállítás kérdésére. Itt is alapvetően más lesz az igényelt szemlélet zsarolóvírus esetén, mint egy normál helyreállításnál. Ennek az oka a technológia fejlődésében keresendő. Napjainkkal ellentétben 20 évvel ezelőtt a vállalatok jelentős része technikailag felkészült lett volna egy ransomware támadás utáni helyreállításra.

Annak idején a használt adatmennyiség töredéke volt a mainak. A merevlemezek ráadásul nagyon drágák voltak, ezért a vállalatok a biztonsági mentésekre szinte kizárólag külső adathordozókat használtak. CD-t, szalagot. Egy átlagos mentési rend úgy nézett ki, hogy a hét minden napjára volt egy (néhány) külön szalag, és ezek a szalagok egy páncélszekrényben voltak tárolva. A mentőegység egyetlen szalagot kezelt. Mivel jó (megbízható, üzemeltethető) szinkronizációs technológiák nem nagyon voltak, ezért inkább hideg tartalék helyszínekben lehetett gondolkodni. Azaz itt a helyreállítás egyszerű (kicsit szándékosan egyszerűsítve): előveszem a szalagokat, megnézem, hogy melyik jó és visszatöltöm.

Idővel fejlődött a technológia, olcsóbb lett a merevlemez, több lett az adat, és ahogy gyorsult az élet, úgy lett az elvárt RTO érték egyre rövidebb, a szinkronizáció egyre gyorsabb. Ezt már a szalagok nem tudták teljesíteni, elkezdődött a diszkre való mentés, amiről esetleg készül időnként további mentés szalagra. Sok helyen azonban mentés már egyáltalán nincs, csak átszinkronizálják az adatokat egy másik telephelyre (bár tudjuk, hogy az valójában nem mentés).

Mi történik a támadás során? A zsarolóvírus sokszor azzal kezdi, hogy megpróbálja letiltani az ismert mentőszoftvereket, tönkre tenni a mentéseket (pl. törlik a shadow copy-t). A normál adatok mellett a mentések felcsatolt particióit (amik biztosítják a gyors helyreállítást) is megpróbálják titkosítani. Ha több fájlverziót őrzünk, akkor – ha azok is ugyanazon az elérhető partíción vannak – azokat is. Ha szinkronizációt használunk, akkor köszönik szépen, a szinkronizáció megoldja a többi telephely titkosítását is. Mi az, ami biztosan megmarad? Azok a mentések, amik olyan médián vannak, amik teljesen elérhetetlenek számukra. Például azért, mert a páncélszekrényben vannak. Mostanában megjelentek cégek, akik a „páncélszekrénybe” is tudnak mentéseket biztosítani, csak ezt (Cyber Recovery) vault-nak hívják. Ezek nyilván megpróbálnak egy páncélszekrényhez képest többlet szolgáltatásokat nyújtani. Persze ezek esetén is az a legfontosabb kérdés, hogy hogyan tudjuk megakadályozni a vírus bekerülését a széfbe (hiszen a saját vírusirtóink nem fogták meg…). Akinek a kockázati profiljába belefér egy felhős mentés, az választhat ilyen szolgáltatást is. Ott a jobb szolgáltatóknál van fájl verzió megőrzés és időgép, így „tetszőleges” időpontra vissza lehet állni probléma esetén, ami megkönnyítheti a helyreállítást, illetve ellenőrzést. Mondjuk, megvan a mentésünk, legyen csak néhány 10TB szalagon (felhőben). Gondoljuk végig azt, hogy miben bízhatunk meg! Hogyan tudunk ennyi adatot ellenőrizni, hogy fertőzött-e? Hogyan fogjuk például ellenőrizni azt, hogy a letárolt base imagek, amiket vissza akarunk tölteni, sértetlenek-e? Készítettünk legalább egy hash-t róluk még „békeidőben”? Nyilvánvalóan minden aspektust nem tudok érinteni, nem is cél, de látható, hogy ezek olyan kérdések, amik egy természeti katasztrófa esetén nem kell, hogy felmerüljenek.

De nem csak a számítógépeket kell vizsgálni. A bűnözők lehet, hogy heteket, hónapokat töltöttek a hálózatunkban. Mindent megvizsgáltak. Jó eséllyel mindenhová eljutottak, ami elérhető a hálózatról. Most gondoljuk végig azt, hogy mi az, amit még menedzselünk. Például kamerákat. Azokban van számítógép? Van. Meg talán az IP telefonokat, beléptető rendszert, légtechnikát, kazánokat, lifteket, ipari vezérlőket (ICS, pl. SCADA rendszerek). Ezekben is ugye van számítógép, valamilyen tároló, firmware. Akkor ezek megbízhatók? Ki fogja ezt leírni? Mi alapján tudja leírni? Például sok helyen a biztonsági kamera az „csak” egy kamera, senkinek sem törődik vele. Fel nem merül, hogy frissíteni is lehetne, vagy hogy egyáltalán milyen fájlokat kell tartalmazzon. Viszont van benne egy web szerver. Arról vissza fertőzhető az a gép, ahonnan megnézik. Szóval célszerű lenne tudni, hogy mi az esetleg, ami pluszban van rajta, vagy változott. Megvizsgálja ezeket is egy szakértő (aki akár tévedhet is), vagy hívjuk a tűzszerészeket (na jó, vegyünk újat)? Nyilván vannak azok a helyek, ahol a minimális kockázatot sem szabad vállalni, a pénz nem számít. (Bár persze a szakértő is pénzbe kerül, azaz mindenképpen érdemes számolni, melyik verzió az olcsóbb.)

Ha a vészhelyzeti kommunikáció témakörét vizsgáljuk meg, akkor rájövünk, hogy szükségünk lehet egy „túsz tárgyalóra”, ha a fizetés mellett döntünk, ami ugye a „normál” katasztrófák esetén nem jellemző. Viszont a gyakorlat azt mutatja, hogy a bűnözők hajlandók némi engedményre, így érdemes tárgyalni, de ez tárgyalás is egy külön szakma és cégméret függő, hogy megéri-e. USA-ban, ahol már biztosítást is lehet kötni zsarolóvírus támadásra, a biztosítók számára teljesen természetes, hogy megpróbálnak alkudozni. Hiszen kisebb a kiadás.

Még egy nagyon fontos aspektus az idő és az ezzel járó stressz. Bár talán viccnek tűnt, teljesen valid az, amit a pánikról írtam. Amikor leáll a cég teljes infrastruktúrája egy zsarolóvírus támadás miatt, biztosak lehetünk benne, hogy pánik lesz. A támadók ezzel számolnak is és próbálják növelni, hiszen ez nekik kedvez. Ezért van, amikor az első nap (első héten) alacsonyabb a váltságdíj. Utána egyre magasabb lehet. Ebben a helyzetben nagyon jól tud jönni az, ha egy (kitesztelt) eljárást elő lehet venni a szekrényből és az alapján azonnal ki lehet osztani a feladatokat. Ha az emberek azt látják, hogy legalább egyvalaki tudja, hogy mit csinál, akkor megnyugszanak és végzik a rájuk bízott feladatot. De ha abban a stresszben kell kitalálni, hogy mi történjen, na az nem egyszerű.

Remélem, hogy mostanra mindenki érti, hogy miért érdemes külön üzletfolytonossági terv a zsarolóvírusra. Legfeljebb sokan azt gondolják, hogy náluk nem lesz ilyen, mert vettek egy méregdrága tűzfalat és van VPN. Szerintem a Colonial Pipeline CISO-ja is ezt gondolta, vagy a már említett UNIX-é is, hogy közelebbi példát mondjak. Szóval a szkeptikusoknak üzenem, hogy természetesen bárkinek lehet szerencséje, de ahogy „épelméjűekre nem lehet világfürdőhelyet bazírozni*”, úgy nagyvállalatot a szerencsére sem.

(*Rejtő Jenő: 14 karátos autó)

A cím az üzletmenetfolytonossági tervről szól, mint talán a legmagasabb szintű folytonossági terv, de sajnos ahogy ez a fentiekből már kiderült, a krízis kommunikációs terv (Crisis Communication Plan), a biztonsági eseménykezelési terv (Cyber Incident Response Plan) és a katasztrófa elhárítási terv (Disaster Recovery Plan) is kiegészítésre szorul, úgyhogy jó tervezést!