DORA TLPT bizonyítékok ISO 27001 kontrollokhoz rendelve

Hétfő reggel 07:40 van, és egy közepes méretű pénzforgalmi intézmény CISO-ja ugyanannak a kényelmetlen kérdésnek három változatát nézi.

Az igazgatóság azt szeretné tudni, hogy a szervezet túlélne-e egy zsarolóvírus okozta kiesést az ügyfélfizetési portálon. A felügyeleti hatóság bizonyítékot kér arra, hogy a digitális működési rezilienciatesztelés nem PowerPoint-gyakorlat. A belső audit tiszta nyomvonalat vár a DORA-kötelezettségektől az IKT-kockázaton, az ISO 27001 kontrollokon, a teszteredményeken, a helyesbítő intézkedési terveken és a beszállítói bizonyítékokon át a vezetői jóváhagyásig.

A CISO-nál van egy red team jelentés. A SOC-nál riasztási képernyőképek vannak. Az infrastruktúra-csapatnál van egy biztonsági mentésből történő helyreállítási napló. A jogi területnél van egy DORA-felkészültségi nyomonkövető. A beszerzésnél felhőszolgáltatói megfelelőségi nyilatkozatok vannak.

Ezek azonban nincsenek összekapcsolva.

Itt bukik el sok DORA TLPT és rezilienciatesztelési program. Nem azért, mert maga a tesztelés gyenge, hanem azért, mert a bizonyítékok töredezettek. Amikor egy auditor azt kérdezi: „Mutassa meg, hogyan bizonyítja ez a teszt egy kritikus vagy fontos funkció rezilienciáját”, a válasz nem lehet egy képernyőképekkel teli mappa. Igazolható bizonyítékláncnak kell lennie.

Ez az a pont, ahol az ISO/IEC 27001:2022-vel összhangban álló IBIR ISO/IEC 27001:2022 valódi értéket ad. Az ISO 27001 struktúrát ad az alkalmazási területhez, a kockázatértékeléshez, a kontrollkiválasztáshoz, az alkalmazhatósági nyilatkozathoz, az operatív kontrollokhoz, a belső audithoz, a vezetőségi átvizsgáláshoz és a folyamatos fejlesztéshez. A DORA biztosítja az ágazatspecifikus szabályozói nyomást. A Clarysec módszertana és keresztmegfelelési eszközei a kettőt egyetlen auditkész bizonyítékmodellbe kapcsolják.

A DORA TLPT irányítási teszt, nem csupán támadásszimuláció

A fenyegetésalapú penetrációs tesztelés, vagyis a TLPT könnyen félreérthető. Műszaki szempontból kifinomult red team gyakorlatnak tűnhet: fenyegetettségi információk, reális támadási útvonalak, rejtett működés, kihasználási kísérletek, laterális mozgási forgatókönyvek és a blue team válaszintézkedéseinek ellenőrzése.

A DORA szempontjából a mélyebb kérdés a digitális működési reziliencia. Képes-e a pénzügyi szervezet ellenállni az üzleti folyamatokat érintő súlyos IKT-zavarnak, reagálni rá és helyreállni belőle? Tudja-e bizonyítani, hogy a kritikus vagy fontos funkciók a hatástűrési határokon belül maradnak? Képes-e a vezetés igazolni, hogy az IKT-kockázat irányított, finanszírozott, tesztelt, kezelt és fejlesztett?

A DORA 1. cikke egységes uniós keretrendszert hoz létre a pénzügyi szervezetek üzleti folyamatait támogató hálózati és információs rendszerek biztonságára. Kiterjed az IKT-kockázatkezelésre, a jelentős IKT-vonatkozású incidensek bejelentésére, a digitális működési rezilienciatesztelésre, az IKT harmadik felek kockázatkezelésére, a kötelező IKT-beszállítói szerződéses követelményekre, a kritikus IKT harmadik fél szolgáltatók felügyeletére és a felügyeleti együttműködésre. A DORA 2025. január 17-től alkalmazandó.

Azoknál a szervezeteknél, amelyekre a NIS2 is vonatkozik, a DORA az átfedő kiberbiztonsági követelmények tekintetében ágazatspecifikus uniós jogi aktusként működik. Gyakorlati szempontból a pénzügyi szervezeteknek az IKT-kockázatkezelés, az incidensjelentés, a tesztelés és az IKT harmadik felek kockázatai területén a DORA-t kell előtérbe helyezniük ott, ahol a szabályozási rezsimek átfednek, miközben továbbra is érteniük kell a NIS2 elvárásait a csoportstruktúrákra, a beszállítókra és a nem pénzügyi digitális szolgáltatásokra vonatkozóan.

A DORA a felelősséget a legfelső szintre helyezi. Az 5. cikk előírja, hogy az irányító testület határozza meg, hagyja jóvá, felügyelje és hajtsa végre az IKT-kockázati intézkedéseket. Ez magában foglalja a digitális működési reziliencia stratégiáját, az IKT üzletmenet-folytonossági szabályzatot, a reagálási és helyreállítási terveket, az auditterveket, a költségvetéseket, az IKT harmadik felekre vonatkozó szabályzatokat, a jelentési csatornákat, valamint a rendszeres képzésen keresztül biztosított megfelelő IKT-kockázati ismereteket.

