ITDR stratēģija ISO 27001, NIS2, DORA un GDPR prasību izpildei

Otrdien pulksten 3.00 naktī FinScale informācijas drošības vadītāja (CISO) Sāra pamodās no brīdinājuma, no kā mūsdienu drošības vadītāji baidās arvien biežāk. Vecākā izstrādātāja aktīvā sesija, kas tikai pirms dažām stundām bija autentificēta ar MFA, no neierasta avota tika izmantota ražošanas datubāzu shēmu uzskaitei.

Nebija ļaunatūras signāla. Nebija izspiedējprogrammatūras paziņojuma. Nebija ugunsmūra ievainojamības izmantošanas. Tikai identitāte.

Drošības operāciju centrs (SOC) darbību konstatēja, taču reaģēšana bija sadrumstalota. Vai tā bija MFA apiešana, nozagts sesijas marķieris vai paša identitātes nodrošinātāja kompromitēšana? Kam bija pilnvaras pārtraukt aktīvo sesiju? Vai pietika ar paroles atsaukšanu, vai komandai bija jāanulē atsvaidzināšanas marķieri, jārotē API autentifikācijas dati un jāpārskata OAuth piešķīrumi? Līdz darbība tika ierobežota, uzbrucējs bija bijis aktīvs 47 minūtes.

Nākamajā rītā drošības incidents kļuva par pārvaldības jautājumu. Valde vēlējās vienkāršā valodā saprast, vai FinScale kiberdrošības higiēna NIS2 izpratnē bija izgāzusies. Atbilstības komanda vēlējās noskaidrot, vai notikumu var klasificēt kā būtisku ar IKT saistītu incidentu DORA ietvaros. Juridiskajai funkcijai bija nepieciešama pamatota atbilde, vai saskaņā ar GDPR Article 32 ir notikusi piekļuve personas datiem un vai nepieciešams personas datu aizsardzības pārkāpuma izvērtējums. Ārējais auditors jautāja, vai ISO/IEC 27001:2022 kontroles pasākumi darbojas efektīvi, nevis ir tikai dokumentēti politikās.

Sāras problēma nebija rīku trūkums. FinScale bija identitātes nodrošinātājs, MFA, SIEM, galapunktu kontroles pasākumi, mākoņvides žurnāli un incidentu reaģēšanas process. Problēma bija tā, ka identitāšu pārvaldība, žurnalēšana, uzraudzība, reaģēšana uz incidentiem, privātuma izvērtēšana un pierādījumu apstrāde darbojās izolēti.

Tā ir 2026. gada identitātes apdraudējumu atklāšanas un reaģēšanas problēma. ITDR vairs nav tikai drošības operāciju spēja. Tā ir starpatbilstības pierādījumu sistēma ISO/IEC 27001:2022, NIS2, DORA un GDPR Article 32 prasību izpildei.

Clarysec Zenith Blueprint: revidenta 30 soļu ceļvedis Zenith Blueprint, politiku komplekts un Zenith Controls: starpatbilstības ceļvedis Zenith Controls palīdz organizācijām pārvērst identitātes uzbrukumus no haotiskām izmeklēšanām atkārtojamos, auditējamos kontroles procesos.

Kāpēc identitātes apdraudējumu atklāšana un reaģēšana tagad ir valdes līmeņa jautājums

Identitātes uzbrukumi darbojas tāpēc, ka tie ļaunprātīgi izmanto leģitīmus piekļuves ceļus. Uzbrucējs, kurš nozog sesijas marķieri, reģistrē ļaunprātīgu OAuth lietojumprogrammu, kompromitē pakalpojuma kontu vai pārliecina lietotāju MFA push noguruma rezultātā, sistēmām, kas pārbauda tikai autentifikācijas sekmīgumu, var izskatīties kā derīgs lietotājs.

Tas padara ITDR atšķirīgu no tradicionālās perimetra aizsardzības. Nobriedušai programmai jāspēj atbildēt uz šādiem jautājumiem:

• Kādas cilvēku, pakalpojumu, piegādātāju un lietojumprogrammu identitātes pastāv?
• Kuras identitātes ir priviliģētas, neaktīvas, koplietotas vai ārēji federētas?
• Kuri autentifikācijas notikumi ir normāli, riskanti vai neiespējami?
• Kuri OAuth piešķīrumi, SaaS marķieri un API autentifikācijas dati var piekļūt sensitīviem datiem?
• Kuri brīdinājumi ierosina incidenta klasifikāciju, pierādījumu saglabāšanu un regulatīvu lēmumu pieņemšanu?
• Kuri kontroles pasākumi pierāda, ka piekļuve personas datiem ir aizsargāta ar atbilstošiem tehniskiem un organizatoriskiem pasākumiem?

