Strategija ITDR za ISO 27001, NIS2, DORA in GDPR

V torek ob 3.00 zjutraj se je Sarah, vodja informacijske varnosti v družbi FinScale, zbudila zaradi opozorila, ki se ga sodobni varnostni vodje vse bolj bojijo. Aktivna seja višjega razvijalca, ki je bila le nekaj ur prej overjena z MFA, se je z neobičajnega vira uporabljala za naštevanje shem produkcijske podatkovne baze.

Ni bilo signala zlonamerne programske opreme. Ni bilo obvestila o izsiljevalski programski opremi. Ni bilo izkoriščanja požarnega zidu. Samo identiteta.

SOC je dejavnost zaznal, vendar odziv ni bil usklajen. Je šlo za obid MFA, ukraden žeton seje ali kompromitacijo samega ponudnika identitet? Kdo je imel pooblastilo za prekinitev aktivne seje? Ali je zadostoval preklic gesla ali je morala ekipa razveljaviti osvežitvene žetone, zamenjati poverilnice API in pregledati odobritve OAuth? Do zajezitve dejavnosti je bil napadalec aktiven 47 minut.

Naslednje jutro je varnostni incident postal vprašanje upravljanja. Upravni odbor je želel jasno razlago, ali je kibernetska higiena družbe FinScale odpovedala v okviru NIS2. Ekipa za skladnost je želela vedeti, ali je dogodek mogoče razvrstiti kot večji incident, povezan z IKT, v okviru DORA. Pravna služba je potrebovala zagovorljiv odgovor, ali je bil izveden dostop do osebnih podatkov v smislu GDPR Article 32 in ali je potrebna presoja kršitve varnosti osebnih podatkov. Zunanji presojevalec je vprašal, ali kontrole ISO/IEC 27001:2022 učinkovito delujejo, ne pa zgolj obstajajo kot zapisi v politikah.

Sarahina težava ni bila pomanjkanje orodij. FinScale je imel ponudnika identitet, MFA, SIEM, kontrole končnih točk, dnevnike v oblaku in proces odzivanja na incidente. Težava je bila v tem, da so upravljanje identitet, beleženje, spremljanje, odziv na incidente, presoja zasebnosti in ravnanje z dokazili delovali v ločenih silosih.

To je izziv zaznavanja groženj identitetam in odzivanja nanje v letu 2026. ITDR ni več zgolj zmogljivost varnostnih operacij. Je dokazni mehanizem za več okvirov skladnosti hkrati: ISO/IEC 27001:2022, NIS2, DORA in GDPR Article 32.

Clarysecov Zenith Blueprint: načrt v 30 korakih za presojevalce Zenith Blueprint, nabor politik in Zenith Controls: vodnik za navzkrižno skladnost Zenith Controls organizacijam pomagajo napade na identitete pretvoriti iz kaotičnih preiskav v ponovljive in preverljive kontrolne procese.

Zakaj je zaznavanje groženj identitetam in odzivanje nanje zdaj vprašanje za upravni odbor

Napadi na identitete delujejo zato, ker zlorabljajo legitimne poti dostopa. Napadalec, ki ukrade žeton seje, registrira zlonamerno aplikacijo OAuth, kompromitira storitveni račun ali uporabnika izčrpa s ponavljajočimi se potisnimi pozivi MFA, je sistemom, ki preverjajo le uspešno avtentikacijo, lahko videti kot veljaven uporabnik.

Zato se ITDR razlikuje od tradicionalne zaščite omrežnega roba. Zrel program mora znati odgovoriti na vprašanja:

• Katere človeške, storitvene, dobaviteljske in aplikacijske identitete obstajajo?
• Katere identitete so privilegirane, mirujoče, skupne ali zunanje federirane?
• Kateri avtentikacijski dogodki so običajni, tvegani ali nemogoči?
• Katere odobritve OAuth, žetoni SaaS in poverilnice API lahko dostopajo do občutljivih podatkov?
• Katera opozorila sprožijo razvrščanje incidenta, hrambo dokazil in regulativno odločanje?
• Katere kontrole dokazujejo, da je dostop do osebnih podatkov zaščiten z ustreznimi tehničnimi in organizacijskimi ukrepi?

