ÜZLETI IT-SECURITY

IDM rendszer bevezetése: kapaszkodók a folyamat szakaszainak tervezéséhez

Bikki Mónika cikke

2020. július 16. - Kalmár Zsuzsanna

Dacára annak, hogy egy IDM rendszer bevezetésének nagyjából megvannak a mindenki által ismert lépései, a folyamat sok buktatót rejthet magában, ha nem megfelelően mérjük fel egy cég érettségének szintjét. A folyamatok felmérése és a pontos cél meghatározása sokat segíthet abban, hogy a stratégiai tervezés megfelelő irányba induljon és haladjon. Ehhez azonban a stratégiai előkészítés során tisztáznunk kell a rendszerbevezetés pontos rövid- közép- és hosszútávú lépéseit, méghozzá a cég érettségi szintjének megfelelően alakítva azokat.

idm_rendszer_bevezetese.jpg

Cégkategóriák és fontosságuk

Kezdjük azzal, hogy tisztázzuk, miért fontos megfelelő kategóriába besorolni az IDM rendszer kiépítésébe belekezdő cégeket: a rövid- közép- és hosszútávú feladatok ütemezése teljesen eltérően alakulhat az egyes vállalatoknál, azok érettségi szintjétől és céljától függően. Szerintünk ebből a szempontból érdemes három kategóriába sorolni a cégeket.

A legéretlenebb szervezet az, ahol pillanatnyilag képtelenek vagy csak nagy nehézség árán képesek megmondani - akár levelezésekből, papírokból vagy egyéb forrásokból összeszedni -, hogy ki, milyen jogosultsággal rendelkezik, azt ki engedélyezte és arról nem is beszélve, hogy bizonyos napokon egy adott rendszerben kinek, mikor, milyen jogosultsága volt. Ez mellesleg elég ijesztő helyzet, de ez lehet az egyik fő indikátora egy IDM rendszer bevezetésnek, amellyel már audit módban  is hatalmas előrelépést érhetünk el a szervezet életében. Audit módban a forrásrendszerekből gyűjtésre kerülnek az adatok, ezáltal aktuálisan és historikusan is ellenőrizhetővé válnak a beállítások. Sőt, adott esetben olyan rendszerekre is tudunk építeni, amelyek bevonása technikailag nehézségekbe ütközik, mert például nem integrálható megoldásokon alapulnak, vagy csak a menedzselése nem az adott cég hatásköre (pl. banki utaláshoz használt alkalmazás, céges Facebook oldal hozzáférés).

Közepes érettségi szinten már elérhetünk odáig, hogy a jóváhagyási és beállítási folyamatokat is felügyeljük és látható, hogy pontosan ki és mikor hagyott jóvá egyes jogosultsági igényeket. Egy IDM rendszerben kvázi felelősségi köröket tudunk kiosztani, így már nem csak a jogosultságváltozásokat felügyeljük. A rendszer ekkor már nem csak arra képes, hogy figyeljen, folyamatosan gyűjtse az adatokat, és eltárolja a jogosultságok időbeni alakulását, hanem az igénylési folyamatok is menedzselhetők, illetve a jóváhagyási és beállítási teendőket is elvégezhetjük.

Végül a legérettebb kategória az, amikor ezekre a folyamatokra felépíthetők a magas szintű üzleti megoldások is. Így csökkenthetjük a szükséges IT erőforrást azzal, hogy a jogosultság beállításokat a célrendszerekben automatizáltan végzi el az IDM rendszer.

Kiépíthetünk olyan megoldásokat is, melyekkel a vállalat munkatársainak teljes életciklusát, jogosultságait képesek vagyunk bizonyos fokú automatizációval menedzselni. Ezekre összetett folyamatok függeszthetők, és megoldható a szerepkörösítés is, hogy mindenki a saját munkakörének megfelelő jogosultságokat kapjon. Így elkerülhetők az olyan - sajnos - hétköznapi esetek, mint amikor valaki megkéri az IT-s kollégát, hogy az új munkatársnál állítsák már be azt, mint Bélánál is, mert hát úgyis ugyanazt fogják majd csinálni. De Bélának lehetnek olyan jogosultságai is, amelyek nem közvetlenül kapcsolódnak a munkaköréhez, akár korábbi munkaköréből visszamaradt hozzáférésekkel is rendelkezhet. Ezekre nem valószínű, hogy az új kollégának szüksége lesz, és az IT nem fogja tudni eldönteni, hogy melyek a szükséges és elégséges jogosultságok. Egy ilyen rendszer esetében pontosan kialakíthatjuk, hogy Bélának mi a szerepköre (alapjoga), melyek azok a jogok amelyek az adott munkakör ellátásához szükséges, s ha ugyanebbe a szerepkörbe vettünk fel valakit, a szabályozáson alapuló folyamataink már képesek arra, hogy pontosan a megfelelő jogosultságokkal ruházzák fel az új munkatársat is. Se többel, se kevesebbel.

Ugyanígy megoldható, hogy egy kolléga távozása esetén a rendszer letiltsa a felhasználói fiókját, elvegye a jogosultságait stb. Vagyis minden kritikus biztonsági folyamatot biztosíthatunk a dolgozó kilépésekor, amelyek egy ilyen rendszer hiánya esetében hatalmas biztonsági kockázatot jelenthetnek a vállalatra nézve.

De tovább megyünk: az olyan bonyolult folyamatoknál is hatalmas előny ez, mint a munkakörváltás. Ha egy kolléga pozíciót vált a cégen belül, nem kell kézzel összehasonlítgatni, hogy milyen jogosultságokkal rendelkezik jelenleg, mire lenne szüksége és mit kellene megvonni tőle. Egy jól konfigurált IDM rendszer ezt a terhet is leveszi a vállunkról.

