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

EURO ONE

Purple Teaming: a reálisabb biztonsági tesztek alapja

Kovács Erik cikke

2021. augusztus 10. - EURO ONE

Ahogy az korábbi bejegyzéseinkből kiderülhetett, a kiberbűnözők eszköztára folyamatosan fejlődik, s adott esetben képes akár teljesen átalakulni - vegyük csak példának a zsarolóvírusok szolgáltatássá avanzsálását - , hogy minél hatékonyabb és profitálóbb támadásokat hajthassanak végre. Szerencsére ezzel egy időben az infosec iparág is mindig előrukkol új megoldásokkal. Olykor ezek nem is feltétlenül jelentenek teljesen új technológiákat, egyszerűen csak a korábbi, bevált módszerek továbbfejlesztését. Az egyik ilyen, egyre többeket foglalkoztató biztonságtechnikai eszköz a Purple Teaming, amelyről a SOC's Summiton tartottunk előadást. Éppen ezért úgy gondoltuk, röviden összefoglaljuk az ott elhangzottakat.

Amikor a pentest nem elég

Kezdjük az elején, s nézzük meg, mi hívta életre a Purple Teaminget. Bizonyára nem mondunk vele újdonságot, de sok vállalatnál a biztonsági felméréseknél még mindig csak a penetrációs tesztekben gondolkodnak. A sebtében elvégzett pentest persze jó eséllyel kiszűri a befoltozandó hibákat, de hatalmas hiba, ha ezek eliminálása után a cégvezetés és a vállalat biztonsági szakértői kényelmesen hátradőlnek a karosszékben, annak biztos tudatában, hogy innentől kezdve sebezhetetlenek.

Sajnos a pentest, s ugyanígy a vulnerability scanning, illetve vulnerability assessment egyaránt megmarad a vállalat technológiai rétegében. S bár ilyen módon a technikai problémák kiszűrésére kiválóan alkalmasak, ám nem szabad elfeledkezni arról, hogy a vállalati működés nem pusztán technológiai háttérből áll: ott van az emberi tényező is.

A hacker támadások legtöbbje nem feltétlenül azért lesz sikeres, mert a kiberbűnözők aprólékos munkával feltörnek webes alkalmazásokat, majd onnan lépésenként eljutnak egészen a domain controllerig. A legtöbb támadás sikerének kulcsa a munkatársak, avagy a felhasználók felkészületlenségének köszönhető: gyanútlan kíváncsisággal kattintanak rá a legprimitívebb phising e-mailben található linkre is, amivel a hackerek részéről gyakorlatilag le is van tudva az initial access megszerzése. S ha a kezdeti hozzáférés megvan, a támadónak már csak annyi a feladata, hogy elhelyezzen a rendszerben egy kódot, amely biztosítja számára a későbbi lépések megtételének lehetőségét, a folyamatos hozzáférést.

Sajnos a felhasználót, mint leggyengébb láncszemet nem tesztelik a pentestekkel és a vulnerability assessmentekkel, ezekkel csak a technológiai layer problémái szűrhetők.

A megoldás: a piros és a kék keverése

Nem, nem arra gondolunk, hogy minden cég folyosóját érdemes pirosra és kékre, vagy a két színből kikeverhető lilára mázolni. A megoldást csak átvitt értelemben jelenti e két szín összekeverése. A Red Teaming és Blue Teaming fogalmak bizonyára mindenkinek ismerősek az infosec témák iránt érdeklődők köreiben. Ha valakinek mégsem, akkor röviden a lényegük: a katonaságtól eredeztethető fogalmak, ahol a gyakorlatok során egy piros (támadó) és egy kék (védekező) csapatra osztották a bakákat, s ily módon igyekeztek valós harci helyzeteket szimulálni. Kiberbiztonsági szempontból a dolog nagyon hasonló, vagyis adott a Red Team (jelesül a hackerek) és a Blue Team (például egy vállalat védelmét ellátó csapat), akik modellezik, hogy mi történne egy kibertámadás során. Sok esetben a támadás tényéről előre csak a cégvezetők tudnak, hogy a dolog minél életszerűbb legyen. Így a kék csapat reális támadásnak érzékeli a cégvezetés által megbízott hackerek furmányait, s ennek megfelelően védekeznek.

Ez önmagában is hatékony lehet a hibák és hátsó kapuk feltárására, ám a mostanában egyre népszerűbb úgynevezett Purple Teaming egy fokkal tovább viszi ezt a gondolatmenetet. Nevezetesen azzal, hogy a Purple Teaming esetében a piros és a kék csapat tagjai tudnak egymásról. Ennek megfelelően együtt elterveznek minden egyes lépést, átbeszélik a várható eseményeket, hogy melyik lépésnél milyen eredményre számíthatnak. Így például ha a Red Team egy credential dumping során igyekszik kinyerni valamelyik gépről a jelszavakat, akkor a Blue Team arra számíthat, hogy az antivírus vagy az EDR (Endpoint Detection & Response) rendszer sipákolni kezd, s megpróbálja automatikusan blokkolni a támadást. Ha eljutnak ehhez a lépéshez, s az antivírus illetve az EDR egyaránt néma marad, máris kivizsgálhatják, mi lehet ennek az oka.

Viszont talán ennél is nagyobb dolog, hogy ezzel a módszerrel az is felmérhető, a felhasználók mekkora elánnal kattintanak az adathalász levelek linkjeire. A teszt során kiderülhet, hogy a kollégák képtelenek felismerni a nem kívánatos linkeket, amiből a cégvezetés leszűrheti a tanulságot és szervezhet pár órányi képzést a munkatársaknak.

Emellett kiváló megoldás ez a folyamatok tesztelésére is, hiszen fény derülhet rá, hogy a Helpdesk tisztában van-e azzal, bizonyos események bekövetkeztekor kihez kell fordulni, vagy épp milyen a SOC (Security Operations Center), a Helpdesk és a felhasználók közötti kapcsolat és információáramlás. A Purple Teaming tehát jóval túlmutat a technológiai réteg tesztelésén, ami hatalmas gyakorlati előnyt jelenthet a biztonság fokozásához.

Szemben a pentest és a vulnerability assessments tesztekkel a Purple Teaming bevetésével az APT támadásokat is hatékonyan lehet megelőzni, ahol - szemben mondjuk egy szórakozásból vagy erőfitogtatásból elkövetett script kiddie próbálkozással - a támadóknak anyagi támogatásuk és idejük (olykor pedig állami hátszelük) is van a támadás kivitelezéséhez. A fejére látványosan fekete kapucnit húzó és így klimpírozó script kiddie közel nem jelent olyan mértékű fenyegetést egy cégre nézve, mint amire egy APT képes. Az APT-k módszerei ellen pedig hatékonyabb védelmet lehet kidolgozni a Purple Teaming eszköztárával, mint a korábban elterjedt tesztelési módszerekkel.

ÉRDEKEL A KIBERBIZTONSÁG? 

Vegyél részt október 14-én az EURO ONE-RSA Cyber Security Summiton

TOVÁBBI INFORMÁCIÓ ITT

 

Új üzleti modell: így lesz szolgáltatás a ransomware-ből

Krékity Gusztáv cikke

2021. június 30. - EURO ONE

Nem is olyan régen, május végén elemeztük ki, miként váltak - sajnálatosan - az elmúlt évek egyik bomba üzletévé a zsarolóvírusok. A fejlődésük, a variánsok megjelenési ütemének gyorsulása egyaránt azt jelzi, hogy a számítógépes bűnözők számára igen jövedelmező üzletággá vált a ransomware.

 ransomware-a-a-service.jpg

Az első támadások még rombolásra és károkozásra voltak kihegyezve, s persze arra, hogy a titkosított adatok visszafejtéséért minél több bitcoint csikarjanak ki a pórul jártakból. Ám ez a fajta megközelítés idővel - különösen a támadások számának megszaporodása miatt - vesztett hatékonyságából: egyre kevesebb áldozat volt hajlandó fizetni. Sajnos a támadók ebből nem azt a következtetést vonták le, hogy a zsarolóvírusoknak leáldozott. Ehelyett egy második zsarolási lépcsőfokot is beépítettek a támadásokba: nem csak titkosították, zárolták az adatokat, hanem el is lopták az érzékeny információkat. Ettől kezdve pedig az áldozatnak már nem is feltétlenül a titkosítás feloldásáért kellett fizetnie, hanem azért, hogy az eltulajdonított céges adatokat ne publikálják a nagyvilág számára. Ez újabb fellendülést hozott a zsarolóvírusoknak, sőt drágultak is a követelések: 12 hónap alatt 230%-os növekedés volt tapasztalható a váltságdíjak átlagos összegében.

Mostanra a zsarolóvírusoknál körvonalazódik egy olyan új üzleti modell, amellyel maga a ransomware már nem korlátozódik az azt létrehozóra: magát a kódot kezdik értékesíteni, így csökkentve a fejlesztő kockázatát. A zsarolóvírust megvásárló számára ez az üzleti modell csökkenti a támadások végrehajtására fordított végrehajtási költséget, hiszen egy előre megírt és felépített kódot használhat a támadás kivitelezéséhez. Ráadásul ez a fajta RaaS (Ransomware-as-a-Service) szolgáltatási modell kibővíti a zsarolóvírusok által generált fenyegetéseket, mert ettől kezdve már nem kell szakképzettség és tapasztalat ahhoz, hogy valaki saját ransomware variánssal hajtson végre sikeres támadást. A fejlesztő számára pedig a RaaS ugyanolyan nyereséges lehet, mint egy közvetlen támadás végrehajtása a megírt kóddal, hiszen az értékesítési díjon felül - a sikeres támadást követően - még a váltságdíjból eredő nyereség egy részét is megkapja, ezzel is garantálva a vásárló számára, hogy személyre szabott és egyedi kódhoz jusson a támadás kivitelezéséhez.

A ransomware mint szolgáltatás

A módszer hasonlít a SaaS (Software as a Service) üzleti modelljére, mivel jelen esetben a ransomware fejlesztők is eladják - vagy bérbe adják - az egyedileg fejlesztett és felépített zsarolóvírus variánsaikat olyan felhasználók számára, akik később a támadásaikat ezekkel a kódokkal hajtják végre. A RaaS üzleti modell felépítését a NIST Cybersecurity Framework megközelítése szerint bontjuk részekre, hogy alaposabban felvázolhassuk működését.

picture1.png

  1. Első lépésként a ransomware kód fejlesztője létrehoz egy saját készítésű, egyedi kártékony kódot, amelyet ezt követően elad egy előre meghatározott fix ellenszolgáltatás fejében, plusz bizonyos sikerdíjas részesedésért az áldozattól zsarolás útján megszerzett tiszta nyereségből.
  2. A felhasználó (hacker) ezt követően a kapott kódot vegyíti egy exploite-tal.
  3. Harmadik lépésként a támadó azonosítja és célba veszi a gyanútlan áldozatot és a támadási vektort továbbítja, jellemzően egy e-mail üzenetben.
  4. A támadás következő fázisában az áldozat megnyitja a levél csatolmányát vagy a beágyazott és fertőzött weblinket az üzenetben. A kártékony kód ezt követően letöltődik és lefut az áldozat gépén.
  5. Ezután a zsaroló program nekilát titkosítani az áldozat állományait, illetve elkezdődik az oldal irányú mozgás a belső hálózaton, amelynek során további potenciális áldozatokat keres (értékes adatokat tároló szervereket, rosszabb esetben a backupot tartalmazó szervert vagy megoldást). A program szép csendben, ebben a fázisban elkezdi módosítani a rendszerkonfigurációkat, hogy a támadónak bármikor legyen belépési pontja a szervezethez és mindeközben elkezdi eltüntetni a nyomait, hogy minél nehezebb legyen a későbbiekben a kivizsgálási folyamat.
  6. Az áldozat monitorján megjelenik a zsaroló üzenet amelyben utasításokat kap, hogyan vásárolhatja meg a titkosított adatai visszafejtéséhez szükséges információkat, lenyomozhatatlan és lekövethetetlen kriptovalutával (bitcoin).
  7. A támadó többször is továbbítja a kapott váltságdíjat, hogy még kevésbé legyen a folyamat a támadáshoz köthető, lekövethető.
  8. Utolsó lépésként a támadó - a sikeres támadást követően - továbbítja a fejlesztő számára az előre megbeszélt sikerdíjat.

Így néz ki a folyamat általában, de ezen belül négy különféle RaaS bevételi modell létezik:

  • A támadó előfizetéses általány díj ellenében vásárol
  • Van sikerdíjas kódbérlés, így a sikeres támadást követően a fejlesztőnek a nyereség általában 20-40%-át a támadó átadja a fejlesztőnek
  • Egyszeri használati díjat fizet a haszon megosztása nélkül
  • Tiszta nyereség, megosztás alapon

Mindez pont olyan egyszerű, amilyennek hangzik: az ügyfélnek mindössze meg kell látogatni a Dark weben egy RaaS portált, ahol létrehoz egy saját fiókot, majd befizeti bitcoinban az ellenszolgáltatás összegét. Ezután pedig kiválaszthatja egy listából, hogy milyen kártékony kódra lenne szüksége.

picture2.png

