Riadenie únavy z MFA a útokov typu push bombing

Push oznámenie o 2:13, z ktorého sa stala otázka pre predstavenstvo

O 2:13 ráno dostane skúsená administrátorka finančného oddelenia mobilné oznámenie: „Schváliť prihlásenie?“ Je v polospánku, predpokladá, že ide o časový limit relácie z cloudovej finančnej platformy, a klepne na schválenie.

O 2:19 je útočník vo vnútri poskytovateľa identít. O 2:31 sa pokúša získať prístup k exportu miezd, privilegovanej cloudovej konzole a zdieľanej e-mailovej schránke používanej na platby dodávateľom. O 3:05 SOC vidí opakované výzvy MFA, neobvyklú geografickú polohu, úspešné schválenie a novú reláciu z nespravovaného zariadenia.

Ranný rozhovor býva známy:

• „Ale veď sme mali MFA."
• „Prečo to používateľka schválila?"
• „Zaznamenávali sme podrobnosti výzvy MFA?"
• „Je to porušenie ochrany osobných údajov?"
• „Vzťahujú sa na nás 24-hodinové alebo 72-hodinové oznamovacie povinnosti?"
• „Bude to náš audítor ISO 27001:2022 považovať za zlyhanie kontroly?"
• „Má to vplyv na NIS2, DORA, GDPR, zákaznícke zmluvy alebo kybernetické poistenie?"

Toto je medzera v riadení, ktorá stojí za únavou z MFA a útokmi typu push bombing. Útočníci neprelamujú kryptografiu. Vyčerpávajú ľudské rozhodovanie, zneužívajú slabý návrh autentifikácie a hľadajú nemonitorované výnimky. Zlyhaním kontroly zriedka býva „MFA nie je zapnuté“. Zvyčajne ide o reťazec slabej dôveryhodnosti identity, rizikového návrhu push schvaľovania, chýbajúceho párovania čísel, nejasných pravidiel privilegovaného prístupu, nedostatočného logovania autentifikácie, slabej triáže upozornení, nedostatočne vyškolených používateľov a chýbajúcich zdokumentovaných dôkazov, že organizácia slabinu preskúmala a odstránila.

Pre CISO, manažérov súladu, audítorov a vedenie organizácie sa musí únava z MFA posudzovať ako problém dôkazov v ISMS, nie iba ako nastavenie poskytovateľa identít. Riešenie kombinuje ošetrenie rizík podľa ISO 27001:2022, kontroly ISO/IEC 27002:2022, povinnosti vyplývajúce z politík, bezpečnostné povedomie používateľov, reakciu na incidenty, riadenie dodávateľov a mapovania naprieč rámcami pre NIS2, DORA, GDPR, NIST CSF 2.0 a COBIT 2019.

Únava z MFA je zlyhaním uistenia, nie problémom používateľa

Únava z MFA, označovaná aj ako push bombing alebo prompt bombing, nastáva, keď útočník s platným heslom opakovane vyvoláva žiadosti o schválenie MFA, kým používateľ jednu z nich neprijme. Niekedy útočník pridá sociálne inžinierstvo, napríklad falošný telefonát z helpdesku, správu typu „testujeme váš účet“ alebo žiadosť o schválenie prihlásenia s cieľom zastaviť oznámenia.

Prevádzkové riziko spočíva v tom, že organizácie často považujú všetky formy MFA za rovnocenné. Nie sú.

Jednoduché push oznámenie „schváliť alebo zamietnuť“ je slabšie než párovanie čísel, bezpečnostné kľúče FIDO2 odolné voči phishingu, autentifikácia založená na certifikátoch alebo podmienený prístup, ktorý blokuje nemožné cestovanie a nespravované zariadenia. MFA zlyháva aj vtedy, keď výnimky z obídenia nie sú zdokumentované, servisné účty sú interaktívne, zastarané protokoly zostávajú povolené alebo vysokorizikový prístup nevyžaduje silnejšiu autentifikáciu.

V Zenith Blueprint: An Auditor’s 30-Step Roadmap Clarysec zasadzuje bezpečnú autentifikáciu do fázy Controls in Action, Step 19: Technological Controls I. Usmernenie je priame:

Autentifikácia je prvá a najkritickejšia línia obrany medzi pôvodcom hrozby a vašimi systémami, údajmi a službami. Ak je autentifikácia slabá, všetko ostatné, šifrovanie, monitorovanie aj segmentácia, možno obísť.

