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

EURO ONE

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.

Három kulcspont, amelyek megalapozzák a hatékony IT üzemeltetést

Becker Zoltán cikke #adatközpont

2021. április 01. - EURO ONE

Manapság számtalan terület van, amelyek erős kihívásokkal küszködnek. Ezek egyike az IT üzemeltetés, ahol normális körülmények között is mindig akadnak idő előtti megőszülést előidéző problémák, de a COVID-19 járvány okozta bizonytalanság csak tovább fokozta ezek súlyosságát. A terjedő távmunka, az ingatag gazdasági környezet, a növekvő szakemberhiány nem egyszerűsíti az IT üzemeltetésben dolgozók életét.

adatkozpont-blog-cikk_vegleges.png

Kihívások minden szinten

A hazai helyzet sem éppen rózsás, a hozzánk forduló cégek szinte mindegyikének komoly fejtörést okoz az erőforrás- és tudáshiány. A temérdek elvégzendő feladat mellett nincs idő képzésekre, ráadásul a munkavállalók sem feltétlenül motiváltak abban, hogy ha a cég nem segít ezen a téren - nem adnak rá se pénzt, se időt -, akkor legalább önképzésbe kezdjenek. Új, modern termékekkel megismerkedni pedig nem mindig egyszerű dolog, nem mindenki születik úgy, hogy zsigerből kiigazodjon egy komplex rendszeren és azt szakértő segítség nélkül, a kisujjából kirázva legyen képes megfelelően használni. Kevés az a szerencsés, aki önerőből tud haladni a korral, ráadásul nem is feltétlenül elég, ha csak a munkaerő fejlődik, a környezetet, az eszközöket, minden hátteret naprakészen kell tartani.

Sokszor előfordul az is, hogy amikor a cégvezetés végre elhatározásra jut egy oktatási terv mellett, a bevezetést felülírják a csúfos anyagiak, vagy épp azoknak az idejével nem sikerül összhangba hozni a dolgokat, akiknek az egész képzés szólna.

Emellett a legtöbbször csak azon projektek váltanak ki reakciókat, amelyek éppen napirenden vannak. A legtöbb helyen nincs előre tervezés. Pedig egy versenyszektorban található cég üzemeltetése alapvetően nem csak a napi problémákkal, konkrét üzemeltetési feladatokkal foglalkozik. Ez egy szerteágazó, több szintes feladatkör, amelybe éppúgy beletartozik a szerverek és a hálózatok üzemeltetése, mint a helpdesk. Ha viszont ennyire sokrétű ez a terület, még fontosabbnak tűnik, hogy a munkatársak lehetőleg önképzők legyenek. Egy ilyen szakmában mindig van olyan tudás, amit újonnan kell elsajátítani. Ehhez adhat lökést a cég is, ha egy konkrét új termék használata miatt van szükség képzésre, de késztethet rá belső indíttatás is, ha például valaki úgy érzi, hogy egy monitoring rendszer sokat egyszerűsítene a napi munkán, s ezért hajlandó időt szakítani a tanulásra.

Ugyanígy felmerülhet valakiben az ötlet, hogy ideje lenne kiépíteni egy belső tudásbázist, amelyre bárki, bármikor támaszkodhat, ha visszatérő problémákat kell megoldani. Kézenfekvő egy ilyet felépíteni, hiszen a kollégák napi szinten akadnak el azonos gondokkal, például az Outlook használatával. Olykor ehhez elég egyszerűbb alapokat választani, nem kell feltétlenül a legösszetettebb rendszerben gondolkodni. A lényeg, hogy megszülessen a gondolat és aztán materializálódjon is a megoldás, esetünkben egy céges tudásbázis létrehozása.

A leghatékonyabb egyébként a proaktív üzemeltetés kiépítése. Ez nem ördögtől való dolog, egyszerűen csak arról van szó, hogy előbb kiderül egy probléma és elindul annak megoldása, mint ahogy azt a felhasználók jelzik. Ha például - maradva a példánál - az Outlookban folyamatosan visszatérő gondok adódnak több felhasználónál, akkor nem egyenként próbáljuk megoldani azt, hanem felkutatjuk a probléma gyökerét és arra keresünk gyógyírt. Egy ilyen megoldás implementálásával proaktívan előzhetjük meg az adott problémák tömegessé válását.

