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

EURO ONE

A gépi tanulás növekvő szerepe a kiberbiztonságban

Krékity Gusztáv cikke

2020. szeptember 08. - Kalmár Zsuzsanna

Az elmúlt időszakban döbbenetes mértékben megnövekedett a kibertámadások száma és sokszínűsége. A kiberbűnözők egyre kreatívabbak, így a CISO-k, üzleti döntéshozók, cégvezetők számára egyre nyilvánvalóbb, hogy ideje átalakítani a kiberbiztonsági stratégiákat. Ráadásul a szervezetek egyre többször szembesülnek azzal, hogy nem találnak megfelelő kompetenciákkal rendelkező - és kellő mennyiségű - biztonsági elemzőt, mérnököt, így nem képesek kellő sebességgel bővíteni biztonsági műveleti központjuk kapacitását (SOC).

blogbejegyzes-mesterseges-intelligencia.jpg

A kérdés legtöbb esetben az: hogyan tudunk lépést tartani kihívásokkal és hogyan tudunk előre jutni? Úgy tűnik, ennek megválaszolására a szervezeteknek, illetve a szervezetek döntéshozóinak fokozniuk kell a mesterséges intelligencia (AI) és a gépi tanulás (ML) iránti érdeklődésüket és elkötelezettségüket.

 

AI és ML: nem feltétlenül a szakemberek teljes kiváltására

Manapság az AI és az ML már számos szervezet kiberbiztonsági keretének nélkülözhetetlen részét képezi. A legfrissebb kutatások és felmérések szerint a következő 4-5 évben az AI és ML alapú megoldások beruházásai - összetett éves alapon mérve - 30%-kal növekedhetnek évről évre. Fontos azonban, hogy ne misztifikáljuk túl e két fogalmat, s ne ragadja túlságosan magával a fantáziánkat az ezeket körüllengő hype. Ígéretekkel tele a padlás, ám ettől még a jelenlegi lehetőségek nem felelnek meg a piac túlméretezett elvárásainak. A döntéshozóknak fokozottan kell vigyázni a különböző gyártói megoldások és ígéretek között arra, hogy az AI-t és a ML-et ne tekintsék önmagukban az egyre inkább növekvő szakemberhiány kiváltására alkalmas csodaszernek. Bár a mesterséges intelligencia és a gépi tanulás - illetve az automatizált rendszerek - kritikussá váltak a kibervédelem szempontjából, ennek oka - bármilyen egyszerűen hangzana is - elsősorban nem a szakemberek hiányára vezethető vissza.

Sokkal kézzelfoghatóbb indok, hogy a gépi tanulással a különböző végpontvédelmi, határvédelmi, viselkedéselemzési rendszerek könnyebben és hatékonyabban elemezhetik a mintákat és tanulhatnak belőlük, hogy megelőzzék a hasonló elveken működő támadásokat, illetve képesek legyenek reagálni a változó viselkedési faktorokra. Egy öntanuló és finomhangoló rendszer segíthet abban is, hogy kiberbiztonsági csapatok proaktívan tudjanak fellépni a különböző fenyegetések megelőzésekor, és ami még ennél is sokkal fontosabb: az aktív támadások valós időben történő egyszerűbb és hatékonyabb detektálását és reagálási képességeit fokozzák.

Emellett az automatizációs megoldások segítséget jelentenek azzal, hogy képesek csökkenteni a rutinfeladatokra fordított időt, s lehetővé teszik a szervezetek számára, hogy rendelkezésre álló erőforrásaikat stratégiailag jobban felhasználhassák.

1_4.jpg

Az adatok szerepe a mesterséges intelligencia és a gépi tanulás szempontjából

A gépi intelligencia és tanulás első számú hajtóereje az óriási mennyiségű adat, valamint az adatok megfelelő osztályozásának és tisztításának szükségessége. A legtöbb mesterséges intelligenciára építő vagy gépi tanulásra hagyatkozó megoldás teljesen haszontalan, amennyiben nem képesek hozzáférni az adatkészletek különböző osztályaihoz, telemetria adatokhoz, vagy épp metaadatokhoz.

