ITDR-strateegia ISO 27001, NIS2, DORA ja GDPR jaoks

Teisipäeval kell 3.00 ärkas FinScale’i infoturbejuht Sarah häireteate peale, mida tänapäeva turbejuhid üha enam kardavad. Vanemarendaja aktiivset seanssi, mis oli vaid mõni tund varem MFA abil autenditud, kasutati ebatavalisest allikast tootmisandmebaaside skeemide loendamiseks.

Ei olnud pahavara beacon-signaali. Ei lunavaranõuet. Ei tulemüüri haavatavuse ärakasutamist. Oli ainult identiteet.

SOC tuvastas tegevuse, kuid reageerimine oli ebaühtlane. Kas tegemist oli MFA-st möödahiilimise, varastatud seansitokeni või identiteedipakkuja enda kompromiteerimisega? Kellel oli volitus aktiivne seanss lõpetada? Kas parooli lähtestamisest piisas või pidi meeskond kehtetuks tunnistama värskendustokenid, roteerima API autentimisandmed ja üle vaatama OAuthi õigused? Selleks ajaks, kui tegevus ohjeldati, oli ründaja olnud aktiivne 47 minutit.

Järgmisel hommikul muutus turbeintsident juhtimisprobleemiks. Juhatus soovis lihtsas keeles selgitust, kas FinScale’i küberhügieen oli NIS2 tähenduses läbi kukkunud. Vastavusmeeskond tahtis teada, kas sündmust saab DORA alusel liigitada oluliseks IKT-ga seotud intsidendiks. Õigusosakond vajas kaitstavat vastust küsimusele, kas GDPR Article 32 tähenduses oli isikuandmetele juurde pääsetud ja kas isikuandmetega seotud rikkumise hindamine on nõutav. Välisaudiitor küsis, kas ISO/IEC 27001:2022 kontrollimeetmed toimisid tõhusalt, mitte ei olnud üksnes poliitikates dokumenteeritud.

Sarah’ probleem ei olnud tööriistade puudumine. FinScale’il olid identiteedipakkuja, MFA, SIEM, lõppseadmete kontrollimeetmed, pilvelogid ja intsidentidele reageerimise protsess. Probleem seisnes selles, et identiteedihaldus, logimine, seire, intsidentidele reageerimine, privaatsuse hindamine ja tõendusmaterjali käitlemine toimisid eraldi silodes.

See on 2026. aasta identiteediohtude tuvastamise ja reageerimise probleem. ITDR ei ole enam ainult turbeoperatsioonide võimekus. See on valdkondadeülene vastavuse tõendusmootor ISO/IEC 27001:2022, NIS2, DORA ja GDPR Article 32 jaoks.

Claryseci Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint, poliitikakogu ja Zenith Controls: The Cross-Compliance Guide Zenith Controls aitavad organisatsioonidel muuta identiteediründed kaootilistest uurimistest korratavateks ja auditeeritavateks kontrolliprotsessideks.

Miks identiteediohtude tuvastamine ja reageerimine on nüüd juhatuse tasandi teema

Identiteediründed toimivad, sest need kuritarvitavad õiguspäraseid juurdepääsuteid. Ründaja, kes varastab seansitokeni, registreerib pahatahtliku OAuthi rakenduse, kompromiteerib teenusekonto või mõjutab kasutajat MFA push-väsimuse kaudu, võib süsteemidele näida kehtiva kasutajana, kui süsteemid kontrollivad ainult autentimise õnnestumist.

See eristab ITDR-i traditsioonilisest perimeetrikaitsest. Küps programm peab suutma vastata järgmistele küsimustele:

• Millised inimese, teenuse, tarnija ja rakenduse identiteedid on olemas?
• Millised identiteedid on privilegeeritud, kasutuseta, jagatud või väliselt födereeritud?
• Millised autentimissündmused on tavapärased, riskantsed või võimatud?
• Millised OAuthi õigused, SaaS-i tokenid ja API autentimisandmed saavad juurde pääseda tundlikele andmetele?
• Millised häired käivitavad intsidendi klassifitseerimise, tõendusmaterjali säilitamise ja regulatiivse otsustamise?
• Millised kontrollimeetmed tõendavad, et juurdepääs isikuandmetele on kaitstud asjakohaste tehniliste ja korralduslike meetmetega?

