Minden idők egyik legsúlyosabb kibertámadása rázta meg Amerikát - elemzés

A „szoftver-ellátási lánc”-ot célzó támadások hatásai, következményei, lehetséges elhárítási módok

2021. március 16. kedd, 06:00
A közelmúlt legsúlyosabb kiberbiztonsági incidenseiben közös elem volt a szakszóval „szoftver-ellátási lánc”-ot célzó támadási elem. Az amerikai kormányzat nagy részét is súlyosan károsítani képes módszer hátterét és a védekezés lehetséges módjait Erdei Csaba IT biztonsági szakértő segítségével jártuk körbe.

Twitter megosztás
Cikk nyomtatása


A szoftver-ellátási lánc támadásnak nevezzük azt, amikor a hackerek a kompromittálják egy adott szoftver fejlesztői környezetét és fejlesztők tudta nélkül manipulálják szoftver vagy szoftverkomponens kódját. A megváltoztatott kód célja, hogy ezzel az adott szoftver felhasználóit támadják. Az elhelyezett rosszindulatú kódrészlet segítségével a támadók adatokat lophatnak, illetve hátsó ajtókat nyithatnak meg az áldozatok hálózatában. Mindezt úgy, hogy közben a megtámadott felhasználók nem is tudják, hogy egy általa megbízhatónak tartott szoftver egyik komponensével érkezett a támadó kód. Ezekben az esetekben általában a kártékony kód a rendes szoftverfrissítéssel érkezik a megtámadott hálózatba, és ott többnyire tökéletesen átmegy az üzemeltetési folyamatokon, azaz a szervezet saját üzemeltetési csapata a munkája során segíti tudta nélkül a támadást.

A „szoftver-ellátási lánc”-ot célzó támadások súlyos károkkal fenyegetik mind az információs társadalom vívmányait, mind a biztonságos kiberteret teremteni kívánó erőfeszítéseket, mind a gazdaságot. A szállítók/fejlesztők és a felhasználók bizalmi viszonyának megbomlása nagyon rossz hatással lehet mindarra a fejlődésre, amit az elmúlt évtizedekben láthattunk. Jelen elemzésben javaslatot fogalmazok meg arra nézve, hogy milyen eljárási, szabályozási és fejlesztési intézkedéseket – valamint természetesen ezek ellenőrzését – kellene végrehajtani ahhoz, hogy ilyen típusú incidensek lehetőleg minél ritkábban következzenek be.

A probléma felvetése

Az elmúlt időszak számos kibervédelmi incidenséből toronymagasan emelkedik ki néhány  „szoftver-ellátási lánc”-ot célzó támadás. Jelen tanulmánynak nem célja ezen támadási metódusok, illetve a konkrét példák támadási idővonalának teljes és pontos ismertetése, azonban a téma kifejtéséhez dióhéjban érdemes megismernünk ezeket az eseteket nagy vonalakban.

A kibertérben vélhetően a megismert második legnagyobb ilyen típusú támadás a tavaly kipattant „SolarWinds incidens”. Az elsődleges áldozat a Solarwinds cég és az Orion nevű – IT rendszer felügyeletére használt – szoftvere volt. A támadó kompromittálta a fejlesztőcéget, majd eredményesen módosította az Orion szoftvert. Az elhelyezett kártékony kód egy adott kiadásnál bekerült a cég ügyfeleinek a hálózatába, amelyek ezáltal tömegesen támadhatóvá váltak. Az incidens érintettjei között a hírek szerint világszerte legalább 18 ezer (de egyes becslések szerint akár több 10ezer) kormányzati intézmény, multinacionális cég és egyéb ügyfél található, ezek között az USA-ban például az államkincstár (U.S. Department of the Treasury), a Külügyminisztérium (U.S. Department of State), a Belbiztonsági Minisztérium (U.S. Department of Homeland Security – DHS),és az Energiaügyi Minisztérium (U.S. Department of Energy – DoE). Különösen kényes szál a történetben, hogy a szintén kompromittálódott FireEye kiberbiztonsági cégtől olyan támadásra alkalmas programkódokat sikerült lopniuk a kiberbűnözőknek, amelyek alkalmasak bizonyos informatikai rendszerek további eredményes kompromittálására. (Ez is akár külön cikk témája lehetne...)