Három kulcspont a hatékony IT üzemeltetéshez

A fentiek alapján tehát akkor járunk jól, ha elkezdünk olyan termékeket használni, amelyek hatékonyan segíthetik a munkánkat. Ez lehet egy tudásbázis, egy monitoring eszköz, vagy mondjuk egy SCCM típusú termék, amely a távoli telepítést és menedzselést segíti. Utóbbival például rengeteg pénz, idő és energia spórolható meg, hiszen nem kell minden egyes alkalommal kicaplatni az ügyfélhez, hanem távolról intézhetők a frissítések.

Foglaljuk össze röviden, melyek azok a pontok, amelyekre odafigyelve megoldható a proaktív IT üzemeltetés bevezetése és hatékony használata.

Tudásbázis

A tudásbázis kiépítésének első lépése minden bizonnyal a dokumentáció iránti igény kialakítása. Ezután vehetünk bele olyan dolgokat a tudásbázisba, amelyek nem szerves részei egy dokumentációnak, leírásnak. Ezeket is elkezdhetjük a közös felületen összegyűjteni, rendszerezni, kategorizálni. Ehhez akad számtalan remek céleszköz, de akár egy helpdesk rendszerre is építhetünk.

Emellett szükséges, hogy felismerjék, hogy akadnak visszatérő dolgok, amelyeknek hosszútávú hatása lehet. Ezeket már alacsony szinten fel kell tudni ismerni, kigyűjteni őket, s közzétenni a tudásbázisban. Ha ez így történik, akkor nem stresszhelyzetben szembesülnek először a problémával, emellett pedig az adott hiba megoldására így több idő jut, nyugodtabban lehet átgondolni, s jobb megoldásokat lehet találni, mintha élesben kell rögtönözni, kapkodni. Még az is előfordul ilyen esetekben, hogy a körültekintőbben végiggondolt megoldások akár egyéb hibák esetében is alkalmazhatók lesznek, így egy csapásra több szinten is megkönnyíthetjük a saját dolgunkat. Ráadásul ez olyasféle önfejlesztő folyamat is egyben, amely nem csak az analitikus gondolkodást segíti, hanem a képes felhozni a szakmaiságot is, hiszen új dolgokra is fény derülhet. Kiváló tanulási alap.

Monitoring

Ez az abszolút klasszikus kulcspont. Egy jól konfigurált, megfelelően paraméterezett monitoring még azelőtt jelez nekünk, hogy a felhasználó szembesülne a hibával. Egyszerű példával élve: nem azt jelzi, hogy betelt a merevlemez, hanem már azt is, ha túlságosan lecsökkent rajta a szabad hely. Így még a háttértár teljes telítődése előtt megtehetjük a szükséges lépéseket, a felhasználó pedig ebből mit sem érzékel, ugyanúgy végezheti a dolgát, mint azelőtt.

Emellett a monitoring rendszer kiváló forrás elemzésekhez is. A visszanyerhető adatok vizsgálatával számtalan megbújó hibára, fejlesztendő területre, leendő beruházási pontokra bukkanhatunk rá, amelyek amúgy észrevétlenül megbújnának az infrastruktúra egészében, s csak későn szembesülnénk velük.

Távoli üzemeltetés

Végül szintén sokat segíthetnek a hatékony IT üzemeltetési rendszer kiépítésében a különféle távoli üzemeltetést lehetővé tévő megoldások. Ilyen például a Microsoft SCCM, de természetesen a redmondi megoldáson kívül is akad még seregnyi remek eszköz ezen a területen.

Ezek segítségével megoldható a távoli telepítés, frissítés, szoftvermenedzselés. Nem vagyunk sem helyhez, sem az adott felhasználóhoz kötve. Még csak fárasztanunk sem kell azzal, hogy az apróbb frissítésekről értesítsük, adott esetben a háttérben, észrevétlenül megoldható minden.

