ITDR strategija za ISO 27001, NIS2, DORA i GDPR

U utorak u 3:00 ujutro Sarah, CISO društva FinScale, probudila se zbog vrste upozorenja koje suvremeni sigurnosni rukovoditelji sve češće strahuju primiti. Aktivna sesija višeg razvojnog inženjera, autentificirana MFA-om samo nekoliko sati ranije, koristila se iz neuobičajenog izvora za popisivanje shema produkcijskih baza podataka.

Nije bilo signalizacije zlonamjernog softvera. Nije bilo poruke iznuđivačkog softvera. Nije bilo iskorištavanja ranjivosti vatrozida. Samo identitet.

SOC je uočio aktivnost, ali odgovor je bio neusklađen. Je li riječ o zaobilaženju MFA-a, ukradenom tokenu sesije ili kompromitaciji samog pružatelja identiteta? Tko je bio ovlašten prekinuti aktivnu sesiju? Je li opoziv lozinke bio dovoljan ili je tim trebao poništiti tokene za osvježavanje, rotirati API vjerodajnice i pregledati OAuth odobrenja? Do trenutka kada je aktivnost ograničena, napadač je bio aktivan 47 minuta.

Sljedećeg jutra sigurnosni incident postao je pitanje upravljanja. Upravni odbor tražio je objašnjenje razumljivo netehničkim dionicima o tome je li FinScaleova kibernetička higijena zakazala prema NIS2. Tim za usklađenost želio je znati može li se događaj klasificirati kao veći incident povezan s IKT-om prema DORA. Pravni poslovi trebali su dokaziv odgovor na pitanje je li pristupljeno osobnim podacima prema GDPR Article 32 i je li potrebna procjena povrede osobnih podataka. Vanjski revizor pitao je djeluju li kontrole ISO/IEC 27001:2022 učinkovito, a ne samo jesu li dokumentirane u politikama.

Sarahin problem nije bio nedostatak alata. FinScale je imao pružatelja identiteta, MFA, SIEM, kontrole krajnjih uređaja, dnevnike iz oblaka i proces odgovora na incidente. Problem je bio u tome što su upravljanje identitetima, zapisivanje događaja, praćenje, odgovor na incidente, procjena privatnosti i postupanje s dokazima djelovali u silosima.

To je problem otkrivanja prijetnji identitetu i odgovora na njih u 2026. godini. ITDR više nije samo sposobnost sigurnosnih operacija. On je mehanizam dokazivanja usklađenosti koji obuhvaća ISO/IEC 27001:2022, NIS2, DORA i GDPR Article 32.

Clarysecov Zenith Blueprint: revizorov plan u 30 koraka Zenith Blueprint, paket politika i Zenith Controls: vodič za višestruku usklađenost Zenith Controls pomažu organizacijama pretvoriti napade na identitete iz kaotičnih istraga u ponovljive, revizijski provjerljive kontrolne procese.

Zašto je otkrivanje prijetnji identitetu i odgovor na njih sada pitanje za upravni odbor

Napadi na identitete uspijevaju zato što zloupotrebljavaju legitimne putove pristupa. Napadač koji ukrade token sesije, registrira zlonamjernu OAuth aplikaciju, kompromitira servisni račun ili navede korisnika na odobrenje zbog zamora od MFA push obavijesti može sustavima koji provjeravaju samo je li autentifikacija uspjela izgledati kao valjan korisnik.

Zbog toga se ITDR razlikuje od tradicionalne obrane perimetra. Zreo program mora moći odgovoriti na sljedeća pitanja:

• Koji ljudski, servisni, dobavljački i aplikacijski identiteti postoje?
• Koji su identiteti povlašteni, neaktivni, dijeljeni ili eksterno federirani?
• Koji su autentifikacijski događaji normalni, rizični ili nemogući?
• Koja OAuth odobrenja, SaaS tokeni i API vjerodajnice mogu pristupiti osjetljivim podacima?
• Koja upozorenja pokreću klasifikaciju incidenta, očuvanje dokaza i regulatorno odlučivanje?
• Koje kontrole dokazuju da je pristup osobnim podacima zaštićen odgovarajućim tehničkim i organizacijskim mjerama?

