MFA-väsimuse ja push-teavituste pommitamise rünnete juhtimine

Kell 2:13 saabunud push-teavitus, millest sai juhatuse küsimus

Kell 2:13 saab vanem finantshaldur mobiiliteavituse: „Kinnita sisselogimine?“ Ta on pooleldi unes, eeldab, et tegemist on pilvepõhise finantsplatvormi seansi ajalõpuga, ja puudutab kinnitamisnuppu.

Kell 2:19 on ründaja identiteedipakkujas sees. Kell 2:31 üritab ta pääseda juurde palgaandmete ekspordile, privilegeeritud pilvekonsoolile ja jagatud postkastile, mida kasutatakse tarnijamaksete jaoks. Kell 3:05 tuvastab SOC korduvaid MFA-viipasid, ebatavalist geograafilist asukohta, õnnestunud kinnitust ja uut seanssi hallatamata seadmest.

Hommikune vestlus on tuttav:

• „Aga meil oli MFA.“
• „Miks kasutaja selle kinnitas?“
• „Kas me logisime MFA väljakutse üksikasjad?“
• „Kas see on isikuandmetega seotud rikkumine?“
• „Kas meil on 24 või 72 tunni teatamiskohustused?“
• „Kas meie ISO 27001:2022 audiitor käsitleb seda kontrollimeetme tõrkena?“
• „Kas see mõjutab NIS2, DORA, GDPR, kliendilepinguid või küberkindlustust?“

See on MFA-väsimuse ja push-teavituste pommitamise taga olev juhtimislünk. Ründajad ei murra krüptograafiat. Nad kurnavad inimese otsustusvõimet, kasutavad ära nõrka autentimisdisaini ja otsivad seiramata erandeid. Kontrollimeetme tõrge on harva „MFA ei olnud lubatud“. Tavaliselt on see nõrga identiteedikindluse, riskantse push-kinnituse disaini, puuduva numbrivastavuse, ebaselgete privilegeeritud juurdepääsu reeglite, ebapiisava autentimislogimise, nõrga teavituste esmase hindamise, ebapiisavalt koolitatud kasutajate ning dokumenteeritud tõendusmaterjali puudumise ahel, mis näitaks, et organisatsioon on nõrkuse läbi vaadanud ja kõrvaldanud.

Infoturbejuhtide, vastavusjuhtide, audiitorite ja ettevõtete omanike jaoks tuleb MFA-väsimust käsitleda ISMS-i tõendusmaterjali probleemina, mitte pelgalt identiteedipakkuja seadistusena. Lahendus ühendab ISO 27001:2022 riskikäsitluse, ISO/IEC 27002:2022 kontrollimeetmed, poliitikast tulenevad kohustused, kasutajate teadlikkuse, intsidentidele reageerimise, tarnijate juhtimise ning raamistikeülesed vastendused NIS2, DORA, GDPR, NIST CSF 2.0 ja COBIT 2019 jaoks.

MFA-väsimus on kindluse andmise tõrge, mitte kasutaja probleem

MFA-väsimus, mida nimetatakse ka push-teavituste pommitamiseks või viipadega pommitamiseks, tekib siis, kui kehtiva parooliga ründaja käivitab korduvalt MFA kinnitustaotlusi, kuni kasutaja ühe neist aktsepteerib. Mõnikord lisab ründaja sotsiaalse manipulatsiooni, näiteks võltsitud kasutajatoe kõne, sõnumi „testime teie kontot“ või palve kinnitada sisselogimine, et teavitused peatuksid.

Operatiivne oht seisneb selles, et organisatsioonid käsitlevad sageli kõiki MFA-meetodeid samaväärsena. Need ei ole samaväärsed.

Lihtne „kinnita või keela“ push-teavitus on nõrgem kui numbrivastavus, andmepüügikindlad FIDO2 turvavõtmed, sertifikaadipõhine autentimine või tingimuslik juurdepääs, mis blokeerib võimatu liikumise ja hallatamata seadmed. MFA ebaõnnestub ka siis, kui möödahiilimise erandid on dokumenteerimata, teenusekontod võimaldavad interaktiivset sisselogimist, pärandprotokollid jäävad avatuks või kõrge riskiga juurdepääs ei nõua tugevamat autentimist.

