MFA nuovargio ir „push bombing“ atakų valdysena

2:13 val. nakties „push“ pranešimas, tapęs valdybos klausimu

2:13 val. nakties vyresnioji finansų administratorė gauna pranešimą telefone: „Patvirtinti prisijungimą?“ Ji pusiau miega, mano, kad tai debesijos finansų platformos sesijos galiojimo pratęsimo užklausa, ir paliečia „patvirtinti“.

2:19 val. užpuolikas jau yra tapatybės teikėjo aplinkoje. 2:31 val. jis bando gauti prieigą prie darbo užmokesčio eksporto, privilegijuotos debesijos konsolės ir bendros pašto dėžutės, naudojamos tiekėjų mokėjimams. 3:05 val. SOC mato pasikartojančias MFA užklausas, neįprastą geografinę vietą, sėkmingą patvirtinimą ir naują sesiją iš nevaldomo įrenginio.

Ryto pokalbis pažįstamas:

• „Bet juk turėjome MFA.“
• „Kodėl naudotojas tai patvirtino?“
• „Ar užregistravome MFA iššūkio duomenis?“
• „Ar tai asmens duomenų saugumo pažeidimas?“
• „Ar turime 24 valandų arba 72 valandų pranešimo pareigas?“
• „Ar mūsų ISO 27001:2022 auditorius tai laikys kontrolės priemonės nesuveikimu?“
• „Ar tai turi poveikį NIS2, DORA, GDPR, klientų sutartims ar kibernetiniam draudimui?“

Tai yra valdysenos spraga, slypinti už MFA nuovargio ir „push bombing“. Užpuolikai nelaužo kriptografijos. Jie išsekina žmogaus sprendimų priėmimą, išnaudoja silpną autentifikavimo projektavimą ir ieško nestebimų išimčių. Kontrolės priemonės nesuveikimas retai būna „MFA neįjungtas“. Dažniausiai tai silpno tapatybės patikimumo užtikrinimo, rizikingo „push“ patvirtinimo modelio, trūkstamo skaičių sutapdinimo, neaiškių privilegijuotos prieigos taisyklių, nepakankamo autentifikavimo žurnalavimo, silpno įspėjimų pirminio vertinimo, nepakankamai apmokytų naudotojų ir nedokumentuotų įrodymų, kad organizacija peržiūrėjo ir ištaisė silpnąją vietą, grandinė.

CISO, atitikties vadovams, auditoriams ir verslo savininkams MFA nuovargis turi būti vertinamas kaip ISVS įrodymų problema, o ne tik kaip tapatybės teikėjo nustatymas. Sprendimas apima ISO 27001:2022 rizikos tvarkymą, ISO/IEC 27002:2022 kontrolės priemones, politikos reikalavimus, naudotojų informuotumą, reagavimą į incidentus, tiekėjų valdyseną ir susiejimą su keliomis sistemomis: NIS2, DORA, GDPR, NIST CSF 2.0 ir COBIT 2019.

MFA nuovargis yra patikimumo užtikrinimo nesėkmė, o ne naudotojo problema

MFA nuovargis, dar vadinamas „push bombing“ arba patvirtinimo užklausų bombardavimu, įvyksta tada, kai galiojantį slaptažodį turintis užpuolikas pakartotinai inicijuoja MFA patvirtinimo užklausas, kol naudotojas vieną jų priima. Kartais užpuolikas prideda socialinę inžineriją, pavyzdžiui, suklastotą pagalbos tarnybos skambutį, žinutę „testuojame jūsų paskyrą“ arba prašymą patvirtinti prisijungimą, kad pranešimai liautųsi.

Operacinė rizika kyla todėl, kad organizacijos dažnai visus MFA metodus laiko lygiaverčiais. Taip nėra.

Paprastas „patvirtinti arba atmesti“ tipo „push“ pranešimas yra silpnesnis nei skaičių sutapdinimas, fišingui atsparūs FIDO2 saugos raktai, sertifikatais pagrįstas autentifikavimas arba sąlyginė prieiga, blokuojanti neįmanomo keliavimo scenarijus ir nevaldomus įrenginius. MFA taip pat neveikia tinkamai, kai apėjimo išimtys nėra dokumentuotos, paslaugų paskyros yra interaktyvios, senieji protokolai lieka atviri arba didelės rizikos prieigai nereikalaujama stipresnio autentifikavimo.