NIS2 od toga čini pitanje upravljanja. Article 20 zahtijeva da upravljačka tijela ključnih i važnih subjekata odobre mjere upravljanja rizicima kibernetičke sigurnosti, nadziru njihovu provedbu i pohađaju osposobljavanje. Article 21 zahtijeva odgovarajuće i razmjerne tehničke, operativne i organizacijske mjere, uključujući analizu rizika, postupanje s incidentima, neprekidnost poslovanja, sigurnost opskrbnog lanca, procjenu djelotvornosti kontrola, kibernetičku higijenu, osposobljavanje, kontrolu pristupa, upravljanje imovinom te višefaktorsku ili kontinuiranu autentifikaciju gdje je primjereno.

DORA stavlja sličan pritisak na financijske subjekte. Zahtijeva dokumentirani okvir upravljanja IKT rizicima, odgovornost upravljačkog tijela, mehanizme otkrivanja, upravljanje incidentima, klasifikaciju, izvješćivanje, testiranje otpornosti i upravljanje rizicima trećih strana u području IKT-a. DORA se primjenjuje od 17. siječnja 2025. Za financijske subjekte koji su također obuhvaćeni NIS2, DORA djeluje kao sektorski specifičan pravilnik za preklapajuće obveze povezane s IKT rizikom i incidentima.

GDPR dodaje sloj odgovornosti za privatnost. Article 5 zahtijeva cjelovitost, povjerljivost i odgovornost. Article 4 široko definira povredu osobnih podataka, uključujući neovlašteni pristup osobnim podacima. Article 32 zahtijeva odgovarajuće tehničke i organizacijske mjere za osiguravanje razine sigurnosti primjerene riziku. U incidentima identiteta dnevnici, kontrole pristupa, autentifikacijski zapisi i dokazi o incidentu postaju ključni za dokazivanje jesu li osobni podaci bili zaštićeni.

ISO/IEC 27001:2022 sustav je upravljanja koji može povezati te obveze. Točka 4 zahtijeva da organizacija razumije svoj kontekst, zainteresirane strane te pravne, regulatorne i ugovorne zahtjeve. Točka 6 zahtijeva procjenu rizika, obradu rizika, odobrenje vlasnika rizika i zadržavanje dokaza. Dodatak A uključuje kontrole za upravljanje identitetima, sigurnu autentifikaciju, zapisivanje događaja, praćenje, upravljanje incidentima, prikupljanje dokaza, odnose s dobavljačima, usluge u oblaku i zaštitu privatnosti.

ITDR pripada unutar ISMS-a jer rizik identiteta postaje revizijski provjerljiv tek kada je obuhvaćen opsegom, ima vlasnika, procijenjen je, obrađen, praćen i poboljšavan.

Scenarij napada na identitet koji zanima regulatore

Zamislite pružatelja financijskog tijeka rada u oblaku koji uslužuje korisnike u EU. Koristi Microsoft 365, SaaS platformu za korisničku podršku, infrastrukturu u oblaku, pružatelja platnih usluga i nekoliko integracija temeljenih na API-ju. Viši inženjer korisničke podrške prima uvjerljiv zahtjev za ponovno povezivanje aplikacije za produktivnost. OAuth zaslon za privolu traži pristup čitanju poštanskog sandučića i izvanmrežni pristup. Inženjer to odobrava.

U roku od nekoliko minuta napadač koristi token za pretraživanje identifikatora korisnika i privitaka podrške. Popisuje članstva u grupama i pokušava pristupiti administratorskom portalu. MFA je bio omogućen, ali napadaču lozinka više nije potrebna jer token omogućuje trajan pristup. SOC vidi neuobičajen pristup poštanskom sandučiću, novu OAuth aplikaciju, neuspjele pokušaje pristupa administratorskom portalu i aktivnost iz neuobičajene geografske lokacije.

Ovaj jedan scenarij prelazi više domena kontrola:

• Životni ciklus identiteta, jer uloga i ovlaštenja korisnika određuju doseg štete.
• Sigurna autentifikacija, jer MFA sam po sebi nije spriječio zlouporabu tokena.
• Zapisivanje događaja i praćenje, jer otkrivanje ovisi o dnevnicima pružatelja identiteta, SaaS-a i aplikacija.
• Odgovor na incidente, jer se vjerodajnice, sesije, tokeni i OAuth odobrenja moraju brzo opozvati.
• Prikupljanje dokaza, jer mogu uslijediti izloženost osobnih podataka i regulatorno izvješćivanje.
• Upravljanje dobavljačima i oblakom, jer su SaaS dnevnici i revizijska API sučelja dio dokaznog lanca.
• Zaštita privatnosti, jer se pristup osobnim podacima mora procijeniti prema GDPR.

Bolje pitanje nije „Koji je alat zakazao?” Bolje pitanje glasi je li organizacija imala osmišljen, testiran i revizijski provjerljiv ITDR kontrolni lanac.

Kontrolni lanac ISO 27001:2022 iza učinkovitog ITDR-a

Najučinkovitiji ITDR programi povezuju preventivne, detektivne, korektivne i dokazne kontrole.

U Zenith Controls, kontrola ISO/IEC 27001:2022 5.16 Upravljanje identitetom tretira se kao preventivna kontrola koja podržava povjerljivost, cjelovitost i dostupnost. Izravno je povezana s 5.15 Kontrola pristupa, 5.17 Informacije za autentifikaciju, 5.18 Prava pristupa, 5.19 Informacijska sigurnost u odnosima s dobavljačima, 5.36 Usklađenost s politikama, pravilima i standardima za informacijsku sigurnost te 8.2 Prava povlaštenog pristupa.

To je važno jer otkrivanje prijetnji identitetu ne uspijeva kada je upravljanje identitetima slabo. Ako servisni račun nije dokumentiran, dobavljački identitet nije pod upravljanjem ili povlaštena uloga nema vlasnika, praćenje može otkriti događaj, ali osobe zadužene za odgovor ne mogu ga brzo protumačiti.

Kontrola 8.5 Sigurna autentifikacija drugo je uporište ITDR-a. U Zenith Controls povezuje se s upravljanjem identitetom, informacijama za autentifikaciju, pravima povlaštenog pristupa, ograničenjem pristupa informacijama, aktivnostima praćenja, upravljanjem incidentima i zaštitom privatnosti osobnih podataka (PII). Autentifikacija ne završava prijavom. Upravljanje sesijama, postupanje s tokenima, zaštita vjerodajnica i sljedivost dio su iste dokazne cjeline.

Kontrola 8.16 Aktivnosti praćenja poveznica je između prikupljanja dnevnika i donošenja odluka. Ovisi o 8.15 Zapisivanje događaja i podržava 5.25 Procjenu i odluku o događajima informacijske sigurnosti, 5.26 Odgovor na incidente informacijske sigurnosti i šire upravljanje incidentima. Za ITDR, 8.16 je mjesto na kojem sumnjivo ponašanje identiteta postaje trijažirani događaj, proglašeni incident ili dokumentirani lažno pozitivan rezultat.

Tablica nije teorijsko mapiranje. To je praktični dokazni lanac koji će revizor, član odbora ili regulator očekivati nakon incidenta identiteta.

Što Clarysec politike dodaju: vlasništvo, okidače i pravila dokazivanja

Alati za identitet ne stvaraju automatski odgovornost. Tijekom krize osobe zadužene za odgovor trebaju ovlast za opoziv sesija, onemogućavanje računa, izvoz dnevnika, očuvanje dokaza i donošenje odluka o eskalaciji. Revizori moraju vidjeti da te radnje nisu bile improvizirane.

Clarysecov paket politika pruža taj operativni model.

Iz korporativne Politike upravljanja korisničkim računima i privilegijama Politika upravljanja korisničkim računima i privilegijama, točka 5.9 Zahtjeva upravljanja navodi:

Organizacija mora održavati detaljan popis svih aktivnih i neaktivnih vjerodajnica, povlaštenih računa i servisnih računa na razini sustava. Taj se popis mora kontinuirano ažurirati i pregledavati tromjesečno.

Time se popis identiteta pretvara u izričitu kontrolnu obvezu. To je posebno važno jer su servisni računi, API ključevi i neaktivne vjerodajnice česte slijepe točke ITDR-a.

