Strategie ITDR pro ISO 27001, NIS2, DORA a GDPR

Ve 3:00 ráno v úterý probudilo Sarah, ředitelku informační bezpečnosti společnosti FinScale, upozornění, kterého se moderní bezpečnostní vedení obává stále častěji. Aktivní relace seniorního vývojáře, ověřená pomocí MFA jen několik hodin předtím, byla z neobvyklého zdroje používána k enumeraci schémat produkčních databází.

Nebyl zde žádný malware beacon. Žádná zpráva ransomwaru. Žádný exploit firewallu. Jen identita.

SOC aktivitu zachytil, ale reakce byla nejednotná. Šlo o obejití MFA, odcizený token relace, nebo kompromitaci samotného poskytovatele identit? Kdo měl pravomoc ukončit aktivní relaci? Stačilo zneplatnit heslo, nebo musel tým zneplatnit refresh tokeny, rotovat API přihlašovací údaje a přezkoumat oprávnění OAuth? Než byla aktivita zastavena, útočník byl aktivní 47 minut.

Následující ráno se bezpečnostní incident změnil v otázku governance. Správní rada chtěla srozumitelné vysvětlení, zda ve FinScale selhala kybernetická hygiena podle NIS2. Compliance tým chtěl vědět, zda lze událost klasifikovat jako závažný incident související s ICT podle DORA. Právní oddělení potřebovalo obhajitelnou odpověď, zda došlo k přístupu k osobním údajům podle GDPR Article 32 a zda je vyžadováno posouzení porušení zabezpečení osobních údajů. Externí auditor se ptal, zda opatření ISO/IEC 27001:2022 fungovala účinně, nikoli pouze zda byla popsána v politikách.

Sarahin problém nespočíval v nedostatku nástrojů. FinScale měl poskytovatele identit, MFA, SIEM, opatření na koncových bodech, cloudové logy a proces reakce na incidenty. Problém spočíval v tom, že správa identit, protokolování, monitorování, reakce na incidenty, posouzení dopadů na soukromí a nakládání s důkazy fungovaly v oddělených silech.

To je problém Identity Threat Detection and Response v roce 2026. ITDR už není jen schopností bezpečnostního provozu. Je to důkazní mechanismus napříč požadavky na soulad podle ISO/IEC 27001:2022, NIS2, DORA a GDPR Article 32.

Clarysec Zenith Blueprint: 30krokový plán auditora Zenith Blueprint, sada politik a Zenith Controls: průvodce napříč požadavky souladu Zenith Controls pomáhají organizacím převést útoky na identity z chaotických vyšetřování na opakovatelné a auditovatelné procesy řízení opatření.

Proč je Identity Threat Detection and Response tématem pro řídicí orgány

Útoky na identity fungují proto, že zneužívají legitimní přístupové cesty. Útočník, který odcizí token relace, zaregistruje škodlivou aplikaci OAuth, kompromituje servisní účet nebo přesvědčí uživatele prostřednictvím únavy z push notifikací MFA, může pro systémy, které pouze ověřují úspěšnou autentizaci, vypadat jako platný uživatel.

Tím se ITDR liší od tradiční ochrany perimetru. Vyspělý program musí umět odpovědět na tyto otázky:

• Jaké lidské, servisní, dodavatelské a aplikační identity existují?
• Které identity jsou privilegované, neaktivní, sdílené nebo externě federované?
• Které autentizační události jsou běžné, rizikové nebo nemožné?
• Která oprávnění OAuth, SaaS tokeny a API přihlašovací údaje mohou přistupovat k citlivým datům?
• Která upozornění spouštějí klasifikaci incidentu, uchování důkazů a regulatorní rozhodování?
• Která opatření prokazují, že přístup k osobním údajům je chráněn vhodnými technickými a organizačními opatřeními?