Zenith Blueprint: audiitori 30 sammu teekaart käsitleb Clarysec turvalist autentimist jaotises „Kontrollimeetmed praktikas“, sammus 19: tehnilised kontrollimeetmed I. Suunis on otsene:

Autentimine on esimene ja kõige kriitilisem kaitseliin ohutegija ning teie süsteemide, andmete ja teenuste vahel. Kui autentimine on nõrk, saab kõigest muust — krüptimisest, seirest ja segmenteerimisest — mööda minna.

Sama Zenith Blueprint käsitleb sammus 22 ka ISO/IEC 27002:2022 kontrollimeedet 5.17:

Kui identiteedi küsimus on „Kes sa oled?“, siis autentimine on tõendus. Kontrollimeede 5.17 on koht, kus teooria kohtub usaldusega. See nõuab, et autentimisteavet hallataks turvaliselt kogu selle elutsükli vältel, tagades, et identiteedi kontrollimiseks kasutatavad meetodid ja autentimisandmed ei muutuks ise nõrgimaks lüliks.

Need kaks väidet selgitavad, miks push-teavituste pommitamine kuulub riskiregistrisse. Krüptimine ei aita, kui ründajast saab heakskiidetud kasutaja. Võrgusegmenteerimisest on vähem kasu, kui privilegeeritud pilvejuurdepääs kinnitatakse väsimusest tingitud viiba kaudu. Seire toimib ainult siis, kui autentimissündmused logitakse piisava detailsusega ja vaadatakse kiiresti läbi.

Küps riskikirjeldus peab olema konkreetne:

Siin muutub ISO 27001:2022 oluliseks. Standard nõuab konteksti, huvitatud pooli, juhtimist, riskihindamist, käsitlusplaani, operatiivset ohjet, seiret, siseauditit, juhtkonna läbivaatust ja pidevat täiustamist. MFA-väsimus puudutab neid kõiki.

ISO 27001:2022 kontrollimeetmete kogum, mida audiitorid testivad

ISO 27001:2022 annab juhtimissüsteemi struktuuri. ISO/IEC 27002:2022 annab kontrollimeetmete rakendamise suunised. MFA-väsimuse ja push-teavituste pommitamise puhul keskenduvad audiitorid tavaliselt kontrollimeetmete kogumile, mitte ühele üksikule kontrollimeetmele.

Claryseci Zenith Controls: raamistikeülese nõuetelevastavuse juhend vastendab ISO/IEC 27002:2022 kontrollimeetme 8.5 Secure authentication toetavate kontrollimeetmetega, nagu 5.17 Authentication information, 8.2 Privileged access rights, 8.16 Monitoring activities, 5.24 Information security incident management planning and preparation ning 5.34 Privacy and protection of PII. See ristseos on oluline, sest kuvatõmmis tekstiga „MFA lubatud“ ei ole piisav. Audiitorid soovivad tõendust, et autentimine on riskipõhiselt kavandatud, seiratud, läbi vaadatud ja täiustatud.

Kaitstav tõendusmaterjali pakett peab sisaldama järgmist:

1. Riskihindamine, milles on tuvastatud push-teavituste pommitamine ja MFA-viipadega seotud sotsiaalne manipulatsioon.
2. Autentimisstandard, mis määratleb vastuvõetavad MFA-meetodid süsteemi kriitilisuse alusel.
3. Privilegeeritud juurdepääsu poliitika, mis nõuab administraatori- ja kaugjuurdepääsu korral tugevamat autentimist.
4. Identiteedipakkuja konfiguratsiooni väljavõte, mis näitab numbrivastavust, viipade piiranguid, tingimuslikku juurdepääsu ja blokeeritud pärandautentimist.
5. Logid, mis näitavad õnnestunud ja ebaõnnestunud MFA sündmusi, keeldutud viipasid, võimatut liikumist ning seadme konteksti.
6. Teavitusreeglid korduvate MFA-viipade, korduvate tõrgete ja ebatavalise õnnestunud kinnituse jaoks.
7. Autentimisega seotud teavituste intsidentidele reageerimise kirjed.
8. Teadlikkuskoolituse sisu, mis juhendab kasutajaid ootamatuid viipasid mitte kinnitama.
9. Juurdepääsuõiguste läbivaatamise kirjed privilegeeritud ja suure mõjuga süsteemide kohta.
10. Erandiregister aegumiskuupäevade, riskiomaniku heakskiitude ja kompenseerivate kontrollimeetmetega.