A gépi tanulás a minták szofisztikált kidolgozásáról és ezen minták algoritmusokkal történő manipulálásáról szól. A különböző ML minták kifejlesztéséhez és finomhangolásához rengeteg - a mindennapokból származó - információra van szükség, hiszen ezeknek az adatoknak a lehető legtöbb lehetséges forgatókönyvet kell megalapozniuk. Ráadásul nem csupán az adatok mennyisége fontos. Ugyanilyen kritikus tényező azok minősége is! Az összegyűjtött információknak teljesnek, relevánsnak, kontextusokban gazdagnak kell lennie.

Ezek az adatok származhatnak végpontokról, hálózati megoldásokból, vagy akár felhőszolgáltatásokból is, de mindegyik esetben összpontosítani kell a megfelelő tisztításukra, hogy ezáltal értelmet kapjanak és meghatározható legyen az eredmény.

Nem csodaszerek, de hatékony eszközök

Mint minden új technológiánál, úgy az AI és a ML esetében is ki kell forrnia az igazán nagy lehetőségeknek. Ezek a megoldások jelenleg - a legtöbb esetben legalábbis - valószínűségekkel foglalkoznak, matematikai modellek és algoritmusok alapján. Egy AI/ML megoldást kínáló gyártó esetében itt arról van szó, hogy önmagukban nem rendelkeznek teljes bizonyossággal arról, ténylegesen rosszindulatú programmal van-e dolguk, vagy csak nagy a valószínűsége annak, hogy egy kód rosszindulatú.

Mindezek ellenére az AI, illetve azon belül a ML, hosszútávon nélkülözhetetlen és hasznos a kibervédelmi stratégia fejlesztésében, a folyamatok tervezésénél. A gépi tanulás már bizonyította, hogy a sikeres támadások számát jelentősen képes lecsökkenteni, így biztosan hatékonyabbá teszi a jelenlegi megoldásokat.

Egy C szintű vezetőnek nem szabad sok időt eltöltenie azzal, hogy megismerje a különböző AI/ML megoldásokat, amelyeket egy CISO alkalmaz egy SOC-ban. Csupán azokkal az alapvető kérdésekkel kell tisztában lennie, amelyekre az AI és az ML segítséget nyújthatnak.

Az üzleti vezetők elsősorban két kérdésre várnak választ:

  • A CISO rendelkezik-e frissített, naprakész, megbízható, bennfentes fenyegetés-észlelési rendszerrel?
  • Növekszik, vagy épp csökken az adathalász kísérletek száma, gyakorisága, sikeressége?

A gépi tanulás pedig nagyban segíthet megválaszolni ezeket a kérdéseket. Az AI és pláne a ML egyelőre nem fogja kiküszöbölni a humán biztonsági elemzők, mérnökök munkáját vagy egy jól felszerelt és hatékony SOC-ot. Viszont kiválóan képes azokat kiegészíteni és érezhetően hatékonyabbá tenni.

2_3.jpg

A téma korábbi cikkét elolvashatja itt.

Iratkozzon fel listánkra, hogy időben értesüljön rendezvényeinkről és cikkeinkről: FELIRATKOZOM

Kövessen minket a LinkedIn-en!

Az RSA Archer automatizálja és tartalommal tölti fel a rutin feladatokat

Hüvelyes Péter cikke

A vállalatok számára a kiberbiztonság és az egyéb kockázatok kezelése szempontjából a legjelentősebb kihívásokat a megfelelő személyzet rendelkezésre állása, a megfelelési követelmények kielégítése, valamint a következetes adatszolgáltatás kötelezettsége jelenti.

blogbejegyzes-archer.jpg

Az RSA által fejlesztett Archer Suite a fentiekben mind segítséget nyújt a feladatok automatizálása, a biztonsági eseményekről készített jelentések, valamint a vállalat egészére vonatkozó egységes rendszertan, munkafolyamatok és mutatók biztosítása által.

