Styring af MFA-træthed og push bombing-angreb

Push-notifikationen kl. 02.13, der blev et bestyrelsesspørgsmål

Kl. 02.13 modtager en økonomichef en mobilnotifikation: “Godkend login?” Hun er halvt sovende, antager, at det er en timeout fra en cloudbaseret økonomiplatform, og trykker godkend.

Kl. 02.19 er angriberen inde hos identitetsudbyderen. Kl. 02.31 forsøger vedkommende at få adgang til en løneksport, en privilegeret cloudkonsol og en fælles postkasse, der bruges til leverandørbetalinger. Kl. 03.05 ser SOC’et gentagne MFA-prompter, usædvanlig geografi, en vellykket godkendelse og en ny session fra en ikke-administreret enhed.

Morgensamtalen er velkendt:

• “Men vi havde MFA.”
• “Hvorfor godkendte brugeren den?”
• “Loggede vi detaljerne om MFA-udfordringen?”
• “Er dette et brud på persondatasikkerheden?”
• “Har vi rapporteringsforpligtelser inden for 24 timer eller 72 timer?”
• “Vil vores ISO 27001:2022-revisor behandle dette som et kontrolsvigt?”
• “Påvirker dette NIS2, DORA, GDPR, kundekontrakter eller cyberforsikring?”

Dette er styringshullet bag MFA-træthed og push bombing. Angribere bryder ikke kryptografien. De udmatter menneskelig beslutningstagning, udnytter svagt autentifikationsdesign og leder efter uovervågede undtagelser. Kontrolsvigtet er sjældent “MFA er ikke aktiveret”. Det er normalt en kæde af svag identitetsassurance, risikabelt push-godkendelsesdesign, manglende nummermatchning, uklare regler for privilegeret adgang, utilstrækkelig autentifikationslogning, svag triage af alarmer, utilstrækkeligt trænede brugere og manglende dokumenteret bevismateriale for, at organisationen har gennemgået og korrigeret svagheden.

For CISO’er, complianceansvarlige, revisorer og virksomhedsejere skal MFA-træthed behandles som et ISMS-bevisproblem, ikke kun som en indstilling hos identitetsudbyderen. Svaret kombinerer ISO 27001:2022-risikobehandling, ISO/IEC 27002:2022-kontroller, politikforpligtelser, brugerbevidsthed, hændelseshåndtering, leverandørstyring og kortlægninger på tværs af rammeværker for NIS2, DORA, GDPR, NIST CSF 2.0 og COBIT 2019.

MFA-træthed er et assurance-svigt, ikke et brugerproblem

MFA-træthed, også kaldet push bombing eller prompt bombing, opstår, når en angriber med en gyldig adgangskode gentagne gange udløser MFA-godkendelsesanmodninger, indtil brugeren accepterer én af dem. Nogle gange tilføjer angriberen social engineering, f.eks. et falsk opkald fra helpdesken, en besked om at “vi tester din konto” eller en anmodning om at godkende et login for at stoppe notifikationerne.

Den driftsmæssige risiko er, at organisationer ofte behandler alle former for MFA som ækvivalente. Det er de ikke.

En simpel “godkend eller afvis”-push-notifikation er svagere end nummermatchning, phishing-resistente FIDO2-sikkerhedsnøgler, certifikatbaseret autentifikation eller betinget adgang, der blokerer umulig rejse og ikke-administrerede enheder. MFA fejler også, når bypass-undtagelser ikke er dokumenteret, servicekonti er interaktive, ældre protokoller fortsat er åbne, eller højrisikoadgang ikke kræver stærkere autentifikation.

I Zenith Blueprint: En revisors 30-trins køreplan placerer Clarysec sikker autentifikation i fasen Controls in Action, trin 19: Teknologiske kontroller I. Vejledningen er direkte:

Autentifikation er den første og mest kritiske forsvarslinje mellem en trusselsaktør og jeres systemer, data og tjenester. Hvis autentifikation er svag, kan alt andet, kryptering, overvågning, segmentering, omgås.

Den samme Zenith Blueprint behandler også ISO/IEC 27002:2022-kontrol 5.17 i trin 22:

Hvis identitet er spørgsmålet “Hvem er du?”, er autentifikation beviset. Kontrol 5.17 er stedet, hvor teori møder tillid. Den kræver, at autentifikationsoplysninger håndteres sikkert gennem hele deres livscyklus, så de metoder og legitimationsoplysninger, der bruges til at verificere identitet, ikke selv bliver det svageste led.

De to udsagn forklarer, hvorfor push bombing hører hjemme i risikoregisteret. Kryptering hjælper ikke, hvis angriberen bliver en godkendt bruger. Netværkssegmentering hjælper mindre, hvis privilegeret cloudadgang godkendes gennem en prompt til en udmattet bruger. Overvågning virker kun, hvis autentifikationshændelser logges tilstrækkeligt detaljeret og gennemgås hurtigt.

En moden risikobeskrivelse skal være eksplicit:

Det er her, ISO 27001:2022 bliver relevant. Standarden kræver kontekst, interessenter, lederskab, risikovurdering, behandlingsplanlægning, operationel styring, overvågning, intern revision, ledelsens gennemgang og løbende forbedring. MFA-træthed berører dem alle.

ISO 27001:2022-kontrolklyngen, som revisorer vil teste

ISO 27001:2022 fastlægger strukturen for ledelsessystemet. ISO/IEC 27002:2022 giver implementeringsvejledning for kontroller. For MFA-træthed og push bombing vil revisorer normalt fokusere på en klynge frem for én enkelt kontrol.

Clarysecs Zenith Controls: Vejledningen til kortlægning på tværs af efterlevelseskrav kortlægger ISO/IEC 27002:2022-kontrol 8.5 Secure authentication til understøttende kontroller såsom 5.17 Authentication information, 8.2 Privileged access rights, 8.16 Monitoring activities, 5.24 Information security incident management planning and preparation og 5.34 Privacy and protection of PII. Denne krydskobling er vigtig, fordi et skærmbillede, der viser “MFA aktiveret”, ikke er nok. Revisorer vil se bevis for, at autentifikation er designet, overvåget, gennemgået og forbedret på baggrund af risiko.

En forsvarlig bevispakke skal omfatte:

1. Risikovurdering, der identificerer push bombing og social engineering af MFA-prompter.
2. Autentifikationsstandard, der definerer acceptable MFA-metoder efter systemkritikalitet.
3. Politik for privilegeret adgang, som kræver stærkere autentifikation for administratoradgang og fjernadgang.
4. Konfigurationseksport fra identitetsudbyderen, der viser nummermatchning, promptbegrænsninger, betinget adgang og blokeret ældre autentifikation.
5. Logfiler, der viser vellykkede og mislykkede MFA-hændelser, afviste prompter, umulig rejse og enhedskontekst.
6. Alarmregler for gentagne MFA-prompter, gentagne fejl og usædvanlig vellykket godkendelse.
7. Registreringer fra hændelseshåndtering for autentifikationsrelaterede alarmer.
8. Indhold til sikkerhedsbevidsthedstræning, der instruerer brugere i ikke at godkende uventede prompter.
9. Registreringer af adgangsgennemgang for privilegerede systemer og systemer med højt konsekvensniveau.
10. Undtagelsesregister med udløbsdatoer, godkendelser fra risikoejer og kompenserende kontroller.

Politikker gør “godkend ikke uventede prompter” til bevismateriale

Mange organisationer fortæller brugere, at de ikke må godkende mistænkelige prompter. Rådet er nyttigt, men det er ikke tilstrækkeligt til ISO 27001:2022-certificering, NIS2-tilsyn, DORA-robusthed, GDPR-ansvarlighed, kunders due diligence eller cyberforsikring.

Det første politiske anker er P38 Politik for sikker kommunikation og Multi-Factor Authentication (MFA). Den adresserer den menneskelige faktor direkte:

Brugerbevidsthed: Brugere skal modtage træning i at skelne sikre fra usikre kommunikationskanaler. Træningen skal dække korrekt brug af Multi-Factor Authentication (MFA) (f.eks. ikke at godkende uventede loginprompter) og praksis for sikker kommunikation (f.eks. verificering af videokonferencelinks og ikke at drøfte fortrolige emner over usikrede linjer).

