Řízení únavy z MFA a útoků push bombing

Push oznámení ve 2:13 ráno, ze kterého se stala otázka pro správní radu

Ve 2:13 ráno obdrží seniorní finanční administrátorka mobilní oznámení: „Schválit přihlášení?“ Je v polospánku, předpokládá, že jde o vypršení relace v cloudové finanční platformě, a klepne na schválit.

Ve 2:19 je útočník uvnitř poskytovatele identity. Ve 2:31 se pokouší získat přístup k exportu mezd, privilegované cloudové konzoli a sdílené poštovní schránce používané pro platby dodavatelům. Ve 3:05 SOC vidí opakované výzvy MFA, neobvyklou geografickou polohu, úspěšné schválení a novou relaci z nespravovaného zařízení.

Ranní diskuse zní povědomě:

• „Ale měli jsme MFA.“
• „Proč to uživatelka schválila?“
• „Protokolovali jsme podrobnosti výzvy MFA?“
• „Jde o porušení zabezpečení osobních údajů?“
• „Máme oznamovací povinnosti do 24 hodin nebo do 72 hodin?“
• „Bude to náš auditor ISO 27001:2022 považovat za selhání opatření?“
• „Má to dopad na NIS2, DORA, GDPR, zákaznické smlouvy nebo kybernetické pojištění?“

Právě zde vzniká mezera ve správě a řízení za únavou z MFA a push bombingem. Útočníci neprolamují kryptografii. Vyčerpávají lidské rozhodování, zneužívají slabý návrh autentizace a hledají nemonitorované výjimky. Selháním opatření je jen zřídka „MFA nebylo zapnuto“. Obvykle jde o řetězec slabé záruky identity, rizikového návrhu push schvalování, chybějícího porovnání čísla, nejasných pravidel privilegovaného přístupu, nedostatečného protokolování autentizace, slabého vyhodnocování upozornění, nedostatečně proškolených uživatelů a chybějících dokumentovaných důkazů, že organizace slabinu přezkoumala a napravila.

Pro CISO, manažery compliance, auditory a vlastníky společností musí být únava z MFA řešena jako problém důkazů v ISMS, nikoli pouze jako nastavení poskytovatele identity. Odpověď kombinuje ošetření rizik podle ISO 27001:2022, opatření ISO/IEC 27002:2022, povinnosti vyplývající z politik, bezpečnostní povědomí uživatelů, reakci na incidenty, řízení dodavatelů a mapování napříč rámci pro NIS2, DORA, GDPR, NIST CSF 2.0 a COBIT 2019.

Únava z MFA je selháním záruky, nikoli problémem uživatele

Únava z MFA, označovaná také jako push bombing nebo zahlcení výzvami, nastává tehdy, když útočník s platným heslem opakovaně spouští žádosti o schválení MFA, dokud uživatel jednu z nich nepřijme. Někdy útočník přidá sociální inženýrství, například falešný hovor z helpdesku, zprávu typu „testujeme váš účet“ nebo žádost o schválení přihlášení, aby oznámení přestala chodit.

Provozní riziko spočívá v tom, že organizace často považují všechna MFA za rovnocenná. Nejsou.

Jednoduché push oznámení „schválit nebo zamítnout“ je slabší než porovnání čísla, bezpečnostní klíče FIDO2 odolné vůči phishingu, autentizace založená na certifikátech nebo podmíněný přístup, který blokuje nemožné cestování a nespravovaná zařízení. MFA selhává také tehdy, když nejsou dokumentovány výjimky z obcházení, servisní účty jsou interaktivní, starší protokoly zůstávají povolené nebo vysoce rizikový přístup nevyžaduje silnější autentizaci.

V Zenith Blueprint: 30kroková roadmapa auditora Clarysec zasazuje bezpečnou autentizaci do fáze Zavedení opatření do praxe, krok 19: Technologická opatření I. Doporučení je přímé:

Autentizace je první a nejkritičtější linie obrany mezi aktérem hrozby a vašimi systémy, daty a službami. Pokud je autentizace slabá, vše ostatní – šifrování, monitorování i segmentaci – lze obejít.