Az auditkérdés tehát nem egyszerűen az, hogy „Lefuttattak-e TLPT-t?”

Hanem ez:

• Kapcsolódott-e a TLPT kritikus vagy fontos funkciókhoz?
• Engedélyezett, megfelelően hatókörbe vont, biztonságos és kockázatértékelt volt-e?
• Bevonták-e a beszállítókat, a felhőfüggőségeket és a kiszervezett IKT-szolgáltatásokat, ahol ez releváns volt?
• Keletkezett-e bizonyíték az észlelésről, a reagálásról, a helyreállításról és a levont tanulságokról?
• A megállapításokat kockázatkezeléssé, nyomon követett helyesbítő intézkedéssé, újrateszteléssé és vezetői jelentéstétellé alakították-e?
• Az alkalmazhatósági nyilatkozat megmagyarázta-e, hogy mely ISO 27001 Annex A kontrollokat választották ki a kockázat kezelésére?

Ezért kezeli a Clarysec a DORA TLPT bizonyítékokat IBIR-bizonyítási problémaként, nem pusztán penetrációs tesztelési teljesítésként.

Építse fel az ISO 27001 bizonyítékvázat a teszt megkezdése előtt

Az ISO 27001 előírja, hogy a szervezet hozzon létre, vezessen be, tartson fenn és folyamatosan fejlesszen egy IBIR-t, amely kockázatkezelési folyamaton keresztül megőrzi a bizalmasságot, a sértetlenséget és a rendelkezésre állást. A 4.1–4.4 pontok előírják, hogy a szervezet értse meg a belső és külső tényezőket, az érdekelt feleket, a jogi és szabályozási kötelezettségeket, az interfészeket és a függőségeket, majd dokumentálja az IBIR alkalmazási területét.

Egy DORA által szabályozott szervezetnél ennek a hatókör-meghatározási lépésnek kifejezetten tartalmaznia kell a kritikus vagy fontos funkciókat, az IKT-eszközöket, a felhőplatformokat, a kiszervezett működést, a fizetési rendszereket, az ügyfélportálokat, az identitásszolgáltatásokat, a naplózási platformokat, a helyreállítási környezeteket és az IKT harmadik fél szolgáltatókat. Ha a TLPT hatóköre nem vezethető vissza az IBIR alkalmazási területére, az auditnyom már eleve gyenge.

Az ISO 27001 6.1.1, 6.1.2 és 6.1.3 pontjai, valamint a 8.2 és 8.3 pontok kockázatértékelési és kockázatkezelési folyamatot írnak elő. A kockázatokat a bizalmasság, a sértetlenség és a rendelkezésre állás szempontjából kell azonosítani. Ki kell jelölni a kockázatgazdákat. Értékelni kell a valószínűséget és a következményeket. A kontrollokat ki kell választani, és össze kell vetni az Annex A-val. A maradványkockázatot a kockázatgazdáknak kell elfogadniuk.

Ez a híd a DORA és az auditkész tesztelés között.

A Clarysec Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint a Risk Management fázis 13. lépésében világosan leírja ezt a visszakövethetőségi szerepet:

A SoA gyakorlatilag áthidaló dokumentum: összekapcsolja a kockázatértékelést/kockázatkezelést a tényleges kontrollokkal. A kitöltésével egyúttal ellenőrizheti, hogy nem maradt-e ki valamelyik kontroll.

DORA TLPT esetén az alkalmazhatósági nyilatkozat nem lehet statikus tanúsítási artefaktum. Meg kell magyaráznia, hogy az olyan kontrollok, mint a beszállítói biztonság, az incidenskezelés, az IKT üzletmenet-folytonossági felkészültsége, a naplózás, a felügyelet, a műszaki sérülékenységkezelés, a biztonsági mentések, a biztonságos fejlesztés és a biztonsági tesztelés miért alkalmazhatók a reziliencia-forgatókönyvre.

Egy gyakorlati kockázati forgatókönyv így hangozhat:

„A privilegizált identitásszolgáltatói hitelesítő adatok kompromittálódása lehetővé teszi a támadó számára, hogy hozzáférjen a fizetésfeldolgozási adminisztrációs rendszerekhez, módosítsa az útválasztási konfigurációkat, és megzavarjon egy kritikus fizetési funkciót, ami szolgáltatáskiesést, szabályozási jelentéstételi kötelezettségeket, ügyfélkárt és reputációs kárt okoz.”

Ez az egyetlen forgatókönyv meghatározhatja a TLPT hatókörét, az észlelési használati eseteket, a beszállítói részvételt, a helyreállítási gyakorlatot, az igazgatósági jelentéstételt és a bizonyítékkészletet.

A Zenith Blueprint azt is javasolja, hogy a szabályozási visszakövethetőséget tegyék explicitté:

Hivatkozzon keresztben a szabályozásokra: Ha bizonyos kontrollokat kifejezetten a GDPR, NIS2 vagy DORA megfelelés érdekében vezettek be, ezt jelezheti akár a kockázati nyilvántartásban (a kockázati hatás indoklásának részeként), akár a SoA megjegyzéseiben.