NIS2 z toho činí otázku správy a řízení. Article 20 vyžaduje, aby řídicí orgány základních a významných subjektů schvalovaly opatření pro řízení rizik kybernetické bezpečnosti, dohlížely na jejich implementaci a absolvovaly školení. Article 21 vyžaduje vhodná a přiměřená technická, provozní a organizační opatření, včetně analýzy rizik, zvládání incidentů, kontinuity činností, zabezpečení dodavatelského řetězce, posuzování účinnosti opatření, kybernetické hygieny, školení, řízení přístupu, správy aktiv a vícefaktorové nebo průběžné autentizace tam, kde je to vhodné.

DORA vytváří podobný tlak na finanční subjekty. Vyžaduje dokumentovaný rámec pro řízení rizik v oblasti ICT, odpovědnost řídicího orgánu, detekční mechanismy, řízení incidentů, klasifikaci, oznamování, testování odolnosti a řízení rizik třetích stran v oblasti ICT. DORA se použije od 17. ledna 2025. U finančních subjektů, které jsou zároveň identifikovány podle NIS2, funguje DORA jako sektorově specifický soubor pravidel pro překrývající se povinnosti v oblasti rizik ICT a incidentů.

GDPR přidává vrstvu odpovědnosti v oblasti ochrany soukromí. Article 5 vyžaduje integritu, důvěrnost a odpovědnost. Article 4 vymezuje porušení zabezpečení osobních údajů široce, včetně neoprávněného přístupu k osobním údajům. Article 32 vyžaduje vhodná technická a organizační opatření k zajištění úrovně zabezpečení odpovídající riziku. U incidentů souvisejících s identitami se logy, řízení přístupu, autentizační záznamy a důkazy k incidentu stávají klíčovými pro prokázání, zda byly osobní údaje chráněny.

ISO/IEC 27001:2022 je systém řízení, který dokáže tyto povinnosti propojit. Kapitola 4 vyžaduje, aby organizace porozuměla svému kontextu, zainteresovaným stranám a právním, regulatorním a smluvním požadavkům. Kapitola 6 vyžaduje posouzení rizik, ošetření rizik, schválení vlastníkem rizika a uchovávané důkazy. Příloha A zahrnuje opatření pro správu identit, bezpečnou autentizaci, protokolování, monitorování, řízení incidentů, sběr důkazů, vztahy s dodavateli, cloudové služby a ochranu soukromí.

ITDR patří do ISMS, protože riziko spojené s identitami je auditovatelné pouze tehdy, když je zahrnuto do rozsahu, má vlastníka, je posouzeno, ošetřeno, monitorováno a zlepšováno.

Scénář útoku na identitu, který zajímá regulační orgány

Představme si poskytovatele cloudového finančního workflow pro zákazníky v EU. Používá Microsoft 365, SaaS platformu pro zákaznickou podporu, cloudovou infrastrukturu, zpracovatele plateb a několik integrací založených na API. Seniorní inženýr podpory obdrží přesvědčivou výzvu k opětovnému připojení produkční aplikace. Obrazovka souhlasu OAuth požaduje přístup pro čtení poštovní schránky a offline přístup. Inženýr žádost schválí.

Během několika minut útočník použije token k vyhledávání identifikátorů zákazníků a příloh podpory. Enumeruje členství ve skupinách a pokouší se o přístup do administrátorského portálu. MFA bylo povoleno, ale útočník už heslo nepotřebuje, protože token poskytuje trvalý přístup. SOC vidí neobvyklý přístup k poštovní schránce, novou aplikaci OAuth, neúspěšné pokusy o přístup do administrátorského portálu a aktivitu z neobvyklé geografické oblasti.

Tento jediný scénář prochází několika doménami opatření:

• Životní cyklus identity, protože role a oprávnění uživatele určují rozsah dopadu.
• Bezpečná autentizace, protože samotné MFA nezabránilo zneužití tokenu.
• Protokolování a monitorování, protože detekce závisí na logách poskytovatele identit, SaaS a aplikací.
• Reakce na incidenty, protože přihlašovací údaje, relace, tokeny a oprávnění OAuth musí být rychle revokovány.
• Sběr důkazů, protože může následovat expozice osobních údajů a regulatorní oznamování.
• Správa dodavatelů a cloudu, protože SaaS logy a auditní API jsou součástí důkazního řetězce.
• Ochrana soukromí, protože přístup k osobním údajům musí být posouzen podle GDPR.

