ÜZLETI IT- Tartalmas, előremutató, vicces de közben halálosan komoly

EURO ONE

Ransomware: hatékony védelmi praktikák a zsarolóvírusok ellen

Krékity Gusztáv cikke

2021. október 22. - EURO ONE

Az elmúlt hetekben, hónapokban egy hosszabb sorozatban foglaltuk össze, milyen - sajnos folyamatosan megújuló - módon használják ki a kiberbűnözők a zsarolóvírusokban rejlő potenciált. Korábbi bejegyzéseinkből kiderült például, hogy az elmúlt évek során a ransomware variánsok funkciói kibővültek az adatok minősítésével és előszűrésével, vagy például létezik olyan verzió amely attól függetlenül törli az adatokat és fájlokat, hogy fizetett-e az áldozat vagy sem. De terítékre kerültek olyan változatok is, amelyek a felhő alapú biztonsági mentéseket zárolják, DDoS (elosztott szolgáltatásmegtagadás) támadásokhoz csatlakoznak, vagy éppen IoT eszközöket titkosítanak.

ransomware--hatekony-vedelmi-praktikak.jpg

Sajnos a zsarolóvírusok rendkívül változatosak, szerteágazók és igencsak veszélyesek. Hosszasan tudnánk még sorolni a variánsokat és azok sajátosságait. Ezúttal azonban nem az újabb ransomware verziókról lesz szó, inkább szeretnénk kicsit elkanyarodni a gyakorlati megoldások felé: csokorba szedtünk néhány olyan tanácsot, amelyek segítségével jó eséllyel elkerülhető, hogy egy sikeres támadás áldozatai legyünk. S bár egy ilyen ajánlás sosem lehet teljes körű, de jól bevált gyakorlatokat tartalmaz, köztük olyan praktikákkal, amelyeket végfelhasználók és vállalatok egyaránt hasznosíthatnak, hogy képesek legyenek jelentősen lecsökkenteni annak a lehetőségét, hogy ransomware támadás áldozatai legyenek.

Általános tanácsok a zsarolóvírusok elleni védekezéshez

Mint fentebb említettük, az alapvető - és a gyakorlatban már jól bevált - kiberbiztonsági praktikákból válogattunk ezúttal, amelyeket érdemes megfontolni és betartani, mert a segítségükkel minimalizálhatjuk a károkat egy esetleges zsarolóvírus támadás során. Ezek nem cégre vagy egyénre szabott ajánlások és sajnos azt sem tudjuk megígérni, hogy százszázalékos védelmet nyújtanak a támadások ellen - ha valaki olvasta korábbi bejegyzéseinket, tudja, hogy ez utóbbi sajnos szinte lehetetlen -, viszont jelentősen csökkenthetjük velük a kockázat. Éppen ezért érdemes ezeket minden vállalatnál bevezetni és folyamatosan ellenőrizni.

  1. Rendszeres biztonsági mentések készítése: A létfontosságú adatokról rendszeresen készüljön biztonsági mentés. Így a támadásokban esetlegesen érintett adatok visszaállíthatók egy korábbi biztonsági mentési pontra.
    Fontos, hogy a biztonsági mentéseket érdemes időről időre rendszeresen tesztelni, hogy valóban minden mentett adat teljes, visszaállítható. A sérült backup adatok ugyanis pont olyanok, mintha nem is lennének.
  2. Rendszeres frissítések: A vállalatok egyre több gyártó megoldásait használják a rendszerben, s mint minden szoftverben, ezekben is lehetnek előre nem ismert programozási hibák, amelyeket a támadók előszeretettel kiaknáznak. Szerencsére minden vendor rendszeresen ad ki - a már ismert - hibákra, sérülékenységekre vonatkozó foltozásokat, javításokat. Ezek a frissítések olyan javítócsomagok, amelyek biztonságosabbá tudják tenni a szoftvereket az ismert fenyegetésekkel szemben. Alkalmazásuk adatvédelmi szempontból létfontosságú, így a rendszeres frissítéseket előre ütemezetten kell a változás menedzsmentbe betervezni és kijelölni a végrehajtásukért felelős személyt. A rendszeres frissítéssel csökkenthetjük a támadási felületet és a potenciális támadóvektort.
  3. Hitelesítő adatok lekövetése: Minden alkalmazott, aki hozzáférést kap, a céges belső rendszerekhez, potenciális biztonsági rést hozhat létre a zsarolóvírusok – vagy bármely más támadási forma – számára. Éppen ezért fontos például a rendszeres jelszó frissítési házirend és szabályozás, vagy épp a megfelelő hozzáférési korlátozások kialakítása.

Teljes felkészülés: reagálási tervek, védelmi eszközök, gyakorlati praktikák

A fenti, általánosabb javaslatokon felül érdemes még a hálózatokat és a végfelhasználókat egyaránt felkészíteni egy esetleges incidensre. Fontos előre megtervezni a reagálási terveket, hogy magabiztosan tudjuk, milyen lépéseket kell végrehajtani egy sikeres támadást követően, hogyan lehet hatékonyan minimalizálni a károkat és a lehető leggyorsabban visszaállítani a rendszer működési kapacitását. Amennyiben ezekkel nem kalkulálunk és megtörténik a baj, a károk mértéke előre felbecsülhetetlen lesz, mivel az nagyban függ a cég méretétől, profiljától és attól, hogy a támadó mihez fért hozzá, milyen adatokat tudott megszerezni, titkosítani.

Erre vonatkozólag is következzen néhány hasznos, gyakorlati tipp, amelyekkel el lehet indulni és megállapítani, hogy egy sikeres támadás után milyen lépésekre vagyunk felkészülve a helyreállítás és kivizsgálás során.

  1. Rendelkezzünk esemény reagálási tervekkel (Incident Response), amelyeknek tartalmaznia kell azokat az információkat és leírásokat, hogy mi a teendő, ha ransomware támadás történik.
  2. Használjunk fejlett végpont védelmi megoldást és SPAM szűrő biztonsági megoldásokat. A fejlett (EPP/AEP) megoldások segítségével hatékonyan védekezhetünk a zsarolóvírusok ellen, mivel a legtöbb megoldás dedikált olyan ransomware protection modullal rendelkezik, amely képes a titkosítási folyamat blokkolására, sőt, egyes eszközök a már titkosított adatok visszaállítására is képesek, adott esetben backup rendszerek nélkül is.
    A SPAM szűrők szintén nagyon fontosak, hiszen a rengeteg támadás - az esetek 94%-a - levelezéssel kerül az kezdődik. Érdemes megfontolni, hogy olyan rendszert válaszunk, amely képes figyelmeztetéssel ellátni az üzenet tárgyát minden olyan esetben, amikor ismeretlen külső forrásból vagy nem megbízható címről kapunk levelet. Így a felhasználók időben figyelmeztethetők, hogy óvatosan kattintsanak levélben található a linkre vagy a csatolmányra.
  3. Érdemes letiltani a makrók parancsfájljait. Érdemes megfontolni az Office Viewer szoftver használatát az e-mailben továbbított vagy beérkezett Microsoft Office fájlok megnyitásához a teljes csomag letöltése helyett.
  4. Korlátozott céges internet hozzáférés bevezetése. Ez elég szigorú megoldás, amelyet meglehetősen ritkán, inkább csak szélsőséges helyzetekben alkalmaznak, de sok nagyvállalati környezet megköveteli a magán és céges internet használat szeparációját, illetve a forgalom megfelelő szűrését. Gyakori eset, hogy a tűzfal vagy egy proxy megoldás szabályozza a veszélyes, pornográf vagy nem megbízható oldalak használatának lehetőségét.
  5. Többtényezős hitelesítés bevezetése (MFA) különösen az RDP szerverek felé.
  6. Belső hálózati szegmentáció kialakítása (ISFW) és Zero Trust architektúra alkalmazása a támadók lelassítására.
  7. XDR megoldások integrációjával növelhető a rendszer átláthatósága és a válaszidők jelentősen javíthatók egy támadás során, amikor minden másodperc számíthat.
  8. A third party megoldások fokozott ellenőrzése is fontos szempont, hiszen sok esetben olyan megoldásokról beszélünk – van ahol egyedi, saját fejlesztésről – ahol bizonytalan a javítócsomagok fejlesztése, kiadása vagy épp ellenőrzése. Ez különösen igaz azokra a megoldásokra, amelyek távoli hozzáféréssel rendelkeznek a szervezet hálózatához.
  9. Csatlakozzunk kiberbiztonsági információ megosztásokhoz (CTI) amelyek segítségével olyan támadásokról is tudomást és információkat szerezhetünk, amelyek nem közvetlenül bennünket érintenek. Ilyen szervezet például az MS-ISAC vagy az Infragard.
  10. Nagyon fontos a felhasználók oktatásának megtervezése és a biztonságtudatosság növelése. Érdemes titkos Phishing auditokkal ellenőrizni az alkalmazottak éberségét, hogy egy valós támadás során mekkora valószínűséggel és kik válhatnak potenciális áldozattá, s jelentenek így a cég számára potenciális biztonsági kockázatot. Érdemes az alkalmazottakat emlékeztetni, hogy zárolják a gépeket amikor nincsenek ott, illetve ne nyissanak meg ismeretlen forrásból származó leveleket, ne csatlakoztassanak ismeretlen meghajtókat a számítógépükhöz stb.
  11. Érdemes létrehozni egy olyan címet a szervezeten belül, amelyen az alkalmazottak bejelenthetik, ha gyanús tevékenységet észlelnek.

Utólagos lépések és kármentés

A fentiekkel hatékonyan védekezhetünk a ransomware támadások ellen, de mint már említettük: tökéletes védelem nincs. A kibernűzözők pénzt és időt nem kímélve dolgoznak azon, hogy fejlesszék eszközeiket a sikeres támadások érdekében. Így jogosan merül fel a kérdés: mit tehetünk, ha már megtörtént a baj? Lássuk, milyen reaktív lehetőségeket érdemes gyorsan végrehajtani.

  1. Érdemes azonnal felmérni a helyzetet, hogy mielőbb kiderüljön, a támadó milyen rendszereket ért el és mit tudunk az adott pillanatban a támadásról.
  2. Válasszuk le a fertőzött rendszert a hálózatról, hogy izolálhassuk a fertőzés további terjedésének a megakadályozására. Viszont ne kapcsoljuk ki a gépet!
  3. Kezdjük el beazonosítani az érintett adatokat és rendszereket. Meg kell határozni, hogy bizalmas információk is veszélybe kerültek-e vagy személyes adatokat tartalmazó fájlokhoz is hozzáfértek-e a támadók. Amennyiben igen, úgy már az IR tevekénységen felül a megfelelő szervek felé is el kell kezdeni jelentést készíteni.
  4. Próbáljunk meg mintavételezést végrehajtani a kompromittálódott rendszerből és próbáljuk meg kideríteni, hogy van-e elérhető dekódoló eljárás. Vannak olyan zsarolóvírusok, amelyeknek a visszaállítása is lehetséges, mert a kódban van a kulcs.
  5. Amennyiben a mentést nem titkosították – sajnos egyre több esetben a támadók a backup szerver titkosításával kezdenek – és rendelkezünk ellenőrzött visszaállítási ponttal, akkor töltsük vissza rendszert. Így csak az utolsó mentés és a támadás közötti adatok vesznek oda. Ezáltal minimalizálható az adatveszteség és a leállási ablak.

Összegzésül

A fenti tanácsok megfogadásával és alkalmazásával jelentősen csökkenthetjük az esélyét annak, hogy ransomware támadások áldozatai legyünk. Ha pedig mégis megtörténik a baj, ezen tippek segítségével jó esélyünk lesz a károk minimalizálására és a munkafolyamatok helyreállítására.

Záró akkordként szeretnénk mindenki figyelmébe ajánlani sorozatunk eddig megjelent cikkeit, amelyekből megismerhető a zsarolóvírusok működése, a ransomware támadások fejlődése, a kiberbűnözők támadásokhoz használt eszköztára, sőt, még a zsarolóvírusok mögött álló üzleti folyamatok is. A védekezés hatékonyabbá tételét az is nagyban elősegítheti, ha pontosan tudjuk, mivel állunk szemben. Éppen ezért érdemes elolvasni a sorozat korábbi darabjait is:

EMELD A TUDÁSODAT AKADÉMIAI SZINTRE, CSATLAKOZZ EXKLUZÍV KLUBUNKHOZ INGYENESEN!

Kedvcsináló: üzleti reggelin tárgyaljuk ki a SOAR rendszer előnyeit

Sajó Péter cikke

2021. szeptember 16. - EURO ONE

blogposzt-soar-siem.jpg

Ezúttal rendhagyó blogbejegyzéssel jelentkezünk, mert hamarosan egy üzleti reggeli keretein belül tárgyaljuk ki a SOAR rendszer előnyeit, alkalmazási területeit, s persze a kiépítéshez és felhasználáshoz is adunk majd gyakorlati tanácsokat. Nyilván mindenki más és más indíttatásból gondolkozik el a SOAR rendszerek bevezetéséről, de mi most segítünk részleteiben megismerni és átlátni ezt a technológiát, a gyártó (Palo Alto) által vázolt példákkal és egy olyan ügyfelünk (MVMI) élménybeszámolójával, aki már a gyakorlatban is felépített ilyet. Utóbbi már csak azért is tanulságos eset, mert megtudhatjuk belőle, miként segített egy évek óta kialakult Security Operation Centerben is ez a technológia, s milyen előnyökkel járt a bevezetése.

Az összhangot teremtő SOAR

Manapság egy nagyvállalat számára biztonsági szempontból az egyik legfontosabb eszköz a biztonságfelügyeleti rendszer, illetve az ahhoz tartozó, azt működtető biztonsági csapat. E csapat elemzőkből, mérnökökből, esetleg - nagyobb szervezetnél - incidens koordinátorokból áll. Ráadásul a csapatot alkotók nem egyedül dolgoznak, hanem szoros kapcsolatban vannak az üzemeltetéssel, illetve az üzemeltetésen belül még számos különböző csoporttal.

Egy ilyen biztonsági csapat felépítésével a vezetőknek napi szinten kell foglalkozniuk, hála a folyamatos - sőt, növekvő mértékű - szakemberhiánynak. Ráadásul képzett munkaerőből, akik ezen a területen azonnal bevethetők, úgyszintén nincs elegendő.

S miközben a vezetőknek a csapat felépítése és foltozgatása miatt fáj a feje, a támadások száma töretlen ütemben, folyamatosan növekszik. S ha ez még nem lenne elég, mostanában e támadások egyre nagyobb része épül gépi tanulásra (ML) és mesterséges intelligenciára (AI). Úgy tűnik, a kiberbűnözők az elsők között adaptálták ezen technológiákat, s használják immár napi szinten az összetett, automatizált támadásokhoz.

Ezekkel a kihívásokkal szemben persze rengeteg technológia megoldással élhetünk, s általában nem is a rendelkezésre álló technológiai háttér a gond, hanem az, hogy a fentebb említett csoportok rendkívül nehézkesen tudnak kommunikálni egymással. Nincs meg az összhang, pedig az a hatékony védekezés alapvető feltétele. Ebben tudnak segíteni a SOAR (Security Operation and Response) megoldások.

Kiknél és hogyan alkalmazható a SOAR?

Ha nagyon velősen szeretnénk megfogalmazni, hogy mi az a SOAR lényege, akkor azt mondhatnánk: ezek a biztonsági csapatok munkáját automatizáló eszközök. Ezen a piacon van jelen a Palo Alto is az XSOAR elnevezésű - a piac élvonalába tartozó - termékével. S hogy pontosan kiknek lehet jó választás mondjuk az XSOAR? Nos, mint minden céges eszköznél, nyilván itt is fontos szempont az úgynevezett érettségi szint, amelyből kiderül, milyen fokon áll a cég a Security Operation - a biztonságfelügyeleti rendszerek, a technológia, a folyamatok és az emberállomány - terén.

uzleti-reggeli-mutacio-940x370_eo_web.jpg

Ha valaki még semmi mást nem csinált, csak a jelenlegi technológiájának üzemeltetésére dedikált néhány embert, vagy legalább tervszerűen elkezdett ezzel foglalkozni, akkor azt tapasztaljuk, hogy számukra máshol ad előnyt a SOAR technológia, mint azoknál, akik már felépítettek egy SOC-ot, ahol a szabályrendszert már több éve fejlesztik, ahol az incidenseknek elemzése nagyrészt kialakult folyamatok mentén történik, és ahol már azon gondolkodnak, hogy miként lehetne ezeket a napi rutinokat folyamatosan csökkenteni. A SOAR technológia a fejlettség bármilyen szintjén komoly előnyt jelenthet, csak pontosan kell tudnunk, hogy kinél, milyen problémákkal kell számolni. Testreszabottan, de biztos, hogy használható és előnyös lesz.

Ha olyan példát keresünk, amellyel a cég méretétől függetlenül szinte biztosan küzd minden biztonsági rendszer, akkor vehetjük alapul a phishing e-maileket. A támadások 80-90 százaléka phishing próbálkozásokkal indul, a legtöbb kiberbűnözőnél ennek az eszköznek komoly szerepe van. Így aztán ez a legtöbb biztonsági csapatot is folyamatos feladattal látja el.

Mit jelent ez a napi gyakorlatban? Tulajdonképpen akár az is lehet, hogy több tíz vagy akár száz e-mail folyamatos megnyitása, a bennük lévő tartalom ellenőrzése, a rendszerből további információk begyűjtése, a tartalom malware vizsgálata, a csatolt fájlok, a szövegben elhelyezett linkek ellenőrzése, hogy van-e bármiféle káros tartalom. Ennek a vizsgálata, tehát az elemzési fázis - egyáltalán annak az eldöntése, hogy mondjuk egy SIEM rendszerből érkező, vagy egy e-mail védelmi rendszerből jövő riasztással foglalkozni kell-e -, rendkívül erőforrás igényes. Egy ilyen levél vizsgálata akár 3-5 percig eltart. Ha valaki napi szinten 10-100 ilyen e-mailt vizsgál át, akkor ki tudjuk számolni, hogy ez fixen mennyi energiát vesz el a biztonsági csapatból. Ráadásul amennyiben beigazolódik, hogy valóban ártó szándékú e-mailről van szó, akkor be kell vonni egyéb csapatokat is, például üzemeltetési oldalról. Emiatt létfontosságú, hogy át tudjuk adni az információkat más csapatoknak is, így hatékony ellenlépések történhessenek.

Ez az eset szinte minden cégnél előfordul, napi szinten. Márpedig egy-egy ilyen feladatot a SOAR rendszer, még az elemzési oldalon, látványosan képes felgyorsítani: gyakorlatilag 100 százalékban tehermentesíthetők az elemzők, vagyis rábízhatjuk magunkat egy ilyen SOAR rendszerre. Mindent automatikusan elvégez a beépített rule-ok és kialakított folyamatok alapján. Sőt, még az ellenintézkedéseket is elénk tárja, ennek köszönhetően pedig akár arról is dönthetünk, hogy valamilyen szinten ezt is automatizáljuk, vagy inkább manuálisan beavatkozunk. Ezek alapján a SOAR bevezetése egy kevésbé fejlett biztonságfelügyeleti rendszerrel, vagy kisebb biztonságfelügyeleti gyakorlattal rendelkező cégnek is komoly előrelépést jelenthet.

Amikor valaki már magasabb fejlettségi szinten van, a csoportok egymás mellett dolgoznak. Van már egy kialakult folyamat, ha nem is teljesen rögzített, de létező gyakorlattal arra nézve, hogy a különböző biztonsági incidenseket miként kezelik. Ilyen esetekben előbb-utóbb el szoktak érkezni ahhoz a ponthoz, amikor a gyakorlatot jó lenne - amennyire csak lehet - sztenderdizálni, hiszen a biztonsági csapatban az emberek folyamatosan változnak. Felvesznek újakat, pozíciót váltanak a csapaton belül, vagy épp kikerülnek a csapatból. Miközben jó lenne, ha ez a tudás végtelenül egyszerű módon, folyamatosan a csapat rendelkezésére állna. Ha egy csapat és a technológia fejlettebb, akkor egyre komolyabb problémákat is képesek menedzselni, ám ilyen esetekben, mivel több csoportnak a működéséről beszélünk, fontos szempont, hogy egy incidensnél viszonylag komoly információkat kell tudni gyorsan és hatékonyan megosztani egymás között.

Ha valakinek már fejlettebb csapata van, ott bizony sok idő eltelt, így adott esetben több éves gyakorlatuk van, sok pénzt emésztett fel a csapat felépítése, folyamatos képzése, az egyre komolyabb technológiák implementálása, így a felsővezetés nyilván jogosan vár el mérőszámokat is, hogy ez a team mennyire működik hatékonyan. Mennyire foglalkozik azokkal a feladatokkal, amelyek a legnagyobb kockázatot jelentik a szervezet számára. Ezeknél a csapatoknál egy SOAR rendszer másképp, de szintén óriási előnnyel kecsegtet, hiszen a technológiai információkat, az üzleti biznisz kontextust, mind egyetlen helyre csoportosítja. Így a folyamatokat előre kialakítva, jól mérhetően tálalja. Tulajdonképpen fogja az elemző kezét, tehát az elemzők mindig ugyanazt csinálják. Legyen az egy éve dolgozó vagy pár hónappal ezelőtt belépő munkatárs, a tudás átadása megtörténik a folyamatos embercserék ellenére is. Mivel a SOAR-ban ott a korábban feltárt és lekezelt incidenseknek lenyomata, az ezekkel kapcsolatos tudástár felépíthető, ami nagy mértékben felgyorsítja a már ismert típusú támadások elhárítását, gyorsítva, hatékonyabbá téve ezzel a csoport munkáját. Az egy helyen elemzett információk könnyen kontextusba helyezhetők, gyorsabban megtalálhatók, a csapatok közötti információátadás hibátlanul, információvesztés nélkül megoldható. Minden lépés naplózva van, az incidensekkel eltöltött, különböző fázisokban igénybe vett idő mérhető. Végtelenül egyszerűen lehet felépíteni egy ilyen rendszerre például egy mérőszámrendszert, amelyből egyértelműen kiderül, mely fázisban, mennyi időt töltött el a csapat a munkával, mennyi idő alatt voltak képesek detektálni egy riasztást, mennyi idő alatt voltak képesek lezárni az adott incidenst. És ha az üzleti kontextussal is összekötjük ezeket a technikai információkat, akkor arról is képet alkothatunk, hogy ezzel mekkora üzleti kockázatot tudtunk megszüntetni.

Laborozunk 1.0: új tesztkörnyezettel az ipari kibertámadások ellen

Hunyadi Péter cikke

2021. szeptember 15. - EURO ONE

security-lab-10_002_1.jpg

Ha valaki rendszeresen követi a blogunk cikkeit, nemrég olvashatott arról, hogy eljátszottunk egy OT Security Labor kiépítésének gondolatával. Az ok nagyon egyszerű: Az OT security esetében összetett folyamatokat kell modellezni, ráadásul egyszerre több terület szakértőinek kell összedolgoznia, ami merőben más szemléletmódot és eljárásokat kíván, mint a hagyományos IT biztonsági megoldások. Ráadásul - szerintünk - a fizikai szemléltetés mindig többet ér, mint az elméleti tudnivalók feldolgozása. Azóta az elhatározást tett követte, s munkatársaimmal elkezdtünk létrehozni egy olyan labort, ahol az ipari kibertámadások karakterisztikáit tudjuk leképezni és megfoghatóbbá tenni. Fő célunk, hogy ügyfeleink átlássák a sajátjukhoz hasonló felépítésű környezet sérülékenységeit, illetve szimulálni tudjuk számukra az olyan eseteket, amelyeket saját éles környezetükben nem tudnak megtenni.

E labor fejlesztésében több csapat képviselője is részt vesz, személy szerint én a GRC tanácsadói csoport tagjaként felügyelem a folyamatot. A nevem Hunyadi Péter, s már tanulmányaim óta kiemelten foglalkozom a kritikus infrastruktúrák védelmével. A Nemzeti Közszolgálati Egyetem elvégzése után ipari információbiztonsággal kezdtem el foglalkozni az Euro One-nál, OT biztonsági tanácsadói pozícióban. Ezek után talán érthető, ha büszkeséggel tölt el, hogy egy ilyen projekt részese lehetek, s úgy vélem, ügyfeleink számára is rendkívül tanulságos lehet e labor felállásának menete éppúgy, mint majdani használata. Így mostantól folyamatosan szeretnék beszámolni az ezzel kapcsolatos fejleményekről itt, a blogban.