NIS2 to padara par pārvaldības jautājumu. Article 20 prasa būtisko un svarīgo vienību vadības institūcijām apstiprināt kiberdrošības riska pārvaldības pasākumus, pārraudzīt to ieviešanu un saņemt apmācību. Article 21 prasa atbilstošus un samērīgus tehniskos, operacionālos un organizatoriskos pasākumus, tostarp risku analīzi, incidentu apstrādi, darbības nepārtrauktību, piegādes ķēdes drošību, kontroles efektivitātes izvērtēšanu, kiberdrošības higiēnu, apmācību, piekļuves kontroli, aktīvu pārvaldību un daudzfaktoru autentifikāciju vai nepārtrauktu autentifikāciju, ja tas ir piemēroti.

DORA rada līdzīgu spiedienu finanšu vienībām. Tā prasa dokumentētu IKT risku pārvaldības ietvaru, vadības institūcijas atbildību, atklāšanas mehānismus, incidentu pārvaldību, klasifikāciju, ziņošanu, noturības testēšanu un trešo pušu IKT risku pārvaldību. DORA piemēro no 2025. gada 17. janvāra. Finanšu vienībām, kas vienlaikus identificētas arī NIS2 ietvaros, DORA darbojas kā nozares specifisks noteikumu kopums pārklājošiem IKT risku un incidentu pienākumiem.

GDPR pievieno privātuma pārskatatbildības slāni. Article 5 prasa integritāti, konfidencialitāti un pārskatatbildību. Article 4 plaši definē personas datu aizsardzības pārkāpumu, tostarp nesankcionētu piekļuvi personas datiem. Article 32 prasa atbilstošus tehniskos un organizatoriskos pasākumus, lai nodrošinātu riskam atbilstošu drošības līmeni. Identitātes incidentos žurnāli, piekļuves kontroles pasākumi, autentifikācijas ieraksti un incidenta pierādījumi kļūst par pamatu tam, lai pierādītu, vai personas dati bija aizsargāti.

ISO/IEC 27001:2022 ir pārvaldības sistēma, kas spēj apvienot šos pienākumus. 4. punkts prasa organizācijai izprast tās kontekstu, ieinteresētās puses un tiesiskās, regulatīvās un līgumiskās prasības. 6. punkts prasa risku izvērtēšanu, riska apstrādi, riska īpašnieka apstiprinājumu un saglabātus pierādījumus. A pielikumā ir kontroles pasākumi identitāšu pārvaldībai, drošai autentifikācijai, žurnalēšanai, uzraudzībai, incidentu pārvaldībai, pierādījumu vākšanai, piegādātāju attiecībām, mākoņpakalpojumiem un privātuma aizsardzībai.

ITDR jāiekļauj IDPS, jo identitātes risks kļūst auditējams tikai tad, ja tam ir noteikta darbības joma, īpašnieks, izvērtējums, riska apstrāde, uzraudzība un pilnveide.

Identitātes uzbrukuma scenārijs, kas interesē regulatorus

Apsveriet mākoņvidē balstītu finanšu darbplūsmas pakalpojumu sniedzēju, kas apkalpo ES klientus. Tas izmanto Microsoft 365, klientu atbalsta SaaS platformu, mākoņinfrastruktūru, maksājumu apstrādātāju un vairākas API balstītas integrācijas. Vecākais atbalsta inženieris saņem pārliecinošu pieprasījumu atkārtoti savienot produktivitātes lietojumprogrammu. OAuth piekrišanas ekrānā tiek prasīta pastkastes lasīšanas piekļuve un bezsaistes piekļuve. Inženieris to apstiprina.

Dažu minūšu laikā uzbrucējs izmanto marķieri, lai meklētu klientu identifikatorus un atbalsta pielikumus. Viņš uzskaita grupu dalības un mēģina piekļūt administratora portālam. MFA bija iespējota, taču uzbrucējam parole vairs nav vajadzīga, jo marķieris piešķir noturīgu piekļuvi. SOC redz neparastu pastkastes piekļuvi, jaunu OAuth lietojumprogrammu, neveiksmīgus administratora portāla piekļuves mēģinājumus un darbību no neierastas ģeogrāfiskās atrašanās vietas.

Šis viens scenārijs šķērso vairākas kontroles jomas:

• Identitātes dzīves cikls, jo lietotāja loma un piekļuves tiesības nosaka ietekmes apmēru.
• Droša autentifikācija, jo MFA viena pati nenovērsa marķiera ļaunprātīgu izmantošanu.
• Žurnalēšana un uzraudzība, jo atklāšana ir atkarīga no identitātes nodrošinātāja, SaaS un lietojumprogrammu žurnāliem.
• Reaģēšana uz incidentiem, jo autentifikācijas dati, sesijas, marķieri un OAuth piešķīrumi ir ātri jāatsauc.
• Pierādījumu vākšana, jo var sekot personas datu ekspozīcija un regulatīva ziņošana.
• Piegādātāju un mākoņpakalpojumu pārvaldība, jo SaaS žurnāli un audita API ir daļa no pierādījumu ķēdes.
• Privātuma aizsardzība, jo piekļuve personas datiem ir jāizvērtē GDPR ietvaros.