Ez az iránymutatás egyszerű, de megváltoztatja az auditbeszélgetést. Ahelyett, hogy a szervezet azt mondaná az auditornak, hogy a DORA-t figyelembe vették, meg tudja mutatni, hol jelenik meg a DORA a kockázati nyilvántartásban, a SoA-ban, a tesztelési programban, a szabályzatkészletben és a vezetőségi átvizsgálásban.

Rendelje hozzá a DORA tesztelést az auditorok által ismert ISO 27001 kontrollokhoz

A DORA 6. cikke dokumentált, az átfogó kockázatkezelésbe integrált IKT-kockázatkezelési keretrendszert vár el. Az ISO 27001 Annex A adja azt a kontrollkatalógust, amely ezt működésbe fordítja.

A DORA TLPT és a rezilienciatesztelés szempontjából az alábbi ISO/IEC 27001:2022 Annex A kontrollok különösen fontosak:

A Clarysec Zenith Controls: The Cross-Compliance Guide Zenith Controls segít elkerülni, hogy a szervezetek ezeket a kontrollokat elszigetelt ellenőrzőlista-elemként kezeljék. Az ISO/IEC 27002:2022 kontrollokat attribútumokhoz, területekhez, működési képességekhez, auditelvárásokhoz és keretrendszerek közötti mintákhoz rendeli.

Például a Zenith Controls az ISO/IEC 27002:2022 5.30 kontrollját, az IKT üzletmenet-folytonossági felkészültségét „helyesbítő” kontrollként osztályozza, a „rendelkezésre álláshoz” igazítja, a „reagálás” kiberbiztonsági fogalmához kapcsolja, és a „reziliencia” területre helyezi. Ez az osztályozás hasznos annak elmagyarázásakor az auditoroknak, hogy egy helyreállítási gyakorlat nem csupán IT-üzemeltetési művelet, hanem a kontrollkörnyezetben meghatározott szereppel rendelkező rezilienciakontroll.

A Zenith Controls a 8.29 kontrollt, a fejlesztési és átvételi biztonsági tesztelést is megelőző kontrollként osztályozza, amely támogatja a bizalmasságot, a sértetlenséget és a rendelkezésre állást, működési képességekkel az alkalmazásbiztonság, az információbiztonsági bizonyosság, valamint a rendszer- és hálózatbiztonság területén. Azoknál a TLPT-megállapításoknál, amelyek alkalmazástervezési gyengeségre, nem biztonságos API-viselkedésre, gyenge hitelesítési folyamatra vagy elégtelen ellenőrzésre vezethetők vissza, ez a kontrollút vezet be a biztonságos fejlesztés irányításába.

Az 5.35 kontroll, az információbiztonság független felülvizsgálata szintén fontos. Támogatja a független kontrollt, az irányítási bizonyosságot és a helyesbítő fejlesztést. A belső csapatok koordinálhatják a tesztelést, de az auditkész bizonyítékok felülvizsgálatot, eszkalációt és olyan felügyeletet igényelnek, amely túlmutat azokon, akik a tesztelt rendszereket építették vagy üzemeltették.

Védje a rendszert a tesztelés közben

A rezilienciatesztelés egyik veszélyes feltételezése, hogy a tesztelés automatikusan hasznos. A valóságban az invazív tesztelés kieséseket okozhat, érzékeny adatokat tehet ki, szennyezheti a naplókat, automatikus védelmi mechanizmusokat indíthat el, megszakíthat ügyfélmunkameneteket, vagy arra késztetheti a beszállítókat, hogy vészhelyzeti eljárásokat aktiváljanak.

A Clarysec Security Testing and Red-Teaming Policy Security Testing and Red-Teaming Policy irányítási mintát ad a biztonságos végrehajtáshoz. A 6.1 pont kimondja:

Teszttípusok: A biztonsági tesztelési programnak legalább a következőket kell tartalmaznia: (a) sérülékenységvizsgálat, amely hálózatok és alkalmazások automatizált heti vagy havi vizsgálatából áll az ismert sérülékenységek azonosítása érdekében; (b) penetrációs tesztelés, amely meghatározott rendszerek vagy alkalmazások szakértő tesztelők által végzett, manuális, mélyreható teszteléséből áll az összetett gyengeségek azonosítása érdekében; és (c) red teaming gyakorlatok, amelyek valós támadások forgatókönyv-alapú szimulációiból állnak, beleértve a szociális manipulációt és más taktikákat is, a szervezet teljes észlelési és reagálási képességeinek tesztelésére.

TLPT esetén a red teaming elem nyilvánvaló, de az auditérték a program kialakításából ered. A sérülékenységvizsgálatnak, a penetrációs tesztelésnek, a red team gyakorlatoknak, a rezilienciagyakorlatoknak és az újratesztelésnek ciklust kell alkotniuk, nem pedig egymástól független tesztek gyűjteményét.

Ugyanezen szabályzat 6.2 pontja a biztonságos végrehajtással foglalkozik:

Hatókör és végrehajtási szabályok: Minden teszt vagy gyakorlat esetében az STC meghatározza a hatókört, beleértve a hatókörbe tartozó rendszereket és IP-tartományokat, az engedélyezett tesztelési módszereket, a célokat, az időzítést és az időtartamot. A végrehajtási szabályokat dokumentálni kell. Például az üzemeltetési szempontból érzékeny rendszerek csak megfigyelésre kijelöltnek minősíthetők a zavar elkerülése érdekében, és minden éles környezetben végzett tesztelésnek tartalmaznia kell visszaállítási és leállítási eljárásokat. Biztonsági intézkedéseket, például meghatározott időablakokat és kommunikációs csatornákat kell létrehozni a nem szándékolt szolgáltatáskiesések megelőzésére.

Ez közvetlenül kapcsolódik a Zenith Blueprint Controls in Action fázisának 21. lépéséhez, amely az ISO 27001 Annex A 8.34 kontrolljára, az információs rendszerek audittesztelés közbeni védelmére összpontosít. A Zenith Blueprint figyelmeztet arra, hogy az auditok, penetrációs tesztek, forenzikus felülvizsgálatok és operatív értékelések emelt jogosultságú hozzáférést, invazív eszközöket vagy a rendszer viselkedésének ideiglenes módosítását igényelhetik. Hangsúlyozza az engedélyezést, a hatókört, az időablakokat, a rendszergazdai jóváhagyást, a visszaállítást, a felügyeletet és a tesztadatok biztonságos kezelését.

Az auditkész bizonyítékcsomagnak tartalmaznia kell:

• TLPT megbízólevél és célkitűzések
• Fenyegetettségi információk összefoglalója és a forgatókönyv indoklása
• Hatókörbe tartozó kritikus vagy fontos funkciók
• Hatókörbe tartozó rendszerek, IP-tartományok, identitások, beszállítók és környezetek
• Kizárások és csak megfigyelésre kijelölt rendszerek
• Végrehajtási szabályok
• Éles környezetben végzett tesztelés kockázatértékelése
• Visszaállítási és leállítási eljárások
• SOC értesítési modell, beleértve, hogy mit közölnek és mit tartanak vissza
• Jogi, adatvédelmi és beszállítói jóváhagyások
• Tesztfiókok létrehozásának és visszavonásának bizonyítékai
• Tesztartefaktumok és naplók biztonságos tárolási helye

Az a DORA TLPT, amely nem tudja igazolni a teszttevékenység biztonságos engedélyezését és kontrollját, ugyan feltárhat rezilienciabeli hiányosságokat, de egyúttal irányítási hiányosságokat is létrehoz.

Alakítsa a TLPT eredményeit kockázatkezeléssé

A teszt utáni leggyakoribb hiba a red team jelentés polcra kerülése. Elkészül egy magas színvonalú jelentés, köröztetik, megvitatják, majd fokozatosan elveszíti a lendületét. A megállapítások nyitva maradnak. A kompenzáló kontrollokat nem dokumentálják. Az elfogadott kockázatok informálisak. Újratesztelés nem történik.

A Security Testing and Red-Teaming Policy ezt elfogadhatatlanná teszi. A 6.6 pont kimondja:

Megállapítások helyesbítése: Minden azonosított sérülékenységet vagy gyengeséget súlyossági besorolással ellátott megállapítási jelentésben kell dokumentálni. A jelentés kézhezvételét követően a rendszergazdák felelősek helyesbítő intézkedési terv készítéséért határidőkkel; például a kritikus megállapításokat 30 napon belül, a magas súlyosságú megállapításokat 60 napon belül kell javítani, összhangban a szervezet Sérülékenység- és javításkezelési szabályzatával. Az STC nyomon követi a helyesbítő intézkedések előrehaladását. Újratesztelést kell végezni annak megerősítésére, hogy a kritikus problémákat megoldották vagy megfelelően mérsékelték.

A 6.7 pont hozzáadja az irányítási réteget:

Jelentéstétel: Minden teszt lezárásakor formális jelentést kell kiadni. Penetrációs tesztelés esetén a jelentésnek tartalmaznia kell vezetői összefoglalót, módszertant, valamint részletes megállapításokat alátámasztó bizonyítékokkal és ajánlásokkal. Red teaming gyakorlatok esetén a jelentésnek részleteznie kell a forgatókönyveket, hogy mely támadási útvonalak voltak sikeresek, mit észlelt a Blue Team, valamint az észlelési és reagálási hiányosságokra vonatkozó tanulságokat. A CISO összefoglaló eredményeket és a helyesbítő intézkedések státuszát bemutatja a felső vezetésnek, és ahol releváns, beépíti azokat az Igazgatóság éves biztonsági jelentésébe.

Ez összhangban áll az ISO/IEC 27005:2022 kockázatkezelési iránymutatásával: kezelési opciók kiválasztása, kontrollok meghatározása az ISO 27001 Annex A és ágazatspecifikus követelmények alapján, kockázatkezelési terv elkészítése, felelős személyek kijelölése, határidők meghatározása, státusz nyomon követése, kockázatgazdai jóváhagyás beszerzése és a maradványkockázat elfogadásának dokumentálása.

Minden jelentős TLPT-megállapításnak a következő négy dolog egyikévé kell válnia: helyesbítő intézkedéssé, kontrollfejlesztéssé, formális kockázatelfogadássá vagy újratesztelési követelménnyé.