Lepší otázka nezní: „Který nástroj selhal?“ Lepší otázka zní, zda měla organizace navržený, otestovaný a auditovatelný řetězec opatření ITDR.

Řetězec opatření ISO 27001:2022 za účinným ITDR

Nejúčinnější programy ITDR propojují preventivní, detekční, nápravná a důkazní opatření.

V Zenith Controls je opatření ISO/IEC 27001:2022 5.16 Správa identit pojato jako preventivní opatření podporující důvěrnost, integritu a dostupnost. Přímo navazuje na 5.15 Řízení přístupu, 5.17 Autentizační informace, 5.18 Přístupová práva, 5.19 Bezpečnost informací ve vztazích s dodavateli, 5.36 Soulad s politikami, pravidly a normami bezpečnosti informací a 8.2 Privilegovaná přístupová práva.

To je důležité, protože detekce identit selhává tam, kde je slabá správa identit. Pokud není servisní účet zdokumentován, dodavatelská identita není spravována nebo privilegovaná role nemá vlastníka, monitorování může událost detekovat, ale osoby reagující na incident ji nedokážou rychle interpretovat.

Opatření 8.5 Bezpečná autentizace je dalším klíčovým prvkem ITDR. V Zenith Controls je propojeno se správou identit, autentizačními informacemi, privilegovanými přístupovými právy, omezením přístupu k informacím, monitorovacími činnostmi, řízením incidentů a ochranou soukromí osobně identifikovatelných údajů. Autentizace nekončí přihlášením. Řízení relací, nakládání s tokeny, ochrana přihlašovacích údajů a dohledatelnost jsou součástí stejného důkazního příběhu.

Opatření 8.16 Monitorovací činnosti je spojovacím prvkem mezi sběrem logů a rozhodováním. Závisí na 8.15 Protokolování a podporuje 5.25 Posouzení a rozhodování o událostech bezpečnosti informací, 5.26 Reakci na incidenty bezpečnosti informací a širší řízení incidentů. Pro ITDR je 8.16 místem, kde se podezřelé chování identity mění na vytříděnou událost, vyhlášený incident nebo zdokumentovaný falešně pozitivní nález.

Tabulka není teoretické mapování. Je to praktický důkazní řetězec, který bude auditor, člen řídicího orgánu nebo regulační orgán očekávat po incidentu souvisejícím s identitou.

Co přidávají politiky Clarysec: vlastnictví, spouštěče a pravidla pro důkazy

Nástroje pro identity automaticky nevytvářejí odpovědnost. Během krize potřebují osoby reagující na incident pravomoc revokovat relace, deaktivovat účty, exportovat logy, uchovat důkazy a rozhodovat o eskalaci. Auditoři potřebují vidět, že tyto kroky nebyly improvizované.

Sada politik Clarysec poskytuje tento provozní model.

Z podnikové Politiky správy uživatelských účtů a oprávnění Politika správy uživatelských účtů a oprávnění, kapitola Požadavky na správu a řízení 5.9, vyplývá:

Organizace musí udržovat podrobnou evidenci všech aktivních a neaktivních přihlašovacích údajů, privilegovaných účtů a servisních účtů na úrovni systému. Tato evidence musí být průběžně aktualizována a čtvrtletně přezkoumávána.

Tím se evidence identit mění na explicitní povinnost opatření. Je to obzvlášť důležité, protože servisní účty, API klíče a neaktivní přihlašovací údaje jsou běžnými slepými místy ITDR.

Stejná politika v kapitole Požadavky na správu a řízení 5.8 uvádí:

Veškeré administrátorské činnosti a úkony privilegovaných účtů musí být protokolovány způsobem s detekcí manipulace a monitorovány z hlediska anomálií nebo porušení politiky.

Tato kapitola propojuje správu privilegovaných přístupů s detekcí. Privilegovaný úkon není pouze povolen nebo zamítnut. Musí být monitorován z hlediska chování, které neodpovídá uživateli, roli, zdroji, času nebo obchodnímu procesu.

Pro menší organizace stanoví Politika správy uživatelských účtů a oprávnění - SME Politika správy uživatelských účtů a oprávnění - SME stručné očekávání v kapitole Uplatňování a soulad 8.1.1:

Vedoucí IT musí pravidelně přezkoumávat systémové logy z hlediska pokusů o neoprávněný přístup, anomálií přihlášení nebo neschválených změn oprávnění.

Zde začíná mnoho programů ITDR v SME. Nevyžaduje to rozsáhlý SOC. Vyžaduje to určené vlastnictví a pravidelný přezkum správných signálů identity.

Politika protokolování poskytuje důkazní základ. Politika protokolování a monitorování - SME Politika protokolování a monitorování - SME stanoví v kapitole Požadavky na správu a řízení 5.4.2:

Autentizační logy: úspěšné a neúspěšné pokusy o přihlášení, doba trvání relace, použití MFA

Tato pole nejsou volitelná. Pomáhají prokázat, zda podezřelá událost zahrnovala úspěšnou autentizaci, opakovaná selhání, použití MFA, přetrvání relace nebo abnormální dobu trvání.

Podniková Politika protokolování a monitorování Politika protokolování a monitorování rozšiřuje požadovaný rozsah logů v kapitole Požadavky na implementaci politiky 6.1.1:

Všechny zahrnuté systémy musí generovat logy zachycující: 6.1.1.1 Autentizaci uživatelů a pokusy o přístup 6.1.1.2 Aktivity privilegovaných uživatelů 6.1.1.3 Změny konfigurace 6.1.1.4 Neúspěšné pokusy o přístup nebo systémové události 6.1.1.5 Detekce malwaru a bezpečnostní upozornění 6.1.1.6 Externí komunikaci a spouštěče pravidel firewallu

Změny konfigurace jsou u útoků na identity zvlášť důležité. Útočníci často přidávají oprávnění OAuth, vytvářejí pravidla přeposílání, registrují zařízení, upravují metody MFA nebo vytvářejí cesty nouzového přístupu.

Politika reakce na incidenty pak dává osobám reagujícím na incident pravomoc. Podniková Politika reakce na incidenty Politika reakce na incidenty uvádí v kapitole Požadavky na implementaci politiky 6.2.1:

SOC musí okamžitě izolovat zasažené systémy, revokovat kompromitované přihlašovací údaje nebo blokovat škodlivý provoz pomocí firewallu nebo nástrojů pro zabezpečení koncových bodů.

Politika reakce na incidenty - SME Politika reakce na incidenty - SME uvádí v kapitole Role a odpovědnosti 4.2.2:

Provádí opatření k omezení dopadu a obnově, například deaktivací přístupu nebo obnovením záloh.

Pro ITDR nestačí revokovat heslo. Runbooky musí zahrnovat deaktivaci účtů, revokaci relací, zneplatnění oprávnění OAuth, rotaci tajných údajů, reset metod MFA a přezkum delegovaných oprávnění.

Nakládání s důkazy je rozdíl mezi reakcí a prokázáním. Podniková Politika sběru důkazů a forenzního šetření Politika sběru důkazů a forenzního šetření uvádí v kapitole Požadavky na správu a řízení 5.5:

Veškeré shromážděné důkazy musí být jednoznačně identifikovány, označeny a uloženy v zabezpečeném repozitáři s: 5.5.1 Ověřením integrity, například hash hodnotami SHA-256 5.5.2 Logy přístupu s časovým razítkem 5.5.3 Záznamy řetězce svěření podepsanými každým správcem aktiv