Ista politika u točki 5.8 Zahtjeva upravljanja navodi:

Sve administrativne aktivnosti i radnje povlaštenih računa moraju se zapisivati na način koji omogućuje otkrivanje neovlaštene izmjene te pratiti radi anomalija ili kršenja politike.

Ta točka povezuje upravljanje povlaštenim pristupom s otkrivanjem. Povlaštena radnja nije samo dopuštena ili odbijena. Mora se pratiti zbog ponašanja koje ne odgovara korisniku, ulozi, izvoru, vremenu ili poslovnom procesu.

Za manje organizacije, Politika upravljanja korisničkim računima i privilegijama - SME Politika upravljanja korisničkim računima i privilegijama - SME daje sažeto očekivanje u točki 8.1.1 Provedbe i usklađenosti:

Voditelj IT-a mora redovito pregledavati dnevnike sustava radi pokušaja neovlaštenog pristupa, anomalija prijave ili neodobrenih promjena privilegija.

Tu počinju mnogi SME ITDR programi. Nije potreban velik SOC. Potrebni su imenovano vlasništvo i redovit pregled pravih signala identiteta.

Politika zapisivanja događaja pruža temelj za dokaze. Politika zapisivanja događaja i praćenja - SME Politika zapisivanja događaja i praćenja - SME u točki 5.4.2 Zahtjeva upravljanja određuje:

Autentifikacijski dnevnici: uspješni i neuspješni pokušaji prijave, trajanje sesije, uporaba MFA-a

Ta polja nisu opcionalna. Pomažu dokazati je li sumnjivi događaj uključivao uspješnu autentifikaciju, ponovljene neuspjehe, uporabu MFA-a, trajnost sesije ili neuobičajeno trajanje.

Korporativna Politika zapisivanja događaja i praćenja Politika zapisivanja događaja i praćenja proširuje potrebni opseg dnevnika u točki 6.1.1 Zahtjeva za provedbu politike:

Svi obuhvaćeni sustavi moraju generirati dnevnike koji obuhvaćaju: 6.1.1.1 Autentifikaciju korisnika i pokušaje pristupa 6.1.1.2 Aktivnosti povlaštenih korisnika 6.1.1.3 Promjene konfiguracije 6.1.1.4 Neuspjele pokušaje pristupa ili događaje sustava 6.1.1.5 Detekcije zlonamjernog softvera i sigurnosna upozorenja 6.1.1.6 Vanjske komunikacije i okidače pravila vatrozida

Promjene konfiguracije osobito su važne u napadima na identitete. Napadači često dodaju OAuth odobrenja, stvaraju pravila prosljeđivanja, registriraju uređaje, mijenjaju MFA metode ili stvaraju pričuvne putove pristupa.

Politika odgovora na incidente zatim daje ovlast osobama zaduženima za odgovor. Korporativna Politika odgovora na incidente Politika odgovora na incidente u točki 6.2.1 Zahtjeva za provedbu politike navodi:

SOC mora odmah izolirati pogođene sustave, opozvati kompromitirane vjerodajnice ili blokirati zlonamjerni promet uporabom vatrozida ili alata za sigurnost krajnjih točaka.

SME Politika odgovora na incidente - SME Politika odgovora na incidente - SME u točki 4.2.2 Uloga i odgovornosti navodi:

Provodi radnje ograničavanja i oporavka, primjerice onemogućavanjem pristupa ili vraćanjem sigurnosnih kopija.

Za ITDR opoziv lozinke nije dovoljan. Operativni postupci moraju uključivati onemogućavanje računa, opoziv sesija, poništavanje OAuth odobrenja, rotaciju tajnih vrijednosti, resetiranje MFA metoda i pregled delegiranih ovlaštenja.

Postupanje s dokazima čini razliku između odgovora i dokazivanja. Korporativna Politika prikupljanja dokaza i forenzike Politika prikupljanja dokaza i forenzike u točki 5.5 Zahtjeva upravljanja navodi:

Svi prikupljeni dokazi moraju biti jedinstveno identificirani, označeni i pohranjeni u sigurnom repozitoriju s: 5.5.1 provjerom cjelovitosti, kao što su SHA-256 vrijednosti sažetka 5.5.2 zapisima pristupa s vremenskom oznakom 5.5.3 unosima lanca čuvanja dokaza koje potpisuje svaki skrbnik

