Amikor a Digitális Operatív Ellenállóképességi Rendeletet (DORA) 2025 januárjában az Európai Unió egész területén kötelezően alkalmazandóvá tették, az adminisztratív feladatok hirtelen felpörögtek. A pénzügyi szervezetek az első évet azzal töltötték, hogy kialakítsák a kockázatirányítási keretrendszert, felmérjék a harmadik fél szolgáltatókat, módosítsák a szerződéses kikötéseket, és dokumentálják az incidensek eszkalációs folyamatait.

A második évre viszont nehezebb szakaszhoz érkezett a DORA: most már azt kell bizonyítani, hogy a keretrendszerek a gyakorlatban is jól működnek. Az uniós felügyeleti szervek egyre nagyobb hangsúlyt helyeznek a DORA gyakorlati megvalósítására, az információs és kommunikációs technológiai (ICT) incidensek elemzésére, valamint az ICT kockázatfelügyelet hatékonyságára. A biztonsági csapatok számára ez egy fontos kérdést vet fel: van-e a SOC-nak elég rálátása ahhoz, hogy észlelje, kivizsgálja és pontosan behatárolja egy aktív betörés kiterjedését a kritikus rendszerekben?

A DORA nem ír elő konkrét biztonsági stack-et, de több követelménye is arra épül, hogy az ICT környezetben folyamatos legyen a láthatóság, és így időben felismerhető legyen minden olyan viselkedés, amely egy kialakuló kockázatra utalhat.

A folyamatos monitorozás több, mint egy leltár

A DORA szempontjából a folyamatos monitorozás nem merül ki abban, hogy tudjuk, minek kellene történnie a hálózatban. A lényeg az, hogy legyen elég rálátásunk ahhoz, hogy észrevegyük, amikor az üzemszerű működés mintázatai eltérnek a megszokottól.

A DORA 9. cikke előírja, hogy a pénzügyi szervezeteknek folyamatosan figyelniük és kezelniük kell az ICT ökoszisztémájuk biztonságát és működését, és olyan folyamatokat kell bevezetniük, amelyek csökkentik az ICT kockázatok hatását.

Az eszközleltár megmutatja, milyen rendszereket birtokol vagy üzemeltet egy pénzügyi intézmény. A konfigurációs nyilvántartásokból kiderül, hogyan kellene ezeknek a rendszereknek egymással együttműködniük. A biztonsági logok és az endpoint telemetria részletes képet adnak a felügyelt rendszereken zajló tevékenységről.

Önmagukban azonban ezek a források sem feltétlenül adnak teljes képet a rendszerek közötti kommunikációról – különösen az örökölt infrastruktúra, a speciális célgépek, a nem menedzselt eszközök vagy az olyan rendszerek esetében, ahol az endpoint telemetria korlátozott. Az alkalmazkodó, AI-sebességű fenyegetésekkel szemben viszont átfogó rálátásra van szükség, hogy azonosítani lehessen azokat a vakfoltokat, amelyeket a támadók tudatosan keresnek. A rendszerek közötti, nem monitorozott kapcsolatokban is lehetnek a kihasználás nyomai, és azok a szervezetek, amelyek ezekre a réseken zajló forgalomra is rálátnak, sokkal nagyobb eséllyel tudják megszakítani a támadási láncot.

A Network Detection and Response (NDR) segít ezt a részletességet egyben látni, és így támogatja a szervezeteket abban, hogy közelebb kerüljenek a DORA elvárásainak teljesítéséhez. A környezet folyamatos monitorozásával az NDR kialakítja a normál működés alapmintáit, és az időzítés, a forgalom mennyisége és iránya alapján értékeli, mikor tér el a kommunikáció a várttól.

Például ha egy fizetési útvonalválasztó alkalmazás, amely normál esetben egy külső hitelbíráló szolgáltatással kommunikál, hirtelen jóval többet kezd beszélgetni ismeretlen belső gépekkel munkaidőn kívül, a hálózati telemetria akkor is rámutat erre az anomáliára, ha magának az alkalmazásnak a logjai nem.

Az anomáliák észleléséhez kontextus kell

A DORA következő szabálya, a 10. cikk előírja, hogy a pénzügyi intézményeknek gyorsan fel kell ismerniük a rendellenes tevékenységeket, beleértve a hálózati teljesítményproblémákat és a kapcsolódó incidenseket is. Emellett küszöbértékeket is meg kell határozni arra, mikor kell elindítani az incidenskezelést.