A másik eset ugyan lényegesen kisebb visszhangot kapott a szaksajtón kívül, ennek ellenére szintén egy igen fajsúlyos eset (a kivizsgálása jelenleg is zajlik): a 2021. februárban derült ki, hogy a francia Centreon által forgalmazott felügyeleti szoftver kompromittálásával egyelőre nem meghatározott számú ügyfelet sikerült kompromittálni a támadóknak. A vállalat ügyfelei között világszerte mintegy 600 nagyvállalat található, valamint Franciaországban számos közintézmény, például a francia Igazságügyi Minisztérium.

A harmadik incidens – amely úgy látszik, hogy súlyosságában megelőzte a Solarwinds esetet is – a Microsoft Exchange nulladik napi hibáit kihasználó támadássorozat. Az elemzések szerint csak Amerikában 30.000 vállalatot / szervezetet érint, világszerte több 10.000 áldozat van még. Ez a támadás nem tipikus „szoftver-ellátási lánc”-ot érintő támadás, mivel a támadó nem módosította a cég által fejlesztett szoftvert, de jelen listába két okból kívánkozik:

·        egyrészt itt is hasonló az a mintázat, hogy egy igen elterjedt szoftver hibája miatt tömegesen esnek áldozatul a felhasználók

·        másrészt a SolarWinds incidensben a Microsoft is az áldozatok között volt bizonytalan időn keresztül, és az ő esetükben az adatlopás az Exchange termékek forráskódját is érintette, így nem zárható ki, hogy a jelenlegi támadássorozathoz szükséges információk is így kerülhettek ki.

Ezzel együtt ezt az esetet a későbbiekben mindig külön tárgyaljuk, mivel nem tipikus példa.

Az esetekben számos hasonlóság van, amiket érdemes vizsgálni:

·        Az első két esetben biztonsági / üzemeltetési felügyeleti szoftvert fejlesztő céget támadtak. Ezen szoftverek (és a fejlesztők) a támadó szempontjából igen jó célpontok, mivel ezek az eszközök általában meglehetősen nagy jogosultságokkal rendelkeznek a felhasználóknál. Sok szervezetnél valamennyi alhálózatba „belátnak”, hogy ott is monitorozni tudják az eszközöket. Ha egy ilyen biztonsági rendszert sikerül kompromittálni a támadónak, akkor az áldozat hálózatában egy pillanat alatt riasztóan erős helyzetbe kerül. E megállapítások kis pontosítással igazak a Microsoft esetére is, annyiban, hogy az Exchenge szerverek is általában a hálózatokban különleges helyet foglalnak el.

·      Fontos szempont mindhárom esetben az IT biztonsági cégek / nagy „dobozos szoftver” szállítók esetében számítani lehet arra, hogy feléjük nagyobb a felhasználók bizalma, így adott esetben nagyobb jogokat is kap(hat)nak, mint egy „egyszerű” beszállító. Ez fokozottan teheti őket első lépcsős célponttá.

·      Mindhárom esetben számottevő volt az incidens észlelési / kezelési ideje. A Solarwinds esetben a támadók legalább 9 hónapon keresztül tevékenykedtek észrevétlenül a fejlesztő cég hálózatában (és az áldozat hálózatokban, köztük a szintén biztonsági cég FireEye-éban, aki az incidenst végül észlelte), míg a  Centreon-nál a jelenlegi becslések szerint 3 év(!!) volt ez az időszak. A Microsoft eset még kivizsgálás alatt van, de itt is legalább 2 hónapról van szó (ez akár több is lehet), számos szervezet jelenleg még nem hárította el a problémát. E fenti adatok különösen szomorúak abban a tekintetben, hogy az áldozatok között kormányzati szervezetektől multinacionális cégekig, nagyon komoly IT infrastruktúrát működtető intézményekről szó, akik nem észlelték a problémát!