SME Politika prikupljanja dokaza i forenzike - SME Politika prikupljanja dokaza i forenzike - SME u točki 6.1.1 Zahtjeva za provedbu politike navodi:

Forenzička kopija ili izvoz uvijek se mora izraditi; izvorni dokaz nikada se ne smije izravno uređivati.

U scenariju FinScale to znači da SOC izvozi dnevnike pružatelja identiteta, SaaS revizijske zapise, zapise pristupa poštanskom sandučiću, zapise OAuth privola, zapise opoziva sesija i SIEM upozorenja u repozitorij dokaza sa zaštitom cjelovitosti i lancem čuvanja dokaza.

Izgradnja ITDR plana pomoću Zenith Blueprint

Zenith Blueprint prevodi kontrolni lanac u korake provedbe.

U fazi Controls in Action, korak 19, Technological Controls I, Blueprint izravno govori o autentifikaciji:

Gdje god je moguće, treba izbjegavati autentifikaciju samo lozinkom, osobito za administratorske račune, konzole u oblaku, alate za udaljeni pristup i svaki sustav izložen internetu. MFA, uporabom drugog faktora kao što su hardverski sigurnosni ključevi, mobilna aplikacija ili biometrija, sada je početna kontrola, a ne luksuz. Ublažava rizike krađe vjerodajnica, phishinga i brute-force napada.

Isti korak ide dalje od lozinki. Zahtijeva sigurnu pohranu i prijenos autentifikacijskih podataka, sigurno postupanje s API tokenima, ID-jevima sesija i OAuth vjerodajnicama, upravljanje tajnama za autentifikaciju između strojeva, rotaciju tokena, kontrole životnog vijeka sesija, sigurne oznake kolačića i pregled autentifikacijskih dnevnika.

Korak 22, Organizacijske kontrole, formalizira životni ciklus pristupa. Usmjerava timove da integriraju dodjelu i ukidanje pristupnih prava s HR-om, provode dokumentirane tromjesečne preglede pristupa, definiraju vrste identiteta kao što su individualni, dijeljeni i servisni računi, provode MFA za povlaštene račune, uklanjaju neaktivne račune i rotiraju servisne vjerodajnice.

Korak 19 također daje put poboljšanja zapisivanja događaja: prosljeđivanje kritičnih dnevnika u SIEM ili sakupljač dnevnika, provjeru zadržavanja, praćenje nedavnog događaja uporabom dnevnika, dokumentiranje značajki cjelovitosti dnevnika i potvrdu upozoravanja za neuspjele prijave ili eskalacije privilegija. Sinkronizacija vremena važna je jer rekonstrukcija incidenta ne uspijeva kada se dnevnici pružatelja identiteta, SaaS-a, krajnjih uređaja i oblaka ne slažu u vremenskim oznakama.

Korak 23, Organizacijske kontrole za 5.19 do 5.37, provjerava sposobnosti upravljanja incidentima. Zahtijeva ažuran plan odgovora na incidente, definirane događaje koji se prijavljuju, stolne vježbe, dokumentirane odluke, komunikacijske zapise, naučene lekcije i očuvanje forenzičkih dokaza kao što su snimke dnevnika, sigurnosne kopije i sigurna izolacija.

Pragmatičan Clarysec ITDR slijed izgleda ovako:

1. Definirati vrste identiteta i vlasnike.
2. Osigurati autentifikaciju, tokene i sesije.
3. Prikupljati autentifikacijske, privilegijske i SaaS dnevnike.
4. Pratiti rizična ponašanja.
5. Definirati pravila odlučivanja od događaja do incidenta.
6. Očuvati dokaze.
7. Izvijestiti, oporaviti se i poboljšati.

Jednotjedni ITDR paket dokaza

Fokusirani „paket dokaza za incident identiteta” jedan je od najbržih načina za otkrivanje praznina. Odaberite jedan visokorizičan scenarij, primjerice: „Povlašteni SaaS korisnik daje privolu neovlaštenoj OAuth aplikaciji, a token se koristi za pristup podacima klijenata.”