Így laborozunk mi

Bár múltkor már elmeséltük, hogy melyek a projekt fő céljai, s terveink szerint miként működik majd a gyakorlatban, most röviden szeretném összefoglalni, hogy milyen szempontok alapján haladunk jelenleg.

Először is szerettük volna, ha a labor követi a tipikus ICS (Industrial Control Systems) rendszerek felépítését. A terv szerint megvalósul benne a Purdue-modell 0-3 szintje, vagyis kezdve az üzemi eszközöktől, helyet kapnak benne kontrollerek (PLC), HMI-k és a legfelső szinten elhelyezkedő felügyeleti és biztonsági funkciókkal bíró szerverkörnyezet egyaránt. A labor képes lesz kommunikálni SIEM rendszerrel is, lehetővé téve, hogy mind OT-, mind az IT hálózatban keletkező eseményeket, incidensek központi felületen lehessen kezelni, s a különböző területen történő, de esetleg összefüggő gyanús eseményeket korrelálni.

A rendszer egyik legfontosabb elemei az OT eszköz-, és biztonságfelügyeleti platformok lesznek. Elsőként például olyanok, amelyek az ipari hálózati forgalomat passzív módon elemezve részben riasztásokat generálnak, részben tolmácsként is funkcionálnak egy teljes vállalat eseményeit kezelő SIEM rendszerek felé, amelyek az ipari protokollokat nem tudják értelmezni. Esetünkben a központi SIEM egy RSA NetWitness lesz. A laborunk működése során mind az OT platformot, mind az itt keletkezett események SIEM rendszerben való kezelését meg lehet valósítani.

A felügyeleti rendszerek mellett természetesen egyéb kiberbiztonsági megoldások tesztelésére és demonstrációjára is alkalmasak leszünk. A labor bővítve lesz ipari IDS eszközökkel és tűzfalakkal, így gyakorlatilag alkalmassá válik az egész logikai védelmi koncepció bemutatására. Mivel a labor környezet miniatürizált és független, ezért szállítható lesz ügyfeleinkhez, vagy éppen rendezvényekre, oktatásra is.

Készül a demó környezet

Röviden itt tartunk most, gőzerővel dolgozunk a projekt mielőbbi megvalósításán. A későbbiekben jelentkezünk további részekkel a demó környezet születéséről, és ezzel összefüggésben bemutatjuk a kiválasztott komponenseket, szoftvereket, beszámolunk a kihívásokról. Emellett reméljük, hogy a tesztüzem bemutatására is mielőbb sort tudunk keríteni. Ha érdekesnek találják az elképzelést, feltétlenül tartsanak velünk legközelebb is!

Purple Teaming: a reálisabb biztonsági tesztek alapja

Kovács Erik cikke

2021. augusztus 10. - EURO ONE

Ahogy az korábbi bejegyzéseinkből kiderülhetett, a kiberbűnözők eszköztára folyamatosan fejlődik, s adott esetben képes akár teljesen átalakulni - vegyük csak példának a zsarolóvírusok szolgáltatássá avanzsálását - , hogy minél hatékonyabb és profitálóbb támadásokat hajthassanak végre. Szerencsére ezzel egy időben az infosec iparág is mindig előrukkol új megoldásokkal. Olykor ezek nem is feltétlenül jelentenek teljesen új technológiákat, egyszerűen csak a korábbi, bevált módszerek továbbfejlesztését. Az egyik ilyen, egyre többeket foglalkoztató biztonságtechnikai eszköz a Purple Teaming, amelyről a SOC's Summiton tartottunk előadást. Éppen ezért úgy gondoltuk, röviden összefoglaljuk az ott elhangzottakat.

Amikor a pentest nem elég

Kezdjük az elején, s nézzük meg, mi hívta életre a Purple Teaminget. Bizonyára nem mondunk vele újdonságot, de sok vállalatnál a biztonsági felméréseknél még mindig csak a penetrációs tesztekben gondolkodnak. A sebtében elvégzett pentest persze jó eséllyel kiszűri a befoltozandó hibákat, de hatalmas hiba, ha ezek eliminálása után a cégvezetés és a vállalat biztonsági szakértői kényelmesen hátradőlnek a karosszékben, annak biztos tudatában, hogy innentől kezdve sebezhetetlenek.

Sajnos a pentest, s ugyanígy a vulnerability scanning, illetve vulnerability assessment egyaránt megmarad a vállalat technológiai rétegében. S bár ilyen módon a technikai problémák kiszűrésére kiválóan alkalmasak, ám nem szabad elfeledkezni arról, hogy a vállalati működés nem pusztán technológiai háttérből áll: ott van az emberi tényező is.

A hacker támadások legtöbbje nem feltétlenül azért lesz sikeres, mert a kiberbűnözők aprólékos munkával feltörnek webes alkalmazásokat, majd onnan lépésenként eljutnak egészen a domain controllerig. A legtöbb támadás sikerének kulcsa a munkatársak, avagy a felhasználók felkészületlenségének köszönhető: gyanútlan kíváncsisággal kattintanak rá a legprimitívebb phising e-mailben található linkre is, amivel a hackerek részéről gyakorlatilag le is van tudva az initial access megszerzése. S ha a kezdeti hozzáférés megvan, a támadónak már csak annyi a feladata, hogy elhelyezzen a rendszerben egy kódot, amely biztosítja számára a későbbi lépések megtételének lehetőségét, a folyamatos hozzáférést.

Sajnos a felhasználót, mint leggyengébb láncszemet nem tesztelik a pentestekkel és a vulnerability assessmentekkel, ezekkel csak a technológiai layer problémái szűrhetők.

A megoldás: a piros és a kék keverése

Nem, nem arra gondolunk, hogy minden cég folyosóját érdemes pirosra és kékre, vagy a két színből kikeverhető lilára mázolni. A megoldást csak átvitt értelemben jelenti e két szín összekeverése. A Red Teaming és Blue Teaming fogalmak bizonyára mindenkinek ismerősek az infosec témák iránt érdeklődők köreiben. Ha valakinek mégsem, akkor röviden a lényegük: a katonaságtól eredeztethető fogalmak, ahol a gyakorlatok során egy piros (támadó) és egy kék (védekező) csapatra osztották a bakákat, s ily módon igyekeztek valós harci helyzeteket szimulálni. Kiberbiztonsági szempontból a dolog nagyon hasonló, vagyis adott a Red Team (jelesül a hackerek) és a Blue Team (például egy vállalat védelmét ellátó csapat), akik modellezik, hogy mi történne egy kibertámadás során. Sok esetben a támadás tényéről előre csak a cégvezetők tudnak, hogy a dolog minél életszerűbb legyen. Így a kék csapat reális támadásnak érzékeli a cégvezetés által megbízott hackerek furmányait, s ennek megfelelően védekeznek.

Ez önmagában is hatékony lehet a hibák és hátsó kapuk feltárására, ám a mostanában egyre népszerűbb úgynevezett Purple Teaming egy fokkal tovább viszi ezt a gondolatmenetet. Nevezetesen azzal, hogy a Purple Teaming esetében a piros és a kék csapat tagjai tudnak egymásról. Ennek megfelelően együtt elterveznek minden egyes lépést, átbeszélik a várható eseményeket, hogy melyik lépésnél milyen eredményre számíthatnak. Így például ha a Red Team egy credential dumping során igyekszik kinyerni valamelyik gépről a jelszavakat, akkor a Blue Team arra számíthat, hogy az antivírus vagy az EDR (Endpoint Detection & Response) rendszer sipákolni kezd, s megpróbálja automatikusan blokkolni a támadást. Ha eljutnak ehhez a lépéshez, s az antivírus illetve az EDR egyaránt néma marad, máris kivizsgálhatják, mi lehet ennek az oka.

Viszont talán ennél is nagyobb dolog, hogy ezzel a módszerrel az is felmérhető, a felhasználók mekkora elánnal kattintanak az adathalász levelek linkjeire. A teszt során kiderülhet, hogy a kollégák képtelenek felismerni a nem kívánatos linkeket, amiből a cégvezetés leszűrheti a tanulságot és szervezhet pár órányi képzést a munkatársaknak.

Emellett kiváló megoldás ez a folyamatok tesztelésére is, hiszen fény derülhet rá, hogy a Helpdesk tisztában van-e azzal, bizonyos események bekövetkeztekor kihez kell fordulni, vagy épp milyen a SOC (Security Operations Center), a Helpdesk és a felhasználók közötti kapcsolat és információáramlás. A Purple Teaming tehát jóval túlmutat a technológiai réteg tesztelésén, ami hatalmas gyakorlati előnyt jelenthet a biztonság fokozásához.

Szemben a pentest és a vulnerability assessments tesztekkel a Purple Teaming bevetésével az APT támadásokat is hatékonyan lehet megelőzni, ahol - szemben mondjuk egy szórakozásból vagy erőfitogtatásból elkövetett script kiddie próbálkozással - a támadóknak anyagi támogatásuk és idejük (olykor pedig állami hátszelük) is van a támadás kivitelezéséhez. A fejére látványosan fekete kapucnit húzó és így klimpírozó script kiddie közel nem jelent olyan mértékű fenyegetést egy cégre nézve, mint amire egy APT képes. Az APT-k módszerei ellen pedig hatékonyabb védelmet lehet kidolgozni a Purple Teaming eszköztárával, mint a korábban elterjedt tesztelési módszerekkel.

ÉRDEKEL A KIBERBIZTONSÁG? 

Vegyél részt október 14-én az EURO ONE-RSA Cyber Security Summiton

TOVÁBBI INFORMÁCIÓ ITT

 

Új üzleti modell: így lesz szolgáltatás a ransomware-ből

Krékity Gusztáv cikke

2021. június 30. - EURO ONE

Nem is olyan régen, május végén elemeztük ki, miként váltak - sajnálatosan - az elmúlt évek egyik bomba üzletévé a zsarolóvírusok. A fejlődésük, a variánsok megjelenési ütemének gyorsulása egyaránt azt jelzi, hogy a számítógépes bűnözők számára igen jövedelmező üzletággá vált a ransomware.

 ransomware-a-a-service.jpg

Az első támadások még rombolásra és károkozásra voltak kihegyezve, s persze arra, hogy a titkosított adatok visszafejtéséért minél több bitcoint csikarjanak ki a pórul jártakból. Ám ez a fajta megközelítés idővel - különösen a támadások számának megszaporodása miatt - vesztett hatékonyságából: egyre kevesebb áldozat volt hajlandó fizetni. Sajnos a támadók ebből nem azt a következtetést vonták le, hogy a zsarolóvírusoknak leáldozott. Ehelyett egy második zsarolási lépcsőfokot is beépítettek a támadásokba: nem csak titkosították, zárolták az adatokat, hanem el is lopták az érzékeny információkat. Ettől kezdve pedig az áldozatnak már nem is feltétlenül a titkosítás feloldásáért kellett fizetnie, hanem azért, hogy az eltulajdonított céges adatokat ne publikálják a nagyvilág számára. Ez újabb fellendülést hozott a zsarolóvírusoknak, sőt drágultak is a követelések: 12 hónap alatt 230%-os növekedés volt tapasztalható a váltságdíjak átlagos összegében.

Mostanra a zsarolóvírusoknál körvonalazódik egy olyan új üzleti modell, amellyel maga a ransomware már nem korlátozódik az azt létrehozóra: magát a kódot kezdik értékesíteni, így csökkentve a fejlesztő kockázatát. A zsarolóvírust megvásárló számára ez az üzleti modell csökkenti a támadások végrehajtására fordított végrehajtási költséget, hiszen egy előre megírt és felépített kódot használhat a támadás kivitelezéséhez. Ráadásul ez a fajta RaaS (Ransomware-as-a-Service) szolgáltatási modell kibővíti a zsarolóvírusok által generált fenyegetéseket, mert ettől kezdve már nem kell szakképzettség és tapasztalat ahhoz, hogy valaki saját ransomware variánssal hajtson végre sikeres támadást. A fejlesztő számára pedig a RaaS ugyanolyan nyereséges lehet, mint egy közvetlen támadás végrehajtása a megírt kóddal, hiszen az értékesítési díjon felül - a sikeres támadást követően - még a váltságdíjból eredő nyereség egy részét is megkapja, ezzel is garantálva a vásárló számára, hogy személyre szabott és egyedi kódhoz jusson a támadás kivitelezéséhez.

