Styrning av MFA-trötthet och push bombing-attacker

Pushnotisen 02:13 som blev en styrelsefråga

Klockan 02:13 får en senior administratör på ekonomiavdelningen en mobil avisering: ”Godkänn inloggning?” Hon är halvvaken, antar att det rör sig om en timeout från en molnbaserad ekonomiplattform och trycker på godkänn.

Klockan 02:19 är angriparen inne hos identitetsleverantören. Klockan 02:31 försöker angriparen komma åt en löneexport, en privilegierad molnkonsol och en delad postlåda som används för leverantörsbetalningar. Klockan 03:05 ser SOC-teamet upprepade MFA-förfrågningar, avvikande geografisk plats, ett lyckat godkännande och en ny session från en icke-hanterad enhet.

Morgondialogen är välbekant:

• ”Men vi hade MFA.”
• ”Varför godkände användaren?”
• ”Loggade vi detaljerna för MFA-utmaningen?”
• ”Är detta en personuppgiftsincident?”
• ”Har vi rapporteringsskyldigheter inom 24 eller 72 timmar?”
• ”Kommer vår ISO 27001:2022-revisor att se detta som ett kontrollmisslyckande?”
• ”Påverkar detta NIS2, DORA, GDPR, kundavtal eller cyberförsäkringen?”

Detta är styrningsgapet bakom MFA-trötthet och push bombing. Angriparna knäcker inte kryptografi. De tröttar ut mänskligt beslutsfattande, utnyttjar svag autentiseringsdesign och letar efter undantag som inte övervakas. Kontrollmisslyckandet är sällan ”MFA var inte aktiverat”. Det är oftare en kedja av svag identitetssäkring, riskfylld design för push-godkännande, avsaknad av nummermatchning, otydliga regler för privilegierad åtkomst, otillräcklig autentiseringsloggning, svag larmtriagering, otillräckligt utbildade användare och avsaknad av dokumenterat underlag som visar att organisationen har granskat och åtgärdat svagheten.

För informationssäkerhetschefer, chefer för regelefterlevnad, revisorer och verksamhetsägare måste MFA-trötthet behandlas som en ISMS-fråga om underlag, inte enbart som en inställning hos identitetsleverantören. Svaret kombinerar ISO 27001:2022-riskbehandling, ISO/IEC 27002:2022-kontroller, policykrav, användarmedvetenhet, incidentrespons, leverantörsstyrning och mappningar mellan ramverk för NIS2, DORA, GDPR, NIST CSF 2.0 och COBIT 2019.

MFA-trötthet är ett bristande säkerhetsförsäkransläge, inte ett användarproblem

MFA-trötthet, även kallat push bombing eller prompt bombing, uppstår när en angripare med ett giltigt lösenord upprepade gånger utlöser MFA-godkännandeförfrågningar tills användaren accepterar en av dem. Ibland lägger angriparen till social manipulation, exempelvis ett falskt samtal från helpdesk, ett meddelande om att ”vi testar ditt konto” eller en begäran om att godkänna en inloggning för att stoppa aviseringarna.

Den operativa risken är att organisationer ofta behandlar all MFA som likvärdig. Det är den inte.

En enkel pushnotis med ”godkänn eller neka” är svagare än nummermatchning, phishingresistenta FIDO2-säkerhetsnycklar, certifikatbaserad autentisering eller villkorlig åtkomst som blockerar omöjlig resa och icke-hanterade enheter. MFA fallerar också när förbikopplingsundantag inte är dokumenterade, tjänstekonton kan användas interaktivt, äldre protokoll fortfarande är öppna eller högriskåtkomst inte kräver starkare autentisering.

I Zenith Blueprint: en färdplan i 30 steg för revisorer placerar Clarysec säker autentisering i fasen aktiva kontroller, steg 19: tekniska kontroller I. Vägledningen är tydlig:

Autentisering är den första och mest kritiska försvarslinjen mellan en hotaktör och era system, data och tjänster. Om autentiseringen är svag kan allt annat – kryptering, övervakning och segmentering – kringgås.

Samma Zenith Blueprint behandlar även ISO/IEC 27002:2022-kontroll 5.17 i steg 22:

Om identitet är frågan ”Vem är du?”, är autentisering beviset. Kontroll 5.17 är där teori möter tillit. Den kräver att autentiseringsinformation hanteras säkert under hela sin livscykel, så att de metoder och autentiseringsuppgifter som används för att verifiera identitet inte själva blir den svagaste länken.

Dessa två uttalanden förklarar varför push bombing hör hemma i riskregistret. Kryptering hjälper inte om angriparen blir en godkänd användare. Nätverkssegmentering hjälper mindre om privilegierad molnåtkomst godkänns genom en förfrågan till en uttröttad användare. Övervakning fungerar bara om autentiseringshändelser loggas med tillräcklig detaljeringsgrad och granskas snabbt.

En mogen riskformulering bör vara explicit:

Här blir ISO 27001:2022 relevant. Standarden kräver kontext, intressenter, ledarskap, riskbedömning, behandlingsplanering, operativ styrning, övervakning, internrevision, ledningens genomgång och ständig förbättring. MFA-trötthet berör dem alla.

Kontrollklustret i ISO 27001:2022 som revisorer kommer att testa

ISO 27001:2022 ger strukturen för ledningssystemet. ISO/IEC 27002:2022 ger vägledning för genomförande av kontroller. För MFA-trötthet och push bombing fokuserar revisorer normalt på ett kontrollkluster snarare än en enskild kontroll.

Clarysecs Zenith Controls: guiden för efterlevnad av flera ramverk mappar ISO/IEC 27002:2022-kontroll 8.5 Säker autentisering till stödjande kontroller som 5.17 Autentiseringsinformation, 8.2 Privilegierade åtkomsträttigheter, 8.16 Övervakningsaktiviteter, 5.24 Planering och förberedelse för hantering av informationssäkerhetsincidenter och 5.34 Integritet och skydd av PII. Denna korskoppling är viktig eftersom en skärmbild som visar ”MFA aktiverat” inte räcker. Revisorer vill ha bevis för att autentisering är utformad, övervakad, granskad och förbättrad utifrån risk.

Ett försvarbart underlagspaket bör innehålla:

1. Riskbedömning som identifierar push bombing och social manipulation av MFA-förfrågningar.
2. Autentiseringsstandard som definierar godtagbara MFA-metoder efter systemkritikalitet.
3. Policy för privilegierad åtkomst som kräver starkare autentisering för administratörs- och fjärråtkomst.
4. Konfigurationsexport från identitetsleverantören som visar nummermatchning, begränsning av förfrågningar, villkorlig åtkomst och blockerad äldre autentisering.
5. Loggar som visar lyckade och misslyckade MFA-händelser, nekade förfrågningar, omöjlig resa och enhetskontext.
6. Larmregler för upprepade MFA-förfrågningar, upprepade fel och avvikande lyckade godkännanden.
7. Incidentresponsunderlag för autentiseringsrelaterade larm.
8. Innehåll för medvetenhetsutbildning som instruerar användare att inte godkänna oväntade förfrågningar.
9. Åtkomstgranskningsposter för privilegierade system och system med hög påverkan.
10. Undantagsregister med utgångsdatum, godkännanden från riskägare och kompenserande kontroller.

Policy gör ”godkänn inte oväntade förfrågningar” till underlag

Många organisationer säger åt användare att inte godkänna misstänkta förfrågningar. Rådet är användbart, men det räcker inte för ISO 27001:2022-certifiering, NIS2-tillsyn, DORA-resiliens, ansvarsskyldighet enligt GDPR, kunders leverantörsgranskning eller cyberförsäkring.

Den första policyankaren är P38 Policy för säker kommunikation och flerfaktorsautentisering (MFA). Den behandlar den mänskliga sidan direkt:

Användarmedvetenhet: Användare ska få utbildning i att skilja säkra kommunikationskanaler från osäkra. Utbildningen ska omfatta korrekt användning av flerfaktorsautentisering (MFA) (t.ex. att inte godkänna oväntade inloggningsförfrågningar) och säker kommunikationspraxis (t.ex. att verifiera länkar till videokonferenser och inte diskutera konfidentiella ämnen över oskyddade linjer).

