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

EURO ONE

A biztonságfelügyelet kialakításának oka és módszere, hazai példákon keresztül

Lesku Gergely cikke

2020. június 15. - EURO ONE

Már 15 éve segítjük a cégeket, amikor biztonsági logelemző, vagy egyéb felügyeleti rendszerek kiépítése, SOC-ok létrehozása a feladat. Ennyi idő alatt bőven volt időnk felmérni, mi motiválja a vállalatok döntéshozóit, amikor kiválasztják a számukra ideálisnak tűnő megoldásokat.

Ösztönző tényező lehet például, hogy 2019-ben már átlagosan 206 napra volt szükség egy esetleges biztonsági incidens észleléséhez, ami 5 százalékkal hosszabb idő, mint az egy évvel korábbi eseteknél (forrás: IBM, The cost of a data breach study 2019). Ráadásul a preventív védelmi rendszerek sem feltétlenül jelentenek százszázalékos védelmet, azokon is átjutnak támadások. Éppen ezért egyre több vállalat dönt a biztonsági incidensekkel kapcsolatos elemzői és válaszadási képességének fejlesztéséről.

euro-one-pr.jpg

Egy már megtörtént incidensnél pusztán a hagyományos védekezési eszközök nem segítenek. Hiába a kiváló végpontvédelem, e-mail ellenőrzés, tűzfal és IPS rendszer, ha hiányoznak megfelelő elemzési képességek, nincs eszközük, tudásuk és gyakorlatuk, akkor továbbra is kiszolgáltatottak maradnak a veszélyekkel szemben.

Hol tart most Magyarország?

A hazai vállalatok felkészültsége ezen a téren igen eklektikus. Vannak olyan multinacionális cégek, amelyek a magyarországi csoport számára is központilag, fejlett módon nyújtanak felügyeletet. Sőt, a nemzetközi vállalatok között olyan is akad, amely épp budapesti központból végzi a felügyeletet, szerte a világban. Sajnos azonban nem ez a jellemző. A hazai vállalkozások túlnyomó többségében - még a magyar szemmel nézve nagyvállalati kategóriába soroltaknál is - nincs a biztonság felügyeletére megfelelő saját erőforrás, és külső szolgáltatót sem vesznek igénybe e célra.

Pozitívum azonban, hogy az utóbbi időben egyre több döntéshozót foglalkoztat ez a kérdés, így érezhetően megnőtt az igény mind a saját felügyeleti megoldások kidolgozására, mind a szolgáltatók bevonására. A kiberbiztonságért felelős vezetők egyre inkább ráébrednek e tevékenység fontosságára és a szakma fő célkitűzése is az, hogy az üzleti döntéshozók minél nagyobb arányban lássák: megéri költeni erre a területre.

Szeretnénk példákkal is alátámasztani az eddig leírtakat, ezért megkértünk három ügyfelünket, hogy - név nélkül - osszák meg velünk tapasztalataikat arról, milyen folyamatok követik a fentebb vázolt felismerést, míg megvalósul a kívánt szintű védelem. Tanulságos történetek következnek arról, miért vált szükségessé az adott cégeknél a biztonságfelügyeleti tevékenység kialakítása, milyen lépéseken mentek keresztül és milyen működési modellt választottak végül.

1. Motiváció: compliance

Első példánk egy kisebb pénzintézet, amely - hasonlóan piacuk többi szereplőjéhez - hosszú évek óta rendelkezett szűrésre, blokkolásra alkalmas eszközökkel. Sőt, még az események központi gyűjtését is megoldották, ami fontos tény egy mintegy 500 felhasználóval rendelkező multinacionális leányvállalatnál. Miért akartak ezek után kialakítani biztonságfelügyeleti tevékenységet és erre egy külön csapatot?

Dacára annak, hogy a szakma régóta harsogja már e tevékenység fontosságát, korábban nem foglalkoztak az események folyamatos elemzésével, csak az eszközök üzemben tartásával törődtek. Ám a társadalom érdekében a fenyegetettségek kezelésére vonatkozó szabályozás folyamatosan szigorodik, minek következtében végül elmarasztalták a céget egy audit során.

Ezt követően már az akcióterv része lett egy fejlett logelemző rendszer kialakítása, illetve a specialistákkal elvégeztetett elemzések, majd az így kapott riportok vezetői szinten történő értékelése, illetve az eredmények megőrzése.

A dicséretes végeredményhez vezető út nem volt egyszerű:

első körben megindult az elemzések készítése a jelentős, de eredetileg nem tervezett beruházásról, az integrációs feladatokról, a várható - és folyamatos - humán erőforrás költségekről. Mivel ez egy rendkívül összetett feladatsor, végül inkább külső szakértőket vontak be a levezényléséhez.

Úgy döntöttek, több szcenáriót is végiggondolnak, ezért logelemző eszközök árait és elemző munkatársak felvételének lehetőségét vizsgálták meg, majd ajánlatot kértek kiszervezett SOC szolgáltatásra. Megállapították, hogy a saját kiépítés ellen szól a legtöbb érv: először is magasabb beruházást és hosszú távon is magasabb költségeket generálna. Másodszor a kiépítés folyamata lényegesen hosszabb a saját kialakítás esetén, hiszen beszerzést kell kiírni az eszközökre, majd azokat leszállítani, telepíteni. Közben szakértőket kell keresni és alkalmazni, akik a céges alapképzésen átesve kialakítják a folyamatokat. Mindezek miatt végül a teljes kiszervezés mellett döntöttek, a rendszert és az elemzést is külső szolgáltatóként nyújtjuk számukra.

Ez a szolgáltatás a SOCWISE észlelés és válaszadás (incident detection & response), amelyet két évvel ezelőtt elindított, saját fejlett felügyeleti központunk nyújt. Ezt éppen azért hoztuk létre, mert észrevettük, hogy a nálunk rendelkezésre álló nagyon magas szintű rendszerismeret és tapasztalatok alapján kialakított módszertani tudás az, amire ügyfeleinknek leginkább szüksége van.

2. Motiváció: digitalizáció okozta kitettség

Második példánknak egy nagyobb méretű, nemzetközileg aktív termelő vállalat a főszereplője, 1000 fő feletti felhasználói létszámmal és több telephellyel, melyeken termelés is folyik.

A cég - stratégiájának részeként - részben az üzletfolytonosság, részben a hatékonyságuk növelése miatt jelentős digitalizációba kezdett több fő üzleti folyamatban. Ez kiterjedt az informatikai rendszereire, üzemeltetésére és a termelési rendszereire egyaránt. Felismerték, hogy egyre több kritikus vállalati folyamatuk vált informatika-függővé, így külön stratégiát alakítottak ki a fejlett kibervédelmi rendszerek kiépítésére és saját biztonsági elemző részleg létrehozására.

E folyamat megvalósításához - részben tanácsadóink segítségével kialakított - architektúrájuk fontos, központi elemeként egy fejlett SIEM rendszert vásároltak, amelyet implementáltunk számukra. Már a telepítés során világossá vált, hogy fontos a cégnél meglévő biztonsági elemző csapattal összedolgozni, hiszen az ő elvárásaik, kockázatértékelési- és informatikai rendszerismeretük mind szükséges ahhoz, hogy az elemző rendszert megfelelően lehessen telepíteni: elengedhetetlenek a szűrési, riasztási és incidens kezelési szabályok. Ezen felül a felkészüléshez és a majdani felügyeleti feladatokhoz megfelelő szakértőket szerettek volna alkalmazni a cégnél, de hosszú hónapok alatt sem leltek olyan jelöltet, aki minden feltételükkel együtt alkalmazható lett volna. A kialakult helyzet a folyamat megakadásával fenyegetett.

Mivel belátható időn belül nem találtak alkalmas szakértőt, s a magukkal szemben felállított biztonsági elvárások szintjét szerették volna teljesíteni, végül úgy döntöttek, legalább ideiglenesen külső szolgáltatótól veszik igénybe az elemzői képességet. A szolgáltatást így ezen ügyfelünk rendszerének felhasználásával nyújtjuk, távoli hozzáférés segítségével.

A SOCWISE szolgáltatásunk ilyen esetben arról szól, hogy a cég rendszerén észlelt biztonsági eseményeket folyamatosan nyomon követjük, értékeljük kritikusság szerint, és szabályozott rendben intézkedünk a fenyegetés elhárításának érdekében, szorosan együttműködve az ügyfél informatikai szervezetével.

3. Motiváció: célzott támadások, törvényi szabályozás

A harmadik cég egy energetikai területen működő nagyvállalat, több ezer felhasználóval, szofisztikált vállalati folyamatokkal és nagyon heterogén, sok telephelyen működő informatikai háttérrel. Jelentős ipari eszközparkkal is rendelkeznek, amelyek nagy részét - korábbi fejlesztések révén - már OT hálózaton keresztül menedzselik.

E cég tisztában volt azzal, hogy mérete és működési szektora végett egyaránt - akár célzott - támadásoknak van kitéve. Ráadásul történt több incidens is, melyek közül volt, amelyik jelentős károkat okozott. A tőzsdei jelenlét, a megfelelési szabályok és a biztonság, egyaránt a magyar törvényi szabályozás (lásd 2013. 50. törvény) hatálya alá esnek, tehát globális trendjeikkel együtt kellett fejleszteniük ezen képességeiket is.

Első körben átfogó felmérést készítettek, amelyhez külső tanácsadóként bevontak bennünket is. Kockázatelemzéssel meghatároztuk az egyes üzletfolytonossági szempontból besorolt területeket, majd az IT és OT infrastruktúra értékelését követően a NIST keretrendszere alapján megterveztük a védelmi lépcsőben elhelyezett prevenciós, detekciós és válaszadási képességet megvalósító eszközöket. A központi elem egy fejlett logelemző rendszer, amely az eseményeket, a teljes hálózati forgalmat és a kliens végpontok eseményeit is gyűjti. A rendszer telepítésén túl, tanácsadóként a szabályrendszer és a folyamatok kialakításában is részt vettünk.