Az Archer egy remek eszköz a szervezet saját kockázatainak megértésére, priorizálására és megfelelőségének kezelésére. Egy ilyen szoftver nélkül nagyon nehéz a prioritások meghatározása a rengeteg informatikai biztonsági vagy sebezhetőségi riasztás között. Elég csak belegondolni: Ha egyszerre több száz, vagy ezer biztonsági hibánk van azonosítva, hogyan döntjük el, hogy mivel foglakozzunk először? Hogyan rangsorolhatjuk ezeket kockázat szempontjából? Hogyan tudjuk a leghatékonyabban csökkenteni a kockázati profilunkat?

Véleményünk szerint a szervezetek gondolkodásmódja olyan irányba fejlődik, ahol a digitális kockázatkezelés a legfontosabb, és ez magában foglalja az egész vállalatra vonatkozó kockázatok holisztikus megértését is. Az integrált kockázatkezelés érdekében az RSA megoldása egy egységes, kitűnően konfigurálható, integrált platformot biztosít a kockázat eltérő dimenzióinak kezelésére. A biztonsági csoportok számára a valós idejű és intuitív módon megjelenített pontos információk nyújtásával megkönnyíti egy átfogó kép megértését, és ezáltal a döntéshozatalt. Nem véletlen, hogy a rendszer a Gartner Magic Quadrant integrált kockázatkezelési kategóriájában (IRM / Integrated Risk Management) kategóriájában a vezető negyedbe került besorolásra.

Könnyű emellett egy web alapú felügyeleti csomagként tekinteni a szoftverre, amely gördülékeny munkafolyamatok és jelentéskészítés révén segíti a folyamatok automatizálását, valamint az egyéb biztonsági eszközökről összegyűjtve jeleníti meg az adatokat, a rutin feladatok pedig automatizálhatóak segítségével.

A rendszer számos különféle módszert kínál a kockázat meghatározására, beleértve az egyszerű színkódolást (zöld/sárga/piros) és a különféle képletek alapján meghatározott számszerű kockázatértékelési értékeket. Ezek párhuzamban állnak a szélesebb körben elfogadott kockázatkezelési módszertanokkal, mint például a NIST 800-53, az ISO 31000, a NIST RMF, stb.

1_2.jpg

Az elérendő cél minden esetben a kockázat számszerűsítése; az a képesség, hogy kiszámoljuk a kockázat költségeit. Nem csak a kockázat súlyosságát, hanem azt is, mennyit ér számunkra adott kockázat elhárítása. Ez lehetővé teszi a szervezet számára, hogy költségvetési szempontból kezdjen el gondolkodni a kockázatokról. Ugyanakkor sok szervezet számára ez egy hosszú evolúciós folyamat. A megfelelő működéshez érett kockázatkezelési kultúrára van szükség, aminek elérése nem megy egyik napról a másikra.

A termék kontextust, mögöttes tartalmat rendel az eseményekhez, biztonsági incidensekhez. Olyan kulcsfontosságú kérdésekre ad választ, mint például hogy

  • milyen további eszközök vannak az érintett rendszertartományban,
  • milyen felhasználói csoportoknak vagy programoknak kell tudni használni a tartományt, hogy működőképesek maradjanak,
  • adott eszköz milyen hálózaton működik,
  • ki felel az alkalmazásokért és a rendszerekért,
  • vagy mi lenne a következménye, ha ezeket a rendszereket leállítanánk az incidens hatásának enyhítése érdekében.

Ezáltal segít a Biztonsági Műveleti Központ (Security Operations Center / SOC) munkatársainak az esemény holisztikus megértésében, és hogy a jövőben a reagálásra vonatkozóan jobb döntéseket hozhassanak.

Az Archer egy központi portált is biztosít az SOC munkatársak számára, mellyel az események kivizsgálása teljes átláthatósággal nyomon követhető és kezelhető, valamint jelentéskészítéssel támogatott, a vezetőség számára pedig lehetővé teszi a fő teljesítménymutatók figyelemmel kísérését. A SOC-ban történő felhasználásán túl pedig az adatok különféle eszközökről aggregálása és az összesített nézet létrehozása által segít az informatikai környezet folyamatos megfigyelésében is.

