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

EURO ONE

Vezeték nélküli rendszerek okos és hatékony megtervezése

Krékity Gusztáv cikke

2022. február 15. - EURO ONE

Az informatika meglehetősen szerteágazó témakör. Itt a blogban eddig csak az IT biztonság kérdéseire kerestünk megfelelő és naprakész válaszokat. Ám a későbbiekben szeretnénk egy kicsit szélesíteni a palettát, s ezt egy - amúgy a biztonsághoz is erősen kapcsolódó - témával kezdjük: a hálózatokkal.

vezetek-nelkuli-rendszerek-.jpg

Kezdetnek azt vizsgáljuk meg, miként lehet megteremteni a feltételeket egy jól működő, megbízható, a jövő változásaihoz is könnyen alkalmazkodó, stabil vezeték nélküli hálózat kialakításához az irodában. Mi mindent kell megvizsgálni, kiértékelni, figyelembe venni ahhoz, hogy sikerrel járjunk, amikor kiépítünk egy ilyen infrastruktúrát, amely immár alap elvárás a modern világban, szinte bármely cégnél.

Ám dacára annak, hogy az irodai munka egyik alapvető pilléréről beszélünk, még mindig gyakran tapasztaljuk, hogy a vállalati környezetben dolgozók elégedetlenek a vezeték nélküli belső hálózattal vagy épp az internet-kapcsolatok sebességével és megbízhatóságával. A munka e fontos és nélkülözhetetlen eleme a legtöbb esetben sok sebből vérzik, ami sokszor köszönhető a - tervezési hiányosságok miatt - rosszul kialakított alap kiszolgáló környezetnek, vagy az elavult és korszerűtlen rendszerek használatának. Mindezek biztonsági szempontból is magas kockázati tényezőt jelentenek (erre később részletesen is kitérünk majd egy önálló cikkben).

Az IoT és a BYOD világában már szinte minden vezeték nélkül kapcsolódik a céges hálózatra, s ugyanígy az internet vezetékmentes elérése is elengedhetetlen. Viszont a hatékony vezeték nélküli hálózat első lépése a megfelelő tervezés. A wifi kialakítás megtervezése a vezeték nélküli hálózat vázaként szolgál, így amennyiben időt szánunk megfontolt kidolgozására, az összetevők megismerésére, a szükséges lépések megértésére, illetve alkalmazzuk a már bevált gyakorlatokat, akkor nem csak a hálózat megbízhatóságát és teljesítményét növelhetjük meg, hanem hosszú távon pénzt és erőforrást is megtakaríthatunk.

Mit nevezünk vezeték nélküli (wifi) tervezésnek?

Wifi tervezésnek azt a folyamatot nevezzük, amely során figyelembe kell venni a vállalkozás egyéni és specifikációs igényeit, követelményeit, majd ennek megfelelően megtervezni a nagyteljesítményű és megbízható hálózatot. Az üzleti követelmények között meg kell határozni többek között, hogy mennyi és milyen típusú eszköznek van szüksége a vezeték nélküli hálózatra (ez lesz a kapacitás), illetve hol van szükség jó minőségű jelszintre az irodában (ez lesz a lefedettség). Eme két tényező alapján lehet kialakítani egy tervezetet az AP-k típusáról és elhelyezéséről, meghatározva, hogy hová, mit kell telepíteni a megfelelő lefedettség és jelszint eléréséhez.

Miért fontos a vezeték nélküli hálózatok megfelelő megtervezése és előkészítése?

Örökérvényű igazság - és sajnos nem csak ebben az esetben -, hogy csak akkor vesszük észre a vezeték nélküli hálózatokat, amikor épp nem működnek. Mindannyian érezhettük már a rosszul működő wifi hálózatok okozta frusztrációt, ami meglehetősen gyakran tapasztalható a mai irodai, ipari, szállodai, nagyvállalati környezetben. Az elmúlt években világszerte csaknem 200 millió olyan vezeték nélküli hálózatról számoltak be, amelyek nem megfelelően és nem kellő hatékonysággal működnek, ráadásul IT szempontból hosszú távon nem fenntarthatók, mivel egyszerűen képtelenek minimális vagy növekvő interferencia mellett optimálisan lefedni a szükséges területeket, s kiszolgálni a kapacitásra vonatkozó követelményeket. A rossz vezeték nélküli rendszerek létrejöttének egyik leggyakoribb oka: a pontatlan vagy elnagyolt tervezést követő kialakítás.

A jó és stabil vezeték nélküli hálózat - miként többször is említettük már - létfontosságú a modern irodai és termelési környezetekben. A szervezetek és az emberek egyre növekvő mértékben támaszkodnak munkájuk során a vezeték nélküli hálózatokra, így ha a wifi nem működik megfelelően, akkor a munka a szó szoros értelmében leáll, vagy legalábbis veszít hatékonyságából. A rossz tervezés hosszútávon nem csak negatívan befolyásolja a teljesítményt, de a hibák keresése és a panaszok rendszeres felülvizsgálata, kiértékelése egyben rengeteg IT erőforrást is felemészt. Arról nem is beszélve, hogy ha a termelés és a munkafolyamatok nem optimálisak, az bizony bevétel kieséssel járhat.