NIS2 muudab selle juhtimisteemaks. Article 20 nõuab, et oluliste ja tähtsate üksuste juhtorganid kiidaksid heaks küberturvalisuse riskijuhtimismeetmed, teeksid järelevalvet nende rakendamise üle ja läbiksid koolituse. Article 21 nõuab asjakohaseid ja proportsionaalseid tehnilisi, operatiivseid ning korralduslikke meetmeid, sealhulgas riskianalüüsi, intsidentide käsitlemist, talitluspidevust, tarneahela turvet, kontrollimeetmete tõhususe hindamist, küberhügieeni, koolitust, juurdepääsukontrolli, varahaldust ning vajaduse korral mitmefaktorilist või pidevat autentimist.

DORA avaldab finantssektori üksustele sarnast survet. See nõuab dokumenteeritud IKT-riski juhtimise raamistikku, juhtorgani vastutust, tuvastusmehhanisme, intsidendihaldust, klassifitseerimist, aruandlust, vastupidavuse testimist ja kolmandate IKT-osapoolte riskijuhtimist. DORA kohaldub alates 17. jaanuarist 2025. Finantsüksuste puhul, kes on hõlmatud ka NIS2-ga, toimib DORA kattuvate IKT-riskide ja intsidendikohustuste sektoripõhise reeglistikuna.

GDPR lisab privaatsuse vastutuse kihi. Article 5 nõuab terviklust, konfidentsiaalsust ja vastutust. Article 4 määratleb isikuandmetega seotud rikkumise laialt, hõlmates ka loata juurdepääsu isikuandmetele. Article 32 nõuab asjakohaseid tehnilisi ja korralduslikke meetmeid, et tagada riskile vastav turvalisuse tase. Identiteediintsidentide korral muutuvad logid, juurdepääsukontrollid, autentimiskirjed ja intsidendi tõendusmaterjal keskseks, et tõendada, kas isikuandmed olid kaitstud.

ISO/IEC 27001:2022 on juhtimissüsteem, mis suudab need kohustused kokku siduda. Punkt 4 nõuab, et organisatsioon mõistaks oma konteksti, huvitatud pooli ning õiguslikke, regulatiivseid ja lepingulisi nõudeid. Punkt 6 nõuab riskihindamist, riskikäsitlust, riskiomaniku heakskiitu ja säilitatavat tõendusmaterjali. Lisa A sisaldab kontrollimeetmeid identiteedihalduse, turvalise autentimise, logimise, seire, intsidendihalduse, tõendite kogumise, tarnijasuhete, pilveteenuste ja privaatsuse kaitse jaoks.

ITDR peab paiknema ISMS-is, sest identiteedirisk muutub auditeeritavaks alles siis, kui see on kohaldamisalasse võetud, omistatud, hinnatud, käsitletud, seiratud ja täiustatud.

Identiteediründe stsenaarium, mis regulaatoreid huvitab

Võtame pilvepõhise finantstöövoo teenusepakkuja, kes teenindab EL-i kliente. Ta kasutab Microsoft 365, klienditoe SaaS-platvormi, pilvetaristut, maksetöötlejat ja mitut API-põhist integratsiooni. Vanemtugitehnik saab veenva viiba tootlikkusrakenduse uuesti ühendamiseks. OAuthi nõusolekuekraan küsib postkasti lugemisõigust ja võrguühenduseta juurdepääsu. Insener kiidab selle heaks.

Mõne minuti jooksul kasutab ründaja tokenit kliendiidentifikaatorite ja tugimanuste otsimiseks. Ta loendab rühmakuuluvusi ja üritab pääseda haldusportaali. MFA oli lubatud, kuid ründaja ei vaja parooli uuesti, sest token annab püsiva juurdepääsu. SOC näeb ebatavalist postkasti juurdepääsu, uut OAuthi rakendust, ebaõnnestunud haldusportaali katseid ja tegevust ebatavalisest geograafilisest asukohast.

See üks stsenaarium läbib mitu kontrollivaldkonda:

• identiteedi elutsükkel, sest kasutaja roll ja õigused määravad mõjuala;
• turvaline autentimine, sest MFA üksi ei takistanud tokeni kuritarvitamist;
• logimine ja seire, sest tuvastamine sõltub identiteedipakkuja, SaaS-i ja rakenduste logidest;
• intsidentidele reageerimine, sest autentimisandmed, seansid, tokenid ja OAuthi õigused tuleb kiiresti tühistada;
• tõendite kogumine, sest järgneda võib isikuandmete avaldumine ja regulatiivne aruandlus;
• tarnija- ja pilvejuhtimine, sest SaaS-i logid ja auditi rakendusliidesed on osa tõendusahelast;
• privaatsuse kaitse, sest isikuandmetele juurdepääsu tuleb hinnata GDPR-i alusel.