Stejný Zenith Blueprint se v kroku 22 věnuje také opatření ISO/IEC 27002:2022 5.17:

Pokud je identita otázkou „Kdo jste?“, autentizace je důkazem. Opatření 5.17 je místem, kde se teorie potkává s důvěrou. Vyžaduje, aby autentizační informace byly bezpečně spravovány po celý svůj životní cyklus a aby se metody a přihlašovací údaje používané k ověření identity samy nestaly nejslabším článkem.

Tato dvě tvrzení vysvětlují, proč push bombing patří do registru rizik. Šifrování nepomůže, pokud se útočník stane schváleným uživatelem. Segmentace sítě pomůže méně, pokud je privilegovaný cloudový přístup schválen přes výzvu, kterou uživatel odklikne z únavy. Monitorování funguje pouze tehdy, pokud jsou události autentizace protokolovány v dostatečném detailu a rychle přezkoumávány.

Vyspělý popis rizika má být explicitní:

Zde vstupuje do hry ISO 27001:2022. Norma vyžaduje kontext, zainteresované strany, vedení, posouzení rizik, plánování ošetření, operativní řízení, monitorování, interní audit, přezkoumání vedením a neustálé zlepšování. Únava z MFA se dotýká všech těchto oblastí.

Shluk opatření ISO 27001:2022, který budou auditoři testovat

ISO 27001:2022 poskytuje strukturu systému řízení. ISO/IEC 27002:2022 poskytuje implementační doporučení pro opatření. U únavy z MFA a push bombingu se auditoři obvykle zaměří spíše na shluk opatření než na jediné opatření.

Zenith Controls: Průvodce souladem napříč rámci od Clarysec mapuje opatření ISO/IEC 27002:2022 8.5 Bezpečná autentizace na podpůrná opatření, jako jsou 5.17 Autentizační informace, 8.2 Oprávnění privilegovaného přístupu, 8.16 Monitorovací činnosti, 5.24 Plánování a příprava řízení incidentů informační bezpečnosti a 5.34 Ochrana soukromí a ochrana PII. Toto provázání je důležité, protože screenshot s textem „MFA zapnuto“ nestačí. Auditoři chtějí důkaz, že autentizace je navržena, monitorována, přezkoumávána a zlepšována na základě rizik.

Obhajitelný balíček důkazů má obsahovat:

1. Posouzení rizik identifikující push bombing a sociální inženýrství u výzev MFA.
2. Standard autentizace definující přípustné metody MFA podle kritičnosti systému.
3. Politiku privilegovaného přístupu vyžadující silnější autentizaci pro administrátorský a vzdálený přístup.
4. Export konfigurace poskytovatele identity dokládající porovnání čísla, limity výzev, podmíněný přístup a blokovanou starší autentizaci.
5. Logy dokládající úspěšné a neúspěšné události MFA, zamítnuté výzvy, nemožné cestování a kontext zařízení.
6. Pravidla upozornění pro opakované výzvy MFA, opakovaná selhání a neobvyklé úspěšné schválení.
7. Záznamy reakce na incidenty pro upozornění související s autentizací.
8. Obsah školení povědomí, který uživatelům ukládá neschvalovat neočekávané výzvy.
9. Záznamy o přezkumech přístupu k privilegovaným systémům a systémům s významným dopadem.
10. Registr výjimek s daty expirace, schváleními vlastníků rizik a kompenzačními opatřeními.

Politika mění „neschvalujte neočekávané výzvy“ na důkazy

Mnoho organizací uživatelům říká, aby neschvalovali podezřelé výzvy. Tato rada je užitečná, ale nestačí pro certifikaci ISO 27001:2022, dohled podle NIS2, odolnost podle DORA, odpovědnost podle GDPR, zákaznickou due diligence ani kybernetické pojištění.

Prvním opěrným bodem politiky je P38 Politika bezpečné komunikace a vícefaktorové autentizace (MFA). Přímo řeší lidskou stránku:

Povědomí uživatelů: Uživatelé musí absolvovat školení, aby dokázali rozlišit bezpečné a nezabezpečené komunikační kanály. Školení musí pokrývat správné používání vícefaktorové autentizace (MFA) (např. neschvalování neočekávaných výzev k přihlášení) a postupy bezpečné komunikace (např. ověřování odkazů na videokonference a neprobírání důvěrných témat přes nezabezpečené linky).