NIS2 iz tega naredi vprašanje upravljanja. Article 20 zahteva, da organi vodenja bistvenih in pomembnih subjektov odobrijo ukrepe za upravljanje kibernetskih tveganj, nadzorujejo njihovo izvajanje in se usposabljajo. Article 21 zahteva ustrezne in sorazmerne tehnične, operativne in organizacijske ukrepe, vključno z analizo tveganj, obravnavanjem incidentov, neprekinjenim poslovanjem, varnostjo dobavne verige, presojo učinkovitosti kontrol, kibernetsko higieno, usposabljanjem, nadzorom dostopa, upravljanjem sredstev ter večfaktorsko ali neprekinjeno avtentikacijo, kadar je to ustrezno.

DORA podoben pritisk nalaga finančnim subjektom. Zahteva dokumentiran okvir upravljanja IKT-tveganj, odgovornost organa vodenja, mehanizme zaznavanja, upravljanje incidentov, razvrščanje, poročanje, testiranje odpornosti in upravljanje tveganj IKT tretjih oseb. DORA se uporablja od 17. januarja 2025. Za finančne subjekte, ki so hkrati opredeljeni tudi po NIS2, DORA deluje kot sektorski pravilnik za prekrivajoče se obveznosti glede IKT-tveganj in incidentov.

GDPR doda plast odgovornosti glede zasebnosti. Article 5 zahteva celovitost, zaupnost in odgovornost. Article 4 široko opredeljuje kršitev varnosti osebnih podatkov, vključno z nepooblaščenim dostopom do osebnih podatkov. Article 32 zahteva ustrezne tehnične in organizacijske ukrepe za zagotavljanje ravni varnosti, primerne tveganju. Pri incidentih identitet postanejo dnevniki, kontrole dostopa, zapisi avtentikacije in dokazila o incidentu ključni za dokazovanje, ali so bili osebni podatki zaščiteni.

ISO/IEC 27001:2022 je sistem upravljanja, ki lahko te obveznosti poveže. Točka 4 zahteva, da organizacija razume svoj kontekst, zainteresirane strani ter zakonske, regulativne in pogodbene zahteve. Točka 6 zahteva oceno tveganja, obravnavo tveganja, odobritev lastnika tveganja in hranjena dokazila. Priloga A vključuje kontrole za upravljanje identitet, varno avtentikacijo, beleženje, spremljanje, upravljanje incidentov, zbiranje dokazov, odnose z dobavitelji, storitve v oblaku in varstvo zasebnosti.

ITDR sodi v ISMS, ker tveganje identitet postane preverljivo šele, ko je vključeno v obseg, ima lastnika, je ocenjeno, obravnavano, spremljano in izboljševano.

Scenarij napada na identitete, ki zanima regulatorje

Predstavljajte si ponudnika finančnih delovnih tokov v oblaku, ki oskrbuje stranke v EU. Uporablja Microsoft 365, platformo SaaS za podporo strankam, infrastrukturo v oblaku, ponudnika plačilnih storitev in več integracij na podlagi API. Višji inženir za podporo prejme prepričljiv poziv za ponovno povezavo aplikacije za produktivnost. Zaslon soglasja OAuth zahteva dostop za branje poštnega predala in dostop brez povezave. Inženir zahtevo odobri.

V nekaj minutah napadalec uporabi žeton za iskanje identifikatorjev strank in priponk v podpori. Našteva članstva v skupinah in poskuša dostopati do administratorskega portala. MFA je bil omogočen, vendar napadalec gesla ne potrebuje več, ker mu žeton omogoča vztrajen dostop. SOC zazna nenavaden dostop do poštnega predala, novo aplikacijo OAuth, neuspele poskuse dostopa do administratorskega portala in dejavnost z neobičajne geografske lokacije.

Ta en sam scenarij prečka več kontrolnih področij:

• Življenjski cikel identitet, ker uporabnikova vloga in dovoljenja določajo obseg vpliva.
• Varna avtentikacija, ker MFA sam po sebi ni preprečil zlorabe žetona.
• Beleženje in spremljanje, ker je zaznavanje odvisno od dnevnikov ponudnika identitet, SaaS in aplikacij.
• Odziv na incidente, ker je treba poverilnice, seje, žetone in odobritve OAuth hitro preklicati.
• Zbiranje dokazov, ker lahko sledi izpostavljenost osebnih podatkov in regulativno poročanje.
• Upravljanje dobaviteljev in oblaka, ker so dnevniki SaaS in revizijski vmesniki API del dokazne verige.
• Varstvo zasebnosti, ker je treba dostop do osebnih podatkov presoditi po GDPR.

Boljše vprašanje ni »Katero orodje je odpovedalo?« Boljše vprašanje je, ali je imela organizacija zasnovano, preizkušeno in preverljivo kontrolno verigo ITDR.

Kontrolna veriga ISO 27001:2022 za učinkovit ITDR

Najbolj učinkoviti programi ITDR povezujejo preventivne, odkrivalne, korektivne in dokazne kontrole.

V Zenith Controls se kontrola ISO/IEC 27001:2022 5.16 Upravljanje identitet obravnava kot preventivna kontrola, ki podpira zaupnost, celovitost in razpoložljivost. Neposredno se povezuje s 5.15 Nadzor dostopa, 5.17 Avtentikacijske informacije, 5.18 Pravice dostopa, 5.19 Informacijska varnost v odnosih z dobavitelji, 5.36 Skladnost s politikami, pravili in standardi informacijske varnosti ter 8.2 Privilegirane pravice dostopa.

To je pomembno, ker zaznavanje na ravni identitet odpove, kadar je upravljanje pravic dostopa šibko. Če storitveni račun ni dokumentiran, dobaviteljska identiteta ni upravljana ali privilegirana vloga nima lastnika, lahko spremljanje dogodek sicer zazna, vendar ga odzivne ekipe ne morejo hitro razložiti.

Kontrola 8.5 Varna avtentikacija je še eno sidro ITDR. V Zenith Controls se povezuje z upravljanjem identitet, avtentikacijskimi informacijami, privilegiranimi pravicami dostopa, omejitvijo dostopa do informacij, dejavnostmi spremljanja, upravljanjem incidentov in varstvom zasebnosti osebno določljivih podatkov. Avtentikacija se ne konča ob prijavi. Upravljanje sej, ravnanje z žetoni, zaščita poverilnic in sledljivost so del iste dokazne zgodbe.

Kontrola 8.16 Dejavnosti spremljanja je vezni člen med zbiranjem dnevnikov in odločanjem. Odvisna je od 8.15 Beleženje ter podpira 5.25 Presojo in odločanje o dogodkih informacijske varnosti, 5.26 Odziv na incidente informacijske varnosti in širše upravljanje incidentov. Pri ITDR je 8.16 mesto, kjer sumljivo vedenje identitete postane triažiran dogodek, razglašen incident ali dokumentiran lažno pozitiven rezultat.

Tabela ni teoretično mapiranje. Je praktična dokazna veriga, ki jo bodo po incidentu identitete pričakovali presojevalec, član upravnega odbora ali regulator.

Kaj dodajo politike Clarysec: lastništvo, sprožilci in pravila dokazovanja

Orodja za identitete sama po sebi ne ustvarijo odgovornosti. Med krizo odzivne ekipe potrebujejo pooblastilo za preklic sej, onemogočanje računov, izvoz dnevnikov, hrambo dokazil in sprejemanje eskalacijskih odločitev. Presojevalci morajo videti, da ta dejanja niso bila improvizirana.

Nabor politik Clarysec zagotavlja tak operativni model.

Podjetniška Politika upravljanja uporabniških računov in privilegijev Politika upravljanja uporabniških računov in privilegijev v točki 5.9 zahtev upravljanja določa:

Organizacija mora vzdrževati podroben popis vseh aktivnih in mirujočih poverilnic, privilegiranih računov in sistemskih storitvenih računov. Ta popis se mora stalno posodabljati in četrtletno pregledovati.

S tem register identitet postane izrecna kontrolna obveznost. To je še posebej pomembno, ker so storitveni računi, ključi API in mirujoče poverilnice pogoste slepe pege ITDR.

Ista politika v točki 5.8 zahtev upravljanja določa:

Vse administratorske dejavnosti in dejanja privilegiranih računov morajo biti zabeležena na način, ki razkriva posege, ter spremljana zaradi anomalij ali kršitev politike.

Ta točka povezuje upravljanje privilegiranih dostopov z zaznavanjem. Privilegirano dejanje ni zgolj dovoljeno ali zavrnjeno. Spremljati ga je treba glede vedenja, ki ne ustreza uporabniku, vlogi, viru, času ali poslovnemu procesu.

Za manjše organizacije Politika upravljanja uporabniških računov in privilegijev - SME Politika upravljanja uporabniških računov in privilegijev - SME v točki 8.1.1 poglavja Izvajanje in skladnost podaja jedrnato pričakovanje:

Vodja IT mora redno pregledovati sistemske dnevnike glede poskusov nepooblaščenega dostopa, anomalij pri prijavah ali neodobrenih sprememb privilegijev.

Tu se začnejo številni programi ITDR v malih in srednjih podjetjih. Ne zahtevajo velikega SOC. Zahtevajo imenovano odgovorno osebo in redni pregled pravih signalov identitete.

Politika beleženja zagotavlja dokazno podlago. Politika beleženja in spremljanja - SME Politika beleženja in spremljanja - SME v točki 5.4.2 zahtev upravljanja določa:

Dnevniki avtentikacije: uspešni in neuspešni poskusi prijave, trajanje seje, uporaba MFA

Ta polja niso neobvezna. Pomagajo dokazati, ali je sumljiv dogodek vključeval uspešno avtentikacijo, ponavljajoče se neuspehe, uporabo MFA, vztrajnost seje ali neobičajno trajanje.

Podjetniška Politika beleženja in spremljanja Politika beleženja in spremljanja v točki 6.1.1 zahtev za izvajanje politike razširja zahtevani obseg dnevnikov:

Vsi zajeti sistemi morajo ustvarjati dnevnike, ki zajemajo: 6.1.1.1 Avtentikacijo uporabnikov in poskuse dostopa 6.1.1.2 Dejavnosti privilegiranih uporabnikov 6.1.1.3 Spremembe konfiguracije 6.1.1.4 Neuspešne poskuse dostopa ali sistemske dogodke 6.1.1.5 Zaznave zlonamerne programske opreme in varnostna opozorila 6.1.1.6 Zunanje komunikacije in sprožitve pravil požarnega zidu

Spremembe konfiguracije so pri napadih na identitete posebej pomembne. Napadalci pogosto dodajo odobritve OAuth, ustvarijo pravila posredovanja, registrirajo naprave, spremenijo metode MFA ali ustvarijo poti za nujni dostop.

Politika odziva na incidente nato odzivnim ekipam daje pooblastila. Podjetniška Politika odzivanja na incidente Politika odzivanja na incidente v točki 6.2.1 zahtev za izvajanje politike določa:

SOC mora takoj izolirati prizadete sisteme, preklicati kompromitirane poverilnice ali blokirati zlonameren promet z uporabo požarnega zidu ali orodij za varnost končnih točk.

Politika odzivanja na incidente - SME Politika odzivanja na incidente - SME v točki 4.2.2 poglavja Vloge in odgovornosti določa:

Izvaja ukrepe zajezitve in obnovitve, na primer z onemogočanjem dostopa ali obnovitvijo varnostnih kopij.

Pri ITDR preklic gesla ni dovolj. Operativni postopkovniki morajo vključevati onemogočanje računov, preklic sej, razveljavitev odobritev OAuth, menjavo skrivnosti, ponastavitev metod MFA in pregled delegiranih dovoljenj.

Ravnanje z dokazili je razlika med odzivanjem in dokazovanjem. Podjetniška Politika zbiranja dokazov in forenzike Politika zbiranja dokazov in forenzike v točki 5.5 zahtev upravljanja določa:

Vsa zbrana dokazila morajo biti enolično identificirana, označena in shranjena v varnem repozitoriju z: 5.5.1 Preverjanjem celovitosti, kot so zgoščene vrednosti SHA-256 5.5.2 Časovno označenimi dnevniki dostopa 5.5.3 Vpisi verige skrbništva, ki jih podpiše vsak skrbnik