Detta gör MFA-trötthet till en utbildningsskyldighet, inte en övning i skuldbeläggning. Det gör det möjligt för informationssäkerhetschefen att visa att prompt bombing omfattas av introduktion, repetitionsutbildning, rollbaserad utbildning och genomgångar för privilegierade användare.

Samma P38 Policy för säker kommunikation och flerfaktorsautentisering (MFA) skapar också en övervakningsskyldighet:

Informationssäkerhet ska fortlöpande övervaka autentiseringsloggar för eventuella inloggningsförsök med enfaktorsautentisering eller avvikande fel i flerfaktorsautentisering (MFA). Loggar från system för säker kommunikation ska, där det är tillämpligt, övervakas för obehöriga åtkomstförsök eller konfigurationsändringar.

För små och medelstora företag anger P11S Policy för hantering av användarkonton och privilegier – SME en praktisk baslinje:

Flerfaktorsautentisering (MFA) måste vara aktiverad, där det är tekniskt möjligt, för administratörskonton eller känsliga system.

Formuleringen ”där det är tekniskt möjligt” får aldrig bli ett kryphål. Om ett system inte kan stödja stark MFA måste undantaget registreras med ägare, utgångsdatum, kompenserande kontroller, övervakning och en migreringsplan. Större organisationer kan anpassa samma förväntan till P11 Policy för hantering av användarkonton och privilegier och därefter testa om policy och operativ verklighet överensstämmer.

Detekteringsunderlag kommer från P22S Loggnings- och övervakningspolicy – SME, som kräver loggning av autentiseringshändelser:

Autentiseringsloggar: lyckade och misslyckade inloggningsförsök, sessionslängd, MFA-användning

Den kräver också omedelbar granskning av högriskindikatorer för autentisering:

Omedelbar granskning vid detektering av larm med hög allvarlighetsgrad (t.ex. skadlig kod, misslyckad flerfaktorsautentisering (MFA), upprepade misslyckade inloggningar)

Medvetenhet måste utvecklas i takt med hoten. Policy för informationssäkerhetsmedvetenhet och utbildning – SME stödjer den återkopplingsloopen:

Ämnen ska omfatta framväxande hot (t.ex. phishing), relevanta policyändringar och interna incidenttrender.

När SOC-teamet upptäcker försök till MFA-trötthet ska denna information användas i användarlarm, helpdeskmanus, skrivbordsövningar och utbildningsuppdateringar.

Ett styrt kontrollpaket för MFA-trötthet

Anta att organisationen använder en molnbaserad identitetsleverantör, ett SaaS-baserat CRM, en ekonomiplattform, ett VPN och en hanterad säkerhetsleverantör. Målet är att styra MFA-trötthet med hjälp av Clarysecs Zenith Blueprint, policybibliotek och Zenith Controls-guide för efterlevnad av flera ramverk.

Börja med steg 19 i Zenith Blueprint, som instruerar team att definiera autentiseringskrav per system och varnar för att autentisering med enbart lösenord bör undvikas för administratörskonton, molnkonsoler, verktyg för fjärråtkomst och internetexponerade system. Tillämpa därefter den praktiska granskningsaktiviteten:

Granska er MFA-täckningsgrad: identifiera eventuella luckor och planera hur de ska stängas. Validera att tjänstekonton är icke-interaktiva där det är möjligt, har starka autentiseringsuppgifter och är dokumenterade. Bekräfta att inga standardautentiseringsuppgifter finns kvar i något system eller någon applikation.

Omvandla denna vägledning till ett operativt kontrollpaket.

Steg 1: klassificera system efter autentiseringsrisk

Steg 2: ta bort högriskbeteenden i pushflöden

För administratörskonton och konton med hög påverkan ska grundläggande push-godkännande inaktiveras. Använd phishingresistenta autentiserare där det är möjligt. Där push finns kvar ska nummermatchning, applikationskontext, geografisk kontext, enhetsbindning och begränsningar av förfrågningsfrekvens tillämpas. Blockera äldre autentisering och kräv återautentisering för riskfyllda sessioner.

