Guvernanța oboselii MFA și a atacurilor de tip push bombing

Notificarea push de la 2:13 a.m. care a devenit o întrebare pentru organul de conducere

La 2:13 a.m., un administrator financiar senior primește o notificare pe mobil: „Aprobați autentificarea?” Este pe jumătate adormit, presupune că este vorba despre expirarea unei sesiuni într-o platformă financiară cloud și apasă pe aprobare.

La 2:19 a.m., atacatorul este deja în furnizorul de identitate. La 2:31 a.m., încearcă să acceseze un export de date de salarizare, o consolă cloud privilegiată și o căsuță poștală partajată utilizată pentru plăți către furnizori. La 3:05 a.m., SOC observă solicitări MFA repetate, o geolocație neobișnuită, o aprobare reușită și o sesiune nouă de pe un dispozitiv negestionat.

Discuția de dimineață este familiară:

• „Dar aveam MFA.”
• „De ce a aprobat utilizatorul?”
• „Am jurnalizat detaliile solicitării MFA?”
• „Este aceasta o încălcare a securității datelor cu caracter personal?”
• „Avem obligații de raportare în 24 de ore sau în 72 de ore?”
• „Auditorul nostru ISO 27001:2022 va considera acest lucru un eșec de control?”
• „Afectează acest lucru NIS2, DORA, GDPR, contractele cu clienții sau asigurarea cibernetică?”

Aceasta este lacuna de guvernanță din spatele oboselii MFA și al atacurilor de tip push bombing. Atacatorii nu sparg criptografia. Ei epuizează capacitatea umană de decizie, exploatează o proiectare slabă a autentificării și caută excepții nemonitorizate. Eșecul de control este rareori „MFA nu era activată”. De regulă, este un lanț format din asigurare slabă a identității, proiectare riscantă a aprobării prin push, lipsa potrivirii numerice, reguli neclare pentru accesul privilegiat, jurnalizare insuficientă a autentificării, triaj slab al alertelor, utilizatori insuficient instruiți și lipsa dovezilor documentate că organizația a revizuit și a remediat punctul slab.

Pentru CISO, manageri de conformitate, auditori și responsabili de business, oboseala MFA trebuie tratată ca o problemă de dovezi în SMSI, nu doar ca o setare a furnizorului de identitate. Răspunsul combină tratarea riscului conform ISO 27001:2022, controalele ISO/IEC 27002:2022, cerințele stabilite prin politici, conștientizarea utilizatorilor, răspunsul la incidente, guvernanța furnizorilor și mapări între cadre pentru NIS2, DORA, GDPR, NIST CSF 2.0 și COBIT 2019.

Oboseala MFA este un eșec de asigurare, nu o problemă a utilizatorului

Oboseala MFA, numită și push bombing sau bombardare cu solicitări, apare atunci când un atacator care deține o parolă validă declanșează în mod repetat solicitări de aprobare MFA până când utilizatorul acceptă una. Uneori, atacatorul adaugă inginerie socială, cum ar fi un apel fals de la helpdesk, un mesaj de tipul „vă testăm contul” sau o cerere de aprobare a unei autentificări pentru a opri notificările.

Riscul operațional este că organizațiile tratează adesea toate formele de MFA ca fiind echivalente. Nu sunt.

O notificare push simplă de tip „aprobare sau respingere” este mai slabă decât potrivirea numerică, cheile de securitate FIDO2 rezistente la phishing, autentificarea bazată pe certificate sau accesul condiționat care blochează deplasarea imposibilă și dispozitivele negestionate. MFA eșuează și atunci când excepțiile de ocolire nu sunt documentate, conturile de serviciu sunt interactive, protocoalele moștenite rămân deschise sau accesul cu risc ridicat nu impune o autentificare mai puternică.

În Zenith Blueprint: foaia de parcurs în 30 de pași pentru auditori, Clarysec încadrează autentificarea securizată în faza Controale în acțiune, Pasul 19: Controale tehnologice I. Recomandarea este directă:

Autentificarea este prima și cea mai critică linie de apărare între un actor de amenințare și sistemele, datele și serviciile dumneavoastră. Dacă autentificarea este slabă, orice altceva, criptare, monitorizare, segmentare, poate fi ocolit.

