ITDR strategija ISO 27001, NIS2, DORA ir GDPR kontekste

Antradienį 3:00 val. ryto Sarah, FinScale vyriausioji informacijos saugumo pareigūnė (CISO), pabudo nuo tokio įspėjimo, kurio šiuolaikiniai saugumo vadovai vis dažniau baiminasi. Vyresniojo kūrėjo aktyvi sesija, vos prieš kelias valandas autentifikuota naudojant MFA, buvo naudojama iš neįprasto šaltinio gamybinių duomenų bazių schemoms inventorizuoti.

Nebuvo jokio kenkimo programinės įrangos švyturio. Jokio išpirkos reikalaujančios programinės įrangos pranešimo. Jokio ugniasienės išnaudojimo. Tik tapatybė.

SOC aptiko veiklą, tačiau reagavimas buvo chaotiškas. Ar tai buvo MFA apėjimas, pavogtas sesijos žetonas, ar paties tapatybės teikėjo kompromitavimas? Kas turėjo įgaliojimus nutraukti aktyvią sesiją? Ar pakako atšaukti slaptažodį, ar komandai reikėjo anuliuoti atnaujinimo žetonus, rotuoti API prisijungimo duomenis ir peržiūrėti OAuth suteiktas teises? Kol veikla buvo suvaldyta, užpuolikas buvo aktyvus 47 minutes.

Kitą rytą saugumo incidentas tapo valdysenos problema. Valdyba norėjo paprasto paaiškinimo, ar FinScale kibernetinė higiena buvo nepakankama pagal NIS2. Atitikties komanda norėjo sužinoti, ar įvykis galėtų būti klasifikuojamas kaip reikšmingas su IRT susijęs incidentas pagal DORA. Teisės funkcijai reikėjo pagrįsto atsakymo, ar pagal GDPR Article 32 buvo pasiekti asmens duomenys ir ar reikalingas asmens duomenų saugumo pažeidimo vertinimas. Išorės auditorius klausė, ar ISO/IEC 27001:2022 kontrolės priemonės veikė veiksmingai, o ne tik buvo aprašytos politikose.

Sarah problema nebuvo priemonių trūkumas. FinScale turėjo tapatybės teikėją, MFA, SIEM, galinių įrenginių kontrolės priemones, debesijos žurnalus ir reagavimo į incidentus procesą. Problema buvo ta, kad tapatybių valdymas, audito žurnalavimas, stebėsena, reagavimas į incidentus, privatumo vertinimas ir įrodymų tvarkymas veikė atskiruose silosuose.

Tai ir yra 2026 m. tapatybės grėsmių aptikimo ir reagavimo problema. ITDR nebėra vien saugumo operacijų pajėgumas. Tai kelių atitikties sričių įrodymų variklis ISO/IEC 27001:2022, NIS2, DORA ir GDPR Article 32 reikalavimams.

Clarysec Zenith Blueprint: Auditoriaus 30 žingsnių veiksmų planas Zenith Blueprint, politikų rinkinys ir Zenith Controls: kryžminės atitikties vadovas Zenith Controls padeda organizacijoms tapatybės atakas iš chaotiškų tyrimų paversti pakartojamais, audituojamais kontrolės procesais.

Kodėl tapatybės grėsmių aptikimas ir reagavimas dabar yra valdybos lygmens klausimas

Tapatybės atakos veikia todėl, kad jos piktnaudžiauja teisėtais prieigos keliais. Užpuolikas, pavogęs sesijos žetoną, užregistravęs kenkėjišką OAuth taikomąją programą, kompromitavęs paslaugos paskyrą arba per MFA patvirtinimo pranešimų nuovargį įtikinęs naudotoją patvirtinti užklausą, sistemoms, kurios tik tikrina, ar autentifikavimas buvo sėkmingas, gali atrodyti kaip teisėtas naudotojas.

Dėl to ITDR skiriasi nuo tradicinės perimetro gynybos. Brandži programa turi gebėti atsakyti į šiuos klausimus:

• Kokios žmonių, paslaugų, tiekėjų ir taikomųjų programų tapatybės egzistuoja?
• Kurios tapatybės yra privilegijuotos, neaktyvios, bendros arba federuotos su išorės sistemomis?
• Kurie autentifikavimo įvykiai yra įprasti, rizikingi arba neįmanomi?
• Kurios OAuth suteiktos teisės, SaaS žetonai ir API prisijungimo duomenys gali pasiekti jautrius duomenis?
• Kurie įspėjimai inicijuoja incidentų klasifikavimą, įrodymų išsaugojimą ir reguliacinių sprendimų priėmimą?
• Kurios kontrolės priemonės įrodo, kad prieiga prie asmens duomenų apsaugoma tinkamomis techninėmis ir organizacinėmis priemonėmis?