Tím se únava z MFA mění na povinnost školení, nikoli na hledání viníka. CISO tak může doložit, že push bombing je zahrnut v onboardingu, opakovacím školení, školení podle rolí a brífincích pro privilegované uživatele.

Stejná P38 Politika bezpečné komunikace a vícefaktorové autentizace (MFA) vytváří také povinnost monitorování:

Informační bezpečnost musí průběžně monitorovat autentizační logy z hlediska pokusů o přihlášení pouze jedním faktorem nebo anomálních selhání vícefaktorové autentizace (MFA). Logy ze systémů bezpečné komunikace, je-li to relevantní, musí být monitorovány z hlediska pokusů o neoprávněný přístup nebo změn konfigurace.

Pro malé a střední podniky stanoví P11S Politika správy uživatelských účtů a oprávnění pro malé a střední podniky praktický základ:

Vícefaktorová autentizace (MFA) musí být zapnuta, pokud je to technicky proveditelné, pro administrátorské účty nebo citlivé systémy.

Formulace „pokud je to technicky proveditelné“ se nikdy nesmí stát mezerou. Pokud systém nepodporuje silné MFA, výjimka musí být zaznamenána s vlastníkem, datem expirace, kompenzačními opatřeními, monitorováním a plánem migrace. Větší organizace mohou stejné očekávání sladit s P11 Politikou správy uživatelských účtů a oprávnění a následně ověřit, zda se politika shoduje s provozní realitou.

Důkazy o detekci vycházejí z P22S Politiky protokolování a monitorování pro malé a střední podniky, která vyžaduje protokolování autentizačních událostí:

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

Vyžaduje také neprodlený přezkum vysoce rizikových autentizačních signálů:

Okamžitý přezkum při detekci upozornění s vysokou závažností (např. malware, neúspěšná vícefaktorová autentizace (MFA), opakovaná selhání přihlášení)

Povědomí se musí vyvíjet spolu s hrozbami. Politika bezpečnostního povědomí a školení pro malé a střední podniky tento cyklus podporuje:

Témata musí zahrnovat nově vznikající hrozby (např. phishing), relevantní změny politik a interní trendy incidentů.

Když SOC detekuje pokusy o únavu z MFA, tyto informace mají vstupovat do upozornění pro uživatele, skriptů helpdesku, tabletop cvičení a aktualizací školení.

Řízený balíček opatření pro únavu z MFA

Předpokládejme, že vaše organizace používá cloudového poskytovatele identity, SaaS CRM, finanční platformu, VPN a poskytovatele řízených bezpečnostních služeb. Cílem je řídit únavu z MFA pomocí Zenith Blueprint, knihovny politik Clarysec a průvodce souladem napříč rámci Zenith Controls.

Začněte krokem 19 v Zenith Blueprint, který týmům ukládá definovat požadavky na autentizaci pro jednotlivé systémy a upozorňuje, že autentizaci pouze heslem je třeba se vyhnout u administrátorských účtů, cloudových konzolí, nástrojů vzdáleného přístupu a systémů dostupných z internetu. Poté použijte praktickou činnost přezkumu:

Přezkoumejte své nasazení MFA: identifikujte případné mezery a naplánujte jejich uzavření. Ověřte, že servisní účty jsou tam, kde je to možné, neinteraktivní, mají silné přihlašovací údaje a jsou dokumentovány. Potvrďte, že v žádném systému ani aplikaci nezůstaly výchozí přihlašovací údaje.

Převeďte toto doporučení do provozního balíčku opatření.

Krok 1: klasifikujte systémy podle autentizačního rizika

Krok 2: odstraňte vysoce rizikové push chování

U administrátorských účtů a účtů s významným dopadem vypněte základní push schvalování. Kde je to možné, používejte autentizátory odolné vůči phishingu. Pokud push výzvy zůstávají, vynucujte porovnání čísla, kontext aplikace, geografický kontext, vazbu na zařízení a limity četnosti výzev. Blokujte starší autentizaci a vyžadujte opětovnou autentizaci u rizikových relací.