Mivel a kiberbűnözők a COVID-19 miatt (is) aktívabbak mint azelőtt, már nincs idő a felhasználó kénye-kedve szerint időzítgetni egy fontos biztonsági frissítés telepítését. Hosszú távon ezzel anyagi és erkölcsi szempontból is jót teszünk a céggel, hiszen manapság egy adatvesztés - s pláne egy adatlopásos esemény - mindkét szempontból képes a vállalatokat megtépázni.

Összegzésül

Az üzemeltetés tulajdonképpen egy szervezet, s ha innen nézzük, számos rétegből áll össze. Amennyiben ezek a rétegek megfelelően épülnek fel - klasszikus példa erre egy call center, egy helpdesk, a felhasználókkal foglalkozó üzemeltetők, a user adminisztrátorok, és az üzemeltető mérnökök -, akkor kialakul egyfajta összhang. Így amellett, hogy jól tudnak egymással dolgozni, tanulhatnak is egymástól, minden irányban. Ráadásul ez egyfajta karrierépítésre, fejlődésre is lehetőséget nyújt.

Emellett mindig kell, hogy legyen valaki - csoportvezető -, aki amellett, hogy végzi a munkáját, egyben felügyeli is az egészet, hogy ha esetleg valahol elakadás van, ott is sikerüljön áthidalni a kihívásokat. A döntéshozást érdemes olyasvalakire bízni, aki átlátja az egészet és tud segíteni másoknak is a döntéseik meghozatalában. Ez is egyike a fontos kulcspontoknak, amelyekkel kiépíthető a hatékony IT üzemeltetés.

Még nincs vége: digitális veszélyek, COVID-ra kihegyezve

Krékity Gusztáv cikke

2021. március 10. - EURO ONE

Tavaly közzétettünk egy statisztikákkal megtűzdelt bejegyzést arról, milyen módon használják ki a világjárvány generálta félelmet és káoszt a kiberbűnözők, hogy sikeres támadásokat hajtsanak végre világszerte. Itt olvasható. Most megjelentek a Trend Micro elemzőcsapatának legfrissebb kutatási adatai arról, miként lovagolták meg a vírusjárvány második hullámát a rosszindulatú hackerek, milyen támadási kísérletekkel igyekeztek megtéveszteni áldozataikat.

digitalis-veszelyek.jpg

Még mindig itt van velünk

Bár 2020-at már magunk mögött hagytuk, a világjárványtól sajnos nem sikerült megszabadulnunk, továbbra is hatalmas zavart okoz a vállalkozások mindennapi életében. Az üzleti műveletek fenntarthatósága miatt - a távoli munkavégzés mellett - a felhő alapú megoldások használata átlagosan 35%-kal növekedett a céges környezetekben, 2019-hez képest. Ez a szám várhatóan tovább növekszik majd a közeljövőben, hiszen a Cloud, mint megoldás, a digitális átalakulás középpontjába került.

A támadók rutinosan alkalmazkodtak a helyzethez és egyre összetettebb, bonyolultabb támadási technikákat vetettek be, ám ezeket a jól bevált módszerekbe csomagolták. Így továbbra is vezető szerephez jutottak az e-mail üzenetekben érkező támadások: Phishing, Malspam, Social Engineering, Malware vagy BEC.

A következő kimutatásokat és adatokat a Trend Micro Cloud App Security segítségével publikálta a gyártó. Ehhez különböző üzleti területen tevékenykedő és eltérő méretű cégek adatait dolgozták fel, anonim módon.

A COVID-19, mint eszköz, minden téren

Mint azt korábban már megírtuk, 2020 január és június között közel 9 millió, a COVID-19-hez kapcsolódó fenyegetést észleltek, azonban év végére már több mint 16,7 millió magas kockázatú e-mail fenyegetést detektált és blokkolt sikeresen a Trend Micro API eszköze, amelyet a Microsoft M365 második védelmi rétegeként integráltak a céges környezetekbe. Az összegző statisztikából megállapítható, hogy a támadások intenzitása növekedett, de az összetett BEC támadások száma a teljes évet figyelembe véve valamelyest csökkent. Eközben az adathalászat mértéke is érezhetően megnőtt. Az adathalászat és a megtévesztésre épülő támadások legnépszerűbb témája pedig egyértelműen a COVID-19.