Poliitika muudab „ära kinnita ootamatuid viipasid“ tõendusmaterjaliks

Paljud organisatsioonid ütlevad kasutajatele, et kahtlasi viipasid ei tohi kinnitada. See nõuanne on kasulik, kuid sellest ei piisa ISO 27001:2022 sertifitseerimiseks, NIS2 järelevalveks, DORA toimepidevuseks, GDPR-i vastutuseks, klientide hoolsuskontrolliks ega küberkindlustuseks.

Esimene poliitikaankur on P38 turvalise side ja mitmefaktorilise autentimise (MFA) poliitika. See käsitleb otseselt inimtegurit:

Kasutajate teadlikkus: kasutajad peavad saama koolitust turvaliste ja ebaturvaliste sidekanalite eristamiseks. Koolitus peab hõlmama mitmefaktorilise autentimise (MFA) nõuetekohast kasutamist (nt ootamatute sisselogimisviipade mitte kinnitamist) ning turvalise side tavasid (nt videokonverentsi linkide kontrollimist ja konfidentsiaalsete teemade mitte arutamist ebaturvalistel liinidel).

See muudab MFA-väsimuse koolituskohustuseks, mitte süüdistamiseks. See võimaldab infoturbejuhil näidata, et push-teavituste pommitamine on hõlmatud sisseelamise, korduskoolituse, rollipõhise koolituse ja privilegeeritud kasutajate briifingutega.

Sama P38 turvalise side ja mitmefaktorilise autentimise (MFA) poliitika loob ka seirekohustuse:

Infoturbefunktsioon peab pidevalt seirama autentimisloge ühefaktorilise sisselogimise katsete või anomaalsete mitmefaktorilise autentimise (MFA) tõrgete tuvastamiseks. Turvaliste sidesüsteemide logisid tuleb vajaduse korral seirata loata juurdepääsukatsete või konfiguratsioonimuudatuste suhtes.

VKE-de jaoks seab P11S kasutajakontode ja õiguste haldamise poliitika - VKE praktilise baastaseme:

Mitmefaktoriline autentimine (MFA) peab olema tehnilise teostatavuse korral lubatud administraatorikontode või tundlike süsteemide puhul.

Väljend „tehnilise teostatavuse korral“ ei tohi kunagi muutuda möödapääsuks. Kui süsteem ei toeta tugevat MFA-d, tuleb erand registreerida koos omaniku, aegumiskuupäeva, kompenseerivate kontrollimeetmete, seire ja migratsiooniplaaniga. Suuremad organisatsioonid saavad sama ootuse joondada P11 kasutajakontode ja õiguste haldamise poliitikaga ning seejärel testida, kas poliitika ja operatiivne tegelikkus kattuvad.

Tuvastamise tõendusmaterjal tuleb P22S logimis- ja seirepoliitikast - VKE, mis nõuab autentimissündmuste logimist:

Autentimislogid: õnnestunud ja ebaõnnestunud sisselogimiskatsed, seansi kestus, MFA kasutus

See nõuab ka kõrge riskiga autentimissignaalide kiiret läbivaatamist:

Viivitamatu läbivaatamine kõrge tõsidusega teavituste tuvastamisel (nt pahavara, ebaõnnestunud mitmefaktoriline autentimine (MFA), korduvad sisselogimistõrked)