·        Jellemző ezekre az esetekre, hogy a támadók nagyon magas szakmai tudással rendelkeztek. Az akciók fejlett, kétlépcsős, célzott támadások voltak, nagy áldozati körrel. A támadások elsődleges céljai – a kompromittált fejlesztő cégek és szoftvertermékek – „csak” az eszközök voltak arra, hogy a valóban elérni kívánt áldozatok hálózataihoz hozzáférjenek. Fontos megállapítani, hogy egyetlen igazán sikeres támadással számos (több tízezer) célpontot tudtak eredményesen kompromittálni, így ez a támadó szempontjából roppant hatékony megoldás, mind költségek, mind erőforrás szempontjából. A befektetett erőforrásokhoz képest felbecsülhetetlen méretű eredményt érnek el ezzel. Meg kell jegyezni ugyanakkor, hogy mind a támadás, mind a rengeteg célpont „kezelése” (adatok ellopása és felhasználása) ebben a nagyságrendben már igen erőforrásigényes feladat. Ennek ellenére erre a támadás típusra „érdemes” nagy erőforrásokat fordítani, hiszen „megéri”. Tudjuk, hogy szervezett bűnözői körök, illetve állami támogatással rendelkező hacker csoportok jelentős erőforrásokat képesek beletenni ilyen támadásokba. Ez a „szoftver-ellátási lánc”-ot érintő támadások igazi kockázat!

Fenti rövid kis elemzés alapján láthatóak a kockázatai ennek a támadás típusnak, illetve levonhatunk néhány alapvető következtetést:

·   Minden fejlesztő cég elsődleges célpont lehet, amely működési modellje az, hogy a fejlesztendő rendszer a felhasználó hálózatában kerül beüzemelésre, és / vagy a fejlesztő valamilyen módon eléri azt, főként frissítéseken keresztül.

·   Minden üzemeltető cég elsődleges célpont lehet, amely a felhasználó hálózatához távolról hozzáfér és ott üzemeltetési feladatokat lát el.

·        A fejlesztő és üzemeltető cégek akár a támadási sor több helyén is érintettek lehetnek, azaz mind elsődleges, mind másodlagos célpontok lehetnek, majd ebből válhatnak további támadások kiinduló pontjává.

·        A cégek / felhasználók tömegesen válhatnak másodlagos célponttá.

·     Létfontosságú infrastruktúra elemek (energetika, pénzügy, telekommunikáció, egészségügy, stb.) válhatnak tömegesen áldozattá egy jól megválasztott elsődleges célponton keresztül

Emiatt a „szoftver-ellátási lánc” szereplői közötti bizalom alapjaiban rendülhet meg. Másik szomorú következmény lehet, hogy a biztonságos üzemeltetéshez szükséges szoftverfrissítések egyébként is sok esetben nem megfelelően vannak kezelve, ilyen incidensek után ez a kérdés még problémásabbá válik.

Hogyan akadályozzuk meg ezeket a típusú támadásokat?

Valójában az ilyen típusú támadásokkal szembeni védekezési lehetőségek elméleti taglalása már évtizedek óta megvan. A szakirodalomban ajánlások, szabványok léteznek, amelyek ezzel a témával foglalkoznak. Úgy tűnik azonban, hogy mivel az eddigi incidensek nem vitték át a törvényhozók, állami szereplők, pénzintézetek és nagyvállalatok ingerküszöbét így sajnos ezek a javaslatok nem kerültek át mindennapos IT iparági gyakorlatba. Nyilvánvaló, hogy a fejlesztés (és üzemeltetés) biztonságának, az ellátási lánc védelmének a közeljövőben nagyobb szerepet kell kapnia. Mindezt úgy, hogy ez az eljárás igazolt, dokumentált módon történjen, úgy a felhasználói oldal is elismerje ezt.

A rendszer / szoftver fejlesztések IT biztonsági megfelelőségét számos nemzetközi és hazai szabályozás javasolta vagy elvárta volna a múltban, melyek közül említsünk meg az egyik legkorábbit:

A Common Criteria – „informatikai biztonság értékelésének közös kritériumai” (CC)[1], és a kapcsolódó módszertan, a „módszertan az információs technológiák biztonságának értékelésére” (CEM)[2] több, mint 20 éves (sőt!) múltra tekint vissza és foglalkozik azokkal a kérdésekkel, amelyek a szoftver-ellátási láncban igen fontosak: szoftver termékek biztonsági funkcionalitása, konfiguráció- és változás kezelés megfelelősége, fejlesztés biztonsága, hozzáférések szabályozása, szoftver „szállítása”, stb. A CC 2005 óta szabvány: ISO/IEC 15408 számon.

Ez alapján éppen azt lehetne biztosítani, hogy a tanúsított szoftvertermék a meghatározott biztonsági céloknak megfelelő biztonsági működéssel rendelkezik és a fejlesztése is biztonságos. 2008-ban hazai séma is megjelent a CC-hez Magyar Informatikai Biztonsági Értékelési és Tanúsítási Séma (MIBÉTS) néven. Mindezek ellenére sajnos a későbbiekben sem a világban, sem itthon nem terjedt el számottevően sem a CC / MIBÉTS, sem a  ISO/IEC 15408 szabvány szerinti tanúsítás tömeges gyakorlata.

Jelen dokumentumnak nem célja a CC kritikai elemzése, azonban vélhetően azért nem terjedt el jobban, mert a termék, illetve rendszer értékelése és tanúsítása – főleg komolyabb biztonsági szinteken – roppant nehézkes, jelentős dokumentációs követelményeket támaszt, igen költséges és időigényes eljárás.

Szintén nem elhanyagolható szempont, hogy szoftver termék esetén a CC tanúsítás gyakorlatilag egy pillanatképet ad meg, mivel egy adott verzióra vonatkozik, annak ellenére, hogy a CC vizsgálja a szoftver életciklus folyamatokat is. Ez egyből felveti azt a problémát, hogy mi történik továbbfejlesztés, hibajavítás esetén a szoftver tanúsításával. Jó példa a problémára, hogy melyik verziót kell használnia annak az ügyfélnek, aki kötelezett „tanúsított” szoftver használatára – frissíthet-e vagy akkor elveszti a tanúsított szoftvert?

Fentiek ellenére jelenleg a piac sajnos gyakorlatilag semmilyen szinten nem premizálja ezeket a bizonyított biztonsági erőfeszítéseket.

Érdemes megemlíteni még az ISO 27001-es szabványt, azzal a megjegyzéssel, hogy véleményünk szerint ez a szabvány – tekintettel elsősorban szervezeti és nem technikai megközelítésére, illetve magasabb szintű szemléleletére – nem elégséges arra, hogy adott szoftver termékek, illetve rendszerek jelen cikkben vizsgált típusú megfelelőségét valóban biztosítsa. Természetesen el tudunk képzelni olyan biztonságirányítási rendszert, ahol ezek a követelmények is teljesülnek, de ellenérzésünket támasztja alá az is, hogy a 27001-hez egyes területeken különböző kiegészítő követelmény rendszerek készülnek, finomítva ezzel a 27001 hatókörén.

Javaslatok

Javaslatunk szerint a következő témakörökben történő jelentős előrelépés biztosítaná a szoftver-ellátási lánc megfelelő működését, megbízhatóságát.

1. Szoftver, illetve rendszer akkreditációk, minősítések ágazati bevezetése, ezek elterjedésének megkövetelése

Véleményünk szerint elkerülhetetlen, hogy a jövőben – legalábbis egyes ágazatokban – kötelezően szoftver termék minősítések / akkreditációk kerüljenek bevezetésre. Egyrészt ez nem példa nélküli ötlet, mivel már most vannak olyan rendszerek, szervezetek ahol ilyen minősítési rend létezik, és szabványok is vannak a területen, azonban fent említett okok miatt egyelőre ez nem terjedt el.

