bardóczi ákos @post.r

Milyen mulasztás történhet egy megyei kórházban következmények nélkül, amiért egy pénzintézetben fejek hullanának? Ransomware támadás áldozatául esett a veszprémi kórház a hétvége folyamán, ahogy arról többek közt az ATV is beszámolt.

A ransomware-ek a kártékony programok azon típusa, amelyik tipikusan email csatolmányaként érkezik, majd ha a felhasználó kellően ostoba hozzá, hogy az ismeretlen feladótól érkező, ordítóan gyanus csatolmányt megnyissa, a zsaroló program települ a gépre és a helyben tárolt felhasználói adatok elérhetetlenné tételén túl nem ritkán elérhetetlenné tesz minden mást is, amit csak lát: hálózati meghajtókon, megosztásokon keresztül szinte mindent. Teszi mindezt úgy, hogy egy valóban erős titkosítással titkosítja a felhasználó fájljait. Ha a felhasználónak nem voltak biztonsági mentései, lehetőleg air-gapped, azaz hálózatról leválasztott adathordozón az adatairól, így járt. A kártevő kedvesen felajánlja, hogy a fájlokat ismét elérhetővé teszi, akkor, ha a felhasználó váltságdíjat fizet értük. Az ATV-s riportban elhangzottal ellentétben a váltságdíjat sosem bankszámlaszámra kell utalni, hiszen az azonnal visszakövethető lenne, hanem a deep web jó öreg, jelen tudásunk szerint gyakorlatilag visszakövethetetlen keményvalutájában, bitcoinban kell fizetni.

Vannak olyan ransomware-variánsok, amik annyira kifinomultak, hogy figyelmeztetik a felhasználót rá, hogy idővel a váltságdíj folyamatosan duplázódik, ami fokozza a pszichikai hatást, a felhasználó pedig fizet, jó esetben pedig valóban visszakapja az elérhetetlenné tett adatait, amit azonban semmi sem garantál.

Ahogy egy-egy gépen egyre nagyobb mennyiségű és egyre nagyobb értékkel bíró információ koncentrálódik, jól mutatja, hogy bizonyos zsaroló vírusok akár 2000 USD-nak megfelelő váltságdíjat is kérhetnek bitcoinban, nyilván teszik mindezt azért, mert bizony a felhasználók egy jókora részének már megér annyit az, hogy ne vesszen el végérvényesen az összes dokumentumuk, fotójuk, videójuk és egyéb fájljaik, amit valaha is készítettek, ha nincs róla biztonsági másolat.

A ransomware-ek terjedése olyannyira nem új jelenség, hogy az egyik kezdetleges változata már 2-3 évvel ezelőtt szabályosan letarolta a SOTE hálózatához tartozó több kutatócsoport gépparkját is, nem kímélve semmit, márpedig ha eleve költséges kísérleteket kell megismételni a biztonsági másolatok hiánya okán bekövetkező adatvesztés miatt, igencsak fájdalmas tud lenni.

A Debreceni Egyetemen nem túl rózsás a helyzet, ha külön körlevélben hívták fel a felhasználók figyelmét a múlt héten arra, amire korábban már számtalanszor, azaz hogy ne kattintsanak ész nélkül mindenre – persze ettől még fognak, egészen addig, amíg a saját bőrükön nem tapasztalják meg a kárt.

A helyzet már csak azért is igencsak súlyos, mert a vírusoknak olyan polimorfjai jelennek meg, amiket könnyen lehet, hogy az antivírus-termék nem fog kiszúrni azonnal, ráadásul ilyen vírus variánsok létrehozására még kitek is rendelkezésre állnak, azaz egy pusztító kártevő egy új változatának létrehozásához már már érteni sem kell a programozáshoz.

Visszatérve az eredeti hírre, túl sok konkrétum nem derül ki, nagyjából csak annyi, hogy valaki, feltehetően még csak nem is privilegizált, magasabb jogosultságokkal rendelkező felhasználó a veszprémi kórházban nem túl bölcsen megnyitotta mondjuk a nigériai főhercegtől érkező Viagrás árajánlatot, ami elég is volt hozzá, hogy földhöz vágja a teljes hálózatot, ezért a kórházi adminisztráció lényegi részét papír alapon kelljen végezni.