Teadlikkus peab arenema koos ohtudega. Infoturbe teadlikkuse ja koolituse poliitika - VKE toetab seda tagasisideahelat:

Teemad peavad hõlmama esilekerkivaid ohte (nt andmepüük), asjakohaseid poliitikamuudatusi ja sisemisi intsidentide suundumusi.

Kui SOC tuvastab MFA-väsimuse katsed, peab see ohuteave jõudma kasutajate hoiatustesse, kasutajatoe skriptidesse, lauaõppustesse ja koolituste ajakohastustesse.

Juhitud MFA-väsimuse kontrollipakett

Eeldame, et organisatsioon kasutab pilvepõhist identiteedipakkujat, SaaS CRM-i, finantsplatvormi, VPN-i ja hallatud turbeteenuse osutajat. Eesmärk on juhtida MFA-väsimust Claryseci Zenith Blueprinti, poliitikakogu ja Zenith Controls raamistikeülese nõuetelevastavuse juhendi abil.

Alustage Zenith Blueprinti sammust 19, mis juhendab meeskondi määratlema autentimisnõuded süsteemide kaupa ja hoiatab, et ainult paroolipõhist autentimist tuleb vältida administraatorikontode, pilvekonsoolide, kaugjuurdepääsutööriistade ja internetile avatud süsteemide puhul. Seejärel rakendage praktilist läbivaatamistegevust:

Vaadake oma MFA juurutus läbi: tuvastage lüngad ja kavandage nende kõrvaldamine. Valideerige, et teenusekontod on võimaluse korral mitteinteraktiivsed, neil on tugevad autentimisandmed ja need on dokumenteeritud. Kinnitage, et üheski süsteemis ega rakenduses ei ole jäänud vaikeautentimisandmeid.

Muutke see suunis toimivaks kontrollipaketiks.

Samm 1: klassifitseeri süsteemid autentimisriski alusel

Samm 2: kõrvalda kõrge riskiga push-käitumine

Administraatori- ja suure mõjuga kontode puhul keelake lihtne push-kinnitus. Kasutage võimaluse korral andmepüügikindlaid autentimisvahendeid. Kui push-meetod jääb kasutusse, rakendage numbrivastavust, rakenduse konteksti, geograafilist konteksti, seadme sidumist ja viipade sageduspiiranguid. Blokeerige pärandautentimine ja nõudke riskantsete seansside puhul uuesti autentimist.

Samm 3: määra MFA-väsimuse teavitusreeglid

Praktiline SIEM-i reegel peab käivituma, kui lühikese ajavahemiku jooksul esineb üks või mitu järgmist mustrit:

• Ühele kasutajale saadetakse kolm või enam MFA push-viipa.
• Kahele keeldutud viibale järgneb üks kinnitatud viip.
• MFA kinnitus pärineb uuest geograafilisest asukohast või hallatamata seadmest.
• MFA viip järgneb paroolipihustamise või autentimisandmete täistoppimise signaalile.
• MFA kinnitus antakse privilegeeritud juurdepääsule väljaspool tavapärast tööaega.
• Uus autentimisvahend registreeritakse vahetult pärast ebaõnnestunud sisselogimiskatseid.

Teavitus peab looma intsidendipileti, teavitama SOC-i või turbejuhti ning nõudma ohjeldamissamme: seansi peatamine, värskendustokenite tühistamine, parooli lähtestamise nõudmine, seadme kontrollimine, kasutaja küsitlemine, seansi ajal toimunud juurdepääsu läbivaatamine ning klassifitseerimine, kas esines mõju isikuandmetele või kriitilisele teenusele.

Samm 4: seo privaatsus- ja intsidendikirjed

Kui kontol on juurdepääs isikuandmetele, rakendage PII turbe ja juurdepääsukontrolli poliitikat. See nõuab tugevat autentimist enne suure mõjuga PII juurdepääsu:

[Mõlemad] Infoturbejuht PEAB nõudma tugevat autentimist enne privilegeeritud, kaug-, haldus- või suure mõjuga PII juurdepääsu lubamist ja registreerima nõude REG12-s.