Zatim izgradite paket dokaza u jednom tjednu.

Uključite barem jedan stvarni trag. Uzmite benignu nedavnu anomaliju prijave i pokažite kako tim prelazi od upozorenja do identiteta korisnika, uređaja, izvorne IP adrese, MFA metode, trajanja sesije, pristupljenih SaaS resursa, podataka kojih se pristup dotaknuo i odluke o ograničavanju. Ako organizacija ne može rekonstruirati taj lanac u stolnoj vježbi, imat će poteškoća tijekom stvarnog incidenta.

Izlazni rezultat postaje ponovno upotrebljiv dokaz za interne revizije ISO/IEC 27001:2022, testiranje DORA procesa IKT incidenata, NIS2 nadzor kibernetičke higijene i odgovornost prema GDPR.

Mapiranje ITDR-a na NIS2, DORA i GDPR Article 32

Snaga jedinstvenog ITDR modela jest u tome što isti dokazi zadovoljavaju više obveza, uz poštivanje jezika svakog okvira.

NIS2 Article 21 očekuje tehničke, operativne i organizacijske mjere koje su temeljene na riziku i razmjerne. Za ITDR to znači kontrolu pristupa, upravljanje imovinom, kibernetičku higijenu, osposobljavanje, postupanje s incidentima, procjenu djelotvornosti kontrola te MFA ili kontinuiranu autentifikaciju gdje je primjereno. Article 23 uvodi fazno izvješćivanje za značajne incidente, uključujući rano upozorenje u roku od 24 sata, obavijest o incidentu u roku od 72 sata i završno izvješće u roku od jednog mjeseca.

DORA Articles 8 to 14 zahtijevaju identifikaciju IKT imovine i ovisnosti, zaštitu i prevenciju, mehanizme otkrivanja, neprekidnost i oporavak, učenje i komunikaciju. Articles 17 to 19 zahtijevaju upravljanje incidentima, utvrđivanje temeljnog uzroka, pokazatelje ranog upozorenja, klasifikaciju prema ozbiljnosti i kritičnosti usluge, eskalaciju, obavješćivanje upravljačkog tijela, izvješćivanje nadležnom tijelu i obavješćivanje klijenata kada su pogođeni financijski interesi.

GDPR zahtijeva odgovarajuće tehničke i organizacijske mjere te dokazivu odgovornost. U napadima na identitet pitanja prema GDPR uključuju je li došlo do neovlaštenog pristupa, koji su osobni podaci bili uključeni, jesu li zaštitne mjere djelovale i jesu li dosegnuti pragovi za prijavu povrede podataka.

Za fintech društva odnos između NIS2 i DORA važan je. DORA se tretira kao sektorski specifičan okvir za financijske subjekte u opsegu u kojem postoje preklapajuće obveze povezane s IKT rizikom i izvješćivanjem o incidentima. U praksi organizacije trebaju izgraditi jedan ITDR dokazni model i mapirati odluke o izvješćivanju na primjenjivi pravni put.

Za SaaS, oblak, upravljane usluge, upravljanu sigurnost i organizacije digitalnih platformi, opseg NIS2 mora se pažljivo provjeriti. NIS2 obuhvaća mnoge sektore iz Priloga I i Priloga II, uključujući digitalnu infrastrukturu, pružatelje usluga računalstva u oblaku, podatkovne centre, usluge povjerenja, DNS, registre TLD-a, pružatelje upravljanih usluga, pružatelje upravljanih sigurnosnih usluga, internetska tržišta, tražilice i platforme društvenih mreža. Određivanje opsega i analiza zainteresiranih strana prema ISO/IEC 27001:2022 točki 4 stoga nisu administrativna formalnost. Oni definiraju koje obveze ISMS mora obuhvatiti.

Rizik identiteta kod dobavljača i SaaS-a

Incidenti identiteta često ovise o dokazima dobavljača. Može li SaaS pružatelj izvesti revizijske zapise? Prikazuje li događaje OAuth privole? Podržava li sigurne kontrole pristupa, zapisivanje događaja i zaštitu podataka? Jesu li pomoć pri incidentu, lokacija podataka, podugovaranje, prava pristupa i odredbe o izlasku ugovorno uređeni?