Politika sběru důkazů a forenzního šetření - SME Politika sběru důkazů a forenzního šetření - SME uvádí v kapitole Požadavky na implementaci politiky 6.1.1:

Forenzní kopie nebo export musí být vždy vytvořeny; původní důkaz nesmí být nikdy přímo upravován.

Ve scénáři FinScale to znamená, že SOC exportuje logy poskytovatele identit, auditní logy SaaS, záznamy o přístupu k poštovní schránce, záznamy souhlasu OAuth, záznamy o revokaci relací a upozornění SIEM do důkazního repozitáře s ochranou integrity a řetězcem svěření.

Tvorba roadmapy ITDR pomocí Zenith Blueprint

Zenith Blueprint převádí řetězec opatření na implementační kroky.

Ve fázi Controls in Action, krok 19, Technologická opatření I, je Blueprint v otázce autentizace jednoznačný:

Kde je to možné, autentizaci pouze heslem je třeba se vyhnout, zejména u administrátorských účtů, cloudových konzolí, nástrojů vzdáleného přístupu a jakéhokoli systému vystaveného internetu. MFA s použitím druhého faktoru, jako je hardwarový klíč, mobilní aplikace nebo biometrie, je dnes základní požadavek, nikoli nadstandard. Zmírňuje rizika odcizení přihlašovacích údajů, phishingu a útoků hrubou silou.

Tentýž krok jde nad rámec hesel. Vyžaduje bezpečné uložení a přenos autentizačních údajů, bezpečné nakládání s API tokeny, ID relací a přihlašovacími údaji OAuth, správu tajných údajů pro autentizaci mezi systémy, rotaci tokenů, řízení životnosti relací, bezpečné příznaky cookies a přezkum autentizačních logů.

Krok 22, Organizační opatření, formalizuje životní cyklus přístupů. Vede týmy k integraci zřizování a odebírání přístupů s HR, provádění dokumentovaných čtvrtletních přezkumů přístupových práv, definování typů identit, jako jsou individuální, sdílené a servisní účty, vynucování MFA pro privilegované účty, odstraňování neaktivních účtů a rotaci servisních přihlašovacích údajů.

Krok 19 poskytuje také cestu ke zlepšení protokolování: předávat kritické logy do SIEM nebo sběrače logů, validovat uchovávání, dohledat nedávnou událost pomocí logů, zdokumentovat prvky integrity logů a potvrdit upozorňování na neúspěšná přihlášení nebo eskalace oprávnění. Synchronizace času je důležitá, protože rekonstrukce incidentu selhává, pokud se logy poskytovatele identit, SaaS, koncových bodů a cloudu neshodují v časových razítkách.

Krok 23, Organizační opatření pro 5.19 až 5.37, validuje schopnosti řízení incidentů. Vyžaduje aktuální plán reakce na incidenty, definované události podléhající hlášení, tabletop cvičení, dokumentovaná rozhodnutí, komunikační záznamy, získané poznatky a uchování forenzních důkazů, například snapshotů logů, záloh a bezpečné izolace.

Pragmatická posloupnost ITDR podle Clarysec vypadá takto:

1. Definovat typy identit a jejich vlastníky.
2. Zabezpečit autentizaci, tokeny a relace.
3. Shromažďovat autentizační, privilegované a SaaS logy.
4. Monitorovat rizikové chování.
5. Definovat pravidla rozhodování od události k incidentu.
6. Uchovat důkazy.
7. Oznámit, obnovit a zlepšit.

Týdenní důkazní balíček ITDR

Cílený „důkazní balíček k incidentu identity“ je jedním z nejrychlejších způsobů, jak odhalit mezery. Vyberte jeden vysoce rizikový scénář, například: „Privilegovaný uživatel SaaS udělí souhlas neautorizované aplikaci OAuth a token je použit k přístupu k zákaznickým datům.“

Poté během jednoho týdne vytvořte důkazní balíček.