Steg 3: definiera larmregler för MFA-trötthet

En praktisk SIEM-regel bör utlösas när ett eller flera av följande mönster uppstår inom ett kort tidsfönster:

• Tre eller fler MFA-pushförfrågningar för en användare.
• Två nekade förfrågningar följda av en godkänd förfrågan.
• MFA-godkännande från ny geografisk plats eller icke-hanterad enhet.
• MFA-förfrågan efter en signal om password spray eller credential stuffing.
• MFA-godkännande för privilegierad åtkomst utanför normal arbetstid.
• Registrering av ny autentiserare kort efter misslyckade inloggningsförsök.

Larmet ska skapa ett incidentärende, underrätta SOC-teamet eller säkerhetsansvarig och kräva begränsningsåtgärder: pausa sessionen, återkalla refresh-token, kräva lösenordsåterställning, verifiera enhet, intervjua användaren, granska åtkomst under sessionen och klassificera om personuppgifter eller kritiska tjänster påverkades.

Steg 4: koppla dataskydds- och incidentposter

Om kontot kan komma åt personuppgifter ska Policy för säkerhet och åtkomstkontroll för personuppgifter tillämpas. Den kräver stark autentisering före åtkomst till personuppgifter med hög påverkan:

[Båda] Informationssäkerhetsansvarig MÅSTE kräva stark autentisering för privilegierad, fjärrbaserad, administrativ eller åtkomst till personuppgifter med hög påverkan innan sådan åtkomst aktiveras och registrera kravet i REG12.

Den kräver också att loggningsomfattningen definieras:

[Båda] Systemägaren / applikationsägaren MÅSTE definiera loggningsomfattning för personuppgifter för autentiseringshändelser, åtkomsthändelser, privilegierade åtgärder, export av personuppgifter och väsentliga konfigurationsändringar i REG12 före produktionsanvändning eller väsentlig ändring.

När övervakning indikerar obehörig åtkomst till personuppgifter uppstår en skyldighet att upprätta en incidentpost:

[Villkorligt] Incidenthanteringskoordinatorn MÅSTE öppna eller länka en REG10-post inom en arbetsdag när övervakning indikerar misstänkt obehörig åtkomst till personuppgifter, misstänkt röjande av personuppgifter, misstänkt ändring av personuppgifter eller misstänkt förlust av tillgänglighet för personuppgifter.

Dataskyddseskaleringen slutförs genom Policy för hantering av personuppgiftsincidenter:

[Villkorligt] Dataskyddsansvarig / PIMS-ansvarig MÅSTE utvärdera tillämpliga rättsliga, sektorsspecifika, finanssektorsrelaterade, cybersäkerhetsrelaterade, avtalsmässiga, kundrelaterade och tjänstemottagarrelaterade rapporteringsutlösare för varje personuppgiftsincident med hög påverkan och registrera utfallet av tillämplighetsbedömningen i REG01, REG08 och REG10.

Det är detta som gör ett MFA-larm till revisionsklart underlag över säkerhet, dataskydd och regelefterlevnad.

NIS2, DORA och GDPR: en incident, olika frågor

MFA-trötthet är ett användbart stresstest för efterlevnad av flera ramverk eftersom det berör styrning, cyberhygien, åtkomstkontroll, incidentdetektering, leverantörsåtkomst och incidentanmälningar.

NIS2: ledningens ansvarsskyldighet och cyberhygien

NIS2 gäller för många väsentliga och viktiga entiteter, beroende på sektor, storlek och medlemsstatens utpekande. Article 20 lägger ansvar på ledningsorgan att godkänna åtgärder för cybersäkerhetsriskhantering, övervaka genomförandet och få utbildning. Article 21 kräver lämpliga tekniska, operativa och organisatoriska åtgärder, inklusive incidenthantering, cyberhygien, säkerhet i leveranskedjan, åtkomstkontroll, tillgångshantering, utbildning samt flerfaktorsautentisering eller kontinuerlig autentisering där det är lämpligt. Article 23 inför stegvisa rapporteringsskyldigheter för betydande incidenter, inklusive tidig varning inom 24 timmar från tidpunkt för kännedom och incidentanmälan inom 72 timmar.