Politika zbiranja dokazov in forenzike - SME Politika zbiranja dokazov in forenzike - SME v točki 6.1.1 zahtev za izvajanje politike določa:

Vedno mora biti ustvarjena forenzična kopija ali izvoz; izvirnih dokazil se nikoli ne sme neposredno urejati.

V scenariju FinScale to pomeni, da SOC izvozi dnevnike ponudnika identitet, revizijske dnevnike SaaS, zapise dostopa do poštnega predala, zapise soglasja OAuth, zapise preklica sej in opozorila SIEM v repozitorij dokazil z zaščito celovitosti in verigo skrbništva.

Gradnja časovnega načrta ITDR z Zenith Blueprint

Zenith Blueprint kontrolno verigo pretvori v izvedbene korake.

V fazi Kontrole v praksi, korak 19, Tehnološke kontrole I, je Blueprint glede avtentikacije neposreden:

Kjer je mogoče, se je treba izogibati avtentikaciji samo z geslom, zlasti za administratorske račune, konzole v oblaku, orodja za oddaljeni dostop in vse sisteme, izpostavljene internetu. MFA z drugim faktorjem, kot so strojni ključ, mobilna aplikacija ali biometrija, je danes osnovni ukrep, ne razkošje. Zmanjšuje tveganja kraje poverilnic, lažnega predstavljanja in napadov z grobo silo.

Isti korak presega gesla. Zahteva varno hrambo in prenos avtentikacijskih podatkov, varno ravnanje z žetoni API, ID-ji sej in poverilnicami OAuth, upravljanje skrivnosti za avtentikacijo med sistemi, menjavo žetonov, kontrole življenjske dobe sej, varne zastavice piškotkov in pregled dnevnikov avtentikacije.

Korak 22, Organizacijske kontrole, formalizira življenjski cikel dostopov. Ekipe usmerja k povezovanju dodeljevanja in ukinjanja dostopa s kadrovsko službo, izvajanju dokumentiranih četrtletnih pregledov pravic dostopa, opredelitvi vrst identitet, kot so individualni, skupni in storitveni računi, uveljavljanju MFA za privilegirane račune, odpravi mirujočih računov in menjavi storitvenih poverilnic.

Korak 19 zagotavlja tudi pot izboljšanja beleženja: posredovanje kritičnih dnevnikov v SIEM ali združevalnik dnevnikov, preverjanje hrambe, sledenje nedavnemu dogodku z uporabo dnevnikov, dokumentiranje funkcij celovitosti dnevnikov in potrditev opozarjanja pri neuspešnih prijavah ali povišanjih privilegijev. Sinhronizacija časa je pomembna, ker rekonstrukcija incidenta odpove, kadar se dnevniki ponudnika identitet, SaaS, končnih točk in oblaka ne ujemajo v časovnih žigih.

Korak 23, Organizacijske kontrole za 5.19 do 5.37, preverja zmogljivosti upravljanja incidentov. Zahteva posodobljen načrt odzivanja na incidente, opredeljene prijavljive dogodke, namizne vaje, dokumentirane odločitve, zapise komunikacij, pridobljene izkušnje in hrambo forenzičnih dokazov, kot so posnetki dnevnikov, varnostne kopije in varna izolacija.

Pragmatično zaporedje ITDR po Clarysec je naslednje:

1. Opredelite vrste identitet in lastnike.
2. Zavarujte avtentikacijo, žetone in seje.
3. Zbirajte dnevnike avtentikacije, privilegijev in SaaS.
4. Spremljajte tvegano vedenje.
5. Določite pravila za odločanje od dogodka do incidenta.
6. Ohranite dokazila.
7. Poročajte, obnovite in izboljšujte.

Enotedenski dokazni paket ITDR

Osredotočen »dokazni paket za incident identitete« je eden najhitrejših načinov za razkritje vrzeli. Izberite en visoko tvegan scenarij, na primer: »Privilegirani uporabnik SaaS poda soglasje nepooblaščeni aplikaciji OAuth, žeton pa se uporabi za dostop do podatkov strank.«

Nato v enem tednu sestavite dokazni paket.