Krok 3: definujte pravidla upozornění pro únavu z MFA

Praktické pravidlo SIEM se má spustit, pokud se v krátkém časovém okně vyskytne jeden nebo více z těchto vzorců:

• Tři nebo více push výzev MFA pro jednoho uživatele.
• Dvě zamítnuté výzvy následované jednou schválenou výzvou.
• Schválení MFA z nové geografické polohy nebo nespravovaného zařízení.
• Výzva MFA následující po signálu password spraying nebo credential stuffing.
• Schválení MFA pro privilegovaný přístup mimo běžnou pracovní dobu.
• Registrace nového autentizátoru krátce po neúspěšných pokusech o přihlášení.

Upozornění má vytvořit incidentní tiket, informovat SOC nebo vedoucího bezpečnosti a vyžadovat kroky k zamezení šíření: pozastavit relaci, zneplatnit refresh tokeny, vyžádat reset hesla, ověřit zařízení, provést rozhovor s uživatelem, přezkoumat přístup během relace a klasifikovat, zda došlo k dopadu na osobní údaje nebo kritickou službu.

Krok 4: propojte záznamy o soukromí a incidentech

Pokud účet může přistupovat k osobním údajům, použijte Politiku zabezpečení PII a řízení přístupu. Ta vyžaduje silnou autentizaci před přístupem k PII s významným dopadem:

[Obě role] Vedoucí informační bezpečnosti MUSÍ vyžadovat silnou autentizaci pro privilegovaný, vzdálený, administrativní přístup nebo přístup k PII s významným dopadem před jeho povolením a zaznamenat požadavek v REG12.

Vyžaduje také definování rozsahu protokolování:

[Obě role] Vlastník systému / vlastník aplikace MUSÍ před produkčním použitím nebo významnou změnou definovat v REG12 rozsah protokolování PII pro autentizační události, události přístupu, privilegované akce, exportní aktivity PII a významné změny konfigurace.

Pokud monitorování naznačuje neoprávněný přístup k PII, vzniká povinnost vytvořit záznam o incidentu:

[Podmíněně] Koordinátor reakce na incidenty MUSÍ do jednoho pracovního dne otevřít nebo propojit záznam REG10, pokud monitorování naznačuje podezření na neoprávněný přístup k PII, podezření na zpřístupnění PII, podezření na změnu PII nebo podezření na ztrátu dostupnosti PII.

Eskalaci v oblasti ochrany soukromí dokončuje Politika řízení incidentů a porušení zabezpečení PII:

[Podmíněně] Vedoucí ochrany soukromí / manažer PIMS MUSÍ u každého incidentu s významným dopadem týkajícího se PII vyhodnotit příslušné právní, odvětvové, finančně-sektorové, kybernetickobezpečnostní, smluvní, zákaznické a servisně-příjemcovské spouštěcí podmínky oznamování a zaznamenat výsledek použitelnosti v REG01, REG08 a REG10.

Tak se upozornění MFA mění na důkazy připravené pro audit napříč bezpečností, ochranou soukromí a compliance.

NIS2, DORA a GDPR: jeden incident, různé otázky

Únava z MFA je užitečný zátěžový test souladu napříč rámci, protože se dotýká správy a řízení, kybernetické hygieny, řízení přístupu, detekce incidentů, přístupu dodavatelů a oznamování porušení zabezpečení osobních údajů.

NIS2: odpovědnost vedení a kybernetická hygiena

NIS2 se vztahuje na řadu základních a důležitých subjektů v závislosti na odvětví, velikosti a určení členským státem. Article 20 ukládá odpovědnost vedoucím orgánům za schvalování opatření řízení kybernetických rizik, dohled nad jejich implementací a absolvování školení. Article 21 vyžaduje přiměřená technická, provozní a organizační opatření, včetně zvládání incidentů, kybernetické hygieny, bezpečnosti dodavatelského řetězce, řízení přístupu, správy aktiv, školení a vícefaktorové nebo průběžné autentizace tam, kde je to vhodné. Article 23 zavádí postupné oznamovací povinnosti pro významné incidenty, včetně včasného varování do 24 hodin od okamžiku zjištění a oznámení incidentu do 72 hodin.