Parem küsimus ei ole „Milline tööriist ebaõnnestus?“. Parem küsimus on, kas organisatsioonil oli kavandatud, testitud ja auditeeritav ITDR-i kontrolliahel.

Tõhusa ITDR-i taga olev ISO 27001:2022 kontrolliahel

Kõige tõhusamad ITDR-programmid seovad ennetavad, tuvastavad, korrigeerivad ja tõenduslikud kontrollimeetmed.

Zenith Controlsis käsitletakse ISO/IEC 27001:2022 kontrolli 5.16 Identiteedihaldus ennetava kontrollimeetmena, mis toetab konfidentsiaalsust, terviklust ja käideldavust. See seostub otseselt kontrollidega 5.15 juurdepääsukontroll, 5.17 autentimisteave, 5.18 juurdepääsuõigused, 5.19 infoturve tarnijasuhetes, 5.36 infoturbe poliitikate, reeglite ja standardite järgimine ning 8.2 privilegeeritud juurdepääsuõigused.

See on oluline, sest identiteediohtude tuvastamine ebaõnnestub, kui identiteedijuhtimine on nõrk. Kui teenusekonto on dokumenteerimata, tarnija identiteet on haldamata või privilegeeritud rollil puudub omanik, võib seire sündmuse tuvastada, kuid reageerijad ei suuda seda kiiresti tõlgendada.

Kontroll 8.5 Turvaline autentimine on teine ITDR-i tugipunkt. Zenith Controlsis seostub see identiteedihalduse, autentimisteabe, privilegeeritud juurdepääsuõiguste, teabele juurdepääsu piirangute, seiretegevuste, intsidendihalduse ja PII privaatsuse kaitsega. Autentimine ei lõpe sisselogimisel. Seansihaldus, tokenite käitlemine, autentimisandmete kaitse ja jälgitavus on sama tõendusloo osad.

Kontroll 8.16 Seiretegevused on ühenduslüli logide kogumise ja otsuste tegemise vahel. See sõltub kontrollist 8.15 Logimine ning toetab kontrolle 5.25 infoturbesündmuste hindamine ja otsustamine, 5.26 infoturbeintsidentidele reageerimine ja laiem intsidendihaldus. ITDR-i puhul on 8.16 koht, kus kahtlane identiteedikäitumine muutub triaažitud sündmuseks, väljakuulutatud intsidendiks või dokumenteeritud valepositiivseks tulemuseks.

Tabel ei ole teoreetiline vastendus. See on praktiline tõendusahel, mida audiitor, juhatuse liige või regulaator pärast identiteediintsidenti ootab.

Mida Claryseci poliitikad lisavad: omanikud, käivitajad ja tõendusreeglid

Identiteeditööriistad ei loo automaatselt vastutust. Kriisi ajal vajavad reageerijad volitust seansside tühistamiseks, kontode keelamiseks, logide eksportimiseks, tõendusmaterjali säilitamiseks ja eskaleerimisotsuste tegemiseks. Audiitorid peavad nägema, et neid tegevusi ei improviseeritud.

Claryseci poliitikakogu annab selle töökorralduse.

Ettevõtte kasutajakontode ja õiguste haldamise poliitika kasutajakontode ja õiguste haldamise poliitika juhtimisnõuete punkt 5.9 sätestab:

Organisatsioon peab pidama üksikasjalikku registrit kõigi aktiivsete ja kasutuseta autentimisandmete, privilegeeritud kontode ning süsteemitaseme teenusekontode kohta. Seda registrit tuleb pidevalt ajakohastada ja kord kvartalis läbi vaadata.

See muudab identiteetide registri selgesõnaliseks kontrollikohustuseks. See on eriti oluline, sest teenusekontod, API-võtmed ja kasutuseta autentimisandmed on levinud ITDR-i pimekohad.

Sama poliitika sätestab juhtimisnõuete punktis 5.8:

Kõik haldustegevused ja privilegeeritud kontode toimingud tuleb logida manipuleerimise tuvastamist võimaldaval viisil ning seirata anomaaliate või poliitikarikkumiste suhtes.