Același Zenith Blueprint abordează și controlul ISO/IEC 27002:2022 5.17 în Pasul 22:

Dacă identitatea este întrebarea „Cine ești?”, atunci autentificarea este dovada. Controlul 5.17 este locul în care teoria devine încredere. Acesta impune ca informațiile de autentificare să fie gestionate securizat pe întregul lor ciclu de viață, asigurând că metodele și credențialele utilizate pentru verificarea identității nu devin ele însele cea mai slabă verigă.

Aceste două afirmații explică de ce push bombing trebuie inclus în Registrul de riscuri. Criptarea nu ajută dacă atacatorul devine un utilizator aprobat. Segmentarea rețelei ajută mai puțin dacă accesul cloud privilegiat este aprobat printr-o solicitare acceptată din oboseală. Monitorizarea funcționează numai dacă evenimentele de autentificare sunt jurnalizate suficient de detaliat și revizuite rapid.

O formulare matură a riscului trebuie să fie explicită:

Aici devine relevant ISO 27001:2022. Standardul impune context, părți interesate, leadership, evaluarea riscurilor, planificarea tratamentului, control operațional, monitorizare, audit intern, revizuire de management și îmbunătățire continuă. Oboseala MFA le atinge pe toate.

Grupul de controale ISO 27001:2022 pe care auditorii îl vor testa

ISO 27001:2022 oferă structura sistemului de management. ISO/IEC 27002:2022 oferă îndrumări de implementare pentru controale. Pentru oboseala MFA și push bombing, auditorii se vor concentra de obicei pe un grup de controale, nu pe un singur control.

Zenith Controls: ghidul de conformitate între cadre de la Clarysec mapează controlul ISO/IEC 27002:2022 8.5 Autentificare securizată la controale-suport precum 5.17 Informații de autentificare, 8.2 Drepturi de acces privilegiat, 8.16 Activități de monitorizare, 5.24 Planificarea și pregătirea gestionării incidentelor de securitate a informațiilor și 5.34 Confidențialitatea și protecția PII. Această corelare este importantă deoarece o captură de ecran care arată „MFA activată” nu este suficientă. Auditorii vor dovezi că autentificarea este proiectată, monitorizată, revizuită și îmbunătățită pe baza riscului.

Un pachet de dovezi defensabil trebuie să includă:

1. Evaluarea riscurilor care identifică push bombing și ingineria socială aplicată solicitărilor MFA.
2. Standard de autentificare care definește metodele MFA acceptabile în funcție de criticitatea sistemului.
3. Politică de acces privilegiat care impune autentificare mai puternică pentru accesul de administrator și accesul la distanță.
4. Export al configurației furnizorului de identitate care arată potrivirea numerică, limitele pentru solicitări, accesul condiționat și autentificarea moștenită blocată.
5. Jurnale care arată evenimente MFA reușite și eșuate, solicitări respinse, deplasare imposibilă și context de dispozitiv.
6. Reguli de alertare pentru solicitări MFA repetate, eșecuri repetate și aprobări reușite neobișnuite.
7. Înregistrări de răspuns la incidente pentru alertele legate de autentificare.
8. Conținut de instruire și conștientizare care le spune utilizatorilor să nu aprobe solicitări neașteptate.
9. Înregistrări ale revizuirilor accesului pentru sisteme privilegiate și cu impact ridicat.
10. Registrul de excepții cu date de expirare, aprobări ale proprietarilor de risc și controale compensatorii.

Politica transformă „nu aprobați solicitările neașteptate” în dovezi

Multe organizații le spun utilizatorilor să nu aprobe solicitări suspecte. Recomandarea este utilă, dar nu este suficientă pentru certificarea ISO 27001:2022, supravegherea NIS2, reziliența DORA, responsabilitatea GDPR, verificarea prealabilă solicitată de clienți sau asigurarea cibernetică.

Primul reper de politică este P38 Politica privind comunicațiile securizate și autentificarea multifactor (MFA). Aceasta abordează direct componenta umană:

Conștientizarea utilizatorilor: Utilizatorii trebuie să primească instruire pentru a distinge canalele de comunicare securizate de cele nesecurizate. Instruirea trebuie să acopere utilizarea corectă a autentificării multifactor (MFA) (de exemplu, neaprobarea solicitărilor de autentificare neașteptate) și practicile de comunicare securizată (de exemplu, verificarea linkurilor pentru videoconferințe și evitarea discutării subiectelor confidențiale pe linii nesecurizate).