Incident push bombingu se proto stává otázkou na úrovni správní rady: bylo MFA navrženo bezpečně, nebo pouze zapnuto?

DORA: autentizace jako digitální provozní odolnost

Pro regulované finanční entity se DORA použije od 17. ledna 2025. Očekává řízení rizik v oblasti ICT, detekci, reakci, obnovu, hlášení incidentů, testování digitální provozní odolnosti a řízení rizik třetích stran v oblasti ICT.

DORA Article 9 se věnuje ochraně a prevenci, včetně opatření řízení přístupu a autentizace. Article 10 se věnuje detekci anomálních činností. Article 17 vyžaduje proces řízení incidentů souvisejících s ICT. V kontextu DORA mají důkazy k únavě z MFA ukázat, že dotčená ICT aktiva byla identifikována, monitorování detekovalo anomální chování, incident byl klasifikován podle kritérií dopadu, vrcholovému vedení byla věc v případě potřeby eskalována a získané poznatky byly zpětně promítnuty do rámce řízení rizik v oblasti ICT.

GDPR: zabezpečení zpracování a odpovědnost

GDPR Article 5(1)(f) vyžaduje integritu a důvěrnost. Article 5(2) vyžaduje odpovědnost. Article 32 vyžaduje zabezpečení přiměřené riziku. Article 4 definuje porušení zabezpečení osobních údajů jako porušení zabezpečení vedoucí k náhodnému nebo protiprávnímu zničení, ztrátě, změně, neoprávněnému zpřístupnění osobních údajů nebo neoprávněnému přístupu k nim.

Pokud se incident únavy z MFA dotýká osobních údajů, otázka důkazů je jednoduchá: dokáže organizace prokázat přiměřená autentizační opatření, monitorování, reakci na incidenty a posouzení porušení zabezpečení osobních údajů?

Mapování ISO, NIST CSF 2.0, COBIT 2019 a auditních důkazů

NIST CSF 2.0 je užitečný, protože převádí řízení MFA na výsledky GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND a RECOVER.

COBIT 2019 přidává jasnost správy a řízení. Auditor orientovaný na COBIT se může zaměřit na DSS05.04 Manage identity and logical access, DSS05 Manage security services, APO13 Managed security a MEA03 Managed compliance with external requirements. Těžištěm není dodavatel MFA. Podstatné je, zda autentizace podporuje obchodní cíle, zda jsou přístupová práva řízena, zda je monitorování účinné a zda vedení dostává smysluplné ujištění.

Konsolidované mapování pomáhá týmům compliance vyhnout se roztříštěným požadavkům na důkazy:

Na co se budou ptát auditoři a regulační orgány

Silný program pro únavu z MFA musí obstát při různých stylech auditu. Průvodce souladem napříč rámci Zenith Controls od Clarysec ukazuje, jak jsou opatření ISO/IEC 27002:2022 testována napříč metodikami ISO, NIST, COBIT a ISACA.

Slabý program řekne: „Zeptali jsme se uživatele a resetovali heslo.“ Řízený program vytvoří upozornění SIEM, incidentní tiket, záznam o zneplatnění relace, důkaz o resetu hesla, přezkum faktoru MFA, analýzu logů přístupu, posouzení PII, vyhodnocení spouštěcích podmínek oznamování, formulaci kořenové příčiny, nápravná opatření a vstup do přezkoumání vedením.

30denní akční plán pro řízení únavy z MFA

Cílem není dokonalost za 30 dní. Cílem je viditelnost, vlastnictví a důkazy.

1. týden: identifikace a rozsah

• Uveďte všechny poskytovatele identity, VPN, cloudové konzole, SaaS platformy a nástroje privilegovaného přístupu.
• Identifikujte systémy s osobními údaji, finančními údaji, přístupem do produkčního prostředí nebo funkcemi s dopadem na službu.
• Exportujte aktuální metody MFA a výjimky.
• Identifikujte externí a dodavatelské účty.
• Přidejte únavu z MFA a push bombing do registru rizik.
• Přiřaďte vlastníka rizika a vlastníka ošetření.