A cél nem több dokumentum előállítása. A cél az, hogy minden dokumentum megmagyarázza a következő döntést.

A rezilienciatesztelésnek a helyreállítást kell bizonyítania, nem csak az észlelést

Egy sikeres TLPT megmutathatja, hogy a SOC észlelte a vezérlő- és irányító forgalmat, blokkolta a laterális mozgást, és megfelelően eszkalált. Ez értékes, de a DORA rezilienciatesztelés továbbmegy. Azt kérdezi, hogy a szervezet képes-e fenntartani vagy helyreállítani az üzleti szolgáltatásokat.

A Zenith Blueprint Controls in Action fázisának 23. lépése az 5.30 kontrollt, az IKT üzletmenet-folytonossági felkészültségét olyan nyelven magyarázza, amelyet minden CISO-nak használnia kell az igazgatóság felé:

Audit szempontból ezt a kontrollt gyakran egyetlen mondattal tesztelik: Mutassa meg. Mutassa meg az utolsó teszteredményt. Mutassa meg a helyreállítási dokumentációt. Mutassa meg, mennyi ideig tartott az átkapcsolás és a visszakapcsolás. Mutassa meg annak bizonyítékát, hogy amit ígértek, teljesíthető.

Ez a „Mutassa meg” mérce különbözteti meg a szabályzati érettséget az operatív rezilienciától.

A Clarysec Business Continuity Policy and Disaster Recovery Policy-sme Business Continuity Policy and Disaster Recovery Policy - SME a „Policy Implementation Requirements” szakasz 6.4.1 pontjában kimondja:

A szervezetnek legalább évente tesztelnie kell mind a BCP-, mind a DR-képességeit. A teszteknek tartalmazniuk kell:

Ugyanezen szabályzat végrehajtási szakaszának 8.5.1 pontja egyértelművé teszi a bizonyítékokkal kapcsolatos elszámoltathatóságot:

A GM köteles biztosítani, hogy az alábbiak fenn legyenek tartva és auditra alkalmas állapotban legyenek:

Egy DORA által szabályozott pénzügyi szervezet számára az éves tesztelés inkább minimum, nem ambíció. A magasabb kockázatú kritikus vagy fontos funkciókat gyakrabban kell tesztelni, különösen architekturális változások, felhőmigráció, jelentős incidensek, új IKT-beszállítók, lényeges alkalmazáskiadások vagy a fenyegetettségi kitettség változása után.

Egy erős rezilienciateszt-bizonyítékcsomagnak tartalmaznia kell:

• Üzleti hatáselemzés, amely feltérképezi a kritikus vagy fontos funkciót
• Üzleti folyamatgazdák által jóváhagyott RTO és RPO
• Rendszerfüggőségi térkép, beleértve az identitást, DNS-t, hálózatot, felhőt, adatbázist, felügyeletet, biztonsági mentést és harmadik fél szolgáltatásokat
• Biztonsági mentési és helyreállítási teszteredmények
• Átkapcsolási és visszakapcsolási időbélyegek
• Bizonyíték arra, hogy a biztonsági kontrollok zavar alatt is működtek
• Ügyfél-, felügyeleti hatósági és belső kommunikációs sablonok
• Incidensirányítási és válságkezelő csoport részvételi naplói
• Levont tanulságok és fejlesztési intézkedések
• Újratesztelési bizonyíték a korábbi helyreállítási hiányosságokra

Itt lép be a GDPR is a képbe. A GDPR 2. és 3. cikke az EU személyes adatainak legtöbb SaaS- és fintech-adatkezelését hatály alá vonja. A 4. cikk meghatározza a személyes adatot, az adatkezelést, az adatkezelőt, az adatfeldolgozót és a személyesadat-sértést. Az 5. cikk sértetlenséget, bizalmasságot és elszámoltathatóságot ír elő, ami azt jelenti, hogy a szervezetnek képesnek kell lennie a megfelelés bizonyítására. Ha a TLPT vagy a helyreállítási tesztelés éles személyes adatokat használ, azonosítókat tartalmazó naplókat másol, vagy adatsértés-kezelést ellenőriz, az adatvédelmi óvintézkedéseket dokumentálni kell.

A beszállítói bizonyíték a DORA vakfoltja, amelyet az auditorok nem fognak figyelmen kívül hagyni

A modern pénzügyi szolgáltatások felhőplatformokból, SaaS-alkalmazásokból, menedzselt biztonsági szolgáltatókból, fizetésfeldolgozókból, adatplatformokból, identitásszolgáltatókból, megfigyelhetőségi eszközökből, kiszervezett fejlesztőcsapatokból és biztonsági mentési szolgáltatókból épülnek fel.