A ransomware mint szolgáltatás

A módszer hasonlít a SaaS (Software as a Service) üzleti modelljére, mivel jelen esetben a ransomware fejlesztők is eladják - vagy bérbe adják - az egyedileg fejlesztett és felépített zsarolóvírus variánsaikat olyan felhasználók számára, akik később a támadásaikat ezekkel a kódokkal hajtják végre. A RaaS üzleti modell felépítését a NIST Cybersecurity Framework megközelítése szerint bontjuk részekre, hogy alaposabban felvázolhassuk működését.

picture1.png

  1. Első lépésként a ransomware kód fejlesztője létrehoz egy saját készítésű, egyedi kártékony kódot, amelyet ezt követően elad egy előre meghatározott fix ellenszolgáltatás fejében, plusz bizonyos sikerdíjas részesedésért az áldozattól zsarolás útján megszerzett tiszta nyereségből.
  2. A felhasználó (hacker) ezt követően a kapott kódot vegyíti egy exploite-tal.
  3. Harmadik lépésként a támadó azonosítja és célba veszi a gyanútlan áldozatot és a támadási vektort továbbítja, jellemzően egy e-mail üzenetben.
  4. A támadás következő fázisában az áldozat megnyitja a levél csatolmányát vagy a beágyazott és fertőzött weblinket az üzenetben. A kártékony kód ezt követően letöltődik és lefut az áldozat gépén.
  5. Ezután a zsaroló program nekilát titkosítani az áldozat állományait, illetve elkezdődik az oldal irányú mozgás a belső hálózaton, amelynek során további potenciális áldozatokat keres (értékes adatokat tároló szervereket, rosszabb esetben a backupot tartalmazó szervert vagy megoldást). A program szép csendben, ebben a fázisban elkezdi módosítani a rendszerkonfigurációkat, hogy a támadónak bármikor legyen belépési pontja a szervezethez és mindeközben elkezdi eltüntetni a nyomait, hogy minél nehezebb legyen a későbbiekben a kivizsgálási folyamat.
  6. Az áldozat monitorján megjelenik a zsaroló üzenet amelyben utasításokat kap, hogyan vásárolhatja meg a titkosított adatai visszafejtéséhez szükséges információkat, lenyomozhatatlan és lekövethetetlen kriptovalutával (bitcoin).
  7. A támadó többször is továbbítja a kapott váltságdíjat, hogy még kevésbé legyen a folyamat a támadáshoz köthető, lekövethető.
  8. Utolsó lépésként a támadó - a sikeres támadást követően - továbbítja a fejlesztő számára az előre megbeszélt sikerdíjat.

Így néz ki a folyamat általában, de ezen belül négy különféle RaaS bevételi modell létezik:

  • A támadó előfizetéses általány díj ellenében vásárol
  • Van sikerdíjas kódbérlés, így a sikeres támadást követően a fejlesztőnek a nyereség általában 20-40%-át a támadó átadja a fejlesztőnek
  • Egyszeri használati díjat fizet a haszon megosztása nélkül
  • Tiszta nyereség, megosztás alapon

Mindez pont olyan egyszerű, amilyennek hangzik: az ügyfélnek mindössze meg kell látogatni a Dark weben egy RaaS portált, ahol létrehoz egy saját fiókot, majd befizeti bitcoinban az ellenszolgáltatás összegét. Ezután pedig kiválaszthatja egy listából, hogy milyen kártékony kódra lenne szüksége.

picture2.png

A kód kiválasztását követően a felhasználó hozzáférhet a zárt fórumokhoz, dokumentumokhoz, funkciófrissítésekhez, sőt, még terméktámogatást is igényelhet. Az igazán professzionális RaaS szolgáltatók olyan portálokat kínálnak, amelyek lehetővé teszik előfizetőik számára, hogy megnézzék az adott támadás életciklusát és a fertőzés(ek) állapotát, kifizetési információkat, fájltitkosításokat, sőt, ha az adatokat a titkosítással párhuzamosan egy külső FTP szerverre is kimásolják, akkor lehetőséget biztosítanak, hogy azzal vagy másodlagos zsarolási kampányba vágjanak bele, vagy mondjuk publikálják, eladják az értékes információkat.

Jelenleg a RaaS üzleti modell abszolút piac- és versenyképes. Olyannyira működik, hogy a RaaS szolgáltatók immár különböző marketing kampányokat is folytatnak, eközben pedig olyan weboldalakkal rendelkeznek, amelyek a megszólalásig emlékeztetnek egy normális cég weboldalára. A portálokon találhatunk videókat a támadásokról, white papers dokumentációkat. Olykor még Twittert is használnak. A zsarolóvírus nagy üzlet a digitális feketepiacon: 2020-ban már a 20 milliárd amerikai dollárt is meghaladta a bevétel, szemben a 2019-es csekély 11,5 milliárd dolláros nyereséggel.

picture3.png

Jelenleg a RaaS modellben működő ransomware támadásokra számos példa akad, melyek közül soknak a neve csenghet ismerősen: Locky, Goliath, Shark, Stampado, Jokeroo, REvil, Dharma vagy épp az egyre nagyobb népszerűségnek örvendő LockBit.

A RaaS és a COVID-19 összefüggései

Sajnos a koronavírus és a pandémia szinte minden alkalommal szóba került az elmúlt 10-13 hónap során, amikor támadásokról beszéltünk. Jelenleg ilyen időket élünk. Talán hamarosan vége lesz, s már látni némi a fényt az alagút végén, de jelenleg még meg kell említeni a COVID-19-et a RaaS esetében, hiszen a járvány több szempontból extra lehetőséget biztosított a bűnözők számára. Rengeteg intézményt - köztük számos kutatólabort, kórházat is - ért a közelmúltban ransomware támadás, tehát még azokat az intézményeket sem kímélték a támadók, akik napról napra értük, vagy épp a vírus ellen küzdöttek és kutattak. Ezen támadások többsége a fejlődő országokat érintette, ahol nincs kiépített biztonsági infrastruktúra, de számos esetben sikeresen támadtak meg egészségügyi és pénzügyi intézményeket a fejlett országokban is, többek között azért, mert a hirtelen bevezetett home office munkamód kiváló alapot teremtett a felhasználók támadására.

Mi tehát a RaaS sikerének titka?

A RaaS sikere nem túl meglepő, hiszen a segítségével olyanok is támadásokat indíthatnak, akik kevésbé képzettek, s önmaguktól egész egyszerűen képtelenek lennének sikeres támadást megvalósítani. A Dark Weben a rosszfiúknak manapság épp olyan egyszerűvé vált megszervezni egy offenzívát, mint otthoni felhasználó számára regisztrálni a Netflixre. A másik ok pont ez az egyszerűség, hiszen most sokkal gyorsabban fejlesztenek ransomware kódvariációkat, nem kell energiát és időt fektetni magába a támadás felépítésébe és kivitelezésébe. Így a fejlesztő minden rendelkezésre álló energiája és ideje a kódok elkészítésére koncentrálódhat. Emellett a RaaS modellben teljeskörű - és visszatérő - ügyfélkörrel dolgozhatnak a fejlesztők, így folyamatos bevételeket szerezhetnek, miközben jelentősen tudják csökkenteni a saját kockázataikat.

 A témában exkluzív anyagokat találsz majd az InfoSec Akadémia hamarosan induló oldalán. Jelenleg előregisztráció zajlik, jelentkezz!

 isakademia_l_1200x627.png

A ransomware támadások kivédésének praktikáit hamarosan e-bookban is olvashatod, amit megtalálhatsz majd az InfoSec Akadémián!

OT security szuperprojekt: megteremtjük a hatékony tesztelés alapjait

Bak Bernadett cikke

2021. június 24. - EURO ONE

Felemelő élmény, amikor az ember egy adott területen tengernyi tapasztalatot szerez. Ennél már csak az tölthet el jobb érzéssel bárkit, amikor e tapasztalatokat megoszthatja másokkal is, hogy segítse őket a munkájukban. Mi is így vagyunk ezzel, nap mint nap igyekszünk átadni a megszerzett tudást megbízóinknak, többek között az IT biztonság terén. Ám ez egy meglehetősen képlékeny és folyamatosan változó terület, így nem elég, ha ülünk a babérjainkon és a megszerzett tudáson: nekünk is fejlődni kell, hogy az átadott tudás naprakész lehessen. Ezúttal egy olyan fejlődési ponthoz érkeztünk, amely valódi mérföldkő lesz majd a hazai IT security területen. Belevágtunk ugyanis egy szuperprojektbe, méghozzá az ipari biztonság területén.

blogposzt-01.jpg

OT security labor: megnövekedett igényekre reagálunk

Az említett szuperprojekt nem más, mint egy valós környezetet szimuláló ipari környezet kialakítása, amelyben a robotkaroktól a SCADA rendszerig minden megtalálható és minden működőképes. S bár elsőre talán furcsának tűnhet, hogy valaki pusztán tesztelési célból építsen ki egy működőképes ipari, gyári környezetet, az ok nagyon is kézzelfogható: az ipari létesítmények elleni támadások megnövekedett száma. Ráadásul egy gyári környezetben nem feltétlenül állják meg a helyüket a hagyományos IT biztonsági megoldások. Az OT security esetében összetett folyamatokat kell modellezni és egyszerre több terület szakértőinek kell hathatós megoldást kidolgoznia, közösen.

Bár mi sem most kezdtünk el foglalkozni az ipari biztonsággal, mostanra rengeteg tapasztalatra tettünk szert, s egyértelművé vált, hogy még olyan ipari szereplőknél is van mit fejleszteni, ahol amúgy már megbízható biztonsági megoldásokat alkalmaznak. Emellett szeretnénk lehetővé tenni, hogy a gyártók által újonnan piacra dobott technológiákat is ki lehessen próbálni, mielőtt azok az ügyfelekhez kerülnek. Erre pedig a legkézenfekvőbb megoldás egy saját labor felállítása.

Tesztelés hiteles monitoring alapanyaggal

Éles környezetben meglehetősen nehéz és kockázatos tesztelni az OT security monitoring megoldásokat. Ez adódik többek között az ipari környezetek feszített munkarendjéből, még akkor is, ha amúgy a cégnél van olyan IT hálózat, amelyen akár tesztelhetne is. Sokkal hatékonyabb egy olyan OT-s minihálózat, amelyen hiteles hálózati adatokkal, megfelelő monitoring alapanyaggal tudunk mindent kipróbálni, majd prezentálni az ügyfél felé.

Egy ilyen környezetben a piacon megjelenő eszközöket hiteles, egységes tesztmetódussal lehet vizsgálni, így láthatóvá válnak a különbségek, előnyök, hátrányok. Be tudjuk azonosítani azt is, melyek azok a funkciók, amelyekre esetleg csak papíron képes az adott rendszer, de a valóságban nem. Emellett egy ilyen ipari hálózaton megfelelő módon lehet szimulálni a támadásokat is, ami fontos, hiszen a támadási módokat is modellezni kell ahhoz, hogy a megfelelő védelmet kialakíthassuk.

Ugyanígy a napi munkát és a kommunikációt is szimulálni kell, hogy lássuk, pontosan mi zajlik az adott ipari hálózaton belül. Reprodukálhatunk a valós környezetben is meglévő módosításokat - például egy programfutás újraindulását, eszközcserét stb. -, s végül az sem elhanyagolható szempont, hogy egy ilyen rendszer oktatási és prezentációs célokra is kiváló. Ráadásul - bár a gyártás önmagában is fontos terület - akár a közműszolgáltatók esetében is hasznosítható ez a megoldás, sőt, tulajdonképpen bárhol, ahol speciális protokollok és architektúrák vannak (géptermek stb.). Éppen ezért az a célunk, hogy gyakorlatilag bármilyen kiberfizikai hálózatot szimulálhassunk.