Labākais jautājums nav “Kurš rīks neizdevās?”. Labākais jautājums ir, vai organizācijai bija projektēta, pārbaudīta un auditējama ITDR kontroles ķēde.

ISO 27001:2022 kontroles ķēde efektīvai ITDR

Efektīvākās ITDR programmas sasaista preventīvos, atklājošos, koriģējošos un pierādījumu nodrošināšanas kontroles pasākumus.

Zenith Controls ietvaros ISO/IEC 27001:2022 kontrole 5.16 Identitāšu pārvaldība tiek uzskatīta par preventīvu kontroles pasākumu, kas atbalsta konfidencialitāti, integritāti un pieejamību. Tā tieši sasaistās ar 5.15 Piekļuves kontrole, 5.17 Autentifikācijas informācija, 5.18 Piekļuves tiesības, 5.19 Informācijas drošība piegādātāju attiecībās, 5.36 Atbilstība informācijas drošības politikām, noteikumiem un standartiem un 8.2 Priviliģētās piekļuves tiesības.

Tas ir būtiski, jo identitātes apdraudējumu atklāšana neizdodas, ja identitātes pārvaldība ir vāja. Ja pakalpojuma konts nav dokumentēts, piegādātāja identitāte netiek pārvaldīta vai priviliģētai lomai nav īpašnieka, uzraudzība var atklāt notikumu, taču reaģētāji nevar to ātri interpretēt.

Kontrole 8.5 Droša autentifikācija ir vēl viens ITDR balsts. Zenith Controls ietvaros tā sasaistās ar identitāšu pārvaldību, autentifikācijas informāciju, priviliģētās piekļuves tiesībām, informācijas piekļuves ierobežošanu, uzraudzības darbībām, incidentu pārvaldību un PII privātuma aizsardzību. Autentifikācija nebeidzas ar pieteikšanos. Sesiju pārvaldība, marķieru apstrāde, autentifikācijas datu aizsardzība un izsekojamība ir daļa no vienota pierādījumu stāsta.

Kontrole 8.16 Uzraudzības darbības ir saikne starp žurnālu vākšanu un lēmumu pieņemšanu. Tā ir atkarīga no 8.15 Žurnalēšana un atbalsta 5.25 Informācijas drošības notikumu izvērtēšana un lēmuma pieņemšana, 5.26 Reaģēšana uz informācijas drošības incidentiem un plašāku incidentu pārvaldību. ITDR kontekstā 8.16 ir vieta, kur aizdomīga identitātes uzvedība kļūst par sākotnēji izvērtētu notikumu, paziņotu incidentu vai dokumentētu kļūdaini pozitīvu gadījumu.

Tabula nav teorētiska kartēšana. Tā ir praktiska pierādījumu ķēde, ko auditors, valdes loceklis vai regulators sagaidīs pēc identitātes incidenta.

Ko pievieno Clarysec politikas: īpašumtiesības, aktivizācijas nosacījumi un pierādījumu noteikumi

Identitātes rīki automātiski nerada pārskatatbildību. Krīzes laikā reaģētājiem nepieciešamas pilnvaras atsaukt sesijas, atspējot kontus, eksportēt žurnālus, saglabāt pierādījumus un pieņemt eskalācijas lēmumus. Auditoriem jāredz, ka šīs darbības nav improvizētas.

Clarysec politiku komplekts nodrošina šādu darbības modeli.

Uzņēmuma Lietotāju kontu un privilēģiju pārvaldības politika Lietotāju kontu un privilēģiju pārvaldības politika, Pārvaldības prasības 5.9. punktā nosaka:

Organizācijai jāuztur detalizēta visu aktīvo un neaktīvo autentifikācijas datu, priviliģēto kontu un sistēmas līmeņa pakalpojumu kontu uzskaite. Šī uzskaite nepārtraukti jāatjaunina un jāpārskata reizi ceturksnī.

Tas pārvērš identitāšu uzskaiti par skaidru kontroles pienākumu. Tas ir īpaši svarīgi, jo pakalpojumu konti, API atslēgas un neaktīvi autentifikācijas dati ir biežas ITDR aklās zonas.

Tajā pašā politikā Pārvaldības prasības 5.8. punktā noteikts:

Visas administratīvās darbības un priviliģēto kontu darbības jāreģistrē žurnālos tā, lai būtu konstatējama iejaukšanās, un jāuzrauga attiecībā uz anomālijām vai politikas pārkāpumiem.