Zenith Blueprint: auditoriaus 30 žingsnių planas Clarysec saugų autentifikavimą pateikia kontrolės priemonių taikymo etape, 19 veiksme: Technologinės kontrolės priemonės I. Gairė tiesioginė:

Autentifikavimas yra pirmoji ir svarbiausia gynybos linija tarp grėsmės veikėjo ir jūsų sistemų, duomenų bei paslaugų. Jei autentifikavimas silpnas, visa kita — šifravimas, stebėsena, segmentavimas — gali būti apeita.

Tas pats Zenith Blueprint 22 veiksme taip pat aptaria ISO/IEC 27002:2022 kontrolę 5.17:

Jei tapatybė atsako į klausimą „Kas jūs?“, autentifikavimas yra įrodymas. Kontrolė 5.17 yra vieta, kur teorija susitinka su pasitikėjimu. Ji reikalauja, kad autentifikavimo informacija būtų saugiai valdoma per visą jos gyvavimo ciklą, užtikrinant, kad tapatybei patikrinti naudojami metodai ir prisijungimo duomenys patys netaptų silpniausia grandimi.

Šie du teiginiai paaiškina, kodėl „push bombing“ turi būti rizikų registre. Šifravimas nepadeda, jei užpuolikas tampa patvirtintu naudotoju. Tinklo segmentavimas mažiau padeda, jei privilegijuota debesijos prieiga patvirtinama dėl nuovargio. Stebėsena veikia tik tada, kai autentifikavimo įvykiai pakankamai išsamiai registruojami žurnaluose ir greitai peržiūrimi.

Brandus rizikos aprašymas turi būti aiškus:

Čia ISO 27001:2022 tampa svarbus. Standartas reikalauja konteksto, suinteresuotųjų šalių, lyderystės, rizikos vertinimo, rizikos tvarkymo planavimo, operacinės kontrolės, stebėsenos, vidaus audito, vadovybės peržiūros ir nuolatinio tobulinimo. MFA nuovargis paliečia juos visus.

ISO 27001:2022 kontrolės priemonių grupė, kurią tikrins auditoriai

ISO 27001:2022 pateikia valdymo sistemos struktūrą. ISO/IEC 27002:2022 pateikia kontrolės priemonių įgyvendinimo gaires. MFA nuovargio ir „push bombing“ atveju auditoriai paprastai vertins kontrolės priemonių grupę, o ne vieną kontrolę.

Clarysec Zenith Controls: kelių atitikties sistemų vadovas susieja ISO/IEC 27002:2022 kontrolę 8.5 Secure authentication su pagalbinėmis kontrolės priemonėmis, tokiomis kaip 5.17 Authentication information, 8.2 Privileged access rights, 8.16 Monitoring activities, 5.24 Information security incident management planning and preparation ir 5.34 Privacy and protection of PII. Ši tarpusavio sąsaja svarbi, nes ekrano kopijos, rodančios „MFA įjungtas“, nepakanka. Auditoriai nori įrodymų, kad autentifikavimas yra suprojektuotas, stebimas, peržiūrimas ir tobulinamas remiantis rizika.

Pagrindžiamame įrodymų pakete turėtų būti:

1. Rizikos vertinimas, kuriame identifikuotas „push bombing“ ir socialinė inžinerija naudojant MFA užklausas.
2. Autentifikavimo standartas, apibrėžiantis priimtinus MFA metodus pagal sistemos kritiškumą.
3. Privilegijuotos prieigos politika, reikalaujanti stipresnio autentifikavimo administratoriaus ir nuotolinei prieigai.
4. Tapatybės teikėjo konfigūracijos eksportas, rodantis skaičių sutapdinimą, užklausų ribas, sąlyginę prieigą ir užblokuotą senąjį autentifikavimą.
5. Žurnalai, rodantys sėkmingus ir nesėkmingus MFA įvykius, atmestas užklausas, neįmanomo keliavimo scenarijus ir įrenginio kontekstą.
6. Įspėjimų taisyklės pasikartojančioms MFA užklausoms, pasikartojančioms nesėkmėms ir neįprastam sėkmingam patvirtinimui.
7. Reagavimo į incidentus įrašai dėl su autentifikavimu susijusių įspėjimų.
8. Informuotumo mokymų turinys, nurodantis naudotojams netvirtinti netikėtų užklausų.
9. Prieigos peržiūros įrašai dėl privilegijuotų ir didelio poveikio sistemų.
10. Išimčių registras su galiojimo pabaigos datomis, rizikos savininkų patvirtinimais ir kompensuojančiomis kontrolės priemonėmis.

