Stratégia ITDR pre ISO 27001, NIS2, DORA a GDPR

V utorok o 3:00 ráno sa Sarah, CISO spoločnosti FinScale, zobudila na typ upozornenia, ktorého sa moderní bezpečnostní lídri obávajú čoraz viac. Aktívna relácia seniorného vývojára, autentifikovaná pomocou MFA len niekoľko hodín predtým, sa používala z neobvyklého zdroja na enumeráciu schém produkčných databáz.

Nebolo viditeľné žiadne malvérové spojenie. Žiadna ransomvérová správa. Žiadny exploit firewallu. Iba identita.

SOC aktivitu zachytilo, ale reakcia bola neprehľadná. Išlo o obídenie MFA, odcudzený token relácie alebo kompromitáciu samotného poskytovateľa identít? Kto mal právomoc ukončiť aktívnu reláciu? Stačilo resetovať heslo, alebo tím musel zneplatniť obnovovacie tokeny, rotovať prihlasovacie údaje API a preskúmať oprávnenia OAuth? Kým sa podarilo aktivitu zamedziť, útočník bol aktívny 47 minút.

Nasledujúce ráno sa bezpečnostný incident zmenil na problém správy a riadenia. Členovia predstavenstva chceli zrozumiteľné vysvetlenie, či zlyhala kybernetická hygiena spoločnosti FinScale podľa NIS2. Tím pre súlad chcel vedieť, či možno udalosť klasifikovať ako významný incident súvisiaci s IKT podľa DORA. Právne oddelenie potrebovalo obhájiteľnú odpoveď, či došlo k prístupu k osobným údajom podľa GDPR Article 32 a či je potrebné posúdenie porušenia ochrany osobných údajov. Externý audítor sa pýtal, či kontroly ISO/IEC 27001:2022 fungovali účinne, nielen či boli zdokumentované v politikách.

Sarahin problém nebol nedostatok nástrojov. FinScale mala poskytovateľa identít, MFA, SIEM, ochranu koncových bodov, cloudové logy a proces reakcie na incidenty. Problém bol v tom, že správa identít, logovanie, monitorovanie, reakcia na incidenty, posúdenie ochrany súkromia a nakladanie s dôkazmi fungovali v oddelených silách.

Toto je problém Identity Threat Detection and Response v roku 2026. ITDR už nie je len schopnosť bezpečnostnej prevádzky. Je to dôkazový mechanizmus pre súlad s viacerými rámcami naprieč ISO/IEC 27001:2022, NIS2, DORA a GDPR Article 32.

Zenith Blueprint: 30-kroková cestovná mapa audítora od Clarysec Zenith Blueprint, súbor politík a Zenith Controls: Sprievodca viacnásobným súladom Zenith Controls pomáhajú organizáciám premeniť útoky na identity z chaotických vyšetrovaní na opakovateľné kontrolné procesy pripravené na audit.

Prečo je Identity Threat Detection and Response témou na úrovni predstavenstva

Útoky na identity fungujú preto, že zneužívajú legitímne prístupové cesty. Útočník, ktorý odcudzí token relácie, zaregistruje škodlivú aplikáciu OAuth, kompromituje servisný účet alebo presvedčí používateľa prostredníctvom únavy z push notifikácií MFA, môže pre systémy, ktoré kontrolujú iba úspešnosť autentifikácie, vyzerať ako platný používateľ.

Tým sa ITDR líši od tradičnej ochrany perimetra. Zrelý program musí vedieť odpovedať na tieto otázky:

• Aké ľudské, servisné, dodávateľské a aplikačné identity existujú?
• Ktoré identity sú privilegované, neaktívne, zdieľané alebo externe federované?
• Ktoré autentifikačné udalosti sú bežné, rizikové alebo nemožné?
• Ktoré oprávnenia OAuth, tokeny SaaS a prihlasovacie údaje API môžu pristupovať k citlivým údajom?
• Ktoré upozornenia spúšťajú klasifikáciu incidentu, uchovanie dôkazov a regulačné rozhodovanie?
• Ktoré kontroly preukazujú, že prístup k osobným údajom je chránený primeranými technickými a organizačnými opatreniami?