Šis punkts sasaista priviliģētās piekļuves pārvaldību ar atklāšanu. Priviliģēta darbība nav tikai atļauta vai liegta. Tā jāuzrauga, lai konstatētu uzvedību, kas neatbilst lietotājam, lomai, avotam, laikam vai biznesa procesam.

Mazākām organizācijām Lietotāju kontu un privilēģiju pārvaldības politika - SME Lietotāju kontu un privilēģiju pārvaldības politika - SME sniedz kodolīgu prasību Ievērošana un atbilstība 8.1.1. punktā:

IT vadītājam regulāri jāpārskata sistēmu žurnāli, lai konstatētu nesankcionētas piekļuves mēģinājumus, pieteikšanās anomālijas vai neapstiprinātas privilēģiju izmaiņas.

Šeit sākas daudzas SME ITDR programmas. Tam nav vajadzīgs liels SOC. Tam vajadzīgs norīkots īpašnieks un regulāra pareizo identitātes signālu pārskatīšana.

Žurnalēšanas politika nodrošina pierādījumu pamatu. Žurnālfiksēšanas un uzraudzības politika - SME Žurnālfiksēšanas un uzraudzības politika - SME Pārvaldības prasības 5.4.2. punktā nosaka:

Autentifikācijas žurnāli: sekmīgi un neveiksmīgi pieteikšanās mēģinājumi, sesijas ilgums, MFA lietojums

Šie lauki nav izvēles jautājums. Tie palīdz pierādīt, vai aizdomīgais notikums ietvēra sekmīgu autentifikāciju, atkārtotas neveiksmes, MFA izmantošanu, sesijas noturību vai neparastu ilgumu.

Uzņēmuma Žurnālfiksēšanas un uzraudzības politika Žurnālfiksēšanas un uzraudzības politika paplašina obligāto žurnālu tvērumu Politikas ieviešanas prasības 6.1.1. punktā:

Visām aptvertajām sistēmām jāģenerē žurnāli, kuros fiksē: 6.1.1.1 Lietotāju autentifikācijas un piekļuves mēģinājumus 6.1.1.2 Priviliģēto lietotāju darbības 6.1.1.3 Konfigurācijas izmaiņas 6.1.1.4 Neveiksmīgus piekļuves mēģinājumus vai sistēmas notikumus 6.1.1.5 Ļaunatūras atklāšanu un drošības brīdinājumus 6.1.1.6 Ārējo komunikāciju un ugunsmūra noteikumu aktivizēšanu

Konfigurācijas izmaiņas identitātes uzbrukumos ir īpaši svarīgas. Uzbrucēji bieži pievieno OAuth piešķīrumus, izveido pārsūtīšanas noteikumus, reģistrē ierīces, maina MFA metodes vai izveido ārkārtas piekļuves ceļus.

Pēc tam incidentu reaģēšanas politika piešķir reaģētājiem pilnvaras. Uzņēmuma Incidentu reaģēšanas politika Incidentu reaģēšanas politika Politikas ieviešanas prasības 6.2.1. punktā nosaka:

SOC nekavējoties jāizolē ietekmētās sistēmas, jāatsauc kompromitētie autentifikācijas dati vai jābloķē ļaunprātīga datplūsma, izmantojot ugunsmūra vai galapunktu drošības rīkus.

SME Incidentu reaģēšanas politika - SME Incidentu reaģēšanas politika - SME Lomas un pienākumi 4.2.2. punktā nosaka:

Īsteno ierobežošanas un atjaunošanas darbības, piemēram, atspējojot piekļuvi vai atjaunojot rezerves kopijas.

ITDR kontekstā paroles atsaukšana nav pietiekama. Reaģēšanas scenārijos jāiekļauj kontu atspējošana, sesiju atsaukšana, OAuth piešķīrumu anulēšana, noslēpumu rotācija, MFA metožu atiestatīšana un deleģēto piekļuves tiesību pārskatīšana.

Pierādījumu apstrāde ir atšķirība starp reaģēšanu un pierādīšanu. Uzņēmuma Digitālo pierādījumu iegūšanas un kriminālistikas politika Digitālo pierādījumu iegūšanas un kriminālistikas politika Pārvaldības prasības 5.5. punktā nosaka:

Visi savāktie pierādījumi ir unikāli jāidentificē, jāmarķē un jāglabā drošā repozitorijā ar: 5.5.1 Integritātes pārbaudi, piemēram, SHA-256 hešvērtībām 5.5.2 Piekļuves žurnāliem ar laikspiedoliem 5.5.3 Pierādījumu glabāšanas ķēdes ierakstiem, ko parakstījis katrs glabātājs