Clarysecova Politika korištenja usluga u oblaku - SME Politika korištenja usluga u oblaku - SME uključuje izravan zahtjev iz točke 5.2.4 Zahtjeva upravljanja:

Usluga pruža sigurne kontrole pristupa, zapisivanje događaja i mogućnosti zaštite podataka

Ta jednostavna rečenica jest kontrola nabave. Ako SaaS platforma ne može proizvesti dnevnike identiteta potrebne za odgovor na incidente, stvara rizik usklađenosti.

DORA to izričito propisuje kroz obveze upravljanja rizicima trećih strana u području IKT-a. Financijski subjekti ostaju odgovorni za usklađenost, moraju održavati registre ugovora o IKT uslugama, razlikovati kritične ili važne funkcije, provoditi dubinsku analizu dobavljača, procjenjivati rizik koncentracije, uključiti prava na reviziju i pristup, definirati pomoć pri incidentu i osigurati izlazne strategije.

U Zenith Controls, kontrola ISO/IEC 27001:2022 8.16 Aktivnosti praćenja povezuje se s 5.22 Praćenje, pregled i upravljanje promjenama usluga dobavljača. To odražava operativnu stvarnost. Upozorenja pružatelja identiteta, SaaS revizijski zapisi, aktivnosti administratora oblaka i računi pružatelja upravljanih usluga čine dio ITDR površine.

Kako će revizori procjenjivati ITDR

Snažan ITDR program mora izdržati više revizijskih perspektiva. Svaka publika postavlja drukčija pitanja, ali dokazi moraju dolaziti iz istog kontrolnog sustava.

Revizor ISO/IEC 27001:2022 pitat će jesu li prijetnje identitetu uključene u procjenu rizika, jesu li vlasnici rizika odobrili obradu, uključuje li Izjava o primjenjivosti relevantne kontrole iz Dodatka A, provode li se politike i pokazuju li dokazi da kontrole djeluju. Može uzorkovati povlašteni račun i pratiti odobrenje, MFA postavku, aktivnost u dnevnicima, pregled pristupa i ukidanje pristupnih prava.

Procjenitelj prema NIST CSF 2.0 ispitat će ishode GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND i RECOVER. ITDR se prirodno uklapa u profil čiji je opseg kompromitacija identiteta, zlouporaba SaaS tokena ili zlouporaba povlaštenog pristupa.

Ispitivač prema DORA tražit će odgovornost upravljačkog tijela, poslovne funkcije podržane IKT-om, mehanizme otkrivanja, kriterije klasifikacije incidenata, eskalaciju, pravila komunikacije s klijentima, analizu temeljnog uzroka i IKT ovisnosti o trećim stranama.

Pregledavatelj prema GDPR pitat će može li organizacija dokazati odgovarajuću sigurnost osobnih podataka. Ispitat će ograničenje pristupa, otkrivanje neovlaštenog pristupa, dnevnike koji pokazuju kojim se podacima možda pristupilo, procjenu povrede i dokaze odgovornosti.

Revizor u stilu COBIT 2019 ili ISACA ispitat će upravljanje, ciljeve kontrola, vlasništvo, praćenje učinkovitosti i osiguranje.

Zenith Controls ovdje je koristan jer djeluje kao vodič za višestruku usklađenost. Ne stvara zasebne „Zenith kontrole”. Mapira područja kontrola ISO/IEC 27001:2022 na povezane ISO kontrole, druge standarde, revizijska očekivanja i odnose provedbe.

Metrike koje dokazuju da ITDR djeluje

Upravni odbori i revizori ne trebaju sirovu SIEM buku. Trebaju dokaze da kontrole identiteta djeluju i poboljšavaju se. Korisne ITDR metrike uključuju:

• Postotak povlaštenih računa s MFA-om otpornim na phishing.
• Broj neaktivnih računa starijih od praga definiranog politikom.
• Broj servisnih računa bez vlasnika ili datuma rotacije.
• Postotak kritičnih SaaS platformi koje šalju autentifikacijske dnevnike u SIEM.
• Prosječno vrijeme do otkrivanja sumnjive aktivnosti identiteta.
• Prosječno vrijeme do opoziva kompromitiranih sesija i tokena.
• Broj OAuth aplikacija koje su odobrene, odbijene ili uklonjene.
• Postotak incidenata identiteta s potpunim paketima dokaza.
• Broj dospjelih, a neriješenih nalaza pregleda pristupa.
• Broj dobavljačkih platformi kojima nedostaju potrebni dnevnici identiteta.