See nõuab ka logimise kohaldamisala määratlemist:

[Mõlemad] Süsteemiomanik / rakenduse omanik PEAB määratlema PII logimise kohaldamisala autentimissündmuste, juurdepääsusündmuste, privilegeeritud toimingute, PII eksporditegevuse ja oluliste konfiguratsioonimuudatuste jaoks REG12-s enne tootmiskasutust või olulist muudatust.

Kui seire viitab loata PII juurdepääsule, tekib intsidendikirje kohustus:

[Tingimuslik] Intsidentidele reageerimise koordinaator PEAB avama või siduma REG10 kirje ühe tööpäeva jooksul, kui seire näitab kahtlustatavat loata PII juurdepääsu, kahtlustatavat PII avalikustamist, kahtlustatavat PII muutmist või kahtlustatavat PII käideldavuse kadu.

Privaatsuse eskaleerimise lõpetab PII intsidentide ja rikkumiste haldamise poliitika:

[Tingimuslik] Privaatsusjuht / PIMS-i juht PEAB hindama iga suure mõjuga PII intsidendi puhul kohaldatavaid õiguslikke, valdkondlikke, finantssektori, küberturbe-, lepingulisi, kliendi- ja teenusesaaja teavitamise aluseid ning registreerima kohaldatavuse tulemuse REG01-s, REG08-s ja REG10-s.

Nii muutub MFA teavitus auditeerimisvalmis tõendusmaterjaliks turbe, privaatsuse ja nõuetelevastavuse lõikes.

NIS2, DORA ja GDPR: üks intsident, erinevad küsimused

MFA-väsimus on kasulik raamistikeülese nõuetelevastavuse stressitest, sest see puudutab juhtimist, küberhügieeni, juurdepääsukontrolli, intsidentide tuvastamist, tarnija juurdepääsu ja rikkumisest teavitamist.

NIS2: juhtkonna vastutus ja küberhügieen

NIS2 kohaldub paljudele olulistele ja tähtsatele üksustele sõltuvalt sektorist, suurusest ja liikmesriigi määratlusest. Article 20 paneb juhtorganitele vastutuse küberturbe riskijuhtimise meetmete heakskiitmise, rakendamise järelevalve ja koolituse saamise eest. Article 21 nõuab asjakohaseid tehnilisi, operatiivseid ja korralduslikke meetmeid, sealhulgas intsidentide käsitlemist, küberhügieeni, tarneahela turvalisust, juurdepääsukontrolli, varahaldust, koolitust ning vajaduse korral mitmefaktorilist või pidevat autentimist. Article 23 kehtestab oluliste intsidentide etapiviisilised teatamiskohustused, sealhulgas varajase hoiatuse 24 tunni jooksul teada saamisest ja intsidenditeavituse 72 tunni jooksul.

Seetõttu muutub push-teavituste pommitamise intsident juhatuse tasandi küsimuseks: kas MFA oli turvaliselt kavandatud või lihtsalt lubatud?

DORA: autentimine kui digitaalne tegevuskerksus

Hõlmatud finantssektori üksustele kohaldub DORA alates 17. jaanuarist 2025. See eeldab IKT-riski juhtimist, tuvastamist, reageerimist, taastamist, intsidentidest teatamist, digitaalse tegevuskerksuse testimist ja IKT kolmandate osapoolte riskijuhtimist.

DORA Article 9 käsitleb kaitset ja ennetust, sealhulgas juurdepääsukontrolli ja autentimismeetmeid. Article 10 käsitleb anomaalse tegevuse tuvastamist. Article 17 nõuab IKT-ga seotud intsidendihalduse protsessi. DORA kontekstis peab MFA-väsimuse tõendusmaterjal näitama, et mõjutatud IKT-varad tuvastati, seire tuvastas anomaalse käitumise, intsident klassifitseeriti mõjukriteeriumide alusel, vajaduse korral eskaleeriti see kõrgemale juhtkonnale ning õppetunnid suunati tagasi IKT-riskiraamistikku.