NIS2 z toho robí otázku správy a riadenia. Article 20 vyžaduje, aby riadiace orgány základných a dôležitých subjektov schvaľovali opatrenia riadenia kybernetických rizík, dohliadali na ich implementáciu a absolvovali školenie. Article 21 vyžaduje primerané a proporcionálne technické, prevádzkové a organizačné opatrenia vrátane analýzy rizík, riešenia incidentov, kontinuity činností, bezpečnosti dodávateľského reťazca, posudzovania účinnosti kontrol, kybernetickej hygieny, školenia, riadenia prístupu, správy aktív a viacfaktorovej alebo priebežnej autentifikácie tam, kde je to vhodné.

DORA vytvára podobný tlak na finančné subjekty. Vyžaduje zdokumentovaný rámec riadenia rizík IKT, zodpovednosť riadiaceho orgánu, detekčné mechanizmy, riadenie incidentov, klasifikáciu, oznamovanie, testovanie odolnosti a riadenie rizík externých poskytovateľov IKT. DORA sa uplatňuje od 17. januára 2025. Pre finančné subjekty, ktoré sú zároveň identifikované podľa NIS2, predstavuje DORA odvetvovo špecifický súbor pravidiel pre prekrývajúce sa povinnosti v oblasti rizík IKT a incidentov.

GDPR pridáva vrstvu zodpovednosti za ochranu súkromia. Article 5 vyžaduje integritu, dôvernosť a zodpovednosť za konanie. Article 4 definuje porušenie ochrany osobných údajov široko vrátane neoprávneného prístupu k osobným údajom. Article 32 vyžaduje primerané technické a organizačné opatrenia na zabezpečenie úrovne bezpečnosti zodpovedajúcej riziku. Pri incidentoch identít sa logy, riadenie prístupu, autentifikačné záznamy a dôkazy o incidente stávajú kľúčovými pre preukázanie, či boli osobné údaje chránené.

ISO/IEC 27001:2022 je systém manažérstva, ktorý dokáže tieto povinnosti udržať pohromade. Kapitola 4 vyžaduje, aby organizácia porozumela svojmu kontextu, zainteresovaným stranám a právnym, regulačným a zmluvným požiadavkám. Kapitola 6 vyžaduje posúdenie rizík, ošetrenie rizík, schválenie vlastníkom rizika a uchovávané dôkazy. Príloha A obsahuje kontroly pre správu identít, bezpečnú autentifikáciu, logovanie, monitorovanie, riadenie incidentov, zber dôkazov, vzťahy s dodávateľmi, cloudové služby a ochranu súkromia.

ITDR patrí do ISMS, pretože riziko identít sa stáva auditovateľným až vtedy, keď je v rozsahu, má vlastníka, je posúdené, ošetrené, monitorované a zlepšované.

Scenár útoku na identity, ktorý zaujíma regulátorov

Predstavte si poskytovateľa cloudového finančného workflow pre zákazníkov v EÚ. Používa Microsoft 365, zákaznícku podporu na platforme SaaS, cloudovú infraštruktúru, spracovateľa platieb a niekoľko integrácií založených na API. Seniorný inžinier podpory dostane presvedčivú výzvu na opätovné pripojenie produkčnej aplikácie. Obrazovka súhlasu OAuth požaduje prístup na čítanie poštovej schránky a offline prístup. Inžinier súhlas schváli.

V priebehu niekoľkých minút útočník použije token na vyhľadávanie identifikátorov zákazníkov a príloh podpory. Enumeruje členstvá v skupinách a pokúša sa o prístup do administrátorského portálu. MFA bola zapnutá, ale útočník už heslo nepotrebuje, pretože token poskytuje trvalý prístup. SOC vidí neobvyklý prístup k poštovej schránke, novú aplikáciu OAuth, neúspešné pokusy o prístup do administrátorského portálu a aktivitu z neobvyklej geografickej lokality.

Tento jediný scenár prechádza viacerými oblasťami kontrol:

• Životný cyklus identít, pretože rola a oprávnenia používateľa určujú rozsah možného dopadu.
• Bezpečná autentifikácia, pretože samotná MFA nezabránila zneužitiu tokenu.
• Logovanie a monitorovanie, pretože detekcia závisí od logov poskytovateľa identít, SaaS a aplikácií.
• Reakcia na incidenty, pretože prihlasovacie údaje, relácie, tokeny a oprávnenia OAuth musia byť rýchlo zrušené.
• Zber dôkazov, pretože môže nasledovať sprístupnenie osobných údajov a regulačné oznamovanie.
• Správa a riadenie dodávateľov a cloudu, pretože logy SaaS a auditné API sú súčasťou dôkazového reťazca.
• Ochrana súkromia, pretože prístup k osobným údajom sa musí posúdiť podľa GDPR.