Vključite vsaj eno dejansko sled. Vzemite neškodljivo nedavno anomalijo pri prijavi in pokažite, kako ekipa preide od opozorila do identitete uporabnika, naprave, izvornega IP-naslova, metode MFA, trajanja seje, dostopanih virov SaaS, dotaknjenih podatkov in odločitve o zajezitvi. Če organizacija te verige ne more rekonstruirati v namizni vaji, bo imela težave med dejanskim incidentom.

Rezultat postane ponovno uporabno dokazilo za notranje presoje ISO/IEC 27001:2022, testiranje procesa IKT-incidentov po DORA, nadzor kibernetske higiene po NIS2 in odgovornost po GDPR.

Mapiranje ITDR na NIS2, DORA in GDPR Article 32

Prednost enotnega modela ITDR je, da ista dokazila izpolnjujejo več obveznosti, pri tem pa še vedno spoštujejo jezik vsakega okvira.

NIS2 Article 21 pričakuje tehnične, operativne in organizacijske ukrepe, ki temeljijo na tveganjih in so sorazmerni. Za ITDR to pomeni nadzor dostopa, upravljanje sredstev, kibernetsko higieno, usposabljanje, obravnavanje incidentov, presojo učinkovitosti kontrol ter MFA ali neprekinjeno avtentikacijo, kadar je to ustrezno. Article 23 uvaja stopenjsko poročanje za pomembne incidente, vključno z zgodnjim opozorilom v 24 urah, obvestilom o incidentu v 72 urah in končnim poročilom v enem mesecu.

DORA Articles 8 do 14 zahtevajo identifikacijo IKT-sredstev in odvisnosti, zaščito in preprečevanje, mehanizme zaznavanja, neprekinjenost in obnovitev, učenje in komunikacijo. Articles 17 do 19 zahtevajo upravljanje incidentov, ugotavljanje temeljnega vzroka, kazalnike zgodnjega opozarjanja, razvrščanje po resnosti in kritičnosti storitve, eskalacijo, obveščanje organa vodenja, poročanje pristojnemu organu in obveščanje strank, kadar so prizadeti finančni interesi.

GDPR zahteva ustrezne tehnične in organizacijske ukrepe ter dokazljivo odgovornost. Pri napadih na identitete vprašanja GDPR vključujejo, ali je prišlo do nepooblaščenega dostopa, kateri osebni podatki so bili vključeni, ali so varovalni ukrepi delovali in ali so sproženi pragovi za obvestilo o kršitvi.

Za fintech podjetja je razmerje med NIS2 in DORA pomembno. DORA se obravnava kot sektorski okvir za finančne subjekte v obsegu, kadar obstajajo prekrivajoče se obveznosti glede IKT-tveganj in poročanja o incidentih. V praksi morajo organizacije vzpostaviti en model dokazil ITDR in odločitve o poročanju mapirati na ustrezno pravno pot.

Za organizacije SaaS, ponudnike oblaka, upravljanih storitev, upravljane varnosti in digitalne platforme je treba obseg NIS2 skrbno preveriti. NIS2 zajema številne sektorje iz Priloge I in Priloge II, vključno z digitalno infrastrukturo, ponudniki storitev računalništva v oblaku, podatkovnimi centri, storitvami zaupanja, DNS, registri TLD, ponudniki upravljanih storitev, ponudniki upravljanih varnostnih storitev, spletnimi tržnicami, iskalniki in platformami družbenih omrežij. Zato opredelitev obsega in analiza zainteresiranih strani po ISO/IEC 27001:2022 točka 4 nista administrativna formalnost. Določata, katere obveznosti mora ISMS obravnavati.

Tveganje dobaviteljev in SaaS pri identitetah

Incidenti identitet so pogosto odvisni od dokazil dobaviteljev. Ali lahko ponudnik SaaS izvozi revizijske dnevnike? Ali prikazuje dogodke soglasja OAuth? Ali podpira varen nadzor dostopa, beleženje in zmogljivosti varstva podatkov? Ali so pomoč pri incidentih, lokacija hrambe podatkov, podizvajanje, pravice dostopa in določila o izstopu pogodbeno urejeni?

Clarysecova Politika uporabe storitev v oblaku - SME Politika uporabe storitev v oblaku - SME vključuje neposredno zahtevo iz točke 5.2.4 zahtev upravljanja:

Storitev zagotavlja varen nadzor dostopa, beleženje in zmogljivosti varstva podatkov

Ta preprost stavek je kontrola nabave. Če platforma SaaS ne more zagotoviti dnevnikov identitet, potrebnih za odziv na incidente, ustvarja tveganje skladnosti.

DORA to izrecno določa prek obveznosti glede tveganj IKT tretjih oseb. Finančni subjekti ostajajo odgovorni za skladnost, vzdrževati morajo registre pogodb o IKT-storitvah, razlikovati med kritičnimi ali pomembnimi funkcijami, izvajati skrbni pregled, ocenjevati tveganje koncentracije, vključiti pravice do revizije in dostopa, opredeliti pomoč pri incidentih ter zagotoviti izstopne strategije.

V Zenith Controls se kontrola ISO/IEC 27001:2022 8.16 Dejavnosti spremljanja povezuje s 5.22 Spremljanje, pregled in upravljanje sprememb storitev dobaviteljev. To odraža operativno realnost. Opozorila ponudnika identitet, revizijski dnevniki SaaS, dejavnost administratorjev v oblaku in računi ponudnikov upravljanih storitev so vsi del površine ITDR.

Kako bodo presojevalci ocenjevali ITDR

Močan program ITDR mora prestati več revizijskih pogledov. Vsaka ciljna skupina postavlja drugačna vprašanja, dokazila pa morajo izhajati iz istega kontrolnega sistema.

Presojevalec ISO/IEC 27001:2022 bo vprašal, ali so grožnje identitetam vključene v oceno tveganja, ali so lastniki tveganj odobrili obravnavo, ali izjava o uporabnosti vključuje ustrezne kontrole Priloge A, ali so politike izvedene in ali dokazila kažejo, da kontrole delujejo. Lahko vzorči privilegirani račun in sledi odobritvi, nastavitvi MFA, dejavnosti v dnevnikih, pregledu pravic dostopa in odvzemu dostopa.

Ocenjevalec NIST CSF 2.0 bo pregledal rezultate GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND in RECOVER. ITDR se naravno prilega profilu, omejenemu na kompromitacijo identitete, zlorabo žetonov SaaS ali neprimerno uporabo privilegiranega dostopa.

Pregledovalec DORA bo iskal odgovornost organa vodenja, poslovne funkcije, podprte z IKT, mehanizme zaznavanja, merila za razvrščanje incidentov, eskalacijo, pravila komunikacije s strankami, analizo temeljnega vzroka in odvisnosti od tretjih oseb na področju IKT.

Pregledovalec GDPR bo vprašal, ali lahko organizacija dokaže ustrezno varnost osebnih podatkov. Pregledal bo omejitve dostopa, zaznavanje nepooblaščenega dostopa, dnevnike, ki kažejo, do katerih podatkov je morda prišlo do dostopa, presojo kršitve in dokazila o odgovornosti.

Presojevalec v slogu COBIT 2019 ali ISACA bo pregledal upravljanje, cilje kontrol, lastništvo, spremljanje uspešnosti in zagotovilo.

Zenith Controls je tu uporaben, ker deluje kot vodnik za navzkrižno skladnost. Ne ustvarja ločenih »kontrol Zenith«. Kontrolna področja ISO/IEC 27001:2022 mapira na povezane kontrole ISO, druge standarde, revizijska pričakovanja in izvedbena razmerja.

Metrike, ki dokazujejo, da ITDR deluje

Upravni odbori in presojevalci ne potrebujejo surovega šuma iz SIEM. Potrebujejo dokazila, da kontrole identitet delujejo in se izboljšujejo. Uporabne metrike ITDR vključujejo:

• Odstotek privilegiranih računov z MFA, odpornim proti lažnemu predstavljanju.
• Število mirujočih računov, starejših od praga v politiki.
• Število storitvenih računov brez lastnika ali datuma menjave.
• Odstotek kritičnih platform SaaS, ki pošiljajo dnevnike avtentikacije v SIEM.
• Povprečni čas do zaznave sumljive dejavnosti identitete.
• Povprečni čas do preklica kompromitiranih sej in žetonov.
• Število aplikacij OAuth, ki so bile odobrene, zavrnjene ali odstranjene.
• Odstotek incidentov identitete s popolnimi dokaznimi paketi.
• Število zapadlih ugotovitev pregledov pravic dostopa.
• Število dobaviteljskih platform brez zahtevanih dnevnikov identitet.