Te metrike moraju se koristiti u preispitivanju sustava upravljanja informacijskom sigurnošću od strane uprave prema ISO/IEC 27001:2022, nadzoru upravljanja prema NIS2, izvješćivanju o IKT rizicima prema DORA i raspravama o odgovornosti prema GDPR.

Uobičajeni ITDR nalazi revizije i korektivne mjere

Clarysec često uočava pet ponavljajućih nalaza.

Prvo, organizacije omogućuju MFA, ali ne prate MFA ponašanje. Ispravite to zapisivanjem promjena MFA metoda, neuspjelih izazova, nemogućeg putovanja, registracije novih uređaja i ponovljenih push pokušaja.

Drugo, servisni računi isključeni su iz upravljanja identitetima. Ispravite to popisivanjem računa na razini sustava, dodjelom vlasnika, rotacijom tajnih vrijednosti, uklanjanjem ugrađenih vjerodajnica i praćenjem anomalnog API ponašanja.

Treće, SaaS privola nije pod upravljanjem. Ispravite to ograničavanjem korisničke privole, pregledom OAuth aplikacija, praćenjem novih odobrenja, dokumentiranjem odobrenih integracija i uklanjanjem nekorištenih aplikacija.

Četvrto, dokazi se mijenjaju tijekom istrage. Ispravite to pridržavanjem pravila iz Politike prikupljanja dokaza i forenzike: izraditi forenzičke kopije ili izvoze, nikada izravno ne uređivati originale i pohraniti dokaze sa sažecima i zapisima lanca čuvanja dokaza.

Peto, klasifikacija incidenta je prespora. Ispravite to unaprijed definiranim pragovima događaja identiteta, uključujući kompromitaciju povlaštenog računa, pristup osobnim podacima, zlouporabu SaaS tokena s utjecajem na klijente, prekid kritične usluge i kompromitaciju dobavljačkog identiteta.

Svaki nalaz ima odgovor kroz kontrolu, politiku i dokaze. To je praktična vrijednost jedinstvenog ITDR programa: definira što mora imati vlasnika, što se mora pratiti, testirati, dokazivati i poboljšavati.

Pretvorite rizik identiteta u dokaze spremne za reviziju

Ako bi se vaš sljedeći incident identiteta dogodio sutra, biste li mogli dokazati tko je pristupio čemu, kako se autentificirao, koji je token ili sesija korištena, kojih su se podataka radnje dotaknule, tko je odlučio o regulatornoj klasifikaciji i koje su korektivne radnje dovršene?

Ako je odgovor neizvjestan, započnite fokusirani ITDR sprint za spremnost.

Upotrijebite Zenith Blueprint za strukturiranje puta provedbe kroz autentifikaciju, životni ciklus pristupa, zapisivanje događaja, praćenje, odgovor na incidente i postupanje s dokazima. Upotrijebite Clarysecove politike kontrole pristupa, zapisivanja događaja, oblaka, odgovora na incidente i forenzike za dodjelu vlasništva i ovlasti za odgovor. Upotrijebite Zenith Controls za mapiranje upravljanja identitetima, sigurne autentifikacije i aktivnosti praćenja na ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST CSF 2.0 i revizijska očekivanja.

Cilj je jednostavan: učiniti napade na identitete otkrivljivima, ograničivima, prijavljivima i dokazivima.

Clarysec vam može pomoći izgraditi ITDR paket dokaza, testirati ga kroz stolnu vježbu sa scenarijem i pretvoriti nalaze u plan obrade rizika koji razumiju vaš upravni odbor, regulator i revizor. Započnite pregledom Politike zapisivanja događaja i praćenja, Politike upravljanja korisničkim računima i privilegijama - SME, Zenith Blueprint i Zenith Controls, a zatim zakažite ITDR procjenu spremnosti kako biste rizik identiteta pretvorili u revizijski spremne dokaze.