Ten istý Zenith Blueprint sa venuje aj kontrole ISO/IEC 27002:2022 5.17 v kroku Step 22:

Ak je otázkou identity „Kto ste?“, potom autentifikácia je dôkazom. Kontrola 5.17 je miestom, kde sa teória stretáva s dôverou. Vyžaduje, aby boli autentifikačné informácie bezpečne riadené počas celého svojho životného cyklu, čím sa zabezpečí, že metódy a poverenia používané na overenie identity sa samy nestanú najslabším článkom.

Tieto dve vyhlásenia vysvetľujú, prečo push bombing patrí do registra rizík. Šifrovanie nepomôže, ak sa útočník stane schváleným používateľom. Segmentácia siete pomôže menej, ak je privilegovaný cloudový prístup schválený výzvou prijatou v dôsledku únavy. Monitorovanie funguje iba vtedy, ak sú autentifikačné udalosti logované v dostatočných podrobnostiach a rýchlo preskúmané.

Zrelé vyhlásenie o riziku má byť explicitné:

Práve tu je ISO 27001:2022 dôležitá. Norma vyžaduje kontext, zainteresované strany, vedenie, posúdenie rizík, plánovanie ošetrenia rizík, prevádzkové riadenie, monitorovanie, vnútorný audit, preskúmanie manažmentom a neustále zlepšovanie. Únava z MFA sa dotýka všetkých týchto oblastí.

Klastre kontrol ISO 27001:2022, ktoré budú audítori testovať

ISO 27001:2022 poskytuje štruktúru systému manažérstva. ISO/IEC 27002:2022 poskytuje implementačné usmernenia ku kontrolám. Pri únave z MFA a útokoch typu push bombing sa audítori zvyčajne zamerajú na klaster kontrol, nie na jednu samostatnú kontrolu.

Zenith Controls: The Cross-Compliance Guide od Clarysec mapuje kontrolu ISO/IEC 27002:2022 8.5 Bezpečná autentifikácia na podporné kontroly, ako sú 5.17 Autentifikačné informácie, 8.2 Privilegované prístupové práva, 8.16 Monitorovanie aktivít, 5.24 Plánovanie a príprava riadenia incidentov informačnej bezpečnosti a 5.34 Ochrana súkromia a ochrana PII. Táto väzba naprieč kontrolami je dôležitá, pretože snímka obrazovky s informáciou „MFA zapnuté“ nestačí. Audítori chcú dôkaz, že autentifikácia je navrhnutá, monitorovaná, preskúmavaná a zlepšovaná na základe rizika.

Obhájiteľný balík dôkazov má obsahovať:

1. Posúdenie rizík identifikujúce push bombing a sociálne inžinierstvo pri výzvach MFA.
2. Štandard autentifikácie definujúci prípustné metódy MFA podľa kritickosti systému.
3. Politiku privilegovaného prístupu vyžadujúcu silnejšiu autentifikáciu pre administrátorský a vzdialený prístup.
4. Export konfigurácie poskytovateľa identít zobrazujúci párovanie čísel, limity výziev, podmienený prístup a blokovanú zastaranú autentifikáciu.
5. Logy zobrazujúce úspešné a neúspešné udalosti MFA, zamietnuté výzvy, nemožné cestovanie a kontext zariadenia.
6. Pravidlá upozornení na opakované výzvy MFA, opakované zlyhania a neobvyklé úspešné schválenie.
7. Záznamy reakcie na incidenty pre upozornenia súvisiace s autentifikáciou.
8. Obsah školenia povedomia, ktorý používateľom prikazuje neschvaľovať neočakávané výzvy.
9. Záznamy revízie prístupových práv pre privilegované systémy a systémy s vysokým dopadom.
10. Register výnimiek s dátumami skončenia platnosti, schváleniami vlastníkov rizík a kompenzačnými kontrolami.

Politika premieňa „neschvaľujte neočakávané výzvy“ na dôkazy

Mnohé organizácie používateľom hovoria, aby neschvaľovali podozrivé výzvy. Táto rada je užitočná, ale nestačí na certifikáciu ISO 27001:2022, dohľad podľa NIS2, odolnosť podľa DORA, preukázateľnú zodpovednosť podľa GDPR, due diligence zákazníkov ani kybernetické poistenie.

Prvou oporou v politike je P38 Politika bezpečnej komunikácie a viacfaktorovej autentifikácie (MFA). Priamo rieši ľudský faktor:

Povedomie používateľov: Používatelia musia absolvovať školenie na rozlíšenie bezpečných a nebezpečných komunikačných kanálov. Školenie musí pokrývať správne používanie viacfaktorovej autentifikácie (MFA) (napr. neschvaľovanie neočakávaných výziev na prihlásenie) a bezpečné komunikačné postupy (napr. overovanie odkazov na videokonferencie a neprerokúvanie dôverných tém cez nezabezpečené linky).

Tým sa únava z MFA mení na školiacu povinnosť, nie na hľadanie vinníka. CISO môže preukázať, že prompt bombing je zahrnutý do procesu nástupu, obnovovacieho školenia, školenia podľa rolí a poučení pre privilegovaných používateľov.

Tá istá P38 Politika bezpečnej komunikácie a viacfaktorovej autentifikácie (MFA) vytvára aj monitorovaciu povinnosť:

Informačná bezpečnosť musí priebežne monitorovať autentifikačné logy na akékoľvek pokusy o prihlásenie iba jedným faktorom alebo anomálne zlyhania viacfaktorovej autentifikácie (MFA). Logy zo systémov bezpečnej komunikácie sa tam, kde je to relevantné, musia monitorovať na pokusy o neoprávnený prístup alebo konfiguračné zmeny.

Pre MSP stanovuje P11S Politika správy používateľských účtov a oprávnení – MSP praktickú základnú úroveň:

Viacfaktorová autentifikácia (MFA) musí byť zapnutá, ak je to technicky uskutočniteľné, pre administrátorské účty alebo citlivé systémy.

Formulácia „ak je to technicky uskutočniteľné“ sa nikdy nesmie stať medzerou. Ak systém nepodporuje silnú MFA, výnimka musí byť zaznamenaná s vlastníkom, dátumom skončenia platnosti, kompenzačnými kontrolami, monitorovaním a plánom migrácie. Väčšie organizácie môžu rovnaké očakávanie zosúladiť s P11 Politika správy používateľských účtov a oprávnení a následne testovať, či sa politika zhoduje s prevádzkovou realitou.

Dôkazy detekcie vychádzajú z P22S Politika logovania a monitorovania – MSP, ktorá vyžaduje logovanie autentifikačných udalostí:

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

Vyžaduje aj bezodkladné preskúmanie vysokorizikových autentifikačných signálov:

Okamžité preskúmanie po detekcii upozornení s vysokou závažnosťou (napr. malvér, zlyhaná viacfaktorová autentifikácia (MFA), opakované zlyhania prihlásenia)

Povedomie sa musí vyvíjať spolu s hrozbami. Politika povedomia a školenia o informačnej bezpečnosti – MSP podporuje túto spätnú väzbu:

Témy musia zahŕňať nové hrozby (napr. phishing), relevantné zmeny politík a interné trendy incidentov.

Keď SOC deteguje pokusy o únavu z MFA, tieto informácie o hrozbách majú vstúpiť do upozornení používateľom, skriptov helpdesku, stolových cvičení a aktualizácií školení.

Riadený balík kontrol pre únavu z MFA

Predpokladajme, že vaša organizácia používa cloudového poskytovateľa identít, SaaS CRM, finančnú platformu, VPN a poskytovateľa riadených bezpečnostných služieb. Cieľom je riadiť únavu z MFA pomocou Zenith Blueprint, knižnice politík a príručky Zenith Controls pre súlad naprieč rámcami od Clarysec.

Začnite krokom Step 19 v Zenith Blueprint, ktorý tímom ukladá definovať požiadavky na autentifikáciu pre každý systém a upozorňuje, že autentifikácii založenej iba na hesle sa treba vyhnúť pri administrátorských účtoch, cloudových konzolách, nástrojoch vzdialeného prístupu a systémoch dostupných z internetu. Potom uplatnite praktickú aktivitu preskúmania:

Preskúmajte svoje nasadenie MFA: identifikujte medzery a naplánujte ich odstránenie. Overte, že servisné účty sú neinteraktívne tam, kde je to možné, majú silné poverenia a sú zdokumentované. Potvrďte, že v žiadnom systéme ani aplikácii nezostali predvolené poverenia.

Premeňte toto usmernenie na prevádzkový balík kontrol.

Krok 1: klasifikujte systémy podľa autentifikačného rizika

Krok 2: odstráňte vysokorizikové push správanie

Pre administrátorské účty a účty s vysokým dopadom vypnite základné push schvaľovanie. Tam, kde je to možné, používajte autentifikátory odolné voči phishingu. Ak push zostáva, vynucujte párovanie čísel, kontext aplikácie, geografický kontext, väzbu na zariadenie a limity frekvencie výziev. Blokujte zastaranú autentifikáciu a vyžadujte opätovnú autentifikáciu pri rizikových reláciách.