Fontos, hogy a minősítési rendszer kockázatarányos legyen, azonban itt le kell szögeznünk, hogy egy „nem túl komoly” rendszer kockázati szintje nem csak önmagától függ, hanem sokkal inkább attól, hogy milyen szervezetnél, és környezetben működik és az esetleges kompromittálódása esetén milyen következmények történhetnek. Az adott rendszerek kockázati szintjeit akár központilag is meg lehetne határozni, elkerülve ezzel azt, hogy az érintett intézmények önállóan, különböző módon próbálják megítélni ugyanazt a problémát. Ezzel az intézmények válláról komoly felelősséget lehetne levenni.

A minősítési rendszerek az egyszerűség kedvéért ágazati szinteken valósulhatnának meg, ami egyébként egybecseng a NIS irányelv[3] vagy az ennek alapján készült hazai stratégia, illetve intézkedési terv[4] által javasoltakkal is. Ez biztosíthatná, hogy az ágazati cél- és szakalkalmazások speciális vizsgálatai is megtörténhessenek.

Az egyes központi hatóságok – kormányzati, katonai, stb.  – feladata lenne az általános célú, illetve az ágazatfüggetlen horizontális alkalmazások vizsgálata például az alaprendszerek és biztonsági rendszerek tekintetében. A nagy szoftvergyártók esetében újra kellene gondolni a korábbi kormányzati együttműködési projekteket, tekintettel arra, hogy ezen szoftverek esetén nemzetbiztonsági méretű kitettség van (pl.: MS, Oracle, Cisco, SAP). Ebben az esetben – tekintettel az Exchange incidensre – a rendszerek forráskódszintű ellenőrzésére is ki kell dolgozni megbízható megoldásokat, elsősorban kormányzati szinten, akkreditált nemzetközi vizsgáló laboratóriumokkal.

A minősítés / akkreditálás kérdését minden kritikus ágazatban jogszabályi kötelezettséggé kell tenni, mivel sajnos nem lehet arra számítani, hogy a piac ezt önszántából támogatni fogja.

A rendszerek vizsgálata során nyilvánvalóan nagyobb hangsúlyt kell fektetni a fejlesztési, üzemeltetési folyamatokra, mivel egy egyszeri – egy verzióra vonatkozó – termék tanúsítás nem fogja elérni a kívánt célt. A folyamatok (pl.: hozzáférések kezelése, verziókezelés, változás kezelés, tesztelés, dokumentáció) ugyanolyan fontosak a termék értékelése során, mint maga a termék, ennek megfelelően a termék tanúsítások során a fejlesztő szervezeteket is vizsgálni szükséges, akár önálló szervezet értékelés folyamatában.

Az eddig is vizsgált biztonsági fejlesztési folyamatok vizsgálatai közé hangsúlyosabban be kell emelni és szigorúan kell ellenőrizni néhány olyat, amely a fent elemzett esetekben kulcsfontosságúak lehettek volna.

Ezek egyike a rendszeres sérülékenység vizsgálatok végzése és azok eredményeinek nyomon követése. Ezek szükségesek a rendszerek gyakorlati biztonsági szintjének folyamatos ellenőrzéséhez. Emellett a napló-, illetve hálózati forgalom elemzés fejlesztése is szükséges, mivel látható, hogy az incidensek korai észlelésével még a legkomolyabb szervezeteknek is komoly problémái vannak. E területeken a követelmények adminisztratív kielégítése nem elégséges.

Meg kell még említeni, hogy az IT biztonsági követelmények mellett az adatvédelmi, adatbiztonsági követelményeknek is meg kell jelenniük az akkreditációs, minősítési rendszerekben.