Lepšia otázka neznie: „Ktorý nástroj zlyhal?“ Lepšia otázka znie, či organizácia mala navrhnutý, otestovaný a auditovateľný kontrolný reťazec ITDR.

Kontrolný reťazec ISO 27001:2022 za účinným ITDR

Najúčinnejšie programy ITDR prepájajú preventívne, detekčné, nápravné a dôkazové kontroly.

V Zenith Controls sa kontrola ISO/IEC 27001:2022 5.16 Správa identít považuje za preventívnu kontrolu podporujúcu dôvernosť, integritu a dostupnosť. Priamo sa prepája s 5.15 Riadenie prístupu, 5.17 Autentifikačné informácie, 5.18 Prístupové práva, 5.19 Informačná bezpečnosť vo vzťahoch s dodávateľmi, 5.36 Súlad s politikami, pravidlami a normami informačnej bezpečnosti a 8.2 Privilegované prístupové práva.

Je to dôležité, pretože detekcia identít zlyháva, keď je správa a riadenie identít slabé. Ak servisný účet nie je zdokumentovaný, dodávateľská identita nie je spravovaná alebo privilegovaná rola nemá vlastníka, monitorovanie môže udalosť detegovať, ale pracovníci reakcie ju nedokážu rýchlo interpretovať.

Kontrola 8.5 Bezpečná autentifikácia je ďalšou oporou ITDR. V Zenith Controls sa prepája so správou identít, autentifikačnými informáciami, privilegovanými prístupovými právami, obmedzením prístupu k informáciám, monitorovacími aktivitami, riadením incidentov a ochranou súkromia PII. Autentifikácia sa nekončí prihlásením. Riadenie relácií, nakladanie s tokenmi, ochrana prihlasovacích údajov a sledovateľnosť sú súčasťou toho istého dôkazového príbehu.

Kontrola 8.16 Monitorovacie aktivity je spojovacím prvkom medzi zberom logov a rozhodovaním. Závisí od 8.15 Logovanie a podporuje 5.25 Posúdenie a rozhodnutie o udalostiach informačnej bezpečnosti, 5.26 Reakcia na incidenty informačnej bezpečnosti a širšie riadenie incidentov. Pri ITDR je 8.16 miestom, kde sa podozrivé správanie identity mení na vytriedenú udalosť, vyhlásený incident alebo zdokumentovaný falošne pozitívny nález.

Tabuľka nie je teoretické mapovanie. Je to praktický dôkazový reťazec, ktorý bude audítor, člen predstavenstva alebo regulátor očakávať po incidente identít.

Čo pridávajú politiky Clarysec: vlastníctvo, spúšťače a pravidlá dôkazov

Nástroje pre identity automaticky nevytvárajú zodpovednosť za konanie. Počas krízy potrebujú pracovníci reakcie právomoc rušiť relácie, deaktivovať účty, exportovať logy, uchovať dôkazy a prijímať rozhodnutia o eskalácii. Audítori potrebujú vidieť, že tieto činnosti neboli improvizované.

Súbor politík Clarysec poskytuje tento prevádzkový model.

Z podnikovej Politiky správy používateľských účtov a oprávnení Politika správy používateľských účtov a oprávnení, kapitola Požiadavky na správu a riadenie, bod 5.9 uvádza:

Organizácia musí udržiavať podrobný inventár všetkých aktívnych a neaktívnych prihlasovacích údajov, privilegovaných účtov a servisných účtov na úrovni systému. Tento inventár sa musí priebežne aktualizovať a štvrťročne preskúmavať.

Tým sa inventár identít mení na výslovnú kontrolnú povinnosť. Je to obzvlášť dôležité, pretože servisné účty, kľúče API a neaktívne poverenia patria medzi bežné slepé miesta ITDR.

Tá istá politika uvádza v kapitole Požiadavky na správu a riadenie, bod 5.8:

Všetky administrátorské aktivity a činnosti privilegovaných účtov musia byť logované spôsobom chráneným proti neoprávnenej zmene a monitorované z hľadiska anomálií alebo porušení politiky.

Tento bod prepája správu privilegovaných prístupov s detekciou. Privilegovaná činnosť nie je iba povolená alebo zamietnutá. Musí sa monitorovať vzhľadom na správanie, ktoré nezodpovedá používateľovi, role, zdroju, času alebo obchodnému procesu.

Pre menšie organizácie Politika správy používateľských účtov a oprávnení - SME Politika správy používateľských účtov a oprávnení - SME stanovuje stručné očakávanie v kapitole Uplatňovanie politiky a súlad, bod 8.1.1:

IT Lead musí pravidelne preskúmavať systémové logy z hľadiska pokusov o neoprávnený prístup, anomálií prihlásenia alebo neschválených zmien oprávnení.

Tu sa začína mnoho programov ITDR v prostredí MSP. Nevyžaduje si veľké SOC. Vyžaduje si určené vlastníctvo a pravidelné preskúmanie správnych signálov identity.

Politika logovania poskytuje dôkazový základ. Politika logovania a monitorovania - SME Politika logovania a monitorovania - SME špecifikuje v kapitole Požiadavky na správu a riadenie, bod 5.4.2:

Autentifikačné logy: úspešné a neúspešné pokusy o prihlásenie, trvanie relácie, použitie MFA

Tieto polia nie sú voliteľné. Pomáhajú preukázať, či podozrivá udalosť zahŕňala úspešnú autentifikáciu, opakované zlyhania, použitie MFA, pretrvávanie relácie alebo neobvyklé trvanie.

Podniková Politika logovania a monitorovania Politika logovania a monitorovania rozširuje požadovaný rozsah logov v kapitole Požiadavky na implementáciu politiky, bod 6.1.1:

Všetky zahrnuté systémy musia vytvárať logy zachytávajúce: 6.1.1.1 Autentifikáciu používateľov a pokusy o prístup 6.1.1.2 Aktivity privilegovaných používateľov 6.1.1.3 Zmeny konfigurácie 6.1.1.4 Neúspešné pokusy o prístup alebo systémové udalosti 6.1.1.5 Detekcie malvéru a bezpečnostné upozornenia 6.1.1.6 Externú komunikáciu a spúšťače pravidiel firewallu

Zmeny konfigurácie sú pri útokoch na identity mimoriadne dôležité. Útočníci často pridávajú oprávnenia OAuth, vytvárajú pravidlá preposielania, registrujú zariadenia, upravujú metódy MFA alebo vytvárajú núdzové prístupové cesty.

Politika reakcie na incidenty následne dáva pracovníkom reakcie právomoc konať. Podniková Politika reakcie na incidenty Politika reakcie na incidenty uvádza v kapitole Požiadavky na implementáciu politiky, bod 6.2.1:

SOC musí okamžite izolovať dotknuté systémy, zrušiť kompromitované prihlasovacie údaje alebo blokovať škodlivú prevádzku pomocou firewallu alebo nástrojov zabezpečenia koncových bodov.

Politika reakcie na incidenty - SME Politika reakcie na incidenty - SME uvádza v kapitole Roly a zodpovednosti, bod 4.2.2:

Implementuje opatrenia na zamedzenie šírenia a obnovu, napríklad deaktiváciou prístupu alebo obnovením záloh.

Pri ITDR nestačí resetovať heslo. Prevádzkové príručky obnovy musia zahŕňať deaktiváciu účtov, rušenie relácií, zneplatňovanie oprávnení OAuth, rotáciu tajomstiev, resetovanie metód MFA a preskúmanie delegovaných oprávnení.

Nakladanie s dôkazmi je rozdiel medzi reakciou a preukázaním. Podniková Politika zberu dôkazov a forenznej analýzy Politika zberu dôkazov a forenznej analýzy uvádza v kapitole Požiadavky na správu a riadenie, bod 5.5:

Všetky zhromaždené dôkazy musia byť jednoznačne identifikované, označené a uložené v zabezpečenom repozitári s: 5.5.1 Overením integrity, napríklad hash hodnotami SHA-256 5.5.2 Prístupovými logmi s časovou pečiatkou 5.5.3 Záznamami reťazca zverenia podpísanými každým správcom