En push bombing-incident blir därför en fråga för styrelsen: var MFA säkert utformad, eller bara aktiverad?

DORA: autentisering som digital operativ resiliens

För omfattade finansiella entiteter gäller DORA från den 17 januari 2025. DORA förväntar sig IKT-riskhantering, detektering, respons, återställning, incidentrapportering, testning av digital operativ motståndskraft och IKT-tredjepartsriskhantering.

DORA Article 9 behandlar skydd och förebyggande åtgärder, inklusive åtkomstkontroll och autentiseringsåtgärder. Article 10 behandlar detektering av avvikande aktivitet. Article 17 kräver en process för hantering av IKT-relaterade incidenter. I ett DORA-sammanhang bör underlag för MFA-trötthet visa att berörda IKT-tillgångar identifierades, att övervakning detekterade avvikande beteende, att incidenten klassificerades med hjälp av konsekvenskriterier, att högsta ledningen eskalerades där det krävdes och att erfarenhetsåterföring matades tillbaka in i IKT-riskramverket.

GDPR: säkerhet i behandlingen och ansvarsskyldighet

GDPR Article 5(1)(f) kräver riktighet och konfidentialitet. Article 5(2) kräver ansvarsskyldighet. Article 32 kräver säkerhet som är lämplig i förhållande till risken. Article 4 definierar en personuppgiftsincident som en säkerhetsöverträdelse som leder till oavsiktlig eller olaglig förstöring, förlust, ändring, obehörigt röjande av eller åtkomst till personuppgifter.

Om en incident med MFA-trötthet berör personuppgifter är underlagsfrågan enkel: kan organisationen visa lämpliga autentiseringskontroller, övervakning, incidentrespons och bedömning av personuppgiftsincident?

Korsmappning för ISO, NIST CSF 2.0, COBIT 2019 och revisionsunderlag

NIST CSF 2.0 är användbart eftersom det översätter MFA-styrning till resultat inom GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND och RECOVER.

COBIT 2019 tillför styrningsklarhet. En COBIT-inriktad revisor kan titta på DSS05.04 Hantera identitet och logisk åtkomst, DSS05 Hantera säkerhetstjänster, APO13 Hanterad säkerhet och MEA03 Hanterad efterlevnad av externa krav. Fokus ligger inte på MFA-leverantören. Fokus är om autentisering stödjer verksamhetsmålen, om åtkomsträttigheter styrs, om övervakning är effektiv och om ledningen får meningsfull säkerhetsförsäkran.

En konsoliderad mappning hjälper regelefterlevnadsteam att undvika fragmenterade underlagsförfrågningar:

Vad revisorer och tillsynsmyndigheter kommer att begära

Ett starkt program för MFA-trötthet bör klara flera typer av revision. Clarysecs Zenith Controls-guide för efterlevnad av flera ramverk visar hur ISO/IEC 27002:2022-kontroller testas inom ISO-, NIST-, COBIT- och ISACA-metodik.

Ett svagt program säger: ”Vi frågade användaren och återställde lösenordet.” Ett styrt program producerar ett SIEM-larm, ett incidentärende, en post om återkallelse av session, underlag för lösenordsåterställning, granskning av MFA-faktor, analys av åtkomstlogg, PII-bedömning, utvärdering av rapporteringsutlösare, beskrivning av grundorsak, korrigerande åtgärder och underlag till ledningens genomgång.

En 30-dagars åtgärdsplan för styrning av MFA-trötthet

Målet är inte perfektion på 30 dagar. Målet är synlighet, ägarskap och underlag.

Vecka 1: identifiera och avgränsa

• Lista alla identitetsleverantörer, VPN:er, molnkonsoler, SaaS-plattformar och verktyg för privilegierad åtkomst.
• Identifiera system med personuppgifter, finansiella data, produktionsåtkomst eller funktioner som kan påverka tjänsteleverans.
• Exportera aktuella MFA-metoder och undantag.
• Identifiera externa konton och leverantörskonton.
• Lägg till MFA-trötthet och push bombing i riskregistret.
• Tilldela en riskägare och en ansvarig för riskbehandling.