Manapság már léteznek professzionális mérő berendezések és műszerek, amelyek lehetővé teszik a tervezés hatékonyságának maximalizálását, modellezését és biztosítják, hogy a tervezési folyamatot követően - miután megtörténik az új rendszer installációja - az első naptól kezdve egy megbízható és költséghatékonyan üzemeltethető kiszolgáló környezetünk legyen, ami az IT ráfordításokat is csökkentheti (idén lesz még szó nálunk a mesterséges intelligencia által támogatott okos rendszerekről is, amelyek tovább növelhetik az üzemeltetés hatékonyságát).

Az üzleti és rádiófrekvenciás követelmények fő kérdései

A jó tervezés mellett pontosan meg kell határozni, hogy milyen üzleti igényeket támasztunk az új vezeték nélküli rendszerrel szemben, s itt fontos, hogy ne csupán az aktuális, jelenlegi igényeket mérjük fel, hanem arról is képet alkossunk, hogy a következő években milyen igények és elvárások merülhetnek fel a rendszerrel kapcsolatban. Amennyiben előre tudunk gondolkodni, úgy sokkal jövőt állóbb vezeték nélküli infrastruktúrát tudunk megtervezni, hiszen senkinek sem célja, hogy két-három évente cserélje a rendszereit, mert azok nem tudják kiszolgálni a változó igényeket.

Fontos, hogy az alábbi kérdésekre mindenképpen legyen válaszunk:

  1. Milyen eszközök kapcsolódnak majd a hálózathoz?
  2. Hány végpontnak lesz szüksége egyidejű kapcsolódásra?
  3. Melyek azok a végpontok, amelyeknél kritikusan fontos a szervezet számára, hogy vezeték nélküli kapcsolattal rendelkezzenek?
  4. Melyek a legfontosabb területek, amelyeknél a legnagyobb szükség van a minőségi és jó lefedettségre?
  5. Szükséges-e felügyelt vendég hálózatot szolgáltatni?
  6. Milyen egyéb ügyfél specifikus igények merülnek fel?

Viszont nézzük, milyen szempontokat veszünk mi figyelembe, amikor az ügyfelek segítséget kérnek tőlünk egy új rendszer megtervezésében, illetve a rendszerintegrációt megelőző fejlesztési terv előállításában.

Megfelelő területi lefedettség

Az egyik legalapvetőbb szempont egy vezeték nélküli rendszer tervezése esetén, hogy minden szükséges információt derítsünk ki arról, hol lehet szükség vezeték nélküli hálózatra. Elsődleges szempontnak tekinthető, hogy jó minőségű és kellő mértékű lefedettséget érjünk el új rendszerünkkel a kívánt területeken. A tervezés során megfelelő mennyiségű és jól pozícionált AP-k (hozzáférési pontok) segítségével tudjuk elérni és optimalizálni a kívánt jelerősséget a vezeték nélkül kapcsolódó rendszerek kiszolgálására. Fontos a jó tervezés, amihez az AP pozícionálás során figyelembe venni az átlapolási lefedettséget vagy a másodlagos lefedettség rétegződését - 2.4 GHz és 5 GHz illetve manapság 6 GHz esetén is - a kapcsolatok stabilitásához és a megfelelő roaming eléréséhez. Fontos meghatározni azokat az üzleti szempontból is kritikus területeket amelyeknél kiemelten fontos a vezeték nélküli infrastruktúra, s ezekre a pontokra érdemes redundánsan tervezni a meghibásodások esetére. Amennyiben nem megfelelő a tervezés, akkor előfordulhat túl sűrű AP telepítés, ami a projekt beruházási költségének növelése mellett interferenciát is okozhat a közegben, vagy épp túl kevés AP elhelyezésével a jelszint nem lesz megfelelő, így lefedettségi hézagok - úgynevezett szürke zónák - alakulhatnak ki a vezeték nélküli telepítést követően.

Tervezéskor mi első lépésként egy professzionális mérőberendezés segítségével felmérjük a meglévő környezet gyenge pontjait, a közeg interferenciát, a jel-zaj viszonyt, majd az eredmények alapján javaslatokat készítünk az AP-k újrapozícionálására, feltéve, hogy ez szükséges.

Zöldmezős beruházás esetén szintén egy professzionális mérő berendezést alkalmazunk, de mivel ebben az esetben nincs olyan környezet, amit fel lehetne mérni, így egy mérő bőröndöt is a helyszínre viszünk, melynek segítségével szimulálhatjuk az AP-k telepítési pontját. Ebből megállapítható, hogy hova és hány AP telepítésére lesz szükség a jövőben.

Kapacitástervezés és AP méretezés