NIS2 tai paverčia valdysenos klausimu. Article 20 reikalauja, kad esminių ir svarbių subjektų valdymo organai patvirtintų kibernetinio saugumo rizikos valdymo priemones, prižiūrėtų jų įgyvendinimą ir gautų mokymus. Article 21 reikalauja tinkamų ir proporcingų techninių, operacinių ir organizacinių priemonių, įskaitant rizikos analizę, incidentų valdymą, veiklos tęstinumą, tiekimo grandinės saugumą, kontrolės priemonių veiksmingumo vertinimą, kibernetinę higieną, mokymus, prieigos kontrolę, turto valdymą ir daugiaveiksnį arba tęstinį autentifikavimą, kai tai tinkama.

DORA panašų spaudimą daro finansų subjektams. Jis reikalauja dokumentuotos IRT rizikos valdymo sistemos, valdymo organo atsakomybės, aptikimo mechanizmų, incidentų valdymo, klasifikavimo, ataskaitų teikimo, atsparumo testavimo ir trečiųjų šalių IRT rizikos valdymo. DORA taikomas nuo 2025 m. sausio 17 d. Finansų subjektams, kurie taip pat identifikuoti pagal NIS2, DORA veikia kaip sektoriui skirtas taisyklių rinkinys persidengiantiems IRT rizikos ir incidentų įpareigojimams.

GDPR prideda privatumo atskaitomybės sluoksnį. Article 5 reikalauja vientisumo, konfidencialumo ir atskaitomybės. Article 4 plačiai apibrėžia asmens duomenų saugumo pažeidimą, įskaitant neteisėtą prieigą prie asmens duomenų. Article 32 reikalauja tinkamų techninių ir organizacinių priemonių, užtikrinančių riziką atitinkantį saugumo lygį. Tapatybės incidentų atveju žurnalai, prieigos kontrolės priemonės, autentifikavimo įrašai ir incidentų įrodymai tampa esminiai pagrindžiant, ar asmens duomenys buvo apsaugoti.

ISO/IEC 27001:2022 yra valdymo sistema, galinti sujungti šiuos įpareigojimus. 4 skyrius reikalauja, kad organizacija suprastų savo kontekstą, suinteresuotąsias šalis ir teisinius, reguliacinius bei sutartinius reikalavimus. 6 skyrius reikalauja rizikos vertinimo, rizikos tvarkymo, rizikos savininko patvirtinimo ir saugomų įrodymų. A priedas apima tapatybių valdymo, saugaus autentifikavimo, audito žurnalavimo, stebėsenos, incidentų valdymo, įrodymų rinkimo, tiekėjų santykių, debesijos paslaugų ir privatumo apsaugos kontrolės priemones.

ITDR priklauso ISVS, nes tapatybės rizika tampa audituojama tik tada, kai ji patenka į taikymo sritį, turi savininką, yra vertinama, tvarkoma, stebima ir tobulinama.

Tapatybės atakos scenarijus, kuris rūpi reguliuotojams

Įsivaizduokite debesijoje veikiantį finansinių darbo eigų teikėją, aptarnaujantį ES klientus. Jis naudoja Microsoft 365, klientų aptarnavimo SaaS platformą, debesijos infrastruktūrą, mokėjimų tvarkytoją ir kelias API pagrindu veikiančias integracijas. Vyresnysis palaikymo inžinierius gauna įtikinamą raginimą iš naujo prijungti produktyvumo taikomąją programą. OAuth sutikimo ekrane prašoma skaitymo prieigos prie pašto dėžutės ir prieigos neprisijungus. Inžinierius tai patvirtina.

Per kelias minutes užpuolikas naudoja žetoną klientų identifikatoriams ir palaikymo priedams ieškoti. Jis inventorizuoja grupių narystes ir bando pasiekti administravimo portalą. MFA buvo įjungtas, tačiau užpuolikui slaptažodžio daugiau nereikia, nes žetonas suteikia ilgalaikę prieigą. SOC mato neįprastą pašto dėžutės prieigą, naują OAuth taikomąją programą, nepavykusius bandymus prisijungti prie administravimo portalo ir veiklą iš neįprastos geografinės vietos.

Šis vienas scenarijus apima kelias kontrolės sritis:

• Tapatybės gyvavimo ciklą, nes naudotojo vaidmuo ir leidimai lemia poveikio mastą.
• Saugų autentifikavimą, nes vien MFA neužkirto kelio piktnaudžiavimui žetonu.
• Audito žurnalavimą ir stebėseną, nes aptikimas priklauso nuo tapatybės teikėjo, SaaS ir taikomųjų programų žurnalų.
• Reagavimą į incidentus, nes prisijungimo duomenys, sesijos, žetonai ir OAuth suteiktos teisės turi būti greitai atšaukti.
• Įrodymų rinkimą, nes gali prireikti vertinti asmens duomenų atskleidimą ir teikti pranešimus reguliuotojui.
• Tiekėjų ir debesijos valdyseną, nes SaaS žurnalai ir audito API yra įrodymų grandinės dalis.
• Privatumo apsaugą, nes prieiga prie asmens duomenų turi būti vertinama pagal GDPR.

Geresnis klausimas nėra „Kuri priemonė nesuveikė?“ Geresnis klausimas — ar organizacija turėjo suprojektuotą, ištestuotą ir audituojamą ITDR kontrolės priemonių grandinę.

ISO 27001:2022 kontrolės priemonių grandinė, kuri užtikrina veiksmingą ITDR

Veiksmingiausios ITDR programos sujungia prevencines, aptinkamąsias, korekcines ir įrodymų kontrolės priemones.

Zenith Controls ISO/IEC 27001:2022 kontrolės priemonė 5.16 Tapatybių valdymas traktuojama kaip prevencinė kontrolės priemonė, palaikanti konfidencialumą, vientisumą ir prieinamumą. Ji tiesiogiai siejasi su 5.15 Prieigos kontrolė, 5.17 Autentifikavimo informacija, 5.18 Prieigos teisės, 5.19 Informacijos saugumas tiekėjų santykiuose, 5.36 Atitiktis informacijos saugumo politikoms, taisyklėms ir standartams ir 8.2 Privilegijuotos prieigos teisės.

Tai svarbu, nes tapatybės aptikimas neveikia, kai tapatybės valdysena silpna. Jei paslaugos paskyra nedokumentuota, tiekėjo tapatybė nevaldoma arba privilegijuotas vaidmuo neturi savininko, stebėsena gali aptikti įvykį, tačiau reaguotojai negalės jo greitai interpretuoti.

Kontrolės priemonė 8.5 Saugus autentifikavimas yra dar vienas ITDR inkaras. Zenith Controls ji siejasi su tapatybių valdymu, autentifikavimo informacija, privilegijuotos prieigos teisėmis, informacijos prieigos apribojimu, stebėsenos veiklomis, incidentų valdymu ir PII privatumo apsauga. Autentifikavimas nesibaigia prisijungimo metu. Sesijų valdymas, žetonų tvarkymas, prisijungimo duomenų apsauga ir atsekamumas yra tos pačios įrodymų istorijos dalis.

Kontrolės priemonė 8.16 Stebėsenos veiklos yra jungtis tarp žurnalų rinkimo ir sprendimų priėmimo. Ji priklauso nuo 8.15 Registravimas audito žurnale ir palaiko 5.25 Informacijos saugumo įvykių vertinimą ir sprendimą dėl jų, 5.26 Reagavimą į informacijos saugumo incidentus ir platesnį incidentų valdymą. ITDR kontekste 8.16 yra vieta, kur įtartina tapatybės elgsena tampa pirminės analizės įvykiu, paskelbtu incidentu arba dokumentuotu klaidingai teigiamu atveju.

Lentelė nėra teorinis susiejimas. Tai praktinė įrodymų grandinė, kurios po tapatybės incidento tikėsis auditorius, valdybos narys arba reguliuotojas.

Ką prideda Clarysec politikos: savininkystė, aktyvikliai ir įrodymų taisyklės

Tapatybės priemonės automatiškai nesukuria atskaitomybės. Krizės metu reaguotojams reikia įgaliojimų atšaukti sesijas, išjungti paskyras, eksportuoti žurnalus, išsaugoti įrodymus ir priimti eskalavimo sprendimus. Auditoriai turi matyti, kad šie veiksmai nebuvo improvizuoti.

Clarysec politikų rinkinys suteikia tokį veiklos modelį.

Iš įmonės Naudotojų paskyrų ir privilegijų valdymo politikos Naudotojų paskyrų ir privilegijų valdymo politika, valdysenos reikalavimų 5.9 punktas nustato:

Organizacija turi tvarkyti išsamią visų aktyvių ir neaktyvių prisijungimo duomenų, privilegijuotųjų paskyrų ir sisteminio lygmens paslaugų paskyrų apskaitą. Ši apskaita turi būti nuolat atnaujinama ir peržiūrima kas ketvirtį.

Tai tapatybių inventorių paverčia aiškiu kontrolės įpareigojimu. Tai ypač svarbu, nes paslaugų paskyros, API raktai ir neaktyvūs prisijungimo duomenys yra dažnos ITDR aklosios zonos.