A kód kiválasztását követően a felhasználó hozzáférhet a zárt fórumokhoz, dokumentumokhoz, funkciófrissítésekhez, sőt, még terméktámogatást is igényelhet. Az igazán professzionális RaaS szolgáltatók olyan portálokat kínálnak, amelyek lehetővé teszik előfizetőik számára, hogy megnézzék az adott támadás életciklusát és a fertőzés(ek) állapotát, kifizetési információkat, fájltitkosításokat, sőt, ha az adatokat a titkosítással párhuzamosan egy külső FTP szerverre is kimásolják, akkor lehetőséget biztosítanak, hogy azzal vagy másodlagos zsarolási kampányba vágjanak bele, vagy mondjuk publikálják, eladják az értékes információkat.

Jelenleg a RaaS üzleti modell abszolút piac- és versenyképes. Olyannyira működik, hogy a RaaS szolgáltatók immár különböző marketing kampányokat is folytatnak, eközben pedig olyan weboldalakkal rendelkeznek, amelyek a megszólalásig emlékeztetnek egy normális cég weboldalára. A portálokon találhatunk videókat a támadásokról, white papers dokumentációkat. Olykor még Twittert is használnak. A zsarolóvírus nagy üzlet a digitális feketepiacon: 2020-ban már a 20 milliárd amerikai dollárt is meghaladta a bevétel, szemben a 2019-es csekély 11,5 milliárd dolláros nyereséggel.

picture3.png

Jelenleg a RaaS modellben működő ransomware támadásokra számos példa akad, melyek közül soknak a neve csenghet ismerősen: Locky, Goliath, Shark, Stampado, Jokeroo, REvil, Dharma vagy épp az egyre nagyobb népszerűségnek örvendő LockBit.

A RaaS és a COVID-19 összefüggései

Sajnos a koronavírus és a pandémia szinte minden alkalommal szóba került az elmúlt 10-13 hónap során, amikor támadásokról beszéltünk. Jelenleg ilyen időket élünk. Talán hamarosan vége lesz, s már látni némi a fényt az alagút végén, de jelenleg még meg kell említeni a COVID-19-et a RaaS esetében, hiszen a járvány több szempontból extra lehetőséget biztosított a bűnözők számára. Rengeteg intézményt - köztük számos kutatólabort, kórházat is - ért a közelmúltban ransomware támadás, tehát még azokat az intézményeket sem kímélték a támadók, akik napról napra értük, vagy épp a vírus ellen küzdöttek és kutattak. Ezen támadások többsége a fejlődő országokat érintette, ahol nincs kiépített biztonsági infrastruktúra, de számos esetben sikeresen támadtak meg egészségügyi és pénzügyi intézményeket a fejlett országokban is, többek között azért, mert a hirtelen bevezetett home office munkamód kiváló alapot teremtett a felhasználók támadására.

Mi tehát a RaaS sikerének titka?

A RaaS sikere nem túl meglepő, hiszen a segítségével olyanok is támadásokat indíthatnak, akik kevésbé képzettek, s önmaguktól egész egyszerűen képtelenek lennének sikeres támadást megvalósítani. A Dark Weben a rosszfiúknak manapság épp olyan egyszerűvé vált megszervezni egy offenzívát, mint otthoni felhasználó számára regisztrálni a Netflixre. A másik ok pont ez az egyszerűség, hiszen most sokkal gyorsabban fejlesztenek ransomware kódvariációkat, nem kell energiát és időt fektetni magába a támadás felépítésébe és kivitelezésébe. Így a fejlesztő minden rendelkezésre álló energiája és ideje a kódok elkészítésére koncentrálódhat. Emellett a RaaS modellben teljeskörű - és visszatérő - ügyfélkörrel dolgozhatnak a fejlesztők, így folyamatos bevételeket szerezhetnek, miközben jelentősen tudják csökkenteni a saját kockázataikat.

 A témában exkluzív anyagokat találsz majd az InfoSec Akadémia hamarosan induló oldalán. Jelenleg előregisztráció zajlik, jelentkezz!

 isakademia_l_1200x627.png

A ransomware támadások kivédésének praktikáit hamarosan e-bookban is olvashatod, amit megtalálhatsz majd az InfoSec Akadémián!

OT security szuperprojekt: megteremtjük a hatékony tesztelés alapjait

Bak Bernadett cikke

2021. június 24. - EURO ONE

Felemelő élmény, amikor az ember egy adott területen tengernyi tapasztalatot szerez. Ennél már csak az tölthet el jobb érzéssel bárkit, amikor e tapasztalatokat megoszthatja másokkal is, hogy segítse őket a munkájukban. Mi is így vagyunk ezzel, nap mint nap igyekszünk átadni a megszerzett tudást megbízóinknak, többek között az IT biztonság terén. Ám ez egy meglehetősen képlékeny és folyamatosan változó terület, így nem elég, ha ülünk a babérjainkon és a megszerzett tudáson: nekünk is fejlődni kell, hogy az átadott tudás naprakész lehessen. Ezúttal egy olyan fejlődési ponthoz érkeztünk, amely valódi mérföldkő lesz majd a hazai IT security területen. Belevágtunk ugyanis egy szuperprojektbe, méghozzá az ipari biztonság területén.

blogposzt-01.jpg

OT security labor: megnövekedett igényekre reagálunk

Az említett szuperprojekt nem más, mint egy valós környezetet szimuláló ipari környezet kialakítása, amelyben a robotkaroktól a SCADA rendszerig minden megtalálható és minden működőképes. S bár elsőre talán furcsának tűnhet, hogy valaki pusztán tesztelési célból építsen ki egy működőképes ipari, gyári környezetet, az ok nagyon is kézzelfogható: az ipari létesítmények elleni támadások megnövekedett száma. Ráadásul egy gyári környezetben nem feltétlenül állják meg a helyüket a hagyományos IT biztonsági megoldások. Az OT security esetében összetett folyamatokat kell modellezni és egyszerre több terület szakértőinek kell hathatós megoldást kidolgoznia, közösen.

Bár mi sem most kezdtünk el foglalkozni az ipari biztonsággal, mostanra rengeteg tapasztalatra tettünk szert, s egyértelművé vált, hogy még olyan ipari szereplőknél is van mit fejleszteni, ahol amúgy már megbízható biztonsági megoldásokat alkalmaznak. Emellett szeretnénk lehetővé tenni, hogy a gyártók által újonnan piacra dobott technológiákat is ki lehessen próbálni, mielőtt azok az ügyfelekhez kerülnek. Erre pedig a legkézenfekvőbb megoldás egy saját labor felállítása.

Tesztelés hiteles monitoring alapanyaggal

Éles környezetben meglehetősen nehéz és kockázatos tesztelni az OT security monitoring megoldásokat. Ez adódik többek között az ipari környezetek feszített munkarendjéből, még akkor is, ha amúgy a cégnél van olyan IT hálózat, amelyen akár tesztelhetne is. Sokkal hatékonyabb egy olyan OT-s minihálózat, amelyen hiteles hálózati adatokkal, megfelelő monitoring alapanyaggal tudunk mindent kipróbálni, majd prezentálni az ügyfél felé.

Egy ilyen környezetben a piacon megjelenő eszközöket hiteles, egységes tesztmetódussal lehet vizsgálni, így láthatóvá válnak a különbségek, előnyök, hátrányok. Be tudjuk azonosítani azt is, melyek azok a funkciók, amelyekre esetleg csak papíron képes az adott rendszer, de a valóságban nem. Emellett egy ilyen ipari hálózaton megfelelő módon lehet szimulálni a támadásokat is, ami fontos, hiszen a támadási módokat is modellezni kell ahhoz, hogy a megfelelő védelmet kialakíthassuk.

Ugyanígy a napi munkát és a kommunikációt is szimulálni kell, hogy lássuk, pontosan mi zajlik az adott ipari hálózaton belül. Reprodukálhatunk a valós környezetben is meglévő módosításokat - például egy programfutás újraindulását, eszközcserét stb. -, s végül az sem elhanyagolható szempont, hogy egy ilyen rendszer oktatási és prezentációs célokra is kiváló. Ráadásul - bár a gyártás önmagában is fontos terület - akár a közműszolgáltatók esetében is hasznosítható ez a megoldás, sőt, tulajdonképpen bárhol, ahol speciális protokollok és architektúrák vannak (géptermek stb.). Éppen ezért az a célunk, hogy gyakorlatilag bármilyen kiberfizikai hálózatot szimulálhassunk.

Csak a példa kedvéért, a felépítés nagyjából úgy néz ki, hogy adott két darab logikai vezérlő, (PLC), irányított robotkarok, érzékelők és visszajelzők, amelyek csatlakoznak egy SCADA rendszerhez. Utóbbi alapja az ipari irányítási, monitoring és felügyeleti szoftver, amely alapelem az ipari szegmensben. Nyilvánvalóan vannak még hálózati eszközök (switch, router a távoli hozzáféréshez stb.), hogy a többi teszt hálózatunktól is elszeparált ipari hálózatot működtethessünk.Fontos, hogy olyan környezetet szeretnénk, ami hordozható, így adtunk hozzá 4G router plusz egy laptop, amelynek segítségével az OT Security Monitoring eszközeinket tudjuk futtatni és monitorozni ezt a mini hálózatot. Emellett szükséges még egy laptop, amivel a támadásokat lehet szimulálni, azaz pentesztelni, offenzív folyamatokat gyakorolni az ipari környezetekre.

A fentiek közül a PLC-k vezérelte robotkarok talán a leglátványosabbak, de akadnak azért még itt kijelzők, érzékelők (fotocella, súlyérzékelő, mágnesérzékelő stb.) is szép számmal, hiszen szükséges alkalmazkodnunk a szabályozási rendszerek sajátosságaihoz is: a legegyszerűbb példa, hogy kell amikor az egyik robotkar olyan helyre tenne át egy tárgyat, ahol érzékelőnk szerint már van egy másik. A leghétköznapibb esetekre is gondolni kell, mert ezek sokszor váratlan negatív események elindítói lehetnek.

A csapat

Végül álljon itt néhány információ arról is, miként épül fel a fentiek mögött álló csapat, amelybe egyébként önkéntes alapon is jelentkezhetnek azok a kollégák, akinek felkeltette az érdeklődését a labor.

A téma gazdája az EURO ONE-on belül Hunyadi Péter, aki egy meglehetősen embert próbáló és összetett szerepkört vállalt ezzel magára, hiszen több tudományág összpontosul egy kézben. Természetesen ez nem azt jelenti, hogy innentől mindent ő csinál majd egy személyben, hiszen komoly csapatok állnak mögötte (OT szakértők, security mérnök csapat, SIEM-SOARmérnök csapat, kibervédelmi tanácsadó (CDA) csapat, GRC csapat, IDM és access management menedzsment csapat), de egy ilyen projekt esetében nagyon fontos, hogy legyen valaki felül, aki az egészet átlátja, irányítja.

Úgy gondoljuk, hogy Péter és az összeállt csapatok erre a feladatra tökéletesen alkalmasak, és a csapatmunkának köszönhetően ez a gigaprojekt egy működőképes és számos cég számára pótolhatatlan megoldássá állhat össze. Peti itt a blogban is beszámol majd ezentúl a labor fejlődéséről, s természetesen a gyakorlati tapasztalatokról is.

Iratkozz fel youtube csatornánkra, hogy elsőként értesülj Hunyadi Péter bemutatkozásáról. 

Hamarosan indul az InfoSec Akadémia, ahol ipari biztonság témakörben is rengeteg tartalmat és újdonságot találsz majd. Jelenleg előregisztráció zajlik. 

isakademia_l_1200x627.png

OT biztonság: több, mint üzlet

Hunyadi Péter cikke

2021. június 18. - EURO ONE

Mint az élet számos területén, úgy az OT biztonság esetén is komoly szerephez jut az anyagi vonzat. A magánkézben lévő vállalatok esetében a biztonsági fejlesztések tervezésekor sokszor elsődleges szempont a kockázatkezelés ára, ami részben érhető, hiszen a nem adminisztratív jellegű kibervédelem eszköztára komoly kiadást jelenthet még a tehetősebb cégek számára is. Amikor egy ügyfél sajnál jelentősebb összeget fordítani fejlesztésekre, tanácsadókként a bekövetkező támadással – és reputációs veszteséggel – járó anyagi kár túlsúlya szolgál érveink alapjául. Természetesen az anyagi szempontok mérlegelése és a károsodás kockázatának felvállalása a vállalat vezetőinek szíve joga, ám fordul a kocka, ha az esetleges kár nem csupán a saját szervezetüket és üzleti kapcsolatrendszerüket érinti, hanem kihatással van a társadalom egy részére, vagy éppen létfontosságú szolgáltatások működésére is.

ot-factory.jpg

Ennek a cikknek nem célja védelmi tanácsokat adni, inkább arra világítunk rá, hogy az OT biztonság erősítése - amely mindenhol sürgető feladat -, bizonyos ágazatokban a döntéshozók komoly társadalmi felelőssége is.

OT és IT rendszerek, mint létfontosság rendszerelemek

Korábban említettük, hogy az ipari kiberbiztonság szorosan kötődik az állam működéséhez és a lakosság ellátásához. Ez magába foglalja többek között a személy- és áruszállítást, az energetikát, a vízellátást, illetve - ahogy a koronavírus járvány is megmutatta - a gyógyszer- és élelmiszergyártók is ide sorolhatók. Ezekben közös, hogy mind létfontosságú ágazatok, aminek köszönhetően az alkotóelemeik közt bőven akadnak, amelyek a hatályos magyar törvény szerint létfontosságú rendszerelemnek minősülnek. A lista kiemelt elemei az OT és IT rendszerek, amelyek az informatikai hálózatoktól való függőség korszakában az alapvető szolgáltatások legfontosabb összetevőivé nőtték ki magukat, így az előbb említett jogi fogalom ezekre fokozottan vonatkozik.