Dette gør MFA-træthed til en træningsforpligtelse, ikke en øvelse i placering af skyld. Det gør det muligt for CISO’en at dokumentere, at prompt bombing er dækket i onboarding, genopfriskningstræning, rollebaseret træning og briefinger for privilegerede brugere.

Den samme P38 Politik for sikker kommunikation og Multi-Factor Authentication (MFA) skaber også en overvågningsforpligtelse:

Informationssikkerhed skal løbende overvåge autentifikationslogfiler for loginforsøg med kun én faktor eller anomale Multi-Factor Authentication (MFA)-fejl. Logfiler fra sikre kommunikationssystemer skal, hvor relevant, overvåges for uautoriserede adgangsforsøg eller konfigurationsændringer.

For SMV’er fastlægger P11S Politik for styring af brugerkonti og privilegier - SMV en praktisk baseline:

Multifaktorgodkendelse (MFA) skal være aktiveret, hvor det er teknisk muligt, for administratorkonti eller følsomme systemer.

Formuleringen “hvor det er teknisk muligt” må aldrig blive et smuthul. Hvis et system ikke kan understøtte stærk MFA, skal undtagelsen registreres med ejer, udløbsdato, kompenserende kontroller, overvågning og en migrationsplan. Større organisationer kan tilpasse samme forventning til P11 Politik for styring af brugerkonti og privilegier og derefter teste, om politik og driftsmæssig virkelighed stemmer overens.

Detektionsbevis kommer fra P22S Lognings- og overvågningspolitik - SMV, som kræver logning af autentifikationshændelser:

Autentifikationslogfiler: Vellykkede og mislykkede loginforsøg, sessionsvarighed, MFA-brug

Den kræver også hurtig gennemgang af højrisikosignaler ved autentifikation:

Øjeblikkelig gennemgang ved detektion af alarmer med høj alvorlighed (f.eks. malware, mislykket multifaktorgodkendelse (MFA), gentagne loginfejl)

Sikkerhedsbevidsthed skal udvikle sig i takt med truslerne. Politik for bevidsthed om informationssikkerhed og uddannelse - SMV understøtter denne sløjfe:

Emner skal omfatte fremspirende trusler (f.eks. phishing), relevante politikændringer og interne hændelsestendenser.

Når SOC’et detekterer forsøg på MFA-træthed, skal denne efterretning indgå i brugeradvarsler, helpdesk-scripts, tabletop-øvelser og opdateringer af træning.

En styret kontrolpakke for MFA-træthed

Antag, at organisationen bruger en cloudbaseret identitetsudbyder, et SaaS-CRM, en økonomiplatform, en VPN og en managed security provider. Målet er at styre MFA-træthed ved hjælp af Clarysecs Zenith Blueprint, politikbibliotek og Zenith Controls-vejledning til kortlægning på tværs af efterlevelseskrav.

Start med trin 19 i Zenith Blueprint, som instruerer teams i at definere autentifikationskrav pr. system og advarer om, at autentifikation baseret alene på adgangskode bør undgås for administrative konti, cloudkonsoller, værktøjer til fjernadgang og internetvendte systemer. Anvend derefter den praktiske gennemgangsaktivitet:

Gennemgå jeres MFA-implementering: identificer eventuelle huller, og planlæg lukning af dem. Valider, at servicekonti er ikke-interaktive, hvor det er muligt, har stærke legitimationsoplysninger og er dokumenteret. Bekræft, at ingen standardlegitimationsoplysninger findes på noget system eller nogen applikation.

Omsæt denne vejledning til en operationel kontrolpakke.

Trin 1: Klassificér systemer efter autentifikationsrisiko

Trin 2: Fjern push-adfærd med høj risiko

For administrator- og højkonsekvenskonti skal basal push-godkendelse deaktiveres. Brug phishing-resistente autentifikatorer, hvor det er muligt. Hvor push fortsat bruges, skal nummermatchning, applikationskontekst, geografisk kontekst, enhedsbinding og begrænsninger for prompthyppighed håndhæves. Bloker ældre autentifikation, og kræv genautentifikation for risikable sessioner.