1_5.jpg

A távmunka hétköznapivá válásával 50-60%-kal nőtt meg az internetszolgáltatók leterheltsége: csak Délkelet-Ázsiában több mint 40 millió ember használta életében először otthoni munkavégzésre az internetet. A home office-ra való átállással arányosan növekedett az igény a meetingek megvalósításához szükséges alkalmazások használatára, miközben a levelezés is elengedhetetlen részét képezte a munkavégzésnek, hiszen ezzel lehetett a leghatékonyabban megoldani a kapcsolattartást munkatársakkal, ügyfelekkel. Egy felmérés szerint a pandémia alatt már átlagosan napi 306,4 milliárd e-mailt küldtek és kaptak naponta a felhasználók. Sajnos az e-mailek túlnyomó része fertőzött volt, vagy rosszindulatú tartalommal érkezett.

Annak ellenére, hogy a felhős rendszerek és szolgáltatások rendelkeznek beépített fenyegetésészleléssel és blokkolási képességekkel, a Trend Micro CAS által szolgáltatott adatok azt mutatják, hogy több millió fenyegetésnek sikerült kicseleznie ezeket az integrált szűrőket.

2_4.jpg

A példa kedvéért a fenti képen jól látszik, hogy egy 10 ezer felhasználós környezetben, ahol M365 E3 integrált védelemmel rendelkezett az ügyfél és egy Cloud App Security is rendelkezésre állt második védelmi rétegként, kicsivel több mint 755 ezer magas kockázatú kártékony tartalommal rendelkező levél került blokkolásra 2020 január és december között. Ez egyébként felhasználónként körülbelül 75 kártékony levelet jelent, amelyeket az alap szűrési csomag natív védelmi szolgáltatása tisztának jelölt. Ezek alapján bizony érdemes megfontolni a rendszerekben a többrétegű védelem kialakítását, hogy sikerrel vehessük fel a harcot a támadókkal szemben.

Az adathalász támadások számának és kifinomultságának növekedése

2019-hez képest a 2020-as évben jelentős növekedést tapasztaltak az adathalász kampányok számában, amelyek a korábbi esetekhez képest kifinomultabbak, szofisztikáltabbak lettek és egyre inkább személyre szabottá váltak. Ezek a támadások jellemzően arra építenek, hogy a gyanútlan áldozatoktól egy jól felépített hamis oldalon keresztül céges belépési hitelesítő adatokat szerezzenek meg.

3_3.jpg

Csökkenő számú BEC támadások, növekvő veszteségekkel

A BEC támadások visszaesése valószínűleg a kifinomultabb technikáknak köszönhető. Bár az elmúlt évek növekedéséhez képest a BEC alapú támadások száma mostanában inkább csökkent, mégis ez a támadási forma okozta a legnagyobb veszteséget az áldozatoknál. A támadások számának csökkenésével párhuzamosan az okozott kár mértéke ugyanis növekedett az elmúlt évekhez képest. Az APWG (Anti-Phishing Working Group) nemrég tette közzé, hogy 2020 első felében egy sikeres BEC támadás átlagos költsége 54 000 USD volt, de 2020 második felére ez az összeg átlagosan legalább 80 183 USD veszteséget okozott egy sikeres támadás során. A Trend Micro publikálta, hogy 2020 során ők 317 575 BEC támadást blokkoltak összesen.

Népszerűbbek és összetettebbek lettek a rosszindulatú programok

A levelekben detektált és letiltott kártékony fájlok száma 16%-kal nőtt 2020-ban. Több, mint 1,1 millió rosszindulatú program észlelése alapján a Trend Micro azt a következtetést vonta le, hogy az ismert kártékony programok aránya 14%-kal, az ismeretlen kártékony kódok aránya pedig 17%-kal nőtt tavaly.