Csak a példa kedvéért, a felépítés nagyjából úgy néz ki, hogy adott két darab logikai vezérlő, (PLC), irányított robotkarok, érzékelők és visszajelzők, amelyek csatlakoznak egy SCADA rendszerhez. Utóbbi alapja az ipari irányítási, monitoring és felügyeleti szoftver, amely alapelem az ipari szegmensben. Nyilvánvalóan vannak még hálózati eszközök (switch, router a távoli hozzáféréshez stb.), hogy a többi teszt hálózatunktól is elszeparált ipari hálózatot működtethessünk.Fontos, hogy olyan környezetet szeretnénk, ami hordozható, így adtunk hozzá 4G router plusz egy laptop, amelynek segítségével az OT Security Monitoring eszközeinket tudjuk futtatni és monitorozni ezt a mini hálózatot. Emellett szükséges még egy laptop, amivel a támadásokat lehet szimulálni, azaz pentesztelni, offenzív folyamatokat gyakorolni az ipari környezetekre.

A fentiek közül a PLC-k vezérelte robotkarok talán a leglátványosabbak, de akadnak azért még itt kijelzők, érzékelők (fotocella, súlyérzékelő, mágnesérzékelő stb.) is szép számmal, hiszen szükséges alkalmazkodnunk a szabályozási rendszerek sajátosságaihoz is: a legegyszerűbb példa, hogy kell amikor az egyik robotkar olyan helyre tenne át egy tárgyat, ahol érzékelőnk szerint már van egy másik. A leghétköznapibb esetekre is gondolni kell, mert ezek sokszor váratlan negatív események elindítói lehetnek.

A csapat

Végül álljon itt néhány információ arról is, miként épül fel a fentiek mögött álló csapat, amelybe egyébként önkéntes alapon is jelentkezhetnek azok a kollégák, akinek felkeltette az érdeklődését a labor.

A téma gazdája az EURO ONE-on belül Hunyadi Péter, aki egy meglehetősen embert próbáló és összetett szerepkört vállalt ezzel magára, hiszen több tudományág összpontosul egy kézben. Természetesen ez nem azt jelenti, hogy innentől mindent ő csinál majd egy személyben, hiszen komoly csapatok állnak mögötte (OT szakértők, security mérnök csapat, SIEM-SOARmérnök csapat, kibervédelmi tanácsadó (CDA) csapat, GRC csapat, IDM és access management menedzsment csapat), de egy ilyen projekt esetében nagyon fontos, hogy legyen valaki felül, aki az egészet átlátja, irányítja.

Úgy gondoljuk, hogy Péter és az összeállt csapatok erre a feladatra tökéletesen alkalmasak, és a csapatmunkának köszönhetően ez a gigaprojekt egy működőképes és számos cég számára pótolhatatlan megoldássá állhat össze. Peti itt a blogban is beszámol majd ezentúl a labor fejlődéséről, s természetesen a gyakorlati tapasztalatokról is.

Iratkozz fel youtube csatornánkra, hogy elsőként értesülj Hunyadi Péter bemutatkozásáról. 

Hamarosan indul az InfoSec Akadémia, ahol ipari biztonság témakörben is rengeteg tartalmat és újdonságot találsz majd. Jelenleg előregisztráció zajlik. 

isakademia_l_1200x627.png

OT biztonság: több, mint üzlet

Hunyadi Péter cikke

2021. június 18. - EURO ONE

Mint az élet számos területén, úgy az OT biztonság esetén is komoly szerephez jut az anyagi vonzat. A magánkézben lévő vállalatok esetében a biztonsági fejlesztések tervezésekor sokszor elsődleges szempont a kockázatkezelés ára, ami részben érhető, hiszen a nem adminisztratív jellegű kibervédelem eszköztára komoly kiadást jelenthet még a tehetősebb cégek számára is. Amikor egy ügyfél sajnál jelentősebb összeget fordítani fejlesztésekre, tanácsadókként a bekövetkező támadással – és reputációs veszteséggel – járó anyagi kár túlsúlya szolgál érveink alapjául. Természetesen az anyagi szempontok mérlegelése és a károsodás kockázatának felvállalása a vállalat vezetőinek szíve joga, ám fordul a kocka, ha az esetleges kár nem csupán a saját szervezetüket és üzleti kapcsolatrendszerüket érinti, hanem kihatással van a társadalom egy részére, vagy éppen létfontosságú szolgáltatások működésére is.

ot-factory.jpg

Ennek a cikknek nem célja védelmi tanácsokat adni, inkább arra világítunk rá, hogy az OT biztonság erősítése - amely mindenhol sürgető feladat -, bizonyos ágazatokban a döntéshozók komoly társadalmi felelőssége is.

OT és IT rendszerek, mint létfontosság rendszerelemek

Korábban említettük, hogy az ipari kiberbiztonság szorosan kötődik az állam működéséhez és a lakosság ellátásához. Ez magába foglalja többek között a személy- és áruszállítást, az energetikát, a vízellátást, illetve - ahogy a koronavírus járvány is megmutatta - a gyógyszer- és élelmiszergyártók is ide sorolhatók. Ezekben közös, hogy mind létfontosságú ágazatok, aminek köszönhetően az alkotóelemeik közt bőven akadnak, amelyek a hatályos magyar törvény szerint létfontosságú rendszerelemnek minősülnek. A lista kiemelt elemei az OT és IT rendszerek, amelyek az informatikai hálózatoktól való függőség korszakában az alapvető szolgáltatások legfontosabb összetevőivé nőtték ki magukat, így az előbb említett jogi fogalom ezekre fokozottan vonatkozik.

Ennek ellenére az ipari hálózatok megfelelő védelmének kialakítása és fenntartása nem könnyű feladat a speciális működési követelmények és az ősrégi rendszerek miatt, miközben azonos súllyal kellene kezelni, mint a – legtöbbször jóval komolyabban vett, akár fegyveres – fizikai védelmet.

Valós fenyegetettség, élő példákkal

Arra, hogy a védelem mennyire fontos, már évekkel ezelőtt rávilágított a 2015-ben, Ukrajnában történt kibertámadás, amely kifejezetten az elektromos hálózat ellen irányult, azzal a – feltehetően részben politikai – céllal, hogy kiesést okozzon az áramellátásban. A BlackEnergy néven ismert malware egyik variánsa segítségével kivitelezett incidens három ukrán villamosenergetikai céget érintett közvetlenül, melyeken keresztül 230 000 ember maradt áram nélkül, s velük együtt persze rengeteg cég is így járt. Habár ez a konkrét eset mindössze hat órányi kimaradást eredményezett, azonnal ráirányította a nemzetközi szakma figyelmét arra, hogy ez az alapvető fontosságú szolgáltatás milyen nagy mértékben támadható. Egy évvel később a Crashoverride-ként  (vagy Industroyer-ként ) elhíresült malware okozott három órás áramszünetet Kijev térségében, ez esetben 225 000 felhasználó környezetét elsötétítve. Habár az Ukrajnai támadások relatíve rövid ideig fejtették ki hatásukat, mégis rámutattak, hogy a kritikus információs infrastruktúrák bizony sérülékenyek és támadhatók, s egy ilyen támadás az elkövető kapacitásától, illetve a kivitelezés kifinomultságától függően hat óra helyett akár napokra, vagy annál is hosszabb időre megfoszthat bennünket alapvető szolgáltatásoktól. Ilyen, és súlyosabb esetekre pedig a kiberhadviselésre berendezkedő hatalmak korában sajnos egyre nagyobb az esély.

Államok és árnyak

Dacára annak, hogy alapvetően a nemzetállamoktól érkező, vagy hozzájuk köthető támadások a legfélelmetesebbek (ilyen a fent említett két eset is), komoly fenyegetést jelentenek a bűnözői csoportok is, amelyeknél a fő motiváció, az anyagi haszonszerzés nem feltétlenül keveredik nagy gazdasági és politikai célokkal. Példáért sem kell túlságosan visszamennünk az időben: 2021. május 7-én történt az Egyesült Államokban, hogy a DarkSide névre hallgató kelet-európai bűnözői csoport ransomware támadást hajtott végre a Colonial Pipeline vezetékrendszer üzemeltetője ellen. Az ország délkeleti partvidékének nagy részét - egészen pontosan 12 államot - üzemanyaggal ellátó Colonial Pipeline Co vállalat IT-oldali számlázási rendszerét érte a támadás, viszont az üzleti folyamatok egymásra hatásából kifolyólag, valamint izolációs okokból az OT rendszereket is le kellett állítani.

Ez az incidens hat napos leállást eredményezett, melynek következtében a térségben az üzemanyagárak elérték a 2014 óta tapasztalt legmagasabb szintet, az emberek pánikszerű üzemanyag-felvásárlásba kezdtek, ráadásul a Colonial-tól való függőség miatt zavar keletkezett két nemzetközi repülőtér működésében is, amelyeken így át kellett szervezni a járatokat. Ez a támadás jó példája annak az aggasztó tendenciának, hogy a bűnözői csoportok folyamatosan fejlődnek és hamarosan olyan képességek birtokába juthatnak, amelyeket eddig csak nemzetállamoknál láthattunk. Azonban privát csoportok esetében, a politikai motívum híján, szinte lehetetlen behatárolni a célterületet, egyszóval bármelyik jelentős vállalat, bárhol, bármikor szembenézhet a Colonial-féle esethez hasonló incidenssel.

A bemutatott példákkal szeretnénk megkongatni a vészharangot, hiszen nem tudható, mit hoz a holnap és mekkora horderejű támadásokkal szemben kell váratlanul helyt állni. Itt az idő a közérdeket az üzleti érdekkel szorosan összefűzni, ennek kapcsán pedig megvizsgálni, hogy a minket ért támadások milyen hatással vannak a lakosságra. Ennek megfelelően pedig végre olyan súllyal foglalkozni információs rendszereink megerősítésével, amilyen megilleti azt a társadalmi egymásrautaltság hálójában.



A témában exkluzív anyagokat találsz majd az InfoSec Akadémia hamarosan induló oldalán. Jelenleg előregisztráció zajlik, jelentkezz!
isakademia_l_1200x627.png

 

 

Így vágj bele egy ISMS bevezetési projektbe

Tóth Tamás bejegyzése

2021. június 01. - EURO ONE

Minden projektnek megvannak a maga szépségei, sajátosságai és nehézségei, ez az ISO 27001 szabványon alapuló Information Security Management System (ISMS) bevezetési projekteknél sincs másképp. A cikksorozatom folytatásaként az ISMS projektek általános jellemzőiről, ajánlott indításáról írok a korábbi tapasztalatokat összegezve. 
Az ISMS tévhitekről itt írtam, míg arról hogyan add el a menedzsmentnek itt. 

 

Ha az előző cikk alapján sikerült meggyőzni a szervezet vezetését az ISMS fontosságáról és megszületett a döntés a bevezetési projekt indításáról, felvetődik a kérdés, hogy hogyan érdemes belevágni az egész munkába. Semmiképpen sem szeretném túlmisztifikálni a szabványt és a témakört, de azzal tisztában kell lenni, hogy csupán a szabvány egyes követelményeire vonatkozó sablonok kitöltésére és szabályzatok gyártására szorítkozva nem lehet ISMS-t kialakítani.

 

ISMS bevezetés, mint formális projekt

Az ISO 27000-es szabványcsalád első pár szabványát (pl. 27000, 27001, 27002) olvasva nagyon hamar egyértelművé válhat, hogy a szervezet nem egy könnyű, de egyébként abszolút reális és megvalósítható feladatra vállalkozik. Az ISMS bevezetése hosszú, összetett feladatokból áll, számtalan függőséggel, amelyeken nagyon könnyű elcsúszni. A hagyományos IT projektektől eltérően itt nem csak az IT, hanem az üzleti és a támogató szervezeti egységek, illetve harmadik felek is érintettek, ami azt eredményezi, hogy több szereplőt nehezebb koordinálni, összefogni.