Trin 3: Definér alarmregler for MFA-træthed

En praktisk SIEM-regel skal udløses, når ét eller flere af disse mønstre forekommer inden for et kort tidsvindue:

• Tre eller flere MFA-push-prompter for én bruger.
• To afviste prompter efterfulgt af én godkendt prompt.
• MFA-godkendelse fra en ny geografi eller en ikke-administreret enhed.
• MFA-prompt efter et signal om password spraying eller credential stuffing.
• MFA-godkendelse til privilegeret adgang uden for normal arbejdstid.
• Ny registrering af autentifikator kort efter mislykkede loginforsøg.

Alarmen skal oprette en hændelsessag, underrette SOC’et eller den sikkerhedsansvarlige og kræve inddæmningstrin: suspendér session, tilbagekald refresh tokens, kræv nulstilling af adgangskode, verificér enhed, interview bruger, gennemgå adgang under sessionen, og klassificér, om der er sket påvirkning af personoplysninger eller kritiske tjenester.

Trin 4: Sammenkobl privatlivs- og hændelsesregistreringer

Hvis kontoen kan tilgå personoplysninger, skal PII Security and Access Control Policy anvendes. Den kræver stærk autentifikation før adgang til PII med højt konsekvensniveau:

[Begge] Den informationssikkerhedsansvarlige SKAL kræve stærk autentifikation for privilegeret, fjernbaseret, administrativ adgang eller adgang til PII med højt konsekvensniveau, før sådan adgang aktiveres, og registrere kravet i REG12.

Den kræver også, at omfanget for logning defineres:

[Begge] Systemejer / Applikationsejer SKAL definere omfanget for PII-logning for autentifikationshændelser, adgangshændelser, privilegerede handlinger, PII-eksportaktivitet og væsentlige konfigurationsændringer i REG12 før produktionsbrug eller væsentlig ændring.

Når overvågning indikerer uautoriseret adgang til PII, skaber det en forpligtelse til registrering af hændelsen:

[Betinget] Hændelseskoordinatoren SKAL åbne eller linke en REG10-registrering inden for én arbejdsdag, når overvågning indikerer mistanke om uautoriseret adgang til PII, mistanke om videregivelse af PII, mistanke om ændring af PII eller mistanke om tab af PII-tilgængelighed.

Privatlivseskaleringen afsluttes af PII Incident and Breach Management Policy:

[Betinget] Privacy Lead / PIMS Manager SKAL evaluere relevante juridiske, sektorbestemte, finanssektorrelaterede, cybersikkerhedsmæssige, kontraktlige, kunde- og tjenestemodtagerrelaterede rapporteringsudløsere for hver PII-hændelse med højt konsekvensniveau og registrere resultatet af anvendelighedsvurderingen i REG01, REG08 og REG10.

Det er dette, der omsætter en MFA-alarm til revisionsklart bevismateriale på tværs af sikkerhed, databeskyttelse og efterlevelse.

NIS2, DORA og GDPR: én hændelse, forskellige spørgsmål

MFA-træthed er en nyttig stresstest på tværs af efterlevelseskrav, fordi den berører styring, cyberhygiejne, adgangsstyring, hændelsesdetektion, leverandøradgang og rapportering af brud.

NIS2: Ledelsesansvar og cyberhygiejne

NIS2 gælder for mange væsentlige og vigtige enheder afhængigt af sektor, størrelse og udpegning i medlemsstaten. Article 20 placerer ansvarlighed hos ledelsesorganer for at godkende foranstaltninger til styring af cybersikkerhedsrisici, føre tilsyn med implementering og modtage træning. Article 21 kræver passende tekniske, driftsmæssige og organisatoriske foranstaltninger, herunder hændelseshåndtering, cyberhygiejne, sikkerhed i forsyningskæden, adgangsstyring, styring af aktiver, træning og multifaktorgodkendelse eller løbende autentifikation, hvor det er relevant. Article 23 indfører trinvise rapporteringsforpligtelser for væsentlige hændelser, herunder tidlig varsling inden for 24 timer fra kendskab og hændelsesunderretning inden for 72 timer.