Krok 3: definujte pravidlá upozornení pre únavu z MFA

Praktické pravidlo SIEM sa má spustiť, keď sa v krátkom časovom okne vyskytne jeden alebo viac z týchto vzorov:

• Tri alebo viac MFA push výziev pre jedného používateľa.
• Dve zamietnuté výzvy nasledované jednou schválenou výzvou.
• Schválenie MFA z novej geografickej lokality alebo nespravovaného zariadenia.
• Výzva MFA po signáli password spraying alebo credential stuffing.
• Schválenie MFA pre privilegovaný prístup mimo bežných pracovných hodín.
• Registrácia nového autentifikátora krátko po neúspešných pokusoch o prihlásenie.

Upozornenie má vytvoriť incidentný ticket, informovať SOC alebo vedúceho bezpečnosti a vyžadovať kroky zamedzenia šírenia: pozastaviť reláciu, zrušiť refresh tokeny, vyžadovať resetovanie hesla, overiť zariadenie, vypočuť používateľa, preskúmať prístup počas relácie a klasifikovať, či došlo k dopadu na osobné údaje alebo kritickú službu.

Krok 4: prepojte záznamy ochrany súkromia a incidentov

Ak účet môže pristupovať k osobným údajom, uplatnite Politiku bezpečnosti a riadenia prístupu k osobným údajom. Vyžaduje silnú autentifikáciu pred prístupom k osobným údajom s vysokým dopadom:

[Obe roly] Vedúci informačnej bezpečnosti MUSÍ vyžadovať silnú autentifikáciu pre privilegovaný, vzdialený, administratívny prístup alebo prístup k osobným údajom s vysokým dopadom pred tým, ako sa takýto prístup povolí, a zaznamenať požiadavku v REG12.

Vyžaduje tiež definovanie rozsahu logovania:

[Obe roly] Vlastník systému / vlastník aplikácie MUSÍ pred produkčným použitím alebo podstatnou zmenou definovať v REG12 rozsah logovania osobných údajov pre autentifikačné udalosti, udalosti prístupu, privilegované akcie, export PII a podstatné konfiguračné zmeny.

Keď monitorovanie naznačuje neoprávnený prístup k PII, vzniká povinnosť záznamu incidentu:

[Podmienené] Koordinátor reakcie na incidenty MUSÍ do jedného pracovného dňa otvoriť alebo prepojiť záznam REG10, keď monitorovanie naznačuje podozrenie na neoprávnený prístup k PII, podozrenie na poskytnutie PII, podozrenie na zmenu PII alebo podozrenie na stratu dostupnosti PII.

Eskaláciu ochrany súkromia uzatvára Politika riadenia incidentov a porušení ochrany osobných údajov:

[Podmienené] Vedúci ochrany súkromia / manažér PIMS MUSÍ pre každý incident s vysokým dopadom týkajúci sa osobných údajov vyhodnotiť uplatniteľné právne, odvetvové, finančno-sektorové, kyberbezpečnostné, zmluvné, zákaznícke a príjemcovské spúšťače hlásenia a zaznamenať výsledok uplatniteľnosti v REG01, REG08 a REG10.

Takto sa upozornenie MFA mení na dôkazy pripravené na audit naprieč bezpečnosťou, ochranou súkromia a súladom.

NIS2, DORA a GDPR: jeden incident, rôzne otázky

Únava z MFA je užitočným záťažovým testom súladu naprieč rámcami, pretože sa dotýka riadenia, kybernetickej hygieny, riadenia prístupu, detekcie incidentov, prístupu dodávateľov a oznamovania porušení.

NIS2: zodpovednosť vedenia a kybernetická hygiena

NIS2 sa vzťahuje na mnohé základné a dôležité subjekty v závislosti od sektora, veľkosti a určenia členským štátom. Article 20 ukladá riadiacim orgánom zodpovednosť schvaľovať opatrenia riadenia kybernetických rizík, dohliadať na ich implementáciu a absolvovať školenie. Article 21 vyžaduje primerané technické, prevádzkové a organizačné opatrenia vrátane riešenia incidentov, kybernetickej hygieny, bezpečnosti dodávateľského reťazca, riadenia prístupu, správy aktív, školení a viacfaktorovej alebo priebežnej autentifikácie tam, kde je to vhodné. Article 23 zavádza etapové oznamovacie povinnosti pri významných incidentoch vrátane včasného varovania do 24 hodín od zistenia a oznámenia incidentu do 72 hodín.