A fenti okok, illetve a későbbiekben részletesen kifejtett okok szükségessé teszik, hogy a szervezet formális projektként, szervezett keretek közt vezesse be az ISMS-t. Maga a feladat aktív projektmenedzsment tevékenységet és részletes tervezést igényel.

 

Scope

A projekt előkészítésének első lépése a scope, más néven hatókör vagy alkalmazási terület meghatározása. A scope-ot több dimenzióban lehet és kell értelmezni: szervezeti egységek és üzleti folyamatok, IT és fizikai lokációk szerint. Szervezeti egységek és üzleti folyamatok szempontjából nem minden ISMS terjed ki az adott szervezet egészére. Nagyobb méretű szervezetek esetén jellemző, hogy csupán egy-egy szakmai terület vagy bizonyos szolgáltatás nyújtásában érintett területek tartoznak az ISMS scope-ba. Nagy szervezeteknél a best practice egyébként is azt javasolja, hogy elsőként csak egy meghatározott területen kerüljön bevezetésre az ISMS, majd a megfelelő érettség után ki lehet terjeszteni, ha "kiforrta magát". Kis szervezeteknél természetesen célszerű lehet az egész szervezetre kiterjeszteni a hatókört, ha ez ellen nem szól semmilyen érv. Az ISO 27001 szabvány erre vonatkozóan nem ír elő követelményt, csupán azt, hogy meg kell határozni és dokumentálni kell a scope-ot.

IT szempontból azok a rendszerek, alkalmazások és hardverek tartoznak a scope-ba, amelyek a scope-ba tartozó üzleti folyamatokat támogatják, azokban felhasznált adatokat kezelik. Az IT scope meghatározásakor a CMDB-t és a szolgáltatáskatalógust lehet felhasználni.

Fizikai lokációk szempontjából a scope-ba beletartozhat egy vagy több teljes telephely, vagy akár irodaházak esetében kijelölt emeletek, vagy korlátozott esetekben csak néhány kijelölt iroda, szerver terem, amelyek szintén a meghatározott üzleti folyamatokat támogatják.

A scope fontossága abban rejlik, hogy az ISMS előírásait, kontrolljait a scope-ba tartozó folyamatokban, rendszereken, hardvereken, és területeken maradéktalanul kell alkalmazni. A scope-ba tartozó folyamatok információs vagyonelemeit kell felvenni és menedzselni, a kockázatokat is ezekkel kapcsolatban kell azonosítani, értékelni és kezelni. Az auditok során a scope-ban lévő elemeket ellenőrzik, de ha az előírások nem teljesülnek maradéktalanul, az sikertelen eredményre vezethet.

A scope-on kívül helyezett elemeket célszerű pontosan meghatározni és formálisan ezeket úgy kell(ene) kezelni, mintha harmadik felek lennének, de ez a gyakorlatban sajnos nem mindig valósul meg megfelelően. 

 

Projekttervezés - szakmai feladatok

Az ISMS projekt lépéseit erősen ajánlott projekttervbe foglalni, amely a bevezetéssel kapcsolatos feladatok lebontását és ütemezését tartalmazza. A projekttervet az elérendő eredmények, állapot alapján mérföldkövekre kell bontani, amelyek részletes szakmai feladatairól a következő cikkem fog szólni.

Az ISMS bevezetési projektek időtervezésére nehéz becsléseket adni, hiszen ahogy a korábbi cikkekben többször kitértem rá, a szervezetek érettségi szintje itt is meghatározó. Példaként kiragadva: nem mindegy, hogy a kockázatkezelési feladatokhoz érve arról kezdünk el beszélgetni, hogy a kockázatkezelésnek milyen módszertanai léteznek, mik az előnyei, kinek kell majd csinálni, vagy esetleg onnan indul a beszélgetés, hogy a risk managerrel áttekintjük a meglévő kockázatkezelési módszertant és csupán kiegészítjük néhány információbiztonsági specifikummal.  Az esetek túlnyomó többségében minden szervezet tanúsítást szeretne, de sajnos erre nem mindegyikük elég érett. Ilyenkor ajánlott egy hosszabb, ISMS-t megelőző felkészülés, az információbiztonság alapok megteremtése, majd ezekre építkezve lehet fókuszáltan az ISMS alkotóelemeit és a kockázatokkal arányos kontrollokat bevezetni. Mindenki a számokra kíváncsi: azt gondolom, hogy egy átlagos kkv. esetén 9-12 hónapnál rövidebb idő alatt nem, vagy rendkívül nehezen lehet működő ISMS-t bevezetni és sikeresen tanúsíttatni. Ezt természetesen sok további tényező befolyásolhatja.

A projekttervben az ütemezésen túl meg kell határozni a feladatok függőségeit is, hiszen vannak olyan feladatok, amelyekkel hatékonyan, párhuzamosan is lehet haladni és természetesen vannak olyan feladatok is, amelyeknél az azt megelőző feladatok értékelését, interjúit, vagy más outputjait kell felhasználni. Ezek a tervezés és szükség esetén az újra tervezés miatt szintén kulcsfontosságúak.

 

Projekttervezés - általános projektmenedzsment

A projekttervezés előző fejezetben bemutatott szakmai részén kívül természetesen elengedhetetlenek a projekttervezés további, jelen esetben "általánosnak" nevezett elemei, amelyek a Projektalapító Dokumentumban (PAD) kerülnek összefoglalásra.

 

Az ISMS bevezetési projektek célja egyértelmű: az ISO 27001 szabványon alapuló Information Security Management System (ISMS) kialakítása és a tanúsítás megszerzése. Az előző mondat tartalmazza a sikerkritériumot is, vagyis a sikeres tanúsítást. A tanúsítás megszerzése utáni, annak fenntartása érdekében végzett feladatok már az ISMS üzemeltetésének számítanak.

 

A PAD másik fontos eleme a projektszervezet és a felelősségek meghatározása, vagyis azoknak a személyeknek az összegyűjtése, akik érintettek a projektben és feladatuk van azzal kapcsolatban. Ezen személyek köre szervezetektől függően változhat, de mégis meg tudunk határozni általános szerepköröket (itt csak a projekt szempontjából legfontosabbakat emelem ki, támogató funkciók nélkül, pl. HR)

Első ilyen szerepkör a menedzsment, vagyis a szervezet felsővezetése, akik elsősorban a projekthez szükséges forrásokat biztosítják, demonstrálják az elkötelezettségüket, részt vesznek és végrehajtják a vezetői átvizsgálást, döntést hoznak az információbiztonsági kockázatokról, célokról, illetve ideális esetben elvárásokat fogalmaznak meg az ISMS-sel és az információbiztonsággal kapcsolatban.

Másik fontos szerepkörbe maga a business, vagyis az üzleti terület döntéshozói tartoznak, akik napi szinten használják a védendő információs vagyont és az információbiztonsági szabályok hatással vannak a munkájukra. Ők rendelkezhetnek jóváhagyási jogkörrel, kockázatokat "birtokolnak" és a saját területükön kikényszerítik a szabályokat. Ők az "első védelmi vonal", nagy valószínűséggel ők lesznek az információs vagyonelemek "tulajdonosai" és a kockázatelemzésbe és más folyamatokba is célszerű bevonni őket, hogy az elvárásaikat megismerve minél inkább hozzájuk lehessen igazítani az irányítási rendszert.

Az IT vezető(k) és az adminisztrátorok nélkülözhetetlen résztvevői az ISMS projekteknek, releváns információkat birtokolnak. A scope meghatározásában, kontrollok érettségének felmérésében, kockázatok értékelésében és kezelésében is sarkalatos a jelenlétük.

Az információbiztonságért felelős vezető és csapata az IT-hoz hasonlóan nélkülözhetetlen a projekt szempontjából, azzal a különbséggel, hogy nagy valószínűséggel az információbiztonságért felelős vezető lesz az ISMS legfőbb felelőse, ezért a tanácsadók által tőle várható a legtöbb információ és igény, tanácsadók igénybevétele nélkül pedig jellemzően ő projekt fő felelőse.

Nem ISMS sajátosság, hogy legyen egy kijelölt projektgazda vagy szponzor, aki mind szakmailag, mind az általános projektvezetés szempontjából döntéshozatali jogkörrel rendelkezik. Ellenkező esetben a döntések lassan, nehezen fognak megszületni, ami valószínűsíthetően a projekt csúszását idézi elő.

 

A PAD-ban kerülnek összefoglalásra a projekttel kapcsolatos költségek, amelyekre az előző cikkemben soroltam fel néhány CAPEX, OPEX példát. Szintén a PAD-ban kerülnek röviden összefoglalásra a részletes projektterv mérföldkövei és azok ütemezése.

 

A leszállítandók vagy másnéven eredménytermékek szintén a PAD-ban kerülnek felsorolásra. Az ISMS projektek leszállítandóit jól elkülöníthető csoportokba tudjuk sorolni. Természetesen ide tartoznak a különféle szabályzatok és eljárásrendek, de vannak "registerek" is, azaz különböző nyilvántartások (pl. információs vagyonelemleltár, kockázati nyilvántartás, CMDB). A feladatok elvégzéséből és a kontrollok üzemeltetéséből előállnak "recordok", vagyis feljegyzések, ticketek, naplóbejegyzések, amelyeket a dokumentált információ elve alapján meg kell őrizni.

 

Mint minden projektben, a hatékony és rendszeres kommunikáció létfontosságú. Az operatív feladatokról szóló, fix időpontban tartott, hetente ismétlődő rendszeres státusz meetingek kijelölésével szintén nem mondok újdonságot. Mindenki elfoglalt, különösen a vezetők, de a projekt előrehaladása szempontjából lényeges, hogy lehetőleg mindenki kezelje prioritásként ezeket a státusz meetingeket. Saját tapasztalatból mondhatom, hogy olyan meeting nem igazán lesz, amit le lehet mondani azért, mert nincs miről beszélni. Alapvető tényként elkönyvelhetjük, hogy senki sem szeret e-mailt olvasni, de hosszabb, informatív e-mailekkel csökkenteni lehet a meetingek számát, és alapos kifejtéssel jó néhány felmerülő kérdést meg lehet előzni, amivel további idő nyerhető a meeting elején tartott bevezetésből.

 

A PAD és a tervezés lényeges eleme a projekttel kapcsolatos korlátok és kockázatok azonosítása. Korlátként fel lehet sorolni olyan komplex feladatokat, amelyek ugyan kapcsolatban vannak az ISMS bevezetéssel, de ha nincsenek betervezve, akkor elvihetik a fókuszt és az erőforrásokat, ezért az ISMS bevezetési projektnek nem lesznek részei. Ilyen feladat lehet a GDPR megfelelés megteremtése, üzletmenet-folytonosság kialakítása és az IT szolgáltatásmenedzsmenttel kapcsolatos tevékenységek.

A projekt kockázatok körébe azok negatív események tartoznak, amelyek bekövetkezése negatív hatással lehet az ISMS projektre. Projekt kockázat lehet a projekttagok leterheltsége, fizetős és belső projektek összeütközése, pandémia, nem megfelelő szabadság szervezés, vagy éppen a kulcsfontosságú pozíciók betöltetlensége, amelyekre valamilyen módon megoldást kell találni vagy el kell fogadni.

 

Ha összeállt a PAD, akkor a kick-off meetingen közzé kell tenni és szükség esetén módosítani kell rajta.

 

Szervezeti változás és kommunikáció

Az előző cikkekben is többször utaltam rá, hogy az ISMS bevezetése egy szervezeti változás, ami az emberi kapcsolatok és a szervezeti működés sajátosságai miatt számos ponton ellenállásba ütközhet.

Ha változásmenedzsmentről van szó, akkor általában John P. Kotter 8 lépéses folyamatmodellje minden esetben megjelenik valamilye formában. A folyamatmodellt külön nem ismertetem, de megfelelő minőségű munkával, szakértelemmel, jó kommunikációval és nyitottsággal minden lépést meg lehet tölteni tartalommal.

Úgy gondolom, hogy a buzzword-dé és közhellyé vált kifejezések helyett arra érdemes koncentrálni, hogy megértsük azt, hogy az adott személy szintjén - nem számít, hogy menedzser vagy üzemeltető - mit tud adni az ISMS, a saját munkája szempontjából, neki konkrétan miért lesz jobb az ISMS szerint működni. Ha ezt megértjük és az ISMS értékeit megfelelően át tudjuk adni részükre, utána a kölcsönös előnyökre alapozva esély lehet egyfajta szövetséget kötni, másrészt talán van rá esély, hogy ennek köszönhetően a nem kevés fáradozás és az elvégzendő munka talán más megítélést kap.

