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

EURO ONE

IT biztonsági előrejelzés: 2022 várható veszélyei

Krékity Gusztáv cikke

2022. január 14. - EURO ONE

Új év, új lehetőségek, szokták mondani! Ám míg pár éve ilyenkor a legtöbben a munkahelyi előléptetésre, a fogyókúrára, vagy az egészségesebb életmódra váltásra gondoltak csak, addig manapság bekerülhet az újévi fogadalmak listájába az új IT biztonsági kihívások elleni hatékonyabb védekezés is. Merthogy immár évről évre új, ráadásul igen komoly fenyegetésekkel kell számolni ezen a területen is, s elsősorban az bízhat a sikeres védekezésben, aki hajlandó előre tervezni és folyamatosan újítani a védelmi megoldásokat illetően.

it-elorejelzes.jpg

Hasonlóan a korábbi évekhez, idén is szolgálunk olyan összefoglalóval, amelyből kiderül, milyen fenyegetésekre számítanak 2022-ben az IT biztonsági vezető vállalatok és szervezetek. Ne legyenek kétségeink: az elmúlt tizenkét hónapban az APT fenyegetések megállás nélkül fejlődtek, s váltak egyre erőteljesebbé. Ám folyamatosan változó természetük ellenére sokat tanulhatunk ezen támadások legújabb trendjeiből és így megjósolhatjuk, mi vár ránk az idei évben. Az általunk is forgalmazott piacvezető vállalatoktól – Palo Alto, Trend Micro, Skybox, Juniper - származó termékek és a gyártóktól független szakmai szakértők és fórumok is mind hasonló jóslatokkal állnak elő az idei évre. Saját tapasztalatainkra és partnereink prognózisaira támaszkodva indítjuk most azzal az új évet, hogy ismét összefoglaljuk a kulcsfontosságú, IT biztonságot érintő előrejelzéseket arról, a támadók milyen módon és vélhetően hol fognak legközelebb lecsapni potenciális célpontjaikra.

Zsarolóvírusok: töretlen lendülettel

2021-ben jól látható volt, hogy a támadások gyakorisága és változatossága egyre extrémebb ütemben növekszik. Ez különösen annak volt köszönhető, hogy a támadók egyre aktívabban kihasználták a sötét web (dark web) piactereit, ahol a hackerek hozzáféréseket árulnak a már megtört rendszerekhez vagy épp RaaS szolgáltatásokat kínálnak fel jutalékos rendszerben (korábbi cikkünkben részletesen írtunk e témáról).

Mivel a malware támadások egyre gyakoribbak, az idei évben a legtöbb vállalat IT biztonsági stratégiájának és fejlesztésének alapját képezi, hogy - a folyamatosan változó ransomware fenyegetések elleni hatékonyabb védelem érdekében - fejlett, következő generációs végponti- és dedikált szerver védelmi megoldást vezessenek be. Mindezt szigorú elvárásokkal a file-less, ransomware, exploite és kernel alapú támadásokkal szemben. Erre már csak azért is szükség van, mert egyértelműen látszik, hogy a szerverek lesznek a támadók fő célpontjai és a ransomware támadások elsődleges hadszínterei.

A 2022-es év egyik fő veszélyforrásai a ransomware-ek lesznek, amelyek következetes fejlődésüknek köszönhetően jelentős kiberfenyegetést jelentenek majd. A végpontok, mint elsődleges belépési pontok közül a támadók és a RaaS modellben működő támadások üzemeltetői a nyílt szolgáltatásokra, illetve a pandémia hatására bevezetett, gyors változásokkal járó szolgáltatás oldali kompromisszumokra fókuszálhatnak. Egyre több esetben a hybrid munkavégzés vált preferált módszertanná a szervezetek számára, s ez a modell megnövekedett támadási felületet nyújt a vállalatokkal szemben. Ezért fontos a gyors reakció egy támadás észlelése és megállítása során, a megfelelő végpont védelemi megoldás integrálásával. A 2021 során megfigyelt biztonsági incidensek alapján két jelentős mozgásra számítunk 2022-ben a ransomware támadások terén. Először is a RaaS portálok üzemeltetői egyre célzottabb, összetettebb és feltűnőbb támadásokat indítanak majd, vagy kínálnak szolgáltatásként. Emellett a TTP-k, bár jó eséllyel változatlanok maradnak, de sokkal bonyolultabb célkitűzéseket választanak, amelyek túlszárnyalják majd az előző éves célokat. A zsarolóvírusok és az ezekre alapozott szolgáltatások azért is lehetnek az eddiginél is népszerűbbek, mert a zsarolásra használt módszerek dinamikusan fejlődnek. Míg pár éve csak a rombolás jelentett veszélyt, manapság a támadás során az adatokat is viszik a támadók, így több faktoros zsarolásokat hajtanak végre. Sajnos az ilyen jellegű támadásokba még több szolgáltatási faktort igyekeznek építhetnek be a jövőben. Ami viszont a támadás elsődleges hangsúlyát illeti, az továbbra is változatlan az előző évekhez képest: még mindig a kritikus adatokhoz vagy szolgáltatásokhoz való hozzáférés megtagadása, ellopása és kiszivárogtatása a fő cél.

A kritikus rendszereknél, környezeteknél a ransomware támadásokkal szembeni védelem érdekében a vállaltoknak a jól bevált gyakorlatokat kell alkalmazniuk biztonságuk megőrzésére és minden operációs rendszer esetén be kell tartaniuk a biztonságra vonatkozó irányelveket.

Sérülékenységek kihasználása

A biztonsági csapatoknak a malware- és ransomware támadások mellett fel kell készülniük arra is, hogy megküzdjenek azon rosszindulatú szereplőkkel, akik a régebbi sebezhetőségek újrahasznosítását, vagy újonnan fellelt, esetleg még nem is publikus sérülékenységek kihasználását tervezik. 2021-ben rekord méreteket öltött a nulladik napi sérülékenységek kihasználása és ez idén sem csökken majd. Emiatt a vállalkozásoknak felkészültebbnek kell lennie a lehetséges támadási felületek csökkentését és a hiányosságok javítását illetően. Olyan megoldások bevezetését érdemes átgondolni, amelyek képesek akár hálózati szinten egy sérülékenység detektálására és blokkolására. Akár ismert, akár ismeretlen sérülékenységről legyen szó.