A fent említett előnyök okán is többek közt az USA Belbiztonsági Minisztériuma (Department of Homeland Security) is az RSA Archer-t választotta a kormányzati szintű kiberbiztonsági programjához. Az adatokat az Archer-ben kockázati szempontú pontozással, és számos jelentést előállítva egy szövetségi ügynökségi szintű irányítópultba gyűjtik. A Folyamatos Diagnosztika és Megfigyelés (Continuous Diagnostics and Monitoring / CDM) irányítópultja a kormányzati hálózatok állapotára vonatkozó valós idejű információkkal és a legfontosabb kockázati mutatókat tartalmazó jelentésekkel látja el az ügynökségek vezetõit. A korábban a hálózatok feltérképezése és kezelése céljából telepített eszközöktől (pl. sérülékenység felderítő és konfigurációkezelő eszközök) begyűjtött adatokat központi hub-ként gyűjti össze, lehetővé téve összesített kockázati kép készítését a szervezet bármely szintjén.


2_2.jpg

Az eddig tárgyalt informatikai biztonsági kockázatkezelés (IT Security Risk Management) ugyanakkor csak egyike a megoldáscsomag hét domain-jének. A többi megoldás az üzleti ellenállóképességtől és a működés tervezésének folyamatosságától az ellenőrzés menedzsmentjén, a működési kockázaton és az ellátási lánc irányításán keresztül egészen a szabályozások betartásáig terjed. Közös bennük, hogy minden megoldás a hatékonyságot növeli, mivel nagy mértékben segíti a folyamatok automatizálását és korszerűsítését.

A Business Resilience megoldás segítségével az Archer hozzárendelhető a riasztásokat generáló eszközökhöz, így automatikus figyelmeztetések küldhetők egy valós biztonsági esemény bekövetkezése esetén.

3_2.jpg

A rendszerben beállítható automatikus adatgyűjtés és jelentés készítés. Ez sokkal jövőbemutatóbb a napjainkban a legtöbb szervezetnél elterjedt gyakorlatnál, miszerint a különböző területek egyenként táblázatos kimutatásokat küldenek -akár eltérő formázással-, amelyeket egy munkatárs fáradtságos munkával összesít egy vállalati szintű jelentésbe. A megoldás ezt a manuális feladatot a megfelelőségi jelentések és a kockázatkezelés szempontjából kiváltja.

A vezetői rálátás tekintetében az egységek közötti közös mérési és jelentéskészítési folyamatok által biztosítja a vállalat egészére vonatkozó adatok következetes áttekintését. A vezetők válasza arra a kérdésre, hogy képesek-e a vállalaton belül egységes és következetes módon összegyűjteni és dokumentálni a kockázatokat, túlnyomó részben nemleges a tömör válasz.

Az RSA Archer segít a vezetőknek a teljes vállalati kockázatok megértésében és kezelésében. És itt nem csak a kiber- és informatikai kockázatokra kell gondolni, hanem minden egyéb kockázatra is, mint például a környezeti-, munkaerő- vagy pénzügyi kockázatok, amelyek szintén nagyban befolyásolhatják a vállalati célok sikeres elérését.

A szoftvercsomag egyik kiemelten hasznos eszköze a Kockázat Nyilvántartás (Risk Register), ami segít a kockázatok meghatározásában, a vállalat egészén átívelő következetes dokumentálásukban és egy egységes terminológia és módszertan kialakításában.

4_1.png

Ezt követően elősegíti a megfelelő szabályzatok és kontrollok kockázatokhoz rendelését is.

Az egymásra épülő eltérő funkcionalitások kihasználása szinergikus. Például a sérülékenység vizsgálat eredményei a rendszerekhez rendelhetők, és ekkor döntéstámogatással segíti az újonnan megjelenő sebezhetőségekre való reagálást.

A szoftver könnyen integrálható, és kitűnően testreszabható. Használható "dobozos" megoldásként is az iparági legjobb gyakorlatok szerint előre kialakított folyamatokkal, de egyedi igények és meghatározott folyamatok alapján is könnyen konfigurálható. Implementáció tekintetében a szervezet saját hardverén, vagy szolgáltatásként is igénybe vehető.