Politika zberu dôkazov a forenznej analýzy - SME Politika zberu dôkazov a forenznej analýzy - SME uvádza v kapitole Požiadavky na implementáciu politiky, bod 6.1.1:

Vždy musí byť vytvorená forenzná kópia alebo export; pôvodný dôkaz sa nikdy nesmie upravovať priamo.

V scenári FinScale to znamená, že SOC exportuje logy poskytovateľa identít, auditné logy SaaS, záznamy prístupu k poštovej schránke, záznamy súhlasu OAuth, záznamy o zrušení relácie a upozornenia SIEM do úložiska dôkazov s ochranou integrity a reťazcom zverenia.

Budovanie cestovnej mapy ITDR pomocou Zenith Blueprint

Zenith Blueprint prevádza kontrolný reťazec na implementačné kroky.

Vo fáze Controls in Action, krok 19, Technologické kontrolné opatrenia I, je Blueprint pri autentifikácii priamy:

Tam, kde je to možné, autentifikácii iba heslom sa treba vyhnúť, najmä pri administrátorských účtoch, cloudových konzolách, nástrojoch vzdialeného prístupu a každom systéme vystavenom internetu. MFA s použitím druhého faktora, ako je hardvérový kľúč, mobilná aplikácia alebo biometrické zabezpečenie, je dnes základom, nie nadštandardom. Zmierňuje riziká odcudzenia prihlasovacích údajov, phishingu a brute force útokov.

Ten istý krok ide nad rámec hesiel. Vyžaduje bezpečné uchovávanie a prenos autentifikačných údajov, bezpečné nakladanie s tokenmi API, identifikátormi relácií a povereniami OAuth, správu tajomstiev pre autentifikáciu medzi strojmi, rotáciu tokenov, kontroly životnosti relácií, bezpečné príznaky cookies a preskúmanie autentifikačných logov.

Krok 22, Organizačné opatrenia, formalizuje životný cyklus prístupov. Vedie tímy k integrácii zriaďovania prístupu a odoberania prístupových práv s HR, vykonávaniu zdokumentovaných štvrťročných revízií prístupových práv, definovaniu typov identít, ako sú individuálne, zdieľané a servisné účty, vynucovaniu MFA pre privilegované účty, odstraňovaniu neaktívnych účtov a rotácii servisných poverení.

Krok 19 poskytuje aj cestu zlepšovania logovania: odosielať kritické logy do SIEM alebo zberača logov, validovať uchovávanie, vysledovať nedávnu udalosť pomocou logov, zdokumentovať funkcie integrity logov a potvrdiť upozorňovanie na neúspešné prihlásenia alebo eskalácie oprávnení. Synchronizácia času je dôležitá, pretože rekonštrukcia incidentu zlyháva, keď sa logy poskytovateľa identít, SaaS, koncových bodov a cloudu nezhodujú v časových pečiatkach.

Krok 23, Organizačné opatrenia pre 5.19 až 5.37, validuje schopnosti riadenia incidentov. Vyžaduje aktuálny plán reakcie na incidenty, definované udalosti podliehajúce hláseniu, stolové cvičenia, zdokumentované rozhodnutia, komunikačné záznamy, získané poznatky a uchovanie forenzných dôkazov, ako sú snapshoty logov, zálohy a bezpečná izolácia.

Pragmatická postupnosť ITDR podľa Clarysec vyzerá takto:

1. Definovať typy identít a vlastníkov.
2. Zabezpečiť autentifikáciu, tokeny a relácie.
3. Zhromažďovať autentifikačné, privilegované a SaaS logy.
4. Monitorovať rizikové správanie.
5. Definovať pravidlá rozhodovania od udalosti k incidentu.
6. Uchovať dôkazy.
7. Oznámiť, obnoviť a zlepšiť.

Týždenný balík dôkazov ITDR

Cielený „balík dôkazov k incidentu identity“ je jedným z najrýchlejších spôsobov, ako odhaliť medzery. Vyberte jeden vysokorizikový scenár, napríklad: „Privilegovaný používateľ SaaS udelí súhlas neoprávnenej aplikácii OAuth a token sa použije na prístup k údajom zákazníkov.“