Arra számítunk, hogy 2022-ben a nulladik napi támadások száma új rekordokat dönthet a támadások felépítése és megtervezése során, így a korábbinál sokkal több sikeres támadás érkezhet ezekre alapozva. A támadók immár sok esetben a sebtiben kiadott hibajavításokban keresik a réseket, amelyeket még a felfedezés előtt kihasználhatnak. Olykor azonban még erre sincs szükség, mert a korábbi hibajavítások telepítésére sem volt elegendő idő vagy erőforrás, mivel nincs, aki elvégezze ezen feladatokat. Ennek köszönhetően a régi, már ismert sérülékenységek sem veszítik el vonzerejüket a támadók szemében. Sőt, nap mint nap fellelhetők a kiaknázásukra tett kísérletek nyomai világszinten, különböző biztonsági megoldások logjaiban. 2022-ben a támadók előszeretettel kombinálhatják a régi és új, ismeretlen sebezhetőségek kihasználási módjait és olyan vegyes támadásokat indíthatnak, amelyek kombinálják a privilégiumok eszkalációjával kapcsolatos sebezhetőségeket, egyéb hibák kihasználásával.

Az ismert sebezhetőségek növekedéséből adódóan - a felmerülő fenyegetések visszaszorítása érdekében - a vállalatoknak gondoskodniuk kell róla, hogy IT-biztonsági csapataik megfelelően felfegyverezzenek a megfelelő védelmi megoldásokkal a virtuális javítások végrehajtására és a szállítóktól érkező biztonsági frissítésekre. A felhőt alkalmazóknak pedig fel kell készülniük a felhőalapú, natív biztonságra.

IoT veszélyek

A vállalatok a hatékonyabb hálózatfelügyeletre és átláthatóságra fognak törekedni, hogy megvédjék informatikai környezeteiket az IoT bevezetéséből származó fenyegetésekkel szemben.

Az 5G infrastruktúra bevezetésével - és más technológiai fejlesztésekkel - az IoT-eszközök hosszú utat tettek meg. A Cyber Magazine cikke szerint az Internet of Things (IoT) piaca az előrejelzések szerint 2026-ra 1,1 billió dollárosra nő. A hírnévnek azonban ára van, így az IoT-eszközök reflektorfénybe kerülésével a modern támadások szereplőinek figyelmét is felkeltették. Havonta több ezer kibertámadás érte az IoT-eszközöket és ez idén sem lesz másként. A 2022-re vonatkozó kiberbiztonsági előrejelzések egyike magában foglalja a fokozott IoT-biztonság iránti növekvő figyelmet. Várhatóan az IoT-eszközöket kísértő kiberfenyegetések az elkövetkező évben tovább növekednek, emellett pedig nagyobb jelentőségre tesznek szert majd a Privileged Access Management (PAM), behatolás megelőző rendszerek (IPS/IDS), és a hálózati analitikai megoldások (NDR), integrációk az IoT-eszközök biztonsága érdekében. Az IoT biztonság egy növekvő piac, amelyről az idei év során még írunk, s részletesebben kifejtjük majd annak veszélyeit.

Supply Chain Risk

Az elmúlt évben nagy port kavartak a Supply Chain alapú támadások és a világ még mindig nem tért magához teljesen az olyan pusztító ellátásilánc-támadások súlyos sokkjából, mint a SolarWinds feltörése, az Accellion megsértése és a Kaseya támadás. Ezek bebizonyították, hogy a fenyegetés szereplői milyen könnyen kompromittálhatnak egyszerre több száz szervezetet, egyetlen jól kidolgozott támadással, amellyel sikeresen megsértik az ellátási lánc egyetlen láncszemét, a szolgáltatás kritikus pontját.

Mivel az ellátási lánc támadásai által okozott károk mértéke lényegesen nagyobb, mint a többi támadási vektor, világszerte a kiberbűnözők kedvencévé vált. Az előrejelzések szerint 2022-ben az ellátási lánc támadásainak veszélye is fenyegeti a szervezeteket világszerte. Ezt figyelembe véve a harmadik fél kockázatkezelésének az egyik legfontosabb prioritásnak kell lennie a szervezetek számára az elkövetkező években.

Felhő biztonság?

Mivel egyre több szervezet alkalmazza a felhő alapú megoldásokat, a felhő sérülékenységei óriási veszélyt jelentenek az adatbiztonságra. Ezek a biztonsági rések súlyosan veszélyeztetik az ott tárolt összes értékes adat biztonságát és integritását. A HelpNetSecurity cikke szerint a vállalkozások 93 százalékának komoly aggodalma van a nyilvános felhőbiztonsággal kapcsolatban.

A felhős környezetek gyors növekedésének köszönhetően a támadási felület jelentősen megnőtt, s 2022-ben tovább bővülhet. A kiberbűnözőknek arra kell összpontosítaniuk erőfeszítéseiket és erőforrásaikat, hogy új hibákat és gyengeségeket találjanak a kialakult felhő környezetekben. Azoknak a szervezeteknek, amelyek a felhőre támaszkodnak az adatok tárolása és menedzselése során, komolyan fontolóra kell venniük, hogy erőforrásaikat a felhőbéli rugalmasságuk erősítésére összpontosítsák.

Összegzésként

Mindent egybevetve 2022-ben a döntéshozóknak és az IT biztonsági szakértőknek meg kell küzdeniük a régi és az új fenyegetésekkel egyaránt. A biztonsági előrejelzések értékes betekintést nyújtanak. Céljuk, hogy segítsenek a szervezeteknek egy többrétegű kiberbiztonsági stratégiát kialakítani, amely ellenálló az összetett és célzott támadásokkal szemben. Ennek a stratégiának a következőket kell tartalmaznia:

  • Kövesse a bevált biztonsági gyakorlatokat, beleértve a szigorú javításkezelési szabályzatokat, hogy megakadályozzák azon biztonsági rések kiaknázását, amelyeket a rosszindulatú szereplők egyébként továbbra is kihasználnának.
  • Nulla bizalom alkalmazása. Ellenőrizzék az összes felhasználót és eszközt - függetlenül attól, hogy már a hálózaton belül van-e vagy sem -, mielőtt engedélyeznék számukra a vállalati erőforrásokhoz való csatlakozást.
  • A szerverbiztonság szigorítása és a hozzáférés-szabályozás alkalmazása. Olyan biztonsági szabályzatokat kell alkalmazni, amelyek a műveletek minden szintjét védik, és figyelembe veszik a hibrid munkarendet. Ez lehetővé teszi az alkalmazottak számára, hogy távolról is hozzáférjenek az érzékeny vállalati erőforrásokhoz.
  • Átállás erősebb biztonságra a megfelelő megoldásokkal, a szakértelem és tudás fejlesztésével. Minden biztonsági szinten le kell küzdeni az egyre összetettebb kiberfenyegetéseket , az alkalmazott fejlett és automatizált megoldásokkal, amelyek a dedikált biztonsági elemzők fenyegetésintelligenciából származó információi alapján rendelkezésre állnak.