2. týden: posílení autentizace

• Vypněte starší autentizaci.
• Vyžadujte MFA odolnou vůči phishingu pro správce tam, kde je to proveditelné.
• Zapněte porovnání čísla a kontext aplikace pro push MFA.
• Uplatněte podmíněný přístup pro lokalitu, soulad zařízení s požadavky a nemožné cestování.
• Omezte opakované push výzvy.
• Vyžadujte opětovnou autentizaci pro vysoce rizikové akce.
• Tam, kde je to možné, nastavte servisní účty jako neinteraktivní.
• Dokumentujte výjimky s expirací a kompenzačními opatřeními.

3. týden: monitorování a nácvik

• Zajistěte, aby autentizační logy zachycovaly úspěch, selhání, dobu trvání relace a používání MFA.
• Vytvořte pravidla upozornění pro opakované výzvy, zamítnuté výzvy následované schválením, registraci nového zařízení a neobvyklou lokalitu.
• Otestujte upozornění řízenou simulací.
• Ověřte vytvoření incidentního tiketu a eskalaci.
• Proškolte uživatele krátkým cvičením „neočekávaná výzva MFA“.
• Aktualizujte skripty helpdesku tak, aby předcházely sociálnímu inženýrství při resetech hesel a opětovné registraci MFA.

4. týden: důkazy a přezkoumání vedením

• Uložte exporty konfigurace a screenshoty.
• Zaznamenejte výsledky přezkumů přístupu.
• Propojte absolvování školení s privilegovanými uživateli.
• Přezkoumejte incidenty a téměř vzniklé incidenty.
• Aktualizujte Prohlášení o použitelnosti a plán ošetření.
• Předložte vedení zbytkové riziko a metriky.
• Naplánujte vzorkování v rámci interního auditu.

Udělejte únavu z MFA auditovatelnou dříve, než se stane oznamovatelnou

Únava z MFA připomíná, že bezpečnostní opatření selhávají na rozhraních: mezi identitou a monitorováním, mezi politikou a školením, mezi dodavateli a interním přístupem, mezi reakcí na incidenty a oznamováním v oblasti ochrany soukromí.

Organizace, které ji řídí dobře, MFA pouze „nezapnou“. Řídí autentizaci jako životní cyklus, monitorují ji jako signál hrozby, školí uživatele jako součást opatření a uchovávají důkazy jako součást ISMS.

Clarysec propojuje tři zdroje:

• Zenith Blueprint: 30kroková roadmapa auditora, zejména krok 19 pro bezpečnou autentizaci, krok 22 pro autentizační informace a krok 16 pro hlášení incidentů řízené personálem.
• Šablony politik Clarysec, včetně P38 Politiky bezpečné komunikace a vícefaktorové autentizace (MFA), P22S Politiky protokolování a monitorování pro malé a střední podniky, P11S Politiky správy uživatelských účtů a oprávnění pro malé a střední podniky, Politiky bezpečnostního povědomí a školení pro malé a střední podniky, Politiky zabezpečení PII a řízení přístupu a Politiky řízení incidentů a porušení zabezpečení PII.
• Zenith Controls: Průvodce souladem napříč rámci, který mapuje opatření ISO/IEC 27002:2022 5.17, 8.5, 8.15 a 8.16 na podpůrná opatření, očekávání auditu ISO, GDPR, NIS2, DORA, NIST a COBIT.

Pokud jste CISO, manažer compliance, auditor nebo vlastník společnosti, proveďte jednotýdenní přezkum důkazů k únavě z MFA. Získejte konfiguraci MFA, autentizační logy, seznam privilegovaných přístupů, seznam dodavatelských přístupů, playbook incidentů, školicí materiály a registr výjimek. Pokud tyto artefakty nevyprávějí jeden konzistentní příběh, Clarysec vám může pomoci vybudovat balíček opatření dříve, než si o něj řekne útočník, auditor nebo regulační orgán.

Prozkoumejte Zenith Blueprint, projděte si Zenith Controls nebo si naplánujte úvodní konzultaci s Clarysec a změňte únavu z MFA z překvapení pro správní radu na obhajitelný a auditovatelný program autentizace.