Potom balík dôkazov vytvorte za jeden týždeň.

Zahrňte aspoň jednu skutočnú stopu. Vezmite neškodnú nedávnu anomáliu prihlásenia a ukážte, ako tím postupuje od upozornenia k identite používateľa, zariadeniu, zdrojovej IP adrese, metóde MFA, trvaniu relácie, prístupným zdrojom SaaS, dotknutým údajom a rozhodnutiu o zamedzení šírenia. Ak organizácia nedokáže tento reťazec zrekonštruovať počas stolového cvičenia, bude mať problém počas skutočného incidentu.

Výstup sa stáva opätovne použiteľným dôkazom pre interné audity ISO/IEC 27001:2022, testovanie procesu incidentov IKT podľa DORA, dohľad nad kybernetickou hygienou podľa NIS2 a zodpovednosť podľa GDPR.

Mapovanie ITDR na NIS2, DORA a GDPR Article 32

Sila jednotného modelu ITDR spočíva v tom, že rovnaké dôkazy spĺňajú viaceré povinnosti, pričom rešpektujú jazyk každého rámca.

NIS2 Article 21 očakáva rizikovo orientované a primerané technické, prevádzkové a organizačné opatrenia. Pri ITDR to znamená riadenie prístupu, správu aktív, kybernetickú hygienu, školenie, riešenie incidentov, posúdenie účinnosti kontrol a MFA alebo priebežnú autentifikáciu tam, kde je to vhodné. Article 23 zavádza postupné oznamovanie významných incidentov vrátane včasného varovania do 24 hodín, oznámenia incidentu do 72 hodín a záverečnej správy do jedného mesiaca.

DORA Articles 8 až 14 vyžadujú identifikáciu aktív IKT a závislostí, ochranu a prevenciu, detekčné mechanizmy, kontinuitu a obnovu, učenie sa a komunikáciu. Articles 17 až 19 vyžadujú riadenie incidentov, identifikáciu koreňovej príčiny, indikátory včasného varovania, klasifikáciu podľa závažnosti a kritickosti služby, eskaláciu, notifikáciu riadiaceho orgánu, oznámenie príslušnému orgánu a notifikáciu klientov, ak sú dotknuté finančné záujmy.

GDPR vyžaduje primerané technické a organizačné opatrenia a preukázateľnú zodpovednosť za konanie. Pri útokoch na identity otázky GDPR zahŕňajú, či došlo k neoprávnenému prístupu, ktoré osobné údaje boli zapojené, či ochranné opatrenia fungovali a či sú splnené prahy pre oznámenie porušenia ochrany osobných údajov.

Pre fintech spoločnosti je vzťah NIS2 a DORA dôležitý. DORA sa považuje za odvetvovo špecifický rámec pre finančné subjekty v rozsahu pôsobnosti, kde existujú prekrývajúce sa povinnosti v oblasti rizík IKT a oznamovania incidentov. V praxi by organizácie mali vybudovať jeden dôkazový model ITDR a mapovať rozhodnutia o oznamovaní na príslušnú právnu cestu.

Pri organizáciách typu SaaS, cloud, poskytovateľ riadených služieb, poskytovateľ riadených bezpečnostných služieb a digitálna platforma je potrebné rozsah NIS2 starostlivo overiť. NIS2 pokrýva mnohé sektory z príloh Annex I a Annex II vrátane digitálnej infraštruktúry, poskytovateľov cloudových výpočtových služieb, dátových centier, dôveryhodných služieb, DNS, registrov TLD, poskytovateľov riadených služieb, poskytovateľov riadených bezpečnostných služieb, online trhovísk, vyhľadávačov a platforiem sociálnych sietí. Určenie rozsahu podľa kapitoly 4 ISO/IEC 27001:2022 a analýza zainteresovaných strán preto nie sú administratíva. Definujú, ktoré povinnosti musí ISMS pokryť.

Dodávateľské riziko a riziko identít v SaaS

Incidenty identít často závisia od dôkazov dodávateľa. Vie poskytovateľ SaaS exportovať auditné logy? Zobrazuje udalosti súhlasu OAuth? Podporuje bezpečné riadenie prístupu, logovanie a ochranu údajov? Sú zmluvne upravené pomoc pri incidente, lokalizácia údajov, subdodávky, prístupové práva a ustanovenia o ukončení?