Ennek ellenére az ipari hálózatok megfelelő védelmének kialakítása és fenntartása nem könnyű feladat a speciális működési követelmények és az ősrégi rendszerek miatt, miközben azonos súllyal kellene kezelni, mint a – legtöbbször jóval komolyabban vett, akár fegyveres – fizikai védelmet.

Valós fenyegetettség, élő példákkal

Arra, hogy a védelem mennyire fontos, már évekkel ezelőtt rávilágított a 2015-ben, Ukrajnában történt kibertámadás, amely kifejezetten az elektromos hálózat ellen irányult, azzal a – feltehetően részben politikai – céllal, hogy kiesést okozzon az áramellátásban. A BlackEnergy néven ismert malware egyik variánsa segítségével kivitelezett incidens három ukrán villamosenergetikai céget érintett közvetlenül, melyeken keresztül 230 000 ember maradt áram nélkül, s velük együtt persze rengeteg cég is így járt. Habár ez a konkrét eset mindössze hat órányi kimaradást eredményezett, azonnal ráirányította a nemzetközi szakma figyelmét arra, hogy ez az alapvető fontosságú szolgáltatás milyen nagy mértékben támadható. Egy évvel később a Crashoverride-ként  (vagy Industroyer-ként ) elhíresült malware okozott három órás áramszünetet Kijev térségében, ez esetben 225 000 felhasználó környezetét elsötétítve. Habár az Ukrajnai támadások relatíve rövid ideig fejtették ki hatásukat, mégis rámutattak, hogy a kritikus információs infrastruktúrák bizony sérülékenyek és támadhatók, s egy ilyen támadás az elkövető kapacitásától, illetve a kivitelezés kifinomultságától függően hat óra helyett akár napokra, vagy annál is hosszabb időre megfoszthat bennünket alapvető szolgáltatásoktól. Ilyen, és súlyosabb esetekre pedig a kiberhadviselésre berendezkedő hatalmak korában sajnos egyre nagyobb az esély.

Államok és árnyak

Dacára annak, hogy alapvetően a nemzetállamoktól érkező, vagy hozzájuk köthető támadások a legfélelmetesebbek (ilyen a fent említett két eset is), komoly fenyegetést jelentenek a bűnözői csoportok is, amelyeknél a fő motiváció, az anyagi haszonszerzés nem feltétlenül keveredik nagy gazdasági és politikai célokkal. Példáért sem kell túlságosan visszamennünk az időben: 2021. május 7-én történt az Egyesült Államokban, hogy a DarkSide névre hallgató kelet-európai bűnözői csoport ransomware támadást hajtott végre a Colonial Pipeline vezetékrendszer üzemeltetője ellen. Az ország délkeleti partvidékének nagy részét - egészen pontosan 12 államot - üzemanyaggal ellátó Colonial Pipeline Co vállalat IT-oldali számlázási rendszerét érte a támadás, viszont az üzleti folyamatok egymásra hatásából kifolyólag, valamint izolációs okokból az OT rendszereket is le kellett állítani.

Ez az incidens hat napos leállást eredményezett, melynek következtében a térségben az üzemanyagárak elérték a 2014 óta tapasztalt legmagasabb szintet, az emberek pánikszerű üzemanyag-felvásárlásba kezdtek, ráadásul a Colonial-tól való függőség miatt zavar keletkezett két nemzetközi repülőtér működésében is, amelyeken így át kellett szervezni a járatokat. Ez a támadás jó példája annak az aggasztó tendenciának, hogy a bűnözői csoportok folyamatosan fejlődnek és hamarosan olyan képességek birtokába juthatnak, amelyeket eddig csak nemzetállamoknál láthattunk. Azonban privát csoportok esetében, a politikai motívum híján, szinte lehetetlen behatárolni a célterületet, egyszóval bármelyik jelentős vállalat, bárhol, bármikor szembenézhet a Colonial-féle esethez hasonló incidenssel.

A bemutatott példákkal szeretnénk megkongatni a vészharangot, hiszen nem tudható, mit hoz a holnap és mekkora horderejű támadásokkal szemben kell váratlanul helyt állni. Itt az idő a közérdeket az üzleti érdekkel szorosan összefűzni, ennek kapcsán pedig megvizsgálni, hogy a minket ért támadások milyen hatással vannak a lakosságra. Ennek megfelelően pedig végre olyan súllyal foglalkozni információs rendszereink megerősítésével, amilyen megilleti azt a társadalmi egymásrautaltság hálójában.



A témában exkluzív anyagokat találsz majd az InfoSec Akadémia hamarosan induló oldalán. Jelenleg előregisztráció zajlik, jelentkezz!
isakademia_l_1200x627.png

 

 

Így vágj bele egy ISMS bevezetési projektbe

Tóth Tamás bejegyzése

2021. június 01. - EURO ONE

Minden projektnek megvannak a maga szépségei, sajátosságai és nehézségei, ez az ISO 27001 szabványon alapuló Information Security Management System (ISMS) bevezetési projekteknél sincs másképp. A cikksorozatom folytatásaként az ISMS projektek általános jellemzőiről, ajánlott indításáról írok a korábbi tapasztalatokat összegezve. 
Az ISMS tévhitekről itt írtam, míg arról hogyan add el a menedzsmentnek itt. 

 

Ha az előző cikk alapján sikerült meggyőzni a szervezet vezetését az ISMS fontosságáról és megszületett a döntés a bevezetési projekt indításáról, felvetődik a kérdés, hogy hogyan érdemes belevágni az egész munkába. Semmiképpen sem szeretném túlmisztifikálni a szabványt és a témakört, de azzal tisztában kell lenni, hogy csupán a szabvány egyes követelményeire vonatkozó sablonok kitöltésére és szabályzatok gyártására szorítkozva nem lehet ISMS-t kialakítani.

 

ISMS bevezetés, mint formális projekt

Az ISO 27000-es szabványcsalád első pár szabványát (pl. 27000, 27001, 27002) olvasva nagyon hamar egyértelművé válhat, hogy a szervezet nem egy könnyű, de egyébként abszolút reális és megvalósítható feladatra vállalkozik. Az ISMS bevezetése hosszú, összetett feladatokból áll, számtalan függőséggel, amelyeken nagyon könnyű elcsúszni. A hagyományos IT projektektől eltérően itt nem csak az IT, hanem az üzleti és a támogató szervezeti egységek, illetve harmadik felek is érintettek, ami azt eredményezi, hogy több szereplőt nehezebb koordinálni, összefogni.

A fenti okok, illetve a későbbiekben részletesen kifejtett okok szükségessé teszik, hogy a szervezet formális projektként, szervezett keretek közt vezesse be az ISMS-t. Maga a feladat aktív projektmenedzsment tevékenységet és részletes tervezést igényel.

 

Scope

A projekt előkészítésének első lépése a scope, más néven hatókör vagy alkalmazási terület meghatározása. A scope-ot több dimenzióban lehet és kell értelmezni: szervezeti egységek és üzleti folyamatok, IT és fizikai lokációk szerint. Szervezeti egységek és üzleti folyamatok szempontjából nem minden ISMS terjed ki az adott szervezet egészére. Nagyobb méretű szervezetek esetén jellemző, hogy csupán egy-egy szakmai terület vagy bizonyos szolgáltatás nyújtásában érintett területek tartoznak az ISMS scope-ba. Nagy szervezeteknél a best practice egyébként is azt javasolja, hogy elsőként csak egy meghatározott területen kerüljön bevezetésre az ISMS, majd a megfelelő érettség után ki lehet terjeszteni, ha "kiforrta magát". Kis szervezeteknél természetesen célszerű lehet az egész szervezetre kiterjeszteni a hatókört, ha ez ellen nem szól semmilyen érv. Az ISO 27001 szabvány erre vonatkozóan nem ír elő követelményt, csupán azt, hogy meg kell határozni és dokumentálni kell a scope-ot.

IT szempontból azok a rendszerek, alkalmazások és hardverek tartoznak a scope-ba, amelyek a scope-ba tartozó üzleti folyamatokat támogatják, azokban felhasznált adatokat kezelik. Az IT scope meghatározásakor a CMDB-t és a szolgáltatáskatalógust lehet felhasználni.

Fizikai lokációk szempontjából a scope-ba beletartozhat egy vagy több teljes telephely, vagy akár irodaházak esetében kijelölt emeletek, vagy korlátozott esetekben csak néhány kijelölt iroda, szerver terem, amelyek szintén a meghatározott üzleti folyamatokat támogatják.

A scope fontossága abban rejlik, hogy az ISMS előírásait, kontrolljait a scope-ba tartozó folyamatokban, rendszereken, hardvereken, és területeken maradéktalanul kell alkalmazni. A scope-ba tartozó folyamatok információs vagyonelemeit kell felvenni és menedzselni, a kockázatokat is ezekkel kapcsolatban kell azonosítani, értékelni és kezelni. Az auditok során a scope-ban lévő elemeket ellenőrzik, de ha az előírások nem teljesülnek maradéktalanul, az sikertelen eredményre vezethet.

A scope-on kívül helyezett elemeket célszerű pontosan meghatározni és formálisan ezeket úgy kell(ene) kezelni, mintha harmadik felek lennének, de ez a gyakorlatban sajnos nem mindig valósul meg megfelelően. 

 

Projekttervezés - szakmai feladatok

Az ISMS projekt lépéseit erősen ajánlott projekttervbe foglalni, amely a bevezetéssel kapcsolatos feladatok lebontását és ütemezését tartalmazza. A projekttervet az elérendő eredmények, állapot alapján mérföldkövekre kell bontani, amelyek részletes szakmai feladatairól a következő cikkem fog szólni.

Az ISMS bevezetési projektek időtervezésére nehéz becsléseket adni, hiszen ahogy a korábbi cikkekben többször kitértem rá, a szervezetek érettségi szintje itt is meghatározó. Példaként kiragadva: nem mindegy, hogy a kockázatkezelési feladatokhoz érve arról kezdünk el beszélgetni, hogy a kockázatkezelésnek milyen módszertanai léteznek, mik az előnyei, kinek kell majd csinálni, vagy esetleg onnan indul a beszélgetés, hogy a risk managerrel áttekintjük a meglévő kockázatkezelési módszertant és csupán kiegészítjük néhány információbiztonsági specifikummal.  Az esetek túlnyomó többségében minden szervezet tanúsítást szeretne, de sajnos erre nem mindegyikük elég érett. Ilyenkor ajánlott egy hosszabb, ISMS-t megelőző felkészülés, az információbiztonság alapok megteremtése, majd ezekre építkezve lehet fókuszáltan az ISMS alkotóelemeit és a kockázatokkal arányos kontrollokat bevezetni. Mindenki a számokra kíváncsi: azt gondolom, hogy egy átlagos kkv. esetén 9-12 hónapnál rövidebb idő alatt nem, vagy rendkívül nehezen lehet működő ISMS-t bevezetni és sikeresen tanúsíttatni. Ezt természetesen sok további tényező befolyásolhatja.

A projekttervben az ütemezésen túl meg kell határozni a feladatok függőségeit is, hiszen vannak olyan feladatok, amelyekkel hatékonyan, párhuzamosan is lehet haladni és természetesen vannak olyan feladatok is, amelyeknél az azt megelőző feladatok értékelését, interjúit, vagy más outputjait kell felhasználni. Ezek a tervezés és szükség esetén az újra tervezés miatt szintén kulcsfontosságúak.

 

Projekttervezés - általános projektmenedzsment

A projekttervezés előző fejezetben bemutatott szakmai részén kívül természetesen elengedhetetlenek a projekttervezés további, jelen esetben "általánosnak" nevezett elemei, amelyek a Projektalapító Dokumentumban (PAD) kerülnek összefoglalásra.

 

Az ISMS bevezetési projektek célja egyértelmű: az ISO 27001 szabványon alapuló Information Security Management System (ISMS) kialakítása és a tanúsítás megszerzése. Az előző mondat tartalmazza a sikerkritériumot is, vagyis a sikeres tanúsítást. A tanúsítás megszerzése utáni, annak fenntartása érdekében végzett feladatok már az ISMS üzemeltetésének számítanak.

 

A PAD másik fontos eleme a projektszervezet és a felelősségek meghatározása, vagyis azoknak a személyeknek az összegyűjtése, akik érintettek a projektben és feladatuk van azzal kapcsolatban. Ezen személyek köre szervezetektől függően változhat, de mégis meg tudunk határozni általános szerepköröket (itt csak a projekt szempontjából legfontosabbakat emelem ki, támogató funkciók nélkül, pl. HR)

Első ilyen szerepkör a menedzsment, vagyis a szervezet felsővezetése, akik elsősorban a projekthez szükséges forrásokat biztosítják, demonstrálják az elkötelezettségüket, részt vesznek és végrehajtják a vezetői átvizsgálást, döntést hoznak az információbiztonsági kockázatokról, célokról, illetve ideális esetben elvárásokat fogalmaznak meg az ISMS-sel és az információbiztonsággal kapcsolatban.

Másik fontos szerepkörbe maga a business, vagyis az üzleti terület döntéshozói tartoznak, akik napi szinten használják a védendő információs vagyont és az információbiztonsági szabályok hatással vannak a munkájukra. Ők rendelkezhetnek jóváhagyási jogkörrel, kockázatokat "birtokolnak" és a saját területükön kikényszerítik a szabályokat. Ők az "első védelmi vonal", nagy valószínűséggel ők lesznek az információs vagyonelemek "tulajdonosai" és a kockázatelemzésbe és más folyamatokba is célszerű bevonni őket, hogy az elvárásaikat megismerve minél inkább hozzájuk lehessen igazítani az irányítási rendszert.