A biztonságfelügyeleti rendszereket (logelemző rendszer, malware elemző képességek) megvették és maguk üzemeltetik. Bár az ő esetükben is az alkalmas szakemberek megtalálása bizonyult a legnehezebbnek, de a megfelelő jövedelem biztosítását és a magas fluktuációt is elfogadták végül, így SOC-ot hoztak létre. Az elemzők képzésébe, a folyamatok kialakításába, és a kialakult képességek tesztelésébe pedig külső szakértőket vonnak be.

Töltsd le a Virtual Cyber Security Summit egyik előadását

Még több szakmai részlet hangzott el a nemrégiben megrendezésre került Virtual Cyber Security Summit eseményünkön, ahol SOC-ot támogató legújabb megoldásokról, egyes szervezetek kihívásairól és iparági specialitásokról is szó esett.

KÉREM A VIDEÓT

Hálózati forgalmon alapuló threat hunting: így vadásszuk le a támadóinkat

Kovács Erik cikke

2020. június 10. - EURO ONE

Biztosan mindenki szeme előtt ott lebegnek a különféle “hackeres” filmek jelenetei, ahol a furfangos kiberbűnözők a képernyőn villámgyorsan tovaszaladó parancssori utasítások és IP címek előtt görnyedve igyekeznek bejutni a több ezer bites titkosítással védett kormányzati és hadászati giga rendszerekbe, hogy hozzáférjenek a világpusztító csodafegyvert működésbe hozó piros Start gombhoz a képernyő közepén. Aztán a főhős az egész folyamatot megszakítja pár villámgyors billentyű leütéssel, de előtte azért percekig nézhetjük a folyamatjelzőt és a visszaszámlálást, ami persze mindig az utolsó másodpercnél áll le.

threat-hunter.jpg

Dacára annak, hogy Hollywood általában erősen eltúlozza a kiberbiztonsággal kapcsolatos jeleneteket, azért a valóságban is akadnak izgalmak. Nem kell, hogy csodafegyverek tervrajzairól legyen szó. Elég, ha egy átlagos vállalat érzékeny adatait szerzik meg a kevésbé dörzsölt, viszont a filmes rossz fiúhoz hasonlóan pénzéhes bűnözők. Olykor egy ilyen hétköznapinak tűnő esetben is virtuális vadászat indulhat, s olykor ez is hasonlóan izgalmas tud lenni, mint a filmeken. A vállalatok számára pedig arányait tekintve lehet olyan mértékű a tét, mintha a világ összeomlását kellene megakadályozni.

Threat hunting: virtuális vadászat

Arra gondoltam, ezúttal nem merülünk el a technikai megoldások mélységes bugyraiban, inkább csak pár példán keresztül megvilágítom, miért is olyan fontos a threat hunting egy SOC és egy vállalat szempontjából. Miként segíthet az üzletmenet-folytonosság fenntartásában.

Kezdjük ott, hogy a threat hunting a SOC-ok detekciós funkcionalitását képes erősíteni, fejleszteni, elősegíteve ezzel a kockázatkezelést. Ez egyszerű ok okozati összefüggés: ahhoz, hogy biztosíthassuk az üzletmenet-folytonosságot, tisztában kell lennünk a kockázatokkal.

Ez két irányból közelíthető meg. Az egyik a detektálás, vagyis a kiberbiztonsági események észlelése, felkutatása a rendszerben. A másik a válaszadás, vagyis annak módja, ahogyan az adott eseményekre reagálunk. Ezúttal a detektálási folyamattal szeretnék foglalkozni.

Nyomozzunk megfelelő módszerrel

A biztonsági problémák detektálása történhet proaktív vagy reaktív módon. Utóbbi esetében egy már korábbról ismert fenyegetést igyekszünk megtalálni a rendszerben. Ez általában azt jelenti, hogy már ismert szignatúrák, mintázatok birtokában vizsgáljuk a rendszert, ami ugyebár nagyrészt automatizálható a SOC-on belül. Nyilván a fals pozitív riasztások esetében nem ússzuk meg a humán erőforrás bevetését ilyenkor sem, hiszen azokat ki kell elemezni és tisztázni, hogy valódi fenyegetést jelentenek-e.

Ha egy támadó kihasznál egy “zero day” sérülékenységet, amiről nem tudtunk, akkor jó esélye van, hogy észrevétlenül beköltözzön a rendszerünkbe, s ellakjon ott egy ideig hívatlan albérlőként. Mivel nem ismertük a támadási lehetőséget, így nem sikerült kivédenünk. Ráadásul amíg nem tudunk róla, a támadó kedvére ténykedhet a rendszerben.

Ilyenkor jöhet jól a proaktív technika, amely nem megelőzni próbálja a bajt, hanem - kicsit paranoiás módon - úgy veszi, hogy már megtörtént. Vagyis van egy-két kéretlen vendégünk, akiket be kell azonosítani, majd ha bebizonyosodott, hogy senki nem hívta őket és csak kárt okoznak, akkor azonnal kipaterolni. Ilyenkor jön a threat hunting, ami a nevéhez hűen tényleg a vadászatra emlékeztet: rátermett vadászként nem a csapda mellett üldögélünk és várjuk a zsákmányt, hanem felkerekedünk és elkezdjük átkutatni az odúkat, ahová bevackolhatta magát.

A kiberbiztonság nyelvére fordítva ez annyit tesz, hogy fogjuk az összes adatot, amelyeket a rendszer begyűjtött (hálózati forgalom, naplók, végpontvédelmi adatok stb.) és elkezdjük ezeket szisztematikusan átfésülni. Protokollról protokollra, forgalom irányától függően kifelé-befelé, átnézve a technikai aspektusokat, igyekszünk észrevenni az olyan anomáliákat, mint mondjuk egy furán festő domain név. Például ha feltűnik egy G00gle nevű domain, van okunk gyanakodni, hogy valaki a Google utánzásával igyekszik elrejtőzni a szemünk elől.

A másik eset, amikor feltételezünk egy konkrét támadási technikát, és annak jellemzőit kezdjük felkutatni a hálózatban. Egy webshell esetében például tudhatjuk, hogy milyen árulkodó jeleket kell keresnünk a logokban, a hálózati forgalomban, a végpontokon.

Ha nem találunk semmit, akkor sem felesleges az ilyen típusú keresés, mert menet közben seregnyi elrontott konfigurációba, rossz beállításba ütközhetünk, amelyek esetleg elkerülhették a mérnökök, rendszerépítők figyelmét, így legalább nekik tudjuk jelezni a beazonosított konfigurációs problémákat. Ez is van olyan fontos, mint a védekezés, s amúgy sem árt, ha támogatjuk egymást a cégen belül. Ezzel is erősítjük a teljes infrastruktúrát.

Maga a folyamat amúgy nem feltétlenül olyan izgalmas, mint a filmeken: az ember felállítja a kis hipotéziseit, majd ennek megfelelően elkezdi a kutatást, és menet közben minden gyanús vagy szokatlan dolgot feljegyez: IP címek, domain nevek, toolok stb. Az ilyen feljegyzésekre lehet aztán ráépíteni később a reaktív védelmi mechanizmusokat, s javítani a rendszer detekciós képességeit. Ily módon a proaktív folyamat fejlesztheti a reaktív folyamatokat is.

Kicsit olyan ez, mint a régi aranyásók módszere: merítünk a folyó egyes részein, míg végül az aranyrögök fennakadnak a rostán. Ha nem találunk semmit egy helyen, megyünk a következőre. Szisztematikusan végignézzük az egészet.

Bár egyhangúan hangzik, megvan a maga szépsége és izgalma a dolognak, még akkor is, ha az ember - szerencsére - nem akad minden nap bele valamilyen WannaCry-szerű fenyegetésbe. Nekem legutóbb egy Wordpress sérülékenységet kihasználni igyekvő támadás került a célkeresztbe. Feltűnt egy mintázat, ami gyanús volt, s egyszerűen a Google-ban sikerült rátalálnom, milyen próbálkozásról van szó, majd befoltozni a rést a pajzson. Ilyenekből jellemzően több is előfordulhat, mert sok cégnél nem igazán adnak a Wordpress és kiegészítőinek naprakészen tartására, a hibajavítások, biztonsági frissítések telepítésére.

Naplók ellenőrzése vagy folyamatos figyelés

Eszembe jut ezzel kapcsolatban még egy példa. Ha egy bank elé felszerelünk egy CCTV kamerát, amely a nap 24 órájában rögzíti az eseményeket, jó esélyünk van rá, hogy ha bankrablás történik, a felvételek visszanézésével felgöngyölíthessük az ügyet. Ez a fajta odafigyelés a kiberbiztonság területén is célravezetőbb, mintha mindig csak a log fájlokat elemeznénk utólag, hiszen azokba nem mindig kerül bele minden esemény. Van, hogy a rendszert konfigurálók kapcsolják ki bizonyos - számukra lényegtelennek tűnő - események naplózását, s van, hogy egy-egy program hiányosságai miatt nem kerülnek rögzítésre dolgok. Ha minden eseményt rögzítünk, pontos képet kapunk utólag is a kritikus történésekről.