A folyamat

Miután sikerült meghatározni egy vállalat érettségi szintjét, máris egyszerűbbé válik a folyamatok tervezése. Ez amúgy szinte minden cég esetében eltér és komoly kockázatokkal jár, ha meggondolatlanul állítják fel az ütemtervet. Ha felkészületlenül állunk neki és fogalmunk sincs, milyen IDM rendszert szeretnénk, azt milyen ütemezéssel vezetnénk be, akkor gyakorlatilag képtelenség a megfelelő terméket kiválasztani. Egy sikersztorihoz - amire lássuk be, minden cég vágyik - alaposan át kell gondolni a lépéseket. Ez amúgy az élet sok területére igaz, miért pont ez lenne kivétel?

Látnunk kell, mi az a cél, amit el szeretnénk érni és mennyi időnk van rá, hogy eljussunk odáig. Persze lehetnek kényszer helyzetek, amikor is egy audit megállapítás miatt adott időre kell eredményt felmutatni, de a legjobb, ha ezeket azért elkerüljük, és időben nekiállunk a tervezésnek. Erre a legjobb módszer a rövid- közép- és hosszútávú tervezés alkalmazása. A sült csirkét sem egyben próbálja meg lenyelni az ember, hanem feldarabolja megfelelő méretű szeletekre. Ráadásul az sem mindig célravezető, ha puszta kézzel esünk neki az ebédnek. Érdemes kiválasztani hozzá a megfelelő eszközöket. Ugyanezt az egyszerű és ésszerű elvet kell alkalmaznunk egy IDM rendszer bevezetésekor is. A pontos felosztáshoz “eszköz” gyanánt érdemes bevonni a folyamatba egy integrátort/tanácsadót, hogy a hatékonyság fokozása végett legyen kéznél olyan szakértő, aki irányítottan képes segíteni az aktuális helyzet felmérésben is.

Mint az előző bekezdésben taglaltuk, az, hogy pontosan honnan, hová és mikorra szeretnénk eljutni, nagyban függ a cég érettségi szintjétől is. Éppen ezért nagyon fontos, hogy precízen tudjuk felmérni az aktuális helyzetet. Emellett el kell dönteni, hogy a nem tisztázott folyamatokat miként kívánjuk dokumentálni, leszabályozni.

Kezdhetünk audit móddal, hogy megtudjuk, pillanatnyilag mi történik a rendszerünkben, s aztán eljuthatunk egészen az automatizálásig. A lényeg, hogy mindezt tudatosan, fokozatosan próbáljuk meg felépíteni.

Nem kell megijednünk attól, ha egy másik cég életében a rövid- közép- és hosszútávú tervezés esetleg teljesen másként alakult. Ez adódhat egyszerűen abból is, hogy teljesen eltérő fejlettségi szinten állt a két vállalat, amikor belekezdett változtatásokba. Egy már meglévő IDM rendszerben például egy audit esetén a historikus adatokból kimutatható, ki, mikor, milyen jogosultságokkal rendelkezett, miközben elképzelhető, hogy egyéb folyamatokat még nem integráltak, így azok felmérése és integrálása csak ekkor kezdődik. Az is lehet egyfajta középtávú cél, hogy idáig eljussunk.

De a végcél például lehet akár az is, hogy az e-mailes ticket küldözgetés helyett a jogosultságbeállítás automatikusan menjen a cégnél. Azonban idáig is apránként, lépésenként kell eljutunk, hogy egy teljesen stabilan, megbízhatóan működő rendszerre tudjuk ráépíteni ezeket a kritikus folyamatokat.

A rövid- közép- és hosszútávú tervek általános részei

Mint a fentiekből is látszik, nehéz általánosan meghatározni azokat az elemeket, amelyek a folyamat három fő szakaszához tartoznak. De azért megpróbálunk néhány példával szolgálni.

A rövidtávú terv egyértelmű része a felmérés és a tervezés. Az, hogy milyen rendszert választunk annak nagyon fontos része, hogy látnunk kell, hol tartunk és hova akarunk eljutni. Különböző IDM rendszerek más-más előnyökkel szolgálhatnak. De ismeret hiányában nehéz kiválasztani azt a rendszert, amely működésben, rugalmasságban, felhasználói oldalon a legjobban kielégíti az igényünket. Egy jó tanácsadó bevonása nagy segítséget jelenthet!

Az előkészítés részeként, ha például van egy HR rendszerünk, de abból kimaradtak a külsős kollégák, akkor ezeket az alapokat le kell fektetni az IDM rendszer felépítése előtt, különben nem kapunk teljes körű szolgáltatást a végén. Lesz egy halom felhasználónk, akikről gőzünk sem lesz, hogy kik is pontosan. Ez rendkívül megnehezíti az ellenőrzést és a jogosultsági kontrollt, pedig az IDM rendszerrel pont az lenne célunk, hogy felügyelni tudjuk a felhasználóinkat. Vagyis a rövidtávú tervben ez esetben szerepelnie kell egy nyilvántartás összeállításnak, és ki kell dolgoznunk, hogy milyen módon érdemes a külsősöket azonosítani, adataikat tárolni.

Rövidtávú terv lehet az alkalmazásaink felmérése, azok kategorizálása, ha még nincs megbízható nyilvántartásunk. Nem biztos, hogy első körben a teljes lefedettség a cél, lehet elég csak a kritikus alkalmazásokra lőni. 

Ha már rövidtávon eljutottunk odáig, hogy kiválasztottuk a rendszert, bevezettük mondjuk audit módban, akkor középtávon specializálhatjuk az IDM működését. Kialakíthatjuk a folyamatokat, szerepköröket, létrehozhatunk különböző szabályokat az automatizáláshoz. De tervezhetjük például egy SOD (Segregation of Duties) rendszerbe integrálását is, amellyel mondjuk egyszerűsíthető az összeférhetetlen szerepkörök kezelése.