Incident push bombing sa preto stáva otázkou na úrovni predstavenstva: bola MFA bezpečne navrhnutá, alebo iba zapnutá?

DORA: autentifikácia ako digitálna prevádzková odolnosť

Pre dotknuté finančné subjekty sa DORA uplatňuje od 17. januára 2025. Očakáva riadenie rizika IKT, detekciu, reakciu, obnovu, hlásenie incidentov, testovanie digitálnej prevádzkovej odolnosti a riadenie rizika IKT tretích strán.

DORA Article 9 sa venuje ochrane a prevencii vrátane riadenia prístupu a autentifikačných opatrení. Article 10 sa venuje detekcii anomálnej aktivity. Article 17 vyžaduje proces riadenia incidentov súvisiacich s IKT. V kontexte DORA majú dôkazy o únave z MFA ukazovať, že dotknuté IKT aktíva boli identifikované, monitorovanie detegovalo anomálne správanie, incident bol klasifikovaný pomocou kritérií dopadu, vrcholovému manažmentu bol eskalovaný tam, kde sa to vyžadovalo, a získané poučenia boli premietnuté späť do rámca riadenia rizík IKT.

GDPR: bezpečnosť spracúvania a preukázateľná zodpovednosť

GDPR Article 5(1)(f) vyžaduje integritu a dôvernosť. Article 5(2) vyžaduje preukázateľnú zodpovednosť. Article 32 vyžaduje bezpečnosť primeranú riziku. Article 4 definuje porušenie ochrany osobných údajov ako porušenie bezpečnosti, ktoré vedie k náhodnému alebo nezákonnému zničeniu, strate, zmene, neoprávnenému poskytnutiu osobných údajov alebo prístupu k nim.

Ak sa incident únavy z MFA dotkne osobných údajov, otázka dôkazov je jednoduchá: dokáže organizácia preukázať primerané autentifikačné kontroly, monitorovanie, reakciu na incidenty a posúdenie porušenia ochrany osobných údajov?

Prevodová mapa pre ISO, NIST CSF 2.0, COBIT 2019 a auditné dôkazy

NIST CSF 2.0 je užitočný, pretože premieňa riadenie MFA na výsledky GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND a RECOVER.

COBIT 2019 pridáva jasnosť riadenia. Audítor orientovaný na COBIT sa môže zamerať na DSS05.04 Manage identity and logical access, DSS05 Manage security services, APO13 Managed security a MEA03 Managed compliance with external requirements. Ťažiskom nie je dodávateľ MFA. Ide o to, či autentifikácia podporuje ciele organizácie, či sú prístupové práva riadené, či je monitorovanie účinné a či manažment dostáva zmysluplné uistenie.

Konsolidované mapovanie pomáha tímom súladu vyhnúť sa roztriešteným požiadavkám na dôkazy:

Čo si vyžiadajú audítori a regulátori

Silný program pre únavu z MFA musí obstáť pri viacerých štýloch auditu. Príručka Zenith Controls od Clarysec pre súlad naprieč rámcami ukazuje, ako sa kontroly ISO/IEC 27002:2022 testujú naprieč metodikami ISO, NIST, COBIT a ISACA.

Slabý program povie: „Opýtali sme sa používateľa a resetovali heslo.“ Riadený program vytvorí upozornenie SIEM, incidentný ticket, záznam zrušenia relácie, dôkazy resetovania hesla, preskúmanie faktora MFA, analýzu prístupových logov, posúdenie PII, vyhodnotenie spúšťačov hlásenia, vyhlásenie o koreňovej príčine, nápravné opatrenia a vstup do preskúmania manažmentom.

30-dňový akčný plán riadenia únavy z MFA

Cieľom nie je dokonalosť za 30 dní. Cieľom je viditeľnosť, vlastníctvo a dôkazy.

1. týždeň: identifikácia a rozsah

• Uveďte všetkých poskytovateľov identít, VPN, cloudové konzoly, platformy SaaS a nástroje privilegovaného prístupu.
• Identifikujte systémy s osobnými údajmi, finančnými údajmi, prístupom do produkčného prostredia alebo funkciami s dopadom na služby.
• Exportujte aktuálne metódy MFA a výnimky.
• Identifikujte externé účty a účty dodávateľov.
• Pridajte únavu z MFA a push bombing do registra rizík.
• Priraďte vlastníka rizika a vlastníka ošetrenia rizika.