Ha például a támadók küldenek egy adathalász levelet benne egy dokumentummal, amelyet a felhasználó gyanútlanul megnyit, s amely elindít egy szkripet, ami letölt és telepít egy malware-t, akkor egy komplett, rendszerszintű folyamaton vagyunk túl. Ha ezt teljes egészében sikerült rögzítenünk, akkor még ha - bármilyen okból - nem is sikerült megakadályoznunk a támadást, de legalább van esélyünk időben felfedezni a nyomait, és megtenni a szükséges intézkedéseket.

Szignatúra vs viselkedéselemzés

Lassan a végére érek a példabeszédnek, de azért egy valamit még érdemes tudni: a végpontvédelem esetében a hagyományos vírusirtók szignatúra és mintázat azonosítási megoldása teljesen más hatásfokkal működik, mintha viselkedés alapon monitorozzuk az esetleges kártevőket. Ezt is érdemes mérlegelni a védelem rétegeinek felépítésekor.

Összegzésül

Mindent egybevetve tehát a threat hunting egy igen értékes, hasznos folyamat, amelynek bevezetését mi minden vállalat esetében javasoljuk. Éppúgy segíthet a megelőzésben, mint a baj megtörténte utáni kármentésben. A folyamatos vadászat az ismeretlen támadások után, és az ismert mintázatok beazonosítása együtt jóval nagyobb védelmet nyújt, mintha csak az egyik eszközzel élünk a védelem kialakításakor.

Érdekel mélyebben is a téma?

 

Iratkozz fel és nézd meg Erik előadását  a Virtual Cyber Security Summiton (az előadás angol nyelven elérhető). 

 

KÉREM A FELVÉTELT

A megfelelően kialakított jogosultságkezelés előnyei

Bikki Mónika cikke

Van egy IT biztonsági terület, amely bár igazán nem tekinthető újnak, de még mindig gyerekcipőben jár a hazai cégeknél: ez a jogosultságkezelés, amelyet sajnos mostohagyerekként kezelnek, cégmérettől függetlenül. Bár akadnak olyan vállalatok, melyeknél valamiféle kötelezettségből kifolyólag - például törvényi előírások miatt - odafigyelnek erre is, egy nagy részük még mindig nem ébredt rá az IDM rendszerek használatának fontosságára. Sok helyen faék egyszerűségű megoldásokkal igyekeznek felülkerekedni ezen a kérdéskörön, s így számtalan olyan gyenge láncszem kerül a gépezetbe, amelyek később komoly - akár erkölcsi, akár anyagi - károkat okozhatnak a cégnek.

adatlopas.jpg

Rengeteg ilyen hibalehetőségre derül fény a különféle belső vizsgálatoknál, ahogy az általunk végzett auditok során is igen gyakran szisszen fel egy-egy döntéshozó, amikor szembesül vele, mennyi feleslegesen kiadott jogosultsággal van tele a rendszer. Legtöbbször már az  IDM bevezetés első fázisánál meglepetés éri a cégeket, milyen rejtett buktatóról nem volt tudomásuk.

Hazai tapasztalatok

Magyarországon vannak olyan szektorok, ahol a megfelelően kialakított jogosultságkezelés alapvető elvárás. Ilyen például a pénzügyi és banki szektor, ahol fontos az elszámoltathatóság azzal kapcsolatban, hogy egyrészt ki, mikor, kinek, milyen hozzáférési engedélyeket kért és állított be, másrészt ez milyen jóváhagyási folyamaton ment keresztül. A legnehezebb ezeket az információkat azonososítható módon együtt kezelni.

A vállalatok egy tekintélyes része persze látja, hogy jogosultság menedzsmentre szükség van. Kialakítanak ad-hoc folyamatokat, megneveznek jóváhagyókat, beállítókat. Ám amennyiben ezek a folyamatok nem automatizáltak, azzal fognak szembesülni, hogy jelentős terhet ró az IT-ra a folyamatok működtetése, a jogosultság ellenőrzésekhez riportok, kimutatások készítése. Ha SLA-t is vállaltak a folyamatokra, akkor ezek mérését is meg kell oldani. Mindez jelentős erőforrásokat von el az IT-tól, ráadásul ez tipikusan az a munka, amit a rendszergazdák rosszul viselnek. Mivel ezek a fennakadások a folyamatokat is lassítják, így az IT mellett az üzleti oldalon is elégedetlenséget szítanak.

Még mindig léteznek olyan cégek, amelyek úgy gondolják, elegendő az Active Directory-ban (röviden AD) menedzselni a felhasználókat és jogosultságaikat. Ilyenkor általában kimarad a számításból, hogy léteznek olyan alkalmazások, amelyeket nem integráltak az AD-vel, ámde használatban vannak a cégnél. Ezeknél teljesen eltérő módon kell kiosztani a jogosultságokat, így később könnyen a feledés homályába merül, kinek, mit engedélyeztek velük kapcsolatban.

Az esetek többségében képtelenség átlátni az így kiosztott hozzáféréseket, bár ez sok esetben nem okoz azonnali gondot. Idővel azonban érkezik a probléma is, ha más nem akkor, amikor egy kolléga elhagyja a céget. Egy idilli világban, mielőtt elválnak útjaik, a cégvezető és az ex-munkatárs barátságosan megöleli és jó kívánságokkal halmozza el egymást. De lássuk be, e jelenet azért viszonylag ritkán zajlik le felmondások és elbocsátások során. Ám ha egy távozó kolléga viszi magával a céges hálózatokhoz, alkalmazásokhoz, Facebook és LinkedIn fiókokhoz, honlapokhoz hozzáférést biztosító jogosultságait is, az rosszabb esetben akár anyagi vagy erkölcsi veszteséghez is vezethet, az esetleges bosszúhadjárat “sikerének” függvényében (sokszor még csak admin jogkör sem szükséges egy komolyabb károkozáshoz). Ráadásul a különféle felhő alkalmazások, közösségi oldalak, blogok  általában nincsenek összekötve az AD-val, így meglehetősen körülményes utólag összeszedni, hogy a távozó kollégának mégis mihez volt hozzáférése. Mellesleg a legkedvesebb, a cég iránt végsőkig lojális kollégával is előfordulhat, hogy ő maga is képtelen megmondani, mi mindenhez kapott már hozzáférést a cégnél az elmúlt évek alatt, pláne, ha azok egy részével csak a ”jobb ha ő is eléri” felkiáltással ruházták fel, de sosem használta. E jogosultságok - például egy banki hozzáférés - már kiosztásra kerültek, s bármikor rossz kezekbe kerülhetnek, ami visszaélésekhez vezethet.

A kilépők  megmaradó jogai mellett másik fájó pont lehet az érzékeny adatok hozzáféréseinek kezelése. Az adatvagyon egy részét kiemelten kell kezelni: itt azt is fontos látni, hogy ki az, akinek közvetlen (nem AD csoporton keresztüli) hozzáférése van vagy ki kapott hozzáférést jóváhagyás nélkül. Ezeket a kérdéseket rendkívül nehéz megválaszolni egy IDM rendszer nélkül.

De akad még példa bőven: ha egy cégnek - bármilyen okból - egy másik vállalat weboldalához van hozzáférése korlátlan ideig, az idő múlásával ez is előidézhet váratlan és kellemetlen helyzeteket. Naív dolog elvárni (bár sokan megpróbálják), hogy az adott cég küldjön időnként egy írásos összefoglalót a ráruházott elérések felülvizsgálatához. Ráadásul egy ilyen lista összeállítása és átnézése egyaránt körülményes, s legtöbbször nem is lehet kellően alapos. Emellett frissen tartani is meglehetősen zűrös egy efféle nyilvántartás-szerűséget, pláne ha e-mailben vagy papíron zajlik az egyeztetés.

Tiszta sor persze, hogy egy IDM rendszer esetében is csak az kerül rögzítésre, amit a cég a rendszerhez kapcsolt. De ilyenkor legalább online és offline is összeköthetjük a különböző rendszereket, így aztán egy esetleges kilépésnél átlátható képet kapunk az aktuális helyzetről. Egy ilyen központi nyilvántartással teljes rálátásunk van mindenre, s akár automatikusan elindíthatunk egy teljes körű jogosultság törlési folyamatot. Arról nem beszélve, hogy mennyivel kényelmesebb és gyorsabb, ha - megfelelő jogosultsággal persze - bármely illetékes azonnal lekérheti a távozó kolléga összes hozzáférésének listáját, ahelyett, hogy ezzel a kéréssel még egy operátort is feltartana… pardon, felkeresne. :)

Távmunka és irodai munka esetén egyaránt előnyös

Bár az ember elsőre azt gondolná, hogy a jogosultságkezelés csak az irodán belüli munkát érinti, a COVID-19 járvány kapcsán sokan szembesülhettek azzal, hogy bizony az otthonról végzett távmunka esetében is sok esetben hasznosnak bizonyul, ha tisztában vagyunk, kinek, mire van jogköre. A közvetlen kontaktus - illetéktelen hozzáférés egy magára hagyott gépről az irodában, vagy egy váratlan betörés során rossz kezekbe kerülő céges laptop otthon - okozta rizikót is könnyebb keretek közé szorítani, ha tudjuk, mihez kell nyúlni egy váratlan incidens esetén.

Emellett az is egyértelmű, hogy nem csak a bankszektor az, amelynél kötelező az IDM rendszerek bevezetése. Jól jöhet minden olyan cégnek, amelyek – a 2013 évi L tv.,  információbiztonsági törvény rendelkezései alapján - kritikus alkalmazásokkal dolgoznak, vagy ahol száz főnél nagyobb a létszám és több alkalmazást is használnak a szerteágazó szervezetben.

Változó rendszerbeállítási körülmények, de egyértelmű haszon

Maradt még egy lényeges kérdés: miként és mennyi idő alatt lehet bevezetni egy cégnél az IDM megoldásokat? Nos, azt kell mondjuk, hogy tapasztalataink szerint ez igen változó.