4_1.jpg

Összegzésül

Összességében elmondható, hogy az elmúlt évben az egészségügyi válságot nem csak az első hónapokban igyekeztek meglovagolni a támadók, hanem egész évben - kisebb-nagyobb intenzitás csökkenéssel, de - visszatértek hozzá. A BEC támadások száma csökkent, de a veszteségek ennek ellenére növekedtek a sikeres támadások által. Az elmúlt év tapasztalatai alapján elmondható az is, hogy a világjárvány idején - és még bőven azon is túl - az információbiztonságnak minden vállalkozás számára prioritást kellene élveznie, mérettől függetlenül. A vállalatok és szervezetek minden eddiginél jobban és sokkal nagyobb mértékben támaszkodnak a felhő alapú e-mail szolgáltatásokra és alkalmazásokra. A szervezeteknek mérettől függetlenül többrétegű biztonsági megoldásokkal érdemes tervezni, s megnövelni az integrált védelmi megoldások hatékonyságát a biztonság fokozása érdekében. Mindezt nem csak a levelezésnél, de a többi együttműködési platformon - például M365 Teams, Google Workspace stb. - esetében is.

Mire figyeljünk egy többrétegű védelem kiválasztása során?

Fontos, hogy a megoldások jövőbemutató technológiákat alkalmazhassanak. Így például:

  • Gépi tanulási képességek az e-mail üzenet szövegtörzsének ellenőrzésekor vagy a mellékletben található gyanús tartalom ellenőrzésénél.
  • Érdemes figyelni arra, hogy az integrált megoldás rendelkezzen saját Sandbox funkcióval, amely képes a fejlett és ismeretlen támadások ellen hatékonyabb védelmet nyújtani.
  • A megoldásnak támogatnia kell a belső levelezés ellenőrzését, hogy a BEC támadásokat sikeresen észlelje és blokkolja.
  • Támogassa és alkalmazza az optikai karakterfelismerési technikákat (OCR).
  • Támogassa az adatszivárgás detektálást és tegye lehetővé a DLP házirendek kialakításának a lehetőségét.
  • Legyen képes védelmet nyújtani az adatvesztéssel és a kártékony kódokkal szemben a felhő alapú fájlmegosztásokban (OneDrive, SharePoint, Google Drive, Dropbox stb.).
  • Kínáljon zökkenőmentes integrációt a meglévő felhőalapú beállításokkal.
  • Minimalizálja a további erőforrások bevonásának szükségességét, a fenyegetések kockázatának automatikus felmérésével.

Tavaly szeptemberben volt egy webinárunk, ahol arról beszéltem, hogyan védjük ki a támadásokat Microsoft 365 esetén. Ide kattintva elérheted a videót. 

Palo Alto Networks jóslatok 2021-re

Krékity Gusztáv cikke

2021. február 01. - EURO ONE

Két dolog egészen biztosan nem maradhat el egy új év első hónapjában: a fogadalmak és a jóslatok. Így van ez természetesen 2021-ben is, s nem kivétel ez alól az IT biztonság területe sem. A piac vezető szereplői minden januárban elkezdik kialakítani a következő hónapokra vonatkozó elképzeléseiket azzal kapcsolatban, hogy mire is számítanak, vagy épp milyen kulcsszerepet kapó trendek várhatók az adott esztendőben. Idén sem volt másképp: ahogy annak lennie kell, megérkeztek a jóslatok arról, miként képzeli el Palo Alto az új évet. Ezeket az elképzeléseket szeretnénk most megosztani veletek.

Fokozott próbatételek utáni élet