Biztonsági riasztásból nincs hiány, de a zaj mennyisége gyakran maga alá temeti a csapatokat, és elrejti a valódi, rendellenes viselkedésre utaló jeleket. A valódi probléma az, hogy kiderüljön: egy riasztás egy nagyobb incidens része-e. Előfordulhat például, hogy az EDR gyanús folyamatot jelez, miközben az identitáskezelő rendszer gyanús bejelentkezést észlel. A hálózati adatok össze tudják kötni a kettőt, mert megmutatják, mely rendszerek kommunikáltak egymással, milyen protokollokat használtak, és mi történt ezután. A command-and-control forgalom, a felderítés, az oldalirányú mozgás és az adatátvitel mind nyomot hagy a hálózati forgalomban, még akkor is, ha más telemetria hiányos vagy nem elérhető.

Az NDR skálázható módon teszi használhatóvá a hálózati bizonyítékokat: strukturált, protokollszintű adatokat nyer ki, amelyek segítik az elemzőket, hogy az összefüggésekre rálátva vizsgálják a riasztásokat, ne pedig elszigetelt forrásokból próbálják utólag összerakni az incidenseket. A kontextus teszi lehetővé, hogy a válaszadók meghatározzák egy incidens kiterjedését és hatását – különösen a mai, AI-sebességű támadások mellett –, ezek pedig közvetlenül befolyásolják a 19. cikk szerinti jelentési kötelezettségeket.

A vonatkozó szabályok szerint az első értesítést a lehető leghamarabb be kell nyújtani, de legkésőbb négy órával azután, hogy az incidenst súlyos, IKT-hoz kapcsolódó eseményként minősítették, és legkésőbb 24 órával azután, hogy a szervezet tudomást szerzett róla. A gyors hozzáférés a hálózati bizonyítékokhoz megadja a szükséges rálátást ahhoz, hogy a válaszadók gyorsan tudjanak lépni az összetett IT-környezetekben: visszakövessék az érintett rendszereket, elszigeteljék a rosszindulatú kapcsolatokat, és a rendelet által előírt határidőn belül összeállítsák a szükséges incidensdokumentációt.

A harmadik felek kockázata túlmutat a szerződésen

A 28–30. cikk a harmadik felekhez kapcsolódó IKT-kockázatkezelésre és a szerződéses megállapodásokra helyezi a hangsúlyt.

A szerződések és a beszállítók értékelése papíron rögzíti, hogy egy szolgáltató milyen hozzáférést kap, és hol húzódnak a működési határai. A hálózati adatok viszont megmutatják, hogyan működnek valójában a szolgáltató szoftvercsomagjai, alagutai és API-integrációi az IT-környezetben. Látszik belőlük, hogy a kapcsolatok betartják-e a jóváhagyott adatútvonalakat, vagy eltérnek a várakozásoktól.

Ha például egy megbízható beszállító hitelesítő adatai kompromittálódnak, a hozzáférés formálisan továbbra is jogos marad, a viselkedés azonban jó eséllyel megváltozik. Az NDR-ből származó hálózati bizonyítékok alapján a pénzügyi szervezet a saját környezetében figyelheti meg ezt a tevékenységet, és olyan kérdéseket tehet fel, amelyekre a beszállító dokumentációja nem ad választ:

• Mely belső rendszerekkel kommunikál a kapcsolat?
• Megfelel a forgalom a dokumentált hatókörnek?
• Változott a kapcsolat időzítése, a használt protokoll vagy az adatforgalom mennyisége?

A második év: működnek-e valójában a kontrollok?

Ahogy a pénzügyi intézmények belépnek a DORA második évébe, egyértelművé válik, hogy a hálózati átláthatóság közvetlenül kapcsolódik a 9. és 10. cikk követelményeihez: a folyamatos monitorozáshoz, az észleléshez és a gyors reagáláshoz. A hálózati adatok abban is segítenek, hogy a szervezetek alaposan kivizsgálják az IKT-harmadik feleket érintő incidenseket, ahogy azt a 28–30. cikk előírja.

Az NDR ezt az átláthatóságot azzal biztosítja, hogy megmutatja, hogyan kommunikálnak a rendszerek, hol jelentkezik rendellenes tevékenység, és hogyan terjednek az incidensek a környezetben. Mivel a DORA előírja, hogy a pénzügyi szereplőknek észlelniük, kivizsgálniuk és kezelniük kell az IKT-hoz kapcsolódó incidenseket, érdemes egy egyszerűbb kérdést feltenni: van-e a SOC-od kezében elég bizonyíték ahhoz, hogy reagáljon egy támadásra, és meg is tudja azt fékezni?