Fogódzóként leszögezhetjük, hogy minden ilyen bevezetés egy részletes felméréssel kezdődik, amikor személyesen elbeszélgetünk az ügyféllel, és átnézzük, melyek azok a fájó pontok, amelyek számára nehézséget okoznak. Ha tudjuk, milyen problémák merültek fel, már tudunk javaslatot tenni, s megtaláljuk a megfelelő megoldást.

A felmérés és a bevezetés időtartama változó. Bár nem jellemző, de előfordul, hogy akár egy-két évet is igénybe vesz, attól függően, hogy az adott szervezet mennyire érett a rendszer bevezetésére. De szerencsére a legtöbb esetben belátható időn belül sikerül kialakítani a szükséges adatstruktúrát és kiosztani az egyedi azonosítókat, amelyek alapján már a megfelelő fiókokhoz, felhasználókhoz rendelhetők a jogosultságok. Sokat gyorsíthat a folyamaton, ha eleve rendelkezésre állnak a szükséges HR adatok, alkalmazások és így rövid idő alatt auditálható a rendszer. Ha az alapokat összeraktuk, jöhet a finomhangolás, míg végül kialakul a tökéletes és átlátható jogosultságkezelő rendszer. Bár az IDM megoldások bevezetése nem egyszerű, a folyamatot megkönnyíti, hogy rengeteg sztenderd megoldásra lehet építeni. Az pedig már csak hab a tortán, hogy a biztos alapokra épített rendszer kellően testreszabható ahhoz, hogy tökéletesen idomíthassuk az ügyfél igényeihez.

Mindent egybevetve tehát megéri mind az idő, mind az anyagi ráfordítást egy IDM rendszer bevezetése, szinte bármely közepes vagy nagyobb cég esetében. Rengeteg kellemetlen helyzettől - és akár anyagi kártól - kímélhetjük meg a céget, egy ilyen megoldással.

Érdekel hogyan válhat a vállalat éretté a jogosultságkezelésre? 

VEGYEN RÉSZT WEBINÁRUNKON

Hogyan mérjük a SOC detektálási és válaszadási képességeit?

Hüvelyes Péter cikke

Ahogy az alábbi ábrán is látszik, az információbiztonságot fenyegető támadások száma meredeken emelkedik. Egy szervezet biztonságának sarokköve a támadások mihamarabbi detektálásának és azokra adott megfelelő válaszintézkedések képessége. Ezt biztosítja egy megfelelő módon működő biztonsági műveleti központ, azaz Security Operations Center (továbbiakban: SOC) kiépítése, vagy igénybevétele külső szolgáltatásként, akár hibrid modellben.

1_1.jpg

Egy SOC kialakítása mögötti legjellemzőbb motivációk a kiberbiztonsági műveletek centralizálásának igénye, a szervezet egészére való rálátás javítása, a folyamatosan növekvő kockázatok kezelésének igénye, a fenyegetettségek feltárásának javítása és a fenyegetettségeknek való kitettség csökkentése. Mindezek mellett jogszabályok és előírások is meghatározhatják a központosított kibervédelmi monitorozást és műveleteket.

Tapasztalatunk alapján ugyanakkor a fejüket biztonsági műveleti központ képességek kiépítésére adó szervezetek az esetek túlnyomó részében rendszeres visszamérés nélkül építenek SOC-ot, pedig ahhoz, hogy egy vállalat elérje céljait, tisztában kell lennie azzal, hogy hova kíván eljutni, hol áll egy adott időpontban, és ezek alapján meghatározza, hogy mik az elvégzendő feladatok.

Jelen cikk egy olyan projekt eredményének kialakításához vezető megfontolásokat, és magát a kialakítási folyamatot, eredményterméket írja le, amelynek célja volt tetszőleges szervezetnél a biztonsági műveleti központ képességeinek mérését lehetővé tevő keretrendszer létrehozása.

Egy SOC építésekor is a megszokott életciklus lépéseket kell végrehajtanunk; ezek a Plan (vagyis a cél megtervezése), az Assess (a jelenlegi állapot felmérése), a Design (a target operating model vagyis a kívánatos működés definiálása), az Implement (a terv szerinti implementálás), és a Monitor (a fentiek visszamérése).

2_1.jpg

Már a Design fázis során a TO-BE modell is meghatározza, hogy mikor és hova szeretnénk eljutni, ezért az éppen aktuális állapot visszaméréséhez szükség van érettségi szintekre az implementálás és monitorozás fázisok során.

De egyébként is, bármely képesség tekintetében elengedhetetlen az érettség mérése, mivel ennek eredménye ad visszajelzést arról, hogy

  • Mennyire jó a képesség jelenlegi állapotában;
  • Szükség van-e további fejlesztésre, hogy elérjük a kívánt állapotot;
  • Illetve hogyan módosítsuk a fejlesztési tervet, hogy elérjük céljainkat.

 

Mielőtt elkezdtünk a saját érettség felmérő keretrendszerünkön dolgozni, próbáltuk felkutatni, hogy milyen már rendelkezésre álló keretrendszert használhatnánk fel. Hamarosan be kellett látnunk, hogy bár sokféle metodológia létezik, de ezek mind a kibervédelem meghatározott részterületeire, domainjeire specializáltak (mint pl. a MITRE Att&ck keretrendszer), nincs egy átfogó megoldás.

Emellett az érettség meghatározása is változik idővel. Egész más felelt meg fejlettnek a kibervédelem terén 15, de akár csak 5 évvel ezelőtt is, mint ma. Egy olyan rendszerre van szükség, ami mindig az aktuális helyzethez, lehetőségekhez mérten értékel. Az érett SOC képesség definíciója esetünkben az incidens detekció és válasz képességet lehetővé tevő folyamatok optimalizáltságának mértékét jelenti.

A jó SOC nem csupán egy riasztásfeldolgozó műveletsor, hanem fenyegetettségekkel kapcsolatos hírszerzési (Threat Intelligence, TI) adatok felhasználója és előállítója, amely szoros kapcsolatban dolgozik az incidenskezelést ellátó csapattal (hacsak ez nem a SOC része is egyben), illetve proaktívan keresi a lehetséges fenyegetettségeket (hunting). A SOC feladata ugyanakkor elsősorban az, hogy észlelje a fenyegetéseket és választ adjon, így minimalizálja egy kiberbiztonsági incidens üzleti hatását. A mi keretrendszerünk fókusza ennek következtében a központi detektálás és reagálás képességek érettségének mérése. Ugyanezen okból hatáskörön kívül esik a biztonsági eszközök (tűzfalak, IDP-k, stb.) napi üzemeltetésének és minden egyéb a fenti kategóriákba nem tartozó tevékenységek érettségi szintjének mérése.

A mi megközelítésünk az volt, hogy egy olyan keretrendszert fejlesszünk, ami illeszkedik hagyományosan elfogadott metodológiákhoz, és aminek eredményterméke egy kézzel fogható fejlesztési terv. Ehhez a NIST Cyber Security Framework-öt (CSF) és az RSA Advanced SOC (ASOC) karakterisztikáit használtuk fel, mivel mindkettő az iparág által széles körben elfogadott. A NIST CSF funkciókra és képességekre hivatkozik, míg az ASOC kézzel fogható leszállítandókat definiál, ami ezen CSF képességeket teszi lehetővé.

 

Mindezek alapján a célunk az volt, hogy

  • Felmérjük a NIST CSF-hez rendelt képességek érettségét, a jelenlegi állapotot;
  • És az eredmények alapján definiáljuk az RSA ASOC szerinti leszállítandókat, a kívánt állapot eléréséhez szükséges lépéseket.

Az alábbi ismert érettségi szinteket határoztuk meg a keretrendszerünkben:

  • Az Initial vagyis kezdeti a legfejletlenebb, ami azt az állapotot jelöli amikor csak ad-hoc eseti folyamataink vannak, és azok kimenetele is kétséges.
  • A Managed vagyis kezelt, amikor meghatározott folyamatok léteznek, de kimenetelük erősen függ attól, hogy ki és hogyan hajtja végre.
  • A Defined azaz definiált, amikor konzisztens folyamataink vannak és azok bevált gyakorlatok szerint működnek.
  • A Measured vagyis visszamért, amikor a folyamatok és azok eredményei előre kiszámíthatóak.
  • Az Optimized pedig amikor a folyamatokat állandóan továbbfejlesztjük, így közeledünk folyamatosan az üzleti céljaink eléréséhez.

 3.png

Nézzük meg kicsit részletesebben az említett keretrendszereket!

A NIST CSF keretrendszert használtuk kiindulási alapként, mivel ez kiválóan összefoglalja a SOC működtetéséhez szükséges detect és response képességek előkövetelményeit, definiálja a kiberbiztonság eléréshez szükséges 5 alapképességet:

4.png

Az Identify (azonosítás) képesség által tudjuk beazonosítani, hogy mit kell védenünk.

A Protection (védelem) képesség meghatározza, hogyan építsük fel az architektúránkat hogy megvédjük az értékes eszközeinket.

Ezt követi a Detect (észlelés) mivel attól hogy beazonosítottuk, és védjük eszközeinket, információs vagyonunkat, még fel kell tudnunk ismerni ha valaki támadja.

A Respond (válasz) képesség biztosítja, hogy ha egy incidens bekövetkezik, tudjuk milyen választ adjunk rá.

Végül, de nem utolsó sorban, attól még, hogy jó incidens válasz képességet építettünk ki, az nem jelenti hogy mindezek ellenére a szervezet nem szenved el sérülést egy kibertámadás esetén, ezért szükségünk van a Recover (helyreállítás) tevékenységre. Ezáltal tudjuk, hogyan építsük újra a kritikus üzleti folyamatainkat.