S hogy mi kerülhet a hosszú távú tervbe, ha már középtávon túljutottunk az automatizálás egy részén? Nos, ne legyenek kétségeink, hogy lesz még mit tovább automatizálni, hogy a lehető legkevesebbre csökkentsük az emberi beavatkozást. Ráadásul közel sem biztos, hogy eljutunk idáig a középtávú tervvel: ahány cég, annyi szokás.

Összegzésül

Ha a fentiek alapján úgy tűnik, hogy egy IDM rendszer bevezetésének megtervezése nagyjából a lehetetlen küldetések kategóriájába tartozik, nem rögtön kell elkeseredni. Csak arra igyekeztünk rávilágítani, hogy a rövid- közép- és hosszútávú tervezés folyamata az IDM bevezetés esetében rendkívüli módon függ a cég aktuális állapotától. Többek között ezért is javasoljuk az integrátor bevonását a folyamatok tervezésébe, mert ha szakértő hiányában nem látjuk át megfelelően a lehetőségeket és feladatokat, annak beláthatatlan következményei lehetnek a cégre nézve. Márpedig a cél éppen az, hogy az IDM bevezetésével elősegítsük a szervezet hatékonyabb és biztonságosabb működését és erre alapozva sikerre tudjuk vinni a vállalkozást.

 

IRATKOZZON FEL A LISTÁNKRA, hogy értesítést kapjon a témához kapcsolódó webinárról.

A webinár időpontja július 29. 10:00-11:00

FELIRATKOZOM

 

Microsoft 365 biztonsági kihívások: így védjük ki a támadásokat

Krékity Gusztáv cikke

Lássuk be, a levelezés on-prem menedzselése sokszor igencsak fájdalmas és elavult, így aki teheti, ignorálja az útválasztási problémákat, a lemezkvóták számolgatását, a visszapattanásokat vagy a felhasználói problémákat. Ezek után nem csoda, hogy a Microsoft 365 (lánykori nevén Office 365) oly népszerűvé vált az utóbbi időben, s egyre több cég voksol rá, hiszen a felhő alapú e-mail kezelés üzemeltetése sokkal egyszerűbb és költséghatékonyabb. Ráadásul olyan alapvető biztonsági funkciókat is tartalmaz, amelyek célja a felhasználók védelme a legújabb fenyegetésekkel szemben, ezen felül pedig lehetőséget kínál a felhasználói élmény fokozására, az egyszerűbb használatra, a hatékonyabb munkára.

adathalaszat.jpg

A felhasználók közvetlenül eljutnak az Microsoft 365 weboldalra, ott beírhatják a vállalati hitelesítő adataikat, így bárhol, bármikor beléphetnek e-mail fiókjukba. Már-már a tökéletes megoldásnak tűnik, de sajnos ez csak a látszat!

A népszerűség átka

Természetesen a trendekre igen fogékony kiberbűnözőknek is feltűnt a Microsoft 365 egyre növekvő népszerűsége, s mi sem természetesebb, hogy ezt igyekeznek minden eszközzel kihasználni: a Microsoft 365 felhasználóit célzó adathalász kampányokba kezdenek, hogy azok segítségével ellopják a felhasználók bejelentkezési adatait. Céljuk, hogy átvegyék a fiókok feletti hatalmat, azaz a teljes hozzáférést.

Ha az online zsiványok sikerrel járnak, legtöbbször bejelentkeznek a kompromittálódott fiókokba, majd változatos módszerekkel kezdenek tombolásba:

  • Megpróbálják az - akár kártékony kódokat is tartalmazó - adathalász leveleket a belső hálózaton keresztül terjeszteni.
  • Célzott és személyre szabott támadásokat hajthatnak végre (Spear Phishing)
  • Adott esetben megszerezhetik a globális vállalati címlistát

E tevékenységek azért is különösen veszélyesek, mivel észrevétlenek maradhatnak. Ennek oka, hogy a támadó valós, engedélyezett hitelesítő adatokkal álcázhatja magát: a rendszerbe valódi munkatársként bejelentkezve gyűjt információkat. Ráadásul ezzel a módszerrel nem csak egyszer élhet, hanem később is visszatérhet, hogy újabb támadásokat hajtson végre.

Hogyan épül fel egy ilyen támadási lánc?

A támadók által a Microsoft 365 fiókunkhoz való hozzáféréshez alkalmazott adathalász módszerek meglepően egyszerűek. Az adathalász kampányok általában a Microsoft által küldött e-maileket utánozzák. Az elektronikus levél egy bejelentkezési felszólítást tartalmaz, például arra kéri a felhasználót, hogy egy - tudtán kívül preparált - linkre kattintva állítsa vissza a jelszavát, mert valamilyen probléma lépett fel a fiókkal.

microsoft_365_biztonsagi_kihivasok_igy_vedjuk_ki_a_tamadasokat_1.jpg

microsoft_365_biztonsagi_kihivasok_igy_vedjuk_ki_a_tamadasokat_2.jpg

A leghatékonyabb átverés általában az, amikor - a felhasználó félelmére alapozva - úgy állítják be a helyzetet, mintha a fiókot ismeretlen támadók feltörték volna, és emiatt sürgősen jelszócserére lenne szükség az adatok védelmében. Ez a legtöbb esetben kellően erős motiváció ahhoz, hogy a felhasználó gondolkodás nélkül kattintson a levélben található “jelszó visszaállítási” linkre. A végeredmény pedig természetesen az, hogy a linkre kattintva megnyitott - értelemszerűen nem a Microsofthoz vagy a céghez tartozó, de hivatalosnak látszó - oldalon megadott régi jelszó és felhasználónév birtokában máris nyeregbe kerülhetnek a kiberbűnözők.