Az IT vezető(k) és az adminisztrátorok nélkülözhetetlen résztvevői az ISMS projekteknek, releváns információkat birtokolnak. A scope meghatározásában, kontrollok érettségének felmérésében, kockázatok értékelésében és kezelésében is sarkalatos a jelenlétük.

Az információbiztonságért felelős vezető és csapata az IT-hoz hasonlóan nélkülözhetetlen a projekt szempontjából, azzal a különbséggel, hogy nagy valószínűséggel az információbiztonságért felelős vezető lesz az ISMS legfőbb felelőse, ezért a tanácsadók által tőle várható a legtöbb információ és igény, tanácsadók igénybevétele nélkül pedig jellemzően ő projekt fő felelőse.

Nem ISMS sajátosság, hogy legyen egy kijelölt projektgazda vagy szponzor, aki mind szakmailag, mind az általános projektvezetés szempontjából döntéshozatali jogkörrel rendelkezik. Ellenkező esetben a döntések lassan, nehezen fognak megszületni, ami valószínűsíthetően a projekt csúszását idézi elő.

 

A PAD-ban kerülnek összefoglalásra a projekttel kapcsolatos költségek, amelyekre az előző cikkemben soroltam fel néhány CAPEX, OPEX példát. Szintén a PAD-ban kerülnek röviden összefoglalásra a részletes projektterv mérföldkövei és azok ütemezése.

 

A leszállítandók vagy másnéven eredménytermékek szintén a PAD-ban kerülnek felsorolásra. Az ISMS projektek leszállítandóit jól elkülöníthető csoportokba tudjuk sorolni. Természetesen ide tartoznak a különféle szabályzatok és eljárásrendek, de vannak "registerek" is, azaz különböző nyilvántartások (pl. információs vagyonelemleltár, kockázati nyilvántartás, CMDB). A feladatok elvégzéséből és a kontrollok üzemeltetéséből előállnak "recordok", vagyis feljegyzések, ticketek, naplóbejegyzések, amelyeket a dokumentált információ elve alapján meg kell őrizni.

 

Mint minden projektben, a hatékony és rendszeres kommunikáció létfontosságú. Az operatív feladatokról szóló, fix időpontban tartott, hetente ismétlődő rendszeres státusz meetingek kijelölésével szintén nem mondok újdonságot. Mindenki elfoglalt, különösen a vezetők, de a projekt előrehaladása szempontjából lényeges, hogy lehetőleg mindenki kezelje prioritásként ezeket a státusz meetingeket. Saját tapasztalatból mondhatom, hogy olyan meeting nem igazán lesz, amit le lehet mondani azért, mert nincs miről beszélni. Alapvető tényként elkönyvelhetjük, hogy senki sem szeret e-mailt olvasni, de hosszabb, informatív e-mailekkel csökkenteni lehet a meetingek számát, és alapos kifejtéssel jó néhány felmerülő kérdést meg lehet előzni, amivel további idő nyerhető a meeting elején tartott bevezetésből.

 

A PAD és a tervezés lényeges eleme a projekttel kapcsolatos korlátok és kockázatok azonosítása. Korlátként fel lehet sorolni olyan komplex feladatokat, amelyek ugyan kapcsolatban vannak az ISMS bevezetéssel, de ha nincsenek betervezve, akkor elvihetik a fókuszt és az erőforrásokat, ezért az ISMS bevezetési projektnek nem lesznek részei. Ilyen feladat lehet a GDPR megfelelés megteremtése, üzletmenet-folytonosság kialakítása és az IT szolgáltatásmenedzsmenttel kapcsolatos tevékenységek.

A projekt kockázatok körébe azok negatív események tartoznak, amelyek bekövetkezése negatív hatással lehet az ISMS projektre. Projekt kockázat lehet a projekttagok leterheltsége, fizetős és belső projektek összeütközése, pandémia, nem megfelelő szabadság szervezés, vagy éppen a kulcsfontosságú pozíciók betöltetlensége, amelyekre valamilyen módon megoldást kell találni vagy el kell fogadni.

 

Ha összeállt a PAD, akkor a kick-off meetingen közzé kell tenni és szükség esetén módosítani kell rajta.

 

Szervezeti változás és kommunikáció

Az előző cikkekben is többször utaltam rá, hogy az ISMS bevezetése egy szervezeti változás, ami az emberi kapcsolatok és a szervezeti működés sajátosságai miatt számos ponton ellenállásba ütközhet.

Ha változásmenedzsmentről van szó, akkor általában John P. Kotter 8 lépéses folyamatmodellje minden esetben megjelenik valamilye formában. A folyamatmodellt külön nem ismertetem, de megfelelő minőségű munkával, szakértelemmel, jó kommunikációval és nyitottsággal minden lépést meg lehet tölteni tartalommal.

Úgy gondolom, hogy a buzzword-dé és közhellyé vált kifejezések helyett arra érdemes koncentrálni, hogy megértsük azt, hogy az adott személy szintjén - nem számít, hogy menedzser vagy üzemeltető - mit tud adni az ISMS, a saját munkája szempontjából, neki konkrétan miért lesz jobb az ISMS szerint működni. Ha ezt megértjük és az ISMS értékeit megfelelően át tudjuk adni részükre, utána a kölcsönös előnyökre alapozva esély lehet egyfajta szövetséget kötni, másrészt talán van rá esély, hogy ennek köszönhetően a nem kevés fáradozás és az elvégzendő munka talán más megítélést kap.

A kommunikáció másik aspektusa a szakmai csapat és a menedzsment rendszeres tájékoztatása mind a projekt, mind az információbiztonság helyzetéről. A kommunikáció tartalmának meghatározásánál figyelembe kell venni a vezetési szinteket és az azokhoz kapcsolódó információigényt. Példaként a kockázatértékelés eredményeinek ismertetésekor a menedzsment tagját elsősorban az fogja érdekelni, hogy a kockázat számszerűsítve milyen esélyekkel és mekkora kárt tud okozni a szervezetnek és azt mennyibe kerül kezelni. Középvezetői, illetve alsóbb szinten természetesen a kockázat kezeléséhez szükséges konkrét intézkedés, a felelős és határidő kijelölése lesz kulcsfontosságú. Számok ismertetésénél külön fontosnak tartom az egyes felmérések módszertanának és a skálák bemutatását, valamint az eredmények következményeit, hiszen ezek nélkül csupán adatokról beszélünk, amiből jó formán semmi sem következik.

 

Konklúzió

A leírtakból talán mindenki számára világossá válik, hogy az ISMS projektek sikere nagyrészt a tervezésen, valamint kialakított tervek betartásán áll vagy bukik. Természetesen nem lehet mindennel számolni, a változásokat nem lehet elkerülni, de a kompetencia, precizitás, agilitás és egyes soft skillek alkalmazása hozzájárulhat a sikerhez.

Az ISMS bevezetés konkrét projekt feladatairól és összefüggéseiről a következő cikkben fogok írni.

Rombolásból pénzeső: így lett virágzó üzletág a ransomware

Krékity Gusztáv cikke

A Ransomware támadások napjaink egyik komoly fenyegetése a szervezetekre és a magánszemélyekre nézve is. Ma ez a támadási forma jelenti az egyik legnagyobb veszélyt a kibertérben és ad szinte biztos megélhetést a kiberbűnözőknek. Ha még nem olvastad az előző bejegyzésünket a ransomware alapokról, kezdd ott az olvasást. Itt találod. 

blogbejegyzes-ransowmare-cikk-2_-resz.png

Az elmúlt években átlagosan 20-25%-kal gyakrabban csaptak le az áldozatokra a támadók. A megkövetelt váltságdíjak összege is jelentősen emelkedett, ráadásul egyre kisebb valószínűséggel kapjuk meg a visszafejtéshez szükséges kulcsokat a támadóktól miután fizettünk. 2019-ben egyetlen támadás során átlagosan 41 ezer dollárt követeltek az adatok helyreállításáért cserébe, de 2020 első negyedévében már 84 ezer dolláros igényekkel lehetett kalkulálni, ami egy év leforgása alatt 104%-os növekedést jelentett. A támadások szaporodásával 2020 második felére ez már az átlag 154 ezer dollárt is elérte.

1_6.jpg

2_5.jpg

Arra gondoltunk, ennek kapcsán átnézzük, milyen közgazdaságtani hatásai vannak a zsarolóvírus támadásoknak és tisztázzuk, pontosan miért is szeretik ezt a támadási formát a kiberbűnözők. De kitérünk majd arra is, hogy jelenleg kik jelentik a támadók fő célközönségét és miért. Első lépésben lássuk, mi is pontosan a ransomware.

Mi is az a ransomware?

Bár napi szinten van már jelen a köznyelvben, mégis akadnak még félreértések, ha elhangzik a ransomware kifejezés. Kanyarodjunk hát vissza egy kicsit az alapokhoz. A ransomware olyan rosszindulatú, kártékony program, amely egy erős titkosítási algoritmus segítségével zárolja a szervezetek - vagy akár magánemberek - számára fontos adatokat, esetleg a napi szintű működéshez elengedhetetlen végpontokat, szervereket, sőt, néha akár még a backup rendszereket is, hogy végképp lehetetlenné tegye a visszaállítást. Miután a támadó sikeresen zárolta az adatokat és az erőforrásokat, egy üzenet jelenik meg a képernyőn, amelyben részletes útmutatást kapunk a teendőkről, amennyiben vissza szeretnénk kapni adatainkat. Ezen a ponton a szervezeteknek dönteniük kell, hogy fizetnek vagy sem. Ha van olyan mentés, amiből visszaállítható a támadás előtti állapot, akkor szerencsés helyzetben vannak, feltéve, hogy a támadó a támadást megelőzően nem volt tartósan jelen a rendszerekben, mert ez esetben a visszaállást követően jó eséllyel újfent számíthatunk egy zsaroló támadásra. Amennyiben nincs backup, de az adatok, amelyeket elvesztettünk nem értékesek, akkor a legjobb egyszerűen legyinteni és lemondani a támadó által titkosított adatokról, mert akkor sincs garancia arra, hogy valóban megkapjuk a visszaállításhoz szükséges kulcsot, ha fizetünk. Zárójelben jegyezzük meg, hogy az USA-ban például olyannyira nem támogatják a zsarolótámadások esetén a fizetést, hogy az Egyesült Államok Pénzügyminisztériuma szankciókat szeretne érvényesíteni azokkal a szervezetekkel szemben akik, fizetnek.

A legtöbb támadás opportunista, tehát könnyű anyagi vagyonszerzés a célja, minimalizált energia- és időbefektetés mellett. A pénzügyi indíttatású bűncselekmények más formáihoz hasonlóan a számítógépes zsarolást is az alapgazdaságtan hatalmi törvényei vezérelik: a ransomware előállítási, eladási és az értékesítésből (zsarolásból) származó nyereség végösszege adja a támadó motivációját. Amennyiben sokan fizetnek, az jelzés értékű a támadók számára, hogy a választott támadási módszer célravezető, s azzal gyorsan és könnyen lehet sok pénzt keresni, maximalizált profitot termelni.

Az utóbbi időben azonban csökkenő tendenciát mutatott a fizetési hajlandóság, amire a támadók az úgynevezett kettős zsarolási eljárással reagáltak: az első zsarolási faktor továbbra is az adatok visszafejtéséhez szükséges kulcs megvásárlása, ám ha az áldozat nem hajlandó fizetni, akkor az üzenet szövege megváltozik, s már arról szól, hogy az adatokat nem csak titkosították, de el is lopták azokat. Innentől kezdve nem a titkosítás feloldásáért kellene fizetni, hanem azért, hogy ne publikálják a bizalmas információkat. Márpedig ez meggyőzőbb érv, hiszen ez már nem csak adatok vesztésével, hanem reputációvesztéssel, sőt, akár komoly jogi következményekkel is járhat. Sokan ezen a ponton fontolják meg a fizetés lehetőségét, de ebben az esetben sincs garancia arra, hogy adataink válnak publikussá.

2020-ban azok a cégek, ahol nem csak a titkosítás történt meg, hanem konkrét adatveszteség is bekövetkezett, 74,8%-ban fizettek a támadóknak, de számtalan olyan példa van, ahol a támadók a megadott idő leteltével a fizetés ellenére is publikálták a bizalmas adatokat, vagy egyszerűen továbbértékesítették azokat a sötét weben.

Minél nagyobb célpont ellen irányul egy támadás, annál jelentősebb a zsarolás mértéke, de a támadónak is annál inkább érdeke, hogy ne csak egy ponton tudja biztosítani nyereségét, hanem legyen egy másodlagos adu a kezében arra az esetre, ha az áldozat mégsem fizetne.

Erre azért van szükség, mert a nagyobb szervezetek sokkal masszívabban védett célpontok. Az ellenük tervezett támadás során sokkal több időre és szakértelemre van szükség a támadás sikeres kivitelezéséhez, sőt, legtöbb esetben az ilyen célpontokhoz meglehetősen költséges, úgynevezett 0-day (zero-day) sérülékenységeket is ki kell használni, amelyek esetleg csak egy alkalommal lesznek bevethetők. Emellett sok olyan tényezővel - például a rendszer változásaival, frissítésekkel - is kell kalkulálni amelyek, zátonyra vihetik a hetekig-hónapokig tartó, gondos előkészületeket. A zsarolás során igényelt váltságdíj általában tükrözi az erőfeszítést, befektetett időt, tudást, kockázatot és költségeket is.