A felmérés eredményeként előálló fejlesztési terv kialakításához az RSA Advanced SOC (vagy röviden ASOC) karakterisztikákat használtuk fel, mivel ez bevált gyakorlatokra épít és leírja a kibervédelmi incidens hatékony detektálási és válasz képességek karakterisztikáit.

Ezek a karakterisztikák lényegében azt mondják ki, hogy ha hatékony kivervédelmi képességeket akarunk megszerezni:

  • Akkor Business and Risk Aligned-nak kell lennünk, vagyis összehangoltan kell kezelni az üzleti és kockázatkezelési folyamatainkat;
  • Szükségünk van vizibilitásra, vagyis pontosan tudnunk kell hogy mely eszközöket kell védenünk;
  • Megfelelő tartalomra (pl. optimalizált, naprakész riasztási szabályokra) van szükségünk a detektálási technikák terén. A SOC lelkét adó SIEM soha nincs készen, a riasztásokat generáló szabályoknak folyamatosan követnie kell a változó támadási módszereket;
  • Elengedhetetlen a megfelelő biztonsági üzemeltetés is, vagyis a kibervédelmi központ belső folyamatai, ami biztosítja kibervédelmi incidens esetén a szükséges, kockázattal és esetleges hatásaikkal arányos válaszlépések megtételét;
  • Valamint képesnek kell lennünk előre jelezni, illetve értesülni a releváns fenyegetésekről. (Applied Intelligence & Analytics).

Az RSA ASOC logikája szerint ha a SOC működése a fenti 5 karakterisztikát kielégíti, akkor kijelenthetjük, hogy egy hatékonyan működő biztonsági műveleti központtal rendelkezünk.

Az általunk elvégzett felmérések során a NIST CSF "Detect" és "Respond" funkciók alkategóriáit 1-az-1-es megfeleltetéssel hozzárendeljük az RSA Advanced SOC domainjeihez, mivel az RSA ASOC kézzel fogható leszállítandókat definiál, amik segítenek megvalósítani a NIST CSF funkciókat és képességeket. A felmérési fázisban egy részletes és célzott kérdőívvel végigvesszük az összes NIST CSF alkategóriát, ellenőrizzük hogy az adott szervezetnél milyen érettségi szinten áll.

5.png

Annak érdekében, hogy megbízható eredményeket kapjunk, minden alkategóriához -egy ésszerű számossági határon belül maradva- több kérdést rendeltünk. A kérdőív részben minden CSF alkategóriába belekérdezünk.

A NIST CSF alkategóriái és az RSA ASOC domainjei közti kapcsolat teszi lehetővé az eredmények érettségi radaron /pókháló diagramon/ való megjelenítését, és a fejlesztési ajánlások fejlesztendő területekhez rendelését.

A végeredményeket szemléltető érettségi radarok előállnak a CSF alkategóriák szintjén, és az 1-az-1-es mapping következtében a pókháló diagramok azonnal legenerálódnak az ASOC domainekre is. Az eredmények könnyen értelmezhetően vizualizálják, hogy mely területek fejlesztésére kell fókuszálni.
vcs.JPG

A keretrendszer gyakorlati megvalósítása az RSA Archer Suite-ban történt. A megoldással nyomon követhető, hogyan változik az érettség idővel, és ezáltal hogy a kitűzött mérföldköveket hogyan érjük el.

A kérdéseket és a rájuk adott válaszokat a rendszer lementi, valamint a megfelelő dokumentáltság biztosítása érdekében szükség esetén evidenciákat is fel lehet csatolni, így egy audit során is hasznos eszköz. Fontos megjegyezni, hogy a felmérés során semmilyen bizalmas információt (például eszközlistát) nem kérünk el ügyfeleinktől.

8.jpgA megoldás a kitöltést követően előállít egy vezetői összefoglalót az érettségi szintek és pontozás magyarázatával, valamint a nem megfelelő válaszoknál automatikusan finding-okat (megállapításokat) is generál.


Összefoglalva, egy olyan keretrendszert akartunk megalkotni, ami lehetővé teszi a SOC detektálási és válaszadási képességének mérését. A felmérés során előáll egy megvalósítható fejlesztési terv, ami kiemeli ha valamilyen képességünk hiányzik. Ez a felmérés ráadásul tetszőlegesen megismételhető, az érettségi szintek változásai nyomon követhetőek, ezáltal lehetőség nyílik az aktuális- és kívánt állapot közti hiányosságok kezelésére, működésünk optimalizálására. 

A felmérésünk és az abból létrehozott riport kiértékelése bár nem oldja meg egy csapásra a SOC minden problémáját, de az eredmények alapján mélyebbre le lehet fúrni, ezáltal jó kiindulási alapot nyújt egy hatékony SOC kialakításához, valamint az igények szerint a felmérés tetszőlegesen tovább fejleszhető.

Érdekel a többi előadás, ami a Virtual Cyber Security Summiton elhangzott? Regisztrálj és elküldjük.

X(DR)-akták, avagy generációváltás a végpontvédelemben

Krékity Gusztáv cikke

Mi sem támasztja alá jobban, milyen fontos a megfelelő végpontvédelem kialakítása, mint hogy folyamatosan érkeznek az újabb technológiák és javaslatok e területen. Tavaly például a Palo Alto Networks alapítója Nir Zuk szorgalmazta a biztonsági piac radikális átalakítását, s ezzel egy teljesen új végpontvédelmi kategória kialakítását.

Tovább

Védelem a végeken, avagy a céges biztonság kialakítása a felhasználói oldalon

Krékity Gusztáv cikke

2020. április 08. - EURO ONE

Eddigi bejegyzéseinkben sorra vettük, mire van szükség ahhoz, hogy biztonságosan megvalósíthassuk a távoli hozzáférést. Most elérkeztünk arra a pontra, amikor tüzetesebben megvizsgálhatjuk, miként oldható meg, hogy az otthonról dolgozó munkatársak irányából is a lehető leghatékonyabb védelmet építsük ki. A felhasználói oldal bebiztosítása ugyanis létfontosságú, hogy megvédjük a szenzitív adatokat mind az otthon használt számítógépeken, mind a céges hálózatban, amelyhez a felhasználó csatlakozik. Ha például van VPN kapcsolat és tűzfal, az elegendő a teljes körű biztonsághoz?

Tovább

A biztonságos home office alapjai

Krékity Gusztáv és Bikki Mónika cikke

2020. március 23. - EURO ONE

A koronavírus helyzet miatt egyre többen térnek át home office munkarendre. Legyen szó nagyvállalatokról vagy kkv-król, mindkét esetben fontos a munkatársak és az ügyfelek egészsége, s jelen pillanatban - ahol az adott munkakörnél megoldható - az otthonról végzett munka tűnik a legjobb megoldásnak ennek elősegítéséhez. Mindez rendjén is van, azonban az elmúlt egy-két hétben meglehetősen vegyes kép alakult ki nálunk is a cégek felkészültségét illetően. A home office ugyanis nem csak az általános hardveres és szoftveres háttér megteremtése végett adja fel a leckét az IT vezetésnek, hanem biztonsági szempontból is. Éppen ezért arra gondoltunk, röviden összefoglaljuk, milyen lehetőségek vannak arra, hogy az otthonról dolgozó munkatársak ne veszélyeztessék a céges adatbiztonságot

Vegyes felkészültségi szintek

Mielőtt belevágnánk, adunk némi helyzetképet. Akadnak például enterprise szinten lévő cégek, melyeknél eleve megvolt a szükséges hardverpark, így ők megúszhatták emergency licencek vásárlásával, amelyek installálásával viszonylag zökkenőmentesen a megnövekedett igényekhez igazíthatták IT struktúrájukat. Ha a rendszerben eleve volt tartalék, akkor a skálázhatóság kihasználásával ezek a cégek rugalmasan tudtak idomulni a koronavírus okozta hirtelen változásokhoz is. Az előző cikkünket a távmunkáról itt olvashatod el.

De sajnos azt kell mondjuk, a cégek jó része - s ezek között kisebb és nagyobb méretűek egyaránt akadnak - abszolút nem volt felkészülve arra, hogy nagyobb mértékben álljanak át otthoni munkavégzésre. Rosszabb esetben ezeknél a vállalatoknál most megy a kapkodás. Jobb esetben szakértői segítséget kérnek, hogy megtalálják a lehető leggyorsabban bevezethető, megbízható megoldást. Csak érdekesség képpen jegyezzük meg, hogy van olyan ügyfelünk, aki még az önként vállalt megelőző karanténból is képes kimozdulni, hogy minél gyorsabban tető alá hozzunk egy ellenőrzési, átállási tervet a távoli munkavégzésre. Ha egy cég szenzitív adatokkal dolgozik, ott nincs idő halogatásra.

Az adatok biztonsága létfontosságú, ennek ellenére sok cégnél most derül ki, hogy eddig erre vajmi kevés figyelmet fordítottak. Igaz, sokuknál ez kényszerhelyzet is, hiszen korábban egyáltalán nem volt náluk példa az otthoni távmunkára. Mindenesetre az biztos, hogy jelenleg még sokan csak az előkészítésnél tartanak. Az elkövetkező hetek számukra a felkészülésről, átállásról szólnak majd.

Home office a saját számítógépről?

Döbbenetes, de sokszor tapasztaljuk, hogy a home office a cégek egy részének azt jelenti: az otthonról dolgozó kollégák a saját otthoni gépükről, ne adj’ isten a gyerek notebookjáról érik el a céges munkaállomást, szervert. Ez azonban nem különösebben jó gyakorlat, hiszen ezeken a gépeken általában még megfelelő szintű vírusvédelem sincs. Az otthoni vírusvédelmi szoftverek és tűzfalak nem igazán alkalmasak vállalati szintű veszélyek kivédésére.