Kérdem én, miféle IT biztonsági házirend van érvényben egy olyan helyen, ahol egy mezei felhasználó hülyesége ekkora kárt tud okozni, de mégis? Ezek szerint vagy még nem hallottak a minimálisan szükséges jogosultságok elvéről, ami kimondja, hogy minden felhasználó egy adott rendszerben pontosan annyi jogosultságot kapjon, amennyi a tevékenysége elvégzéséhez szükséges, de egy grammnyival se többet vagy éppen hallottak az elvről, csak éppen betartani nem tudták. Mert feltehetően nem a rendszergazdák valamelyike vágta gallyra a hálózatot egy duplaklikkel, abban pedig szinte biztos vagyok, hogy azt, akinek a fertőzést köszönhetik, nemhogy felelősségre vonni nem tudják, de még azt sem tudják utólag megállapítani, hogy ki volt.

Ilyenkor körlevélben megy egy kis ejnye-bejnye, na meg figyelmeztetés azzal kapcsolatban, hogy tessék jobban vigyázni, az egység sugarú felhasználó pedig még mindig ott tart, hogy ő csak a munkáját végezné, erre jönnek ezek a csúnya számítógépes bűnözők, aztán izgalmasabbá teszik az életet. Hát nem! Amiatt, hogy ennyire tragikusan rossz a helyzet globálisan, a felhasználó is tehet. A felhasználók pedig nem veszik észre, hogy biztonságtudatosság nélkül használni a gépet olyan, mintha sosem zárnák a házuk, na meg kocsijuk ajtaját, mert csak az hibáztatható, aki betör a házba vagy elköti a verdát.

Kicsit előreszaladok – még néhány hónappal ezelőtt beszéltem egy, a hazai bankok informatikai biztonságával foglalkozókat tömörítő szervezet egyik vezetőjével, akit arról kérdeztem, hogy világos, hogy a felhasználók ennyire tompák voltak 10, 15 vagy 20 évvel ezelőtt, de hogy lehet, hogy ez gyakorlatilag semmit sem változott, csak éppenséggel ma már nem MSN-üzenetben jön az áldás, hanem Facebook-linkek formájában vagy email csatolmányként. Mire jött a válasz, amihez túl sokat nem is tudnék hozzátenni: miért feltételeznénk, hogy az emberek változnak?

És valóban: magatartástudományi ismereteim fényében röviden én is csak annyit tudok mondani, hogy a biztonságtudatos magatartást csak akkor lehet elvárni a felhasználóktól, ha tartanak a felelőtlenségük következményétől.

Általános összefüggés, hogy egy szervezetben minél inkább közvetlenül kifejezhető pénzben és minél látványosabb egy breachből adódó kár, a szervezetre annál szigorúbb standardok vonatkoznak, nem csak technikai szempontból, hanem emberi oldalról szintén. Gondoljunk csak a légi irányításban használatos szoftverrendszerekre vagy az ipari vezérlőrendszerekre, ahol egy-egy IT-politikával egybefüggő mulasztás, szoftverhiba vagy sikeres informatikai támadás emberéletekbe kerülhet, míg egy pénzintézet esetében is a szervezet saját bőrén érzi, ha az informatikai rendszerben meghibásodás történik.

Nem véletlen, hogy minden, úgymond rázósabb területen saját iparági standardokat alakítottak ki és tartatnak be annak érdekében, hogy az informatikai eredetű kockázatokat és károkat minimalizálják. Ezek a standardok annál inkább belemennek a részletekbe, minél inkább kritikus infrastruktúrát kell védeni. Hogy az Olvasó is képbe legyen: külön forgatókönyvek és szabályzatok deklarálják, hogy a biztonsági mentéseket hogyan kell kezelni, milyen szabályok vonatkoznak a biztonságos felhasználói azonosítására, a felhasználók magatartására, a szervezeten belüli információcsere részleteire és így tovább.

Ami viszont a lényeg: még a leginkább penge módon kidolgozott, sokezer oldalas szabályzatok sem érnének semmit abban az esetben, ha a szabályok megszegése nem lenne szankcionálva. Rémes leírni, de a felhasználók közt még azok is, akik egyébként a kockázatokkal tisztában vannak, nem értenek a szép szóból, a szabályok betartatása pedig a cég IT biztonságáért felelős CISO-k számára állandó, lassacskán már az egyik legfajsúlyosabb kihívást jelenti. Nem csoda, hiszen ha egy relatív alacsonyabb beosztásban lévő alkalmazott hibájából történik meg a baj, belső vizsgálatot, fegyelmit lehet indítani ellene, el lehet bocsátani, esetleg a törvény előtt is felelnie kell, viszont sokkal bonyolultabb a helyzet akkor, ha az, aki a hibát elköveti, középvezető vagy éppen felsővezető, akit érthetően nehezebb felelősségre vonni.