Aceasta transformă oboseala MFA într-o obligație de instruire, nu într-un exercițiu de atribuire a vinei. Permite CISO să demonstreze că bombardarea cu solicitări este acoperită în procesul de onboarding, instruirea periodică, instruirea bazată pe roluri și informările pentru utilizatorii privilegiați.

Aceeași P38 Politica privind comunicațiile securizate și autentificarea multifactor (MFA) creează și o obligație de monitorizare:

Securitatea informației trebuie să monitorizeze continuu jurnalele de autentificare pentru orice tentative de autentificare cu un singur factor sau eșecuri anormale ale autentificării multifactor (MFA). Jurnalele din sistemele de comunicații securizate, acolo unde este aplicabil, trebuie monitorizate pentru tentative de acces neautorizat sau modificări de configurare.

Pentru IMM-uri, P11S Politica privind gestionarea conturilor de utilizator și a privilegiilor - IMM stabilește o bază practică:

Autentificarea multifactor (MFA) trebuie activată, acolo unde este fezabil tehnic, pentru conturile de administrator sau sistemele sensibile.

Expresia „acolo unde este fezabil tehnic” nu trebuie să devină niciodată o portiță. Dacă un sistem nu poate suporta MFA puternică, excepția trebuie înregistrată cu un proprietar, o dată de expirare, controale compensatorii, monitorizare și un plan de migrare. Organizațiile mai mari pot alinia aceeași așteptare la P11 Politica privind gestionarea conturilor de utilizator și a privilegiilor, apoi pot testa dacă politica și realitatea operațională coincid.

Dovezile de detecție provin din P22S Politica de jurnalizare și monitorizare - IMM, care impune jurnalizarea evenimentelor de autentificare:

Jurnale de autentificare: tentative de autentificare reușite și eșuate, durata sesiunii, utilizarea MFA

Aceasta impune și revizuirea urgentă a semnalelor de autentificare cu risc ridicat:

Revizuire imediată la detectarea alertelor de severitate ridicată (de exemplu, programe malware, autentificare multifactor (MFA) eșuată, eșecuri repetate de autentificare)

Conștientizarea trebuie să evolueze pe măsură ce amenințările evoluează. Politica privind conștientizarea și instruirea în domeniul securității informației - IMM susține acest circuit:

Temele trebuie să includă amenințări emergente (de exemplu, phishing), modificări relevante ale politicilor și tendințe interne ale incidentelor.

Atunci când SOC detectează tentative de oboseală MFA, aceste informații despre amenințări trebuie să alimenteze alertele către utilizatori, scripturile helpdesk, exercițiile de tip tabletop și actualizările de instruire.

Un pachet guvernat de controale pentru oboseala MFA

Să presupunem că organizația utilizează un furnizor de identitate cloud, un CRM SaaS, o platformă financiară, un VPN și un furnizor de securitate gestionată. Obiectivul este guvernanța oboselii MFA utilizând Zenith Blueprint, biblioteca de politici și ghidul de conformitate între cadre Zenith Controls de la Clarysec.

Începeți cu Pasul 19 din Zenith Blueprint, care instruiește echipele să definească cerințele de autentificare pentru fiecare sistem și avertizează că autentificarea doar cu parolă trebuie evitată pentru conturi administrative, console cloud, instrumente de acces la distanță și sisteme expuse la internet. Apoi aplicați activitatea practică de revizuire:

Revizuiți implementarea MFA: identificați lacunele și planificați închiderea lor. Validați că, acolo unde este posibil, conturile de serviciu sunt neinteractive, au credențiale puternice și sunt documentate. Confirmați că nu mai există credențiale implicite pe niciun sistem sau nicio aplicație.

Convertiți această îndrumare într-un pachet operațional de controale.

Pasul 1: clasificați sistemele după riscul de autentificare

Pasul 2: eliminați comportamentul push cu risc ridicat

Pentru conturile de administrator și conturile cu impact ridicat, dezactivați aprobarea push de bază. Utilizați autentificatori rezistenți la phishing acolo unde este posibil. Acolo unde push rămâne activ, impuneți potrivirea numerică, contextul aplicației, contextul geografic, asocierea cu dispozitivul și limite ale ratei solicitărilor. Blocați autentificarea moștenită și impuneți reautentificarea pentru sesiunile riscante.