Miként védekezhetünk az ilyen jellegű támadások ellen?

Szerencsére számos IT biztonsági gyártó, köztük a Trend Micro is, kiemelt figyelmet szentel a levelezés védelmére. A Trend Micro Cloud App Security megoldása közel 13 millió, magas kockázati besorolású e-mail fenyegetést blokkolt az elmúlt év során azokon felül, amelyeket már a felhőalapú e-mail biztonsági és szűrési szolgáltatások is felismertek.

Nemrég - 2020 márciusában - az FBI (Federal Bureau of Investigation) kibervédelmi osztálya egy közleményt adott ki a BEC (Business Email Compromise) támadásokról. Ebből kiderül, hogy - az FBI panaszinformációi alapján - a Microsoft Microsoft 365 és a Google G Suite, tehát a jelenlegi két legnagyobb és legnépszerűbb felhőalapú e-mail szolgáltatást célozták leginkább a kiberbűnözők az elmúlt években. A 2014 és 2019 között az FBI Internetes Bűncselekmények Panaszközpontja (IC3) több mint 2,1 milliárd dollárnyi ténylegesen leigazolt veszteségről tudott a fenti két felhőszolgáltatást megcélzó BEC támadások alapján.

A Trend Micro Cloud App Security egy API alapú megoldás, amely hatékonyan megvédheti a Microsoft 365, a Google G Suite és a Dropbox felhő szolgáltatásokat egyaránt. Ehhez több fejlett fenyegetésvédelmi technológiát használ. Az eszköz a Microsoft 365 mellé települ, egyfajta második rétegként, amely a belső levelezési forgalmat is vizsgálja, szemben az e-mail biztonsági és Microsoft 365 ATP szolgáltatásokkal.

hh.png

A Trend Micro 2019-ben 12,7 millió kritikus vagy magas kockázatot jelentő e-mail fenyegetést azonosított azokon felül, amelyeket az Microsoft 365 vagy Gmail biztonsági eszköztára már blokkolt. E fenyegetések közé tartozik:

  • 1 Millió rosszindulatú program
  • 11,3 Millió adathalászati kísérlet
  • 386K BEC kísérlet
  • 4,8 millió hitelesítő adathalászat
  • 225K Ransomware kártékony kód

microsoft_365_biztonsagi_kihivasok_igy_vedjuk_ki_a_tamadasokat_4.jpg

Ezen támadások mindegyike olyan potenciális veszélyforrás, amelynek végkimenetele a szervezet monetáris-, termelékenységi- vagy akár reputációs vesztesége is lehet.

A Trend Micro 2018 óta teszi közzé hivatalosan a Cloud App Security fenyegetés detektálási statisztikákat és jelentéseket. A következő statisztikák és példák különböző forgatókönyvekre vonatkozóan azt is jól ábrázolják, hogy a Cloud App miként képes megvédeni a szervezeteket az ilyen jellegű támadásokkal szemben.

microsoft_365_biztonsagi_kihivasok_igy_vedjuk_ki_a_tamadasokat_5.jpg

A fenti, anonim adatokat tartalmazó táblázat öt Microsoft 365 felhasználó 1 éves (2019) adatait mutatja a Trend Micro Cloud App Security használata mellett. Ebbe a statisztikában már csak azok a támadások kerültek bele, amelyeket a Trend Micro blokkolt második rétegként. A fent említett öt cég különböző iparágakban működik és méretükből adódóan 550 és 80 ezer közötti számban vannak e-mail fiókjaik. Az ügyfelek kivétel nélkül Microsoft 365 E3 előfizetéssel rendelkeznek, amely magába foglalja az alapvető biztonságot jelentő Exchange Online Protection Service szolgáltatást.

Jól megfigyelhető, hogy az e-mail átjárók és felhő alapú e-mail szolgáltatások beépített biztonsága mára egyértelműen nem elegendő a szervezetek védelméhez az e-mail alapú, fejlett, ismeretlen vagy célzott fenyegetésekkel szemben. A vállalkozásokat - méretüktől függetlenül - számos ilyen jellegű veszély fenyegeti. Éppen ezért a cégeknek mérlegelniük kell egy átfogó, többrétegű biztonsági megoldás bevezetését, amely képes hatékonyan kiegészíteni az e-mail védelmi és az együttműködési platformok, például a Microsoft 365 és a G Suite biztonsági csomagjait.

További hasznos tudnivalók

Amennyiben további érdekességek, statisztikák és támadások érdekelnek vagy a Trend Micro Cloud App Security megoldása részletesen, csatlakozz a témában következő Webinárhoz, amelyet a gyártó hazai képviseletének Pre-Sales mérnökével közösen szervezünk.

 

IRATKOZZON FEL A LISTÁNKRA, hogy értesítést kapjon a témához kapcsolódó webinárról.

A webinár időpontja július 30. 10:00-11:00

FELIRATKOZOM

 

A Packet Broker előnyei a hálózat monitorozásban

Egy hálózat biztonságának fejlesztése ma létfontosságú szempont a vállalatoknál. Fontos a hálózat állapotának folyamatos ellenőrzése, a meglévő eszközök megfelelőségének vizsgálata, és az esetleges fejlesztések elvégzése. A zökkenőmentes működést azonban biztosítani kell az állapotfelmérés alatt is, ami sokszor közel sem egyszerű feladat. Nem mindegy tehát, hogy milyen hálózat monitorozási megoldások mellett tesszük le a voksunkat. Mai bejegyzésükben olyan eszközöket mutatunk, amelyekkel mindez - a lehetőségekhez mérten - kényelmesen és megbízhatóan kivitelezhetőblogbejegyzes-monitoring-fekvo.jpg