Ezen a területen a néhány évvel ezelőttihez képest jelentős fejlődés, hogy a CISO-k egyre több helyen már közvetlenül a menedzsmentnek számolnak be, ezen kívül a cégek felsővezetői is egyre nagyobb jelentőséget tulajdonítanak az informatikai biztonságnak.

Nemrég hallgattam egy kitűnő előadást azzal kapcsolatban, hogy egy nagy-nagy banknál hogyan is történik az informatikai incidensek kezelése és általában mik a tipikusan elkövetett hibák. Bizarr vagy sem, de megkísérlem összehasonlítani tényleg csak néhány ponton, hogy mik a legmarkánsabb eltérések a példánál maradva pénzintézeti környezetben működő IT infrastruktúrák üzemeletetése és használata, valamint sokkal köznapibb helyeken, azaz például kisvállalkozásoknál, közoktatási vagy felsőoktatási intézmények háza táján.

Felhasználói azonosítás

Ha van valami, amivel napi rendszerességgel ki lehet kergetni a világból a rendszergazdát vagy a IT biztonsági főnökök, az egyik ez. Hiába a megfelelően erős jelszavakkal kapcsolatos ajánlások valamint konkrét előírások, nap, mint nap előfordul, hogy az egyik felhasználó a másiknak kényelemből odaadja a felhasználói nevét és jelszavát. Fájóan hosszú lenne boncolgatni, hogy elvi szempontból is miért hatalmas hiba illetve kockázat, még abban az esetben is, ha egy magáncélra használt, súlytalanabb webes szolgáltatásról lenne szó, nem még hogy valamilyen munkahelyi belépésről. Ha egy alkalmazott a másik nevében végez nem kívánt műveleteket vagy éppenséggel akaratlanul pont akkor fertőzi le a gépet valamilyen kémprogrammal, utólag nyilván megállapíthatatlan, hogy az egyik vagy  a másik alkalmazott hibázott, azaz kinek kellene elvinni a balhét. Pénzintézeti környezetben az ilyet szigorúan szankcionálják, ezen kívül további lépéseket építenek az azonosítási folyamatba a jelszó mellett, de én még olyanról nem nagyon hallottam, hogy valakit felelősségre vontak volna azért, mert a hozzáférési adatait kölcsönadta valakinek. Egyébként van pozitív példa is: az egyik nagy hazai egyetemen az ilyenért a felhasználó felkerült az informatikai szolgáltató központhoz, géptermekhez vezető hülyetáblára, ezen kívül be sem léphet egy ideig.

Ismertté vált szoftverhibák javítása, rendszeres frissítések

Ideális esetben az IT team amellett, hogy technikai szinten meghatározta a biztonsági házirendet [jogosultságok kiosztása szerepkörök szerint, tűzfalkonfiguráció, APT-védelem, stb.] néha rá is néz a tűzfal naplófájljaira és kiszúrja a gyanus műveleteket, amiket ma már fejlett naplóelemző alkalmazások segítenek. Ha pedig megtörtént a baj, például egy szoftverhibát kihasználva feltörték a céges aloldalt, nem csak visszaállítja azt az eredeti állapotába, hanem megszünteti azt a sebezhetőséget jelentő beállítást vagy szoftverhibát, ami azt lehetővé tette. Ehhez képest például a feltört weboldalak esetén a helyreállítás megtörténik ugyan, viszont a tartalomkezelő rendszerben benne marad ugyanaz a hiba, ami lehetővé tette a sikeres támadást egy kisebb szervezet esetén.

A néhány héttel ezelőtti előadásban viszont az is szóba került, hogy esetleg az IT-staff nagyon nem szivesen nyúl egy megtorpedózott alrendszerhez a helyreállítást követően, mivel tartanak a hibajavítás idejére eső kiesés következményeitől. Mivel egy komolyabb rendszerben egy hibát nem elég pusztán javítani, hanem a módosított rendszert teszteken, közelebbről, unitteszteken, rendszerteszteken, állapotátmenet-teszteken, keresztül kell ellenőrizni, ami sokszor akár több időt is igénybe vehet, mint maga a fejlesztés vagy a bugfix.

Azt pedig egy pillanatig se felejtsük el, hogy bizonyos rendszerek időleges kiesése az üzletfolytonosságot veszélyeztetnék, még néhány perces kiesés sem fogadható el. Márpedig hiába van tartalék rendszer arra az esetre, ha egy ilyen kritikus fontosságú rendszer leállna. A hibajavítás sokszor nem oldható meg leállítás és újraindítás nélkül, ha pedig a leállítás idejére a tartalék rendszert indítják el, az értelemszerűen ugyanazt a sebezhetőséget tartalmazza és azzal fog futni, a karbantartás ideje alatt így arra az időre a sebezhetőség is kihasználható. Akár a 22-es csapdája, nem? Nem csoda, hogy igen kackiás általános, de magas szintű vagy kimondottan iparági jellegzetességekre szabott protokollok vannak előírva az ilyen esetekre.  