A legfőbb támadási vektor egy ransomware offenzíva során

Minden sikeres támadásnak van egy kezdő lépése. Az elmúlt években a domináns támadási vektor az e-mail phising volt, amelyet viszonylag nagy lemaradással az RDP, illetve a mezőnyben harmadik helyen végző szoftveres sérülékenységek követtek. A prekurzor rosszindulatú programok, mint például a Trickbot vagy az Emotet az adathalász kampányokat részesítik előnyben elsődleges támadási mechanizmusként. Sokszor egy ilyen támadás alkalmával férgeket telepítenek az áldozat hálózatában, amelyek lehetővé teszik, hogy a vállalati hálózaton keresztül tovább tudjanak terjedni, illetve belépési pontokat helyezzenek el az ellátási láncban (Supply Chain), amelyet közvetlenül eladhatnak olyan bűnözőknek, akik éppen zsarolóvírusos támadáson gondolkodnak.

3_4.jpg

Kik válhatnak elsődleges célponttá?

Legegyszerűbb válasz talán az, hogy bárkiből lehet áldozat, hiszen a biztonsági szakértők szerint immár nem az a kérdés, hogy kinek a rendszerét törik fel, inkább az, hogy mikor. A támadók nem válogatnak szervezeti méret vagy bevétel szerint. A kisvállalkozások nem rendelkeznek fejlett védelmi és detektáló megoldásokkal, így könnyű célpontnak számítanak, viszont a méretesebb vállalatok jelentősen nagyobbat bukhatnak, s persze nagyobb a tőkéjük is, amiből fizethetnek. Cserébe sokkal fejlettebb védelmi megoldásokkal biztosítják rendszereik védelmét és adataik sértetlenségét. Az utóbbi időben a legelsöprőbb támadási hullámot a közép-piaci vállalatok szenvedték el, mivel ezek jellemzően ugyanolyan könnyedén feltörhetők, mint a kisvállalatok, ellenben jobb fizetési képességekkel rendelkeznek.

4_2.jpg

A szervezeti egység mérete mellett megvizsgálhatjuk azt is, az elmúlt éves során mely iparágak voltak érintetek a támadásokban. Jól megfigyelhető, hogy leginkább a professzionális szolgáltatásokat nyújtó vállalkozások estek áldozatul, így például pénzügyi vagy jogi szolgáltatásokat nyújtó szervezetek. Ennek oka egyszerű: bár ezek a szervezetek általában rendelkeznek IT biztonsági megoldásokkal - például tűzfal, email szűrés, végpont védelem stb. - és belső céges szabályzatokkal, de kiemelten tárolnak rendkívül bizalmas adatokat, amelyek elvesztése végzetes is lehet a cégre nézve. A legnagyobb gond - amit a kiberbűnözők szívesen kiaknáznak -, hogy ezek a szervezetek a bizalmas adatok tárolása ellenére sem tartják magukat potenciális célpontnak, s elegendőnek érzik a meglévő védelmi megoldásokat. Kialakult bennül egyfajta hamis biztonságérzet, amely miatt nem frissítik és nem fejlesztik a már meglévő, egykor talán megfelelő szintűnek számító védelmi megoldásokat, szabályzatokat.

5.jpg

Egy jól fizető támadóeszköz

A ransomware az egyik legjobban fizető támadási forgatókönyv, mivel a zsarolások összege egyre csak növekszik, s a kettős zsarolási eljárásnak köszönhetően az áldozatok túlnyomó része inkább kifizeti a megkövetelt váltságdíjakat, annak ellenére is, hogy nincs garancia az adatok visszaállíthatóságára vagy épp arra, hogy az elvitt adatokkal nem találkozunk majd egy weboldalon. Még az sem biztos, hogy nem kerül a cég az újságok címlapjára, amikor kiderül, hogy elvesztette az ügyfelek, partnerek bizalmas adatait. Egészen addig, amíg a támadások során a támadó oldal számára nagyobb a profit, mint a befektetés, a zsarolóvírusokra épülő támadások és variánsok száma rohamosan növekedni - és sajnos fejlődni - fog a jövőben is.

A RaaS üzleti modell egyre népszerűbbé válik és a modell terjedésével már nem korlátozódik a zsarolóvírus kódja az azt létrehozó fejlesztőkre. A ransomware fejlesztők inkább értékesítik a kódokat, ami egyrészt jó a vásárlónak, hiszen csak használnia kell egy kész eszközt, és tökéletes a fejlesztőnek is, hiszen minimalizálja a saját kockázatát azzal, hogy nem szükséges támadást végrehajtani a profit reményében.

Amennyiben részletesebben is érdekel a RaaS, olvasd el a témában hamarosan megjelenő következő cikket is.

Iratkozz fel a listánkra, tanulj tőlünk az IT biztonságról. FELIRATKOZOM

Ne építsünk égő házat, avagy ilyen, ha az üzemeltetés segítségre szorul

Becker Zoltán cikke #adatközpont

2021. április 26. - EURO ONE

Minden bizonnyal nem árulunk el hatalmas titkot, ha azt mondjuk: mindenkinek a saját feladata a legfontosabb és a többségben fel sem merül, hogy esetleg a kapcsolódó tevékenységekkel kapcsolatban is érintett lehet. Ez gyakran előforduló probléma az IT üzemeltetés területén is.

Egy üzemeltetési probléma jellemzően technikai erőforrás kérdésekből, kimutatási vagy riport kérdésekből adódik. Másrészt azonban komoly tényező lehet az emberi oldal is, éppen ezért érdemes e két dolgot elkülönítve is megközelíteni.

Kezdjük ott, hogy ahány ember, annyiféle nézőpont: ugyebár vannak az üzemeltetők, akik teljesen mást gondolnak arról, mikor van szükségük segítségére, mint amit az ő közvetlen vezetőjük. És még ez sem az összes aspektus, hiszen a hierarchia legtetején találjuk az IT vezetőt, aki ugyancsak a saját szemszögéből figyeli a dolgokat. Emellett pedig ott van még az ügyfél is, aki szintén jelezheti, ha problémát észlel, s minden bizonnyal számára is az lesz a fő vonulat, ami közvetlenül őt érinti.

adatkozpont-blog-cikk-ne-epitsunk-ego-hazat_v2.jpg

A problémák beazonosítása

Van egy mondat, amely az esetek többségében előkerül egy üzemeltetői probléma kialakulásakor: “sajnos semmire sincs időnk”. Ennek elhangzása egyike az első jeleknek, amelyekből már sejthetjük, hogy valami nincs rendjén. Szintén klasszikus égi jel, amikor azt tapasztaljuk, hogy egyre több a visszatérő probléma (erről beszéltünk egy korábbi cikkünkben is ITT), illetve az is, amikor a problémák tömegesen jelentkeznek. Ekkor már látszik, hogy valami nem megfelelően működik, és felmerülhet a tervezés szükségessége.

Időnként előfordul, hogy az üzemeltetés annyira szegmentált, hogy a probléma megoldása két terület között akad el, ilyenkor az érintett területek képviselői egymásra mutogatnak. Ennek sajnos a jövőre nézve sincs jótékony hatása (legfeljebb elmérgesíteni lehet vele a munkahelyi kapcsolatokat, ami tovább gátolhatja az együttműködést), és a probléma megoldását sem szokta elősegíteni.

Sajnos jellemző probléma az is, hogy üzemeltetés nem követi nyomon a rendelkezésre álló hardver, szoftver, licenc mennyiséget. Ennek egyenes következménye a munka elakadása, amint elfogynak az erőforrások.

A problémák megoldása

Ha sikerült beazonosítani egy problémát (pláne ha még a kezdeti szakaszban elcsíptük), az kétség kívül nagy előrelépés. A kérdés már csak az, hogy ilyenkor az üzemeltetői oldal felől, vagy fentről érdemesebb-e megindítani a problémamegoldást.

Nos, szerintünk ez kétirányú. Egyrészt minden ilyen csapatban van egy-két olyan ember, aki képes kicsit felülről nézve, tágabban tekinteni a problémára. Az már csak a hab a tortán, ha képes a kollégákat is ebbe az irányba terelni. Mindenesetre inkább az a jellemző, hogy az üzemeltető észreveszi, érzékeli a problémát, de kevésbé jellemző, hogy egyben megoldással is ő szolgáljon.

S itt jön a képbe a csoportvezető, a közvetlen felettes, az, akinek minderre figyelnie kell, s akinek a hierarchiát tekintve is megvan a lehetősége, hogy erre a szemléletmódra rávezesse a többieket, vagy konkrét megoldást adjon a kezükbe. Általában ő az, akinek feltűnik, hogy folyamatosan csúszásban vannak, egyre több a munka, s egyre kevesebb feladat elvégzésére jut idő. Mindig előre kell venni valamit, semmi nem készült el időre, állandóan haladékot kell kérni az igénylőtől vagy a felettesektől, s az ő tevékenysége is lassan abból áll csak, hogy állandó operatív munkát végez, vagyis a problémákat és az embereket menedzseli. Pedig egy csoportvezető ennél azért többre hivatott, s ha bekerül ebbe a mókuskerékbe, azzal csak egy bizonyos szintet lehet tartani, de előre jutni és hosszú távú megoldásokkal szolgálni aligha.

El kell érni, hogy a csoportvezetőnek jusson ideje a tervezésre, fejlesztésre, hogy indukátorként működhessen és segítségével a csapat is megfelelő ritmusban, tervek alapján tudjon előrehaladni. Ha ez elmarad, az csak újabb problémákat generál. Ha azonban sikerült ezt elérni, általában az is rögtön kiderül, hogy nem az erőforráshiány, hanem a rosszul menedzselt folyamatok jelentették a fő gondot. Ezeket kell tehát tiszta fejjel, felülről áttekintve rendezni.

Éppen ezért egy csoportvezető legfontosabb feladata a folyamatok kitalálása, felügyelete, azok racionalizálása, s amennyire csak lehet - ez ugyebár trendi téma manapság - azok automatizálása is. Ez utóbbit illetően is neki kell átlátnia, mivel lehet segíteni az üzemeltetők munkáját, mi az, amit az automatizálással rábízhatunk a gépre, hogy időt nyerjünk.

A menedzsment szint

A fenti folyamatokon keresztül kiderülhet egy csoportvezetőnél, mikor érkezik el arra a pontra, amikor segítségre van szüksége, még ha nem is feltétlenül veszi ezt észre. A következő szint pedig az IT vezető, azaz a menedzsment szint.

Itt is akad két-három olyan eset, amikor a menedzsment észlelheti ha gond van. Az egyik, hogy házon belül jutnak el hozzá a problémák, vagyis az alatta lévő középvezetőkön is átívelnek. A másik - ami egy menedzsmentnél klasszikus esetnek számít -, amikor SLA riportokat, teljesítménymutatókat (KPI) néznek, s ha azokat rendszeresen olvassák és elemzik, könnyen feltűnik, hogy valahol porszem került a gépezetbe.

A harmadik eset - amelyiket valószínűleg minden cég szeretne elkerülni -, amikor az ügyfelektől érkezik visszajelzés. Lássuk be, ha az ügyfél annyira elégedetlen a szolgáltatással, hogy közvetlenül a menedzsmentet keresi, ott már nagyon ég a ház.

Menedzsment szinten a legfőbb kihívást az jelenti, hogy mielőbb sikerüljön beazonosítani, pontosan hol bújik meg a probléma oka. Ki kell deríteni, hogy emberi mulasztás, esetleg hardveres erőforrás okozza-e, vagy mondjuk a folyamat egy bizonyos pontjával van gond. Ez az a rész, ahol a menedzsment szorulhat a középvezetők segítségére.

Ne építsünk égő házat, avagy a probléma megelőzése

Az eddigiek alapján úgy gondoljuk, a folyamatoknál alapvető, hogy azok átgondoltak, racionalizáltak és az üzemeltetők számára is komfortosak legyenek. Ez az egyik legfontosabb.

Emellett a folyamatokba be kell építeni olyan eszközöket, amelyekkel kimutathatóvá válnak a belefektetett idők, energiák, vagyis statisztikák nyerhetők ki róluk. Így például ha veszünk egy helpdesket, akkor tudnunk kell összegezni az emberek munkáját, a feladatok végrehajtásának idejét, az esetleges teljesülési hiányosságokat. A céges szintű jelentések és csoportszintű beszámolók egyaránt fontosak.

Meg kell találni azokat a termékeket, amelyeket használva kimutatásokat készíthetünk a folyamatok egyes pontjain. Az is nagyon fontos, hogy ezek a riportok, ne másfél-két napos munkával előállítható Excel táblázatok legyenek, feldobva pár kördiagrammal. Ehelyett egyszerűen, gyorsan elkészíthető, nagyon könnyen összehasonlítható kimutatásokra van szükség, ahol egy-egy aktuális értéket villámgyorsan össze lehet hasonlítani az elvárttal. Érjük el, hogy akár a nap végén egyszerűen lehessen lehúzni egy ilyen jelentést. Ez nagyon fontos, hiszen ha egy ilyen beszámoló elkészítése túl sok időt emészt fel, akkor ez lesz a gátja annak, hogy megfelelő visszajelzéseket kapjunk.