A kapacitástervezés már egy lépéssel túlmutat a lefedettségen és figyelembe veszi a hálózathoz csatlakozó klienseket, illetve az alkalmazás igények típusait és számát is. A vezeték nélküli hálózat kapacitási igényének meghatározása az egyidejűleg támogatott kliensek számának, a forgalom mennyiségének mérése az igénybe vett sávszélesség alapján. Amennyiben rosszul határozzuk meg a kapacitási szükségletet, annak a későbbiekben nagyon súlyos következményei lehetnek a felhasználók számára. A lassú sebesség, a kapcsolódási problémák, a megbízhatatlan vezeték nélküli hálózat mind adódhatnak abból, hogy nem a megfelelő használati követelményekhez mérten határoztuk meg a hozzáférési pontok kapacitását.

Az ügyfeleknek a tervezés e fázisában rendszerint az igényeikhez leginkább szükséges és hosszútávon skálázható AP megoldásokat szoktuk javasolni, hogy a későbbi növekvő igényekre is megfelelő megoldást tudjanak választani.

Kritikus eszközök meghatározása

A vezeték nélküli hálózathoz kapcsolódó különféle típusú kliensek áttekintése szintén nagyon fontos a tervezés során, illetve meg kell határozni az üzleti szempontból kiemelten fontos kritikus végpontokat is. Ezek azok az eszközök, amelyek offline állapotba kerülésekor leáll a cég működése és ellehetetlenülnek a munkafolyamatok. Fontos figyelembe venni ezen eszközök életkorát és technológia érettségét egyaránt, hiszen olyan megoldást kell választani, amely ezen eszközöket is megfelelően képes kiszolgálni. Ilyen pont lehet például:

  • A CEO laptopja, amelyet már évek óta nem hajlandó lecserélni, de az új vezeték nélküli szabványokat nem támogatja.
  • Raktári környezetben egy 10-12 éves szkenner, amely napi 12-16 órát van használatban, de a beépített antenna már elavult és optimalizálni kell a teljesítményt, hogy a lehető leghatékonyabban működjön az új rendszer mellett is a kissé avitt technológia.

Rendszerint készítünk egy listát az ilyen eszközökről és tanulmányozzuk, hogy a gyártó milyen specifikációkat publikált, így megbizonyosodhatunk arról, hogy az új rendszer mellett megbízhatóan fognak működni ezek a létfontosságú, ám esetleg elavultabb berendezések is.

Fizikai akadályok és AP elhelyezés

A fizikai környezet kritikus szerepet játszik a vezeték nélküli hálózat működésében. Minden ügyfél esetében előfordulhatnak egyedi sajátosságok, például extra magas mozgatható polc szerkezetek, fémszerkezetű nagykiterjedésű berendezések, extra fényes vagy épp matt felületek, amelyek a jel torzulásához, töréséhez vagy épp elnyeléséhez vezethetnek. Ezeket az akadályokat a tervezés során figyelembe kell venni és az AP pozicionálását ezen sajátosságok figyelembevételével kell kialakítani.

Az alaprajz a prediktív tervezéshez és az aktív tervezéshez is elengedhetetlen, de ugyanilyen fontos minden esetben körbejárni és megismerni a lefedendő helyszínt, megismerni a helyi sajátosságokat. A faltípusokat, falvastagságokat is figyelembe venni, hogy tudjuk, milyen reflexiós tényezőkkel kell kalkulálni a tervezés során. Ugyancsak fontos a helyszín megismerése, hogy felül tudjuk vizsgálni a kábelezés kialakításának és megvalósíthatóságának a feltételeit is.

Reflexiós tényezők

Az imént már említettem, de mert ez a tervezés egyik kritikus pontja, így megérdemel egy külön bekezdést és bővebb kifejtést: a vezeték nélküli rendszerek tervezése során fontos, hogy minden esetben vegyük figyelembe a tervezési és fejlesztési környezet falainak méretét, vastagságát, anyagát, alakját is ahhoz, hogy a megfelelő jelcsillapítási tényezőkkel kalkulálhassunk. Minden faltípus rendelkezik egy csillapítási tényezővel. Ez azt jelenti, hogy a rádiófrekvenciás erősséget részben vagy teljesen elnyelheti a közeg. A gipszkartonról például általánosan elmondható, hogy 3 dB jelszint csökkenést okozhat, viszont a nagy sűrűségű és vastag betonfalak, oszlopok akár teljesen, vagy nagymértékben tudják tompítani, blokkolni a jeleket. Így ilyen esetben az adott területre külön AP-t kell tervezni a megfelelő lefedettséghez.

kep1.png

A tervezés során - legyen szó meglévő hálózat fejlesztéséről, cseréjéről, vagy akár új beruházásról - minden esetben egy helyszíni felmérést szoktunk végezni a helyszíni sajátosságok figyelembevételével, így a lehető legoptimálisabban tudjuk megtervezni az új vezeték nélküli rendszereket.

RF spektrumaktivitás