Ta pati politika valdysenos reikalavimų 5.8 punkte nustato:

Visos administracinės veiklos ir privilegijuotųjų paskyrų veiksmai turi būti registruojami klastojimą atskleidžiančiu būdu ir stebimi dėl anomalijų arba politikos pažeidimų.

Šis punktas susieja privilegijuotos prieigos valdymą su aptikimu. Privilegijuotas veiksmas nėra vien leidžiamas arba draudžiamas. Jis turi būti stebimas dėl elgsenos, kuri neatitinka naudotojo, vaidmens, šaltinio, laiko ar verslo proceso.

Mažesnėms organizacijoms Naudotojų paskyrų ir privilegijų valdymo politika - MVĮ Naudotojų paskyrų ir privilegijų valdymo politika - MVĮ įgyvendinimo ir atitikties 8.1.1 punkte pateikia glaustą lūkestį:

IT vadovas turi reguliariai peržiūrėti sistemų žurnalus dėl neteisėtos prieigos bandymų, prisijungimo anomalijų arba nepatvirtintų privilegijų pakeitimų.

Čia prasideda daugelis MVĮ ITDR programų. Tam nereikia didelio SOC. Tam reikia įvardytos savininkystės ir reguliarios tinkamų tapatybės signalų peržiūros.

Žurnalų tvarkymo politika suteikia įrodymų pagrindą. Žurnalų tvarkymo ir stebėsenos politika - MVĮ Žurnalų tvarkymo ir stebėsenos politika - MVĮ valdysenos reikalavimų 5.4.2 punkte nustato:

Autentifikavimo žurnalai: sėkmingi ir nesėkmingi prisijungimo bandymai, sesijos trukmė, MFA naudojimas

Šie laukai nėra neprivalomi. Jie padeda įrodyti, ar įtartinas įvykis apėmė sėkmingą autentifikavimą, pasikartojančias nesėkmes, MFA naudojimą, sesijos tęstinumą arba neįprastą trukmę.

Įmonės Žurnalų tvarkymo ir stebėsenos politika Žurnalų tvarkymo ir stebėsenos politika politikos įgyvendinimo reikalavimų 6.1.1 punkte išplečia privalomą žurnalų apimtį:

Visos į taikymo sritį patenkančios sistemos turi generuoti žurnalus, fiksuojančius: 6.1.1.1 Naudotojų autentifikavimo ir prieigos bandymus 6.1.1.2 Privilegijuotųjų naudotojų veiklas 6.1.1.3 Konfigūracijos pakeitimus 6.1.1.4 Nesėkmingus prieigos bandymus arba sistemos įvykius 6.1.1.5 Kenkimo programinės įrangos aptikimus ir saugumo įspėjimus 6.1.1.6 Išorinę komunikaciją ir ugniasienės taisyklių aktyviklius

Konfigūracijos pakeitimai yra ypač svarbūs tapatybės atakose. Užpuolikai dažnai prideda OAuth suteiktas teises, sukuria persiuntimo taisykles, registruoja įrenginius, keičia MFA metodus arba sukuria avarinius prieigos kelius.

Tada reagavimo į incidentus politika suteikia reaguotojams įgaliojimus. Įmonės Reagavimo į incidentus politika Reagavimo į incidentus politika politikos įgyvendinimo reikalavimų 6.2.1 punkte nustato:

SOC turi nedelsdamas izoliuoti paveiktas sistemas, atšaukti kompromituotus prisijungimo duomenis arba blokuoti kenkėjišką srautą naudodamas ugniasienės arba galinių įrenginių saugumo priemones.

MVĮ Reagavimo į incidentus politika - MVĮ Reagavimo į incidentus politika - MVĮ vaidmenų ir atsakomybių 4.2.2 punkte nustato:

Įgyvendina suvaldymo ir atkūrimo veiksmus, pavyzdžiui, išjungdamas prieigą arba atkurdamas atsargines kopijas.

ITDR kontekste slaptažodžio atšaukimo nepakanka. Atkūrimo instrukcijose turi būti paskyrų išjungimas, sesijų atšaukimas, OAuth suteiktų teisių anuliavimas, paslapčių rotacija, MFA metodų nustatymas iš naujo ir deleguotų leidimų peržiūra.

Įrodymų tvarkymas yra skirtumas tarp reagavimo ir gebėjimo įrodyti. Įmonės Įrodymų rinkimo ir kriminalistikos politika Įrodymų rinkimo ir kriminalistikos politika valdysenos reikalavimų 5.5 punkte nustato:

Visi surinkti įrodymai turi būti unikaliai identifikuoti, paženklinti ir saugomi saugioje saugykloje, kurioje užtikrinama: 5.5.1 Vientisumo patikra, pavyzdžiui, SHA-256 maišos reikšmės 5.5.2 Prieigos žurnalai su laiko žymomis 5.5.3 Įrodymų saugojimo ir perdavimo grandinės įrašai, pasirašyti kiekvieno atsakingo saugotojo

MVĮ Įrodymų rinkimo ir kriminalistikos politika - MVĮ Įrodymų rinkimo ir kriminalistikos politika - MVĮ politikos įgyvendinimo reikalavimų 6.1.1 punkte nustato:

Visada turi būti sukurta kriminalistinė kopija arba eksportas; pirminiai įrodymai niekada negali būti tiesiogiai redaguojami.

FinScale scenarijuje tai reiškia, kad SOC eksportuoja tapatybės teikėjo žurnalus, SaaS audito žurnalus, pašto dėžutės prieigos įrašus, OAuth sutikimo įrašus, sesijų atšaukimo įrašus ir SIEM įspėjimus į įrodymų saugyklą su vientisumo apsauga ir įrodymų saugojimo grandine.

ITDR veiksmų plano kūrimas su Zenith Blueprint

Zenith Blueprint kontrolės priemonių grandinę paverčia įgyvendinimo žingsniais.

Kontrolės priemonių veikimo etape, 19 žingsnyje „Technologinės kontrolės priemonės I“, Blueprint aiškiai kalba apie autentifikavimą:

Kur įmanoma, turi būti vengiama autentifikavimo vien slaptažodžiu, ypač administracinėms paskyroms, debesijos konsolėms, nuotolinės prieigos priemonėms ir bet kuriai sistemai, pasiekiamai iš interneto. MFA, naudojant antrąjį veiksnį, pavyzdžiui, aparatinį raktą, mobiliąją programėlę arba biometrinius duomenis, dabar yra bazinis reikalavimas, o ne prabanga. Jis mažina prisijungimo duomenų vagystės, fišingo ir grubios jėgos atakų riziką.

Tas pats žingsnis apima daugiau nei slaptažodžius. Jis reikalauja saugaus autentifikavimo duomenų saugojimo ir perdavimo, saugaus API žetonų, sesijų ID ir OAuth prisijungimo duomenų tvarkymo, paslapčių valdymo mašinų tarpusavio autentifikavimui, žetonų rotacijos, sesijos trukmės kontrolės, saugių slapukų vėliavėlių ir autentifikavimo žurnalų peržiūros.

22 žingsnis „Organizacinės kontrolės priemonės“ formalizuoja prieigos gyvavimo ciklą. Jis padeda komandoms integruoti prieigos suteikimą ir prieigos panaikinimą su HR, atlikti dokumentuotas ketvirtines prieigos peržiūras, apibrėžti tapatybių tipus, pavyzdžiui, individualias, bendras ir paslaugų paskyras, taikyti MFA privilegijuotoms paskyroms, šalinti neaktyvias paskyras ir periodiškai keisti paslaugų prisijungimo duomenis.

19 žingsnis taip pat pateikia žurnalų tvarkymo gerinimo kelią: perduoti kritinius žurnalus į SIEM arba žurnalų surinkimo priemonę, patvirtinti saugojimo terminus, atsekti neseną įvykį naudojant žurnalus, dokumentuoti žurnalų vientisumo funkcijas ir patvirtinti įspėjimus apie nesėkmingus prisijungimus arba privilegijų pakėlimus. Laiko sinchronizavimas svarbus, nes incidento rekonstrukcija žlunga, kai tapatybės teikėjo, SaaS, galinio įrenginio ir debesijos žurnalai nesutaria dėl laiko žymų.

23 žingsnis „Organizacinės kontrolės priemonės nuo 5.19 iki 5.37“ patvirtina incidentų valdymo pajėgumus. Jis reikalauja aktualaus reagavimo į incidentus plano, apibrėžtų praneštinų įvykių, stalo pratybų, dokumentuotų sprendimų, komunikacijos įrašų, įgytos patirties ir kriminalistinių įrodymų išsaugojimo, pavyzdžiui, žurnalų momentinių kopijų, atsarginių kopijų ir saugaus izoliavimo.

Pragmatiška Clarysec ITDR seka atrodo taip:

1. Apibrėžkite tapatybių tipus ir savininkus.
2. Apsaugokite autentifikavimą, žetonus ir sesijas.
3. Rinkite autentifikavimo, privilegijų ir SaaS žurnalus.
4. Stebėkite rizikingą elgseną.
5. Apibrėžkite sprendimų taisykles nuo įvykio iki incidento.
6. Išsaugokite įrodymus.
7. Praneškite, atkurkite ir tobulinkite.

Vienos savaitės ITDR įrodymų paketas