Miért fontos monitorozni a hálózatot?

A hálózatok csomagszintű monitorozása rendkívül fontos, hiszen így proaktív módon vagyunk képesek detektálni a hálózati problémákat: ha rendelleneséget tapasztalunk a hálózaton, valamilyen hálózati anomália jelentkezik, esetleg egy támadás indul akár az Internet, akár a belső hálózat irányából. Ezen esetekben gyorsabban tudjuk azonosítani a problémák okát a hálózat csomagszintű monitorozásával, mint bármely más megoldással.

Egyre nagyobb igény a csomag szintű monitorozásra

A hálózati üzemeltetés esetében nagyon sokszor előfordul, hogy valamilyen hálózati probléma lép fel. Ilyenkor tulajdonképpen a legjobb módszer, ha csomag szinten odamegyünk és megnézzük, hogy az adott linken mi történik. Így gyorsan kiderítjük, milyen jellegű kommunikációs hibát okoz mondjuk egy alkalmazás, és elháríthatjuk a problémát. Ezzel a megoldással követő üzemmód helyett egy afféle előre detektáló, előrelátó megoldást kapunk, amivel nem csak akkor deríthetünk fényt a problémára amikor az már bekövetkezett, hanem bizonyos szinten előre tudjuk jelezni a veszélyt. Ha például olyan forgalmat, csomagokat észlelünk a hálózatban, amelyek nem odavalók, az akár egy támadás jele is lehet, vagy adott esetben a forgalom téves irányítására is utalhat.

A „csupán” LOG és Flow információkkal végzett hálózat monitorozás, egy kicsit olyan, mintha -ca sötétben tapogatózva igyekeznénk információkat összegyűjteni egy szobában, s képtelenek lennénk eldönteni, hogy amit találtunk, az egy asztal vagy szék-e inkább. A hálózati visibility ezzel szemben maga a zseblámpa, amivel pontosan rávilágíthatunk a dolgokra, s egyértelműen beazonosíthatjuk azokat, mielőtt magunkra döntjük a ruhásszekrényt is a sötétben.

Ez a megoldás akkor válik igazán látványossá, ha több ilyen „lámpánk” van, s focipálya módjára az egész területet (avagy a hálózatunkat) kivilágíthatjuk, hogy még pontosabban lássuk mi zajlik éppen a pályán. A bírák (hálózat biztonsági eszközök) könnyebben észreveszik a szabálytalanságokat, az edzők (hálózat, alkalmazás performancia monitorozó eszközök) számára pedig nyilvánvalóvá válik mely pontokon teljesít alul a csapat; sőt az egész mecset akár rögzíthetjük is (forensics eszközök) későbbi vizsgálatok céljából. Amit az egyszerű LOG üzenetekből, naplófájlokból nehéz kimazsolázni, itt sokkal könnyebben kibogozható

Éppen ezért a hálózati üzemeltetésben egyre nagyobb az igény arra, hogy a hálózatok viselkedését akár csomagszinten is vizsgálhassuk.

Egy a hálózat perifériáján működő hálózatbiztonsági eszköz egy adott biztonsági szintet tud biztosítani számunkra az adott kapcsolaton. Esetleg log információk gyűjtésével részleges információt kaphatunk arról, hogy a hálózat többi részén milyen események történnek. De képzeljük, hogy ugyan az a hálózatbiztonsági eszköz a hálózat összes kritikus pontjának védelmét csomagszinten tudná biztosítani, anélkül, hogy újabb és újabb inline eszközöket kellene telepítenünk.

Az igény növekedésével a gyártók is sorra hoznak ki csomag szintű analizátorokat. A kérdés így már csak az, hogy miként lehet a hálózati forgalmat ezekre az eszközökre, performancia monitorozó alkalmazásokra irányítani. Mit tegyünk, ha egy SAP vagy egy voice over IP szolgáltatás minőségét szeretnénk ellenőrizni, annak megzavarása, kockáztatása nélkül?

Ráadásul akkor is nagyon sokat segíthet egy ilyen rendszer kiépítése, ha szükségessé válik a hálózat bővítése, fejlesztése, mert elöregedett a meglévő eszközpark. Ezekkel a modern monitorozó megoldásokkal az új eszközöket kényelmesen, s ami fontos, élő forgalommal tesztelhetjük, anélkül, hogy megzavarnánk vagy kockáztatnánk a meglévő hálózat működését. Gyakorlatilag letükrözzük a meglévő forgalmat, s azon tesztelünk. Ez szoftver frissítések esetében is igen hasznos kellék lehet.

Variációk egy témára

Egyre több helyen tapasztaljuk, hogy a vállalatoknak több ilyen eszközre is szükségük van, amikor tetszőleges célból monitorozni akarják a hálózati forgalmat csomag szinten. A feladat gyakorlatilag az, hogy megtaláljuk a módját, hogy ezek az alkalmazások, megoldások hozzáférhessenek a hálózati forgalomhoz.

Az egyik módszer az lenne, hogy inline illesztjük őket a hálózati forgalom útjába, ám ez meglehetősen skálázhatatlan: ha meghibásodik ez a monitorozó eszközünk, akkor ott az adott link is megszakad. Éppen ezért inkább az out of band módszert szokták választani, vagyis nem az éles hálózati forgalomba illesztjük bele ezeket az eszközöket, hanem kitükrözzük a hálózati forgalmat, kvázi kimásoljuk a hálózatból. Létrehozunk egy out of band infrastruktúrát, amely az éles hálózati infrastruktúra mellett működik. Így semmilyen módon nem befolyásolja az éles hálózatunk működését, ami lássuk be, létfontosságú az ügymenet folytonossága szempontjából.