2. týždeň: posilnenie autentifikácie

• Vypnite zastaranú autentifikáciu.
• Vyžadujte MFA odolnú voči phishingu pre administrátorov tam, kde je to uskutočniteľné.
• Zapnite párovanie čísel a kontext aplikácie pre push MFA.
• Uplatnite podmienený prístup pre lokalitu, súlad stavu zariadenia a nemožné cestovanie.
• Obmedzte opakované push výzvy.
• Vyžadujte opätovnú autentifikáciu pri vysokorizikových akciách.
• Nastavte servisné účty ako neinteraktívne tam, kde je to možné.
• Zdokumentujte výnimky s dátumom skončenia platnosti a kompenzačnými kontrolami.

3. týždeň: monitorovanie a nácvik

• Zabezpečte, aby autentifikačné logy zachytávali úspech, zlyhanie, trvanie relácie a používanie MFA.
• Vytvorte pravidlá upozornení pre opakované výzvy, zamietnuté výzvy nasledované schválením, registráciu nového zariadenia a neobvyklú lokalitu.
• Otestujte upozornenia kontrolovanou simuláciou.
• Validujte vytvorenie a eskaláciu incidentného ticketu.
• Preškolte používateľov krátkym cvičením „neočakávaná výzva MFA“.
• Aktualizujte skripty helpdesku, aby bránili sociálnemu inžinierstvu pri resetovaní hesiel a opätovnej registrácii MFA.

4. týždeň: dôkazy a preskúmanie manažmentom

• Uložte exporty konfigurácie a snímky obrazovky.
• Zaznamenajte výsledky revízie prístupových práv.
• Prepojte absolvovanie školení s privilegovanými používateľmi.
• Preskúmajte incidenty a takmer vzniknuté incidenty.
• Aktualizujte Vyhlásenie o uplatniteľnosti a plán ošetrenia rizík.
• Predložte manažmentu zostatkové riziko a metriky.
• Naplánujte vzorkovanie vnútorného auditu.

Urobte únavu z MFA auditovateľnou skôr, než sa stane hlásiteľnou

Únava z MFA pripomína, že bezpečnostné kontroly zlyhávajú na rozhraniach: medzi identitou a monitorovaním, medzi politikou a školením, medzi dodávateľmi a interným prístupom, medzi reakciou na incidenty a hlásením v oblasti ochrany súkromia.

Organizácie, ktoré ju zvládajú dobre, nielen „zapnú MFA“. Riadia autentifikáciu ako životný cyklus, monitorujú ju ako signál hrozby, školia používateľov ako súčasť kontroly a uchovávajú dôkazy ako súčasť ISMS.

Clarysec spája tri aktíva:

• Zenith Blueprint: An Auditor’s 30-Step Roadmap, najmä Step 19 pre bezpečnú autentifikáciu, Step 22 pre autentifikačné informácie a Step 16 pre nahlasovanie incidentov založené na personáli.
• Šablóny politík Clarysec vrátane P38 Politika bezpečnej komunikácie a viacfaktorovej autentifikácie (MFA), P22S Politika logovania a monitorovania – MSP, P11S Politika správy používateľských účtov a oprávnení – MSP, Politika povedomia a školenia o informačnej bezpečnosti – MSP, Politika bezpečnosti a riadenia prístupu k osobným údajom a Politika riadenia incidentov a porušení ochrany osobných údajov.
• Zenith Controls: The Cross-Compliance Guide, ktorý mapuje kontroly ISO/IEC 27002:2022 5.17, 8.5, 8.15 a 8.16 na podporné kontroly, očakávania auditu ISO, GDPR, NIS2, DORA, NIST a COBIT.

Ak ste CISO, manažér súladu, audítor alebo člen vedenia organizácie, vykonajte jednotýždňové preskúmanie dôkazov k únave z MFA. Stiahnite svoju konfiguráciu MFA, autentifikačné logy, zoznam privilegovaných prístupov, zoznam prístupov dodávateľov, incidentný playbook, školiace materiály a register výnimiek. Ak tieto artefakty nerozprávajú jeden konzistentný príbeh, Clarysec vám môže pomôcť vybudovať balík kontrol skôr, než si ho vyžiada útočník, audítor alebo regulátor.

Preskúmajte Zenith Blueprint, pozrite si Zenith Controls alebo si naplánujte úvodný rozhovor s Clarysec, aby ste únavu z MFA premenili z prekvapenia na úrovni predstavenstva na obhájiteľný a auditovateľný autentifikačný program.