Pasul 3: definiți reguli de alertare pentru oboseala MFA

O regulă SIEM practică trebuie să se declanșeze atunci când unul sau mai multe dintre aceste tipare apar într-un interval scurt:

• Trei sau mai multe solicitări push MFA pentru un utilizator.
• Două solicitări respinse urmate de o solicitare aprobată.
• Aprobare MFA dintr-o geolocație nouă sau de pe un dispozitiv negestionat.
• Solicitare MFA după un semnal de password spray sau credential stuffing.
• Aprobare MFA pentru acces privilegiat în afara programului normal de lucru.
• Înregistrarea unui autentificator nou la scurt timp după tentative de autentificare eșuate.

Alerta trebuie să creeze un tichet de incident, să notifice SOC sau responsabilul cu securitatea și să impună pași de conținere: suspendarea sesiunii, revocarea token-urilor de reîmprospătare, resetarea parolei, verificarea dispozitivului, intervievarea utilizatorului, revizuirea accesului din timpul sesiunii și clasificarea eventualului impact asupra datelor cu caracter personal sau asupra unui serviciu critic.

Pasul 4: corelați înregistrările de confidențialitate și de incident

Dacă un cont poate accesa date cu caracter personal, aplicați Politica de securitate și control al accesului la PII. Aceasta impune autentificare puternică înaintea accesului la PII cu impact ridicat:

[Ambele] Responsabilul cu securitatea informației TREBUIE să impună autentificare puternică pentru accesul privilegiat, la distanță, administrativ sau cu impact ridicat la PII înainte ca acest acces să fie activat și să înregistreze cerința în REG12.

Aceasta impune și definirea domeniului de aplicare al jurnalizării:

[Ambele] Proprietarul sistemului / Proprietarul aplicației TREBUIE să definească domeniul de aplicare al jurnalizării PII pentru evenimente de autentificare, evenimente de acces, acțiuni privilegiate, activitate de export PII și modificări semnificative de configurare în REG12 înainte de utilizarea în producție sau de o modificare semnificativă.

Atunci când monitorizarea indică acces neautorizat suspectat la PII, se creează o obligație de înregistrare a incidentului:

[Condițional] Coordonatorul răspunsului la incidente TREBUIE să deschidă sau să coreleze o înregistrare REG10 în termen de o zi lucrătoare atunci când monitorizarea indică acces neautorizat suspectat la PII, divulgare suspectată de PII, modificare suspectată de PII sau pierdere suspectată a disponibilității PII.

Escaladarea privind confidențialitatea este completată de Politica de gestionare a incidentelor și încălcărilor securității PII:

[Condițional] Responsabilul pentru confidențialitate / Managerul PIMS TREBUIE să evalueze criteriile aplicabile de raportare juridice, sectoriale, din sectorul financiar, de securitate cibernetică, contractuale, ale clienților și ale destinatarilor serviciului pentru fiecare incident PII cu impact ridicat și să înregistreze rezultatul privind aplicabilitatea în REG01, REG08 și REG10.

Acesta este mecanismul prin care o alertă MFA devine dovadă pregătită pentru audit în securitate, confidențialitate și conformitate.

NIS2, DORA și GDPR: un singur incident, întrebări diferite

Oboseala MFA este un test util de conformitate între cadre, deoarece atinge guvernanța, igiena cibernetică, controlul accesului, detectarea incidentelor, accesul furnizorilor și raportarea încălcărilor securității datelor.

NIS2: responsabilitatea conducerii și igiena cibernetică

NIS2 se aplică multor entități esențiale și importante, în funcție de sector, dimensiune și desemnarea de către statul membru. Articolul 20 stabilește responsabilitatea organelor de conducere de a aproba măsurile de management al riscurilor de securitate cibernetică, de a supraveghea implementarea și de a primi instruire. Articolul 21 impune măsuri tehnice, operaționale și organizatorice adecvate, inclusiv gestionarea incidentelor, igienă cibernetică, securitatea lanțului de aprovizionare, controlul accesului, managementul activelor, instruire și autentificare multifactor sau autentificare continuă, acolo unde este adecvat. Articolul 23 introduce obligații etapizate de raportare a incidentelor semnificative, inclusiv avertizare timpurie în termen de 24 de ore de la luarea la cunoștință și notificarea incidentului în termen de 72 de ore.