Ha egy stratégia kidolgozásakor figyelembe vesszük a fentieket, úgy jó esélyünk van arra, hogy jelentősen csökkentsük a sikeres támadások számát és megvédjük fontos vállalati adatainkat az idei évben.

Ezekről a témákról Guszti év közben rendszeresen tart majd előadást az InfoSec Akadémián.

b0f22d0b64f312b26a65c3b5f4c8c1b0.png

Log4j sérülékenységek – Veszélyben az ipari rendszerek?

Hunyadi Péter cikke

2021. december 23. - EURO ONE

 

2021. december 9-én vált ismertté, és azóta hangos a kiberbiztonsági sajtó (ha van ilyen) attól a sérülékenységtől, amely az Apache Foundation által fejlesztett Java alapú Log4j elnevezésű naplózási eszköz 2. verziójával kapcsolatosan derült ki. A sérülékenység a CVE-2021-44228 azonosítót és a Log4Shell nevet, CVSS skálán (Common Vulnerability Scoring System, a sérülékenységek súlyosságát meghatározó pontozási rendszer) pedig a legmagasabb 10-es értéket kapta. Súlyosságát jelzi, hogy a Log4j használata rendkívül elterjedt, valamint a Log4Shell nehezen detektálható módon ad lehetőséget kártékony kódok távolról történő lefuttatására. Szükségesnek láttam röviden, nem belebonyolódva a technikai mélységekbe bemutatni a sérülékenységet és annak ipari (ICS) hálózatokra gyakorolt hatását.

Mi is az a Log4Shell?

A sérülékenység a széles körben elterjedt logolási eszköz, a Log4j log-kezelési mechanizmusára épül. A támadó a hálózaton kívülről indíthat kérést a kiszemelt szerver irányába, amelynek fejlécébe beágyaz egy JNDI keresést indító (Java Naming and Directory Interface) string-et. Ahogy a Log4j naplózza a kérést, lefuttattja a benne kapott keresést, amely viszont egy távoli, a támadó által kontrollált LDAP szervert kérdez le, ahonnan letöltődik és lefut a kártékony kód, akár egy, a gyártást teljesen leállítani képes ransomware. Így gyakorlatilag távoli hozzáférés, vagy C2 kapcsolat nélkül nyílik lehetőség bármely malware célbajuttatására és lefuttatására a támadók gépeiről (RCE – Remote Code Execution), és megszerezhető a hozzáférés az áldozat rendszeréhez (Initial Access).

Ha azt feltételezzük, hogy a támadó már bejutott a hálózatunkba, akkor az ezen belüli mozgáshoz (Lateral Movement) is kihasználható a Log4Shell, ebben az esetben viszont a már egy helyi szerverre eljuttatott kártékony kódot kell lefuttatni (LCE – Local Code Execution).

A Log4Shell-re válaszul kiadott első patch-eket követően derült fény egy másik ezzel összefüggő sérülékenységre, amely a CVE-2021-45105 azonosítót kapta, és DoS (Denial of Service) támadásra ad lehetőséget. A Log4j a „ThreadContext map”-ben megkeresi a naplózott kérésekben található változókat, mint például a felhasználónevet. A támadó ezt képes úgy manipulálni, hogy ez a keresés végtelenszer újra generálódjon, ha egyszer elindították, amely túlcsordulásos hibához (Stack Overflow failure) vezet és leállíthat létfontosságú szolgáltatásokat, amelyek talán épp a legkritikusabb termelési folyamatokhoz szükségesek.

ICS érintettség

A Log4j használata, mint már azt említettem, nagyon elterjedt és ez alól nem kivételek ICS gyártók sem, mivel az ipari rendszereknél is fontos funkció a különböző biztonsági és teljesítmény információk naplózása. Az egyik legnagyobb és legelterjedtebb ICS és IIoT gyártó Siemens jelentése szerint 17 termékük érintett az elsőként felfedezett sérülékenységben, melyek között megtalálható a PLC-k programozására használt LOGO! SoftComfort szoftver is. Érintettek még többek között a Java-t használó OPC-UA szerverek, SCADA (Supervisory Control and Data Acquisition) és EMS (Energy Management System) rendszerek, valamint a szerverek virtualizációjánál ICS környezetben is előszeretettel használt VMware ESXi.

Az ipari hálózatok gyenge pontjai tehát az internetre kilátó és Log4j 2-t használó eszközök, valamint azok a hálózati kapcsolatok, amelyek egyik végén az irodai IT hálózat valamely, ebben a sérülékenységben érintett eszköze található.

Hogyan reagáljunk?

A legkézenfekvőbb megoldás a sérülékeny eszközök frissítése a legújabb verzióra (patch-elés). Az Apache Foundation által kiadott 2.17 verzió mindkét tárgyalt sérülékenységre megoldást kínál. Viszont itt jön a képbe az időtényező, ami nem a biztonsági szakembereknek dolgozik. A Log4j sokszor több szinten van alkalmazva, így a teljeskörű frissítés bonyolult és hosszadalmas feladat akár csak egy rendszer esetén is. Mindenképp szükséges a patch-ek telepítése, viszont a reakciónkat érdemes több vonalon elindítani.

Legyünk tisztában az érintettségünkkel.

Gyakori probléma, hogy az üzemeltetők nem ismerik megfelelően a saját hálózatukat, főleg nem azt, hogy hány potenciálisan érintett eszközzel rendelkeznek. Érdemes most dönteni hálózatfelügyeleti képesség bevezetéséről, amely alkalmas a kommunikáló és nem kommunikáló eszközök felderítésére, jelezve azok sérülékenységeit. Több gyártó rendelkezik már frissítésekkel a Log4Shell és a kapcsolódó sérülékenységek felismerésére és az azokat kihasználó támadások detektálására. Az ezek által összegyűjtött eszközleltár segítségével hamarabb látható a hálózat támadási felülete, gyors észlelés pedig elengedhetetlen, ha a megtörtént incidens további eszkalálódását meg akarjuk előzni.