Ezekre a feladatokra egyébként bőven akad megfelelő eszköz. A teljesség igénye nélkül ilyenek a különféle helpdesk rendszerek (OTRS, ServiceNow, Freshdesk, ManageEngine…stb). Ezek mindegyike képes jelentéseket készíteni a benne végrehajtott feladatokról. Az ezekben használt ticketek végrehajtása folyamathoz kötött, az ezeken alapuló workflow-k és tevékenységek mind-mind több szinten riportozhatók, tehát akár egy csoportvezető is lehúzhatja magának a statisztikát, például arról, hogy mennyi nyitott jegy van, mennyi van közülük csúszásban, az egyes embereknél mennyi feladat áll. Így rögtön le lehet szűrni, hogy ki az, aki túlterhelt vagy éppen kinek nem jutott feladat. Így optimalizálhatók a folyamatok.

Technikai oldalról térjünk még vissza egy kicsit a monitoringhoz, vagyis hogy miként állnak a hardver erőforrások, a rendelkezésre álló erőforrások, vagy akár a rendelkezésre álló licencek. Ezek technikai dolgok, amelyeket egy monitoring rendszer képes folyamatosan figyelni, követni, képes ezekről trendeket, grafikonokat készíteni, szükség esetén riasztást generálni, és adott időközönként - nyilván itt a hierarchiától függően negyedévente, félévente, évente - készíthet olyan beszámolókat is, amelyekből az erőforrás használati trendek követők. Így ha veszünk egy csoportvezetőt, ő is megnézheti, hogy akár az elmúlt egy hónapra visszamenőleg miként fogytak el a tárhely kapacitások, mennyiben nőtt a virtuális környezetek memória és CPU terhelése, és ebből következtethet arra, hogy a beérkező feladatok, igények és az elfogyott erőforrások között van-e összefüggés? Ebben az esetben akár ő maga is elindíthatja az erőforrásbővítési folyamatot, vagy módosíthat úgy folyamatokat, hogy nagyobb kontrollhoz jusson. Így például elkerülhető, hogy mindenki, minden részfeladatra újabb virtuális gépet kérjen, s így egy idő után már ezer darab virtuális gépünk legyen, amelyek közül ötszáz ugyanazon a feladaton dolgozik.

Tehát a monitoring rendszer technikai statisztikái, grafikonjai, és az emberi erőforrásra vonatkozó jelentések remekül párhuzamba állíthatók. Mindez pedig jól jöhet az éves tervezéseknél, a jövő évi tervek készítésénél is, hiszen így könnyebben kideríthető, miként növekedhetnek az erőforrás igények az ügyfelek oldaláról és saját részről.

A lényeg az, hogy mindig azt a pontot, azt a helyet, azt az embert, azt a csoportot kell tudni pontosan meghatározni, ahol a beavatkozásra, segítségre szükség van.

Ransomware alapok, avagy a zsarolóvírusok térhódításának története

Krékity Gusztáv cikke

2021. április 15. - EURO ONE

 Lassan nosztalgiával gondol vissza az ember az egykori DOS-os vírusokra, amelyek ugyan kalandosabbá tették az IT szakemberek életét, de a legtöbb átlagfelhasználó sosem találkozott velük, csak a róluk szóló horror-sztorikkal (kivételt talán csak az iskolai számítógépek jelentettek, amelyeken valahogy mindig megjelent egy-egy képviselője a kor malware-inek). Aztán a digitális kártevők rohamos fejlődésnek indultak, s mára a kiberbűnözők népszerű, napi szinten használt eszközévé váltak. Mostanság ezen bűnös eszköztár legnépszerűbb darabjai a különféle zsarolóvírusok, avagy a ransomware programok.

blogbejegytes-ransomware-01.jpg

Nem ma kezdték

A ransomware őrület ugyan a 2000-es években burjánzott el igazán, de valójában már a 90-es évek előtt is velünk voltak ezek a malware-ek. Az első zsaroló kód 1989 decemberében látott napvilágot és fertőzött flopi lemezeken terjedt, amelyeket - körülbelül 20 ezer példányban - egy AIDS konferencia résztvevőinek kézbesítettek. A lemezeket AIDS Information – Introductory Diskettes címkével látták el, hogy növeljék a támadás hatékonyságát, s - az emberi kíváncsiság végett - minél biztosabb legyen, hogy a címzett megnézi majd a lemez tartalmát. Aki így tett, egy üzenttel szembesült, mely szerint 189 dollárért (USD) cserébe újra hozzáférhet titkosított adataihoz. Így kezdődött, de mára, hatékonyság tekintetében jelentősen túlnőttek a zsarolóvírusok az ősökön.

Amikor a ransomware berobbant a kiberfenyegetések világába, még egy kategóriába sorolták az olyan megoldásokkal, mint például a FAKEAV, amely hamis vizsgálati eredményeket készített, hogy rákényszerítse az áldozatokat hamis antivírus szoftverek megvásárlására. Aztán az idő haladtával a sikeresebb ransomware családok fenyegetőbbé váltak: elkezdték a fájlokat nagyszámban titkosítani. Ám a kezdetben okozott sokk után ez a taktika idővel elvesztette hatékonyságát, mert a szervezetek rájöttek, hogy rendszeres biztonsági mentéssel csökkenthető a zsarolóprogram okozta veszély és megelőzhetők a komoly károk. Bizonyos értelemben a zsarolóvírusok hírneve csökkeni kezdett és besorolásuk a veszélyesről a kellemetlenre szelídült. Nagy kár, hogy mindez csak ideiglenes folyamat volt.

2016-ban és 2017-ben számos új zsarolóvírus-család jelent meg, amelyek hatalmas pusztítást végeztek világszerte. Ezekre a kiterjedt ransomware támadásokra válaszul a szervezetek megerősítették védekezési képességeiket. 2018-ra úgy tűnt, hogy a zsarolóvírusok fejlesztése visszaszorul, mert a kriptovaluta bányászatra alkalmazott vírusok elkezdték megelőzni őket a népszerűségi listán. Ám mind kiderült, ez is csak átmeneti visszaesés volt, mert még abban az évben megérkezett a Ryuk, amely magasabbra helyezte a lécet és fordulópontot hozott a zsarolóvírusok életében.

A Ryuk az első dokumentált ransomware volt, amelyet célzott támadásként alkalmaztak. A trickbot és annak moduljai segítségével terjesztette és telepítette a powershell empire-t. Az oldalirányú mozgáshoz kiterjedten használta a PowerShellt és a WMI-t is. 2019-re a ransomware támadások célzottabb megközelítést alkalmaztak, amely 2020-ra már normává vált.

1_1.png

A zsarolóvírusok (ransomware) fejlődésének idővonala

Míg 2019-ben még csak 95 ransomware család létezett, amelyekkel a támadások során találkozhattunk, addig 2020-ban már 127 családra bővült a választék, s 2021-ben ez a szám jelentősen tovább növekedhet.

Mi az a kettős zsarolás?

A kettős zsarolás kiemelkedett a ransomware programok közös vonásai közül és az adatsértések jelentős részében szerepet kapott. A kiberbűnözők ebben az esetben nem csak titkosították az adatokat és blokkolták a hozzáférést, hanem azzal is fenyegetőztek, hogy publikálják a megszerzett adatok másolatát, amennyiben nem teljesítik követeléseiket. Ez a szervezetek számára jelentősen megnövelte a kockázatot, viszont éppen ezért fokozta a zsarolóprogramok elleni védekezési képességek erősítésére tett erőfeszítéseket is. Az ugyanis egy dolog, ha egy cégnek esetleg adatvesztése származik egy-egy támadásból, de a nagyobb szervezetek számára, amelyek rengeteg érzékeny, bizalmas, adott esetben személyes információval dolgoznak, ezek kéretlen publikálása egyenesen végzetes lehet. Egy ilyen támadás esetén nem csak az anyagi veszteségtől, de a hírnév elvesztésétől és a kemény munkával felépített imázs teljes összedőlésétől is retteghetnek.

2_1.png

2019.November és 2020 Október közötti Ransomware támadások, amely kettős zsarolást hajtottak végre

 

Az, hogy az adatokat már nem csak az áldozatok rendszerein belül titkosították hanem egy füst alatt el is lopták, megteremtette a célzott támadások megközelítésének lehetőségét. A támadók ismert taktikákat, technikákat és eljárásokat (TTP-t) használtak, amelyek nem különböztek más APT- vagy célzott támadásoktól.

A ransomware támadások négy szakasza

A tipikus ransomware támadási folyamatok jobb megértése érdekében lebontjuk, hogy egy támadás vagy kampány milyen szakaszokból és összetevőkből áll. A 2020-as ransomware támadások átlagosan négy fő szakaszra voltak oszthatók.

3_2.png

Minden szakasz magába foglalja az eszközöket és a technikákat, amelyek egyedi célokhoz lettek hozzáigazítva:

  1. Kezdeti hozzáférés
    Többféle módszert is alkalmazhatnak a rendszer gyenge pontjának meghatározásához. Céljuk a leghatékonyabb és leggyorsabb behatolás megtervezése, például egy adathalász levéllel vagy valamilyen publikus sérülékenység kiaknázásával.
  2. Hálózat felderítése és oldal irányú mozgás
    E lépés során a támadók elkészítik az áldozat hálózatának leltárát. A támadó ezt követően vagy tovább értékesíti a megszerzett adatokat - a dark weben, egy fórumon stb. - vagy közvetlenül maga folytathatja a kinyert információk alapján a megtervezett támadást.
  3. Adatszűrés
    Ez a folyamat elengedhetetlenné vált a kettős zsarolási elv megvalósításához, ugyanis mielőtt még titkosítani kezdenék az áldozat adatait, a Ransomware készítője előbb fontos adatokat lop el az áldozattól. Ezek általában rendkívül érzékeny információk - például szellemi tulajdon, szerződések, személyazonossági adatok -, amelyeket feltöltenek felhőbe vagy akár egy FTP szerverre.
  4. Ransomware telepítése
    Az adatok ellopásával folytatódhat a támadás és telepíthető a zsarolóvírus az áldozat rendszerébe. Első lépésként a kliens védelme és a futó folyamatok kerülnek leállításra, hogy biztosan telepíthető legyen a kártékony kód. A támadók rendszerint törlik a naplókat is, hogy lehetőleg ne maradjon digitális lábnyom utánuk, így nehezebb legyen kideríteni, hogy mi is történt valójában.

Zsarolóvírus, mint elsődleges fegyver

Az elmúlt években a ransomware elsődleges fegyverré vált a gyors vagyonszerzésre törekvő kiberbűnözők kezében. Bár a WannaCry és a Petya által okozott károk óvatosabbá tették az embereket, illetve a szervezetek is következetesebb biztonsági intézkedéseket vezettek be a fenyegetések ellen, sajnos ezzel egy időben a támadók is egyre szofisztikáltabb megoldásokat vetnek be, hogy továbbra is sikeres támadásokat hajthassanak végre. Az elmúlt évben például egyre többször okozott problémát, hogy a ransomware programokat célzott támadások során alkalmazták és már nem csak titkosították az érzékeny adatokat, hanem meg is szerezték azokat. A kettős zsarolás technikájára támaszkodtak, hogy még inkább sarokba szorítsák és hatékonyabban zsarolhassák áldozataikat.

Miért figyeljünk a zsarolóvírusokra?

A ransomware támadások súlyos hatással járhatnak és semmi garancia nincs arra, hogy a felhasználó adatait visszaállítják, akkor sem, ha az áldozat hajlandó ezért kifizetni a váltságdíjat. Ilyen következmények például:

  • Személyes szinten a pénzügyi kár vagy érzékeny személyes adatok nyilvánosságra kerülése.
  • Céges szinten ilyen lehet az üzleti folyamatok megakasztása, a pénzügyi kár - akár kifizetés esetén vagy épp a kivizsgálás költségessége miatt -, de sérülhet a cég jó híre is, ami a jelenlegi és a potenciális üzletfelek elvesztését okozhatja.

Ráadásul a ransomware célja nem mindig a pénzszerzés, hanem akadnak egyéb okok is egy ilyen jellegű támadás mögött: lehet a cél figyelemelterelés, álcázhat hagyományos hálózati támadást, elfedheti egy korábbi támadás nyomait, leplezhet egy éppen zajló hálózati adatlopást, vagy éppen korlátozhatja - illetve adott esetben meggátolhatja - a rendszer produktivitását, míg az IT csapat éppen a felfedezett zsarolóvírus fertőzéssel küzd.

Fizetni vagy nem fizetni, ez itt a kérdés?

Egy sikeres zsarolóvírus támadás áldozatainak kulcsfontosságú döntést kell meghozni, amikor szembesülnek azzal, hogy idegenek titkosították a számukra és ügyfeleik számára kritikus fontosságú, érzékeny információkat, sőt rosszabb esetben le is nyúlták azokat. Fizessenek váltságdíjat vagy sem?

Nos, a váltságdíj kifizetése egy olyan opció amely néha a probléma enyhítésének leggyorsabb és legegyszerűbb módjának tűnhet, különösen abban az esetben, ha nem rendelkezünk biztonsági mentéssel - vagy más helyreállítási lehetőséggel - a rendszer gyors visszaállításához. A kezdeti pánik hevében sokszor fizetnek a cégek, akik nem rendelkeznek megfelelő tudással és szakértelemmel egy ilyen jellegű incidens kezeléséhez és helyreállításához.