A DORA 28. cikke előírja, hogy a pénzügyi szervezetek az IKT harmadik fél kockázatot az IKT-kockázatkezelési keretrendszer részeként kezeljék, és teljes felelősséggel tartozzanak akkor is, ha az IKT-szolgáltatásokat kiszervezik. A 30. cikk írásos IKT-szolgáltatási szerződéseket ír elő szolgáltatásleírásokkal, alvállalkozási feltételekkel, adatkezelési helyszínekkel, adatvédelemmel, hozzáféréssel és helyreállítással, szolgáltatási szintekkel, incidenstámogatással, hatósági együttműködéssel, felmondási jogokkal, a kritikus vagy fontos funkciókra vonatkozó szigorúbb feltételekkel, auditálási jogokkal, biztonsági intézkedésekkel, ahol releváns TLPT-részvétellel és kilépési megállapodásokkal.

Ez azt jelenti, hogy egy TLPT-forgatókönyv nem állhat meg a szervezet tűzfalánál, ha a kritikus funkció egy beszállítótól függ.

A Clarysec Third-Party and Supplier Security Policy-sme Third-Party and Supplier Security Policy - SME, a „Policy Implementation Requirements” szakasz 6.3.1 pontjában kimondja:

A kritikus vagy magas kockázatú beszállítókat legalább évente felül kell vizsgálni. A felülvizsgálatnak ellenőriznie kell:

A Security Testing and Red-Teaming Policy 6.9 pontja tesztelés-specifikus beszállítói követelményt ad hozzá:

Harmadik fél tesztelési koordináció: Amennyiben bármely kritikus beszállító vagy szolgáltató a szervezet átfogó biztonságának hatókörébe tartozik, a Third-Party and Supplier Security Policy szerint a szervezetnek, ahol megvalósítható, bizonyosságot kell szereznie azok biztonsági tesztelési gyakorlatairól, vagy közös tesztelést kell koordinálnia. Például ha Cloud Service Provider (CSP) kerül igénybevételre, a szervezet támaszkodhat annak penetrációs tesztelési jelentéseire, vagy szerződéses rendelkezések mellett bevonhatja együttműködésen alapuló red team forgatókönyvekbe.

Az auditkész DORA bizonyítékoknál a beszállítói bizonyosságot ugyanahhoz a kockázati forgatókönyvhöz kell kapcsolni, mint a TLPT-t. Ha az identitásszolgáltató alapvető a fizetések helyreállításához, a bizonyítékcsomagnak tartalmaznia kell a beszállítói átvilágítást, a szerződéses biztonsági követelményeket, az incidenstámogatási feltételeket, a tesztelési koordinációt, a bizonyossági jelentéseket, a szolgáltatási szint bizonyítékait, a kilépési stratégiát és a tesztelési korlátozásokat.

A NIS2 21. cikke a SaaS-, felhő-, menedzselt szolgáltatási, menedzselt biztonsági, adatközponti, CDN-, bizalmi szolgáltatási, DNS-, TLD-, online piactéri, kereső- és közösségi hálózati szolgáltatók szempontjából is releváns. Összkockázati megközelítést ír elő, amely kiterjed a kockázatelemzésre, az incidenskezelésre, az üzletmenet-folytonosságra, az ellátási lánc biztonságára, a biztonságos fejlesztésre, az eredményesség értékelésére, a képzésre, a kriptográfiára, a hozzáférés-szabályozásra, az eszközkezelésre, az MFA-ra és a biztonságos kommunikációra.

A gyakorlati következmény egyszerű: a pénzügyi szervezeteknek egyetlen bizonyítékmodellt kell kialakítaniuk, amely először a DORA-t elégíti ki, majd keresztbe hivatkozza a NIS2 elvárásait ott, ahol beszállítók, csoporton belüli szervezetek vagy nem pénzügyi digitális szolgáltatások érintettek.

Gyakorlati Clarysec TLPT bizonyítéknyilvántartás

Tegyük fel, hogy a forgatókönyv a következő:

„Egy fenyegető szereplő kompromittál egy rendszergazdai fiókot egy SaaS támogatási platformon, átlép a fizetési műveleti környezetbe, módosítja a konfigurációt, és megzavarja a tranzakciófeldolgozást.”

Hozzon létre bizonyítéknyilvántartást, bizonyítékobjektumonként egy sorral. Ne várjon a teszt végéig. Töltse fel a tervezés, a végrehajtás, a helyesbítő intézkedések és a lezárás során.

Ezután használja a Zenith Blueprint 13. lépését a kockázati nyilvántartásba és az alkalmazhatósági nyilatkozatba épített visszakövethetőség hozzáadásához. Minden bizonyítékelemnek kapcsolódnia kell egy kockázati forgatókönyvhöz, kockázatgazdához, kiválasztott kontrollhoz, kockázatkezelési tervhez és maradványkockázati döntéshez.

Ha egy megállapítás szoftveres gyengeséghez kapcsolódik, hivatkozzon a biztonságos fejlesztési és tesztelési kontrollokra. A Clarysec Secure Development Policy-sme Secure Development Policy - SME, a „Policy Implementation Requirements” szakasz 6.5.2 pontja előírja:

A tesztelést az alábbiakkal kell dokumentálni:

Ha egy megállapítás forenzikus anyagot eredményez, őrizze meg a bizonyítékláncot. A Clarysec Evidence Collection and Forensics Policy-sme Evidence Collection and Forensics Policy - SME, a „Governance Requirements” szakasz 5.2.1 pontja kimondja:

Minden digitális bizonyítékelemet naplózni kell az alábbiakkal:

Ezt sok csapat nem veszi észre. A bizonyíték nem csak a végső jelentéseket jelenti. Kontrollált nyilvántartás arról, hogy ki hagyta jóvá, ki hajtotta végre, mi történt, mit észleltek, mit állítottak helyre, mi változott, mi maradt kitettségként, és ki fogadta el ezt a kitettséget.

Hogyan vizsgálják az auditorok ugyanazokat a TLPT bizonyítékokat

A DORA TLPT bizonyítékokat az auditor hátterétől függően eltérően olvassák. A Clarysec úgy tervezi a bizonyítékcsomagokat, hogy minden nézőpont megtalálja benne, amire szüksége van, anélkül hogy a csapatoknak duplikálniuk kellene a munkát.

A COBIT 2019 megjelenik a Zenith Blueprint keresztmegfelelési hivatkozásában a biztonságos audit- és tesztvégrehajtásra vonatkozóan, beleértve a DSS05.03 és MEA03.04 elemeket. A lényeg nem az, hogy a COBIT kiváltaná a DORA-t vagy az ISO 27001-et, hanem az, hogy az ISACA-típusú bizonyossági szakemberek szabályozott végrehajtást, felügyeletet, értékelést és megfelelési bizonyítékokat keresnek.

Az igazgatósági narratíva: mit kell a vezetésnek jóváhagynia

Az igazgatósági jelentéstételnek kerülnie kell a technikai színházat. Az igazgatóságnak nincs szüksége exploit hasznos terhekre. Döntésre alkalmas bizonyítékokra van szüksége:

• Melyik kritikus vagy fontos funkciót tesztelték?
• Milyen fenyegetési forgatókönyvet szimuláltak, és miért?
• Működött-e az észlelés?
• Működött-e a reagálási eszkaláció?
• A helyreállítás megfelelt-e az RTO és RPO követelményeknek?
• Mely beszállítók voltak érintettek vagy korlátozottak?
• Milyen lényeges gyengeségek maradtak fenn?
• Mi a helyesbítő intézkedés költsége, felelőse és ütemezése?
• Mely maradványkockázatok igényelnek formális elfogadást?
• Mit fognak újratesztelni?

Itt válik fontossá az ISO 27001 5. pontja. A felső vezetésnek biztosítania kell, hogy az információbiztonsági szabályzat és célkitűzések létrejöjjenek, összhangban legyenek a stratégiai iránnyal, beépüljenek az üzleti folyamatokba, megfelelő erőforrást kapjanak, kommunikálva legyenek és folyamatosan fejlődjenek. Ki kell jelölni a szerepköröket és felelősségeket. A célkitűzéseknek, ahol megvalósítható, mérhetőknek kell lenniük, és figyelembe kell venniük az alkalmazandó követelményeket és a kockázatkezelési eredményeket.

Ha a TLPT azt azonosítja, hogy a helyreállítási idő hat óra egy négyórás üzleti toleranciával szemben, az nem pusztán infrastruktúra-backlog elem. Ez vezetői döntés, amely kockázatvállalási hajlandóságot, költségvetést, ügyfélvállalásokat, szabályozói kitettséget, szerződéseket, architektúrát és működési kapacitást érint.

Gyakori bizonyítékhiányosságok a DORA rezilienciatesztelésben

A Clarysec felülvizsgálatai gyakran ugyanazokat a bizonyítékhiányokat találják a DORA-ra készülő pénzügyi szervezeteknél és IKT-szolgáltatóknál.

Először: a TLPT hatóköre nem kapcsolódik kritikus vagy fontos funkciókhoz. A teszt lehet műszakilag lenyűgöző, de nem bizonyítja annak az üzleti folyamatnak a rezilienciáját, amely a felügyeleti hatóság számára lényeges.

Másodszor: a beszállítói függőségeket elismerik, de nem támasztják alá bizonyítékokkal. A csapatok azt mondják, hogy a felhőszolgáltató, a menedzselt SOC vagy a SaaS-platform hatókörben van, de hiányoznak a szerződések, az auditálási jogok, a tesztelési engedélyek, az incidenstámogatási feltételek és a kilépési tervek.

Harmadszor: a tesztelés bizonyítékot hoz létre, de nem eredményez kockázatkezelést. A megállapítások red team jelentésben maradnak, ahelyett hogy kockázati nyilvántartás frissítésekké, kontrollváltozásokká, felelősökké, dátumokká, újrateszteléssé és maradványkockázati döntésekké alakulnának.

Negyedszer: a helyreállítást feltételezik, nem pedig bizonyítják. Léteznek biztonsági mentési szabályzatok, de senki sem tud átkapcsolási időbélyegeket, helyreállítási sértetlenség-ellenőrzéseket, hozzáférés-ellenőrzést vagy üzleti folyamatgazdai megerősítést bemutatni.

Ötödször: az adatvédelmi és forenzikus bizonyítékok nincsenek kontroll alatt. A naplók és képernyőképek személyes adatokat tartalmaznak, a tesztartefaktumokat megosztott meghajtókon tárolják, az ideiglenes fiókok aktívak maradnak, és a bizonyítéklánc hiányos.