Figyeljünk az IT-re.

A Log4Shell a laterális mozgás eszköze is lehet, tehát használható az eleve kompromittált IT hálózatról a gyártási szegmensbe történő vándorláshoz. Jobb, ha a támadók csak az IT hálózaton maradnak, illetve, ha oda sem jutnak be. Hogy egy egész vállalati hálózatot érintő támadást csírájában elfojthassunk, szükségünk van IT oldalon valamilyen SIEM rendszer alkalmazására, valamint az ez és az ICS oldali hálózatfelügyeleti rendszer által észlelt aktivitásokat közösen monitorozni egy IT/ICS műveleti központban (Security Operations Center, SOC). Ennek bevezetése igen komplex feladat, így természetesen ez hosszabb távú fejlesztés tárgya, ám annál nagyobb előrelépést jelent.

Gondoljuk újra a hálózati architektúrát.

A fő támadási vektorok a direkt internetkapcsolatok és az IT hálózattal való direkt kommunikáció. Mivel mindkettő forrásra szükség van, nem zárható le hermetikusan egy ICS rendszer sem, viszont érdemes minden külső kommunikációt DMZ szegmenseken (akár külön a közös elérésű szervereknek, és külön a gyártói frissítések kezelésének) keresztül bonyolítani, hogy egy esetleges kártékony kód futtatás minél kisebb területre legyen koncentrálható, elkülönítve a kritikus rendszerektől. A DoS támadásokkal szemben használjunk ICS környezeteknek megfelelő hálózati és végpontvédelmi eszközöket. A tűzfalakat frissítsük a legújabb szoftververziókra, és érvényesítsük a Zero Trust elvet az ICS hálózati hozzáférések kezelésénél.

Maradjunk naprakészek.

A fenyegetések és sérülékenységek kutatásával foglalkozó szervezetek (CISA), valamint az érintett gyártók (Siemens) folyamatosan publikálják a Log4j sebezhetőségeivel kapcsolatos fejleményeket, frissítéseket és termékspecifikus kockázatcsökkentési javaslatokat. Legyen egy felelős személy, aki követi ezeket. Gondoljunk arra, hogy a Log4j első, Log4Shell-re keresztelt sérülékenységének felfedezése és kezdeti patch-ek megjelenése után még fény derült újabb biztonsági résekre és a kiadott frissítések hiányosságaira.

Végezetül…

A Log4Shell és „kistestvérei” természete és az általuk jelentett veszély felderítése még gyerekcipőben jár, de rendkívül fontos az időben elkezdett és a jelenleg ismert „best practice”-ek szerinti reagálás. Különösen gyártással foglalkozó cégek és létfontosságú rendszerelemek esetében fontos az óvatosság, mivel sajnos pont az ünnepek előtt érte az IT/ICS világot ennek a híre és félő, hogy támadói oldalon hamarosan megnövekedik az aktivitás, ugyanis ki ne próbálná meg melegében kihasználni a jelenlegi, kissé kapkodás jellemezte légkört.

 

 Jövőre folytatjuk!

Boldog karácsonyt és sikeres új évet kíván az EURO ONE InfoSec csapata!

Az ipari biztonság jövője, avagy Zero Trust OT környezetben

Hunyadi Peti bejegyzése Tom Thirer cikke alapján

2021. december 09. - EURO ONE

Miként az élet többi területén, úgy a kiberbiztonságban is mindenki számára a saját környezetének biztonsága az elsődleges. Ráadásul - ahogy az az élet minden vonatkozásában lenni szokott - akadnak olyan területek, amelyekkel kissé mostohábban bánnak azok, akik valóban tehetnének érte. Kicsit ilyennek tűnik az ipari kiberbiztonság is.

zero-trust-ot--blogposzt.jpg

Ha valaki folyamatosan nyomon követi a híreket, 2021-ben többször találkozhatott olyan kritikus infrastruktúrák ellen intézett támadásokról, mint az olajvezetékek üzemeltetői, élelmiszergyártók vagy éppen a vízkezelő szervezetek. Korábban az ilyen támadások visszhangja jóval kisebb volt a médiában és az egyes iparágak képviselői is kissé félvállról vették a dolgot. Ám mostantól ez változhat!

Ahogy az ipari hálózatok kiberbiztonsági kitettségének mindennapi életre gyakorolt hatása egyre inkább kézzelfoghatóbbá válik, az érintett szervezetek, szakemberek is elkezdenek e területre összpontosítani. Sőt, az ipari kibervédelmi tudatosság immár a legmagasabb kormányzati szintekre is eljutott: Joe Biden, az Egyesült Államok elnöke 2021 májusában kiadta a Nemzet kiberbiztonságának fejlesztéséről szóló rendeletét, amely - nem túl meglepő módon - kiemelten foglalkozik a kritikus infrastruktúrákkal. Az elnök rendelkezése szerint a „védelem hatóköre magába kell, hogy foglalja az információs (IT) és a gyártást és munkavédelmet kiszolgáló (OT) rendszereket egyaránt”.

Fontos tudni, hogy a terület kockázati profilját három tényező alakítja:

  • Egyre több kritikus infrastruktúra üzemeltető fordul a digitalizáció felé, ami növeli a fenyegetettséget.
  • Az IT és az OT összeolvadása a hagyományos IT támadásokat relevánssá teszi a gyártósorokra nézve is.
  • A támadói eszköztár egyre kifinomultabbá válik, legyen szó bűnelkövetői csoportokról vagy nemzetállamokról.

Már csak ezek alapján is elmondható, hogy bár a Biden-féle lépés örvendetes, ám jelenleg korántsem elégséges az ipari kiberbiztonságban. Ennél kicsit többre lesz szükség a hatékony megoldások kidolgozásához.

Növekvő kitettség és téves megoldások

Az ipari hálózatok külső összeköttetésének erősödésével a legtöbb hagyományos védelmi stratégia - mint a már sokat hallott izoláció - irrelevánssá és haszontalanná válik. Bár megannyi szervezet gondolkozik IT biztonsági megoldásokban, keresve azok integrációs lehetőségeit ICS eszközökkel, de ez sajnos halva született megközelítés. Főleg akkor, ha hálózatok feltérképezéséről van szó. Ezen hálózatoknak speciális megoldásokra van szükségük a hatékony védelem eléréséhez, ráadásul adott esetben akár épp a fent említetthez hasonló környezetidegen védelmi technológiák növelik a veszélyt, leállásokat vagy hamis riasztásokat okozva.