GDPR: töötlemise turvalisus ja vastutus

GDPR Article 5(1)(f) nõuab terviklust ja konfidentsiaalsust. Article 5(2) nõuab vastutust. Article 32 nõuab riskile vastavat turvalisust. Article 4 määratleb isikuandmetega seotud rikkumise kui turvanõuete rikkumise, mis põhjustab isikuandmete juhusliku või ebaseadusliku hävitamise, kaotsimineku, muutmise, loata avalikustamise või neile loata juurdepääsu.

Kui MFA-väsimuse intsident puudutab isikuandmeid, on tõendusmaterjali küsimus lihtne: kas organisatsioon suudab tõendada asjakohaseid autentimiskontrolle, seiret, intsidentidele reageerimist ja rikkumise hindamist?

ISO, NIST CSF 2.0, COBIT 2019 ja audititõendusmaterjali vastendustabel

NIST CSF 2.0 on kasulik, sest see tõlgib MFA juhtimise GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND ja RECOVER tulemusteks.

COBIT 2019 lisab juhtimisselgust. COBIT-põhine audiitor võib vaadata DSS05.04 identiteedi ja loogilise juurdepääsu haldamist, DSS05 turvateenuste haldamist, APO13 hallatud turvet ning MEA03 väliste nõuetega vastavuse haldamist. Fookus ei ole MFA tarnijal. Küsimus on selles, kas autentimine toetab ärieesmärke, kas juurdepääsuõigused on juhitud, kas seire on tõhus ja kas juhtkond saab sisulist kindlust.

Koondvastendus aitab nõuetelevastavuse meeskondadel vältida killustatud tõendusmaterjali päringuid:

Mida audiitorid ja regulaatorid küsivad

Tugev MFA-väsimuse programm peab vastu pidama mitmele auditistiilile. Claryseci Zenith Controls raamistikeülese nõuetelevastavuse juhend näitab, kuidas ISO/IEC 27002:2022 kontrollimeetmeid testitakse ISO, NIST, COBIT ja ISACA metoodikates.

Nõrk programm ütleb: „Küsisime kasutajalt ja lähtestasime parooli.“ Juhitud programm loob SIEM-i teavituse, intsidendipileti, seansi tühistamise kirje, parooli lähtestamise tõendusmaterjali, MFA-teguri läbivaatamise, juurdepääsulogide analüüsi, PII hindamise, teavitamise aluste hindamise, algpõhjuse kirjelduse, parandusmeetmed ja sisendi juhtkonna läbivaatuseks.

30 päeva tegevusplaan MFA-väsimuse juhtimiseks

Eesmärk ei ole saavutada täiuslikkust 30 päevaga. Eesmärk on nähtavus, vastutus ja tõendusmaterjal.

1. nädal: tuvasta ja määra kohaldamisala

• Loetle kõik identiteedipakkujad, VPN-id, pilvekonsoolid, SaaS-platvormid ja privilegeeritud juurdepääsu tööriistad.
• Tuvasta süsteemid, kus on isikuandmeid, finantsandmeid, tootmiskeskkonnale juurdepääs või teenust mõjutavad funktsioonid.
• Ekspordi praegused MFA-meetodid ja erandid.
• Tuvasta välised ja tarnijakontod.
• Lisa MFA-väsimus ja push-teavituste pommitamine riskiregistrisse.
• Määra riskiomanik ja käsitluse omanik.

2. nädal: tugevda autentimist

• Keela pärandautentimine.
• Nõua administraatorite puhul andmepüügikindlat MFA-d, kui see on teostatav.
• Luba push-MFA jaoks numbrivastavus ja rakenduse kontekst.
• Rakenda tingimuslik juurdepääs asukoha, seadme vastavuse ja võimatu liikumise jaoks.
• Piira korduvaid push-viipasid.
• Nõua kõrge riskiga toimingute puhul uuesti autentimist.
• Muuda teenusekontod võimaluse korral mitteinteraktiivseks.
• Dokumenteeri erandid koos aegumiskuupäeva ja kompenseerivate kontrollimeetmetega.