A kommunikáció másik aspektusa a szakmai csapat és a menedzsment rendszeres tájékoztatása mind a projekt, mind az információbiztonság helyzetéről. A kommunikáció tartalmának meghatározásánál figyelembe kell venni a vezetési szinteket és az azokhoz kapcsolódó információigényt. Példaként a kockázatértékelés eredményeinek ismertetésekor a menedzsment tagját elsősorban az fogja érdekelni, hogy a kockázat számszerűsítve milyen esélyekkel és mekkora kárt tud okozni a szervezetnek és azt mennyibe kerül kezelni. Középvezetői, illetve alsóbb szinten természetesen a kockázat kezeléséhez szükséges konkrét intézkedés, a felelős és határidő kijelölése lesz kulcsfontosságú. Számok ismertetésénél külön fontosnak tartom az egyes felmérések módszertanának és a skálák bemutatását, valamint az eredmények következményeit, hiszen ezek nélkül csupán adatokról beszélünk, amiből jó formán semmi sem következik.

 

Konklúzió

A leírtakból talán mindenki számára világossá válik, hogy az ISMS projektek sikere nagyrészt a tervezésen, valamint kialakított tervek betartásán áll vagy bukik. Természetesen nem lehet mindennel számolni, a változásokat nem lehet elkerülni, de a kompetencia, precizitás, agilitás és egyes soft skillek alkalmazása hozzájárulhat a sikerhez.

Az ISMS bevezetés konkrét projekt feladatairól és összefüggéseiről a következő cikkben fogok írni.

Rombolásból pénzeső: így lett virágzó üzletág a ransomware

Krékity Gusztáv cikke

A Ransomware támadások napjaink egyik komoly fenyegetése a szervezetekre és a magánszemélyekre nézve is. Ma ez a támadási forma jelenti az egyik legnagyobb veszélyt a kibertérben és ad szinte biztos megélhetést a kiberbűnözőknek. Ha még nem olvastad az előző bejegyzésünket a ransomware alapokról, kezdd ott az olvasást. Itt találod. 

blogbejegyzes-ransowmare-cikk-2_-resz.png

Az elmúlt években átlagosan 20-25%-kal gyakrabban csaptak le az áldozatokra a támadók. A megkövetelt váltságdíjak összege is jelentősen emelkedett, ráadásul egyre kisebb valószínűséggel kapjuk meg a visszafejtéshez szükséges kulcsokat a támadóktól miután fizettünk. 2019-ben egyetlen támadás során átlagosan 41 ezer dollárt követeltek az adatok helyreállításáért cserébe, de 2020 első negyedévében már 84 ezer dolláros igényekkel lehetett kalkulálni, ami egy év leforgása alatt 104%-os növekedést jelentett. A támadások szaporodásával 2020 második felére ez már az átlag 154 ezer dollárt is elérte.

1_6.jpg

2_5.jpg

Arra gondoltunk, ennek kapcsán átnézzük, milyen közgazdaságtani hatásai vannak a zsarolóvírus támadásoknak és tisztázzuk, pontosan miért is szeretik ezt a támadási formát a kiberbűnözők. De kitérünk majd arra is, hogy jelenleg kik jelentik a támadók fő célközönségét és miért. Első lépésben lássuk, mi is pontosan a ransomware.

Mi is az a ransomware?

Bár napi szinten van már jelen a köznyelvben, mégis akadnak még félreértések, ha elhangzik a ransomware kifejezés. Kanyarodjunk hát vissza egy kicsit az alapokhoz. A ransomware olyan rosszindulatú, kártékony program, amely egy erős titkosítási algoritmus segítségével zárolja a szervezetek - vagy akár magánemberek - számára fontos adatokat, esetleg a napi szintű működéshez elengedhetetlen végpontokat, szervereket, sőt, néha akár még a backup rendszereket is, hogy végképp lehetetlenné tegye a visszaállítást. Miután a támadó sikeresen zárolta az adatokat és az erőforrásokat, egy üzenet jelenik meg a képernyőn, amelyben részletes útmutatást kapunk a teendőkről, amennyiben vissza szeretnénk kapni adatainkat. Ezen a ponton a szervezeteknek dönteniük kell, hogy fizetnek vagy sem. Ha van olyan mentés, amiből visszaállítható a támadás előtti állapot, akkor szerencsés helyzetben vannak, feltéve, hogy a támadó a támadást megelőzően nem volt tartósan jelen a rendszerekben, mert ez esetben a visszaállást követően jó eséllyel újfent számíthatunk egy zsaroló támadásra. Amennyiben nincs backup, de az adatok, amelyeket elvesztettünk nem értékesek, akkor a legjobb egyszerűen legyinteni és lemondani a támadó által titkosított adatokról, mert akkor sincs garancia arra, hogy valóban megkapjuk a visszaállításhoz szükséges kulcsot, ha fizetünk. Zárójelben jegyezzük meg, hogy az USA-ban például olyannyira nem támogatják a zsarolótámadások esetén a fizetést, hogy az Egyesült Államok Pénzügyminisztériuma szankciókat szeretne érvényesíteni azokkal a szervezetekkel szemben akik, fizetnek.

A legtöbb támadás opportunista, tehát könnyű anyagi vagyonszerzés a célja, minimalizált energia- és időbefektetés mellett. A pénzügyi indíttatású bűncselekmények más formáihoz hasonlóan a számítógépes zsarolást is az alapgazdaságtan hatalmi törvényei vezérelik: a ransomware előállítási, eladási és az értékesítésből (zsarolásból) származó nyereség végösszege adja a támadó motivációját. Amennyiben sokan fizetnek, az jelzés értékű a támadók számára, hogy a választott támadási módszer célravezető, s azzal gyorsan és könnyen lehet sok pénzt keresni, maximalizált profitot termelni.

Az utóbbi időben azonban csökkenő tendenciát mutatott a fizetési hajlandóság, amire a támadók az úgynevezett kettős zsarolási eljárással reagáltak: az első zsarolási faktor továbbra is az adatok visszafejtéséhez szükséges kulcs megvásárlása, ám ha az áldozat nem hajlandó fizetni, akkor az üzenet szövege megváltozik, s már arról szól, hogy az adatokat nem csak titkosították, de el is lopták azokat. Innentől kezdve nem a titkosítás feloldásáért kellene fizetni, hanem azért, hogy ne publikálják a bizalmas információkat. Márpedig ez meggyőzőbb érv, hiszen ez már nem csak adatok vesztésével, hanem reputációvesztéssel, sőt, akár komoly jogi következményekkel is járhat. Sokan ezen a ponton fontolják meg a fizetés lehetőségét, de ebben az esetben sincs garancia arra, hogy adataink válnak publikussá.

2020-ban azok a cégek, ahol nem csak a titkosítás történt meg, hanem konkrét adatveszteség is bekövetkezett, 74,8%-ban fizettek a támadóknak, de számtalan olyan példa van, ahol a támadók a megadott idő leteltével a fizetés ellenére is publikálták a bizalmas adatokat, vagy egyszerűen továbbértékesítették azokat a sötét weben.

Minél nagyobb célpont ellen irányul egy támadás, annál jelentősebb a zsarolás mértéke, de a támadónak is annál inkább érdeke, hogy ne csak egy ponton tudja biztosítani nyereségét, hanem legyen egy másodlagos adu a kezében arra az esetre, ha az áldozat mégsem fizetne.

Erre azért van szükség, mert a nagyobb szervezetek sokkal masszívabban védett célpontok. Az ellenük tervezett támadás során sokkal több időre és szakértelemre van szükség a támadás sikeres kivitelezéséhez, sőt, legtöbb esetben az ilyen célpontokhoz meglehetősen költséges, úgynevezett 0-day (zero-day) sérülékenységeket is ki kell használni, amelyek esetleg csak egy alkalommal lesznek bevethetők. Emellett sok olyan tényezővel - például a rendszer változásaival, frissítésekkel - is kell kalkulálni amelyek, zátonyra vihetik a hetekig-hónapokig tartó, gondos előkészületeket. A zsarolás során igényelt váltságdíj általában tükrözi az erőfeszítést, befektetett időt, tudást, kockázatot és költségeket is.

A legfőbb támadási vektor egy ransomware offenzíva során

Minden sikeres támadásnak van egy kezdő lépése. Az elmúlt években a domináns támadási vektor az e-mail phising volt, amelyet viszonylag nagy lemaradással az RDP, illetve a mezőnyben harmadik helyen végző szoftveres sérülékenységek követtek. A prekurzor rosszindulatú programok, mint például a Trickbot vagy az Emotet az adathalász kampányokat részesítik előnyben elsődleges támadási mechanizmusként. Sokszor egy ilyen támadás alkalmával férgeket telepítenek az áldozat hálózatában, amelyek lehetővé teszik, hogy a vállalati hálózaton keresztül tovább tudjanak terjedni, illetve belépési pontokat helyezzenek el az ellátási láncban (Supply Chain), amelyet közvetlenül eladhatnak olyan bűnözőknek, akik éppen zsarolóvírusos támadáson gondolkodnak.

3_4.jpg

Kik válhatnak elsődleges célponttá?

Legegyszerűbb válasz talán az, hogy bárkiből lehet áldozat, hiszen a biztonsági szakértők szerint immár nem az a kérdés, hogy kinek a rendszerét törik fel, inkább az, hogy mikor. A támadók nem válogatnak szervezeti méret vagy bevétel szerint. A kisvállalkozások nem rendelkeznek fejlett védelmi és detektáló megoldásokkal, így könnyű célpontnak számítanak, viszont a méretesebb vállalatok jelentősen nagyobbat bukhatnak, s persze nagyobb a tőkéjük is, amiből fizethetnek. Cserébe sokkal fejlettebb védelmi megoldásokkal biztosítják rendszereik védelmét és adataik sértetlenségét. Az utóbbi időben a legelsöprőbb támadási hullámot a közép-piaci vállalatok szenvedték el, mivel ezek jellemzően ugyanolyan könnyedén feltörhetők, mint a kisvállalatok, ellenben jobb fizetési képességekkel rendelkeznek.

4_2.jpg

A szervezeti egység mérete mellett megvizsgálhatjuk azt is, az elmúlt éves során mely iparágak voltak érintetek a támadásokban. Jól megfigyelhető, hogy leginkább a professzionális szolgáltatásokat nyújtó vállalkozások estek áldozatul, így például pénzügyi vagy jogi szolgáltatásokat nyújtó szervezetek. Ennek oka egyszerű: bár ezek a szervezetek általában rendelkeznek IT biztonsági megoldásokkal - például tűzfal, email szűrés, végpont védelem stb. - és belső céges szabályzatokkal, de kiemelten tárolnak rendkívül bizalmas adatokat, amelyek elvesztése végzetes is lehet a cégre nézve. A legnagyobb gond - amit a kiberbűnözők szívesen kiaknáznak -, hogy ezek a szervezetek a bizalmas adatok tárolása ellenére sem tartják magukat potenciális célpontnak, s elegendőnek érzik a meglévő védelmi megoldásokat. Kialakult bennül egyfajta hamis biztonságérzet, amely miatt nem frissítik és nem fejlesztik a már meglévő, egykor talán megfelelő szintűnek számító védelmi megoldásokat, szabályzatokat.

5.jpg

Egy jól fizető támadóeszköz

A ransomware az egyik legjobban fizető támadási forgatókönyv, mivel a zsarolások összege egyre csak növekszik, s a kettős zsarolási eljárásnak köszönhetően az áldozatok túlnyomó része inkább kifizeti a megkövetelt váltságdíjakat, annak ellenére is, hogy nincs garancia az adatok visszaállíthatóságára vagy épp arra, hogy az elvitt adatokkal nem találkozunk majd egy weboldalon. Még az sem biztos, hogy nem kerül a cég az újságok címlapjára, amikor kiderül, hogy elvesztette az ügyfelek, partnerek bizalmas adatait. Egészen addig, amíg a támadások során a támadó oldal számára nagyobb a profit, mint a befektetés, a zsarolóvírusokra épülő támadások és variánsok száma rohamosan növekedni - és sajnos fejlődni - fog a jövőben is.