En push bombing-hændelse bliver derfor et spørgsmål på bestyrelsesniveau: Var MFA sikkert designet eller blot aktiveret?

DORA: Autentifikation som digital operationel robusthed

For omfattede finansielle enheder finder DORA anvendelse fra 17. januar 2025. Forordningen forventer styring af IKT-risiko, detektion, respons, genopretning, hændelsesrapportering, test af digital operationel robusthed og styring af IKT-tredjepartsrisici.

DORA Article 9 omhandler beskyttelse og forebyggelse, herunder adgangsstyring og autentifikationsforanstaltninger. Article 10 omhandler detektion af anomal aktivitet. Article 17 kræver en proces for styring af IKT-relaterede hændelser. I en DORA-kontekst bør bevismateriale om MFA-træthed vise, at berørte IKT-aktiver blev identificeret, at overvågning detekterede anomal adfærd, at hændelsen blev klassificeret ved hjælp af konsekvenskriterier, at øverste ledelse blev eskaleret, hvor det var påkrævet, og at læring blev ført tilbage i IKT-risikostyringsrammen.

GDPR: Behandlingssikkerhed og ansvarlighed

GDPR Article 5(1)(f) kræver integritet og fortrolighed. Article 5(2) kræver ansvarlighed. Article 32 kræver sikkerhed, der passer til risikoen. Article 4 definerer et brud på persondatasikkerheden som et brud på sikkerheden, der fører til hændelig eller ulovlig tilintetgørelse, tab, ændring, uautoriseret videregivelse af eller adgang til personoplysninger.

Hvis en MFA-træthedshændelse berører personoplysninger, er beviskravet enkelt: Kan organisationen dokumentere passende autentifikationskontroller, overvågning, hændelseshåndtering og vurdering af brud?

Krydsreference for ISO, NIST CSF 2.0, COBIT 2019 og revisionsbevismateriale

NIST CSF 2.0 er nyttigt, fordi det omsætter MFA-styring til resultater inden for GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND og RECOVER.

COBIT 2019 tilføjer styringsmæssig klarhed. En COBIT-orienteret revisor kan se på DSS05.04 Manage identity and logical access, DSS05 Manage security services, APO13 Managed security og MEA03 Managed compliance with external requirements. Fokus er ikke MFA-leverandøren. Fokus er, om autentifikation understøtter forretningsmål, om adgangsrettigheder styres, om overvågning er effektiv, og om ledelsen modtager meningsfuld assurance.

En konsolideret kortlægning hjælper compliance-teams med at undgå fragmenterede anmodninger om bevismateriale:

Hvad revisorer og tilsynsmyndigheder vil efterspørge

Et stærkt program for MFA-træthed skal kunne modstå flere revisionsstile. Clarysecs Zenith Controls-vejledning til kortlægning på tværs af efterlevelseskrav viser, hvordan ISO/IEC 27002:2022-kontroller testes på tværs af ISO-, NIST-, COBIT- og ISACA-metodikker.

Et svagt program siger: “Vi spurgte brugeren og nulstillede adgangskoden.” Et styret program producerer en SIEM-alarm, hændelsessag, registrering af sessionstilbagekaldelse, dokumentation for nulstilling af adgangskode, gennemgang af MFA-faktor, analyse af adgangslog, PII-vurdering, evaluering af rapporteringsudløsere, rodårsagsbeskrivelse, korrigerende handlinger og input til ledelsens gennemgang.

En 30-dages handlingsplan for styring af MFA-træthed

Målet er ikke perfektion på 30 dage. Målet er synlighed, ejerskab og bevismateriale.

Uge 1: Identificér og afgræns

• Oplist alle identitetsudbydere, VPN’er, cloudkonsoller, SaaS-platforme og værktøjer til privilegeret adgang.
• Identificér systemer med personoplysninger, finansielle data, produktionsmiljøadgang eller funktioner, der kan påvirke tjenester.
• Eksportér aktuelle MFA-metoder og undtagelser.
• Identificér eksterne konti og leverandørkonti.
• Tilføj MFA-træthed og push bombing til risikoregisteret.
• Tildel en risikoejer og en behandlingsansvarlig.