A fentieket általában úgy valósítják meg a hálózatos mérnökök, hogy a hálózati eszközökben (switchekben) valamilyen módon tükrözést állítanak be, amivel a hálózati eszközökből kitükrözik a forgalmat, vagy annak egy részét, esetleg az adott linkek forgalmát az eszközök felé. Ez általában működik, ráadásul legtöbb esetben ingyenes megoldást is találunk rá a hálózati eszközökben. A hatékonysága viszont sok esetben nem megfelelő.

Alapvetően ennek a SPAN portnak a működése igen bizonytalan. Nem minden esetben tudjuk garantálni, hogy az összes rajta áthaladó csomag tükröződik és biztosan elérkezik az analizáló eszközhöz. Ez pedig óriási probléma, hiszen ha mi egy nagyon jó minőségű, drága, megbízható megoldásba beruházunk, de közben nem vagyunk képesek garantálni, hogy tényleg mindent lásson ami a hálózatunkban történik, akkor az analizáló eszközzel mért eredmények nem lesznek relevánsak. Fél információból tápláljuk meg az eszközünket, ami így alkalmatlanná válik a pontos elemzésre. A switchekbe integrált ingyenes szolgáltatások ily módon inkább csak kényelmi extrák, mintsem valóban használatra alkalmas megoldások. Ráadásul ha valamilyen hálózati probléma adódik, ezek az eszközök szinte elsőként tiltják le vagy helyezik háttérbe ezt a funkciót, ami újfent csomagvesztést okozhat.

A másik probléma az, ha van egy ilyen SPAN portunk, viszont több eszközünk van, amelyek felé továbbítanánk a forgalmat. Ez újfent problémát okozhat, hiszen a mirror portról érkező forgalmat macerás megfelelően szétosztani a különböző analizáló eszközök felé. Ráadásul ilyen esetekben nagyon könnyen túlterhelhetjük az eszközöket. Sőt, még azzal a kihívással is szembesülhetünk, hogy fizikailag sem áll rendelkezésre annyi port az analizáló eszközön, mint amennyi hálózati forgalmat éppen tükrözni kívánunk.

Network visibility megoldások

A fenti kihívásokra nyújtanak megoldást a network visibility rendszerek. Ezek egyrészt hálózati TAP-ekből épülnek fel - hálózati forgalom kitükröző eszközök -, amelyekre a hálózati kábel ráköthető, s így a hálózati forgalom pontos másolatát tudjuk tükrözni. Ha például optikai kábelről van szó, akkor gyakorlatilag a fény egy részét türközik ki. Passzív eszközök, amelyekkel konkrétan láthatjuk, mi történik az adott linkeken.

Másrészt fontos funkcionális elemek az úgynevezett Packet Broker megoldások is. Ezen eszközök képesek aggregálni a nagy számú kitükrözött forgalmat. Mindent, amit a hálózatról próbálunk begyűjteni, megfelelő interfész sebességgel tudnak fogadni. Ezekre az eszközökre szépen ráköthetjük a különböző analizáló eszközeinket, amelyekkel monitoroznánk a hálózatot.

ixia.png

A Packet Broker előnye, hogy nem csak egyszerűen összegyűjti és egy másik porton továbbítja az összegyűjtött forgalmat, hanem képes előszűrni azt. Feldolgozza a beérkező forgalmat és a megfelelő analizáló eszközöknek csak a számukra releváns forgalmat továbbítja. Ha mondjuk van egy voice over IP hangszolgáltatást elemző monitoring szoftverünk, annak nyilván a teljes kitükrözött forgalomból elég csak a hang alapú forgalmat továbbítani. Felesleges lenne terhelnünk egyéb, nagy mennyiségű adatforgalommal, amivel amúgy sem tud mit kezdeni. Ugyanígy a hálózat biztonsági eszközök esetében is elég csak a releváns forgalmat továbbítani. Mondjuk a titkosított forgalmat, amibe nem tud belenézni, eleve levesszük a kérdéses eszközről, megelőzve az esetleges túlterhelést. Ezáltal sokkal hatékonyabban lehet e megoldásokat a hálózatba illeszteni. Emellett rugalmasságot biztosítanak: ha a hálózat egy bizonyos pontjára szeretnék rálátni, akkor csak egy újabb TAP-et illesztünk a hálózatunkba, bekötjük egy Packet Borkerbe, s az eszközünk annak a hálózati szegmesnek a védelmét is képes ellátni.

Érdemes még megemlíteni a felső kategóriás Packet Broker megoldásokat, amelyek amellett, hogy aggregálják, szűrik, esetleg terheléselosztást biztosítanak a különböző monitorozó megoldások felé, olyan csomag szintű módosításokat és elvégezhetnek mint a forgalom deduplikálása. Vagyis ha több helyről tükrözzük ki a hálózati forgalmat, akkor ismétlődően ugyanazt a csomagot több helyről is begyűjthetjük a hálózatról, amivel nyilván feleslegesen terhelnénk az analizáló eszközöket. Ezeket egy Packet Broker megoldás legyűjti, leválogatja és az analizáló eszköz felé az elkapott csomag csak egyetlen példányát továbbítja. Emellett képes csomagmódosítást végezni, vagyis ha valamilyen felesleges (header) információ van a csomagon, azokat el tudja távolítani. Sőt, arra is kiválóan használható, hogy SSL titkosítással védett csomagokat kibontsunk vele. Így olyan titkosított kapcsolatokba is belenézhetünk, amelyeket egyébként a hálózat analizáló megoldás nem tudna feldolgozni, vagy ha fel is tudná dolgozni, a Packet Brokerrel mindössze egyszer kell elvégeznünk a kititkosítását, amelyet aztán akár több eszköz is megvizsgálhat.