A RaaS üzleti modell egyre népszerűbbé válik és a modell terjedésével már nem korlátozódik a zsarolóvírus kódja az azt létrehozó fejlesztőkre. A ransomware fejlesztők inkább értékesítik a kódokat, ami egyrészt jó a vásárlónak, hiszen csak használnia kell egy kész eszközt, és tökéletes a fejlesztőnek is, hiszen minimalizálja a saját kockázatát azzal, hogy nem szükséges támadást végrehajtani a profit reményében.

Amennyiben részletesebben is érdekel a RaaS, olvasd el a témában hamarosan megjelenő következő cikket is.

Iratkozz fel a listánkra, tanulj tőlünk az IT biztonságról. FELIRATKOZOM

Ne építsünk égő házat, avagy ilyen, ha az üzemeltetés segítségre szorul

Becker Zoltán cikke #adatközpont

2021. április 26. - EURO ONE

Minden bizonnyal nem árulunk el hatalmas titkot, ha azt mondjuk: mindenkinek a saját feladata a legfontosabb és a többségben fel sem merül, hogy esetleg a kapcsolódó tevékenységekkel kapcsolatban is érintett lehet. Ez gyakran előforduló probléma az IT üzemeltetés területén is.

Egy üzemeltetési probléma jellemzően technikai erőforrás kérdésekből, kimutatási vagy riport kérdésekből adódik. Másrészt azonban komoly tényező lehet az emberi oldal is, éppen ezért érdemes e két dolgot elkülönítve is megközelíteni.

Kezdjük ott, hogy ahány ember, annyiféle nézőpont: ugyebár vannak az üzemeltetők, akik teljesen mást gondolnak arról, mikor van szükségük segítségére, mint amit az ő közvetlen vezetőjük. És még ez sem az összes aspektus, hiszen a hierarchia legtetején találjuk az IT vezetőt, aki ugyancsak a saját szemszögéből figyeli a dolgokat. Emellett pedig ott van még az ügyfél is, aki szintén jelezheti, ha problémát észlel, s minden bizonnyal számára is az lesz a fő vonulat, ami közvetlenül őt érinti.

adatkozpont-blog-cikk-ne-epitsunk-ego-hazat_v2.jpg

A problémák beazonosítása

Van egy mondat, amely az esetek többségében előkerül egy üzemeltetői probléma kialakulásakor: “sajnos semmire sincs időnk”. Ennek elhangzása egyike az első jeleknek, amelyekből már sejthetjük, hogy valami nincs rendjén. Szintén klasszikus égi jel, amikor azt tapasztaljuk, hogy egyre több a visszatérő probléma (erről beszéltünk egy korábbi cikkünkben is ITT), illetve az is, amikor a problémák tömegesen jelentkeznek. Ekkor már látszik, hogy valami nem megfelelően működik, és felmerülhet a tervezés szükségessége.

Időnként előfordul, hogy az üzemeltetés annyira szegmentált, hogy a probléma megoldása két terület között akad el, ilyenkor az érintett területek képviselői egymásra mutogatnak. Ennek sajnos a jövőre nézve sincs jótékony hatása (legfeljebb elmérgesíteni lehet vele a munkahelyi kapcsolatokat, ami tovább gátolhatja az együttműködést), és a probléma megoldását sem szokta elősegíteni.

Sajnos jellemző probléma az is, hogy üzemeltetés nem követi nyomon a rendelkezésre álló hardver, szoftver, licenc mennyiséget. Ennek egyenes következménye a munka elakadása, amint elfogynak az erőforrások.

A problémák megoldása

Ha sikerült beazonosítani egy problémát (pláne ha még a kezdeti szakaszban elcsíptük), az kétség kívül nagy előrelépés. A kérdés már csak az, hogy ilyenkor az üzemeltetői oldal felől, vagy fentről érdemesebb-e megindítani a problémamegoldást.

Nos, szerintünk ez kétirányú. Egyrészt minden ilyen csapatban van egy-két olyan ember, aki képes kicsit felülről nézve, tágabban tekinteni a problémára. Az már csak a hab a tortán, ha képes a kollégákat is ebbe az irányba terelni. Mindenesetre inkább az a jellemző, hogy az üzemeltető észreveszi, érzékeli a problémát, de kevésbé jellemző, hogy egyben megoldással is ő szolgáljon.

S itt jön a képbe a csoportvezető, a közvetlen felettes, az, akinek minderre figyelnie kell, s akinek a hierarchiát tekintve is megvan a lehetősége, hogy erre a szemléletmódra rávezesse a többieket, vagy konkrét megoldást adjon a kezükbe. Általában ő az, akinek feltűnik, hogy folyamatosan csúszásban vannak, egyre több a munka, s egyre kevesebb feladat elvégzésére jut idő. Mindig előre kell venni valamit, semmi nem készült el időre, állandóan haladékot kell kérni az igénylőtől vagy a felettesektől, s az ő tevékenysége is lassan abból áll csak, hogy állandó operatív munkát végez, vagyis a problémákat és az embereket menedzseli. Pedig egy csoportvezető ennél azért többre hivatott, s ha bekerül ebbe a mókuskerékbe, azzal csak egy bizonyos szintet lehet tartani, de előre jutni és hosszú távú megoldásokkal szolgálni aligha.

El kell érni, hogy a csoportvezetőnek jusson ideje a tervezésre, fejlesztésre, hogy indukátorként működhessen és segítségével a csapat is megfelelő ritmusban, tervek alapján tudjon előrehaladni. Ha ez elmarad, az csak újabb problémákat generál. Ha azonban sikerült ezt elérni, általában az is rögtön kiderül, hogy nem az erőforráshiány, hanem a rosszul menedzselt folyamatok jelentették a fő gondot. Ezeket kell tehát tiszta fejjel, felülről áttekintve rendezni.

Éppen ezért egy csoportvezető legfontosabb feladata a folyamatok kitalálása, felügyelete, azok racionalizálása, s amennyire csak lehet - ez ugyebár trendi téma manapság - azok automatizálása is. Ez utóbbit illetően is neki kell átlátnia, mivel lehet segíteni az üzemeltetők munkáját, mi az, amit az automatizálással rábízhatunk a gépre, hogy időt nyerjünk.

A menedzsment szint

A fenti folyamatokon keresztül kiderülhet egy csoportvezetőnél, mikor érkezik el arra a pontra, amikor segítségre van szüksége, még ha nem is feltétlenül veszi ezt észre. A következő szint pedig az IT vezető, azaz a menedzsment szint.

Itt is akad két-három olyan eset, amikor a menedzsment észlelheti ha gond van. Az egyik, hogy házon belül jutnak el hozzá a problémák, vagyis az alatta lévő középvezetőkön is átívelnek. A másik - ami egy menedzsmentnél klasszikus esetnek számít -, amikor SLA riportokat, teljesítménymutatókat (KPI) néznek, s ha azokat rendszeresen olvassák és elemzik, könnyen feltűnik, hogy valahol porszem került a gépezetbe.

A harmadik eset - amelyiket valószínűleg minden cég szeretne elkerülni -, amikor az ügyfelektől érkezik visszajelzés. Lássuk be, ha az ügyfél annyira elégedetlen a szolgáltatással, hogy közvetlenül a menedzsmentet keresi, ott már nagyon ég a ház.

Menedzsment szinten a legfőbb kihívást az jelenti, hogy mielőbb sikerüljön beazonosítani, pontosan hol bújik meg a probléma oka. Ki kell deríteni, hogy emberi mulasztás, esetleg hardveres erőforrás okozza-e, vagy mondjuk a folyamat egy bizonyos pontjával van gond. Ez az a rész, ahol a menedzsment szorulhat a középvezetők segítségére.

Ne építsünk égő házat, avagy a probléma megelőzése

Az eddigiek alapján úgy gondoljuk, a folyamatoknál alapvető, hogy azok átgondoltak, racionalizáltak és az üzemeltetők számára is komfortosak legyenek. Ez az egyik legfontosabb.

Emellett a folyamatokba be kell építeni olyan eszközöket, amelyekkel kimutathatóvá válnak a belefektetett idők, energiák, vagyis statisztikák nyerhetők ki róluk. Így például ha veszünk egy helpdesket, akkor tudnunk kell összegezni az emberek munkáját, a feladatok végrehajtásának idejét, az esetleges teljesülési hiányosságokat. A céges szintű jelentések és csoportszintű beszámolók egyaránt fontosak.

Meg kell találni azokat a termékeket, amelyeket használva kimutatásokat készíthetünk a folyamatok egyes pontjain. Az is nagyon fontos, hogy ezek a riportok, ne másfél-két napos munkával előállítható Excel táblázatok legyenek, feldobva pár kördiagrammal. Ehelyett egyszerűen, gyorsan elkészíthető, nagyon könnyen összehasonlítható kimutatásokra van szükség, ahol egy-egy aktuális értéket villámgyorsan össze lehet hasonlítani az elvárttal. Érjük el, hogy akár a nap végén egyszerűen lehessen lehúzni egy ilyen jelentést. Ez nagyon fontos, hiszen ha egy ilyen beszámoló elkészítése túl sok időt emészt fel, akkor ez lesz a gátja annak, hogy megfelelő visszajelzéseket kapjunk.

Ezekre a feladatokra egyébként bőven akad megfelelő eszköz. A teljesség igénye nélkül ilyenek a különféle helpdesk rendszerek (OTRS, ServiceNow, Freshdesk, ManageEngine…stb). Ezek mindegyike képes jelentéseket készíteni a benne végrehajtott feladatokról. Az ezekben használt ticketek végrehajtása folyamathoz kötött, az ezeken alapuló workflow-k és tevékenységek mind-mind több szinten riportozhatók, tehát akár egy csoportvezető is lehúzhatja magának a statisztikát, például arról, hogy mennyi nyitott jegy van, mennyi van közülük csúszásban, az egyes embereknél mennyi feladat áll. Így rögtön le lehet szűrni, hogy ki az, aki túlterhelt vagy éppen kinek nem jutott feladat. Így optimalizálhatók a folyamatok.

Technikai oldalról térjünk még vissza egy kicsit a monitoringhoz, vagyis hogy miként állnak a hardver erőforrások, a rendelkezésre álló erőforrások, vagy akár a rendelkezésre álló licencek. Ezek technikai dolgok, amelyeket egy monitoring rendszer képes folyamatosan figyelni, követni, képes ezekről trendeket, grafikonokat készíteni, szükség esetén riasztást generálni, és adott időközönként - nyilván itt a hierarchiától függően negyedévente, félévente, évente - készíthet olyan beszámolókat is, amelyekből az erőforrás használati trendek követők. Így ha veszünk egy csoportvezetőt, ő is megnézheti, hogy akár az elmúlt egy hónapra visszamenőleg miként fogytak el a tárhely kapacitások, mennyiben nőtt a virtuális környezetek memória és CPU terhelése, és ebből következtethet arra, hogy a beérkező feladatok, igények és az elfogyott erőforrások között van-e összefüggés? Ebben az esetben akár ő maga is elindíthatja az erőforrásbővítési folyamatot, vagy módosíthat úgy folyamatokat, hogy nagyobb kontrollhoz jusson. Így például elkerülhető, hogy mindenki, minden részfeladatra újabb virtuális gépet kérjen, s így egy idő után már ezer darab virtuális gépünk legyen, amelyek közül ötszáz ugyanazon a feladaton dolgozik.

Tehát a monitoring rendszer technikai statisztikái, grafikonjai, és az emberi erőforrásra vonatkozó jelentések remekül párhuzamba állíthatók. Mindez pedig jól jöhet az éves tervezéseknél, a jövő évi tervek készítésénél is, hiszen így könnyebben kideríthető, miként növekedhetnek az erőforrás igények az ügyfelek oldaláról és saját részről.

A lényeg az, hogy mindig azt a pontot, azt a helyet, azt az embert, azt a csoportot kell tudni pontosan meghatározni, ahol a beavatkozásra, segítségre szükség van.

süti beállítások módosítása