Uge 2: Hærd autentifikation

• Deaktivér ældre autentifikation.
• Kræv phishing-resistent MFA for administratorer, hvor det er muligt.
• Aktivér nummermatchning og applikationskontekst for push-MFA.
• Anvend betinget adgang for lokation, enhedsefterlevelse og umulig rejse.
• Begræns gentagne push-prompter.
• Kræv genautentifikation for højrisikohandlinger.
• Gør servicekonti ikke-interaktive, hvor det er muligt.
• Dokumentér undtagelser med udløb og kompenserende kontroller.

Uge 3: Overvåg og øv

• Sikr, at autentifikationslogfiler registrerer succes, fejl, sessionsvarighed og MFA-brug.
• Opret alarmregler for gentagne prompter, afviste prompter efterfulgt af godkendelse, registrering af ny enhed og usædvanlig lokation.
• Test alarmer med en kontrolleret simulering.
• Validér oprettelse og eskalering af hændelsessager.
• Træn brugere med en kort øvelse om “uventet MFA-prompt”.
• Opdatér helpdesk-scripts for at forebygge social engineering ved nulstilling af adgangskoder og genregistrering af MFA.

Uge 4: Bevismateriale og ledelsens gennemgang

• Gem konfigurationseksporter og skærmbilleder.
• Registrér resultater af adgangsgennemgange.
• Knyt gennemført træning til privilegerede brugere.
• Gennemgå hændelser og nærved-hændelser.
• Opdatér anvendelighedserklæringen (SoA) og behandlingsplanen.
• Præsentér restrisiko og metrikker for ledelsen.
• Planlæg stikprøvetest i intern revision.

Gør MFA-træthed revisionsklar, før den bliver rapporteringspligtig

MFA-træthed er en påmindelse om, at sikkerhedskontroller fejler i overgangene: mellem identitet og overvågning, mellem politik og træning, mellem leverandører og intern adgang, mellem hændelseshåndtering og rapportering om databeskyttelse.

Organisationer, der håndterer det godt, “slår ikke bare MFA til”. De styrer autentifikation som en livscyklus, overvåger den som et trusselssignal, træner brugere som en del af kontrollen og bevarer bevismateriale som en del af ISMS’et.

Clarysec samler tre aktiver:

• Zenith Blueprint: En revisors 30-trins køreplan, særligt trin 19 for sikker autentifikation, trin 22 for autentifikationsoplysninger og trin 16 for personaledrevet hændelsesrapportering.
• Clarysecs politikskabeloner, herunder P38 Politik for sikker kommunikation og Multi-Factor Authentication (MFA), P22S Lognings- og overvågningspolitik - SMV, P11S Politik for styring af brugerkonti og privilegier - SMV, Politik for bevidsthed om informationssikkerhed og uddannelse - SMV, PII Security and Access Control Policy og PII Incident and Breach Management Policy.
• Zenith Controls: Vejledningen til kortlægning på tværs af efterlevelseskrav, som kortlægger ISO/IEC 27002:2022-kontrollerne 5.17, 8.5, 8.15 og 8.16 til understøttende kontroller, ISO-revisionsforventninger, GDPR, NIS2, DORA, NIST og COBIT.

Hvis du er CISO, complianceansvarlig, revisor eller virksomhedsejer, så gennemfør en uges gennemgang af bevismateriale for MFA-træthed. Hent jeres MFA-konfiguration, autentifikationslogfiler, liste over privilegeret adgang, liste over leverandøradgang, playbook for hændelser, træningsmateriale og undtagelsesregister. Hvis disse artefakter ikke fortæller én sammenhængende historie, kan Clarysec hjælpe jer med at opbygge kontrolpakken, før en angriber, revisor eller tilsynsmyndighed beder om den.

Udforsk Zenith Blueprint, gennemgå Zenith Controls, eller book et Clarysec discovery call for at gøre MFA-træthed fra en overraskelse på bestyrelsesniveau til et forsvarligt, revisionsklart autentifikationsprogram.