Összegzésül

Mindent egybevetve nézzük meg, melyik az a négy értékteremtő jellemzője e megoldásoknak, amelyek miatt előnyös lehet az ügyfelek számára:

  1. növeli a biztonságot
  2. növeli a hálózati forgalomnak a láthatóságát
  3. gyakorlatilag a hibaelhárítás folyamatát is képes csökkenteni, így sokkal előbb rálátunk az esetleges problémákra
  4. növeli a hálózat monitorozó eszközök hatékonyságát

Egy ilyen hálózat visibility megoldás segítségével a fejlett, csomagszintű analizálásra is képes eszközeink (pl. RSA NetWitness, Dynatrace, Wireshark, Viavi stb.) sokkal hatékonyabbak tudnak lenni, mivel az oda becsatornázott forgalom százszázalékosan az a forgalom, amit az eszköznek vizsgálnia kell (nem több nem KEVESEBB). A visibility infrastruktúra kiterjesztésével újabb és újabb hálózati szegmensekre (akár virtuális, publikus felhő infrastruktúrák), a hálózat közel egészén ugyan azt a biztonsági szintet, felhasználói élményt tudjuk biztosítani. Ugyanakkor a megoldás out-of-band mivoltából adódóan az újabb analizáló eszközök bevezetése nincs hatással a produktív hálózat működésére.

IRATKOZZON FEL A LISTÁNKRA, hogy értesítést kapjon a témához kapcsolódó webinárról.

A webinár időpontja július 28. 10:00-11:00

FELIRATKOZOM

Az IT biztonság automatizációjának fontossága, előnyei

Sajó Péter cikke

2020. június 29. - EURO ONE

Az IT biztonság területének talán az egyik legösszetettebb - és jelenleg az egyik legfelkapottabb - fogalma az automatizáció. Esetünkben ez egy elég tág fogalom, amelynek rengeteg aspektusa van: ide tartozik például a machine learning, vagyis hogy miként lehet olyan rendszereket építeni, amelyek különösebb emberi beavatkozás nélkül képesek tanulni, s ide tartozik a robotika is. Sok nagyvállalat - többek között pénzintézetek - foglalkozik e témakörrel abból a szempontból, hogy gépekkel tudják kiváltani a humán erőforrás egy részét. Éppen ezért nem csak IT, hanem döntéshozói szempontból is rendkívül fontos, hogy megismerjük ezen automatizáció lehetőségeit, előnyeit.

Miért van szükség az IT biztonság automatizációjára?

Az IT biztonság automatizációja tulajdonképpen egy üzleti projekt, amelynek fő mozgatórugói megegyeznek az IT szektoron belül megszokottakkal. Az egyik ilyen indítóok például az lehet, ha nincs megfelelő számú szakértő a piacon. Ez esetben valamiképp helyettesíteni kell őket. Anélkül kell csonka létszámmal dolgozni, hogy veszítenénk a hatékonyságunkból. Szintén hajtóerő lehet, hogy egyre bonyolultabb rendszerekkel dolgozunk, egyre összetettebb architektúrákat működtetünk. Ennek köszönhetően a hibalehetőségek száma is jelentősen megnőtt, márpedig ezeket a versenyképességünk megtartása érdekében - amennyire csak lehet - meg kell próbálnunk kiküszöbölni. Emellett nyilván gyorsítani is kell e folyamatokat, hiszen a versenyképesség egyik kulcsfontosságú eleme, hogy kellő gyorsasággal reagáljunk, amikor egy folyamatot végigviszünk annak lezárásáig. Ráadásul a mostani támadások jóval kifinomultabbak, mint régen, így az észlelésük és elhárításuk egyaránt bonyolult technikai rendszereket és összetett folyamatokat igényel. A hatékony fellépéshez több csoport együttműködésére van szükség. Mindezek alapján közel sem mindenki számára egyértelmű, hogy ezekre az üzletet veszélyeztető fenyegetésekre mi a jó válasz, s miként lehet gyors megoldást találni.

E kihívásoknak köszönhetően az üzleti élet számos területén tolódik el hangsúly az intelligens automatizálás irányába. Amerikában és Nyugat-Európában már nagyjából két éve dolgoznak ezen, olyan esetek elemzésével, amelyekkel modellezhető, hogyan építhető fel egy vállalati szintű program, milyen buktatók adódhatnak, s miként lehet gyors sikereket elérni. Ezen átalakítás hullámai érték el most a biztonsági világot is, a Security Operation Automation and Response technológia területén. S mivel ennyire erős az összefonódás a két terület között, ez a problémakör egyszerre érinti az IT biztonságot és a vele amúgy is kéz a kézben járó IT üzemeltetést.

Buktatók

Összetettsége okán a cégek számára meglehetősen nehéz kérdés, hogy hol is kezdjenek hozzá a biztonsági automatizáláshoz. Kézenfekvő persze, hogy arra a területre koncentráljanak, ahol a legtöbb megtérülés érhető el, a lehető legegyszerűbb módon, s az üzleti szempontú igényeket a lehető legolcsóbban lehet kielégíteni.

Biztonság szempontjából sok cégnél volt fókuszban eddig is a megelőzés, s ha sikerült egy működőképes modellt összehozni, nem feltétlenül ezen a részen érdemes most automatizálásban gondolkodni. Vállalati szinten maguk a gyártók gondoskodnak arról, hogy minél korszerűbb eszközökkel rukkoljanak elő, amelyek viszonylag kevés emberi beavatkozás nélkül is alkalmasabb a bonyolult feladatok megoldására. Van azonban e területnek egy olyan része is, ahol a technológia nem képzelhető el humán interakció nélkül: a biztonság felügyeleti rendszerek.