Mivel a vezeték nélküli hálózatok a szabad közegben terjednek, így nagyon fontos a tervezés során a lehető legtöbb, a közegben található spektrumtevékenységet megérteni és figyelembe venni. Így például:

  • Csatornakiosztás és versengés: Az AP-k elhelyezése mellett érdemes megtervezni azt is, hogy milyen csatornákon fogják szórni az adott jelet. Ehhez érdemes csatorna kiosztási tervet készíteni amennyiben az AP-k egymás között nem tudják lekommunikálni, hogy ki milyen csatornát használ majd, mint például a 2.4 GHz esetén jellemzően az 1-es, 6-os, 11-es csatornák.
  • Közeg interferencia: Figyelembe kell venni, hogy az a környezet amelyet lefednénk, milyen interferenciális sajátosságokkal rendelkezik, amelyek befolyásolhatják a vezeték nélküli rendszer stabilitását. Ilyen lehet például, hogy az adott környezet hol található egy nagyvároson belül (ipari területen, külvárosi raktárban stb.), hiszen nem ugyanazok lesznek a zavaró környezeti kihatások. Továbbá figyelembe kell venni a mikrohullámú sütőket, Bluetooth eszközöket, mozgásérzékelőket, nagyfeszültségű vezetékeket és sok egyéb specifikus tényezőt, amelyek időszakosan vagy hosszútávon zavarhatják a kapcsolati minőséget és az adatátvitelt.
  • Csatorna szélesség: Minél nagyobb a csatorna szélessége – Channel Widths - annál nagyobb az áteresztő képesség. Az egyénspecifikus RF környezettől és az AP sűrűségtől függően meghatározható a kívánt csatorna szükséglet is.

Most, hogy végigevettünk néhány olyan, a tervezési folyamat során nélkülözhetetlen és mindenképpen fontos tervezési pontot, amelyek nélkül nehezen lehet a számunkra optimális vezeték nélküli infrastruktúrákat telepíteni, foglaljuk össze, hogy milyen követelményeket kell mindenképpen meghatározni és összeszedni ahhoz, hogy egy rendszerintegrátor hatékonyan tudjon tervezni és segíteni az új rendszer telepítése során:

  • Legyen meghatározva, hogy pontosan hol kell lefedettség, legyen alaprajz, amely alapján tervezhető lesz az AP-k pozícionálása
  • Legyenek, összegyűjtve milyen klienseket kell kiszolgálni és melyek a kritikus eszközök, amelyeknek a lehető legstabilabb kapcsolatra van szüksége
  • Fontos tudni, hogy hol milyen kliens-sűrűséggel kell kalkulálni
  • A helyszín bejárása elengedhetetlen, hogy megállapíthatók legyenek az egyéni és környezet specifikus környezeti tényezők (reflexiós pontok, falak, kábelezési lehelőségek)

Mint a fentiekből kiderülhetett, az új rendszer alapjainak kialakítását és az eszközök méretezését, megtervezését érdemes minden esetben szakemberekre bízni, hiszen így üzemeltethetőbb és működőképesebb rendszer áll majd a rendelkezésünkre, amely hosszú távon kifizetődőbb és költséghatékonyabb is.

A GRC lényege és funkciói

Tóth Tamás cikke

2022. február 01. - EURO ONE

Minden időszaknak megvannak a maga népszerű hívószavai, témakörei. Nincs ez másként az IT biztonság területén sem, ahol jelenleg egyre többen szembesülnek a Governance, Risk, and Compliance, vagy röviden GRC fogalmával. Elsőre elég rejtélyes dolognak tűnik, így arra gondoltunk, részletesen kifejtjük, miről van szó valójában, s melyek a GRC általános szervezeti funkciói. Ebben a cikkben több mérvadó nemzetközi forrás felhasználásával mutatjuk be e funkciók lényegét.

governance-risk-compliance.jpg

Maga a GRC, mint fogalom 2002-ben jelent meg. Elsőként Michael Rasmussen használta a Forrester Research kutatások kapcsán. Elmondása szerint a SOX megfelelés kapcsán merült fel a kifejezés, de azóta a GRC evolúciójának több jelentős állomása is volt már.

Az OCEG GRC Capability Model

A GRC egy mozaikszó, amely a Governance, Risk, and Compliance szavakat jelöli. Ez magyarul a vállalatirányítási, kockázatkezelési és megfelelési szervezeti funkciókat jelenti. Ha a Governance, Risk, and Compliance (GRC) fogalmát kell meghatározni vagy hasonló kontextusban szóba kerül e három betű, akkor nem lehet elmenni az Open Compliance and Ethics Group (OCEG) féle GRC Capability Model (v3) koncepciója mellett, amely új perspektívába helyezte a GRC-t.

Fontos megjegyezni, hogy a legtöbb alkalommal, amikor GRC-ról beszélünk, akkor nem az OCEG koncepciója szerinti - silók lebontását célzó és úgynevezett “principled performance” elérését vizionáló - GRC koncepciót értjük alatta, hanem a szervezetek hagyományos GRC funkcióira gondolunk, amelyek már az OCEG elgondolása előtt is létezetek és működtek. Éppen ezért e cikk további fejezeteiben a hagyományos GRC funkciókat elemezzük.