Prin urmare, un incident de push bombing devine o întrebare la nivelul organului de conducere: MFA a fost proiectată securizat sau doar activată?

DORA: autentificarea ca reziliență operațională digitală

Pentru entitățile financiare vizate, DORA se aplică de la 17 ianuarie 2025. Regulamentul impune managementul riscului TIC, detecție, răspuns, recuperare, raportarea incidentelor, testarea rezilienței operaționale digitale și managementul riscului asociat terților TIC.

Articolul 9 din DORA abordează protecția și prevenirea, inclusiv măsurile de control al accesului și autentificare. Articolul 10 abordează detectarea activității anormale. Articolul 17 impune un proces de gestionare a incidentelor legate de TIC. În context DORA, dovezile privind oboseala MFA trebuie să arate că activele TIC afectate au fost identificate, monitorizarea a detectat comportamentul anormal, incidentul a fost clasificat utilizând criterii de impact, conducerea superioară a fost informată prin escaladare acolo unde era necesar, iar lecțiile învățate au fost reintegrate în cadrul de risc TIC.

GDPR: securitatea prelucrării și responsabilitate

Articolul 5(1)(f) din GDPR impune integritate și confidențialitate. Articolul 5(2) impune responsabilitate. Articolul 32 impune securitate adecvată riscului. Articolul 4 definește o încălcare a securității datelor cu caracter personal ca o încălcare a securității care conduce la distrugerea accidentală sau ilegală, pierderea, modificarea, divulgarea neautorizată sau accesul neautorizat la date cu caracter personal.

Dacă un incident de oboseală MFA atinge date cu caracter personal, întrebarea privind dovezile este simplă: poate organizația să demonstreze controale adecvate de autentificare, monitorizare, răspuns la incidente și evaluare a încălcării securității datelor?

Tabel de corelare pentru ISO, NIST CSF 2.0, COBIT 2019 și dovezi de audit

NIST CSF 2.0 este util deoarece transpune guvernanța MFA în rezultate GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND și RECOVER.

COBIT 2019 adaugă claritate de guvernanță. Un auditor orientat pe COBIT poate analiza DSS05.04 Gestionarea identității și a accesului logic, DSS05 Gestionarea serviciilor de securitate, APO13 Securitate gestionată și MEA03 Conformitate gestionată cu cerințele externe. Accentul nu este pe furnizorul MFA. Accentul este pe măsura în care autentificarea susține obiectivele organizației, drepturile de acces sunt guvernate, monitorizarea este eficace, iar managementul primește asigurare relevantă.

O mapare consolidată ajută echipele de conformitate să evite solicitările fragmentate de dovezi:

Ce vor solicita auditorii și autoritățile de reglementare

Un program solid pentru oboseala MFA trebuie să reziste mai multor stiluri de audit. Ghidul de conformitate între cadre Zenith Controls de la Clarysec arată cum sunt testate controalele ISO/IEC 27002:2022 în metodologiile ISO, NIST, COBIT și ISACA.

Un program slab spune: „Am întrebat utilizatorul și am resetat parola.” Un program guvernat produce o alertă SIEM, un tichet de incident, o înregistrare de revocare a sesiunii, dovezi privind resetarea parolei, revizuirea factorilor MFA, analiza jurnalelor de acces, evaluarea PII, evaluarea criteriilor de raportare, declarația cauzei principale, acțiuni corective și input pentru revizuirea de management.

Plan de acțiune pe 30 de zile pentru guvernanța oboselii MFA

Obiectivul nu este perfecțiunea în 30 de zile. Obiectivul este vizibilitate, responsabilitate și dovezi.

Săptămâna 1: identificați și delimitați domeniul de aplicare

• Listați toți furnizorii de identitate, VPN-urile, consolele cloud, platformele SaaS și instrumentele de acces privilegiat.
• Identificați sistemele cu date cu caracter personal, date financiare, acces la mediul de producție sau funcții cu impact asupra serviciilor.
• Exportați metodele MFA și excepțiile curente.
• Identificați conturile externe și ale furnizorilor.
• Adăugați oboseala MFA și push bombing în Registrul de riscuri.
• Desemnați un proprietar de risc și un responsabil pentru tratare.