3. nädal: seira ja harjuta läbi

• Veendu, et autentimislogid hõlmavad õnnestumisi, tõrkeid, seansi kestust ja MFA kasutust.
• Loo teavitusreeglid korduvate viipade, kinnitusele järgnevate keeldutud viipade, uue seadme registreerimise ja ebatavalise asukoha jaoks.
• Testi teavitusi kontrollitud simulatsiooniga.
• Valideeri intsidendipileti loomine ja eskaleerimine.
• Koolita kasutajaid lühikese „ootamatu MFA viiba“ harjutusega.
• Uuenda kasutajatoe skripte, et vältida sotsiaalset manipulatsiooni paroolide lähtestamisel ja MFA uuesti registreerimisel.

4. nädal: tõendusmaterjal ja juhtkonna läbivaatus

• Salvesta konfiguratsiooni väljavõtted ja kuvatõmmised.
• Registreeri juurdepääsuõiguste läbivaatamise tulemused.
• Seo koolituse läbimine privilegeeritud kasutajatega.
• Vaata läbi intsidendid ja peaaegu juhtumid.
• Uuenda kohaldatavusavaldust ja käsitlusplaani.
• Esita juhtkonnale jääkrisk ja mõõdikud.
• Ajasta siseauditi valimipõhine kontroll.

Muuda MFA-väsimus auditeeritavaks enne, kui sellest saab teatamiskohustuslik sündmus

MFA-väsimus tuletab meelde, et turbekontrollid ebaõnnestuvad kokkupuutepunktides: identiteedi ja seire vahel, poliitika ja koolituse vahel, tarnijate ja sisemise juurdepääsu vahel ning intsidentidele reageerimise ja privaatsusaruandluse vahel.

Organisatsioonid, kes juhivad seda hästi, ei „lülita MFA-d lihtsalt sisse“. Nad juhivad autentimist elutsüklina, seiravad seda ohusignaalina, koolitavad kasutajaid kontrollimeetme osana ja säilitavad tõendusmaterjali ISMS-i osana.

Clarysec ühendab kolm vara:

• Zenith Blueprint: audiitori 30 sammu teekaart, eriti samm 19 turvalise autentimise, samm 22 autentimisteabe ja samm 16 personalipõhise intsidentidest teatamise kohta.
• Claryseci poliitikamallid, sealhulgas P38 turvalise side ja mitmefaktorilise autentimise (MFA) poliitika, P22S logimis- ja seirepoliitika - VKE, P11S kasutajakontode ja õiguste haldamise poliitika - VKE, Infoturbe teadlikkuse ja koolituse poliitika - VKE, PII turbe ja juurdepääsukontrolli poliitika ning PII intsidentide ja rikkumiste haldamise poliitika.
• Zenith Controls: raamistikeülese nõuetelevastavuse juhend, mis vastendab ISO/IEC 27002:2022 kontrollimeetmed 5.17, 8.5, 8.15 ja 8.16 toetavate kontrollimeetmete, ISO auditi ootuste, GDPR, NIS2, DORA, NIST ja COBIT-iga.

Kui oled infoturbejuht, vastavusjuht, audiitor või ettevõtte omanik, tee ühenädalane MFA-väsimuse tõendusmaterjali ülevaatus. Võta välja MFA konfiguratsioon, autentimislogid, privilegeeritud juurdepääsu loend, tarnijate juurdepääsu loend, intsidendi tööjuhis, koolitusmaterjal ja erandiregister. Kui need artefaktid ei räägi üht sidusat lugu, saab Clarysec aidata sul kontrollipaketi üles ehitada enne, kui ründaja, audiitor või regulaator seda küsib.

Tutvu Zenith Blueprintiga, vaata läbi Zenith Controls või lepi kokku Claryseci avastuskõne, et muuta MFA-väsimus juhatuse tasandi üllatusest kaitstavaks ja auditeeritavaks autentimisprogrammiks.