See punkt seob privilegeeritud juurdepääsu halduse tuvastamisega. Privilegeeritud toiming ei ole pelgalt lubatud või keelatud. Seda tuleb seirata käitumise suhtes, mis ei sobitu kasutaja, rolli, allika, aja või äriprotsessiga.

Väiksematele organisatsioonidele annab kasutajakontode ja õiguste haldamise poliitika - SME kasutajakontode ja õiguste haldamise poliitika - SME rakendamise ja vastavuse punktis 8.1.1 lühikese ootuse:

IT-valdkonna juht peab regulaarselt üle vaatama süsteemilogid loata juurdepääsukatsete, sisselogimisanomaaliate või heakskiitmata õigustemuudatuste tuvastamiseks.

Siit algavad paljud VKE-de ITDR-programmid. See ei eelda suurt SOC-i. See eeldab nimelist vastutust ja õigete identiteedisignaalide regulaarset läbivaatamist.

Logimispoliitika loob tõendusmaterjali aluse. Logimis- ja seirepoliitika - SME logimis- ja seirepoliitika - SME määratleb juhtimisnõuete punktis 5.4.2:

Autentimislogid: õnnestunud ja ebaõnnestunud sisselogimiskatsed, seansi kestus, MFA kasutus

Need väljad ei ole valikulised. Need aitavad tõendada, kas kahtlane sündmus hõlmas edukat autentimist, korduvaid ebaõnnestumisi, MFA kasutamist, seansi püsivust või ebatavalist kestust.

Ettevõtte logimis- ja seirepoliitika logimis- ja seirepoliitika laiendab nõutavat logide ulatust poliitika rakendamise nõuete punktis 6.1.1:

Kõik hõlmatud süsteemid peavad genereerima logid, mis kajastavad: 6.1.1.1 kasutajate autentimist ja juurdepääsukatseid 6.1.1.2 privilegeeritud kasutajate tegevusi 6.1.1.3 konfiguratsioonimuudatusi 6.1.1.4 ebaõnnestunud juurdepääsukatseid või süsteemisündmusi 6.1.1.5 pahavara tuvastusi ja turbehäireid 6.1.1.6 välissuhtlust ja tulemüürireeglite käivitusi

Konfiguratsioonimuudatused on identiteedirünnete korral eriti olulised. Ründajad lisavad sageli OAuthi õigusi, loovad edasisuunamisreegleid, registreerivad seadmeid, muudavad MFA meetodeid või loovad erakorralisi juurdepääsuteid.

Seejärel annab intsidentidele reageerimise poliitika reageerijatele volituse. Ettevõtte intsidentidele reageerimise poliitika intsidentidele reageerimise poliitika sätestab poliitika rakendamise nõuete punktis 6.2.1:

SOC peab viivitamata isoleerima mõjutatud süsteemid, tühistama kompromiteeritud autentimisandmed või blokeerima pahatahtliku liikluse tulemüüri või lõppseadmete turvatööriistade abil.

VKE-de intsidentidele reageerimise poliitika - SME intsidentidele reageerimise poliitika - SME sätestab rollide ja vastutuste punktis 4.2.2:

Rakendab ohjeldamis- ja taastetegevusi, näiteks keelates juurdepääsu või taastades varukoopiaid.

ITDR-i puhul ei piisa parooli lähtestamisest. Tööjuhised peavad hõlmama kontode keelamist, seansside tühistamist, OAuthi õiguste kehtetuks tunnistamist, saladuste roteerimist, MFA meetodite lähtestamist ja delegeeritud õiguste läbivaatamist.

Tõendusmaterjali käitlemine eristab reageerimist tõendamisest. Ettevõtte tõendite kogumise ja kohtuekspertiisi poliitika tõendite kogumise ja kohtuekspertiisi poliitika sätestab juhtimisnõuete punktis 5.5:

Kõik kogutud tõendusmaterjal tuleb unikaalselt tuvastada, märgistada ja säilitada turvalises hoidlas koos järgmisega: 5.5.1 tervikluse kontroll, näiteks SHA-256 räsiväärtused 5.5.2 ajatemplitega juurdepääsulogid 5.5.3 iga halduri allkirjastatud tõendite käitlemisahela kanded