Sutelktas „tapatybės incidento įrodymų paketas“ yra vienas greičiausių būdų atskleisti spragas. Pasirinkite vieną didelės rizikos scenarijų, pavyzdžiui: „Privilegijuotas SaaS naudotojas suteikia sutikimą neautorizuotai OAuth taikomajai programai, o žetonas naudojamas klientų duomenims pasiekti.“

Tada per vieną savaitę sukurkite įrodymų paketą.

Įtraukite bent vieną faktinį pėdsaką. Paimkite nepavojingą neseną prisijungimo anomaliją ir parodykite, kaip komanda pereina nuo įspėjimo prie naudotojo tapatybės, įrenginio, šaltinio IP, MFA metodo, sesijos trukmės, pasiektų SaaS išteklių, paliestų duomenų ir suvaldymo sprendimo. Jei organizacija negali atkurti šios grandinės stalo pratybose, realaus incidento metu jai bus sunku.

Rezultatas tampa pakartotinai naudojamais įrodymais ISO/IEC 27001:2022 vidaus auditams, DORA IRT incidentų proceso testavimui, NIS2 kibernetinės higienos priežiūrai ir GDPR atskaitomybei.

ITDR susiejimas su NIS2, DORA ir GDPR Article 32

Vieningo ITDR modelio stiprybė yra ta, kad tie patys įrodymai patenkina kelis įpareigojimus, kartu išlaikant kiekvienos sistemos terminiją.

NIS2 Article 21 tikisi rizika grindžiamų, proporcingų techninių, operacinių ir organizacinių priemonių. ITDR kontekste tai reiškia prieigos kontrolę, turto valdymą, kibernetinę higieną, mokymus, incidentų valdymą, kontrolės priemonių veiksmingumo vertinimą ir MFA arba tęstinį autentifikavimą, kai tai tinkama. Article 23 nustato etapais vykdomą pranešimą apie reikšmingus incidentus, įskaitant ankstyvąjį įspėjimą per 24 valandas, pranešimą apie incidentą per 72 valandas ir galutinę ataskaitą per vieną mėnesį.

DORA Articles 8 to 14 reikalauja identifikuoti IRT turtą ir priklausomybes, užtikrinti apsaugą ir prevenciją, aptikimo mechanizmus, tęstinumą ir atkūrimą, mokymąsi ir komunikaciją. Articles 17 to 19 reikalauja incidentų valdymo, pagrindinės priežasties nustatymo, ankstyvojo įspėjimo indikatorių, klasifikavimo pagal sunkumą ir paslaugos kritiškumą, eskalavimo, valdymo organo informavimo, pranešimo kompetentingai institucijai ir klientų informavimo, kai paveikiami finansiniai interesai.

GDPR reikalauja tinkamų techninių ir organizacinių priemonių bei įrodomos atskaitomybės. Tapatybės atakų atveju GDPR klausimai apima tai, ar įvyko neteisėta prieiga, kokie asmens duomenys buvo susiję, ar apsaugos priemonės veikė ir ar pasiekiamos pranešimo apie pažeidimą ribos.

Fintech įmonėms NIS2 ir DORA santykis yra svarbus. DORA laikomas sektoriui skirtu karkasu į taikymo sritį patenkantiems finansų subjektams, kai persidengia IRT rizikos ir pranešimo apie incidentus įpareigojimai. Praktikoje organizacijos turėtų sukurti vieną ITDR įrodymų modelį ir susieti pranešimo sprendimus su taikytinu teisiniu keliu.

SaaS, debesijos, valdomų paslaugų, valdomo saugumo ir skaitmeninių platformų organizacijoms NIS2 taikymo sritis turi būti patikrinta atidžiai. NIS2 apima daug Annex I ir Annex II sektorių, įskaitant skaitmeninę infrastruktūrą, debesijos paslaugų teikėjus, duomenų centrus, patikimumo užtikrinimo paslaugas, DNS, TLD registrus, valdomų paslaugų teikėjus, valdomo saugumo paslaugų teikėjus, internetines prekyvietes, paieškos sistemas ir socialinių tinklų platformas. Todėl ISO/IEC 27001:2022 4 skyriaus taikymo srities apibrėžimas ir suinteresuotųjų šalių analizė nėra formalumas. Jie apibrėžia, kokius įpareigojimus turi apimti ISVS.

Tiekėjų ir SaaS tapatybės rizika

Tapatybės incidentai dažnai priklauso nuo tiekėjų įrodymų. Ar SaaS teikėjas gali eksportuoti audito žurnalus? Ar jis rodo OAuth sutikimo įvykius? Ar palaiko saugias prieigos kontrolės priemones, žurnalavimą ir duomenų apsaugą? Ar incidentų pagalba, duomenų vieta, subrangos naudojimas, prieigos teisės ir pasitraukimo nuostatos yra sutarti sutartyje?