Egy jól átgondolt home office esetében tehát a cég adja a gépeket is a munkatársaknak, amelyekre előre telepítik a megfelelő színvonalú vírusvédelmi, tűzfal és további védelmi megoldásokat, melyek gondoskodnak a távoli kapcsolat biztonságossá tételéről. Ezek telepítése ráadásul megoldható group policy alapján, így minden szükséges szoftver a számítógépre kerülhet, pár lépésben.

Ha ezt nem lépjük meg, a felhasználók saját, otthoni számítógépeiről pillanatok alatt kerülhetnek kártékony kódok a céges rendszerbe, nem beszélve arról, hogy már az elmúlt hetekben is megnövekedett a távmunkát bevezető cégek elleni támadások száma, amelyek könnyebben találnak utat egy szimpla otthoni gépen keresztül a céges infrastruktúra felé, mintha jól védett klienseket használnának a munkatársak, s azokkal megfelelően felvértezett céges rendszerhez kapcsolódnának.

A megfelelő tűzfal kiválasztása

Rengeteg tűzfal megoldás létezik, de a megfelelő kiválasztását segítheti, ha tisztában vagyunk pár fontos kritériummal, amelyeknek egy hatékony tűzfalnak meg kell felelnie.

Egy jó minőségű tűzfal például több szinten is képes ellenőrizni a kliens megbízhatóságát. Például csak akkor enged be a céges VPN-re, ha - a cég irányelveit követve - mondjuk Microsoftos környezet van rajta (például Windows 10), abból is a legutóbbi frissítésekkel ellátott példány.

Emellett legyen telepítve egy fejlett végpont védelmi megoldás a kliensen, természetesen a legfrissebb szoftver verzióval, adatbázissal, s az elmúlt 24 órában legalább egyszer történt teljes kliensoldali rendszerellenőrzés is. Ha mindezen szempontok teljesülnek, a kliens beléphet a központi rendszerbe.

Azonban még ezeken felül is érdemes további megfelelőségi kapukat felállítani. Ilyen lehet például az RSA SecurID, amely a felhasználónév és jelszó pároshoz ad egy extra védelmi szintet. A belépéshez rendelkeznie kell a felhasználónak a megfelelő tokennel, s csak az erről leolvasható, 60 másodpercenként megújuló kód beírása után tud egyáltalán belépni, hiába ismeri a név+jelszó kombót.

Végül harmadik faktorként használhatnak valamilyen certificate megoldást is, amelynek meglétét szintén képes ellenőrizni a tűzfal, s csak ennek birtokában engedi belépni a felhasználót. Ezzel viszonylag egyszerűen lehet garantálni, hogy nem a saját, otthoni gépéről igyekszik bejutni, kockáztatva ezzel egy adatbiztonsági incidenst.

Sajnos nem az a jellemző, hogy mindenki e három faktor biztosításával kezdene neki a távmunkának, de már most is akadnak olyan cégek, amelyek ezeket kérik tőlünk. Számukra fontos, hogy a bizalmas adatok ne kerüljenek illetéktelen kezekben a kialakult kényszerhelyzetben sem. Ráadásul ezzel hosszú távon is biztosítható a távmunka, s később sem kell kapkodni, ha újabb hasonló helyzet áll elő, vagy esetleg időközben ráéreznek a cégnél a home office ízére.

Promóciók a gyors kiépítéshez

A fenti megoldások kiépítése persze időbe telik és pénzbe kerül, így a megfelelő megoldás keresése, a finanszírozás átgondolása túlságosan elhúzhatja a döntéshozói folyamatokat. Szerencsére akadnak nagyszerű promóciók is, amelyek közül mi is ajánlunk néhányat ügyfeleinknek, hiszen ezekkel gyorsan és költséghatékonyan lehet kiépíteni a megfelelő biztonsági infrastruktúrát.

A Palo Alto az aktuális promóciójával speciálisan a kialakult helyzetben igyekszik támogatni az új és a már meglévő ügyfeleit egyaránt. Ennek keretein belül limitált számú fizikai tűzfal áll rendelkezésre NFR (Not for resale) változatban. Ezek nem értékesíthetők a piacon, vagyis ha egy ügyfél megkapja, s később esetleg a megvásárlása mellett dönt, nem az adott NFR példányt hagyják ott nála, hanem egy teljesen újat adnak. Ezeken az eszközökön van egy 30 vagy 60 napos (igénytől függ) eval licence, így ezen időszak alatt képes frissíteni a támadási content adatbázist. Ezen felül a GlobalProtect szolgáltatást is 90 napig ingyenes biztosítja a gyártó..

Emellett elérhető a Palo Alto virtual appliance megoldás, melynek lényege a virtualitás, hiszen így nem kell logisztikailag is megoldani az eszközök szállítását, ami gyorsabb beüzemelést jelent. Az ügyfél részéről egy virtuális környezet szükséges hozzá. Ehhez is van 30 vagy 60 napos eval licenc, illetve a GlobalProtect ebben az esetben is 90 napig jár.

Ezekkel a megoldásokkal akár azok a cégek is élhetnek (gyakorlatilag mérettől függetlenül), amelyeknél nem igazán skálázható az IT rendszer. Segítségükkel ők is több hónapra beüzemelhetik a biztonságos VPN hozzáférést és a támadások megakadályozásához szükséges tűzfalat.

RSA SecureID megoldások díjmentesen

Ha már szóba került korábban, fontos kiemelnünk, hogy az RSA hat hónapig ingyen adja a kétfaktoros autentikáció bizonyos alap szolgáltatásait azoknak az új, potenciális ügyfeleknek, akik még nem rendelkeznek hasonló szolgáltatással.

Ebben az esetben is szükség van ügyfél oldalról egy virtuális gépre. Lényegében ezen keresztül, illetve a munkavállalók telefonján lévő kliens alkalmazásokkal valósul meg a multifaktoros autentikáció (MFA).

Mivel a pusztán felhasználónévre és jelszóra építő beléptetések egyre nagyobb mértékben vannak kitéve támadásoknak (a támadások közel 80%-a erre irányul), ráadásul nagy az esély, hogy a belépéshez szükséges két adat illetéktelen kezekbe kerüljön, így az RSA MFA bevezetése szinte mindenkinek ajánlott, nem csak azoknak, akik érzékeny, bizalmas adatokkal dolgoznak. Egy ilyen rendszer kiépítése egyébként meglepően gyorsan megvalósulhat.

Az RSA e terület nagy öregje, gyakorlatilag a token alapú megoldások legjelentősebb gyártója. Ha a multifaktoros autentikáció szóba kerül, az RSA szinte biztos, hogy ott van a figyelemre méltó ajánlatok között.

Összegzésül

Mindent egybevetve a fenti megoldások ma már kihagyhatatlanok, ha a távoli munkavégzés kiépítése a célunk. A jelenlegi, COVID-19 koronavírus okozta helyzetben egyre több munkavállalónak kell majd otthonról dolgoznia. Ezekhez a körülményekhez pedig - sajnos - még a cégeknél is gyorsabban alkalmazkodtak a kiberbűnözők, akik komolyan ráálltak a home office rendszerek sebezhetőségeit kihasználó támadásokra. Emellett egyre nagyobb veszélyt jelentenek a ransomware támadások és az adathalász próbálkozások, melyek száma az elmúlt hetekben megnőtt.

Nem csak a bizalmas, szenzitív adatokkal dolgozó vállalatok, hanem minden, az otthoni munkavégzést támogatni kívánó cég esetén kiemelt fontosságú tehát a megfelelő biztonsági megoldások használata. Elég kihívást jelent egészség és gazdaság szempontjából a való világ vírustámadása, nem érdemes ezt tovább tetézni virtuális kártevőkkel, adatbiztonsági incidensekkel.

Érdekel a téma? Kövesd a LinkedIn oldalunkat.

Folytatjuk, kövesd a blogot, vagy iratkozz fel, hogy értesítsünk a következő cikkről. ITT

A hatékony távmunka eszközei, járvány és karantén idején

2020. március 17. - EURO ONE

Immár Magyarországot is elérte a kínai Vuhan városából kiindult koronavírus (COVID-19), a kormány pedig, a kialakult hazai és nemzetközi helyzetre reagálva, az elmúlt napokban rendkívüli jogrendet hirdetett. S bár azt - e bejegyzés készültekor még - a vállalatokra bízta, hogy a koronavírus kapcsán miként járulnak hozzá az egészségügyi helyzethez, úgy tűnik, hogy a hazai cégek között is egyre többen hirdetik meg a rendkívüli munkarendet. Ennek kialakítása során saját hatáskörben rendelkeznek arról, hogy a dolgozóik otthonról végezzék-e a munkát, vagy bejárjanak az irodába, az adott munkakörök elvárásaihoz is igazodva. A cél, hogy a járvány további terjedését lassítsák a megfelelő munkarend kidolgozásával. Erre pedig a legjobb megoldás értelemszerűen a távmunka vagyis home office, amikor a munkavállaló az otthona elhagyása nélkül végezheti el céges feladatait.

De mire van szüksége egy vállalatnak, hogy azonnal léphessen? Milyen IT feltételek szükségesek ahhoz, hogy a távmunka ne csak egészségügyi szempontból, hanem a céges adatvédelem tekintetéből is biztonságos legyen? Hogyan oldhatjuk meg a hatékony home office bevezetését? Ezekre a kérdésekre adunk választ ebben a bejegyzésben.

Mire van szükség a hatékony távmunkához?