Săptămâna 2: securizați autentificarea

• Dezactivați autentificarea moștenită.
• Impuneți MFA rezistentă la phishing pentru administratori, acolo unde este fezabil.
• Activați potrivirea numerică și contextul aplicației pentru MFA prin push.
• Aplicați acces condiționat pentru locație, conformitatea dispozitivului și deplasare imposibilă.
• Limitați solicitările push repetate.
• Impuneți reautentificarea pentru acțiuni cu risc ridicat.
• Faceți conturile de serviciu neinteractive acolo unde este posibil.
• Documentați excepțiile cu dată de expirare și controale compensatorii.

Săptămâna 3: monitorizați și exersați

• Asigurați-vă că jurnalele de autentificare captează succesul, eșecul, durata sesiunii și utilizarea MFA.
• Creați reguli de alertare pentru solicitări repetate, solicitări respinse urmate de aprobare, înregistrarea unui dispozitiv nou și locație neobișnuită.
• Testați alertele printr-o simulare controlată.
• Validați crearea tichetelor de incident și escaladarea.
• Instruiți utilizatorii printr-un scurt exercițiu privind „solicitarea MFA neașteptată”.
• Actualizați scripturile helpdesk pentru a preveni ingineria socială în timpul resetării parolelor și reînrolării MFA.

Săptămâna 4: dovezi și revizuire de management

• Stocați exporturile de configurare și capturile de ecran.
• Înregistrați rezultatele revizuirilor accesului.
• Corelați finalizarea instruirii cu utilizatorii privilegiați.
• Revizuiți incidentele și incidentele evitate la limită.
• Actualizați Declarația de aplicabilitate și planul de tratare.
• Prezentați managementului riscul rezidual și metricile.
• Programați eșantionarea pentru auditul intern.

Faceți oboseala MFA auditabilă înainte să devină raportabilă

Oboseala MFA amintește că măsurile de securitate eșuează la intersecții: între identitate și monitorizare, între politică și instruire, între furnizori și accesul intern, între răspuns la incidente și raportarea de confidențialitate.

Organizațiile care gestionează bine acest risc nu se limitează la „activarea MFA”. Ele guvernează autentificarea ca un ciclu de viață, o monitorizează ca semnal de amenințare, instruiesc utilizatorii ca parte a controlului și păstrează dovezile ca parte a SMSI.

Clarysec reunește trei active:

• Zenith Blueprint: foaia de parcurs în 30 de pași pentru auditori, în special Pasul 19 pentru autentificare securizată, Pasul 22 pentru informații de autentificare și Pasul 16 pentru raportarea incidentelor de către personal.
• Șabloanele de politici Clarysec, inclusiv P38 Politica privind comunicațiile securizate și autentificarea multifactor (MFA), P22S Politica de jurnalizare și monitorizare - IMM, P11S Politica privind gestionarea conturilor de utilizator și a privilegiilor - IMM, Politica privind conștientizarea și instruirea în domeniul securității informației - IMM, Politica de securitate și control al accesului la PII și Politica de gestionare a incidentelor și încălcărilor securității PII.
• Zenith Controls: ghidul de conformitate între cadre, care mapează controalele ISO/IEC 27002:2022 5.17, 8.5, 8.15 și 8.16 la controale-suport, așteptări de audit ISO, GDPR, NIS2, DORA, NIST și COBIT.

Dacă sunteți CISO, manager de conformitate, auditor sau responsabil de business, derulați o revizuire de o săptămână a dovezilor privind oboseala MFA. Extrageți configurația MFA, jurnalele de autentificare, lista accesului privilegiat, lista accesului furnizorilor, playbook-ul de incident, materialul de instruire și Registrul de excepții. Dacă aceste artefacte nu spun o poveste coerentă, Clarysec vă poate ajuta să construiți pachetul de controale înainte ca un atacator, auditor sau o autoritate de reglementare să îl solicite.

Explorați Zenith Blueprint, revizuiți Zenith Controls sau programați un apel de descoperire cu Clarysec pentru a transforma oboseala MFA dintr-o surpriză la nivelul organului de conducere într-un program de autentificare defensabil și verificabil prin audit.