Ezek helyett az érintett szervezeteknek olyan OT specifikus megoldásokra van szükségük, amelyek Zero Trust képességekkel rendelkeznek. Ez dióhéjban a megfelelő azonosítással és jogokkal nem rendelkező felhasználók, eszközök hozzáféréseinek korlátozását jelenti.

Lássuk, miként működik mindez ipari környezetben!

Zero Trust OT hálózatban

A Zero Trust megközelítés mottója: „sose bízz, mindig hitelesíts”. Ez ipari környezetben rendkívül hasznos elv, ám érvényesülésének több akadálya van. Egyrészt sok OT eszköz és rendszer a mai napig titkosítatlan és hitelesítésmentes protokollon kommunikál. Másrészt a titkosítással és hitelesítéssel rendelkező rendszerek üzemeltetői ódzkodnak eszközeik internetes kommunikációjának engedélyezésétől, így igény sem alakul ki a Zero Trust megközelítésre. Ezt a hozzáállást azonban az IT-OT konvergencia egyre inkább felülírja, aminek köszönhetően szükségé válik a modell bevezetése által eredményezett magas szintű hozzáférés-kezelés, s ezáltal a támadási felület csökkentése.

Megfontolandó Zero Trust kontroll a többfaktoros hitelesítési eljárás (MFA), például szerepkör-alapú hozzáféréssel ötvözve. Az MFA során a hozzáféréshez kettő - vagy több - érvényes azonosító eszköz bemutatása szükséges, melyek extra biztonsági rétegeket képeznek a jogosulatlan hozzáférésekkel szemben.

Nyilvánvaló, hogy a Zero Trust bevezetése egyáltalán nem egyszerű, többtényezős folyamat, viszont - azt keretrendszerként használva - újragondolni OT hálózatunk védelmét mindenképpen bölcs lépés.

Hogyan segíthet a SCADAfence?

A SCADAfence ICS biztonsági gyártó teljes átláthatóságot biztosító platformja integrálható a Zero Trust modellbe, valamint csoport alapú szegmentálást hajthatunk végre vele ICS hálózatokon belül. Az ipari kiberbiztonságban piacvezető Einstein-tanulási mechanizmus segítségével a platform két nap alatt feltérképez (ún. „tanulási fázis”) egy komplett ipari hálózatot, ami magába foglalja az előforduló hálózati forgalmi mintázatokat, az egyes eszközök viselkedését, illetve az alhálózati topológiát egyaránt. Ezt követően a SCADAfence a megtanult, normális aktivitástól eltérő eseményeket észleli, majd riasztásokat generál. Ha az Einstein-tanulási fázis alatt a platformon engedélyezzük a Zero Trust modellt, akkor felelősi jóváhagyásig minden hálózati eseményt gyanúsként kezel és automatikusan riaszt.

Mint ezekből is kitűnik, a SCADAfence Platform Zero Trust integrációs funkciója, továbbá folyamatosan bővülő képességei, segíthetnek elmozdulni az alapvető biztonsági szintről a fejlett és agilis biztonsági menedzsment irányába.


Az InfoSec Akadémiára már felkerült egy korábbi webinár a SCADAFENCE ipari megoldásáról. 


b0f22d0b64f312b26a65c3b5f4c8c1b0.png

Egy sikeres ISO 27001 bevezetés gyakorlati tapasztalatai

Tóth Tamás cikke

2021. december 07. - EURO ONE

Az ISO 27001-ről és az ISMS bevezetésről szóló cikksorozatom lezárásaként egy 1 évig tartó ISMS bevezetési projekt gyakorlati tapasztalatait kívánom megosztani. A tanúsító audit megállapítások és nemmegfelelőségek azonosítása nélkül, 3 erősség kiemelésével zárult, tehát a projekt sikeres lett.

iso-27001-bevezetes-blogposzt.jpg

