ESETTANULMÁNY
BEVEZETŐ
Minden szervezet esetében fennáll az a kérdés, hogy az ügyfelek, partnerek által a kezelésükbe adott információk az informatikai rendszerek és környezetük minden pontján megfelelő és költség-hatékony védelemben részesülnek-e. Erre a kérdésre — az informatikai rendszerek kiterjedését és komplexitását figyelembe véve — a válasz nem mindig kézenfekvő és egyértelmű, így megválaszolását egy olyan kockázatelemzés segíti elő, amely figyelembe veszi és felméri a szervezet védendő vagyonelemeit (folyamatok, adatok, informatikai erőforrások stb.), az ezek védelmét szolgáló kontrollokat, a releváns fenyegetéseket, a védelem gyenge pontjait és a potenciális kockázatokat.
A PR-AUDIT minden évben számos felkérést kap, hogy végezzen egy, a fentieknek megfelelő informatikai biztonsági kockázatelemzést. Az ideiek közül egy projektet jelen keretek közt bemutatunk annak kockázataival együtt. A projekt megrendelőjére a téma érzékenysége miatt a továbbiakban csak Ügyfél néven hivatkozunk.
KOCKÁZATELEMZÉSI GYAKORLATOK
Mivel az Ügyfél a magyar pénzügyi piac egyik szereplője, ezért tevékenységét és informatikai biztonsági felkészültségét a vonatkozó törvények és a Magyar Nemzeti Bank (MNB), mint a pénzügyi szervezetek felügyeletét ellátó szerv módszertani útmutatói vezérlik. Ebből adódóan számára előírás az első bekezdésben leírt jellegű kockázatelemzési tevékenység legfeljebb kétévente történő elvégzése.
Az Ügyfél a korábbi években gördülő kockázatelemzést alkalmazott, amelynek lényege, hogy az MNB részéről hároméves ciklusokban szintén elvárt független informatikai biztonsági ellenőrzéseket kétéves intervallumokban hajtotta végre, és az ezek során feltárt hiányosságok képezték a kockázatelemzése alapját, amelyet természetesen kiegészített minden egyéb forrásból (belső vizsgálatok, felügyeleti ellenőrzések, ad-hoc kockázatértékelések stb.) származó kockázati információval. Ennek a módszernek két jelentős előnye van: a feltárt hiányosságok evidenciákkal alátámasztott ellenőrzések eredményei, tehát magas bizonyossággal állapíthatók meg, valamint folyamatba épített értékelés, így a kockázatelemzési tevékenység önmagában minimális többlet erőforrást igényel. Hátrányosnak tekinthető, hogy ennek az eljárásnak az alkalmazásával, a teljeskörűség érdekében a szervezeteknek két éven belül kell lefolytatniuk azokat az ellenőrzéseket, amelyeket egyébként három év alatt oszthatna el, így alapvetően az ellenőrzési erőforrások igénye magasabb. Az Ügyfél e megfontolásból döntött úgy, hogy a független ellenőrzéseket kiterjeszti hároméves ciklusokra, és projektalapú kockázatelemzést vezet be.
A projektalapú kockázatelemzés az erőforrások optimális felhasználása mellett magával vonja azt is, hogy a tevékenység hatóköre egyértelműen kijelölhető, így priorizálhatók a szervezet számára kritikus jelentőséggel bíró rendszerelemek és kontrollok. A módszer hátránya azonban, hogy az ellenőrzési erőforrás-hatékonyság alacsonyabb, hiszen a figyelembe vehető független ellenőrzések nem teljeskörűek az adott kockázatelemzési ciklusban, ezért olyan technikák használata indokolt, amelyek alacsonyabb bizonyossági szintet jelentenek a hiányosságok feltárása során, és csak kiegészítő tevékenységekkel emelhető a bizonyosság mértéke. Az Ügyfél felkérésére elvégzett kockázatelemzésünk ez utóbbi eljárásra épült fel, amelyet a következőkben ismertetünk.
MÓDSZERTAN KIVÁLASZTÁSA
A projekt első lépéseként kialakításra került a kockázatelemzéshez alkalmazott módszertan. Figyelembe véve, hogy az Ügyfél informatikai működését ennek elvárásai vezérlik, a kockázatelemzés alapját az MNB 8/2020. számú módszertani útmutatója képezte kiegészítve az ISO/IEC 27001:2013 szabvány releváns pontjaiban foglaltakkal, a módszertan kerete pedig az ISO/IEC 27005:2011 (Information technology — Security techniques — Information security risk management) szabványt, mint nemzetközi legjobb gyakorlatot követi. A kockázatelemzési módszertant az alábbi pontoknak megfelelően építettük fel.
HATÓKÖR
A kockázatelemzés hatókörének pontos kijelölésének célja, hogy minden, az Ügyfél számára értékkel bíró vagyonelem (folyamat, adat, erőforrás stb.) figyelembe vételre kerüljön a kockázatelemzés lefolytatása során. Ennek bejövő adatait az Ügyfél üzleti hatáselemzése adta. A kockázatelemzés feladatai azokra a rendszerekre terjedtek ki, amelyeket az üzleti hatáselemzés során az Ügyfél kritikus folyamatot támogató erőforrásként jelölt meg, és/vagy az adatbesorolás szerinti kiemelten védendő adatokat kezel, így a kockázatfelmérés hatókörébe ~25 db rendszer került kiválasztásra, melynek jelentős részét üzleti alkalmazások tették ki, de szerepelt köztük pl. a levelezőrendszer, központi naplógyűjtő és elemző rendszer, adatszivárgásvédelmi rendszer és határvédelmi rendszer is.
Tekintve, hogy egy adott rendszer nem csak egy rendszerelemből áll, így felmértük azt is, hogy a kiválasztott rendszerek milyen komponensekkel, függőségekkel rendelkeznek, amelyhez begyűjtöttük a lehető legtöbb releváns információt, pl. érintett szerverek (virtuális és fizikai), érintett hálózatok, authentikációs/authorizációs eljárások, felügyeleti megoldások, interfészek, szolgáltatói függőségek stb. Az összegyűjtött adatok alapján kockázati területeket (Risk domain) alkottunk az egyes rendszerekre vonatkozóan, és a kockázatelemzés a továbbiakban az így azonosított és körülhatárolt kockázati területek tekintetében került lefolytatásra.
Projektkockázatok:
- Az üzleti hatáselemzés adatai a kockázatelemzés nélkülözhetetlen részét képezik. Amennyiben ez nem megfelelően lett végrehajtva (pl. folyamatok indokolatlanul magas vagy alacsony kritikussági besorolása), úgy a kockázatfelmérés hatóköre sem lesz megfelelő.
- Egy nem elegendő tapasztalattal rendelkező szakember helytelenül vagy hiányosan ítélheti meg az egyes rendszerek függőségeit, amelynek eredményeként előfordulhat, hogy alapvetően kockázatos komponensek nem kerülnek bele a projekt hatókörébe.
FENYEGETÉSEK
A kialakított kockázati területek ismeretében már meghatározhattuk azokat a lehetséges emberi, természeti és környezeti veszélyforrásokat, amelyek a potenciális sebezhetőségeket kihasználhatják, előidézhetik azok káros üzleti hatását. Ehhez az ISO/IEC 27005:2011 szabvány fenyegetés leltárjának általunk kibővített változatát alkalmaztuk, amelyet az Ügyfélre szabtunk, és összerendeltük a potenciálisan kihasználható sebezhetőségekkel. Természetesen, ezek a fenyegetés-sebezhetőség párosok nem feltárt, hanem alapértelmezett kockázatokat képeznek, így a kockázatelemzés során nem mindegyiknek tulajdonítottunk jelentőséget, valamint kiegészítésre is került új, akár feltárt kockázatokkal is.
Projektkockázatok:
- Ha nem megfelelően kerül meghatározásra a releváns fenyegetések köre (pl. hegy tetején vagy sivatagban elhelyezett erőforrások esetén árvíz, mint fenyegető tényező), indokolatlanul kitágulhat a projekt, amellyel megnőhet annak erőforrásigénye is.
KOCKÁZATOK MINŐSÍTÉSE
A kockázatelemzés során feltárt kockázatokat kvantitatív módszerekkel értékeltük. Minden hiányosság esetén felmértük, hogy az általa hordozott kockázat bekövetkezése milyen mértékű negatív hatást gyakorolhat a vizsgált rendszer/folyamat által kezelt adatokra bizalmasság, sértetlenség és rendelkezésre állás tekintetében, valamint azt, hogy a következő évben mekkora valószínűséggel következhet be a kockázat. Mindkét attribútumot egy-egy ötfokozatú skálán helyeztük el, és az egyes hiányosságok végső kockázati besorolását egy, a két mérce felhasználásával készített kockázati mátrix alapján határoztuk meg az alábbi ábra szerint:
Projektkockázatok:
- A kockázatelemzést végző tapasztalatának vagy az aktuális fenyegetettségi környezet ismeretének hiányában előfordulhat, hogy nem megfelelően kerülnek kialakításra a kockázatértékeléshez használt skálák (pl. a szervezet méretétől, felépítésétől eltérő léptékek).
EREDMÉNYTERMÉKEK
Kockázatfelmérésünk eredményeként az Ügyfél részére egy kockázatelemzési táblázatot készítettünk, amely teljeskörűen tartalmazott minden releváns adatot (kontroll követelmények, kapcsolódó fenyegetések és sebezhetőségek, kontroll követelményeknek történő megfelelés értékelése, feltárt hiányosságok, javasolt intézkedések, kockázat értékelése). Mivel a kockázatelemzési tevékenység lényege, hogy elősegítse a menedzsment döntéseit azzal, hogy kiemeli a szervezet számára kockázatos területeket, természetesen nem elvárható, hogy az Ügyfél közel 1500 db kiértékelt kockázatot véleményeztessen a szervezetével, ezért elkészítettünk egy összefoglaló jelentést is, amelyben bemutattuk az elvégzett tevékenységeket, a felmérés körülményeit, a figyelembe vett adatokat, a résztvevőket, az eredmények összefoglalását, valamint kivonatoltuk kizárólag azokat a kockázatokat, amelyek intézkedést igényel(het)nek.
Projektkockázatok:
- Amennyiben a kockázatelemzés eredményterméke nem néhány, jól átlátható és érthető dokumentációból áll, az szintén rossz vezetői döntéseket vagy újbóli dokumentálással járó többlet erőforrás-igényt eredményezhet.
PROJEKT MENETE
DOKUMENTÁCIÓS KÖRNYEZET
ÁLTALÁNOS KONTROLLOK, KOCKÁZATOK
Miután kialakítottuk a fentiek szerint a kockázatelemzéshez használt módszertant, létrehoztuk a kockázatelemzéshez kapcsolódó dokumentációs környezetet is. Ennek keretében elkészítettük a kockázatelemzés alapját képező kontroll katalógust, ami az MNB 8/2020. számú módszertani útmutatójának követelményeiből állt, ezeket a követelményeket pedig összerendeltük az ISO/IEC 27001:2013 szabvány megfelelő pontjaival. Az egyes kontrollpontokhoz kiválogattunk továbbá a fenyegetés-sebezhetőség leltárból minden olyan párost, amelyek relevánsak lehetnek az adott kontroll tekintetében.
Projektkockázatok:
- Örökölt kockázat a fenyegetések tekintetében – ha nem megfelelően kerül meghatározásra a releváns fenyegetések köre, akkor előfordulhat, hogy a kockázatok meghatározásánál figyelembe vett fenyegetések köre is a szükségesnél tágabban értelmezett
RENDSZERSPECIFIKUS KOCKÁZATOK
Az előzőekhez hasonlóan, egy külön táblázatban az egyes rendszerekhez is hozzárendeltük a releváns fenyegetéseket és sebezhetőségeket, valamint azoknak az általános kontrolloknak az azonosítóit, amelyeket az adott fenyegetés-sebezhetőség páros érinthet, ezzel egy kapcsolatot teremtve az általános kontrollok és a rendszerspecifikus kontrollok között.
Projektkockázatok:
- Örökölt kockázat a fenyegetések tekintetében – ha nem megfelelően kerül meghatározásra a releváns fenyegetések köre, akkor előfordulhat, hogy a kockázatok meghatározásánál figyelembe vett fenyegetések köre is a szükségesnél tágabban értelmezett
KONTROLL ANALÍZIS
A dokumentációs környezet felállítását követően elkezdhettük az kockázatfelmérés első érdemleges szakaszát, vagyis a kontroll analízist. A kontroll analízis során arra fókuszáltunk, hogy az Ügyfél milyen eljárásokat, folyamatokat alkalmaz a kontroll követelményeknek történő megfelelés érdekében, ezért a szakasz első lépéseként elkértük a rendelkezésre álló összes, informatikai és biztonsági vonatkozású szabályzatot és eljárásrendet. A megkapott dokumentációkat egyesével, részletesen elemeztük, és a megfelelő részeket hozzárendeltük a kontroll katalógus egyes pontjaihoz.
Az Ügyfél konkrét folyamatainak ismeretében interjúkat szerveztünk a folyamatok üzemeltetéséért felelős személyekkel, vagyis az üzemeltetési és IT biztonsági vezetőkkel. Az interjúk során – egy ISO27001 audit módszereihez hasonlóan – kértük, hogy a felelősök magyarázzák el, mutassák be az egyes kontroll követelményekre kidolgozott folyamatok gyakorlati megvalósításának mikéntjeit, amelyben kitértünk pl. a folyamatok résztvevőire, feladataikra, az alkalmazott megoldásokra és működési környezeteikre, a felügyeleti eljárásokra, jóváhagyási láncolatokra stb.
A belső folyamati dokumentációk elemzése, és a lefolytatott interjúk alapján dokumentáltuk az általános folyamatok megfelelőségét, valamint feltártunk és értékeltünk minden olyan hiányosságot, ami a kontroll követelmények és a kialakított folyamatok, vagy a kialakított folyamatok és azok gyakorlati megvalósítása között felmerült, és javaslatokat fogalmaztunk meg ezek javítására.
Projektkockázatok:
- Az interjúalanyok véletlen vagy szándékosan eltitkolhatnak olyan lényeges információkat, amelyeket egy tapasztalt szakember több szemszögből közelítve végül feltárhat.
- Amennyiben a kockázatfelmérést a szervezeten belüli személy végzi el, úgy előfordulhat, hogy elfogult valamely kontroll kialakítását illetően, és nem vesz figyelembe, akár jelentősebb kockázatokat.
- A kockázatelemzést végző tapasztalatának vagy az aktuális fenyegetettségi környezet ismeretének hiányában előfordulhat, hogy nem megfelelően kerülnek kiértékelésre a kockázatok.
RENDSZERSPECIFIKUS KOCKÁZATÉRTÉKELÉS
Figyelembe véve, hogy az Ügyfél részéről megrendelt kockázatértékelés hatóköre a kritikus erőforrásokra terjedt ki, a kontroll analízist követően elkezdtük a rendszerspecifikus kockázatok kiértékelését is. Ehhez ismételten interjúkat szerveztünk, azonban ezúttal már az egyes, a kockázatelemzés hatókörébe tartozó rendszerek felelőseivel (adatgazdák, rendszerszervezők, rendszergazdák).
Az eddig rendelkezésre álló adatok alapján minden interjúra egyedi interjútervet készítettünk a rendszerek sajátosságai alapján, és arra kerestük a választ az interjúalanyoktól, hogy az általános folyamatok miként érvényesülnek az adott rendszer tekintetében (pl. a változáskezelési folyamatok hogyan illeszkednek a vállalati folyamati struktúrába), kivétel esetén milyen egyedi folyamatok alkalmazottak a rendszerben (pl. AD integráció hiányában milyen hitelesítési eljárás működik), vagy abban az esetben, ha hiányosság tapasztalható az általános kontrollokban, akkor helyileg milyen kompenzációs eljárások működhetnek, amelyek csökkentik a kockázatokat.
A kontroll analízis szakaszhoz hasonlóan tovább elemeztük az interjúkat követően előállt adathalmazt, és feltártunk minden rendszerspecifikus hiányosságot. Ezeket a hiányosságokat a rendszerspecifikus kockázatok között dokumentáltuk a javításukra vonatkozó javaslatokkal együtt. Továbbá, a rendszerspecifikus kockázatok alapján újraértékeltük azokat az általános kontrollokat is, ahol hiányosságot tártunk fel a kontroll analízis során.
Projektkockázatok:
- Az interjúalanyok véletlen vagy szándékosan eltitkolhatnak olyan lényeges információkat, amelyeket egy tapasztalt szakember több szemszögből közelítve végül feltárhat.
- Amennyiben a kockázatfelmérést a szervezeten belüli személy végzi el, úgy előfordulhat, hogy elfogult valamely kontroll kialakítását illetően, és nem vesz figyelembe, akár jelentősebb kockázatokat.
- A kockázatelemzést végző tapasztalatának vagy az aktuális fenyegetettségi környezet ismeretének hiányában előfordulhat, hogy nem megfelelően kerülnek kiértékelésre a kockázatok.
KIEGÉSZÍTŐ TEVÉKENYSÉGEK
Tekintve, hogy a kockázatfelmérés során nem ellenőrzési kapacitásunkban voltunk jelen, azaz a projekt nem terjedt ki olyan tevékenységekre, amelyekkel magas bizonyossággal kijelenthető a kockázatértékelés teljeskörűsége (pl. célellenőrzések, mélységi vizsgálatok, technológiai auditok), így olyan kiegészítő információkat kellett beszereznünk, amellyel kompenzálhatók az esetleges hiányosságok. Ennek érdekében elkértük az Ügyfél kockázat nyilvántartását, amelyből átemeltünk minden, a kockázatelemzést megelőző 2 évben elvégzett független ellenőrzések során feltárt, a kockázatelemzés hatókörébe illeszkedő nyitott kockázatot is. Ezekkel az adatokkal már teljeskörűnek tekinthető az Ügyfél kockázatfelmérése.
Projektkockázatok:
- Helytelen bejövő adatok miatt, vagy a kockázatelemzést végző tapasztalatának hiányában előfordulhat, hogy nem minden releváns kockázat kerül át a kockázatelemzésbe, vagy olyanok is, amelyek a kockázatelemzés hatóköre tekintetében nem relevánsak.
EREDMÉNYEK
Az eddigiekben bemutatott kockázatfelmérés eredményeként előállt az Ügyfél kockázati térképe, amely megalapozhatja a vezetőség döntéseit az informatika területén. A feltárt kockázatok darabszámát az anonimitás érdekében nem kívánjuk közölni, azonban az alábbi, az Ügyfélnek átadott kockázatelemzési jelentésben szereplő diagram bemutatja azok relatív számosságát, valamint megoszlását:
A fenti ábrán látható, hogy a kockázatfelmérési projekt számottevő mennyiségű kockázatot tárt fel, ugyanis a zölddel jelzett részek a korábban is feltárt kockázatok kb. 30%-át teszik ki.
FŐBB KÖVETKEZTETÉSEK
A digitális technológiák egyre szélesebb körű alkalmazása a fejlődés természetes következménye, azonban, például egy nem megfelelően tervezett infrastruktúra, egy sietve fejlesztett rendszer, egy felhasználó figyelmetlen kattintása mind olyan kockázatoknak enged teret, amelyek súlyos negatív hatásokat gyakorolhatnak egy szervezetre, vagy akár teljes szolgáltatási láncokra, így nem véletlen, hogy az Európai Bizottság is egyre több olyan javaslatot terjeszt elő, amik az informatikai vonatkozású kockázatelemzést hivatottak hangsúlyozni. A DORA például a már eddig is erőteljesen szabályozott pénzügyi intézményekre fogalmaz meg további elvárásokat, a nemrégiben elfogadott NIS 2 pedig 16 piaci ágazat szereplőire terjeszt ki felelősségeket a témában, így az elkövetkező években számos szervezetnek kell majd valamilyen kockázatelemzési módszert választania, vagy továbbfejlesztenie a már használatban lévőt.
Álláspontunk szerint, a bemutatott – de általánosságban az összes – kockázatelemzési projektből két fő tanulság vonható le. Egyrészt, ahogy az eredményeken is látszik, nem létezik univerzális, teljeskörűséget garantáló módszer a kockázatok felmérésére, mivel a különböző módszerek előnyei és hátrányai ellentétesek, azonban figyelembe veendő, hogy bármelyik eljárással jelentős mennyiségű probléma fedhető fel egy adott szervezetben, amelyek remediálása nélkül csak idő kérdése, hogy mikor következik be valamelyik, ami aztán helyreállíthatatlan károkat okozhat. Ennek fényében, MI mindenképpen javasoljuk a rendszeres kockázatelemzések elvégzését még akkor is, ha nem előírás…
Másrészt, a felvázolt projektkockázatok miatt, egy kockázatelemzés megfelelő, pontos elvégzésében kiemelkedő szerepet játszik a kockázatfelmérést végrehajtó szakemberek felkészültsége és függetlensége. Ezek hiányában hiába fordít egy szervezet bármennyi erőforrást kockázatelemzésekre, mivel az eredmény egy torz kép lesz, ami nehezen használható a felsővezetői döntések megalapozására, vagy egyenesen rossz irányba is terelheti azokat, így ajánlott megfelelő kompetenciával rendelkező, külső szolgáltatót felkérni a kockázatok feltárására.
Amennyiben egy szervezet felismeri, hogy szüksége lehet kockázatelemzésre, és lehetősége is van külső szakértőt bevonni, már csak a projekt hatékonyságának és erőforrás-igényének optimalizációja lehet kérdéses, amelynek kulcsa véleményünk szerint a tapasztalat.