Politika paverčia „netvirtinkite netikėtų užklausų“ įrodymais

Daugelis organizacijų naudotojams sako netvirtinti įtartinų užklausų. Šis patarimas naudingas, tačiau jo nepakanka ISO 27001:2022 sertifikavimui, NIS2 priežiūrai, DORA atsparumui, GDPR atskaitomybei, klientų deramam patikrinimui ar kibernetiniam draudimui.

Pirmasis politikos atramos taškas yra P38 Saugių ryšių ir kelių veiksnių autentifikavimo (MFA) politika. Joje tiesiogiai aptariama žmogaus pusė:

Naudotojų informuotumas: naudotojai turi būti mokomi atskirti saugius ryšio kanalus nuo nesaugių. Mokymai turi apimti tinkamą kelių veiksnių autentifikavimo (MFA) naudojimą (pvz., netvirtinti netikėtų prisijungimo užklausų) ir saugios komunikacijos praktiką (pvz., tikrinti vaizdo konferencijų nuorodas ir neaptarinėti konfidencialių temų nesaugiais kanalais).

Tai paverčia MFA nuovargį mokymų pareiga, o ne kaltinimo pratimu. CISO gali parodyti, kad užklausų bombardavimas įtrauktas į įvadinius mokymus, žinių atnaujinimo mokymus, vaidmenimis pagrįstus mokymus ir privilegijuotų naudotojų instruktažus.

Ta pati P38 Saugių ryšių ir kelių veiksnių autentifikavimo (MFA) politika taip pat sukuria stebėsenos pareigą:

Informacijos saugumo funkcija turi nuolat stebėti autentifikavimo žurnalus dėl bet kokių vieno veiksnio prisijungimo bandymų arba anomalių kelių veiksnių autentifikavimo (MFA) nesėkmių. Kai taikoma, saugių ryšių sistemų žurnalai turi būti stebimi dėl neteisėtos prieigos bandymų arba konfigūracijos pakeitimų.

MVĮ taikoma P11S Naudotojų paskyrų ir privilegijų valdymo politika – MVĮ nustato praktinį bazinį reikalavimą:

Kelių veiksnių autentifikavimas (MFA) turi būti įjungtas, kai techniškai įmanoma, administratorių paskyroms arba jautrioms sistemoms.

Formuluotė „kai techniškai įmanoma“ niekada neturi tapti spraga. Jei sistema nepalaiko stipraus MFA, išimtis turi būti užregistruota nurodant savininką, galiojimo pabaigos datą, kompensuojančias kontrolės priemones, stebėseną ir migracijos planą. Didesnės organizacijos gali tą patį lūkestį suderinti su P11 Naudotojų paskyrų ir privilegijų valdymo politika, o tada patikrinti, ar politika atitinka operacinę realybę.

Aptikimo įrodymai gaunami iš P22S Žurnalų tvarkymo ir stebėsenos politika – MVĮ, kurioje reikalaujama autentifikavimo įvykių žurnalavimo:

Autentifikavimo žurnalai: sėkmingi ir nesėkmingi prisijungimo bandymai, sesijos trukmė, MFA naudojimas

Joje taip pat reikalaujama skubiai peržiūrėti didelės rizikos autentifikavimo signalus:

Nedelsiant peržiūrėti aptikus didelio sunkumo įspėjimus (pvz., kenkimo programinę įrangą, nesėkmingą kelių veiksnių autentifikavimą (MFA), pasikartojančias prisijungimo nesėkmes)

Informuotumas turi keistis kartu su grėsmėmis. Informacijos saugumo informuotumo ir mokymo politika – MVĮ palaiko šį ciklą:

Temos turi apimti naujas grėsmes (pvz., fišingą), aktualius politikos pakeitimus ir vidines incidentų tendencijas.

Kai SOC aptinka MFA nuovargio bandymus, ši grėsmių informacija turi būti panaudota naudotojų įspėjimams, pagalbos tarnybos scenarijams, stalo pratyboms ir mokymų atnaujinimams.

Valdomas MFA nuovargio kontrolės priemonių paketas

Tarkime, jūsų organizacija naudoja debesijos tapatybės teikėją, SaaS CRM, finansų platformą, VPN ir valdomų saugumo paslaugų teikėją. Tikslas — valdyti MFA nuovargį naudojant Clarysec Zenith Blueprint, politikų biblioteką ir Zenith Controls kelių atitikties sistemų vadovą.

Pradėkite nuo 19 veiksmo Zenith Blueprint, kuriame komandoms nurodoma apibrėžti autentifikavimo reikalavimus kiekvienai sistemai ir perspėjama, kad vien slaptažodžiais pagrįsto autentifikavimo reikėtų vengti administracinėms paskyroms, debesijos konsolėms, nuotolinės prieigos priemonėms ir į internetą nukreiptoms sistemoms. Tada pritaikykite praktinę peržiūros veiklą:

Peržiūrėkite savo MFA diegimą: nustatykite spragas ir suplanuokite jų pašalinimą. Patikrinkite, kad paslaugų paskyros, kai įmanoma, būtų neinteraktyvios, turėtų stiprius prisijungimo duomenis ir būtų dokumentuotos. Patvirtinkite, kad jokioje sistemoje ar taikomojoje programoje neliko numatytųjų prisijungimo duomenų.

Paverskite šias gaires veikiančiu kontrolės priemonių paketu.

1 veiksmas: klasifikuokite sistemas pagal autentifikavimo riziką

2 veiksmas: pašalinkite didelės rizikos „push“ elgseną

Administratoriaus ir didelio poveikio paskyroms išjunkite bazinį „push“ patvirtinimą. Kur įmanoma, naudokite fišingui atsparius autentifikatorius. Jei „push“ lieka, taikykite skaičių sutapdinimą, taikomosios programos kontekstą, geografinį kontekstą, įrenginio susiejimą ir užklausų dažnio ribas. Blokuokite senąjį autentifikavimą ir reikalaukite pakartotinio autentifikavimo rizikingoms sesijoms.

3 veiksmas: apibrėžkite MFA nuovargio įspėjimų taisykles

Praktinė SIEM taisyklė turėtų suveikti, kai per trumpą laikotarpį pasireiškia vienas ar keli iš šių dėsningumų:

• Trys ar daugiau MFA „push“ užklausų vienam naudotojui.
• Dvi atmestos užklausos, po kurių seka viena patvirtinta užklausa.
• MFA patvirtinimas iš naujos geografinės vietos arba nevaldomo įrenginio.
• MFA užklausa po slaptažodžių purškimo arba masinio pavogtų prisijungimo duomenų bandymo signalo.
• MFA patvirtinimas privilegijuotai prieigai ne įprastomis darbo valandomis.
• Naujo autentifikatoriaus registravimas netrukus po nesėkmingų prisijungimo bandymų.

Įspėjimas turėtų sukurti incidento užklausą, informuoti SOC arba saugumo vadovą ir reikalauti lokalizavimo veiksmų: sustabdyti sesiją, atšaukti atnaujinimo žetonus, pareikalauti slaptažodžio keitimo, patikrinti įrenginį, apklausti naudotoją, peržiūrėti prieigą sesijos metu ir klasifikuoti, ar įvyko poveikis asmens duomenims arba kritinei paslaugai.

4 veiksmas: susiekite privatumo ir incidentų įrašus

Jei paskyra gali pasiekti asmens duomenis, taikykite PII saugumo ir prieigos kontrolės politiką. Joje reikalaujama stipraus autentifikavimo prieš didelio poveikio PII prieigą:

[Abiem atvejais] Informacijos saugumo vadovas PRIVALO reikalauti stipraus autentifikavimo privilegijuotai, nuotolinei, administracinei arba didelio poveikio PII prieigai prieš tokią prieigą įjungiant ir užregistruoti reikalavimą REG12.