Politika používania cloudových služieb - SME od Clarysec Politika používania cloudových služieb - SME obsahuje priamu požiadavku z kapitoly Požiadavky na správu a riadenie, bod 5.2.4:

Služba poskytuje bezpečné riadenie prístupu, logovanie a schopnosti ochrany údajov

Táto jednoduchá veta je kontrola obstarávania. Ak platforma SaaS nedokáže poskytnúť logy identít potrebné pre reakciu na incidenty, vytvára riziko súladu.

DORA to výslovne stanovuje prostredníctvom povinností týkajúcich sa rizík externých poskytovateľov IKT. Finančné subjekty zostávajú zodpovedné za súlad, musia udržiavať registre zmlúv o službách IKT, rozlišovať kritické alebo dôležité funkcie, vykonávať náležitú starostlivosť, posudzovať riziko koncentrácie, zahrnúť práva na audit a prístup, definovať pomoc pri incidentoch a zabezpečiť stratégie ukončenia.

V Zenith Controls sa kontrola ISO/IEC 27001:2022 8.16 Monitorovacie aktivity prepája s 5.22 Monitorovanie, preskúmanie a riadenie zmien služieb dodávateľov. Odzrkadľuje to prevádzkovú realitu. Upozornenia poskytovateľa identít, auditné logy SaaS, aktivita cloudových administrátorov a účty poskytovateľov riadených služieb sú súčasťou povrchu ITDR.

Ako budú audítori posudzovať ITDR

Silný program ITDR musí obstáť pri viacerých audítorských pohľadoch. Každé publikum kladie iné otázky, ale dôkazy by mali pochádzať z rovnakého kontrolného systému.

Audítor ISO/IEC 27001:2022 sa bude pýtať, či sú hrozby pre identity zahrnuté v posúdení rizík, či vlastníci rizík schválili ošetrenie, či Vyhlásenie o uplatniteľnosti obsahuje relevantné kontroly prílohy A, či sú politiky implementované a či dôkazy ukazujú, že kontroly fungujú. Môže odobrať vzorku privilegovaného účtu a vysledovať schválenie, nastavenie MFA, aktivitu v logoch, revíziu prístupových práv a odoberanie prístupových práv.

Posudzovateľ NIST CSF 2.0 preskúma výsledky GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND a RECOVER. ITDR prirodzene zapadá do profilu zameraného na kompromitáciu identity, zneužitie tokenu SaaS alebo zneužitie privilegovaného prístupu.

Kontrolór podľa DORA bude hľadať zodpovednosť riadiaceho orgánu, obchodné funkcie podporované IKT, detekčné mechanizmy, kritériá klasifikácie incidentov, eskaláciu, pravidlá komunikácie s klientmi, analýzu koreňovej príčiny a závislosti od externých poskytovateľov IKT.

Posudzovateľ GDPR sa bude pýtať, či organizácia dokáže preukázať primeranú bezpečnosť osobných údajov. Preskúma obmedzenie prístupu, detekciu neoprávneného prístupu, logy ukazujúce, ku ktorým údajom mohlo dôjsť k prístupu, posúdenie porušenia ochrany údajov a dôkazy o zodpovednosti za konanie.

Audítor v štýle COBIT 2019 alebo ISACA preskúma správu a riadenie, kontrolné ciele, vlastníctvo, monitorovanie výkonnosti a uistenie.

Zenith Controls je tu užitočný, pretože funguje ako sprievodca viacnásobným súladom. Nevytvára samostatné „kontroly Zenith“. Mapuje oblasti kontrol ISO/IEC 27001:2022 na súvisiace kontroly ISO, iné normy, audítorské očakávania a implementačné vzťahy.

Metriky, ktoré preukazujú, že ITDR funguje

Predstavenstvá a audítori nepotrebujú surový šum zo SIEM. Potrebujú dôkazy, že kontroly identít fungujú a zlepšujú sa. Užitočné metriky ITDR zahŕňajú:

• Percento privilegovaných účtov s MFA odolnou voči phishingu.
• Počet neaktívnych účtov starších ako prah stanovený politikou.
• Počet servisných účtov bez vlastníka alebo dátumu rotácie.
• Percento kritických platforiem SaaS odosielajúcich autentifikačné logy do SIEM.
• Priemerný čas do zistenia podozrivej aktivity identity.
• Priemerný čas do zrušenia kompromitovaných relácií a tokenov.
• Počet aplikácií OAuth schválených, zamietnutých alebo odstránených.
• Percento incidentov identít s úplnými balíkmi dôkazov.
• Počet omeškaných zistení z revízií prístupových práv.
• Počet dodávateľských platforiem bez požadovaných logov identít.

Tieto metriky by mali vstupovať do preskúmania manažmentom podľa ISO/IEC 27001:2022, dohľadu nad správou a riadením podľa NIS2, reportovania rizík IKT podľa DORA a diskusií o zodpovednosti podľa GDPR.

Bežné auditné zistenia ITDR a náprava

Clarysec pravidelne vidí päť opakujúcich sa zistení.

Po prvé, organizácie zapnú MFA, ale nemonitorujú správanie MFA. Nápravou je logovanie zmien metódy MFA, zlyhaných výziev, nemožného cestovania, registrácie nových zariadení a opakovaných push pokusov.

Po druhé, servisné účty sú vyňaté zo správy a riadenia identít. Nápravou je inventarizovať účty na úrovni systému, priradiť vlastníkov, rotovať tajomstvá, odstrániť vložené prihlasovacie údaje a monitorovať anomálne správanie API.

Po tretie, súhlas v SaaS nie je spravovaný. Nápravou je obmedziť súhlas používateľov, preskúmavať aplikácie OAuth, monitorovať nové oprávnenia, dokumentovať schválené integrácie a odstraňovať nepoužívané aplikácie.

Po štvrté, dôkazy sa počas vyšetrovania menia. Nápravou je dodržiavať pravidlo Politiky zberu dôkazov a forenznej analýzy: vytvárať forenzné kópie alebo exporty, nikdy neupravovať originály priamo a ukladať dôkazy s hash hodnotami a záznamami reťazca zverenia.

Po piate, klasifikácia incidentov je príliš pomalá. Nápravou je vopred definovať prahy udalostí identít vrátane kompromitácie privilegovaného účtu, prístupu k osobným údajom, zneužitia SaaS tokenu s dopadom na zákazníka, prerušenia kritickej služby a kompromitácie dodávateľskej identity.

Každé zistenie má kontrolnú, politickú a dôkazovú reakciu. To je praktická hodnota jednotného programu ITDR: definuje, čo musí mať vlastníka, čo sa musí monitorovať, testovať, dokazovať a zlepšovať.

Premeňte riziko identít na dôkazy pripravené na audit

Ak by sa váš ďalší incident identity stal zajtra, vedeli by ste preukázať, kto k čomu pristúpil, ako sa autentifikoval, ktorý token alebo relácia boli použité, ktorých údajov sa to dotklo, kto rozhodol o regulačnej klasifikácii a ktoré nápravné opatrenia boli dokončené?

Ak odpoveď nie je istá, začnite cieleným sprintom pripravenosti ITDR.

Použite Zenith Blueprint na štruktúrovanie implementačnej cesty naprieč autentifikáciou, životným cyklom prístupov, logovaním, monitorovaním, reakciou na incidenty a nakladaním s dôkazmi. Použite politiky Clarysec pre riadenie prístupu, logovanie, cloud, reakciu na incidenty a forenznú analýzu na priradenie vlastníctva a právomoci reakcie. Použite Zenith Controls na mapovanie správy identít, bezpečnej autentifikácie a monitorovacích aktivít na ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST CSF 2.0 a audítorské očakávania.

Cieľ je jednoduchý: zabezpečiť, aby boli útoky na identity detegovateľné, zamedziteľné, oznamovateľné a obhájiteľné.

Clarysec vám môže pomôcť vybudovať balík dôkazov ITDR, otestovať ho prostredníctvom stolového scenára a premeniť zistenia na plán ošetrenia rizík, ktorému porozumie vaše predstavenstvo, regulátor aj audítor. Začnite preskúmaním Politiky logovania a monitorovania, Politiky správy používateľských účtov a oprávnení - SME, Zenith Blueprint a Zenith Controls, potom si naplánujte posúdenie pripravenosti ITDR, aby ste premenili riziko identít na dôkazy pripravené na audit.