SME Digitālo pierādījumu iegūšanas un kriminālistikas politika - SME Digitālo pierādījumu iegūšanas un kriminālistikas politika - SME Politikas ieviešanas prasības 6.1.1. punktā nosaka:

Vienmēr jāizveido kriminālistiska kopija vai eksports; oriģinālos pierādījumus nekad nedrīkst rediģēt tieši.

FinScale scenārijā tas nozīmē, ka SOC eksportē identitātes nodrošinātāja žurnālus, SaaS audita žurnālus, pastkastes piekļuves ierakstus, OAuth piekrišanas ierakstus, sesiju atsaukšanas ierakstus un SIEM brīdinājumus pierādījumu repozitorijā ar integritātes aizsardzību un pierādījumu glabāšanas ķēdi.

ITDR ceļkartes izveide ar Zenith Blueprint

Zenith Blueprint pārvērš kontroles ķēdi ieviešanas soļos.

Fāzē “Kontroles praksē”, 19. solī “Tehnoloģiskie kontrolpasākumi I”, Blueprint par autentifikāciju izsakās tieši:

Ja iespējams, jāizvairās no autentifikācijas tikai ar paroli, īpaši administratora kontiem, mākoņvides konsolēm, attālinātās piekļuves rīkiem un jebkurai sistēmai, kas ir pieejama internetā. MFA, izmantojot otro faktoru, piemēram, aparatūras atslēgu, mobilo lietotni vai biometriju, tagad ir pamatlīmenis, nevis papildu greznība. Tā mazina autentifikācijas datu zādzības, pikšķerēšanas un brutāla spēka uzbrukumu riskus.

Tas pats solis iet tālāk par parolēm. Tas prasa drošu autentifikācijas datu glabāšanu un pārsūtīšanu, drošu API marķieru, sesijas ID un OAuth autentifikācijas datu apstrādi, noslēpumu pārvaldību mašīna–mašīna autentifikācijai, marķieru rotāciju, sesijas ilguma kontroles, drošus sīkfailu karodziņus un autentifikācijas žurnālu pārskatīšanu.

22. solis “Organizatoriskās kontroles” formalizē piekļuves dzīves ciklu. Tas palīdz komandām integrēt piekļuves piešķiršanu un atņemšanu ar HR, veikt dokumentētu ceturkšņa piekļuves tiesību pārskatīšanu, definēt identitāšu tipus, piemēram, individuālos, koplietotos un pakalpojumu kontus, piemērot MFA priviliģētajiem kontiem, likvidēt neaktīvus kontus un rotēt pakalpojumu autentifikācijas datus.

23. solis arī nodrošina žurnalēšanas pilnveides ceļu: pārsūtīt kritiskos žurnālus uz SIEM vai žurnālu savācēju, validēt glabāšanu, izsekot nesenu notikumu, izmantojot žurnālus, dokumentēt žurnālu integritātes funkcijas un apstiprināt brīdināšanu par neveiksmīgām pieteikšanās reizēm vai privilēģiju paaugstināšanu. Laika sinhronizācija ir būtiska, jo incidenta rekonstrukcija neizdodas, ja identitātes nodrošinātāja, SaaS, galapunkta un mākoņvides žurnāli neatbilst laikspiedolos.

24. solis “Organizatoriskās kontroles 5.19 līdz 5.37” validē incidentu pārvaldības spējas. Tas prasa aktuālu incidentu reaģēšanas plānu, definētus ziņojamus notikumus, galda scenārija izspēles, dokumentētus lēmumus, komunikācijas ierakstus, gūtās mācības un digitālās kriminālistikas pierādījumu saglabāšanu, piemēram, žurnālu momentuzņēmumus, rezerves kopijas un drošu izolāciju.

Pragmatiska Clarysec ITDR secība izskatās šādi:

1. Definēt identitāšu tipus un īpašniekus.
2. Nodrošināt drošu autentifikāciju, marķierus un sesijas.
3. Vākt autentifikācijas, privilēģiju un SaaS žurnālus.
4. Uzraudzīt riskantu uzvedību.
5. Definēt noteikumus pārejai no notikuma uz incidentu.
6. Saglabāt pierādījumus.
7. Ziņot, atjaunot darbību un pilnveidot.

Vienas nedēļas ITDR pierādījumu pakotne

Fokusēta “identitātes incidenta pierādījumu pakotne” ir viens no ātrākajiem veidiem, kā atklāt trūkumus. Izvēlieties vienu augsta riska scenāriju, piemēram: “Priviliģēts SaaS lietotājs piešķir piekrišanu nesankcionētai OAuth lietojumprogrammai, un marķieris tiek izmantots piekļuvei klientu datiem.”

Pēc tam vienas nedēļas laikā izveidojiet pierādījumu pakotni.