Természetesen a felsoroltaknál sokkal több gyakorlati tapasztalatról lehetne értekezni, de az alábbiakat mindenképp kiemelném:

  • A vezetői elkötelezettség elengedhetetlen. Minden projektben vannak holtpontok, egy ISMS bevezetés során több ilyen is előfordulhat. Az állandó és szilárd vezetői elkötelezettség át tudja billenteni a projektet ezeken a holtpontokon, a projekt összecsapása vagy feladása helyett. Ezen kívül természetesen a projekttagokat is motiválni kell, ami legfőképp az ő területükön jelentkező előnyökkel lehetséges.

 

  • Az alapos projektmenedzsment fél siker. Az előbbi mondat gyakorlatilag minden projektre igaz lehet, de ha az ISMS követelmények komplexitására, az érintett területek széles spektrumára és az elérendő változások nagy mértékére gondolunk, akkor nem túlzás kijelenteni, hogy egy sikeres ISMS bevezetés a jó projektmenedzsmenten állhat vagy bukhat. Elengedhetetlen, hogy rendszeresen státuszoljunk és a részletek mellett magasszintű rálátás is kell az egész projektre és ha valami nem a tervek szerint alakul, akkor arra már korán figyelmeztetni kell. A projektterv, mérföldkövek, feladatok és ezek függőségeinek meghatározása, tervezése, megértése alapszintű elvárás. Az ütemezés során ráhagyásokkal kell számolni, hogy csúszások esetén legyen miből gazdálkodni. Az ISMS bevezetés ügyfél oldalon mindig belső projekt, amelyek előrehaladását sok dolog - leginkább a fizetős projektek - visszafoghatja. Menet közben nagy valószínűséggel kiderülhetnek olyan súlyos hiányosságok (pl. magas kockázatok), amelyek megoldása időigényes. Sokszor eljöhet az a pont, amikor inkább az újra ütemezés célravezetőbb, mert az eredeti ütemezéshez való görcsös ragaszkodás a minőség vagy a projekt sikerességének a rovására mehet. A súlyos hiányosságok kijavítása nem minden esetben, de gyakran költséges lehet (pl. új generációs tűzfalak beszerzése, licenszek vásárlása), így ezeket is előre kell jelezni és a tervezés során minél több információt kell beszerezni ezekre vonatkozóan.

 

  • Ismerni és érteni kell a szabványokat. A projekt szakmai vezetőjének alaposan ismernie kell az ISO 2700x szabványcsalád releváns tagjait: 27000, 27001, 27002, 27003, 27005, ezen belül a logikájukat, elveiket és az elvárásaikat. Vegyülnie kell a minőségügyi "quality-s" nézőpontnak, valamint az információbiztonsági kockázatkezelési és technikai nézőpontnak, hiszen ahogy a korábbi cikkekben írtam, a 27001-es szabvány két elválaszthatatlan részből áll, amelyeket eltérő módon kell megközelíteni. Meg kell tudni érteni és be kell tudni csatornázni például a stakeholderek elvárásait, de a kontrollok technikai hátterét és célját is érteni kell, hogy a kontrollok bevezetésének/alkalmazásának részleteit, követelményeit megfelelően lehessen átadni a végrehajtásért felelős projekttagoknak és a végrehajtást is vissza lehessen ellenőrizni.

 

  • Auditor szempontot is érvényesíteni kell. Ahogy a korábbi cikkeimben hangsúlyoztam, ha jó ISMS-t szeretnénk bevezetni, akkor nem csak a papírozással törődünk, hogy átcsússzunk az auditon. Ugyanakkor mégis nagy gondot kell fordítani arra, hogy a saját munkánkat auditori nézőpontból is értékeljük és feltegyük a kérdéseket: Megfelelően teljesítjük az elvárt követelményeket? Megfelelő dokumentációval rendelkezünk? Vannak evidenciáink a megfelelő működésre vonatkozóan? Mindenki ismeri a rá vagy a területére vonatkozó követelményeket? Ha nem vagyunk teljesen magabiztosak a válaszainkat illetően, akkor még lesz munkánk az audit előtt.

 

  • Fenntartható dokumentációt kell kialakítani. Szintén visszautalva a korábbi cikkekre, az ISMS dokumentációval jár, ebből azonban előnyöket lehet kovácsolni, hiszen a működés és a követelmények kialakításával vagy fejlesztésével és azok leírásával egyből növekszik a szervezet érettségi szintje. Nagyon fontos, hogy a dokumentációt logikusan felépített struktúrába kell rendezni és erősen ajánlott a GRC platformok vagy más támogató rendszerek igénybevétele és későbbi használata. Ellenkező esetben a dokumentumok és a tudás el fog veszni vagy csorbulni fog, ami megállapításokhoz, komolyabb esetekben nemmegfelelőséghez vezet az ISMS működtetésével járó munka megkeserítése mellett.

 

  • Bevezetés után nem ajánlott egyből tanúsítani - Ha összeálltak az ISMS alkotóelemei és a dokumentációja, akkor még nem ajánlott az azonnali tanúsítás. Lehetőleg már a projekt korai szakaszaitól kezdve az ISMS előírásai szerint kell működni és alkalmazni kell a kontrollokat (pl. hozzáférési jogok felülvizsgálata, BCP-k tesztelése, tűzfalszabályok felülvizsgálata, stb.) és az irányítási rendszer alkotóelemeit (pl. vezetőségi átvizsgálások, projekt áttekintő értekezletek lebonyolítása, célok kijelölése és nyomon követése, stb.). Ez azért hasznos, mert ezek a tevékenységek hamarabb megszilárdulnak és csiszolódnak, továbbá evidenciák állnak elő az ISMS szerinti működésről. Egy nem régóta működő irányítási rendszert nehezen lehet auditálni.
    Másik erősen ajánlott - és egyébként kötelező elem - a belső audit lebonyolítása. A projekt sikere szempontjából célszerű az első belső auditot kiszervezni egy komoly referenciákkal rendelkező, független külső félnek, aki nem vett részt a bevezetésben és ezáltal objektív módon tudja lebonyolítani az auditot. Ezzel nem csak a kötelező követelmény teljesül, de felszínre kerülhetnek olyan hiányosságok vagy fejlesztési lehetőségek, amelyekre a bevezetés során esetleg nem gondoltunk vagy másképp ítéltük meg a súlyát. Ezek felismerése és korrigálása nagy mértékben hozzájárul a projekt sikeréhez. A projekttervezésről szóló cikknél említettem, hogy a belső auditot úgy kell beütemezni, hogy elegendő idő legyen az esetlegesen feltárt hiányosságok javítására. A menetrend tehát a következő: bevezetés, működtetés, belső audit, tanúsító audit.

ismstt.jpg

 

  • A tanácsadó egyedül nem tud mindent megoldani. A tanácsadó a szabványismeretével, a szakmai tapasztalatával, minősítéseinek és vizsgáinak gyakorlati tudássá alakításával segíti a projekt tervezését, dokumentáció kialakítását, konkrét javaslatokat ad a követelmények ügyfél általi bevezetésére és alkalmazására. Gyakori tévhit, hogy az egész munkát ki lehet szervezni a tanácsadónak és ő egyedül mindent meg tud oldani. Elengedhetetlen egy - ügyfélnél dolgozó - belső kontaktszemély kijelölése, aki az ügyfél szervezetén belül összefogja a munkát és segít a tanácsadónak eligazodni a belső formális és informális viszonyok közt. A nap végén az ügyfélnél dolgozóknak vagy az ügyfél részére szolgáltatást nyújtó harmadik feleknek kell a gyakorlatban alkalmazni a szabályzatokban, folyamatokban leírtakat.

 

  • Az ISMS-t működtetni kell - A sikeres tanúsító audit után meg kell ünnepelni az elért eredményeket, ahogy azt az alábbi kép 15. lépése is javasolja. A kép az iso27001security.com ISO 27001 Toolkitéből származik, azon belül az ISO27k ISMS implementation and certification process 4v1 c. dokumentum szemlélteti az ISMS bevezetés fő lépéseit, amelyre a tervezés során mi is támaszkodtunk. Az ünneplés után nem lehet hátradőlni, a 16. lépésnek megfelelően a lerakott alapok, éves ütemterv, kialakított felelősségi körök és átadott tudás alapján kell működtetni az ISMS-t. A szóban forgó projektnél is így történt: az audit utáni szabadság után az ISMS működtetésével járó munka az utolsó negyedéves és a következő éves feladatok megtervezésével, az információs vagyonelemleltár frissítésével és az éves kockázatelemzéssel folytatódott.

 

Az ISMS gyakorlati lépésiről szóló leírás megtalálható az EURO ONE InfoSec Akadémián. 
A fentebb említett projektről hamarosan egy beszélgetést osztunk meg Tamással, ahol bővebben is beszél az 1 éves projektről. 

b0f22d0b64f312b26a65c3b5f4c8c1b0.png