2020 meglehetősen rendhagyóra sikerült, s ennek köszönhetően vízválasztónak tekinthető az IT biztonságban is. Rengeteg új kihívással és próbatétellel szembesültünk a pandémia időszakában. Mivel a COVID-19 hatása nagy valószínűséggel a következő években is érezhető lesz, a vállalkozásoknak tovább kell gondolniuk IT, illetve azon belül IT biztonsági stratégiájukat, hogy hosszabb távon eligazodjanak az új normák között. Mivel egyre jobban függünk a technológiától, létfontosságú kérdés, hogy mennyire lesznek képesek biztosítani a vállalkozások a 2021-es digitális jövőt. De talán még ennél is fontosabb felvetés, hogy mennyire lesznek képesek biztonságosan megoldani a felmerülő kihívásokat.

Következzenek hát a Palo Alto Networks által megfogalmazott, kiberbiztonsággal kapcsolatos előrejelzések, amelyek 2021-ben befolyásolhatják a digitális világot.

IoT eszközök számának növekedése

A legfrissebb IoT biztonsággal kapcsolatos kutatások szerint a BYOD növekvő szerepének köszönhetően egyre több nem céges, üzleti jellegű eszköz kapcsolódik a belső hálózatokhoz. Jól megfigyelhető, hogy a biztonsági irányelvek az elmúlt időszakban enyhültek, hogy lehetővé váljon a dolgozók számára a kényelmesebb munkavégzés. Ez azonban azzal jár, hogy a rendszerek a végfelhasználói eszközök számának növekedésével sokkal nehezebben felügyelhetők és kevésbé átláthatók, ráadásul jelentősen megnő a biztonsági kockázat is.

Terjednek a pandémiára építő csalások

Legyen szó nagyvállalati környezetről, kis- és középes vállalkozásokról vagy épp magánszemélyekről, a pandémia idején sajnos minden szinten jóval több sikeres támadás történt, mint az elmúlt években. Immár bárkiből, bármikor lehet áldozat, nem csak egy potenciálisan kiemelt intézményből vagy szervezetből. A támadók idén is kihasználják majd a COVID-19 által generált zavaros és félelemmel teli helyzetet: számtalan elterjedt pszichológiai manipulációval hatnak az emberek kétségbeesésére. Utóbbi ugyanis nagyszerű táptalaj az adathalászathoz és a bankkártyás csalásokhoz.

Munkavállalói kimerültség

Az elmúlt időszakban csökkent a személyes találkozások lehetőségének száma és egy digitális térben történő folyamatos, csak minimális szünetekkel megszakított kommunikációra álltunk át. A digitális munkára történő váltás magával hozta, hogy új IT biztonsági oktatási programokra is felhívjuk a figyelmet. Mit jelent ez pontosan? Nos, figyelni kell például arra, hogy az emberek képesek legyenek észrevenni a szellemi fáradtság és a koncentráció csökkenésének a jeleit, s ennek kapcsán megfelelő mennyiségű szünetet tervezzenek be a megbeszélések közé. A vállalkozásoknak számolniuk kell az emberi hibatényezőkkel is. A távoli kapcsolatokat, céges erőforrás eléréseket fokozottan kell figyelni és ellenőrizni az otthoni munkavégzés során.

Terjed az 5G

Egy ideje hatalmas beruházások zajlanak a háttérben az 5G bevezetésére, s vélhetően 2021 lesz az az év, amikor a kiberbűnözők már elkezdik kihasználni az új lehetőségeket és feltérképezni azokat a módszereket amelyekkel 2022-ben már a kiépített 5G hálózatokat támadhatják. Miért 2022-ben? Leginkább azért, mert jelenleg még túlságosan csekély az 5G kihasználtsága. Azonban 2022-re jó eséllyel a piaci szereplők közel egyharmada átáll az 5G használatára Európában. Ráadásul arra is számíthatunk, hogy egyre többen vezetnek majd be 5G alapú privát hálózatokat a közeljövőben, hiszen ez remek eszköz lehet a gyorsabb és hatékonyabb munkavégzés elősegítésére.

Irány a felhő!