Clarysec Debesijos paslaugų naudojimo politika - MVĮ Debesijos paslaugų naudojimo politika - MVĮ valdysenos reikalavimų 5.2.4 punkte apima tiesioginį reikalavimą:

Paslauga suteikia saugias prieigos kontrolės priemones, žurnalavimo ir duomenų apsaugos galimybes

Šis paprastas sakinys yra pirkimų kontrolės priemonė. Jei SaaS platforma negali pateikti tapatybės žurnalų, reikalingų reagavimui į incidentus, ji sukuria atitikties riziką.

DORA tai aiškiai įtvirtina per trečiųjų šalių IRT rizikos įpareigojimus. Finansų subjektai išlieka atsakingi už atitiktį, turi tvarkyti IRT paslaugų sutarčių registrus, atskirti kritines arba svarbias funkcijas, atlikti deramą rūpestingumą, vertinti koncentracijos riziką, įtraukti audito ir prieigos teises, apibrėžti incidentų pagalbą ir užtikrinti pasitraukimo strategijas.

Zenith Controls ISO/IEC 27001:2022 kontrolės priemonė 8.16 Stebėsenos veiklos siejasi su 5.22 Tiekėjų paslaugų stebėsena, peržiūra ir pakeitimų valdymu. Tai atspindi operacinę realybę. Tapatybės teikėjo įspėjimai, SaaS audito žurnalai, debesijos administratoriaus veikla ir valdomų paslaugų teikėjo paskyros yra ITDR paviršiaus dalis.

Kaip auditoriai vertins ITDR

Stipri ITDR programa turi atlaikyti kelias audito perspektyvas. Kiekviena auditorija užduoda skirtingus klausimus, tačiau įrodymai turi būti gaunami iš tos pačios kontrolės sistemos.

ISO/IEC 27001:2022 auditorius klaus, ar tapatybės grėsmės įtrauktos į rizikos vertinimą, ar rizikos savininkai patvirtino tvarkymą, ar Taikytinumo pareiškimas apima aktualias A priedo kontrolės priemones, ar politikos įgyvendintos ir ar įrodymai rodo, kad kontrolės priemonės veikia. Jis gali atrinkti privilegijuotą paskyrą ir atsekti patvirtinimą, MFA nustatymą, žurnalo veiklą, prieigos peržiūrą ir prieigos teisių panaikinimą.

NIST CSF 2.0 vertintojas nagrinės GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND ir RECOVER rezultatus. ITDR natūraliai dera prie profilio, kurio taikymo sritis yra tapatybės kompromitavimas, piktnaudžiavimas SaaS žetonais arba netinkamas privilegijuotos prieigos naudojimas.

DORA tikrintojas ieškos valdymo organo atskaitomybės, IRT palaikomų verslo funkcijų, aptikimo mechanizmų, incidentų klasifikavimo kriterijų, eskalavimo, klientų komunikacijos taisyklių, pagrindinės priežasties analizės ir trečiųjų šalių IRT priklausomybių.

GDPR vertintojas klaus, ar organizacija gali įrodyti tinkamą asmens duomenų saugumą. Jis nagrinės prieigos apribojimą, neteisėtos prieigos aptikimą, žurnalus, rodančius, kokie duomenys galėjo būti pasiekti, pažeidimo vertinimą ir atskaitomybės įrodymus.

COBIT 2019 arba ISACA tipo auditorius nagrinės valdyseną, kontrolės tikslus, savininkystę, veiklos stebėseną ir užtikrinimą.

Zenith Controls čia naudinga, nes veikia kaip kryžminės atitikties vadovas. Ji nesukuria atskirų „Zenith kontrolių“. Ji susieja ISO/IEC 27001:2022 kontrolės sritis su susijusiomis ISO kontrolės priemonėmis, kitais standartais, audito lūkesčiais ir įgyvendinimo sąsajomis.

Rodikliai, įrodantys, kad ITDR veikia

Valdyboms ir auditoriams nereikia neapdoroto SIEM triukšmo. Jiems reikia įrodymų, kad tapatybės kontrolės priemonės veikia ir tobulėja. Naudingi ITDR rodikliai apima:

• Privilegijuotųjų paskyrų su fišingui atspariu MFA procentinę dalį.
• Neaktyvių paskyrų, senesnių nei politikos slenkstis, skaičių.
• Paslaugų paskyrų be savininko arba rotacijos datos skaičių.
• Kritinių SaaS platformų, siunčiančių autentifikavimo žurnalus į SIEM, procentinę dalį.
• Vidutinį įtartinos tapatybės veiklos aptikimo laiką.
• Vidutinį kompromituotų sesijų ir žetonų atšaukimo laiką.
• Patvirtintų, atmestų arba pašalintų OAuth taikomųjų programų skaičių.
• Tapatybės incidentų su visais įrodymų paketais procentinę dalį.
• Pradelstų prieigos peržiūros išvadų skaičių.
• Tiekėjų platformų, neturinčių privalomų tapatybės žurnalų, skaičių.

Šie rodikliai turi būti įtraukiami į ISO/IEC 27001:2022 vadovybės peržiūrą, NIS2 valdysenos priežiūrą, DORA IRT rizikos ataskaitas ir GDPR atskaitomybės aptarimus.

Dažnos ITDR audito išvados ir jų taisymas

Clarysec dažnai mato penkias pasikartojančias išvadas.

Pirma, organizacijos įjungia MFA, bet nestebi MFA elgsenos. Tai taisoma žurnaluose fiksuojant MFA metodo pakeitimus, nesėkmingus patvirtinimus, neįmanomas keliones, naujų įrenginių registravimą ir pasikartojančius patvirtinimo pranešimų bandymus.

Antra, paslaugų paskyros neįtraukiamos į tapatybės valdyseną. Tai taisoma inventorizuojant sistemos lygmens paskyras, priskiriant savininkus, rotuojant paslaptis, šalinant įterptus prisijungimo duomenis ir stebint anomalią API elgseną.

Trečia, SaaS sutikimai nevaldomi. Tai taisoma ribojant naudotojų sutikimus, peržiūrint OAuth taikomąsias programas, stebint naujas suteiktas teises, dokumentuojant patvirtintas integracijas ir šalinant nenaudojamas programas.

Ketvirta, tyrimo metu pakeičiami įrodymai. Tai taisoma laikantis Įrodymų rinkimo ir kriminalistikos politikos taisyklės: kurti kriminalistines kopijas arba eksportus, niekada tiesiogiai neredaguoti originalų ir saugoti įrodymus su maišos reikšmėmis bei įrodymų saugojimo grandinės įrašais.

Penkta, incidentų klasifikavimas per lėtas. Tai taisoma iš anksto apibrėžiant tapatybės įvykių slenksčius, įskaitant privilegijuotos paskyros kompromitavimą, prieigą prie asmens duomenų, klientams poveikį darantį piktnaudžiavimą SaaS žetonu, kritinės paslaugos sutrikimą ir tiekėjo tapatybės kompromitavimą.

Kiekviena išvada turi kontrolės priemonių, politikos ir įrodymų atsaką. Tai praktinė vieningos ITDR programos vertė: ji apibrėžia, kas turi turėti savininką, būti stebima, testuojama, pagrindžiama įrodymais ir tobulinama.

Paverskite tapatybės riziką auditui tinkamais įrodymais

Jei kitas tapatybės incidentas įvyktų rytoj, ar galėtumėte įrodyti, kas ką pasiekė, kaip autentifikavosi, kuris žetonas arba sesija buvo naudojama, kokie duomenys buvo paliesti, kas priėmė reguliacinio klasifikavimo sprendimą ir kokie korekciniai veiksmai buvo užbaigti?

Jei atsakymas neaiškus, pradėkite nuo sutelkto ITDR pasirengimo sprinto.

Naudokite Zenith Blueprint, kad struktūruotumėte įgyvendinimo kelią per autentifikavimą, prieigos gyvavimo ciklą, žurnalavimą, stebėseną, reagavimą į incidentus ir įrodymų tvarkymą. Naudokite Clarysec prieigos kontrolės, žurnalų tvarkymo, debesijos, reagavimo į incidentus ir kriminalistikos politikas savininkystei ir reagavimo įgaliojimams priskirti. Naudokite Zenith Controls, kad susietumėte tapatybių valdymą, saugų autentifikavimą ir stebėsenos veiklas su ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST CSF 2.0 ir audito lūkesčiais.

Tikslas paprastas: padaryti tapatybės atakas aptinkamas, suvaldomas, praneštinas ir pagrindžiamas įrodymais.

Clarysec gali padėti sukurti ITDR įrodymų paketą, patikrinti jį per stalo pratybų scenarijų ir paversti išvadas rizikos tvarkymo planu, kurį supras jūsų valdyba, reguliuotojas ir auditorius. Pradėkite nuo Žurnalų tvarkymo ir stebėsenos politikos, Naudotojų paskyrų ir privilegijų valdymo politikos - MVĮ, Zenith Blueprint ir Zenith Controls peržiūros, tada suplanuokite ITDR pasirengimo vertinimą, kad tapatybės riziką paverstumėte auditui tinkamais įrodymais.