VKE-de tõendite kogumise ja kohtuekspertiisi poliitika - SME tõendite kogumise ja kohtuekspertiisi poliitika - SME sätestab poliitika rakendamise nõuete punktis 6.1.1:

Alati tuleb luua kohtuekspertiisiline koopia või eksport; algset tõendusmaterjali ei tohi kunagi otse muuta.

FinScale’i stsenaariumis tähendab see, et SOC ekspordib identiteedipakkuja logid, SaaS-i auditilogid, postkasti juurdepääsukirjed, OAuthi nõusolekukirjed, seansi tühistamise kirjed ja SIEM-i häired tõendusmaterjali hoidlasse koos tervikluse kaitse ja tõendite käitlemisahelaga.

ITDR-i teekaardi koostamine Zenith Blueprinti abil

Zenith Blueprint teisendab kontrolliahela rakendussammudeks.

Controls in Action etapis, Step 19, Technological Controls I, on Blueprint autentimise osas otsene:

Võimaluse korral tuleb vältida ainult paroolil põhinevat autentimist, eriti halduskontode, pilvekonsoolide, kaugjuurdepääsu tööriistade ja mis tahes süsteemi puhul, mis on internetile avatud. MFA, kasutades teist faktorit, näiteks riistvaravõtit, mobiilirakendust või biomeetriat, on nüüd baastase, mitte luksus. See maandab autentimisandmete varguse, andmepüügi ja jõurünnete riske.

Sama samm läheb paroolidest kaugemale. See nõuab autentimisandmete turvalist säilitamist ja edastamist, API-tokenite, seansi ID-de ja OAuthi autentimisandmete turvalist käitlemist, saladuste haldust masin-masin autentimiseks, tokenite roteerimist, seansi eluea kontrolli, turvalisi küpsiselippe ja autentimislogide läbivaatamist.

Step 22, Organizational Controls, vormistab juurdepääsu elutsükli. See juhendab meeskondi integreerima juurdepääsuõiguste andmise ja juurdepääsu lõpetamise HR-iga, tegema dokumenteeritud kvartalipõhiseid juurdepääsuõiguste läbivaatamisi, määratlema identiteeditüübid, näiteks individuaalsed, jagatud ja teenusekontod, rakendama MFA-d privilegeeritud kontodele, kõrvaldama kasutuseta kontod ja roteerima teenuse autentimisandmeid.

Step 19 annab ka logimise täiustamise tee: edastada kriitilised logid SIEM-i või logikogujasse, valideerida säilitamine, jälitada hiljutist sündmust logide abil, dokumenteerida logide tervikluse funktsioonid ja kinnitada häired ebaõnnestunud sisselogimiste või õiguste eskaleerimise kohta. Aja sünkroniseerimine on oluline, sest intsidendi rekonstrueerimine ebaõnnestub, kui identiteedipakkuja, SaaS-i, lõppseadme ja pilve logid ei ühti ajatemplite osas.

Step 23, Organizational Controls kontrollidele 5.19 kuni 5.37, valideerib intsidendihalduse võimekust. See nõuab ajakohast intsidentidele reageerimise plaani, määratletud teatamiskohustuslikke sündmusi, lauaõppusi, dokumenteeritud otsuseid, suhtluskirjeid, saadud õppetunde ja kohtuekspertiisilise tõendusmaterjali säilitamist, näiteks logitõmmiseid, varukoopiaid ja turvalist isoleerimist.

Pragmaatiline Claryseci ITDR-järjestus näeb välja järgmine:

1. Määratle identiteeditüübid ja omanikud.
2. Turva autentimine, tokenid ja seansid.
3. Kogu autentimis-, privilegeerimis- ja SaaS-logid.
4. Seira riskantset käitumist.
5. Määra sündmusest intsidendiks liigitamise otsustusreeglid.
6. Säilita tõendusmaterjal.
7. Teavita, taasta ja täiusta.

Ühenädalane ITDR-i tõenduspakett

Fokuseeritud „identiteediintsidendi tõenduspakett“ on üks kiiremaid viise puudujääkide esiletoomiseks. Vali üks kõrge riskiga stsenaarium, näiteks: „Privilegeeritud SaaS-i kasutaja annab nõusoleku autoriseerimata OAuthi rakendusele ja tokenit kasutatakse kliendiandmetele juurdepääsuks.“

Seejärel koosta tõenduspakett ühe nädalaga.