Joje taip pat reikalaujama apibrėžti žurnalavimo taikymo sritį:

[Abiem atvejais] Sistemos savininkas / taikomosios programos savininkas PRIVALO apibrėžti PII žurnalavimo taikymo sritį autentifikavimo įvykiams, prieigos įvykiams, privilegijuotiems veiksmams, PII eksporto veiklai ir esminiams konfigūracijos pakeitimams REG12 prieš naudojimą produkcinėje aplinkoje arba esminį pakeitimą.

Kai stebėsena rodo įtariamą neteisėtą PII prieigą, atsiranda pareiga sukurti incidento įrašą:

[Sąlyginai] Reagavimo į incidentus koordinatorius PRIVALO per vieną darbo dieną atidaryti arba susieti REG10 įrašą, kai stebėsena rodo įtariamą neteisėtą PII prieigą, įtariamą PII atskleidimą, įtariamą PII pakeitimą arba įtariamą PII prieinamumo praradimą.

Privatumo eskalavimą užbaigia PII incidentų ir pažeidimų valdymo politika:

[Sąlyginai] Privatumo vadovas / PIMS vadovas PRIVALO įvertinti taikomas teisines, sektorines, finansų sektoriaus, kibernetinio saugumo, sutartines, klientų ir paslaugų gavėjų pranešimo inicijavimo sąlygas kiekvienam didelio poveikio PII incidentui ir užregistruoti taikomumo rezultatą REG01, REG08 ir REG10.

Būtent tai MFA įspėjimą paverčia auditui tinkamais įrodymais saugumo, privatumo ir atitikties srityse.

NIS2, DORA ir GDPR: vienas incidentas, skirtingi klausimai

MFA nuovargis yra naudingas kelių atitikties sistemų atsparumo testas, nes apima valdyseną, kibernetinę higieną, prieigos kontrolę, incidentų aptikimą, tiekėjų prieigą ir pranešimą apie pažeidimus.

NIS2: vadovybės atskaitomybė ir kibernetinė higiena

NIS2 taikoma daugeliui esminių ir svarbių subjektų, priklausomai nuo sektoriaus, dydžio ir valstybės narės priskyrimo. Article 20 nustato valdymo organų atskaitomybę: patvirtinti kibernetinio saugumo rizikos valdymo priemones, prižiūrėti jų įgyvendinimą ir gauti mokymus. Article 21 reikalauja tinkamų techninių, operacinių ir organizacinių priemonių, įskaitant incidentų tvarkymą, kibernetinę higieną, tiekimo grandinės saugumą, prieigos kontrolę, turto valdymą, mokymus ir kelių veiksnių arba tęstinį autentifikavimą, kai tinkama. Article 23 nustato etapines pranešimo apie reikšmingus incidentus pareigas, įskaitant ankstyvą įspėjimą per 24 valandas nuo sužinojimo ir pranešimą apie incidentą per 72 valandas.

Todėl „push bombing“ incidentas tampa valdybos lygmens klausimu: ar MFA buvo suprojektuotas saugiai, ar tik įjungtas?

DORA: autentifikavimas kaip skaitmeninis operacinis atsparumas

Apimamoms finansų sektoriaus įmonėms DORA taikoma nuo 2025 m. sausio 17 d. Ji tikisi IRT rizikos valdymo, aptikimo, reagavimo, atkūrimo, pranešimo apie incidentus, skaitmeninio operacinio atsparumo testavimo ir trečiųjų šalių IRT rizikos valdymo.

DORA Article 9 reglamentuoja apsaugą ir prevenciją, įskaitant prieigos kontrolę ir autentifikavimo priemones. Article 10 reglamentuoja anomalios veiklos aptikimą. Article 17 reikalauja su IRT susijusių incidentų valdymo proceso. DORA kontekste MFA nuovargio įrodymai turėtų parodyti, kad paveikti IRT ištekliai buvo identifikuoti, stebėsena aptiko anomalią elgseną, incidentas buvo klasifikuotas pagal poveikio kriterijus, kai reikėjo — eskaluotas vyresniajai vadovybei, o įgyta patirtis buvo grąžinta į IRT rizikos valdymo sistemą.