Valójában beszélhetünk-e AI-ról a kiberbiztonságban?

2021. november 09. - EURO ONE

A mesterséges intelligencia a kiberbiztonágban

 

2021-ben nem kell sokat görgetnünk az Interneten, hogy a “mesterséges intelligencia” (artificial intelligence – AI) szavakkal találkozzunk, de még nagyobb a valószínűsége, hogy szembejön velünk ez a kifejezés, ha valamilyen IT-vel kapcsolatos területen tevékenykedünk. Mint más iparágakban, az AI az kiberbiztonság területén is felkapott téma lett. De valóban mesterséges intelligencia-e az, amit az IT-biztonsági szakemberek mesterséges intelligencia alatt értenek? Ha érdekli a válasz, olvasson tovább.

A mesterséges intelligencia kezdetei

Sokak számára, attól függően, hogy milyen területen dolgoznak, a mesterséges intelligencia egy felkapott, viszonylag új keletű kifejezésként hathat, ami csupán az elmúlt időben épült be a köztudatba. Azonban az AI már 1993-ban is létező kifejezés volt, amikor a kognitív rendszerekkel kapcsolatos kutatások beindultak. Akkoriban a “mesterséges intelligencia” kifejezést túl ambiciózusnak tartották, főleg a tudomány akkori álláshoz képest. De ami ennél is meghökkentőbb, az az, hogy az AI fogalma még ennél is jóval régebben született meg: a gondolkodó gép gondolata a második világháború környékén fogalmazódott meg Alan Turing elméjében – jóval azelőtt, hogy megjelentek volna működőképes számítógépek és szoftverek, amelyek által az egész megvalósíthatóvá vált. Azonban az elmúlt 30 (vagy inkább 80) évben sok minden változott. Az “AI” felhasználása elterjedtté vált sok különböző szektorban, mint például a big data, az okos város, az önvezető autó, sőt, az egészségügy területén is – a szakemberek pedig már nem bánnak olyan óvatosan ezzel a kifejezéssel.

AI kontra ML kontra DL

Mielőtt rátérnénk arra, hogy mit jelent pontosan az AI a kiberbiztonságban (és más szektorokban is, ha már itt tartunk), érdemes tisztázni pár kapcsolódó kifejezést, amelyek hasznosnak fognak bizonyulni, amikor közelebbről is megvizsgáljuk a helyzetet.

 

Habár a deep learningre (DL) és a machine learningre (ML) is több figyelem irányult az elmúlt időben, ezeket még mindig nem emlegetik olyan gyakran, mint az AI-t, amire meg is van a magyarázat. Ami azt illeti, amikor az emberek mesterséges intelligenciáról beszélnek – és nem is kizárólag csak a laikusok –, hajlamosak a DL-t és ML-t is AI-nak címkézni, pedig ezek a kifejezések nem felcserélhetők. Persze vannak hasonlóságok és átfedések ez a három technológia között, de messze állnak egymástól, és nem is szabadna egyként kezelni őket. Vizsgáljuk meg őket egyenként.

 

Deep learning

A deep learning kifejezés egy olyan technológiát takar, amely gondolkodni ugyan nem képes, de meg tudja tanulni, hogy hogyan dolgozza fel az agyunk az információt, és utánozza a folyamatot anélkül, hogy bármilyen hálózattal modellezné azt. Képes szimulálni az emberi viselkedést, de mint ahogy a repülés szimuláció és igazi repülés között is van különbség, vannak határai, amelyeket nem tud átlépni. Azonban ez nem azt jelenti, hogy a DL nem értékes. Sőt, a DL-t bevált és megbízható technológiaként alkalmazzák például leszállási rendszerekben is. De fontos megjegyezni, hogy hatalmas mennyiségű adatra van szüksége, hogy megfelelően működjön.

Machine learning

Ezzel ellentétben, a machine learningnek nincs szüksége sok adatra, hogy hatékony legyen. Abban különbözik a DL-től, hogy kivételek betanítása által, valamint ember által betáplált tanácsokkal is lehet okosítani. Az algoritmus képes magán is változásokat végrehajtani (melynek megnevezése “unsupervised”), de végrehajthat változtatásokat rajta egy adatelemző is (“supervised”). Habár ez utóbbi kétségtelenül rendelkezik előnyökkel, mint például a rugalmasság, mégis az első bizonyul igazán értékesnek, mivel az képes kiváltani az emberi erőforrást, amely meglehetősen szűkös mostanában, mint ahogy azt Önök is tudják. Emellett az ML remekül tud feladatokat támogatni, még akkor is, ha nem érti, hogy mit csinál. Más szóval, nem tudja, hogy “miért”, de tudja, hogy “hogyan”.

Mesterséges intelligencia

És el is érkeztünk a lényeghez, a mesterséges intelligenciához. Az AI képes mind arra, amire a fenti két technológia képes, de még ennél is sokkal többre: képes tapasztalatból tanulni, mint az emberek. Képes interakcióra és képes érvelni. Magyarán annyira emberi, amennyire egy gép az lehet.

 

Az AI először 1997-ben tett szert igazi hírnévre, amikor az IBM által fejlesztett Deep Blue legyőzte sakkban az akkori nagymestert és hosszú éveken át veretlen világbajnokot, Garry Kasparovot, aki azt megelőzően egyetlen meccset sem veszített még. Az AI persze sokat fejlődött azóta (a Deep Blue-t magát nem is arra programozták, hogy emberként gondolkodjon, hanem “csupán” arra, hogy képes legyen hiba nélkül sakkozni), de ez mindenképpen egy mérföldkő volt a technológia számára, amely nagy visszhangot váltott ki. Az AI-ban rejlő hatalmas potenciálnak, valamint a fogalom körül a science fiction és a popkultúra közreműködésével kialakult felhajtásnak köszönhetően nem csoda, hogy az emberek mindent megtesznek, hogy azt mondhassák: “mesterséges intelligenciával dolgoznak”.

Valóban van-e a kiberbiztonságban AI?

Röviden: nincs, legalábbis nem teljesen. A kiberbiztonságban kétségkívül alkalazni fogják az AI-t a jövőben, de egyelőre amit annak neveznek, az valójában egy ML képességekkel bíró szakértői rendszer. Nézzük meg közelebbről, hogy mi is jelent ez.

 

Szakértői rendszerek