Lisa vähemalt üks tegelik jälg. Võta hiljutine kahjutu sisselogimisanomaalia ja näita, kuidas meeskond liigub häirest kasutaja identiteedi, seadme, lähte-IP, MFA meetodi, seansi kestuse, kasutatud SaaS-i ressursside, puudutatud andmete ja ohjeldamisotsuseni. Kui organisatsioon ei suuda seda ahelat lauaõppusel rekonstrueerida, on tal päris intsidendi ajal raskusi.

Väljundist saab taaskasutatav tõendusmaterjal ISO/IEC 27001:2022 siseauditite, DORA IKT-intsidendiprotsessi testimise, NIS2 küberhügieeni järelevalve ja GDPR vastutuse jaoks.

ITDR-i vastendamine NIS2, DORA ja GDPR Article 32 nõuetega

Ühtse ITDR-mudeli tugevus seisneb selles, et sama tõendusmaterjal täidab mitu kohustust, austades samal ajal iga raamistiku keelekasutust.

NIS2 Article 21 eeldab riskipõhiseid ja proportsionaalseid tehnilisi, operatiivseid ning korralduslikke meetmeid. ITDR-i puhul tähendab see juurdepääsukontrolli, varahaldust, küberhügieeni, koolitust, intsidentide käsitlemist, kontrollimeetmete tõhususe hindamist ning vajaduse korral MFA-d või pidevat autentimist. Article 23 loob oluliste intsidentide etapilise aruandluse, sealhulgas varajase hoiatuse 24 tunni jooksul, intsidenditeavituse 72 tunni jooksul ja lõpparuande ühe kuu jooksul.

DORA Articles 8 to 14 nõuavad IKT-varade ja sõltuvuste tuvastamist, kaitset ja ennetust, tuvastusmehhanisme, talitluspidevust ja taastet, õppimist ja teabevahetust. Articles 17 to 19 nõuavad intsidendihaldust, algpõhjuse tuvastamist, varajasi hoiatusindikaatoreid, klassifitseerimist tõsiduse ja teenuse kriitilisuse alusel, eskaleerimist, juhtorgani teavitamist, pädevale asutusele aruandlust ja kliendi teavitamist, kui mõjutatud on finantshuvid.

GDPR nõuab asjakohaseid tehnilisi ja korralduslikke meetmeid ning tõendatavat vastutust. Identiteedirünnete korral hõlmavad GDPR-i küsimused seda, kas toimus loata juurdepääs, millised isikuandmed olid kaasatud, kas kaitsemeetmed toimisid ja kas rikkumisest teatamise künnised on täidetud.

Fintech-ettevõtete puhul on NIS2 ja DORA suhe oluline. DORA-t käsitatakse sektoripõhise raamistikuna kohaldamisalasse kuuluvate finantsüksuste jaoks, kui kattuvad IKT-riskide ja intsidenditeavituse kohustused. Praktikas peaksid organisatsioonid looma ühe ITDR-i tõendusmudeli ja vastendama aruandlusotsused kohaldatava õigusliku teega.

SaaS-i, pilve-, hallatud teenuste, hallatud turbe ja digiplatvormide organisatsioonide puhul tuleb NIS2 kohaldamisala hoolikalt kontrollida. NIS2 hõlmab paljusid I ja II lisa sektoreid, sealhulgas digitaristut, pilveteenuse pakkujaid, andmekeskusi, usaldusteenuseid, DNS-i, TLD registreid, hallatud teenusepakkujaid, hallatud turvateenuse pakkujaid, veebipõhiseid kauplemiskohti, otsingumootoreid ja sotsiaalvõrgustike platvorme. Seetõttu ei ole ISO/IEC 27001:2022 punkti 4 kohaldamisala ja huvitatud poolte analüüs pelgalt paberitöö. Need määravad, milliseid kohustusi ISMS peab käsitlema.

Tarnija ja SaaS-i identiteedirisk

Identiteediintsidendid sõltuvad sageli tarnija tõendusmaterjalist. Kas SaaS-i teenusepakkuja saab eksportida auditilogisid? Kas see näitab OAuthi nõusolekusündmusi? Kas see toetab turvalisi juurdepääsukontrolle, logimist ja andmekaitset? Kas intsidendiabi, andmete asukoht, alltöövõtt, juurdepääsuõigused ja väljumissätted on lepinguliselt kaetud?