A magas szintű informatikai biztonságot igénylő iparágakkal párhuzamosan persze kialakult azoknak a minősítéseknek a rendszere, ami sokszor beugró ahhoz, hogy valaki ilyen típusú feladatot lásson el. Ezek közül a legismertebbek az ISACA, az EC-Council, az Offensive Security certijei, vagy éppen a GIAC minsőítései, amiket megszerezni nem könnyű persze, viszont jóval nagyobb értékkel bírnak, mint a hagyományos tudományos fokozatok.

Másik gyakori hiba, a megfelelő biztonsági mentés hiánya

A biztonsági mentés, akár kézzel kell végezni, akár automatizálva van, amilyen lélekölő, annyira hasznos, ha egy megsérült rendszer adatait mentésből kell helyreállítani. A leggyakoribb probléma természetesen az, hogy nincs használható biztonsági mentés vagy éppenséggel van, de az annyira régi, hogy látta az élő Lenint, ilyen módon nem sokat ér. A legtöbb helyen nincs is policy azzal kapcsolatban, hogy a biztonsági mentést milyen gyakran, hogyan, kell elkészíteni, ahogy persze szankcionálva sincs, ha egy súlyos adatvesztés után az egyszeri rendszergazda nem tudja elvégezni a megfelelő helyreállítást. Banki környezetben természetesen ez is máshogy működik.

Ha mentésről van szó, mondanom sem kell, itt is egy nagyon szerteágazó, kérdések áradatát felvető témáról van szó. Például nem elegendő rendszeresen biztonsági mentéseket végezni, azok sértetlenségét, működőképességét is ellenőrizni kell.

Nincs vagy hiányosan van előírva, hogy a felhasználók hogyan kezelhetik az IT-eszközöket és magukat az információkat

Nem, most tényleg nem csak arra gondoltam, hogy a legócskább social engineering támadásokkal szemben is védtelen a cégek és közintézmények többsége.
Kicsit is normális helyen háztáji szerveren vagy megbízható privát felhőben történik a céges információk tárolása és kezelése, ahogy maga a céges kommunikáció is, ahogy a cloud technológiák évről évre egyre olcsóbbak váltak.

Annak ellenére, hogy a cégek az igényeknek megfelelően saját levelezéssel, tárhellyel, vagy akár komplett ERP-vel rendelkeznek, nagyon gyakori, hogy céges adatokat küldözgetnek át az alkalmazottak egymásnak kommersz, ingyenes levelezőrendszerekben, de olyat is hallottam már, hogy egy közösségi szolgáltatást használtak ilyenre. A rendszergazda, ha tud is róla, jó esetben legalább valamiféle képe van azzal kapcsolatban, hogy ez mekkora kockázattal jár, mégsem nagyon tud mit tenni ellene.

Mielőtt úgy gondolnánk, hogy csak a közvetlenül pénzzé tehető adatvagyon egy részét használó felhasználók jelentenek kockázatot a fegyelmezetlenségükkel, képzeljük el, hogy egy nagy szerkesztőség újságírója kényelemből valamilyen ingyenes kommersz levelezőrendszert használ, amikből meg sok esetben végképp nem nehéz észrevétlenül szivárogtatni az információt jelszólopással, kémprogrammal, akármivel, viszont mivel a postafiók nem a céges rendszerhez tartozik, a rendszergazdának esélye sincs észlelni ezt. Ebben az egyszerű példában képzeletbeli újságíró barátunk veszélybe sodorhatja az informátorait, lenyúlhatják a postafiókjából a mástól hozzá érkező kéziratokat és így tovább. Csak a fantázia szab határt annak, hogy mekkora kavar lehet abból, ha házon kívülre viszik a céges adatokat, mivel a felhasználók egyszerűen nem veszik figyelembe, hogy az nem az ő tulajdonuk, hanem a cégé!