A szállítói / hatósági auditok, vizsgálatok egyébként ismert rendszerét nagyon komolyan szükséges kiterjeszteni és megkövetelni a szoftver-ellátási lánc minden szegmensében, beleértve a „dobozos szoftverek”-et is. Az egyedi fejlesztésű szoftverek esetében pedig ezeknek gyakorlatilag természetessé kellene válnia. A kiemelt területeken mindenképpen biztosítani szükséges a fejlesztő, illetve üzemeltető ellenőrizhetőségét a felhasználók által. Addig is, amíg nem alakul ki a minősítések, akkreditációk átfogó rendszere, addig is javasolt, hogy a megrendelő szervezetek független információbiztonsági ellenőrzéseket és auditokat hajtsanak végre szállítóknál a megkövetelt feltételek ellenőrzésére. Ennek folyamatát érdemes már a szerződéskötés, megrendelés során rögzíteni, sőt, akár már a beszállítói rendszerbe való bekerülésnek is része kell, hogy legyen. Ez egyébként nagyon sok cégnél már ma is működik, azonban ezen vizsgálatok többnyire a valódi IT biztonsági helyzetet nem vizsgálják megfelelő mélységben, főleg nem fejlesztési területen.

2. Fejlesztők és üzemeltetők biztonság tudatosságának fejlesztése, szakértői biztonsági minősítések bevezetése és megkövetelése

Sajnálatos módon az incidensek kivizsgálása során igen sok esetben derül ki az, hogy elkerülhető emberi hiba is közrejátszott az incidens kialakulásában. Ahogy az a híradásokban megjelent megerősítésre került, a fent említett Orion incidensben valóban szerepe volt egy „solarwinds123” jelszónak is, ami lássuk be, nem méltó egy IT biztonsági fejlesztő céghez. De ugyanígy megemlíthetnénk számos szervezetnél a nem frissített rendszereket, vagy a nem megfelelő minőségben fejlesztett kódot.

Manapság az IT területei jelentős specializációt igényelnek, így a fejlesztők és az üzemeltetők is valójában már régen nem két szakterület, hanem több tíz. Mindannyi területen komoly biztonsági tudással, tapasztalattal, elvárásokkal rendelkeznek a szenior kollégák, ami jellemző az adott tudásterületre. Itt az ideje szakítani azzal a nézettel, hogy egy IT biztonsági területen képzetlen, tapasztalat nélküli fejlesztő megfelelő kódot tud előállítani – valójában még keretrendszerek használatával sem, sőt, ezek nem megfelelő felhasználása külön kockázatot jelenthet.

Napjainkra – bár az oktató cégek ontják a 3-6 hónapos tanfolyamokról a fejlesztőket – igen megnőtt a belépési küszöb a valódi enterprise fejlesztések és üzemeltetések területére. A fizikai világból vett példával, míg a saját házának az építését senki nem bízná rá a szomszéd fiúra, aki nagyon ügyes szakmunkás tanuló, addig igen komoly rendszerek fejlesztésében tömegével vesznek részt releváns végzettség és tapasztalat nélküli informatikus munkatársak. Egy forráskód / rendszer minőségét sajnos a megrendelők a legritkább esetben tudják megítélni, míg szakértői szemmel döbbenetes különbségek vannak.

Sajnos a biztonságtudatos fejlesztést és üzemeltetést nem árazza be a piac, pedig egyre inkább látható, hogy hova vezet ez. A piac nem azért dönt egy rendszer sikere mellett, mert biztonságos (mivel ezt nem igazán tudja mérni), hanem azért mert mondjuk szép, használható, felhasználó barát és jó a funkcionalitása. Ezek lássuk be, dicséretes tulajdonságok, de a támadásoktól nem óvnak meg minket.

Fentieknek megfelelően a fejlesztői és üzemeltetői biztonság tudatosság területét is mérhetővé kell tenni, és adott szegmensekben ezt meg kell követelni.

Ezek alapján azt javasoljuk, hogy a fejlesztői és üzemeltetői képzésekbe alap építőelemként kerüljenek bele a releváns biztonsági vonatkozások. Egyrészt általános szinten – alap biztonság tudatosság –, másrészt a tudásterület részeként:

·        fejlesztőknél az adott keretrendszer, technológia, nyelv biztonsági funkciói, azok megfelelő használata, módszertani ismeretek

·        üzemeltetőknél az alkalmazott eszközök, technológiák biztonsági beállításai, hardening eljárások, módszertani ismeretek

·        minden területen biztonságos tervezés ismeretei és még számos egyéb terület érinthető lenne