A jövő

Jelenleg még a rendszer nem hoz automatizált döntéseket, egyelőre csak információk nyújtásával segíti az emberi döntéshozatalt. Egy valós biztonsági esemény esetén például az adott menedzsernek kell megtennie a szükséges lépéseket a riasztás kiküldésére.

Ugyanakkor elmozdulás látszik az automatizált döntéshozatal irányába. Ahogy az RSA fogalmaz: "Jelenleg elsősorban információkat szolgáltatunk. Például a rendszer nem alkalmazza a javítást, viszont figyelmeztetést küld a biztonsági menedzsereknek, akik alkalmazzák a patch-et. Ugyanakkor végeztünk mesterséges intelligenciával kapcsolatos fejlesztéseket, ez a funkcionalitás hamarosan elérhetővé válhat."

Véleményünk szerint a közeljövőben ezen a területen az Archer kiválthatja az emberi munkavégzést.

A megoldás mögötti háttér

Az RSA már 1977 óta világviszonylatban is az egyik legismertebb kiberbiztonsági szereplőnek számít, amióta az alapító három tudós - Rivest, Shamir és Adleman akik nevének kezdőbetűiből áll össze a cég neve - egy új típusú titkosítást írtak le.

Az RSA termékportfóliójába a GRC rendszer az Archer Technologies 2010-es felvásárlásával került be. Nagyobb szervezetek körében -mind az állami, mind a versenyszférában - széles körben használt eszköz. Globálisan több mint 1500 nagyvállalat (bankok, kereskedelmi- és telco cégek) tartozik a felhasználói ügyfélkörbe, köztük a Forbes 100-as listán szereplő cégek fele.

Az EURO ONE Számítástechnikai Zrt. az RSA egyetlen magyarországi Securworld Titanium minősítésű partnere, mely viszonteladóként a megoldás beszerzésében, majd teljes körű implementálásában, testre szabásában segítséget tud nyújtani.

Iratkozzon fel listánkra, hogy időben értesüljön rendezvényeinkről és cikkeinkről: FELIRATKOZOM

Kövessen minket a LinkedIn-en!

 

Gépi tanulás és mesterséges intelligencia: meséből valóság?

Krékity Gusztáv cikke

2020. augusztus 28. - EURO ONE

Míg pár évtizede a mesterséges intelligencia (Artificial Intelligence , AI) még csak a tudományos-fantasztikus regények izgalmas lehetősége volt, mára szinte a mindennapi valóság részévé vált, kiegészítve a gépi tanulás fogalmával (Machine Learning - ML). Egyre több alkalmazásban találkozhatunk az AI és ML megoldásokra építő funkciókkal. Előszeretettel alkalmazzák például az olyan képszerkesztőkben, mint mondjuk az Adobe okostelefonokra PS kamera alkalmazása, vagy a Luminar, amelyek felhasználói beavatkozás nélkül képesek kielemezni egy fotó tartalmát, hogy aztán annak megfelelően cseréljék le az égen a nappali felhőket az éjszakai égbolt csillagaira, retusálják az arcokat, vagy módosítsák a fényelési beállításokat. De ennél komolyabbnak tűnő megoldásokban is alkalmazzák őket, így például olyan robotokban, eszközökben is helyet kapnak, amelyek a gépi tanulásnak köszönhetően képesek a viselkedésüket, működésüket az adott céloknak megfelelően, ráadásul megismételhető módon (a korábbiakból tanulva) változtatni. S persze a legkézenfekvőbb, hétköznapi példa nem is lehetne más, mint az önvezető autók, amelyek igen jó utón haladnak ahhoz, hogy előbb-utóbb bárki számára elérhetővé váljanak. Itt a mesterséges intelligencia rengeteg adatot dolgozhat fel egy út során, a gépi tanulás pedig segíthet, hogy a kialakult helyzetek alapján egyre nagyobb megbízhatósággal röpítsenek minket a jövő “K.I.T.T.-jei” az úticélhoz. De ott vannak ezek a technológiák az arc- és beszédfelismerésben, a kézírás felismerésében, orvosi diagnosztikai eszközökben stb. S ha ennyi helyen fel lehet használni e két megoldást, miért pont a kiberbiztonság területén ne vennénk hasznukat? Csak tudnunk kell, hogy pontosan miről is beszélünk, amikor e két fogalmat emlegetjük.