Claryseci pilveteenuste kasutamise poliitika - SME pilveteenuste kasutamise poliitika - SME sisaldab juhtimisnõuete punktis 5.2.4 otsest nõuet:

Teenus pakub turvalise juurdepääsukontrolli, logimise ja andmekaitse võimekust

See lihtne lause on hankekontroll. Kui SaaS-platvorm ei suuda toota identiteedilogisid, mida on vaja intsidentidele reageerimiseks, tekitab see vastavusriski.

DORA teeb selle selgesõnaliseks kolmandate IKT-osapoolte riskikohustuste kaudu. Finantsüksused jäävad vastavuse eest vastutavaks, peavad pidama IKT-teenuste lepingute registreid, eristama kriitilisi või olulisi funktsioone, tegema taustakontrolli, hindama kontsentratsiooniriski, lisama auditi- ja juurdepääsuõigused, määratlema intsidendiabi ning tagama väljumisstrateegiad.

Zenith Controlsis seostub ISO/IEC 27001:2022 kontroll 8.16 Seiretegevused kontrolliga 5.22 tarnijate teenuste seire, läbivaatamine ja muudatuste juhtimine. See peegeldab operatiivset tegelikkust. Identiteedipakkuja häired, SaaS-i auditilogid, pilveadministraatori tegevus ja hallatud teenusepakkuja kontod moodustavad kõik osa ITDR-i pinnast.

Kuidas audiitorid ITDR-i hindavad

Tugev ITDR-programm peab taluma mitut auditi vaatenurka. Iga sihtrühm küsib erinevaid küsimusi, kuid tõendusmaterjal peaks tulema samast kontrollisüsteemist.

ISO/IEC 27001:2022 audiitor küsib, kas identiteediohud sisalduvad riskihindamises, kas riskiomanikud on riskikäsitluse heaks kiitnud, kas kohaldatavusdeklaratsioon sisaldab asjakohaseid lisa A kontrolle, kas poliitikad on rakendatud ja kas tõendusmaterjal näitab kontrollimeetmete toimimist. Ta võib võtta valimisse privilegeeritud konto ja jälgida heakskiitu, MFA seadet, logitegevust, juurdepääsuõiguste läbivaatamist ja juurdepääsu lõpetamist.

NIST CSF 2.0 hindaja vaatab GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND ja RECOVER tulemusi. ITDR sobitub loomulikult profiili, mille ulatus on identiteedi kompromiteerimine, SaaS-i tokenite kuritarvitamine või privilegeeritud juurdepääsu väärkasutus.

DORA kontrollija otsib juhtorgani vastutust, IKT-toega ärifunktsioone, tuvastusmehhanisme, intsidendi klassifitseerimise kriteeriume, eskaleerimist, kliendisuhtluse reegleid, algpõhjuse analüüsi ja kolmandate IKT-osapoolte sõltuvusi.

GDPR-i läbivaataja küsib, kas organisatsioon suudab tõendada isikuandmete asjakohast turvalisust. Ta uurib juurdepääsu piiranguid, loata juurdepääsu tuvastamist, logisid, mis näitavad, millistele andmetele võidi juurde pääseda, rikkumise hindamist ja vastutuse tõendusmaterjali.

COBIT 2019 või ISACA-stiilis audiitor uurib juhtimist, kontrollieesmärke, omanikke, toimivuse seiret ja kindlustandvaid tegevusi.

Zenith Controls on siin kasulik, sest see toimib valdkondadeülese vastavuse juhendina. See ei loo eraldi „Zenith-kontrolle“. See vastendab ISO/IEC 27001:2022 kontrollivaldkonnad seotud ISO kontrollide, muude standardite, auditi ootuste ja rakendussuhetega.

Mõõdikud, mis tõendavad ITDR-i toimimist

Juhatus ja audiitorid ei vaja toorest SIEM-i müra. Nad vajavad tõendusmaterjali, et identiteedikontrollid toimivad ja paranevad. Kasulikud ITDR-i mõõdikud on muu hulgas:

• andmepüügikindla MFA-ga privilegeeritud kontode osakaal;
• poliitika lävendist vanemate kasutuseta kontode arv;
• teenusekontode arv, millel puudub omanik või roteerimiskuupäev;
• kriitiliste SaaS-platvormide osakaal, mis saadavad autentimislogid SIEM-i;
• keskmine aeg kahtlase identiteeditegevuse tuvastamiseks;
• keskmine aeg kompromiteeritud seansside ja tokenite tühistamiseks;
• heakskiidetud, tagasi lükatud või eemaldatud OAuthi rakenduste arv;
• täieliku tõenduspaketiga identiteediintsidentide osakaal;
• tähtaja ületanud juurdepääsuõiguste läbivaatamise leidude arv;
• nõutavate identiteedilogideta tarnijaplatvormide arv.

Need mõõdikud peaksid toetama ISO/IEC 27001:2022 juhtkonnapoolset läbivaatust, NIS2 juhtimisjärelevalvet, DORA IKT-riskide aruandlust ja GDPR vastutuse arutelusid.

Levinud ITDR-i auditileiud ja parandused

Clarysec näeb sageli viit korduvat leidu.

Esiteks lubavad organisatsioonid MFA, kuid ei seira MFA käitumist. Parandus on logida MFA meetodi muudatused, ebaõnnestunud väljakutsed, võimatu asukohavahetus, uue seadme registreerimine ja korduvad push-katsed.

Teiseks jäetakse teenusekontod identiteedijuhtimisest välja. Parandus on inventeerida süsteemitaseme kontod, määrata omanikud, roteerida saladusi, eemaldada manustatud autentimisandmed ja seirata anomaalset API-käitumist.

Kolmandaks on SaaS-i nõusolek haldamata. Parandus on piirata kasutaja nõusolekut, vaadata üle OAuthi rakendused, seirata uusi õigusi, dokumenteerida heakskiidetud integratsioonid ja eemaldada kasutamata rakendused.

Neljandaks muudetakse tõendusmaterjali uurimise käigus. Parandus on järgida tõendite kogumise ja kohtuekspertiisi poliitika reeglit: luua kohtuekspertiisilised koopiad või ekspordid, mitte kunagi muuta originaale otse ning säilitada tõendusmaterjal koos räside ja tõendite käitlemisahela kirjetega.

Viiendaks on intsidendi klassifitseerimine liiga aeglane. Parandus on eelnevalt määratleda identiteedisündmuste lävendid, sealhulgas privilegeeritud konto kompromiteerimine, isikuandmetele juurdepääs, klienti mõjutav SaaS-i tokeni kuritarvitamine, kriitilise teenuse katkestus ja tarnija identiteedi kompromiteerimine.

Igal leiul on kontrollimeede, poliitika ja tõendusmaterjali vastus. See on ühtse ITDR-programmi praktiline väärtus: see määratleb, millel peab olema omanik, mida tuleb seirata, testida, tõendada ja täiustada.

Muuda identiteedirisk auditiks valmis tõendusmaterjaliks

Kui sinu järgmine identiteediintsident juhtuks homme, kas suudaksid tõendada, kes millele juurde pääses, kuidas ta autenditi, millist tokenit või seanssi kasutati, milliseid andmeid puudutati, kes otsustas regulatiivse klassifikatsiooni ja millised parandusmeetmed lõpetati?

Kui vastus on ebakindel, alusta fokuseeritud ITDR-i valmisoleku sprindiga.

Kasuta Zenith Blueprinti, et struktureerida rakendustee autentimise, juurdepääsu elutsükli, logimise, seire, intsidentidele reageerimise ja tõendusmaterjali käitlemise lõikes. Kasuta Claryseci juurdepääsukontrolli, logimise, pilve, intsidentidele reageerimise ja kohtuekspertiisi poliitikaid, et määrata omanikud ja reageerimisvolitused. Kasuta Zenith Controlsi, et vastendada identiteedihaldus, turvaline autentimine ja seiretegevused ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST CSF 2.0 ning auditi ootustega.

Eesmärk on lihtne: muuta identiteediründed tuvastatavaks, ohjeldatavaks, teatatavaks ja kaitstavaks.

Clarysec saab aidata luua ITDR-i tõenduspaketi, testida seda lauaõppuse stsenaariumis ja teisendada leiud riskikäsitlusplaaniks, millest sinu juhatus, regulaator ja audiitor aru saavad. Alusta logimis- ja seirepoliitika, kasutajakontode ja õiguste haldamise poliitika - SME, Zenith Blueprinti ja Zenith Controlsi läbivaatamisest ning planeeri seejärel ITDR-i valmisoleku hindamine, et muuta identiteedirisk auditiks valmis tõendusmaterjaliks.