Míg a családon, rokonságon belüli kapcsolattartáshoz ilyenkor is elegendő lehet a megszokott, szinte minden platformon elérhető Facebook Messenger és Gmail páros, addig ezek az eszközök egy cég esetében túl sok biztonsági problémát vetnek fel. Jól meg kell hát választanunk a biztonságos kapcsolattartáshoz, táveléréshez, fájlcseréhez használt szoftvereket. De ugyanígy az sem mindegy, milyen minőségű internetkapcsolaton keresztül érik el a dolgozók a cég belső hálózatát, annak védeleméről nem is beszélve. A legfontosabbak tehát:

1.           Sávszélesség, amely képes kiszolgálni az adott cég méretét távmunka esetén.

2.           Alap technikai feltételek: notebook, mobiltelefon és internet elérés.

3.           Olyan skálázható IT infrastruktúra, amely tartalmazza az otthoni felhasználók kapcsolódását biztosító eszközt, szaknyelven VPN koncentrátort vagy VPN koncentrátorként is használható tűzfalat.

4.           Biztonságos kapcsolat.

5.           Megfelelő szoftverek, például Webex, Microsoft Teams stb.

Terjedelmi okokból nem tudunk minden pontot kifejteni, így most csak a harmadik és negyedik pontokban felvetett hozzávalókkal kapcsolatban osztunk meg néhány gondolatot.

Skálázható IT infrastruktúra

Jelen pillanatban azok a vállalatok képesek biztosítani az azonnali távoli munkavégzést, akiknek már adottak a harmadik pontban leírt IT feltételek, s ezekhez megfelelő licencekkel is rendelkeznek. Az elmúlt években napi szinten volt szó a skálázható informatikai rendszerekről, és arról, milyen előnyei vannak. Ezt most a gyakorlatban is megtapasztalhatjuk.

Szinte biztosan kiderül majd minden érintett cég számára, miért is olyan fontos a jelenlegi IT rendszer skálázhatósága. Az ok egyszerű: a hirtelen megnövekvő igénybevételt is ki kell tudja szolgálni. Ilyen igény például amikor minden munkatárs távolról, egyszerre igyekszik elérni a céges környezetet.

Gyorsan tudnak a jelenlegi helyzetben reagálni azok a vállalatok is, akik rendelkeznek ugyan megfelelő eszközökkel, viszont nem rendelkeznek a szükséges szolgáltatás vagy kapcsolódás használhatóságáról gondoskodó licencekkel. Ők licenc bővítéssel - s ha szükséges a VPN kliensnek a távolról csatlakozó kollégák eszközeire való feltelepítésével - gyorsan működőképessé tehetik a rendszert.

Hasonló esetekre léteznek úgynevezett vészhelyzeti licencek (Emergency Licenses) is, amelyek csupán néhány hétig érvényesek, majd az adott időszak végén lejárnak. Amennyiben átmeneti állapotról van szó, érdemes ezt a lehetőséget is megfontolni.

Mit tehet, aki nincs felkészülve a home office-ra?

Ha a rendszer a megnövekedett felhasználói igényeket nem képes kiszolgálni, vagy nem rendelkezik VPN koncentrátorral, esetleg elavult és régi a tűzfal, akkor az infrastruktúrát mindenképpen fejleszteni kell.

Egy olyan fizikai rendszert, amelyben egyáltalán nincs VPN koncentrátor, az idő rövidsége, a gyártási folyamatok és a logisztika lassulása miatt hosszú idő lenne felkészíteni. Jelenleg a koronavírus első és második hulláma zajlik a világban. S bár a COVID-19 még a virológus szakemberek számára is sok kérdőjeles tulajdonsággal rendelkezik, azt semmiképpen sem javasoljuk, hogy bárki félvállról vegye. A spanyolnátha például anno három hullámban jelentkezett egy éven belül, és a második hullám jóval nagyobb volt az elsőnél. Fontos tehát mielőbb meghozni a szükséges fejlesztési döntéseket.

Mi történik például abban az esetben, ha a jelenlegi IT infrastruktúra jól működik az adott kapacitással, de a megnövekedett igényeket már nem tudja kiszolgálni? Nézzünk egy példát!

Vegyünk egy 100 felhasználós céget, amelyiknél a jelenlegi rendszer kapacitása 20 felhasználót képes kiszolgálni távolról. A hálózatuk már így is maximálisan kihasznált, aminek következtében a nagyobb terhelést - hiába is vásárolják meg a szükséges licenceket - képtelen kiszolgálni. Ez a rendszer túlterheléséhez vezet. Ebben a helyzetben megoldást biztosíthat a virtuális eszközök integrációja is. Ez azt jelenti, hogy virtuális tűzfalat integrálunk a meglévő rendszerhez, amellyel akár 5 nap alatt megvalósítható minden felhasználó számára a biztonságos, távoli munkavégzés lehetősége.

Az érzékeny adatokkal dolgozó cégek számára megfontolandó egy multifaktoros hitelesítő rendszer bevezetése is a távoli kapcsolatok biztonságosabbá tételéhez, akár a meglévő rendszerek kiegészítéseként is. Érdemes szem előtt tartani azt is, hogy bár vészhelyzetben az alapbeállítások pár nap alatt elvégezhetők, azért a bevezetés ideje nagyban függ a cég méretétől és igényeitől.

Ne legyenek kétségeink: az következő hetek meghatározzák a jövőt. A változás mindenki számára elkezdődött. A digitális transzformáció évek óta zajlik, most azok tudnak rugalmasabban reagálni, akik már részesei az átalakulásnak, és rendelkeznek üzletmenet folytonossági tervvel is. 

3 alapvető kérdés a jogosultságkezelésedről

Bikki Mónika cikke

2020. február 27. - EURO ONE

3 alapvető kérdés a jogosultságkezelésedről

Noha sokan továbbra is azt hiszik, hogy minden jól elszeparált és védett, a szembeszökő valóság az, hogy egy folyamatosan fejlődő korlátok nélküli világban élünk, ahol bárki, bárhonnan, bármit elérhet. Vállalati infrastruktúránk is határok nélküli, kritikus adataink felhőalapúak és felhasználóink a világ bármely pontjáról dolgozhatnak.

Az első, és valószínűleg egyetlen védelmi vonalunk a dolgozó: olyan megbízható személy, aki rendelkezik jogosultságokkal, és feltételezzük megbízhatóan dönt és figyelembe veszi a kockázatokat. Sajnos a legtöbb szervezet soha nem nézi át munkatársai felhasználói fiókjait, illetve azok jogosultságait, továbbá kihagyja a lehetőséget egy olyan jogosultságkezelési programnak, amire támaszkodhatna a jövőben.

Az évek során megállapítottuk, hogy néhány kérdésen keresztül rávilágíthatunk a jogosultságkezelési stratégiára, hogy ügyfeleink átgondolják mennyire érett szervezetük jogosultságkezelése. Ezek a kérdések azért nem terjednek ki mindenre, de segítenek megérteni azokat a pontokat, amelyek bármilyen típusú jogosultságkezelési stratégiának az alapját képezik.

1. Hol vannak a jogosultságaid? Először azt érdemes megvizsgálni, hogy rendelkezünk-e megbízható jogosultsági nyilvántartással, vagy sem. A jogosultsági nyilvántartás a felhasználói fiókok, szerepkörök és hozzáférési jogok gyűjteménye, a teljes vállalati környezetre nézve.

A jogosultsági nyilvántartás sok felhasználói fiókot tartalmaz, de felhasználónként csak egy, egyedi azonosító van, amely a dolgozóhoz tartozik. Egy vállalat tipikusan az Active Directory-t (AD) tekinti a jogosultsági nyilvántartásának, hisz az AD felhasználói fiókokokat használják a hozzáférések kezelésére. Ugyanakkor érdemes meggyőződni arról is, hogy ezek kiterjednek-e azokra az infrastruktúra-elemekre is, amelyek nem használnak AD-t a hitelesítéshez. Fontolóra kell venni az összes alkalmazás, hálózati eszköz és a Linux szerver hitelesítési- és jogosultságkezelési folyamatát, valamint azt, hogy létezik-e olyan központi rendszer, amely tartalmazza ezen elemek felhasználói és jogosultsági adatait is.

2. Hogyan működik a hitelesítés? Másodszor, fontos a vállalkozáson belüli összes hitelesítési folyamatot felülvizsgálni. Általánosságban elmondhatjuk, hogy régi infrastruktúrákkal találkozunk a munkánk során, melyek évtizedek óta felügyelet nélkül működnek, ezáltal a technikai felhasználói fiókok felelősei teljesen nyomon követhetetlenné váltak az évek során. Míg a szervezetek túlnyomó többsége az Active Directory-ba központosította Windows-környezetét, jóval kevesebben integrálták hálózati eszközeiket, alkalmazásaikat vagy azok Linux szervereit is AD-hoz. A legtöbb esetben az ilyen típusú rendszerek helyi azonosítókat használnak a hitelesítéshez, ugyanakkor ezeket semmilyen központi nyilvántartási rendszerben nem kezelik vagy rendelik felelősökhöz.

A hitelesítési folyamatok felmérése nehézkes lehet, különösen az évtizedek óta működő alkalmazások esetében. Kihívást jelentenek az alkalmazások adatbázisában vagy a fájlokban eltemetett technikai fiókok, a több éves (vagy évtizedes) régi SSH kulcsok és megbízhatatlan „megosztott” fiókok. Nem kétséges, hogy a rendszerek átvizsgálására fordított idő hosszútávú befektetést jelent a vállalat számára.