Addig már eljutottunk, hogy a gépek riasztanak bármilyen észlelt probléma esetén, ám e ponttól kezdve hatékony humán erőforrásra lenne szükség a felmerülő kihívások megoldására. S itt szokott elvérezni a cégek nagy része. Korábbi kutatásaink és a friss céges egyeztetések alapján egyértelműen látszik, hogy a cégek igen eltérő érettségi szinten vannak ezt illetően. A nemzetközi trendekhez hasonlóan itthon is jellemző, hogy még a megfelelő számban és minőségben rendelkezésre álló, szükséges technológia birtokában, saját szakértőkkel a hátuk mögött is kihívást jelent számukra az összehangolt együttműködés. A folyamatok nincsenek megfelelően rögzítve, a csoportok közötti információátadásnak nincsenek megteremtve a feltételei, és a nagy mennyiségű információ elemzése sincs kiegészítve kellő technológiával és üzleti kontextussal. Márpedig meglehetősen nehéz úgy megfelelő döntést hozni, hogy a temérdek információ - például rengeteg riasztás - özönéből nem tudjuk kimazsolázni, melyek a valóban üzletileg kritikus fenyegetések.

Mi a megoldás?

Sajnos faék egyszerűségű megoldás ez esetben nem létezik. A megfejtés az automatizálás lehet. A biztonsági felügyeleti rendszert üzemeltető csapat egyik feladata a vállalatot fenyegető kockázatok észlelése, s annak gyors eldöntése, hogy az adott fenyegetés valóban kritikus-e vagy sem. Emellett kötelességük, hogy szükség esetén a lehető leggyorsabban és leghatékonyabban reagáljanak, akár önállóan, akár más csapatokkal együttműködve.

Sajnos azonban - és ezt a nemzetközi trendek is megerősítik - a folyamatok jelenleg nem ilyen gördülékenyek: hol a részlegek, hol a szoftverek nem működnek együtt

Ahhoz, hogy mindez működőképessé váljon, a munka két aspektusának kell megfelelni, amihez a detektálási és a válaszadási oldalt is rendbe kell tenni.

Ha e kettőt külön kezeljük, akkor a feladat nem megoldható egyszerűen egy új technológia bevezetésével. Ezért létfontosságú felmérni, hogy a folyamat szabályozási szintjén adott pillanatban hogyan áll a vállalat: ha a két végletet nézzük, akkor ad hoc működnek, vagy nagyon szabályozottan, a kockázatokat minden pillanatban mérlegelő módon. Ha ez a felmérés megtörténik, már könnyebb kijelölni a megfelelő utat.

Nyilván szükség van egy olyan platformra is, amely ezt a típusú tevékenységet támogatja. Ez lehet a Soar technológia (Security operation, Automation and Response), amelynek bevezetésében szakértők tudnak segíteni a cégnek. Ők tudják meghatározni, hogy a folyamatokat milyen módon lehet automatizálni és az adott platformra megvalósítani. Automatizálni szinte mindent lehet, a kérdés leginkább csak az, hogy mivel kezdjük el. Osztályozni kell a tennivalókat fontosság szerint, ami nem mindig egyszerű feladat, mert előfordulhat, hogy olyan folyamatba futunk bele, amit első ránézésre nem tudunk automatizálni biztonsági szempontból. Viszont ha egy ilyen folyamat üzleti szempontból létfontosságú, akkor érdemes jobban belenyúlni és esetleg úgy átalakítani, hogy később mégis automatizálhatóvá váljon.

A folyamat lépései

Ha egy cég megkeres bennünket azzal, hogy biztonsági rendszerét szeretné hatékonyabbá tenni, esetleg konkrétan az automatizáláson gondolkodik, akkor a módszertanok viszonylag egyszerűek. Először is elvégezhetünk egy felmérést, melynek során a nemzetközi iránymutatások, sztenderdek alapján elemezzük a cég jelenlegi működését, illetve azt, hogy életciklusilag hol tart a biztonsági rendszerek tekintetében. Ezek alapján kiszűrhető, hogy melyek azok a technológia illetve folyamat szintű problémák - akár humán erőforrás szintű problémák - amelyeket kezelni kell. Ebből készítünk egy road mapet az ügyfél számára - ez egy több negyedéven, akár éveken keresztül is áthúzódó fejlesztési terv -, amely mindhárom fontos layert egyszerre kezeli, így a segítségünkkel az ügyfél képes lesz a jelenlegi technológiákat jobban kihasználni. Ugyanis nem kizárólag új technológiák bevezetésével lehet csak fejlődni, hanem a jelenlegiek optimalizálásával is. A meglévő folyamatok átalakítása is jó eredményt hozhat.

Egy adott ponton elképzelhető, hogy bevezetünk egy SOAR platformot ha szükséges, de akár azt is lehetséges, hogy ezt szolgáltatásként megkapják.

A variációs lehetőségek száma hatalmas, így az is javasolt, hogy készüljön egy “automatizálási blueprint”, módszertani leírás, amellyel a döntéshozók számára is egyértelműen szemléltethetők a változtatások és azok hatásai.

Hozzátenném, hogy több céggel dolgozunk együtt jelenleg is, és vannak olyan futó projektjeink, ahol kifejezetten biztonság felügyeleti csapatokat, vagy ahol SOC csapatokat, illetve azok működését próbáljuk most hatékonyabbá tenni. Mindezt egy automatizálási projekt keretein belül is.

Bár mindez nem egyszerű, a szakértők bevonásával jelentősen csökkenthető a bevezetési idő, így véleményünk szerint mindenképpen érdemes ebbe az irányba elindulni.

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

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