Minden esetre azzal érdemes számolni, hogy az esetek többségében a tolvajok között nincs becsület, tehát még ha fizetünk is, nincs rá garancia, hogy a bűnözők valóban átadják a visszafejtéshez szükséges kulcsokat és eszközöket, vagy adott esetben nem publikálják az eltulajdonított adatokat. Sőt, arra sem, hogy nem érkezik később tőlük újabb zsarolás, immár nagyobb tarifával. Továbbá - ami nagyon fontos tényező egy sikeres támadást követően -, ha fizetünk, semmi nem fogja azt garantálni, hogy a közeljövőben nem leszünk ismét támadók áldozatai között. Gyakori eset ugyanis, hogy a fekete kalapos hacker, miután felderített egy céges infrastruktúrát és sikeres támadást hajtott végre, egész egyszerűen továbbadja az információkat a dark weben, más kiberbűnözőknek.

Összegzésül

A ransomware támadások évről évre a legkedveltebb támadási eszköznek számítanak a kiberbűnözők körében. Egyes esetekben csak a gyors, egyszerű pénzszerzés, vagy épp a rombolás a cél, de egyre több esetben alkalmazzák ezeket az összetett támadások során is. Az egyik legfontosabb oka annak, hogy a bűnözők továbbra is sikeresek a ransomware támadások terén az, hogy képesek kihasználni a sebezhető pontokat, amelyek egyszerűen lefedhetők lennének megfelelő fejlesztésekkel, egy biztonságtudatos fejlesztési terv mentén felépíthető többrétegű védelmi rendszer kialakításával. Ám a szervezetek sok esetben nem hajlandók erre, csak miután már megtörtént a baj.

A zsarolóvírusok jövőjét tekintve folyamatosan növekvő trendre lehet számítani és nagy valószínűséggel a RaaS modell is egyre népszerűbb lesz, amelyben a támadók szolgáltatásként bérelhetnek támadóeszközt. Várható az is, hogy egyre több esetben érvényesül majd a kettős zsarolási stratégia, amely miatt még nagyobb károkat szenvedhetnek el az áldozatok. Egyre több teljesen új mellett a már meglévő kártékony kódok variánsai is folyamatosan látnak napvilágot, ami megnehezíti a védekezést.

A közeljövőben többször is foglalkozunk még a témával és több, zsarolóvírusokhoz köthető cikk is érkezik majd a blogra. Többek között részletesebben írnunk majd a ransomware várható jövőjéről, a mesterséges intelligencia által támogatott zsarolóvírus támadásokról, de terítékre kerül majd a szolgáltatásként elérhető zsarolóvírusok sötét világa is. S persze a legfontosabb: folyamatosan adunk majd tippeket is, hogy miként lehet hatékonyan védekezni, illetve mit tehetnek azok, akik pórul járnak és egy sikeres támadás áldozatává válnak.

Ha szeretnél tőlünk tanulni az IT biztonságról, és részt venni ingyenes eseményeken, mindenképpen iratkozz fel a listánkra. FELIRATKOZOM

Kövess minket a LinkedInen is. 

Felhasznált forrás: Trend Micro- The State of Ransomware: 2020’s Catch-22

Hatékony kockázatkezelési megoldások ICS rendszereknél

Hunyadi Péter cikke

2021. április 08. - EURO ONE

Mind az otthoni, mind a vállalati felhasználók számára az IT biztonság fogalma kimerül az asztali gépek, okoseszközök, céges hálózatok védelmében: ne vigyék a hackerek a személyes adatainkat, ne kódolja a zsarolóvírus a fontos dokumentumainkat, s ne a mi böngészőnkön keresztül gazdagodjanak az illegális kriptobányászatra szakosodott kiberbűnözők. Pedig akadnak a világban ezeknél jóval durvább támadások is, amelyek annak ellenére is érinthetik mindennapi életünket, hogy nem közvetlenül a mi eszközeink ellen irányulnak.

blogbejegyzes-ics-01.png

Még 2010-ben történt, hogy feltehetően amerikai és izraeli forrásból egy Stuxnet nevű kártékony program – féreg – fertőzte meg az iráni bushehri atomerőművet és natanzi urándúsítót, utóbbi létesítményben túlpörgette és tönkretette a használt centrifugák 20%-át. Az akció mérföldkőnek számít a kiberbiztonságban, mert a Stuxnet-támadás után jelentősen megnövekedett az ipari irányítási rendszereket (Industrial Control Systems – ICS) fenyegető incidensek száma, melyek a legtöbb esetben az államok és a lakosság ellátása szempontjából létfontosságú rendszerek, szolgáltatások működéséért felelnek, mint a víz- és áramellátás, áru- és személyforgalmi szolgáltatások vagy épp a jelentősebb élelmiszergyártó üzemek. S ez így tán ijesztőbben is hat, mint amikor az ember a számítógépén tárolt adatok miatt aggódik.

Egy hivatalos ajánlás háttere

Cikkünk alapját az Egyesült Államok Belbiztonsági Minisztériuma (DHS) által javasolt Improving Industrial Control Systems Cybersecurity with Defense-in-Depth Strategies című ajánlás képezi. A kiadvány 2016-ban jelent meg a DHS alá tartozó National Cybersecurity and Communications Integration Center (NCCIC) és Industrial Control Systems Cyber Emergency Response Team (ICS-CERT) munkacsoportok, valamint más állami és versenyszférába tartozó ipari szereplők közös munkájának eredményeként. A dokumentum nem szabvány terjedelmű, ennek megfelelően nem is részletezi aprólékosan az információkat, de összhangban van a NIST (National Institute of Standards and Technology) SP 800-82 és 800-53, valamint a NIST Cybersecurity Framework sztenderdekkel.

Célunk az ebben közzétett ipari-kiberbiztonsági kockázatkezelési ajánlások rövid bemutatása, mégpedig azért, mert - a sok kihívást rejtő ipari kiberbiztonsággal kapcsolatos - munkánk során magunk is nagyon hasznosnak találtuk az oldalain javasolt megközelítést.

Változó kihívások ICS területen és megoldásuk

A már említett 2010-es Stuxnet-támadás után, az ICS rendszerek elleni incidensek számának növekedésén túl egy másik tendencia is megfigyelhető volt az elmúlt években.

Korábban az ICS rendszerek hagyományosan teljesen elszeparált hálózatokon működtek, sajátos, zárt ipari protokollokkal. Használatukhoz egy szűk, belső kör értett csupán, így nem alakult ki igény az adatforgalom logikai védelmére, elegendő volt az ipari környezetek fizikai védelme. A termelés hatékonyságának növeléséhez fűződő érdekek azonban kimozdítják ezeket a rendszereket az izoláció biztonságából, s az üzleti hálózattal való összekötést, illetve az átláthatóságot helyezik előtérbe. Éppen ezért megjelentek a klasszikusan IT környezetben elterjedt nyitott protokollok is (IP) az ipari eszközök portfóliójában. Az ipari rendszerek így egyre inkább kitetté válnak az internet felől érkező fenyegetéseknek, miközben üzletmenet szempontjából rendkívül kritikusnak számítanak. A kihívást tetézi, hogy a magas rendelkezésre állási követelmények miatt nehezebb logikai védelmet kialakítani rajtuk.

De mi lehet erre a megoldás? Nos, mivel az izolációra többé nem lehet alapozni, továbbá az újfajta nyitott modellhez biztonsági szempontból nem zárkózott fel az ICS rendszerek technikai háttere, ezért az IT világban megszokott „hagymahéj-elven” alapuló, ipari hálózatokra szabott mélységi védelem (Defense-in-Depth) alkalmazását javasolja a tárgyalt dokumentum.

Az ajánlás ezt a mélységi védelmet egy könnyen értelmezhető keretrendszer formájában ábrázolja. A mélységi védelem egy minden információs rendszerre ráhúzható rugalmas koncepció, amely holisztikusan, mind humán, mind folyamat, mind technológiai téren (People-Process-Technology) az összes lehetséges védelmi megoldást, illetve minden támadási vektort figyelembe vesz annak érdekében, hogy a védett rendszert valóban ellenállóvá tegye.

A dokumentum a mélységi védelem koncepcióját kilenc stratégiai elemre osztja. Ezek nem különböznének egy IT rendszer esetében sem, ahogy ez az első ábrán látható.

blog1.jpg1. ábra - Mélységi védelem - Stratégiai eleme

Az ajánlás ezután a felsorolt stratégiai elemeket bontja ki, elhelyezve őket az ipari környezet kihívásai, speciális igényei között. A javasolt megoldások bevezetését támpontokkal egészíti ki, a felhasználókra bízva, hogy miként alkalmazzák azokat a saját környezetükre.

OT-irányú kockázatkezelés

A stratégiai elemek tárgyalása a Kockázatkezeléssel kezdődik. Fontos kiemelni, hogy ez nem csak egy elem a kilenc közül, hanem a többi által lefedett biztonsági tevékenység alapját képezi. Éppen ezért itt is részletesebben foglalkozom vele. Az ICS-CERT kiadványa három szintű kockázatmenedzsment modell bevezetését javasolja:

  1. Szervezeti szinten határozzák meg a vállalat minden szinten követendő kockázatkezelési kereteit és minimumát, a kockázati étvágyat és toleranciát. Az újfajta, nyitott ICS rendszerek korában ezen a szinten az ipari domain sérülékenységeinek, kockázatainak a szervezet egészére, az üzletmenet folytonosságra – sőt, a külvilágra – gyakorolt hatásait is abszolút realisztikusan kell figyelembe venni. Ehhez fontos az alsóbb szintekről származó tapasztalatok és észrevételek szem előtt tartása.
  2. Üzleti folyamatok szintjén – ami alatt ez esetben az ipari termelési folyamatokat értem – történik az OT (Operational Technology) környezetek célzott kockázatkezelési folyamata. Az ajánlás itt – és később is – kiemeli az eszközök, technológiák leltárazását, kritikusságának és kockázatainak meghatározását és a fókuszpontok, kényesebb elemek azonosítását, mint a hatékony védekezés alapját.
  3. Végül az üzemeltetési/rendszer szinten valósul meg fizikailag mindaz, amit fentebb meghatároztak. A rendszer biztonságát érintő tapasztalatok, visszajelzések innen felfelé áramolva segítenek a stratégia későbbi fejlesztésében. Az alsó két szinten történő kockázatkezelési feladatokat a dokumentum folyamatként konkretizálja, részletesen kitérve ennek egyes lépéseire, amely - miként a második ábrán látható - a második szinten a sérülékenységi és kockázati profilalkotásból, majd a technikai szinten megvalósuló kontrollok bevezetéséből, monitorozásából és fejlesztéséből tevődik össze.

blog2.png

2. ábra - Kockázatkezelési ciklus

A bemutatott kockázatkezelés menete az eszközök leltárazásával kezdődik, mivel nem tudunk hatékony védelmet kialakítani, ha nem tudjuk, mit védünk. Ahhoz, hogy később fel tudjunk készülni a lehetséges támadásokra, számba kell venni minden használt hardvert, szoftvert, háttéreszközt, ismerni kell ezeknek az egymástól való függőségi viszonyait és az információáramlás csatornáit is, majd kategorizálni kell eszközeinket a kritikusságuk alapján. Több tízéves rendszerek esetében azonban korántsem könnyű feladat a leltár kivitelezése. Ha tudjuk, mit védünk, tudnunk kell, milyen kockázatok fenyegetnek bennünket. A támadás potenciális irányaival és a sérülékenységeinkkel kapcsolatban olyan forrásokra támaszkodhatunk, mint a gyártóegységek műszaki vezetői és kezelői, külső tanácsadók, vagy olyan keretrendszerek, mint amilyen a „MITRE ATT&CK for ICS”. Munkám során én több olyan termékkel találkoztam, melyek képesek feltérképezni az ipari protokollokat használó eszközöket (akár típussal, gyártóval, konfigurációval együtt) és adatbázisokból kinyerni a konkrét verzió ismert gyengeségeit. A támadások hatásvizsgálata és valószínűségének meghatározása véleményünk szerint az egyik leglényegesebb lépés, hiszen az ipari informatikai eszközöknél egy támadás nem csupán anyagi javakban okozhat kárt, hanem emberek testi épsége, akár élete is veszélybe kerül. A hatást befolyásolja a rendszer kritikussága, az hálózat és a rajta folyó kártékony aktivitás átláthatósága és a helyreállítási képességek is. A valószínűség alakulásában szerepet játszik, hogy a rendszereket biztonsági szintre soroltuk, valamint a hozzáféréskezelés mennyire kifinomult és, hogy a szoftverek frissítve vannak-e a legutóbbi verzióra. Az eszközök leltárja és kategóriákba rendezése ennek a lépésnek is megágyazott, így a támadás lehetséges vektorait, valószínűségét és súlyosságát láthatóvá tette. Az eddigi lépésekben szerzett ismeretek birtokában leszünk csak képesek meghatározni és bevezetni a megfelelő biztonsági kontrollokat. Az ipari igényekhez szabott kontrollok lefedik a humán-jellegű intézkedéseket (pl. tudatosítás), a folyamatkialakításokat és a technikai megoldásokat. Implementáláskor érdemes a legveszélyeztetettebb – vagyis a legkritikusabb és legsérülékenyebb – rendszerelemekkel kezdeni. Az ICS rendszerek speciális igényei és technikai nehézségei miatt gyakrabban fordul elő, hogy bizonyos kockázatokat el kell fogadnunk, esetleg a legjobbnak ígérkező kontroll helyett – akár az elvártnál gyengébb – alternatívát kell keresnünk kompatibilitási problémák miatt. A mélységi védelem sokfélesége viszont ezt a nehézséget is hivatott enyhíteni.