Az OCEG GRC Capability Model megalkotta a "principled performance" fogalmát, amelynek nincs magyar nyelvű megfelelője. Ennek víziója az üzlet olyan megközelítése, amely segít a szervezeteknek céljaik megbízható elérésében, miközben a bizonytalanságot kezelik és tisztességesen járnak el:

„Principled Performance: a point of view and approach to business that helps organizations reliably achieve objectives while addressing uncertainty and acting with integrity.”

Az OCEG felfogása szerint a GRC mozaikszó által jelölt kritikus képességek (critical capabilities), a modellben foglalt lépések, illetve ezek megfelelően integrált alkalmazása szükségesek ahhoz, hogy egy szervezet részei együttműködjenek és elérjék a principled performance víziójának célkitűzését. Emiatt a GRC fogalmát gyakran a principled performance definíciójával azonosítják.

kep1.jpg

kep3.jpg

Az OCEG fenti illusztrációi megfelelően szemléltetik, hogy a principled performance elérését - leegyszerűsítve - a szervezeti silók akadályozzák. A szervezeti egységek nem egységesen, hanem eltérő módon működnek, külön jelentenek, nem használják következetesen a közös fogalmakat, ami gyengébb hatékonyságot és költséges működést eredményez. A GRC Capability Modelben foglalt lépésekkel viszont megszüntethetők a silók és integrálni lehet a különálló szervezeti egységeket. Az embereken és a folyamatokon túl technológia is szükséges a megvalósításához, amiben a GRC platformok nyújtanak segítséget.

GRC egyes elemeinek értelmezése

Governance

A (corporate) governance témájában a King IV Report on Corporate Governance az egyik legismertebb dokumentum, amely meghatározza vállalatirányítás fogalmát és összegyűjti annak elemeit, valamint bevált gyakorlatát. A King IV szerint a vállalatirányítás „az irányító testület etikus és hatékony vezetési gyakorlata az irányítási eredmények elérése érdekében: etikus kultúra, jó teljesítmény, hatékony kontroll, legitimitás”.

A vállalatirányítást az irányító testület és a menedzsment végzi:

  • Az irányító testület leggyakrabban a board of directors (röviden board), amelyet magyarul igazgatótanácsnak fordíthatunk és a tagjai a tulajdonosok érdekeit képviselik, élükön az elnökkel (chair).
  • A menedzsment a senior vagy executive management, amely egy jellemzően (C-level) igazgatókból álló, végrehajtásért felelős legfelsőbb szintű testület. Ennek élén a vezérigazgató (angolul chief executive officer – CEO) áll. A menedzsment felelős azért, hogy megszervezze a vállalatot és olyan hatékonyan működjön, hogy el tudják érni a kitűzött célokat és eredményeket.

A King IV által meghatározott üzleti ciklus szerint a vállalatirányítás keretében az irányító testület meghatározza a vállalat működésének stratégiai irányát, majd erről szabályzatokat (policies) és működési terveket (operational plans) fogadnak el, amelyek végrehajtását a menedzsmentnek delegálják. Az irányító testület folyamatosan felügyeli, figyelemmel kíséri a végrehajtást és - amennyiben szükséges - elszámoltatja a menedzsmentet. A King IV által vázolt működés jellemzően az angolszász nagyvállalatokra vonatkozik, az Európában jellemző német modell némileg eltér ettől, a magyar modell pedig a kettő keveréke.

A vállalati célok első hallásra túl általánosnak tűnhetnek, de a Chikán Attila által alkotott vállalati célhierarchia szintjeibe mindannyian tudunk saját példákat hozni a munkahelyünkről vagy ismerős vállalkozásokból. A vállalati célhierarchia alapján a vállalat alapvető célja a fogyasztói igények kielégítése a nyereség elérése mellett, amit az határoz meg, hogy a vállalat mivel foglalkozik, milyen tevékenységeket folytat.

kep4.png

Ezek konkrét megvalósítását - és a növekedési terveket - a tartós távlati célok részletezik, amelyeket közvetlen irányítási célokra bontanak. Az beosztottak szintjén, a hétköznapi legalsó szinten a rövidtávú, operatív célok találhatók.

Risk

Minden tevékenység kockázattal jár, s ez hatványozottan igaz a vállalati működésre. A kockázat fogalmának meghatározásában kulcsfontosságú az ISO 31000:2018 nemzetközi szabvány, amely szerint a kockázat, a bizonytalanság hatása a célokra. A kockázatokat más megközelítésben a potenciálisan negatív események hatásaként és azok bekövetkezési valószínűségeként lehet meghatározni, amelyek technológiai, környezeti, gazdasági és egyéb forrásokból származhatnak.

A kockázatok kapcsán nagyon fontos visszautalni a vállalati célhierarchia alsó és középső szintjeire, mert egy negatív esemény bekövetkezése esetén - például zsarolóvírusos támadás miatti hosszabb leállás - annak következménye (SLA vagy szállítási határidők megsértése, reputáció vesztés, kötbérek fizetése) hátráltatják vagy akadályozzák a vállalatot abban, hogy elérje a tervezett célokat.