Zahrňte alespoň jednu skutečnou stopu. Vezměte nedávnou neškodnou anomálii přihlášení a ukažte, jak se tým přesune od upozornění k identitě uživatele, zařízení, zdrojové IP adrese, metodě MFA, době trvání relace, zpřístupněným SaaS zdrojům, dotčeným datům a rozhodnutí o omezení dopadu. Pokud organizace nedokáže tento řetězec rekonstruovat v tabletop cvičení, bude mít potíže při skutečném incidentu.

Výstup se stává opakovaně použitelným důkazem pro interní audity ISO/IEC 27001:2022, testování procesu incidentů v oblasti ICT podle DORA, dohled nad kybernetickou hygienou podle NIS2 a odpovědnost podle GDPR.

Mapování ITDR na NIS2, DORA a GDPR Article 32

Síla jednotného modelu ITDR spočívá v tom, že stejné důkazy plní více povinností a zároveň respektují jazyk každého rámce.

NIS2 Article 21 očekává technická, provozní a organizační opatření založená na rizicích a přiměřená dané situaci. Pro ITDR to znamená řízení přístupu, správu aktiv, kybernetickou hygienu, školení, zvládání incidentů, posouzení účinnosti opatření a MFA nebo průběžnou autentizaci tam, kde je to vhodné. Article 23 zavádí stupňovité oznamování významných incidentů, včetně včasného varování do 24 hodin, oznámení incidentu do 72 hodin a závěrečné zprávy do jednoho měsíce.

DORA Articles 8 to 14 vyžadují identifikaci ICT aktiv a závislostí, ochranu a prevenci, detekční mechanismy, kontinuitu a obnovu, učení a komunikaci. Articles 17 to 19 vyžadují řízení incidentů, identifikaci kořenové příčiny, indikátory včasného varování, klasifikaci podle závažnosti a kritičnosti služby, eskalaci, informování řídicího orgánu, oznámení příslušnému orgánu a informování klientů, pokud jsou dotčeny finanční zájmy.

GDPR vyžaduje vhodná technická a organizační opatření a prokazatelnou odpovědnost. U útoků na identity otázky podle GDPR zahrnují, zda došlo k neoprávněnému přístupu, jaké osobní údaje byly dotčeny, zda fungovala ochranná opatření a zda jsou naplněny prahové hodnoty pro oznamování porušení zabezpečení.

U fintech společností je vztah NIS2 a DORA důležitý. DORA je považována za sektorově specifický rámec pro finanční subjekty v rozsahu působnosti tam, kde existují překrývající se povinnosti v oblasti rizik ICT a oznamování incidentů. V praxi by organizace měly vybudovat jeden důkazní model ITDR a mapovat rozhodnutí o oznamování na příslušnou právní cestu.

U organizací poskytujících SaaS, cloud, řízené služby, řízenou bezpečnost a digitální platformy je nutné rozsah NIS2 pečlivě ověřit. NIS2 pokrývá mnoho sektorů z přílohy I a přílohy II, včetně digitální infrastruktury, poskytovatelů cloud computingu, datových center, služeb vytvářejících důvěru, DNS, registrů TLD, poskytovatelů řízených služeb, poskytovatelů řízených bezpečnostních služeb, online tržišť, vyhledávačů a platforem sociálních sítí. Vymezení rozsahu podle ISO/IEC 27001:2022 kapitola 4 a analýza zainteresovaných stran proto nejsou administrativní formalitou. Určují, které povinnosti musí ISMS řešit.

Riziko identit u dodavatelů a SaaS

Incidenty související s identitami často závisí na důkazech od dodavatelů. Dokáže poskytovatel SaaS exportovat auditní logy? Zobrazuje události souhlasu OAuth? Podporuje bezpečné řízení přístupu, protokolování a ochranu údajů? Jsou smluvně upraveny podpora při incidentech, umístění dat, subdodávky, přístupová práva a ustanovení o ukončení spolupráce?