Hatodszor: a vezetői jelentéstétel túl technikai. A felső vezetők nem látják, javult-e a reziliencia, a kockázat a kockázatvállalási hajlandóságon belül van-e, vagy milyen beruházási döntésekre van szükség.

E hiányosságok mindegyike kezelhető azzal, ha a DORA TLPT-t strukturált ISO 27001 bizonyíték-munkafolyamatként kezelik.

A Clarysec integrált megközelítése az auditkész rezilienciához

A Clarysec megközelítése három réteget kombinál.

Az első réteg a Zenith Blueprint 30 lépéses bevezetési ütemterv. Ebben a témában a 13. lépés kockázatkezelési és SoA-visszakövethetőséget épít, a 21. lépés védi a rendszereket az audittesztelés során, a 23. lépés pedig ellenőrzi az IKT üzletmenet-folytonossági felkészültségét. Ezek a lépések a TLPT-t műszaki eseményből dokumentált irányítási ciklussá alakítják.

A második réteg a Clarysec szabályzattára. A Security Testing and Red-Teaming Policy meghatározza a teszttípusokat, a hatókört, a végrehajtási szabályokat, a helyesbítő intézkedéseket, a jelentéstételt és a beszállítói koordinációt. A Business Continuity Policy and Disaster Recovery Policy-sme elvárásokat határoz meg az éves BCP- és DR-tesztelésre, valamint az auditkész folytonossági bizonyítékokra. A Third-Party and Supplier Security Policy-sme támogatja a beszállítói bizonyosságot. A Secure Development Policy-sme biztosítja a biztonsági tesztelés dokumentálását. Az Evidence Collection and Forensics Policy-sme támogatja a bizonyítékok naplózását és a bizonyítéklánc fegyelmét.

A harmadik réteg a Zenith Controls, a Clarysec keresztmegfelelési útmutatója. Segít az ISO/IEC 27002:2022 kontrollokat attribútumokhoz, területekhez, működési képességekhez és keretrendszerek közötti elvárásokhoz rendelni. DORA TLPT esetén a legfontosabb minta nem egyetlen kontroll. Hanem a tesztelés, a folytonosság, az incidenskezelés, a beszállítókezelés, a naplózás, a felügyelet, a biztonságos fejlesztés, a független felülvizsgálat és az irányítás közötti kapcsolat.

Amikor ezek a rétegek együtt működnek, a CISO hétfő reggeli problémája megváltozik. Az igazgatóság, a felügyeleti hatóság és a belső audit három egymástól elszakadt kérdése helyett a szervezetnek egyetlen bizonyítéki története van:

„Azonosítottuk a kritikus funkciót. Értékeltük az IKT-kockázatot. Kiválasztottuk és indokoltuk a kontrollokat. Engedélyeztük és biztonságosan végrehajtottuk a TLPT-t. Észleltünk, reagáltunk és helyreálltunk. Bevontuk a beszállítókat, ahol szükséges volt. Dokumentáltuk a bizonyítékokat. Helyesbítettük a megállapításokat. Újrateszteltünk. A vezetés felülvizsgálta és elfogadta a fennmaradó kockázatot.”

Ez az auditkész reziliencia.

Következő lépések

Ha a DORA TLPT programja még mindig jelentések, nem pedig bizonyítékláncok köré szerveződik, kezdjen egy Clarysec bizonyítékbejárással.

Használja a Zenith Blueprint Zenith Blueprint 13. lépését a TLPT-forgatókönyvek kockázatokhoz, kontrollokhoz és az alkalmazhatósági nyilatkozathoz kapcsolására. Használja a 21. lépést a biztonságos engedélyezés, a végrehajtási szabályok, a visszaállítás, a felügyelet és a tisztítás ellenőrzésére. Használja a 23. lépést az IKT üzletmenet-folytonossági felkészültségének bizonyítására helyreállítási bizonyítékokkal.

Ezután hangolja össze működési dokumentumait a Clarysec Security Testing and Red-Teaming Policy Security Testing and Red-Teaming Policy, Business Continuity Policy and Disaster Recovery Policy-sme Business Continuity Policy and Disaster Recovery Policy - SME, Third-Party and Supplier Security Policy-sme Third-Party and Supplier Security Policy - SME, Secure Development Policy-sme Secure Development Policy - SME, valamint Evidence Collection and Forensics Policy-sme Evidence Collection and Forensics Policy - SME szabályzataival.

Végül használja a Zenith Controls Zenith Controls útmutatót a DORA TLPT bizonyítékainak ISO 27001 kontrollokhoz, NIS2-höz, GDPR-hoz, COBIT 2019-hez és auditori elvárásokhoz való kereszthozzárendelésére.

Ha azt szeretné, hogy a következő rezilienciatesztje ne csak megállapításokat eredményezzen, használja a Clarysec-et, hogy igazolható bizonyítéklánccá alakítsa. Töltse le az eszközkészleteket, ütemezzen bizonyíték-felkészültségi értékelést, vagy kérjen bemutatót arról, hogyan rendeli a Clarysec a DORA TLPT-t az ISO 27001:2022 kontrollokhoz a tervezéstől az igazgatósági jóváhagyásig.