A kockázatoknak számtalan besorolása létezik, ezek közül a legáltalánosabb felosztás: üzleti, pénzügyi és működési kockázat kategóriák. Fontos kiemelni ezek közül a működési kockázatokat, mert az információbiztonsági kockázatok is ebbe a kategóriába tartoznak. A működési kockázatok fogalmát a bankok tőkeképzési kötelezettségével kapcsolatban a Basel II. szabályozás határozta meg:

„a nem megfelelő vagy rosszul működő belső folyamatokból és rendszerekből, személyek nem megfelelő feladatellátásából, vagy külső eseményekből eredő veszteség kockázata, amely magában foglalja a jogi kockázatot, de nem tartalmazza a stratégiai és reputációs kockázatot.”

Annak érdekében, hogy a vállalatok elérhessék a vállalatirányítás során meghatározott célokat, koordinált tevékenységekkel kell kezelniük a kockázatokat. Egy egész vállalatra kiterjedő kockázatkezelést az Enterprise Risk Management (ERM) keretrendszer kialakításával és működtetésével lehet megvalósítani, ahova az információbiztonsági kockázatok is becsatornázandók.

Az ERM keretrendszer kialakításakor meg kell határozni a:

  • kockázatkezeléssel kapcsolatos szerepköröket és felelősségeket, fórumokat,
  • jelentéstétel (reporting) részleteit,
  • kockázati mátrixot és annak szintjeit,
  • kockázatvállalási szintet,
  • kockázatok kezelési lehetőségeit (csökkentés, elfogadás, áthárítás, elkerülés),
  • kockázatkezelési tevékenység részfolyamatait: a kockázatok azonosítása (risk identification), elemzése (risk analysis), értékelése (risk evaluation), majd a kezelése (risk treatment).

A megfelelően működő kockázatkezelés legnagyobb előnyei között a tudatos döntések meghozatalát, a szervezet ellenálló képességét (resilience), az elért eredményeket, s ezen keresztül az ügyfelek elégedettségét szokták felsorolni.

Compliance

A compliance, vagyis a megfelelés alatt a vállalatok működésével összefüggő jó gyakorlatokat, az etikai normáknak, jogszabályoknak és szerződéses követelményeknek, továbbá az önkéntesen vállalt kötelezettségeknek való megfelelést értik. Szinte minden irányadó GRC-val kapcsolatos jó gyakorlat (King IV, OCEG GRC Capability Model, COSO) az etikai normákkal kezdődik, s ez bizony nem véletlen. A 2000-es évek elején az USA-t két nagyvállalati botrány rázta meg: az Enron és a Worldcom egyaránt fiktív könyveléssel és a pénzügyi beszámolók manipulálásával bukott le, amit persze megpróbáltak eltitkolni. A botrányok a részvényárak bezuhanásával jelentős pénzügyi veszteségeket okoztak.

E botrányok eredményeként 2002-ben az amerikai törvényhozás megalkotta a Sarbanes-Oxley Act (SOX) törvényt, amely a mai napig hatályban van és előírja az amerikai tőzsdén szereplő vállalatoknak - plusz a világ bármely pontján működő leányvállalataiknak is -, hogy egy etikus, megbízható és átlátható működést biztosító belső kontrollrendszert kell működtetniük, amelyért a vezérigazgató (CEO) és a pénzügyi igazgató (CFO) a felelősek. A belső kontrollrendszerek kialakításánál a COSO Internal Control Framework elvei az irányadók.

Három védelmi vonal

A GRC-hez szorosan kapcsolódik az Institute of Internal Auditors (IIA) által megalkotott Három Védelmi Modell, amely útmutatást ad a vállalatoknak arra nézve, hogyan szervezzék meg a kockázatkezelési és belső kontroll funkcióikat, mivel ezek komplex és összefüggő területek. A modell a COSO Internal Control Frameworkhöz hasonlóan szintén referencia dokumentummá vált.

Az első védelmi vonalba maga az üzlet tartozik, vagyis a vállalat termékeit és szolgáltatásait nyújtó szervezeti egységek. A hétköznapi működés során elsősorban ezen szervezeti egységeknek kell alkalmazniuk az előírt kontrollokat, ezek tevékenysége nyomán valósulnak meg az irányító testület által kitűzött üzleti célok.

kep5.png

A második védelmi vonalba elsősorban a kockázatkezeléssel, (információ)biztonsággal, megfeleléssel foglalkozó szervezeti egységek tartoznak, amelyek szakértelmükkel támogatják az első védelmi vonal tevékenységét és közreműködnek a kockázatok kezelésében.

A harmadik védelmi vonalba jellemzően a belső audit funkció tartozik, amely ellenőrzi a vállalatirányítás, kockázatkezelés, megfelelés hatékonyságát.

Információbiztonság és GRC

A Forrester Research publikációja az IT GRC-ről nem csak az IT-ra érvényes. Az abban foglaltak az információbiztonsággal kapcsolatos GRC-re is értelmezhetők.

Információbiztonság - governance