GDPR: tvarkymo saugumas ir atskaitomybė

GDPR Article 5(1)(f) reikalauja vientisumo ir konfidencialumo. Article 5(2) reikalauja atskaitomybės. Article 32 reikalauja riziką atitinkančio saugumo. Article 4 asmens duomenų saugumo pažeidimą apibrėžia kaip saugumo pažeidimą, dėl kurio atsitiktinai ar neteisėtai sunaikinami, prarandami, pakeičiami, neteisėtai atskleidžiami asmens duomenys arba suteikiama neteisėta prieiga prie jų.

Jei MFA nuovargio incidentas paliečia asmens duomenis, įrodymų klausimas paprastas: ar organizacija gali parodyti tinkamas autentifikavimo kontrolės priemones, stebėseną, reagavimą į incidentus ir pažeidimo vertinimą?

ISO, NIST CSF 2.0, COBIT 2019 ir audito įrodymų susiejimas

NIST CSF 2.0 naudingas, nes MFA valdyseną paverčia GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND ir RECOVER rezultatais.

COBIT 2019 suteikia valdysenos aiškumo. COBIT orientuotas auditorius gali vertinti DSS05.04 Manage identity and logical access, DSS05 Manage security services, APO13 Managed security ir MEA03 Managed compliance with external requirements. Dėmesys skiriamas ne MFA tiekėjui. Vertinama, ar autentifikavimas palaiko verslo tikslus, ar prieigos teisės valdomos, ar stebėsena veiksminga ir ar vadovybė gauna prasmingą patikinimą.

Konsoliduotas susiejimas padeda atitikties komandoms išvengti fragmentuotų įrodymų prašymų:

Ko prašys auditoriai ir priežiūros institucijos

Stipri MFA nuovargio programa turi atlaikyti skirtingus audito metodus. Clarysec Zenith Controls kelių atitikties sistemų vadovas rodo, kaip ISO/IEC 27002:2022 kontrolės priemonės tikrinamos pagal ISO, NIST, COBIT ir ISACA metodikas.

Silpna programa sako: „Paklausėme naudotojo ir iš naujo nustatėme slaptažodį.“ Valdoma programa pateikia SIEM įspėjimą, incidento užklausą, sesijos atšaukimo įrašą, slaptažodžio keitimo įrodymus, MFA veiksnio peržiūrą, prieigos žurnalų analizę, PII vertinimą, pranešimo inicijavimo sąlygų vertinimą, pagrindinės priežasties aprašymą, korekcinius veiksmus ir vadovybės peržiūros įvestį.

30 dienų veiksmų planas MFA nuovargio valdysenai

Tikslas nėra per 30 dienų pasiekti tobulumą. Tikslas — matomumas, atsakomybė ir įrodymai.

1 savaitė: identifikuokite ir apibrėžkite taikymo sritį

• Išvardykite visus tapatybės teikėjus, VPN, debesijos konsoles, SaaS platformas ir privilegijuotos prieigos priemones.
• Nustatykite sistemas, kuriose yra asmens duomenų, finansinių duomenų, prieiga prie produkcinės aplinkos arba paslaugai poveikį darančios funkcijos.
• Eksportuokite esamus MFA metodus ir išimtis.
• Identifikuokite išorines ir tiekėjų paskyras.
• Įtraukite MFA nuovargį ir „push bombing“ į rizikų registrą.
• Paskirkite rizikos savininką ir rizikos tvarkymo savininką.

2 savaitė: sustiprinkite autentifikavimą

• Išjunkite senąjį autentifikavimą.
• Kai įmanoma, reikalaukite fišingui atsparaus MFA administratoriams.
• Įjunkite skaičių sutapdinimą ir taikomosios programos kontekstą „push“ MFA.
• Taikykite sąlyginę prieigą pagal vietą, įrenginio atitiktį ir neįmanomo keliavimo scenarijus.
• Ribokite pasikartojančias „push“ užklausas.
• Reikalaukite pakartotinio autentifikavimo didelės rizikos veiksmams.
• Kai įmanoma, padarykite paslaugų paskyras neinteraktyvias.
• Dokumentuokite išimtis nurodydami galiojimo pabaigą ir kompensuojančias kontrolės priemones.