A szakértői rendszerek olyan számítógépes rendszerek, amelyek emulálják egy emberi szakértő döntéshozatali képességét, és komplex problémákat tudnak megoldani érvelés által, if-then szabályok nagy mennyiségű adaton történő alkalmazásához hasonlóan. A szakértői rendszereket két alrendszerre osztjuk, a következtető rendszerre és a tudásbázisra. A tudásbázis tartalmazza a tényeket és a szabályokat, amelyek alapján a következtető rendszer alkalmazza a szabályokat az ismert tényekre, és új tényeket állapít meg. Ugyanakkor egy szakértői rendszer nem képes önállóan és pontosan kiszűrni egy hackert. Ehelyett képes értesíteni a SOC elemzőt az olyan incidensekről, amelyek nagy valószínűséggel lehetnek támadások vagy egyéb veszélyforrások. Ezt követően az ML további if-then szabályokkal egészíti ki a tudásbázist, hogy az a jövőben pontosabb tudjon lenni. Azonban mivel gyakran nem érkezik visszajelzés a tényleges felhasználótól, az emberi szakvéleményt leginkább a szolgáltató adja.

 

De akkor miért mondja az iparág ennek ellenére továbbra is, hogy “AI”? A válasz egyszerű: a “szakértői rendszer” kifejezés nem eléggé piacképes, így hát nem is használják sokat. Tehát ha bármilyen kiberbiztonsági anyagban mesterséges intelligenciát emlegetnek, valójában egy ML képességekkel bíró szakértői rendszerről, valamint a fent leírt következtető műveletről beszélnek.

Állapotjelentés az AI-ról a kiberbiztonságban

Nézzünk egy analógiát egy másik szektorból, hogy még tisztább legyen. Az autóiparban például sokat hallhatunk vezető asszisztens rendszerekről és önvezető autókról. A legtöbb ember számára ez a két kifejezés hasonló fogalmat jelenthet, de a valóságban jelentős különbségek vannak a kettő között. A vezető asszisztens rendszerek nem többek mint szakértői rendszerek, amelyeket fentebb már alaposan körbejártunk. Az önvezető autókat azonban machine learning és a fejlesztői szakasz során hozzáadott vezetői visszajelzések is segítik.

 

Na most, ha vesszük a vezető asszisztens rendszereket és önvezető autókat, és ezek között szerenék elhelyezni a kiberbiztonság “AI” képességeit, azok valahol a kettő között lennének félúton. Ez azt jelenti, hogy megvan az AI-ban a potenciál, hogy önállóan SOC elemzőként cselekedjen a jövőben, mint ahogy az önvezető autó is képes sofőrként cselekedni, de ehhez intenzív visszajelzésre van szükség minden érintett felhasználótól a rendszerben.

 

Mindazonáltal a kiberbiztonságban jelenleg alkalmazott AI segít megküzdeni egy olyan kiemelkedő problémával, amely megvetette a lábát a szektorban; ez pedig nem más, mint a személyzethiány. Ahogy azt a területen dolgozó emberek bizonyára tudják, egyszerűen nincs elegendő SOC szakértő a szektorban, amelyből következik, hogy nagy kihívást jelent a megfelelő számú újonnan érkezők betanítása és tapasztalatszerzése is. Azonban az AI – még jelenlegi érettségi szintjén is – rendkívül hasznosnak bizonyul a SOC dolgozók számára, és arra is megvan benne a potenciál, hogy a jövőben átvegyen tőlük bizonyos feladatokat.

A mesterséges intelligencia jövője a kiberbiztonságban

Ha most azt gondolná, hogy az IT biztonság nem teljesít túl jól az AI területén, az tökéletesen érthető lenne. A helyzet azonban egyáltalán nem olyan rossz. Az előző analógiánkhoz visszatérve nem volt teljesen igazságos az összehasonlításunk – az utak ritkán változnak, de a kiberbiztonsági környezet annál inkább, amely meglehetősen megnehezíti a fejlődést. Mielőtt “igazi” AI-t alkalmazhatnánk az IT biztonságban, először meg kell tanulnunk, hogy hogyan tudjuk kiaknázni teljesen a machine learning és szakértői rendszerek adta lehetőségeket, és csak ezután tudnak a rendszereink továbbfejlődni a következő fázisba.

 

Mindemellett az AI rendszereknek is fel kell nőniük. Nem lehet őket a kelleténél korábban munkába állítani, majd magasra helyezni a feléjük állított elvárásainkat, mert ettől csak a hitünket fogjuk elveszíteni a kiberbiztonságban alkalmazott AI-ban – ami kár lenne, mert nagy benne a potenciál. A SOC rendszerek egyszer képesek lesznek megjósolni a támadásokat azelőtt, hogy azok megtörténnének, ezáltal a cégek által elszenvedett károk nullára fognak redukálódni. Más szóval az AI segítségével a kiberbiztonsági műveleti központok többé nem reaktívan, hanem proaktívan fognak működni, előre figyelmeztetve minket a támodásokra ahelyett, hogy olyanokra reagálnának, amelyek már pusztítást végeznek. És ez az ismert fenyegetésekről az ismeretlenekre irányuló fókuszváltás éppen az a cél, amit egy hatékony SOC-nak ki kéne tűznie maga elé.

 

De hogy érhető el mindez? Először is a kiberbiztonságban alkalmazott AI képességeinek képesnek kell lenniük lépést tartani a fenyegetések fejlődésével, amely szorosan követi a technológiában történő fejlesztéseket. A támadási felületeink folyamatosan fejlődnek és bővülnek, de túl sok az összefüggéstelen és strukturálatlan adat, amely akadályozza a SOC elemzőket a gyors és hatékony incidens felderítésben és válaszadásban. A jelenleg használatban lévő, hatástalan megfigyelő technológiák általánosságban nem adnak a specialistáknak elegendő rálátást. Hogy lépést tudjunk tartani ezekkel a fenyegetésekkel, a szakértőknek segítségre van szükségük a rendellenes viselkedések felderítésében, az ismert és ismeretlen fenyegetések azonosításában, valamint a támadások életciklusainak teljes átlátásában – a mesterséges intelligencia pedig, ha majd eléri a megfelelő fejlettségi szintet, éppen ezekben tud segíteni a kiberbiztonságnak.

 

Erről a témáról tartott előadást néhány személyes példával Corne van Roij az idei EURO ONE-RSA Cyber Security Summiton.
A summit előadásai hamarosan felkerülnek az InfoSec Akadémiára.

Az InfoSec Akadémia egy exkluzív klub IT security szakembereknek. További információ itt.

 

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!

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