Te metrike morajo napajati vodstveni pregled ISO/IEC 27001:2022, nadzor upravljanja po NIS2, poročanje o IKT-tveganjih po DORA in razprave o odgovornosti po GDPR.

Pogoste revizijske ugotovitve ITDR in odprava

Clarysec pogosto opaža pet ponavljajočih se ugotovitev.

Prvič, organizacije omogočijo MFA, vendar ne spremljajo vedenja MFA. To odpravite z beleženjem sprememb metod MFA, neuspešnih izzivov, geografsko nemogočih prijav, registracije novih naprav in ponavljajočih se potisnih poskusov.

Drugič, storitveni računi so izključeni iz upravljanja identitet. To odpravite s popisom sistemskih računov, dodelitvijo lastnikov, menjavo skrivnosti, odstranjevanjem vdelanih poverilnic in spremljanjem anomalnega vedenja API.

Tretjič, soglasje SaaS ni upravljano. To odpravite z omejitvijo uporabniškega soglasja, pregledom aplikacij OAuth, spremljanjem novih odobritev, dokumentiranjem odobrenih integracij in odstranjevanjem neuporabljenih aplikacij.

Četrtič, dokazila se med preiskavo spremenijo. To odpravite z upoštevanjem pravila Politike zbiranja dokazov in forenzike: ustvarite forenzične kopije ali izvoze, izvirnikov nikoli ne urejajte neposredno in dokazila hranite z zgoščenimi vrednostmi ter zapisi verige skrbništva.

Petič, razvrščanje incidentov je prepočasno. To odpravite z vnaprejšnjo opredelitvijo pragov za dogodke identitet, vključno s kompromitacijo privilegiranega računa, dostopom do osebnih podatkov, zlorabo žetonov SaaS z vplivom na stranke, motnjo kritične storitve in kompromitacijo dobaviteljske identitete.

Vsaka ugotovitev ima kontrolni, politični in dokazni odziv. To je praktična vrednost enotnega programa ITDR: določa, kaj mora imeti lastnika, kaj je treba spremljati, testirati, dokazovati in izboljševati.

Spremenite tveganje identitet v revizijsko pripravljena dokazila

Če bi se vaš naslednji incident identitete zgodil jutri, ali bi lahko dokazali, kdo je dostopal do česa, kako se je avtenticiral, kateri žeton ali seja je bila uporabljena, katerih podatkov se je dotaknil, kdo je odločil o regulativni razvrstitvi in kateri korektivni ukrepi so bili zaključeni?

Če odgovor ni gotov, začnite z osredotočenim sprintom pripravljenosti ITDR.

Uporabite Zenith Blueprint za strukturiranje izvedbene poti prek avtentikacije, življenjskega cikla dostopov, beleženja, spremljanja, odziva na incidente in ravnanja z dokazili. Uporabite Clarysecove politike nadzora dostopa, beleženja, oblaka, odziva na incidente in forenzike za dodelitev lastništva in pooblastil za odziv. Uporabite Zenith Controls za mapiranje upravljanja identitet, varne avtentikacije in dejavnosti spremljanja na ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST CSF 2.0 in revizijska pričakovanja.

Cilj je preprost: napade na identitete narediti zaznavne, zajezljive, prijavljive in zagovorljive.

Clarysec vam lahko pomaga sestaviti dokazni paket ITDR, ga preizkusiti z namiznim scenarijem in ugotovitve pretvoriti v načrt obravnave tveganja, ki ga bodo razumeli vaš upravni odbor, regulator in presojevalec. Začnite s pregledom Politike beleženja in spremljanja, Politike upravljanja uporabniških računov in privilegijev - SME, Zenith Blueprint in Zenith Controls, nato načrtujte presojo pripravljenosti ITDR, da tveganje identitet pretvorite v revizijsko pripravljena dokazila.