E képességek mentén a fejlesztési, üzemeltetési területeken is meg kellene követelni, hogy bizonyos biztonsági szint feletti termék fejlesztése / üzemeltetése esetében a szállítók a megfelelő biztonsági tudással rendelkező, képesített munkatársakkal rendelkezzenek.

További gondolatindítóként jegyezzük meg, hogy a HR kérdéseket az IT szervezetekben kiemelten át kell tekintetni az IT biztonság vonatkozásában, mivel például a fluktuáció, vagy a gyakornoki rendszerek, illetve egyéb okok miatt számos esetben olyan hozzáférések történhetnek, amelyek egy kritikus rendszer esetében nem megengedhetőek. Jól ismert nehézség például a technikai felhasználók kezelése, ahol 1-1 rendszergazda kolléga távozása után komoly erőforrás ráfordítással lehet csak végrehajtani egy jelszó cserét a teljes rendszerben. Itt például egy egyszerű HR eset egy igen komoly IT biztonsági problémává válik. Úgy tűnik, hogy a jövőben az ilyen problémák megoldását nem lehet majd megtakarítani.

3. Innováció a kibervédelemben

Sajnos napjainkban a digitális fejlődés egyik, talán a legfőbb objektív hátráltató tényezője a globális szintű szakértő hiány, mind a teljes IT területen, mind az IT biztonság területén. Ennek megfelelően a kiberbiztonsági helyzetben komoly innováció nélkül félő, hogy középtávon sem érthetőek el jó eredmények, s az incidensek előbb-utóbb jóvátehetetlen károkat is okoznak.

A kibervédelemben az innováció irányai között mindenképpen ott kell majd lennie az alábbi témáknak:

·  biztonsági vizsgálatok tömeges elvégzésének erőteljes támogatása, mind a gyakorlati vizsgálatok, mind a megfelelőségi vizsgálatok területén

·        rendszer monitoring eszközök fejlesztései

·        incidens felderítés támogatása: naplóelemzés, hálózati forgalom elemzés erőteljes fejlesztése

·        fejlesztői keretrendszerek biztonsági fejlesztései

      a rendelkezésre álló fejlesztői eszköztár biztonságosabbá tétele

      a fejlesztés teljes életciklusában, beleértve a változáskezelést is

·        forráskód elemző eszközök fejlesztései

·        rendszerek önvédelmi képességeinek erősítése: önmonitorozás, kompromittálódás nehezítése

·        üzemeltetés támogatás

Összefoglalás

A „szoftver-ellátási lánc”-ot célzó támadások valóban fenyegetik a jelenleg szépen fejlődő digitális gazdaságot és digitális állami működést. Ezen eredmények fenntartása és fejlesztése érdekében szükséges a szoftver termékek, illetve informatikai szolgáltatások tekintetében is bevezetni olyan biztonsági / minőségbiztosítási eljárásokat, folyamatokat és követelményeket amelyekhez hasonlóak más iparágakban – pl.: gépjármű gyártás, gyógyszeripar, építőipar – már akár sok évtizedes múltra tekintenek vissza és teljesen természetesnek számítanak.

Erdei Csaba

az 
Infotér Egyesület és a Modern Vállalkozások programjának IT biztonsági szakértője,
valamint az ACPM IT Kft. IT biztonsági tanácsadó cég ügyvezetője

 



[1]      Common Criteria for Information Technology Security Evaluation (CC)

[2]      Common Methodology for Information Technology Security Evaluation (CEM)

[3]      AZ EURÓPAI PARLAMENT ÉS A TANÁCS (EU) 2016/1148 IRÁNYELVE (2016. július 6.) a hálózati és információs rendszerek biztonságának az egész Unióban egységesen magas szintjét biztosító intézkedésekről

[4]      Magyarország hálózati és információs rendszerek biztonságára vonatkozó Stratégiájáról szóló 1838/2018. (XII. 28.) Korm. határozat alapján, A hálózati és információs rendszerek biztonságára vonatkozó Stratégia végrehajtásának 2020-2022. évekre vonatkozó intézkedési terve