Iekļaujiet vismaz vienu faktisku izsekošanu. Paņemiet nekaitīgu nesenu pieteikšanās anomāliju un parādiet, kā komanda no brīdinājuma nonāk līdz lietotāja identitātei, ierīcei, avota IP, MFA metodei, sesijas ilgumam, piekļūtajiem SaaS resursiem, skartajiem datiem un ierobežošanas lēmumam. Ja organizācija nespēj rekonstruēt šo ķēdi galda scenārija izspēlē, tai būs grūtības reāla incidenta laikā.

Rezultāts kļūst par atkārtoti izmantojamiem pierādījumiem ISO/IEC 27001:2022 iekšējiem auditiem, DORA IKT incidentu procesa testēšanai, NIS2 kiberdrošības higiēnas pārraudzībai un GDPR pārskatatbildībai.

ITDR kartēšana uz NIS2, DORA un GDPR Article 32

Vienota ITDR modeļa spēks ir tajā, ka vieni un tie paši pierādījumi apmierina vairākus pienākumus, vienlaikus respektējot katra ietvara terminoloģiju.

NIS2 Article 21 sagaida uz risku balstītus, samērīgus tehniskos, operacionālos un organizatoriskos pasākumus. ITDR kontekstā tas nozīmē piekļuves kontroli, aktīvu pārvaldību, kiberdrošības higiēnu, apmācību, incidentu apstrādi, kontroles efektivitātes izvērtēšanu un MFA vai nepārtrauktu autentifikāciju, ja tas ir piemēroti. Article 23 ievieš pakāpenisku ziņošanu par būtiskiem incidentiem, tostarp agrīnu brīdinājumu 24 stundu laikā, incidenta paziņojumu 72 stundu laikā un galīgo ziņojumu viena mēneša laikā.

DORA Articles 8 to 14 prasa identificēt IKT aktīvus un atkarības, aizsardzību un prevenciju, atklāšanas mehānismus, nepārtrauktību un atjaunošanu, mācīšanos un komunikāciju. Articles 17 to 19 prasa incidentu pārvaldību, pamatcēloņa identificēšanu, agrīnā brīdinājuma indikatorus, klasifikāciju pēc smaguma pakāpes un pakalpojuma kritiskuma, eskalāciju, vadības institūcijas informēšanu, kompetentās iestādes informēšanu un klientu informēšanu, ja skartas finanšu intereses.

GDPR prasa atbilstošus tehniskos un organizatoriskos pasākumus un pierādāmu pārskatatbildību. Identitātes uzbrukumos GDPR jautājumi ietver to, vai notikusi nesankcionēta piekļuve, kādi personas dati bija iesaistīti, vai drošības pasākumi darbojās un vai ir sasniegti paziņošanas par pārkāpumu sliekšņi.

Finanšu tehnoloģiju uzņēmumiem NIS2 un DORA attiecība ir būtiska. DORA tiek uzskatīta par nozares specifisku ietvaru tvērumā esošām finanšu vienībām, kur pastāv pārklājoši IKT riska un incidentu ziņošanas pienākumi. Praksē organizācijām jāizveido viens ITDR pierādījumu modelis un jāsaista ziņošanas lēmumi ar piemērojamo tiesisko ceļu.

SaaS, mākoņpakalpojumu, pārvaldīto pakalpojumu, pārvaldītās drošības un digitālo platformu organizācijām NIS2 tvērums ir rūpīgi jāpārbauda. NIS2 aptver daudzas I un II pielikuma nozares, tostarp digitālo infrastruktūru, mākoņdatošanas pakalpojumu sniedzējus, datu centrus, uzticamības pakalpojumus, DNS, TLD reģistrus, pārvaldīto pakalpojumu sniedzējus, pārvaldītās drošības pakalpojumu sniedzējus, tiešsaistes tirdzniecības vietas, meklētājprogrammas un sociālo tīklu platformas. ISO/IEC 27001:2022 4. punkta darbības jomas noteikšana un ieinteresēto pušu analīze tāpēc nav formalitāte. Tās nosaka, kuri pienākumi IDPS jāaptver.

Piegādātāju un SaaS identitātes risks

Identitātes incidenti bieži ir atkarīgi no piegādātāja pierādījumiem. Vai SaaS pakalpojumu sniedzējs var eksportēt audita žurnālus? Vai tas parāda OAuth piekrišanas notikumus? Vai tas atbalsta drošus piekļuves kontroles pasākumus, žurnalēšanu un datu aizsardzību? Vai incidentu atbalsts, datu atrašanās vieta, apakšuzņēmēji, piekļuves tiesības un izstāšanās noteikumi ir līgumiski aptverti?