A közelmúltban egyre több európai vállalat kezdte megtervezni, hogy a kulcsfontosságú üzleti folyamatait miként mozgassa át felhőbe az elkövetkező évek során. A világjárvány miatt e folyamatok sok helyen rohamtempóban zajlanak és csupán néhány hónapos migrációs tervezésre alapoznak ahelyett, hogy a jelenlegi folyamatok újradefiniálására szántak volna időt. A felhőbe költözés kritikus fontosságú lépés, amelyet jól meg kell tervezni. A megvalósíthatóságot biztonsági szempontból is át kell vizsgálni, mert bár a folyamtok ugyanazok maradhatnak, ám a környezet és az információk biztonságának védelme alaposan megváltozik. A vállalkozások többsége 2021-ben már a migrációs folyamatok második szakaszának megvalósítását tervezi, hogy mielőbb kiaknázhassa a szervezet a felhő használatából származó előnyöket. A gyors migráció azonban sok esetben vezethet - vagy adott esetben a közelmúltban vezetett is - biztonsági hiányosságokhoz, s ennek következményeként egyre több felhő alapú környezetben lehet adatlopásra számítani idén.

A SOC csapatok problémáinak növekedése

2021-ben a jelentős mértékű szakemberhiány mellett a korai kiégés lehetősége is fejfájást okozhat majd. Sok SOC csapat megszokta már munkája során, hogy több forrásból, több monitoron keresztül kell kezelni egy–egy támadást és a kivizsgálási folyamatokat. Emellett azon sem csodálkoznak, hogy a biztonsági megoldások száma évről évre növekszik. A megszokás azonban nem jelenti azt, hogy ez a jó irány. Az eszközök számának növekedése több kivizsgálandó hamis riasztást generál, amelyek elfedhetik a valós veszélyeket. Az elemzők gyorsabban kifáradnak, kiégnek. A klasszikus SOC koncepciót érdemes újragondolni és elgondolkodni az automatizációs lehetőségek bevezetésén, vagy épp az ML és AI alapú megoldások alkalmazásával segíteni a SOC-ban dolgozókat, hogy proaktívak legyenek a támadókkal szemben.

Shadow IT növekedése az ipari környezetekben

Az Shadow IT, avagy az árnyékinformatika az OT környezetekben is egyre inkább jelen van. A digitalizálási folyamatok jelentősen felgyorsulnak és többnyire az elavult OT rendszereket igyekeznek összekötni IoT megoldásokkal. Az IT és OT környezetben egyaránt nagy kihívást jelent az árnyékinformatika felderítése. Az energetikai ipar egyre jobban bővíti az IoT eszközök használatát 2021-ben, de a Zero Trust megoldások is fokozatosan népszerűbbé válnak. A SOC csapatoknál egyre inkább összevonásra kerül az IT és az OT, IIoT megoldások figyelése és monitorozása.

A kiberbűnözők és a COVID kapcsolata

A bűnözők naprakészen követik az épp aktuális trendeket, híreket, amelyek segítségével egy-egy támadást felépíthetnek és sikeresen végrehajthatnak. 2020-ban ez nagyrészt a világjárvány okozta félelemre és érdeklődésre összpontosult: számos COVID-19 tartalommal ellátott BEC támadást és kampányt hajtottak végre sikeresen a rosszfiúk. Nem lesz ez másként idén sem, az egyetlen változást valószínűleg a támadások számának további növekedése és az egyre kifinomultabb módszerek jelentik majd.

Zárszóként

Így a végére következzen egy idézet, amely szerintük remekül összefoglalja a fentieket. Heider Pasha a Palo Alto Networks MEA vezetője szerint:

„A 2020-as év a globális világjárvánnyal párosulva soha nem látott módon megváltoztatta a szervezetek és az egyének életének mindennapi aspektusát, ideértve a Közel-Keleten végzett munkákat, életvitelünket és az üzleti tevékenységeket is. A következő évben a technológiai fejlődés hatására beleértve az 5G hálózatokat, a felhő és a ZTP technológiák növekedését új kihívásokat és biztonsági réseket is fogunk tapasztalni. Megfelelő kiberbiztonsági stratégiák mellett azonban az informatikai felsővezetők jól felkészülhetnek ahhoz, hogy átláthatóvá tegyék és legyőzzék az újév kihívásait.

Kövess minket a LinkedIn-en!

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