Vecka 2: härda autentiseringen

• Inaktivera äldre autentisering.
• Kräv phishingresistent MFA för administratörer där det är möjligt.
• Aktivera nummermatchning och applikationskontext för push-MFA.
• Tillämpa villkorlig åtkomst för plats, efterlevnad av enhetskrav och omöjlig resa.
• Begränsa upprepade pushförfrågningar.
• Kräv återautentisering för högriskåtgärder.
• Gör tjänstekonton icke-interaktiva där det är möjligt.
• Dokumentera undantag med utgångsdatum och kompenserande kontroller.

Vecka 3: övervaka och öva

• Säkerställ att autentiseringsloggar fångar lyckade och misslyckade försök, sessionslängd och MFA-användning.
• Skapa larmregler för upprepade förfrågningar, nekade förfrågningar följda av godkännande, registrering av ny enhet och avvikande plats.
• Testa larm med en kontrollerad simulering.
• Validera att incidentärenden skapas och eskaleras.
• Utbilda användare med en kort övning om ”oväntad MFA-förfrågan”.
• Uppdatera helpdeskmanus för att förhindra social manipulation vid lösenordsåterställning och omregistrering av MFA.

Vecka 4: underlag och ledningens genomgång

• Lagra konfigurationsexporter och skärmbilder.
• Registrera resultat från åtkomstgranskningar.
• Koppla genomförd utbildning till privilegierade användare.
• Granska incidenter och nära-händelser.
• Uppdatera tillämpbarhetsförklaringen och riskbehandlingsplanen.
• Presentera kvarstående risk och mätetal för ledningen.
• Schemalägg stickprov för internrevision.

Gör MFA-trötthet möjlig att granska innan den blir rapporteringspliktig

MFA-trötthet påminner om att säkerhetskontroller ofta fallerar i skarvarna: mellan identitet och övervakning, mellan policy och utbildning, mellan leverantörer och intern åtkomst, mellan incidentrespons och dataskyddsrapportering.

Organisationer som hanterar detta väl ”slår inte bara på MFA”. De styr autentisering som en livscykel, övervakar den som en hotsignal, utbildar användare som en del av kontrollen och bevarar underlag som en del av ISMS.

Clarysec sammanför tre tillgångar:

• Zenith Blueprint: en färdplan i 30 steg för revisorer, särskilt steg 19 för säker autentisering, steg 22 för autentiseringsinformation och steg 16 för personaldriven incidentrapportering.
• Clarysecs policymallar, inklusive P38 Policy för säker kommunikation och flerfaktorsautentisering (MFA), P22S Loggnings- och övervakningspolicy – SME, P11S Policy för hantering av användarkonton och privilegier – SME, Policy för informationssäkerhetsmedvetenhet och utbildning – SME, Policy för säkerhet och åtkomstkontroll för personuppgifter och Policy för hantering av personuppgiftsincidenter.
• Zenith Controls: guiden för efterlevnad av flera ramverk, som mappar ISO/IEC 27002:2022-kontrollerna 5.17, 8.5, 8.15 och 8.16 till stödjande kontroller, ISO-revisionsförväntningar, GDPR, NIS2, DORA, NIST och COBIT.

Om du är informationssäkerhetschef, chef för regelefterlevnad, revisor eller verksamhetsägare bör du genomföra en enveckasgranskning av underlaget för MFA-trötthet. Ta fram MFA-konfiguration, autentiseringsloggar, lista över privilegierad åtkomst, lista över leverantörsåtkomst, åtgärdsplan för incidenter, utbildningsmaterial och undantagsregister. Om dessa artefakter inte berättar en sammanhängande historia kan Clarysec hjälpa dig att bygga kontrollpaketet innan en angripare, revisor eller tillsynsmyndighet begär det.

Utforska Zenith Blueprint, granska Zenith Controls eller boka ett inledande samtal med Clarysec för att förvandla MFA-trötthet från en överraskning på styrelsenivå till ett försvarbart och granskningsbart autentiseringsprogram.