3. Hogyan támogatja a vállalatot a jogosultságkezelési stratégiád? Végül fontos, hogy teljesen átlássuk a jogosultságkezelési folyamatok működését vállalatunknál. Noha a manuális folyamat megfelelő szigor mellett sikeres lehet, mégis automatizálás szükséges ahhoz, hogy minimalizáljuk az emberi hibákat, amelyek eredendően előfordulnak a manuális folyamatok során.

Az auditálhatóság is kulcsfontosságú kérdés. Véletlenszerűen kiválasztva a felhasználói fiókok 20% -át, egyértelműen kijelenthető-e, hogy mindegyik követi a fiókok létrehozásának dokumentált folyamatát? Új belépő dolgozók esetén a HR-től indul a beléptetési folyamat? A közvetlen felettes kezdeményezi a jogosultsági igényléseket? A munkatársuk maguknak igénylik a hozzáféréseket? Mi a helyzet az áthelyezésekkel vagy promóciókkal?

Minden jogosultságkezelési stratégia valódi célja a felhasználói fiókok létrehozásának, karbantartásának és végleges törlésének, jóváhagyási folyamatainak megértése. Mindezek mellett biztosítani kell a historikus adatok ellenőrizhetőségét auditok esetén, melyek során mindenképpen kiderül mennyire fontos a megfelelő jogosultságkezelési program.

Három alapvető szempont mindenki számára, aki gondolkozik  minimális jogosultságkezelési stratégia készítésén. Ha előzetesen figyelembe veszed ezt a három szempontot, garantálható, hogy hosszútávon sikeresebb lesz.

Érdekel a téma? Kövess minket a LinkedIn-en is!

Vegyél részt az éves Cyber Security Summit-on! Kattints ide

A MITRE ATT&CK filozófiája

2020. február 25. - EURO ONE

Mintegy 5 évvel ezelőtt kezdte el kategorizálni a MITRE az ismert támadási módszereket annak érdekében, hogy szimulálják a támadók viselkedését és javítsák a behatolásdetekciós képességet.  Azóta jelentősen megnőtt a MITRE ATT&CK mind a tartalmát, mind a tartalom fenntartásának a folyamatát tekintve.

A MITRE nagyon fontosnak tartja, hogy hasznos maradjon a közösség számára. Kiadtak egy a filozófiáról szóló whitepapert, amely hiteles forrása az ATT&CK módszertan mögött álló tervezési, illetve filozófiai gondolatoknak. Úgy gondolják, a módszertan fontossága jobban fenntartható, ha átláthatóak a mögötte lévő döntések. A kezdetek óta még nyitottabbá vált a modell, és a nyitottság továbbra is alapvető elem.

Nem minden potenciális fenyegetés egyforma

Az ATT&CK módszertanát úgy fejlesztették ki, hogy utólagosan minél jobban észleljék a kiberbűnözők támadás alatti viselkedését. A fejlesztési munka célja, hogy aki az ATT&CK módszertant használja, képes legyen a dokumentált támadási viselkedésre összpontosítva rangsorolni a védekezés módját. A folyamatos fenyegetések – ezt gyakran ATP-nek nevezik – onnan kapták a nevüket, hogy a támadók a céljaik elérése érdekében, a célt azt különböző időben elnyújtva, többször, sokféleképpen, működésüket megszakítva végzik. A tartós fenyegetéseknek számos formája lehet, mint például az államok által szponzorált ATP-k, a kémkedés, a pénzügyileg motivált bűnözők, illetve a szellemi tulajdont fenyegetők. Mindegy milyen egyéni motivációval érkeznek a támadók, azok a technikák, amiket használnak, nagyon hasonlítanak egymáshoz. A támadók által alkalmazott technikák tárháza hatalmas. Elég, ha csak megnézzük, mi történt az előző években, vagy mi történik most, vagy mivel foglalkoznak a kutatások, illetve hogyan néznek ki ma a sérülékenységi adatbázisok, ha éppen valaki új ötlettel állt elő.

Megdöbbentő, hogy a vállalatoknak mennyi minden ad okot az aggodalomra, egyre nehezebb a technológia területén is boldogulni, miközben egyensúlyoznak a biztonsági események hatékonysága és a döntéseket alátámasztó kritikusság között. Nagyon praktikus, ha valaki képes ezeket részeire bontani, az empirikusan dokumentált fenyegetési aktivitásokra fókuszálni, hogy priorizáljon és azokkal foglalkozzon először, amelyek alapvetően befolyásolják a biztonsági szintjüket.

 

Milyen információforrásokat használ az ATT&CK?

 

Számos különböző információforrás van:

·       Threat intelligence jelentések

·       Konferencia-előadások

·       Webináriumok

·       Közösségi média

·       Blogok

·       Nyílt forráskód-tárházak

·       Malware-minták

 

Minden hasonló technikára, fenyegetettségi információra nyitott a MITRE egészen addig, amíg az megbízható forrásból származik és növeli a közösség kollektív technikai megértését. Az ATT&CK csapatnak számos munkatársa van, akiknek többéves közösségi tapasztalata van threat intel védelemben és szimulációs gyakorlatokban.

Mi a helyzet a red teaminggel és az új technikák kutatásával?

Sajnos a nyilvánosan elérhető információk nem elégségesek, hogy megértse a MITRE mit csinálnak a szemben lévő támadók.  Ami látható, illetve riportálható, azokon az adatokon alapul, amit valaki éppen abban a pillanatban látott, de az igazán érzékeny része az információnak – hogy mi is vezetett az aktuális esethez, mit is csináltak a támadók – legtöbbször publikusan nem elérhető.

Ez igazán komoly kihívás az ATT&CK számára, mivel folyamatosan frissen akarják tartani a keretrendszert. A legutóbbi taktikákat, technikákat, folyamatokat az úgynevezett TTP-t szeretnék feldolgozni, amit minden egyes védelemben dolgozó szakembernek tudnia kellene. Mindezt figyelembe véve többféle módszertant használnak arra, hogy megközelítőleg meg tudják mondani a támadók módszereit a való életben.

Léteznek nem túl gyakran dokumentált események, mert nem születnek róluk leírások. Az információmegosztási kontrollok és az adatok érzékenysége limitálja ezt, ezért, ha egy megbízható információforrás azt mondja, hogy felbukkant egy technika az életben és elég információ van róla, hogy elmondják hogyan történt, a legtöbb esetben bizonyítottnak tekintik, még akkor is, ha nincs róla riport.

 

Red teaming

Ugyanazzal a céllal történik általában, ahogyan a fenyegetéseket próbálják szimulálni.  A támadóoldali technika nagyon sokszor hasonlít a valós élethez, de néhány esetben teljesen különbözik. Ha azt tapasztalják, hogy ezek a red teamek sikeresen használnak bizonyos technikákat és elég sok ügyfél sérülékeny ezekre a módszertanokra, valószínűsíthető, hogy egy a való életben is előforduló módszertanról van szó.

Az új technikákról rengeteg kutatás készül, sok jó publikálás születik az új módszertanokról és a biztonsági problémákról. Időnként ezek a technikák a való életből származnak, de vannak teljesen újak is, amit most fedeztek fel. Ilyenkor a régi adatokat vizsgálják, de új szemszögből. Ebben az esetben nagyon fontos, hogy az újonnan megjelent technikákat valamilyen szinten a múlttal is összevessék és így vizsgálják a megtörténésük valószínűsíthetőségét.

 

Technikákat befolyásoló döntési faktorok

Akkor kell új technikát létrehozni, amikor új előfordulást vagy új leíró riportot találnak. Bizonyos esetekben azonban csak kicsit átalakítják vagy kiegészítik azt egy meglévő részleteivel, vagy az észlelthez hasonló technikával, vagy csak új infót helyeznek el benne. Amikor egy-egy ilyen technikába új információt tesznek, akkor sok tényezőt gondolnak át, hogy megértsék a modellben, tudásbázisban hogyan és hova illeszthető be.

 

Számos szempont alapján mérlegelnek 

Mit is valósít meg ez a technika? Hasonló technikák már előfordulhatnak úgy is, hogy különböző taktikai lépéseket valósítanak meg, vagy az is meglehet, hogy különböző technikák valósítanak meg hasonló taktikai lépéseket kicsit másképpen.

Akciók. Hogyan is hajtották végre ezt a támadási taktikát? A taktikát jelző trigger esemény különbözik még akkor is, ha a végeredmény ugyanaz vagy hasonló.

Megnézik, ki használja. Ha több csoport használja, ők hogyan használják? Ugyanúgy vagy különböző módon? Milyen előzmények szükségesek?  Milyen komponensekre van szükség, hogy ezt a technikát kivitelezni tudják, és hol fejti ki a hatását? Fájlokon, registry változásokban, API-hívásokban, vagy jogosultságkezelési beállításokban?

Milyen hasonló komponenseket használnak a különböző technikákban? Mi a különböző és mi a hasonló?

Megnézik a detektálási oldalt is. Mi kell ahhoz, hogy észlelni tudják a technika használatát? Ez kapcsolatban van valami előzetes követelménnyel vagy cselekvéssel. Az is előfordulhat, hogy hasonló technikákban ez teljesen eltérő.

Hogyan tudják a hatását csökkenteni? Milyen hatáscsökkentő mechanizmusok állnak rendelkezésre abban az esetben, ha ezek hasonlóak más technikákkal? Ugyanazokat kell lépniük, és ugyanazok az eredmények várhatóak?

Legtöbb esetben az előbb említett kérdések egyike sem képes eldönteni, hogy hova tegyék az új információkat. De mindezeket átgondolva segítenek megtalálni a legjobb módot arra, hogy hogyan is építsék be az információkat az ATT&CK keretébe.

Ha érdekel a téma ezt is olvasd el

Regisztrálj a webinárra, hogy megértsd hogyan használhatod fel! 

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