Clarysec Mākoņpakalpojumu izmantošanas politika - SME Mākoņpakalpojumu izmantošanas politika - SME ietver tiešu prasību no Pārvaldības prasības 5.2.4. punkta:

Pakalpojums nodrošina drošas piekļuves kontroles, žurnālfiksēšanas un datu aizsardzības iespējas

Šis vienkāršais teikums ir iepirkuma kontroles pasākums. Ja SaaS platforma nespēj nodrošināt identitātes žurnālus, kas nepieciešami reaģēšanai uz incidentiem, tā rada atbilstības risku.

DORA to skaidri nosaka ar trešo pušu IKT riska pienākumiem. Finanšu vienības joprojām ir atbildīgas par atbilstību, tām jāuztur IKT pakalpojumu līgumu reģistri, jānošķir kritiskās vai svarīgās funkcijas, jāveic sākotnējā izpēte, jāizvērtē koncentrācijas risks, jāiekļauj audita un piekļuves tiesības, jādefinē incidentu atbalsts un jānodrošina izstāšanās stratēģijas.

Zenith Controls ietvaros ISO/IEC 27001:2022 kontrole 8.16 Uzraudzības darbības sasaistās ar 5.22 Piegādātāju pakalpojumu uzraudzība, pārskatīšana un izmaiņu pārvaldība. Tas atspoguļo operacionālo realitāti. Identitātes nodrošinātāja brīdinājumi, SaaS audita žurnāli, mākoņvides administratora darbības un pārvaldīto pakalpojumu sniedzēju konti visi veido daļu no ITDR virsmas.

Kā auditori izvērtēs ITDR

Spēcīgai ITDR programmai jāiztur vairāki audita skatījumi. Katra auditorija uzdod atšķirīgus jautājumus, bet pierādījumiem jāizriet no vienas kontroles sistēmas.

ISO/IEC 27001:2022 auditors jautās, vai identitātes apdraudējumi ir iekļauti risku izvērtēšanā, vai riska īpašnieki ir apstiprinājuši apstrādi, vai Piemērojamības paziņojums ietver attiecīgos A pielikuma kontroles pasākumus, vai politikas ir ieviestas un vai pierādījumi parāda kontroles pasākumu darbību. Auditors var atlasīt priviliģētu kontu un izsekot apstiprinājumam, MFA iestatījumam, žurnāla darbībai, piekļuves tiesību pārskatīšanai un piekļuves atņemšanai.

NIST CSF 2.0 izvērtētājs pārbaudīs GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND un RECOVER rezultātus. ITDR dabiski iekļaujas profilā, kura darbības joma ir identitātes kompromitēšana, SaaS marķieru ļaunprātīga izmantošana vai priviliģētās piekļuves neatļauta izmantošana.

DORA pārbaudītājs meklēs vadības institūcijas pārskatatbildību, IKT atbalstītas biznesa funkcijas, atklāšanas mehānismus, incidentu klasifikācijas kritērijus, eskalāciju, klientu komunikācijas noteikumus, pamatcēloņa analīzi un trešo pušu IKT atkarības.

GDPR pārskatītājs jautās, vai organizācija var pierādīt atbilstošu personas datu drošību. Tiks pārbaudīti piekļuves ierobežojumi, nesankcionētas piekļuves atklāšana, žurnāli, kas parāda, kādiem datiem varētu būt piekļūts, pārkāpuma izvērtējums un pārskatatbildības pierādījumi.

COBIT 2019 vai ISACA tipa auditors pārbaudīs pārvaldību, kontroles mērķus, īpašumtiesības, veiktspējas uzraudzību un apliecinājumu.

Zenith Controls šeit ir noderīgs, jo tas darbojas kā starpatbilstības ceļvedis. Tas neveido atsevišķas “Zenith kontroles”. Tas kartē ISO/IEC 27001:2022 kontroles jomas uz saistītajiem ISO kontroles pasākumiem, citiem standartiem, audita gaidām un ieviešanas attiecībām.

Metrika, kas pierāda ITDR darbību

Valdēm un auditoriem nav vajadzīgs neapstrādāts SIEM troksnis. Viņiem vajadzīgi pierādījumi, ka identitātes kontroles pasākumi darbojas un pilnveidojas. Noderīga ITDR metrika ietver:

• Priviliģēto kontu īpatsvars ar pret pikšķerēšanu noturīgu MFA.
• Neaktīvo kontu skaits, kas pārsniedz politikas slieksni.
• Pakalpojumu kontu skaits bez īpašnieka vai rotācijas datuma.
• Kritisko SaaS platformu īpatsvars, kas sūta autentifikācijas žurnālus uz SIEM.
• Vidējais laiks līdz aizdomīgas identitātes darbības atklāšanai.
• Vidējais laiks līdz kompromitētu sesiju un marķieru atsaukšanai.
• Apstiprināto, noraidīto vai noņemto OAuth lietojumprogrammu skaits.
• Identitātes incidentu īpatsvars ar pilnām pierādījumu pakotnēm.
• Nokavēto piekļuves tiesību pārskatīšanas konstatējumu skaits.
• Piegādātāju platformu skaits, kurām trūkst obligāto identitātes žurnālu.