AI és ML a kiberbiztonságban: egyre hétköznapibb dolgok

A mesterséges intelligencia és a gépi tanulás kiberbiztonsági felhasználása egyre több terméknél valósul meg. Nem csak a szervezetek kiberbiztonsági megközelítése tolódik az ilyen irányú korszerűsítések felé, hanem egyszerű, átlag felhasználók által elérhető víruskereső szoftverekben is egyre másra bukkannak fel például a ML elemek. Így például az antivírusok egy része a korábbi kártevők veselkedése, jellemzői alapján igyekszik beazonosítani a még ismeretlen fenyegetéseket, folyamatosan tanulva az önállóan felfedezett esetekből is.

Természetesen a vállalatok szempontjából is fontosak lehetnek, hiszen e két egymással összefüggő megoldás képes leegyszerűsíteni a biztonsági műveleteket, növelni a hatékonyságot és csökkenteni a biztonsági kockázatokat azáltal, hogy segíti a biztonsági elemzőket az ismert és ismeretlen támadások felderítésében. Ezen előnyöknek az ismeretei mellett nem meglepő, hogy az IT biztonsági területen az AI megoldások piaca 2025-ig várhatóan több mint 30%-ot növekedhet éves szinten és 2025-ig elérheti a 34,8 milliárd dollárt. Mielőtt azonban egy cég kiaknázhatná az AI/ML megoldások előnyeit fontos néhány dolgot megérteni!

Mit értünk gépi tanulás alatt?

Sok különböző definíciót használhatunk a gépi tanulás leírására, de ezek alapvetően ugyanazt jelentik. A Stanford University határozta meg talán a legjobban eddig:

„A gépi tanulás azon tudás, hogy a számítógépeket kifejezetten programozás nélkül tudjuk működtetni.”

A gépi tanuláshoz rengeteg minőségi adatra van szükség, amelyeket kombinálhatunk az ML által használt algoritmusok segítségével. Ezek az algoritmusok az adatok elemzéséből képesek tanulni, s ez lehetővé teszi a különböző ML alapú megoldás számára, hogy előrejelzéseket készíthessen olyan teljesen új adatokról, amelyeket még soha nem látott és nem is tud semmilyen előzetes mintához illeszteni. Annak érdekében, hogy a kiválasztásra került adatparamétereket biztosíthassuk, három kérdést kell feltenni az illetékes csapatoknak:

1.           Látható minden?
Az adatokat bármikor, bárhonnan látnia kell a rendszernek (felhő, Hálózat, végpont)

2.           Milyen gyorsan képes a rendszer elemezni az adatokat?
Miután megállapítjuk és meghatározzuk, hogy milyen adatokat és kontextusokat láthat a megoldás, azt is ki kell deríteni, milyen sebességgel képes az adatok feldolgozására.

3.           Van automatizált válaszadási képesség?
Ki kell deríteni, hány embert és mennyi időt igényel egy incidensre való reagálás. Ha nincs automatizált válaszadási képesség az ML vagy AI alapú megoldásban, akkor hosszútávon növekvő kockázattal kell kalkulálni. Ha több emberre és eszközre van szükség az adatok kézi értelmezéséhez, és a válaszok, illetve a jövőbeni védelem érdekében történő felhasználásához, akkor nem használja ki az adatokat, nem maximalizálja a gépi tanulást, és nem egyszerűsít semmit.

Mit jelent a Mesterséges intelligencia (AI)?

A mesterséges intelligencia ugyanolyan gondosságot és figyelmet igényel az adatok gyűjtésére és -kezelésére, mint a gépi tanulás, tehát hasonló kérdések vonatkoznak az AI maximalizálása érdekében, a műveletek egyszerűsítése és a kockázat csökkentése érdekében. De a mesterséges intelligencia egy szélesebb körű fogalom, mint a gépi tanulás, így eltérő előnyökkel jár a szervezet számára.