3 savaitė: stebėkite ir repetuokite

• Užtikrinkite, kad autentifikavimo žurnalai fiksuotų sėkmę, nesėkmę, sesijos trukmę ir MFA naudojimą.
• Sukurkite įspėjimų taisykles pasikartojančioms užklausoms, atmestoms užklausoms, po kurių seka patvirtinimas, naujo įrenginio registravimui ir neįprastai vietai.
• Išbandykite įspėjimus kontroliuojama simuliacija.
• Patikrinkite incidento užklausos sukūrimą ir eskalavimą.
• Apmokykite naudotojus trumpu „netikėtos MFA užklausos“ pratimu.
• Atnaujinkite pagalbos tarnybos scenarijus, kad būtų užkirstas kelias socialinei inžinerijai slaptažodžių atkūrimo ir MFA pakartotinio registravimo metu.

4 savaitė: įrodymai ir vadovybės peržiūra

• Saugokite konfigūracijos eksportus ir ekrano kopijas.
• Užregistruokite prieigos peržiūros rezultatus.
• Susiekite mokymų baigimą su privilegijuotais naudotojais.
• Peržiūrėkite incidentus ir beveik įvykusius atvejus.
• Atnaujinkite Taikytinumo pareiškimą (SoA) ir rizikos tvarkymo planą.
• Pateikite liekamąją riziką ir rodiklius vadovybei.
• Suplanuokite vidaus audito imčių tikrinimą.

Padarykite MFA nuovargį audituojamą, kol jis netapo praneštinas

MFA nuovargis primena, kad saugumo kontrolės priemonės nesuveikia sandūrose: tarp tapatybės ir stebėsenos, tarp politikos ir mokymų, tarp tiekėjų ir vidinės prieigos, tarp reagavimo į incidentus ir privatumo pranešimų.

Organizacijos, kurios tai valdo gerai, ne vien „įjungia MFA“. Jos valdo autentifikavimą kaip gyvavimo ciklą, stebi jį kaip grėsmės signalą, moko naudotojus kaip kontrolės priemonės dalį ir saugo įrodymus kaip ISVS dalį.

Clarysec sujungia tris išteklius:

• Zenith Blueprint: auditoriaus 30 žingsnių planas, ypač 19 veiksmą dėl saugaus autentifikavimo, 22 veiksmą dėl autentifikavimo informacijos ir 16 veiksmą dėl personalo inicijuojamo pranešimo apie incidentus.
• Clarysec politikų šablonus, įskaitant P38 Saugių ryšių ir kelių veiksnių autentifikavimo (MFA) politiką, P22S Žurnalų tvarkymo ir stebėsenos politiką – MVĮ, P11S Naudotojų paskyrų ir privilegijų valdymo politiką – MVĮ, Informacijos saugumo informuotumo ir mokymo politiką – MVĮ, PII saugumo ir prieigos kontrolės politiką ir PII incidentų ir pažeidimų valdymo politiką.
• Zenith Controls: kelių atitikties sistemų vadovą, kuris susieja ISO/IEC 27002:2022 kontrolės priemones 5.17, 8.5, 8.15 ir 8.16 su pagalbinėmis kontrolės priemonėmis, ISO audito lūkesčiais, GDPR, NIS2, DORA, NIST ir COBIT.

Jei esate CISO, atitikties vadovas, auditorius ar verslo savininkas, atlikite vienos savaitės MFA nuovargio įrodymų peržiūrą. Surinkite MFA konfigūraciją, autentifikavimo žurnalus, privilegijuotos prieigos sąrašą, tiekėjų prieigos sąrašą, incidentų veiksmų planą, mokymų medžiagą ir išimčių registrą. Jei šie artefaktai nepasako vienos nuoseklios istorijos, Clarysec gali padėti sukurti kontrolės priemonių paketą, kol jo nepaprašė užpuolikas, auditorius ar priežiūros institucija.

Susipažinkite su Zenith Blueprint, peržiūrėkite Zenith Controls arba suplanuokite Clarysec įvadinį pokalbį, kad MFA nuovargį iš valdybos lygmens staigmenos paverstumėte pagrindžiama, audituojama autentifikavimo programa.