Az információbiztonság irányítása során a menedzsmentnek meg kell határoznia az információbiztonságért felelős szervezeti felépítést, amit jellemzően a CISO vezet, az viszont már a szervezet sajátosságaitól és méretétől függ, hogy ő kinek jelent. Ez egy visszatérő és nem eldöntött kérdés.

kep6.png

A szervezeti felépítés kialakítása akkor jelenthet kihívást, amikor egy több országban működő multinacionális vállalatcsoportról van szó, ahol csoportszinten, széles hatókörben kell hatékonyan irányítani a feladatokat és kikényszeríteni a meghatározott szabályokat. Nem ritka, hogy az információbiztonság egy globális szolgáltatóközpontként működik a vállalatcsoporton belül, jellemzően Cyber Defense Center megnevezéssel, de a belső Security Operations Centerek (SOC) is ide tartoznak, vagy az előbbi szervezet részei. A többi területtel történő hatékony együttműködés érdekében bizottságokat, úgynevezett steering committe-ket is létre szoktak hozni, amelyek tagjai az üzemeltetésért, fejlesztésért, üzletmenet-folytonosságért, kockázatkezelésért és megfelelésért, valamint auditért felelős vezetők és beosztottjaik is.

Komoly szervezeteknél a vállalati stratégia része az információbiztonsági stratégia is, amelynek megvalósítása az elvárt viselkedési szabályokat és követelményeket tartalmazó szabályzatok (policy, standard), illetve az előbbiek megvalósításának lépéseit leíró eljárásrendek (procedure) kidolgozásával és betartatásával érhető el. Az információbiztonsági céloknak illeszkedniük kell a vállalati célhierarchiába, akár a napi operatív célokról beszélünk - például információbiztonsági incidensek észlelési és lezárási idejének meghatározása és mérése -, akár egy komolyabb információbiztonsági program elemeiről, mint amilyen mondjuk az IT biztonsági megoldások sikeres bevezetése és a kockázatok kezelése. Az információbiztonsági tevékenységek egyben szolgáltatások is, ezért ezekhez szolgáltatási szintű megállapodás (SLA) is tartozhat, különösen akkor, ha ezeket a tevékenységeket egy kiszervezett szolgáltató vagy a belső szolgáltatóközpont látja el: például a kritikus sérülékenységek patchelését, fiókok tiltását, incidensek kezelését.

Information security risk management

Ahogyan a cikk korábbi részében említettük, az információbiztonsági kockázatok a működési kockázatok kategóriájába tartoznak, de ez a besorolás szervezetenként eltérhet. Egy a fontos: az információbiztonsági kockázatokat nem lehet külön silóban kezelni és értékelni, a hatékony és eredményes működés érdekében azokat a szervezet ERM keretrendszerébe kell beilleszteni és azon keresztül működtetni. Az információbiztonsági kockázatokra és domainekre mindenki tud példákat mondani, így ezekre külön nem térünk ki.

kep7.png

A viszonylag éretlen szervezetek esetében az ISO/IEC 27001 bevezetésnél előfordul, hogy nincs szervezeti vagy egyéb kockázatkezelés. Ilyenkor csak az információbiztonsági kockázatok kezelése valósul meg, vagy legalábbis azoknak kellene megvalósulnia. Utóbbi esetben egy fejlődő szervezet jól működő információbiztonsági kockázatkezeléséből kifejlődhet egy szélesebb körű, más területeket is lefedő szervezeti kockázatkezelés.

Information security compliance

Az információbiztonsági megfelelés meglehetősen komplex. Több közös, illetve több iparáganként, működési területenként eltérő eleme van. Szinte minden vállalat valamelyik best practice és/vagy ismert keretrendszer szerint alakítja ki kontrolljait és működését. Az egyik ilyen alap az ISO/IEC 27000-es szabványcsalád, de széles körben elterjedt a NIST Cybersecurity Framework (CSF) is, amelynek - az elvárásoktól függően - önkéntesen vagy kötelező jelleggel meg kell felelnie egy vállalatnak.

kep8.png

Ez tovább bonyolódhat, ha a vállalat beszállítója a német autógyáraknak, ami magával vonja a TISAX megfelelést, vagy éppen kártyaadatokat dolgoz fel és emiatt a PCI-DSS követelményei vonatkoznak rá. Ha egy vállalatcsoport tagjáról van szó, akkor annak nagy valószínűséggel - a többi terület mellett - az anyavállalati vagy csoportszintű információbiztonsági követelményeknek is meg kell felelnie.

A követelmények további jelenetős forrásai a jogszabályok. Ezen a területen nem mehetünk el szó nélkül az EU-s adatvédelmi rendelet, a GDPR mellett, de a szakmában ismert az állami és önkormányzati szervezetekre és a létfontosságú rendszerelemekre (kritikus infrastruktúra) vonatkozó terjedelmes szabályozás (Ibtv. és végrehajtási rendelete), illetve a pénzintézetek és biztosítók ágazati szabályozása, a kapcsolódó MNB ajánlásokkal is. Ezt még lehet fokozni: a Forrester Research ábrája nem tartalmazza a beszállítói követelményeket, így a vállalatra az ügyfelekkel kötött szerződések mellékleteként még számos kontroll alkalmazását írhatja elő, de ha egy szervezet megfelel az előzőekben felsorolt források jelentős részének, akkor a beszállítói követelmények között már általában nincs sok újdonság.