Clarysec Politika používání cloudových služeb - SME Politika používání cloudových služeb - SME obsahuje přímý požadavek z kapitoly Požadavky na správu a řízení 5.2.4:

Služba poskytuje schopnosti bezpečného řízení přístupu, protokolování a ochrany údajů

Tato jednoduchá věta je kontrolou při pořizování. Pokud platforma SaaS nedokáže poskytnout logy identit potřebné pro reakci na incidenty, vytváří riziko nesouladu.

DORA to výslovně stanoví prostřednictvím povinností v oblasti rizik třetích stran v ICT. Finanční subjekty zůstávají odpovědné za soulad, musí vést registry smluv o ICT službách, rozlišovat kritické nebo důležité funkce, provádět náležitou péči, posuzovat riziko koncentrace, zahrnout práva na audit a přístup, definovat podporu při incidentech a zajistit strategie ukončení spolupráce.

V Zenith Controls se opatření ISO/IEC 27001:2022 8.16 Monitorovací činnosti propojuje s 5.22 Monitorování, přezkum a řízení změn služeb dodavatelů. To odráží provozní realitu. Upozornění poskytovatele identit, auditní logy SaaS, aktivita cloudových administrátorů a účty poskytovatelů řízených služeb tvoří součást povrchu ITDR.

Jak budou auditoři posuzovat ITDR

Silný program ITDR musí obstát při několika auditních pohledech. Každá skupina klade jiné otázky, ale důkazy mají vycházet ze stejného systému opatření.

Auditor ISO/IEC 27001:2022 se bude ptát, zda jsou hrozby související s identitami zahrnuty v posouzení rizik, zda vlastníci rizik schválili ošetření, zda Prohlášení o použitelnosti zahrnuje relevantní opatření přílohy A, zda jsou politiky implementovány a zda důkazy ukazují, že opatření fungují. Může vybrat vzorek privilegovaného účtu a sledovat schválení, nastavení MFA, aktivitu v logách, přezkum přístupových práv a odebrání přístupových oprávnění.

Hodnotitel NIST CSF 2.0 bude zkoumat výstupy GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND a RECOVER. ITDR přirozeně zapadá do profilu vymezeného na kompromitaci identity, zneužití SaaS tokenu nebo zneužití privilegovaného přístupu.

Kontrolor podle DORA bude hledat odpovědnost řídicího orgánu, obchodní funkce podporované ICT, detekční mechanismy, kritéria klasifikace incidentů, eskalaci, pravidla komunikace s klienty, analýzu kořenové příčiny a závislosti na třetích stranách v ICT.

Přezkoumávající osoba podle GDPR se bude ptát, zda organizace dokáže prokázat vhodné zabezpečení osobních údajů. Bude zkoumat omezení přístupu, detekci neoprávněného přístupu, logy ukazující, k jakým datům mohlo být přistoupeno, posouzení porušení zabezpečení a důkazy odpovědnosti.

Auditor ve stylu COBIT 2019 nebo ISACA bude zkoumat správu a řízení, cíle opatření, vlastnictví, monitorování výkonnosti a ujištění.

Zenith Controls je zde užitečný, protože funguje jako průvodce napříč požadavky souladu. Nevytváří samostatná „opatření Zenith“. Mapuje oblasti opatření ISO/IEC 27001:2022 na související opatření ISO, jiné normy, auditní očekávání a implementační vazby.

Metriky, které prokazují, že ITDR funguje

Řídicí orgány a auditoři nepotřebují surový šum ze SIEM. Potřebují důkazy, že opatření pro identity fungují a zlepšují se. Mezi užitečné metriky ITDR patří:

• Procento privilegovaných účtů s MFA odolnou vůči phishingu.
• Počet neaktivních účtů starších než prahová hodnota politiky.
• Počet servisních účtů bez vlastníka nebo data rotace.
• Procento kritických SaaS platforem odesílajících autentizační logy do SIEM.
• Průměrná doba do detekce podezřelé aktivity identity.
• Průměrná doba do revokace kompromitovaných relací a tokenů.
• Počet aplikací OAuth schválených, zamítnutých nebo odstraněných.
• Procento incidentů identity s úplnými důkazními balíčky.
• Počet zjištění z přezkumu přístupových práv po termínu.
• Počet dodavatelských platforem, kterým chybí požadované logy identit.

Tyto metriky by měly vstupovat do přezkoumání vedením podle ISO/IEC 27001:2022, do dohledu nad governance podle NIS2, do reportingu rizik ICT podle DORA a do diskusí o odpovědnosti podle GDPR.

Běžná auditní zjištění ITDR a jejich náprava

Clarysec běžně vidí pět opakujících se zjištění.

Za prvé, organizace povolí MFA, ale nemonitorují chování MFA. Náprava spočívá v protokolování změn metod MFA, neúspěšných výzev, nemožného cestování, registrace nových zařízení a opakovaných push pokusů.

Za druhé, servisní účty jsou vynechány ze správy identit. Náprava spočívá v evidenci účtů na úrovni systému, přiřazení vlastníků, rotaci tajných údajů, odstranění vložených přihlašovacích údajů a monitorování anomálního chování API.

Za třetí, souhlas SaaS není řízen. Náprava spočívá v omezení uživatelského souhlasu, přezkumu aplikací OAuth, monitorování nových oprávnění, dokumentování schválených integrací a odstraňování nepoužívaných aplikací.

Za čtvrté, důkazy jsou během vyšetřování měněny. Náprava spočívá v dodržení pravidla Politiky sběru důkazů a forenzního šetření: vytvářet forenzní kopie nebo exporty, nikdy přímo neupravovat originály a ukládat důkazy s hash hodnotami a záznamy řetězce svěření.

Za páté, klasifikace incidentu je příliš pomalá. Náprava spočívá v předem definovaných prahových hodnotách událostí identity, včetně kompromitace privilegovaného účtu, přístupu k osobním údajům, zneužití SaaS tokenu s dopadem na zákazníky, narušení kritické služby a kompromitace dodavatelské identity.

Každé zjištění má odpověď v podobě opatření, politiky a důkazů. To je praktická hodnota jednotného programu ITDR: definuje, co musí mít vlastníka, být monitorováno, testováno, doloženo a zlepšováno.

Přeměňte riziko identity na důkazy připravené pro audit

Kdyby k dalšímu incidentu identity došlo zítra, dokázali byste prokázat, kdo k čemu přistoupil, jak se autentizoval, který token nebo relace byly použity, jaká data byla dotčena, kdo rozhodl o regulatorní klasifikaci a která nápravná opatření byla dokončena?

Pokud je odpověď nejistá, začněte cíleným sprintem připravenosti ITDR.

Použijte Zenith Blueprint ke strukturování implementační cesty napříč autentizací, životním cyklem přístupů, protokolováním, monitorováním, reakcí na incidenty a nakládáním s důkazy. Použijte politiky Clarysec pro řízení přístupu, protokolování, cloud, reakci na incidenty a forenzní šetření k přiřazení vlastnictví a pravomoci k reakci. Použijte Zenith Controls k mapování správy identit, bezpečné autentizace a monitorovacích činností na ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST CSF 2.0 a auditní očekávání.

Cíl je jednoduchý: zajistit, aby útoky na identity byly detekovatelné, zvládnutelné, oznamovatelné a obhajitelné.

Clarysec vám může pomoci vybudovat důkazní balíček ITDR, otestovat jej prostřednictvím tabletop scénáře a převést zjištění do plánu ošetření rizik, kterému porozumí řídicí orgán, regulační orgán i auditor. Začněte přezkumem Politiky protokolování a monitorování, Politiky správy uživatelských účtů a oprávnění - SME, Zenith Blueprint a Zenith Controls, poté naplánujte posouzení připravenosti ITDR a přeměňte riziko identity na důkazy připravené pro audit.