Šai metrikai jābaro ISO/IEC 27001:2022 vadības pārskatīšana, NIS2 pārvaldības pārraudzība, DORA IKT risku ziņošana un GDPR pārskatatbildības diskusijas.

Bieži ITDR audita konstatējumi un labojumi

Clarysec bieži redz piecus atkārtotus konstatējumus.

Pirmkārt, organizācijas iespējo MFA, bet neuzrauga MFA uzvedību. Novērsiet to, žurnālos fiksējot MFA metožu izmaiņas, neveiksmīgus izaicinājumus, neiespējamu pārvietošanos, jaunu ierīču reģistrāciju un atkārtotus push mēģinājumus.

Otrkārt, pakalpojumu konti ir izslēgti no identitātes pārvaldības. Novērsiet to, uzskaitot sistēmas līmeņa kontus, piešķirot īpašniekus, rotējot noslēpumus, noņemot iegultos autentifikācijas datus un uzraugot anomālu API uzvedību.

Treškārt, SaaS piekrišana netiek pārvaldīta. Novērsiet to, ierobežojot lietotāju piekrišanu, pārskatot OAuth lietojumprogrammas, uzraugot jaunus piešķīrumus, dokumentējot apstiprinātās integrācijas un noņemot neizmantotās lietotnes.

Ceturtkārt, izmeklēšanas laikā pierādījumi tiek mainīti. Novērsiet to, ievērojot Digitālo pierādījumu iegūšanas un kriminālistikas politikas noteikumu: izveidojiet kriminālistiskas kopijas vai eksportus, nekad tieši nerediģējiet oriģinālus un glabājiet pierādījumus ar hešvērtībām un pierādījumu glabāšanas ķēdes ierakstiem.

Piektkārt, incidentu klasifikācija ir pārāk lēna. Novērsiet to, iepriekš definējot identitātes notikumu sliekšņus, tostarp priviliģēta konta kompromitēšanu, piekļuvi personas datiem, klientus ietekmējošu SaaS marķiera ļaunprātīgu izmantošanu, kritiska pakalpojuma traucējumu un piegādātāja identitātes kompromitēšanu.

Katram konstatējumam ir kontroles pasākums, politika un pierādījumu reakcija. Tā ir vienotas ITDR programmas praktiskā vērtība: tā nosaka, kam jābūt īpašumā, kas jāuzrauga, jāpārbauda, jāpamato ar pierādījumiem un jāpilnveido.

Pārvērtiet identitātes risku auditam gatavos pierādījumos

Ja jūsu nākamais identitātes incidents notiktu rīt, vai jūs varētu pierādīt, kurš kam piekļuva, kā viņš autentificējās, kurš marķieris vai sesija tika izmantota, kādi dati tika skarti, kurš pieņēma regulatīvās klasifikācijas lēmumu un kuras korektīvās darbības tika pabeigtas?

Ja atbilde nav skaidra, sāciet ar fokusētu ITDR gatavības sprintu.

Izmantojiet Zenith Blueprint, lai strukturētu ieviešanas ceļu autentifikācijas, piekļuves dzīves cikla, žurnalēšanas, uzraudzības, reaģēšanas uz incidentiem un pierādījumu apstrādes jomās. Izmantojiet Clarysec piekļuves kontroles, žurnalēšanas, mākoņpakalpojumu, incidentu reaģēšanas un kriminālistikas politikas, lai piešķirtu īpašumtiesības un reaģēšanas pilnvaras. Izmantojiet Zenith Controls, lai kartētu identitāšu pārvaldību, drošu autentifikāciju un uzraudzības darbības uz ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST CSF 2.0 un audita gaidām.

Mērķis ir vienkāršs: padarīt identitātes uzbrukumus atklājamus, ierobežojamus, ziņojamus un pamatoti aizstāvamus.

Clarysec var palīdzēt jums izveidot ITDR pierādījumu pakotni, pārbaudīt to ar galda scenārija izspēli un pārvērst konstatējumus riska apstrādes plānā, ko saprot jūsu valde, regulators un auditors. Sāciet ar Žurnālfiksēšanas un uzraudzības politikas, Lietotāju kontu un privilēģiju pārvaldības politikas - SME, Zenith Blueprint un Zenith Controls pārskatīšanu, pēc tam ieplānojiet ITDR gatavības izvērtēšanu, lai pārvērstu identitātes risku auditam gatavos pierādījumos.