Összegzésül

A cikkben bemutatott GRC részterületek ismertetése és összefoglalása egy több hónapos folyamat eredménye, ám ez még mindig csak a felszín, mivel az OCEG GRC Capability Model számos további érdekességgel és tanulsággal szolgálhat.

Az információbiztonsági GRC egy rendkívül komplex terület, melynek minden eleme összefügg a többivel. Példaként: a megfelelési követelmény előírja a kockázatkezelést és az információbiztonsággal kapcsolatos szerepkörök kijelölését, szabályzatok kialakítását, naprakészen tartását és különböző technológiai kontrollok alkalmazását. Ugyanakkor a követelményektől független kockázat, ha a felsoroltak nincsenek meg vagy épp nem működnek. Kockázatot azonban nem lehet eredményesen kezelni, amennyiben az egész információbiztonsági terület nincs megfelelően menedzselve. Az egésznek csak akkor van hozzáadott értéke, ha nem papírgyártás történik, hanem valóban működtetik a három betű mögötti elemeket.

Ördögi körnek tűnhet, de szerintünk korántsem olyan rossz a helyzet. Az információbiztonsági GRC területen történő sikeres működéshez egy széleskörű, holisztikus látásmódra van szükség, bármennyire elcsépeltnek tűnik is e fogalom. Ismerni és érteni kell a technológiai kontrollokat, de ezen felül át kell látni a követelményeket tartalmazó szabványokat és jogszabályokat, illetve a kockázatkezelést egyaránt. A felsoroltak logikai háttere és összefüggései állandók, csak a részletek térnek el.

Nagyvállalati környezetben a megértésen túl elengedhetetlen a már említett GRC platform használata is, amelynek segítségével az összes felsorolt elem rögzíthető és kezelhető.

Érdekel hogyan tudja a fentieket segíteni és támogatni egy GRC platform? Mi az RSA Archer megoldását használjuk a munkánk során. Iratkozz fel, hogy értesítést küldjünk és csatlakozz február 24-én 10 órakor online workshopunkhoz!

FELIRATKOZOM

 

A cikk forrásai:

 

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

Krékity Gusztáv cikke

2022. január 14. - EURO ONE

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

it-elorejelzes.jpg

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

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

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

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

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

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

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

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

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

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

IoT veszélyek

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

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

Supply Chain Risk

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

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

Felhő biztonság?

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

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

Összegzésként

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

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

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

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

csatlakozz2.JPG

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

Hunyadi Péter cikke

2021. december 23. - EURO ONE

 

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

Mi is az a Log4Shell?

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

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

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

ICS érintettség

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

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

Hogyan reagáljunk?

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

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

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

Figyeljünk az IT-re.

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

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

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

Maradjunk naprakészek.

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

Végezetül…

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

 

 Jövőre folytatjuk!

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

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

Hunyadi Peti bejegyzése Tom Thirer cikke alapján

2021. december 09. - EURO ONE

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

zero-trust-ot--blogposzt.jpg

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

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

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

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

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

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

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

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

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

Zero Trust OT hálózatban

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

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

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

Hogyan segíthet a SCADAfence?

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

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


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


b0f22d0b64f312b26a65c3b5f4c8c1b0.png

Egy sikeres ISO 27001 bevezetés gyakorlati tapasztalatai

Tóth Tamás cikke

2021. december 07. - EURO ONE

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

iso-27001-bevezetes-blogposzt.jpg

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

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

 

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

 

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

 

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

 

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

 

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

ismstt.jpg

 

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

 

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

 

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

b0f22d0b64f312b26a65c3b5f4c8c1b0.png

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

2021. november 09. - EURO ONE

A mesterséges intelligencia a kiberbiztonágban

 

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

A mesterséges intelligencia kezdetei

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

AI kontra ML kontra DL

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

 

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

 

Deep learning

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

Machine learning

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

Mesterséges intelligencia

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

 

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

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

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

 

Szakértői rendszerek

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

 

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

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

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

 

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

 

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

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

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

 

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

 

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

 

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

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

 

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

Krékity Gusztáv cikke

2021. október 22. - EURO ONE

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

ransomware--hatekony-vedelmi-praktikak.jpg

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

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

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

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

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

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

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

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

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

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

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

Összegzésül

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

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

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

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

Sajó Péter cikke

2021. szeptember 16. - EURO ONE

blogposzt-soar-siem.jpg

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

Az összhangot teremtő SOAR

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

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

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

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

Kiknél és hogyan alkalmazható a SOAR?

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

uzleti-reggeli-mutacio-940x370_eo_web.jpg

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

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

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

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

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

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

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

Hunyadi Péter cikke

2021. szeptember 15. - EURO ONE

security-lab-10_002_1.jpg

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

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

Így laborozunk mi

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

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

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

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

Készül a demó környezet

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

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