AI vs ML: a főbb különbségek

A gépi tanulást és a mesterséges intelligenciát gyakran felcserélhető kifejezésekként használják a szaknyelvben, pedig nem ugyanazt jelentik! Kapcsolatban állnak egymással abból a szempontból, hogy az ML részhalmaza az AI-nak, ám igencsak eltérők a képességeik. Az üzleti, informatikai és IT biztonsági döntéshozók kialakíthatnak egy elvárási specifikációt arra vonatkozóan, mi az ami megvalósítható ezekkel a megoldásokkal, s milyen korlátai vannak a két módszernek. Mind az AI, mind az ML bevezetése egy szervezetbe rendkívül pozitív előnyökkel járhat, de csak akkor, ha a megfelelő, minőségi adatokkal látjuk el őket. Ez azt jelenti, hogy teljes, releváns és kontextusban gazdag adatokra van szükség, amelyeket az algoritmusok hatékonyan feldolgozhatnak és kiértékelhetnek.

Annak érdekében, hogy az ML és az AI egyszerűsítse a biztonsági műveleteket és biztonságosabbá tegye a szervezet működését a biztonsági fenyegetésekkel, kockázatokkal szemben, nagyon fontos megérteni a két kifejezésben rejlő képességeket, hasonlóságokat és különbségeket.

   A mesterséges intelligencia (AI) egy roppant széles tudományág, melynek célja az emberihez hasonló kognitív képességek (például tanulás, problémamegoldás, kvázi intelligencia) imitálása számítógépek segítségével.

   A gépi tanulás (ML) egy részterület az AI-n belül. Az ML célja, hogy lehetővé tegye a gépek számára, hogy maguk tanuljanak a megadott adatok felhasználásával és minél pontosabb előrejelzéseket készítsenek.

Nem mindegy tehát, hogy a két megoldás közül melyiket nevezzük ki megvalósítandó célként. A mai szoftverek java része egyelőre a gépi tanulás útján halad, vagyis elsősorban a meglévő adatok alapján igyekeznek megoldást találni a feladatuk elvégzésére, viszont e folyamat során állandóan képesek tanulni a már feldolgozott információkból, így a későbbiekben a tanultakat is hasznosíthatják az újabb és újabb adatfeldolgozások során. Visszatérve a bevezetőben felvetett képszerkesztős példához, a ML alapon működő szoftver egy idő után egyre kevésbé dől majd be a vízfelületen tükröződő felhőknek az égbolt automatikus cseréjekor. S ugyanígy egy biztonsági szoftver is egyre nagyobb magabiztossággal veheti fel a harcot a ML segítségével az újonnan megjelenő kártevőkkel és támadási módszerekkel szemben, hiszen a kapott alap információkat folyamatosan képes kiegészíteni a tanult adatokkal. De attól, hogy a kapott és tanult adatokból képesek általánosítani, szabályok alapján elvégezni a feladatukat, még továbbra sem alakulnak egy sci-fiből előpattant, az AI lehetőségeit végsőkig kihasználó androiddá, amelyik miután lejárt a munkaideje, leugrik a boltba is bevásárolni nekünk, este pedig elmeséli, mi minden történt aznap a munkahelyén, megoldja a gyerekkel a házifeladatot, összeüt egy gyors vacsit, másnap pedig betipeg újra a hús-vér adminok közé dolgozni. A ML tanulási képessége nem egyenlő egy létrehozott tudattal vagy mesterséges intelligenciával. Mi viszont ettől még nagyon nagy hasznát vehetjük ennek a technológiának, így van miért örülni annak, hogy az utóbbi években irgalmatlan gyorsan terjed. Előbb utóbb pedig biztosan túllépnek a biztonsági szoftverek is azon, hogy pusztán a gépi tanulásra hagyatkozzanak, s kihasználják majd a AI technológia többi lehetőségét is.

A cikket hamarosan folytatjuk. Iratkozzon fel listánkra, hogy időben értesüljön rendezvényeinkről és cikkeinkről: FELIRATKOZOM

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

Bikki Mónika cikke

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

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