Viszont nem egy esetet hallottam, amikor a céges eszközöket egyáltalán nem használták, ráadásul az egyik legnagyobb magyar, tartalomszolgáltatással foglalkozó cégénél. Ezt ismétcsak úgy lehetne kivédeni, ha következetesen szankcionálnák a cégen belül, ha valaki céges adatokat nem az arra fenntartott infrastruktúrán kezel. Ezen kívül persze, nagy szerepe van annak, hogy az alkalmazottak kapjanak biztonságtudatossági tréninget, már ahol egyáltalán tudják is, hogy mi az, még ha bizonyos szempontból egyre nehezebb is. Kevin Mitnick nem mondott nagy újdonságot azzal, amikor azt mondta, hogy a felhasználók a biztonsági előírásokat akkor fogják betartani, ha látják annak az értelmét. Viszont manapság már a támadások olyannyira szofisztikálttá váltak, hogy az az átlagos felhasználónak túl bonyolultak, amit csak úgy lehet kompenzálni, ha technikai módszerrel korlátozzák, hogy a felhasználó mit tehet meg és mit nem, ahogy írtam, a jogosultságok kiosztását meg kell, hogy előzze a szerepkörök pontos meghatározása.

Fontos megjegyezni, hogy ha a belső használatra szánt eszközök nem eléggé rugalmasak, stabilak és felhasználóbarátak, ahol ezt szankciómentesen megtehetik, az alkalmazottak Gmailt, Google Docst, Dropboxot és hasonló kommersz eszközöket fognak használni a céges adatok kezeléséhez is. Ezzel értelemszerűen menedzselhetetlenné válik a cég információáramlása, megnehezíti az incidensek vagy éppen az adatszivárgások, azaz DLP-k megelőzését kivizsgálását. Ráadásul ezek a közkeletű ingyenes szolgáltatások formálisan semmiféle felelősséget nem vállalnak a náluk tárolt felhasználói adatokért, az azok elvesztéséből adódó károkért, gyakorlatilag pedig egész egyszerűen nem elég biztonságosak. Nem, még akkor sem, ha a fél világ arról cikkezik, hogy azok.

Mit tehet mégis egy közepes méretű vállalat, amelyik nem foglalkoztathat CISO-t főállásban, a céges rendszergazda tehet szert csak úgy olyan szintű tudásra, mint egy CISO, ugyanakkor szeretné biztonságban tudni az általa kezelt információkat? Külső szakértőt megbízni mindenképp ajánlott, akivel együtt a házirendet ki tudják dolgozni és időnként felül is tudják vizsgálni.

Ez persze szubjektív, de szerintem a dolog legérdekesebb része, hogy hogyan építsenek a házirendbe olyan részt, ami kimondottan azzal foglalkozik, hogy az emberi tévedésből, mulasztásból, figyelmetlenségből vagy social engineering támadások kiküszöbölhetőek legyenek és azt tényleg mindenki tartsa be.

Ahogy írtam, annál hatékonyabb a megelőzés, minél inkább ismert a támadások kivitelezésének módja.

Amit rendkívül hasznosnak találtam a Social Engineering Penetration Testing – Executing Social Engineering Pen Test, Assessments and Defense kötet végén található cheat sheetet, ami kellő részletességgel, ugyanakkor áttekinthetően mutatja a social engineering támadások általános sémáját.

Idén jelent meg ebook formájában ingyenesen letölthető kiadványként a Navigating the Digital Age – The Definitive Cybersecurity Guide for Directors and Officers kötet, kimondottan cégvezetőknek, ami a legfrissebb tények tükrében foglalja össze az informatikai biztonság fontosságát.

Igen ám, csakhogy a cégek felsővezetői könnyen lehet, hogy nem szivesen futnak neki egy közel 400 oldalas könyvnek, így gyakorlati szempontból talán még jobbak azok a Dummies-füzetkék, amit különböző gyártók támogatásával jelentetnek meg rendszeresen és ugyancsak ingyenesen letölthetőek. Ha pedig a cégvezetők a szükséges mértékben értik a cég vérkeringését jelentő IT-rendszerek működését, jobban megértik egymást az informatikai csoporttal. Ilyen ingyenes kiadvány például a Cybersecurity for Dummies, a Network Security in Virtualized Data Centers for Dummies, a Mobile Security for Dummies, az Advanced Endpoint Protection for Dummies vagy éppen a Paloalto mellett a Fortinet által támogatott Dummies-könyvek, mint a Unified Threat Management for Dummies,
csak hogy a legfrissebb információkat tartalmazó kiadványokat említsem, amiket egy-egy elfoglalt cégvezető szivesebben vesz kézbe nyomtatva, mint egy jóval vaskosabb kiadványt.

Az IT-seknek szükséges könyvek ára sokszor be van építve egy-egy képesítés anyagába.

A magyar nyelvű, frissen megjelent könyvek közül átfogó műként a Vállalati információs rendszerek műszaki alapjait találtam a legjobbnak, ugyan annak tartalma már túlmutat a menedzsment tagjai számára szükséges ismereteken.