Zárásként elmondhatjuk, hogy a jelenlegi OT technológiai fejlődés iránya és a növekvő biztonsági igények egyelőre ellentmondásban vannak egymással, ráadásul nincs egy olyan kibervédelmi „csodaszer”, amely az ipari rendszerek biztonsági és rendelkezésre állási igényeit egyaránt kielégítené. Ebből kifolyólag – a kisebb számú ipari logikai védelmi termékek mellett – létező, ismert védelmi megoldásokat kell OT környezetekhez szabnunk, legyenek azok logikai, fizikai vagy folyamat jellegű módszerek, amihez hiánypótló segítséget nyújt az ICS-CERT ajánlása, mely ingyenesen elérhető az alábbi címen: https://us-cert.cisa.gov/ics/Recommended-Practices

Forrásmegjelölés

A 2. ábra forrása: ICS-CERT, 2016. Recommended Practice: Improving Industrial Control Systems Cybersecurity with Defense-in-Depth Strategies, p. 8.

Még több tartalomért, videókért és rendezvényekért kövess minket a LinkedInen is, kattints ide. 

Így add el az ISMS-t menedzsmentnek

Tóth Tamás cikke

2021. április 07. - EURO ONE

 

Az előző részben is igyekeztem rávilágítani arra, hogy az ISO 27001 alapú alapuló Information Security Management System (ISMS) sokkal összetettebb dolog, mint ahogy azt a szabványok elolvasása után vagy akár egy összefoglaló videó megnézése alapján ezt elsőre gondolnánk. Az ISMS összefüggéseinek megértésénél természetesen sokkal bonyolultabb az irányítási rendszer bevezetése és működtetése, ezért nem ritka, hogy néha a tapasztaltabb információbiztonsági tanácsadók bicskája is beletörik. Egy projekt sikertelensége azonban nem jelenti feltétlen a tanácsadók hibáját, ennél sokkal árnyaltabb a kép.

 

Az ISMS bevezetés kulcsfontosságú tényezői

 

Ha egy szervezetnél különböző okokból kifolyólag felmerül az ISMS bevezetésének ötlete, három kulcsfontosságú tényezőre kell kiemelt hangsúlyt fektetni:

 

1.       a menedzsment támogatásának megszerzésére,

2.       a kezdeményezés formális projektként való kezelésére és

3.       az ISMS elemeinek, elveinek és ezek összefüggéseinek megfelelő ismeretére.

 

Jelen cikkemben a menedzsment támogatásának fontosságát és megszerzésének lehetőségét fejtem ki, az ISMS bevezetés konkrét projektmenedzsmentjére és összefüggéseire a következő cikkemben fogok kitérni.

 

A menedzsment támogatásának fontossága

 

Szinte minden információbiztonsággal foglalkozó szakember előbb utóbb találkozik a terület egyik legnagyobb kihívásával: megszerezni szervezet vezetésének támogatását, információbiztonságért való elkötelezettségét, illetve a fejlesztésekhez szükséges büdzsét. Az ISMS bevezetésénél sincs ez másképp, hiszen a menedzsment támogatása kulcsfontosságú, de ez nem feltétlen az erre vonatkozó kötelező szabványpontok teljesítése miatt van így.

 

Ahogyan az a tankönyvekben is szerepel, az információbiztonságra vonatkozó igény ideális esetekben "top down" irányú, de ide sorolhatjuk a világszerte ismert vállalatirányítási (King IV Report on Corporate Governance) és belső kontrollra vonatkozó best practice-ket (COSO Internal Control Framework) , amelyek  a "setting the tone at the top" kifejezéssel kezdődnek, amit a példamutatás és az elkötelezettség kifejezéseknek lehet megfeleltetni.

A menedzsment támogatásának és elkötelezettségének birtokában lehet jelentősebb szervezeti változásokat elindítani és végrehajtani, az ISMS bevezetése pedig ilyen: érettségi szint növekedés és bizonyos szempontból kultúra váltás. Ahhoz, hogy ez megfelelően végbe tudjon menni és illeszkedjen a szervezet igényeihez, a menedzsment aktív részvételét igénylik az elvárások megfogalmazása, célok és a kapcsolódó kockázatok meghatározása, elfogadása, a szükséges erőforrások biztosítása és nehézségek esetén a problémák eszkalációja szempontjából. Fontos kiemelni, hogy ez a támogatás az irányítási rendszer fenntartásához elengedhetetlen, de a tapasztalatok szerint a sikeres tanúsítást követően meredeken zuhanni szokott, pedig nem lehet hátradőlni.

 

Támogatás megszerzése - érték

 

A menedzsment támogatását a jól ismert, mindenhol felbukkanó haszonszempontok egyszerű ismételgetésével - pl. hatékonyság növelése, károk csökkentése, kiszámíthatóság növelése, reputáció védelme - nem lehet megszerezni. Nem azért, mert nem lennének igazak, hanem azért, mert minden második terméket vagy projektet hasonló előnyökkel próbálnak nekik eladni és az ISMS elvész ezek közt. Véleményem szerint egy ISMS projektet két dolog részletes kibontásával lehet "eladni" a menedzsment felé: az ISMS bevezetése, működtetése és a tanúsítása által teremtett értékekkel, vagyis mivel lesz jobb a szervezetnek, miért éri meg. A másik dolog az, hogy hogyan térül meg ez a befektetés, hiszen mindenki profitot akar termelni és az információbiztonságnak is ezt kell támogatnia. Ezeket az üzeneteket az általános felsővezetői információs igényeket figyelembe véve, magasszinten kell kommunikálni, a "saját nyelvükön".

 

A nemrég publikált ITIL 4 szolgáltatásmenedzsment best practice fogalmazásában az érték "valaminek vélt előnyei, hasznossága és fontossága". Az ITIL érték definíciója szubjektív, de ennek a logikája mentén össze lehet gyűjteni az ISMS bevezetés által szállított értékeket. Ezeket természetesen minden esetben az adott szervezetre kell szabni. 

 

Az ISMS előnyei közé sorolhatjuk a tanúsítás által jelentett üzleti előnyöket, mivel bizalmat kelt a potenciális üzleti partnerekben és ügyfelekben. A tanúsítás megléte egy szerződéses vagy más jogi követelmény lehet bizonyos tendereken való indulás esetén, ami a compliance nyomás növekedésével egyre gyakoribb. Példaként a Magyarországon működő autóipari beszállítók számára kifejezetten előnyös lehet az ISMS tanúsítás megléte, hiszen az autógyárak ezt jellemzően más minőségirányítási tanúsítványokkal együtt megkövetelik. Másrészt a Német Gépjárműipari Szövetség. (VDA) információbiztonsági szabványa a TISAX (Trusted Information Security Assessment Exchange) szintén ISO 27001 alapokon nyugszik, így a megfelelés egy meglévő ISMS tanúsítással jóval könnyebben megszerezhető.

 

Az (igazi) ISMS hasznos, mivel a jól bevált keretrendszer bevezetésével, szabályozás, folyamatok kidolgozásával, felelősségek meghatározásával és korszerű technológiai megoldásokkal ötvözve (pl. IDM, SOC, új generációs tűzfalak, EDR) valóban hatékonyabb információbiztonsági működést lehet elérni, amelyet a KPI-k is alátámasztanak és hitelesen igazolják mindezt a menedzsment számára is. Az ISMS hasznához hozzájárul a kockázatok kezelése is, amelyek rávilágítanak azokra a sérülékenységekre és fenyegetésekre, amelyek veszélyeztetik a szervezet működését és ezáltal a szervezeti célok elérését is. A kockázatok ismeretében azokat hatékonyan lehet priorizálni és kezelni, így csökkentve a nem várt, esetleg nagy hatással járó incidensek bekövetkezését, vagyis kiszámíthatóbb működést lehet elérni. Az előző cikkemhez hasonlóan itt is kihangsúlyozom, hogy a valós előnyök csak egy jól működő, szervezetbe illesztett, tartalommal megtöltött ISMS-nél jelentkeznek, a kizárólag a falon lógó tanúsítványú ISMS kontraproduktív.

 

Az ISMS, vagyis azon keresztül az információbiztonság fontos. A jól ismert mondás szerint "a jó hírnevet igen nehéz megszerezni, de nagyon könnyű elveszíteni". Egy súlyos információbiztonsági és kapcsolódó adatvédelmi incidens jelentősen megtépázhatja egy szervezet reputációját, amit mindenki igyekszik elkerülni, de a híreket olvasva egyre gyakrabban láthatjuk, hogy ezt nem a megfelelő úton vagy módon teszik. Nem vagyok híve a szankciókkal való ijesztgetésnek, de ha objektíven nézzük, a reputáció sérülésén túl az incidensek miatt fizetendő kötbérek, bírságok, valamint hatósági eljárások tovább mélyíthetik a problémákat, elég csak a GDPR megsértése miatt kiszabott bírságok mértékére gondolni. Azt is látni kell, hogy a compliance és anyavállalati nyomáson kívül egy korábbi információbiztonsági vagy kapcsolódó adatvédelmi incidens segíthet a támogatás megszerzésében, hogy az ismét ne fordulhasson elő.

 

Támogatás megszerzése - befektetés

 

A hitelesség érdekében azt is el kell mondani, hogy a hosszan sorolható előnyöknek ára van, hiszen egy ISMS bevezetés és fenntartás alapvetően nem olcsó projekt, de könnyű ésszerű kereteken belül megmaradni.

 

Az ISMS bevezetését és fenntartását nagyban befolyásolja a szervezet kiinduló és elvárt érettségi szintje, valamint az alkalmazandó jogszabályok és szerződéses kötelezettségek. Példaként egy létfontosságú rendszerelemként kijelölt szervezet vélhetően azért vezet be ISMS-t, hogy hatékonyan tudja teljesíteni a jogi követelményeket, ami viszont olyan követelményeket támaszthat, amit bizonyos estekben csak drága technológiai megoldásokkal lehet maradéktalanul teljesíteni, ami az ISMS projekt költségtervét fogja drágítani. Az ISMS bevezetését az információbiztonsági tanácsadók igénybevétele is drágíthatja, hiszen a szervezetek információbiztonsági szakemberei jellemzően leterheltek, ezért őket korlátozottan lehet a projektre allokálni. Másrészt gyakran az ISMS bevezetéshez szükséges kompetencia is hiányzik a szervezeknél, mert ahogy a cikk elején említettem, az ISMS összetett.

 

Szimbolikusan a mérleg egyik serpenyőjében az ISMS ITIL 4 érték definíciójára felfűzött előnyei, hasznossága és fontossága van, a másik serpenyőben pedig a CAPEX, OPEX összegét adó TCO. A mérleget ideális esetben a ROI fogja értékek oldalára fogja billenteni. Mindenki által ismert az a tény, hogy a költségeket nem lehet pontosan megtervezni és a keretet általában gyakran túl kell lépni, de a ezek tervezése mégis kiemelt fontosságú egy ISMS projekt tervezésekor és jóváhagyásakor.

 

A CAPEX, vagyis a Capital expenditure tőkebefektetést jelent. Az ISMS bevezetés CAPEX költségei elsősorban az új kontrollok bevezetése miatti eszközök, biztonsági megoldások és egyszeri licenszek beszerzésében merülnek ki. Ide sorolhatjuk még a bevezetés során igénybe vett tanácsadói költségeket, valamint a tanúsító audit (magasabb) díját és a szabványok megvásárlását is.

Az OPEX, vagyis az Operational expenditure működési költséget jelent. Működési költségekről már egy bevezetett és  tanúsított ISMS esetében beszélhetünk, amit fenn kell tartani. Az OPEX költségek tehát a kontrollok üzemeltetésének, illetve különböző havidíjas biztonsági szolgáltatások és licenszek díját, kiszervezés vagy támogatás esetén a tanácsadói díjat, illetve az éves felülvizsgálati auditok díját foglalják magukban.

A TCO, vagyis a Total Cost of Ownership a tulajdonosi költséget vagy birtoklási összköltséget jelenti, ami gyakorlatilag a CAPEX és OPEX összegéből áll elő, 3-4 évre vetítve. A TCO fogja elárulni a menedzsment számára, hogy az ISMS bevezetés és fenntartás összesen mekkora költséget fog jelenteni.

A ROI, vagyis a Return on Investment a befektetés megtérülési arányát jelenti. A ROI egy ISMS projektnél nehezen megfogható, de a teljesség kedvéért célszerűnek tartom beemelni a "képletbe". Az ISMS projektnek csak kiadásai vannak, számszerűsíthető bevételt nem igazán lehet meghatározni. Bevételt azon üzleti lehetőségek kiaknázása hozhat, amelynek feltétele, vagy kifejezett előnye az ISMS tanúsítás megléte. Bevételt ugyan nem hoz, de a hatékonyabb működéssel csökkenthetők a költségek, illetve az esetleges bírságok elmaradása és a reputációveszteség elkerülése is pozitív hatással lehet a számokra.

 

Konklúzió

A menedzsment támogatás megszerzésére nincs általános recept és gyakran nem a cikk tartalmát képző üzenet összeállítása jelenti a nehézséget, hanem annak az alkalomnak a megteremtése, ahol azt át lehet adni címzettjeinek. Nagyvállalati szinten az Audit Committe vagy Risk Committee-k formájában már megvannak ezek a fórumok, de közepes méretű vállalatoknál az információbiztonsági vezető ritkán jut be a megfelelő ajtók mögé, ha van ilyen személy. Ilyen esetekben alkalmazhatók a soft skillek és a szervezeten belüli kapcsolatok.

A következő cikkben a menedzsment támogatás megszerzését követő lépésekről, vagyis az ISMS projekt tervezéséről és annak konkrét lépéseiről fogok írni.

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