Obvladovanje utrujenosti zaradi MFA in napadov z zasipanjem s potisnimi pozivi

Potisno obvestilo ob 2:13, ki je postalo vprašanje za upravni odbor

Ob 2:13 višja finančna administratorka prejme mobilno obvestilo: »Odobri prijavo?« Napol spi, domneva, da gre za potek seje v finančni platformi v oblaku, in tapne odobritev.

Ob 2:19 je napadalec že znotraj ponudnika identitet. Ob 2:31 poskuša dostopati do izvoza obračuna plač, privilegirane konzole v oblaku in skupnega poštnega predala, ki se uporablja za plačila dobaviteljem. Ob 3:05 SOC zazna ponavljajoče se pozive MFA, neobičajno geografsko lokacijo, uspešno odobritev in novo sejo iz neupravljane naprave.

Jutranji pogovor je znan:

• »Saj smo imeli MFA.«
• »Zakaj je uporabnica to odobrila?«
• »Ali smo zabeležili podrobnosti izziva MFA?«
• »Ali je to kršitev varnosti osebnih podatkov?«
• »Ali imamo 24-urne ali 72-urne obveznosti poročanja?«
• »Ali bo naš presojevalec ISO 27001:2022 to obravnaval kot odpoved kontrole?«
• »Ali to vpliva na NIS2, DORA, GDPR, pogodbe s strankami ali kibernetsko zavarovanje?«

To je vrzel v upravljanju, ki stoji za utrujenostjo zaradi MFA in zasipanjem s potisnimi pozivi. Napadalci ne razbijajo kriptografije. Izčrpavajo človeško odločanje, izkoriščajo šibko zasnovo avtentikacije in iščejo izjeme brez spremljanja. Odpoved kontrole je redko v tem, da »MFA ni omogočena«. Običajno gre za verigo šibkega zagotavljanja identitete, tvegane zasnove potisnih odobritev, manjkajočega ujemanja številk, nejasnih pravil privilegiranega dostopa, nezadostnega beleženja avtentikacije, slabe triaže opozoril, premalo usposobljenih uporabnikov in odsotnosti dokumentiranih dokazil, da je organizacija slabost pregledala in odpravila.

Za CISO, vodje skladnosti, presojevalce in lastnike podjetij je treba utrujenost zaradi MFA obravnavati kot vprašanje dokazil v ISMS, ne zgolj kot nastavitev ponudnika identitet. Odgovor združuje obravnavo tveganj po ISO 27001:2022, kontrole ISO/IEC 27002:2022, obveznosti iz politik, ozaveščanje uporabnikov, odziv na incidente, upravljanje dobaviteljev in preslikave med okviri za NIS2, DORA, GDPR, NIST CSF 2.0 in COBIT 2019.

Utrujenost zaradi MFA je odpoved zagotavljanja identitete, ne uporabniška težava

Utrujenost zaradi MFA, imenovana tudi zasipanje s potisnimi pozivi ali zasipanje s pozivi, nastane, ko napadalec z veljavnim geslom ponavljajoče sproža zahteve za odobritev MFA, dokler uporabnik ene ne sprejme. Včasih napadalec doda socialni inženiring, na primer lažen klic službe za pomoč uporabnikom, sporočilo z navedbo »testiramo vaš račun« ali zahtevo, naj uporabnik odobri prijavo, da se obvestila ustavijo.

Operativna nevarnost je v tem, da organizacije pogosto obravnavajo vse oblike MFA kot enakovredne. Niso.

Preprosto potisno obvestilo »odobri ali zavrni« je šibkejše od ujemanja številk, varnostnih ključev FIDO2, odpornih proti lažnemu predstavljanju, avtentikacije na podlagi digitalnih potrdil ali pogojnega dostopa, ki blokira nemogoče potovanje in neupravljane naprave. MFA odpove tudi takrat, ko izjeme za obhod niso dokumentirane, ko so storitveni računi interaktivni, ko ostajajo odprti zastareli protokoli ali ko visoko tvegani dostop ne zahteva močnejše avtentikacije.

V Zenith Blueprint: 30-koračni načrt za presojevalce Clarysec umešča varno avtentikacijo v fazo Kontrole v praksi, korak 19: tehnološke kontrole I. Usmeritev je neposredna:

Avtentikacija je prva in najpomembnejša obrambna linija med akterjem grožnje ter vašimi sistemi, podatki in storitvami. Če je avtentikacija šibka, je mogoče obiti vse drugo: šifriranje, spremljanje in segmentacijo.

Isti Zenith Blueprint obravnava tudi kontrolo ISO/IEC 27002:2022 5.17 v koraku 22:

Če je identiteta vprašanje »Kdo ste?«, je avtentikacija dokaz. Kontrola 5.17 je točka, kjer se teorija sreča z zaupanjem. Zahteva, da se informacije za avtentikacijo varno upravljajo skozi njihov celotni življenjski cikel, s čimer se zagotovi, da metode in poverilnice za preverjanje identitete same ne postanejo najšibkejši člen.

Ti dve izjavi pojasnjujeta, zakaj zasipanje s potisnimi pozivi sodi v register tveganj. Šifriranje ne pomaga, če napadalec postane odobren uporabnik. Segmentacija omrežja pomaga manj, če je privilegiran dostop do oblaka odobren prek poziva, ki ga uporabnik potrdi zaradi utrujenosti. Spremljanje deluje le, če so dogodki avtentikacije zabeleženi dovolj podrobno in pravočasno pregledani.

Zrela izjava o tveganju mora biti izrecna:

Tu postane pomemben ISO 27001:2022. Standard zahteva razumevanje konteksta, zainteresiranih strani, voditeljstvo, oceno tveganja, načrtovanje obravnave tveganja, operativno kontrolo, spremljanje, notranjo revizijo, vodstveni pregled in nenehno izboljševanje. Utrujenost zaradi MFA se dotika vseh teh področij.

Skupek kontrol ISO 27001:2022, ki ga bodo preverjali presojevalci

ISO 27001:2022 zagotavlja strukturo sistema upravljanja. ISO/IEC 27002:2022 zagotavlja smernice za implementacijo kontrol. Pri utrujenosti zaradi MFA in zasipanju s potisnimi pozivi se presojevalci običajno osredotočijo na skupek kontrol, ne na eno samo kontrolo.

Clarysecov Zenith Controls: vodnik za skladnost med okviri preslika kontrolo ISO/IEC 27002:2022 8.5 Varna avtentikacija na podporne kontrole, kot so 5.17 Informacije za avtentikacijo, 8.2 Pravice privilegiranega dostopa, 8.16 Dejavnosti spremljanja, 5.24 Načrtovanje in priprava upravljanja incidentov informacijske varnosti ter 5.34 Zasebnost in varstvo PII. Ta povezava med kontrolami je pomembna, ker posnetek zaslona z navedbo »MFA omogočena« ne zadostuje. Presojevalci želijo dokaz, da je avtentikacija zasnovana, spremljana, pregledovana in izboljševana na podlagi tveganj.

Zagovorljiv paket dokazil mora vključevati:

1. Oceno tveganja, ki opredeljuje zasipanje s potisnimi pozivi in socialni inženiring pozivov MFA.
2. Standard avtentikacije, ki določa sprejemljive metode MFA glede na kritičnost sistema.
3. Politiko privilegiranega dostopa, ki zahteva močnejšo avtentikacijo za administratorski in oddaljeni dostop.
4. Izvoz konfiguracije ponudnika identitet, ki prikazuje ujemanje številk, omejitve pozivov, pogojni dostop in blokirano zastarelo avtentikacijo.
5. Dnevnike, ki prikazujejo uspešne in neuspešne dogodke MFA, zavrnjene pozive, nemogoče potovanje ter kontekst naprave.
6. Pravila opozarjanja za ponavljajoče se pozive MFA, ponavljajoče se napake in neobičajno uspešno odobritev.
7. Zapise odziva na incidente za opozorila, povezana z avtentikacijo.
8. Vsebino usposabljanja za ozaveščanje, ki uporabnikom nalaga, naj ne odobrijo nepričakovanih pozivov.
9. Zapise pregledov pravic dostopa za privilegirane sisteme in sisteme z velikim vplivom.
10. Register izjem z datumi poteka, odobritvami lastnikov tveganj in kompenzacijskimi kontrolami.

Politika pretvori »ne odobrite nepričakovanih pozivov« v dokazila

Številne organizacije uporabnikom sporočijo, naj ne odobravajo sumljivih pozivov. Ta nasvet je koristen, vendar ne zadostuje za certifikacijo ISO 27001:2022, nadzor po NIS2, odpornost po DORA, odgovornost po GDPR, skrbni pregled strank ali kibernetsko zavarovanje.

Prvo izhodišče politike je P38 Politika varnih komunikacij in večfaktorske avtentikacije (MFA). Neposredno obravnava človeški vidik:

Ozaveščenost uporabnikov: uporabniki morajo biti usposobljeni za razlikovanje med varnimi in nezavarovanimi komunikacijskimi kanali. Usposabljanje mora zajemati pravilno uporabo večfaktorske avtentikacije (MFA) (npr. neodobravanje nepričakovanih prijavnih pozivov) in prakse varnih komunikacij (npr. preverjanje povezav za videokonference in neobravnavanje zaupnih tem prek nezavarovanih povezav).

S tem se utrujenost zaradi MFA spremeni v obveznost usposabljanja, ne v iskanje krivde. CISO lahko pokaže, da je zasipanje s pozivi zajeto pri uvajanju, obnovitvenem usposabljanju, usposabljanju na podlagi vlog in seznanitvah privilegiranih uporabnikov.

Ista P38 Politika varnih komunikacij in večfaktorske avtentikacije (MFA) vzpostavlja tudi obveznost spremljanja:

Informacijska varnost mora stalno spremljati dnevnike avtentikacije zaradi morebitnih poskusov prijave z enim samim faktorjem ali anomalnih napak večfaktorske avtentikacije (MFA). Dnevnike sistemov za varne komunikacije je treba, kjer je to primerno, spremljati zaradi poskusov nepooblaščenega dostopa ali sprememb konfiguracije.

Za MSP P11S Politika upravljanja uporabniških računov in privilegijev – MSP določa praktično osnovo:

Večfaktorska avtentikacija (MFA) mora biti, kjer je tehnično izvedljivo, omogočena za administratorske račune ali občutljive sisteme.

Besedna zveza »kjer je tehnično izvedljivo« ne sme nikoli postati obvod. Če sistem ne podpira močne MFA, mora biti izjema evidentirana z lastnikom, datumom poteka, kompenzacijskimi kontrolami, spremljanjem in migracijskim načrtom. Večje organizacije lahko enako pričakovanje uskladijo s P11 Politika upravljanja uporabniških računov in privilegijev, nato pa preverijo, ali se politika in operativna realnost ujemata.

Dokazila o zaznavanju izhajajo iz P22S Politika beleženja in spremljanja – MSP, ki zahteva beleženje dogodkov avtentikacije:

Dnevniki avtentikacije: uspešni in neuspešni poskusi prijave, trajanje sej, uporaba MFA

Zahteva tudi takojšen pregled visoko tveganih signalov avtentikacije:

Takojšen pregled ob zaznavi opozoril visoke resnosti (npr. zlonamerna programska oprema, neuspešna večfaktorska avtentikacija (MFA), ponavljajoči se neuspešni poskusi prijave)

Ozaveščenost se mora razvijati skupaj z grožnjami. Politika ozaveščanja in usposabljanja za informacijsko varnost – MSP podpira ta krog:

Teme morajo vključevati nastajajoče grožnje (npr. lažno predstavljanje), ustrezne spremembe politik in notranje trende incidentov.

Ko SOC zazna poskuse utrujanja uporabnikov z MFA, se morajo ti obveščevalni podatki prenesti v uporabniška opozorila, skripte službe za pomoč uporabnikom, namizne vaje in posodobitve usposabljanja.

Upravljan paket kontrol za utrujenost zaradi MFA

Predpostavimo, da organizacija uporablja ponudnika identitet v oblaku, CRM SaaS, finančno platformo, VPN in ponudnika upravljanih varnostnih storitev. Cilj je obvladovati utrujenost zaradi MFA z uporabo Clarysecovega Zenith Blueprint, knjižnice politik in vodnika Zenith Controls za skladnost med okviri.

Začnite s korakom 19 v Zenith Blueprint, ki ekipam nalaga opredelitev zahtev za avtentikacijo po sistemih in opozarja, da se je treba izogibati avtentikaciji samo z geslom za administratorske račune, konzole v oblaku, orodja za oddaljeni dostop in sisteme, izpostavljene internetu. Nato uporabite praktično pregledno dejavnost:

Preglejte uvedbo MFA: opredelite vrzeli in pripravite načrt za njihovo zaprtje. Preverite, da so storitveni računi neinteraktivni, kjer je to mogoče, da imajo močne poverilnice in da so dokumentirani. Potrdite, da na nobenem sistemu ali aplikaciji niso ostale privzete poverilnice.

To usmeritev pretvorite v operativni paket kontrol.

Korak 1: razvrstite sisteme glede na tveganje avtentikacije

Korak 2: odstranite visoko tvegano vedenje potisnih odobritev

Za administratorske račune in račune z velikim vplivom onemogočite osnovno potisno odobritev. Kjer je mogoče, uporabite avtentikatorje, odporne proti lažnemu predstavljanju. Kjer potisni pozivi ostanejo, uveljavite ujemanje številk, kontekst aplikacije, geografski kontekst, vezavo naprave in omejevanje pogostosti pozivov. Blokirajte zastarelo avtentikacijo in zahtevajte ponovno avtentikacijo za tvegane seje.

Korak 3: določite pravila opozarjanja za utrujenost zaradi MFA

Praktično pravilo SIEM se mora sprožiti, ko se v kratkem časovnem oknu pojavi eden ali več naslednjih vzorcev:

• Trije ali več potisnih pozivov MFA za enega uporabnika.
• Dva zavrnjena poziva, ki jima sledi en odobren poziv.
• Odobritev MFA iz nove geografske lokacije ali neupravljane naprave.
• Poziv MFA po signalu napada z razprševanjem gesel ali polnjenjem poverilnic.
• Odobritev MFA za privilegirani dostop zunaj običajnega delovnega časa.
• Nova registracija avtentikatorja kmalu po neuspešnih poskusih prijave.

Opozorilo mora ustvariti zahtevek za incident, obvestiti SOC ali vodjo varnosti in zahtevati ukrepe zajezitve: začasno zaustavitev seje, preklic žetonov za osvežitev, zahtevo za ponastavitev gesla, preverjanje naprave, razgovor z uporabnikom, pregled dostopa med sejo in razvrstitev, ali je prišlo do vpliva na osebne podatke ali kritično storitev.

Korak 4: povežite evidence zasebnosti in incidentov

Če lahko račun dostopa do osebnih podatkov, uporabite Politiko varnosti PII in nadzora dostopa. Ta zahteva močno avtentikacijo pred dostopom do PII z velikim vplivom:

[Oboje] Vodja informacijske varnosti MORA zahtevati močno avtentikacijo za privilegiran, oddaljen, administratorski dostop ali dostop do PII z velikim vplivom, preden je tak dostop omogočen, in zahtevo evidentirati v REG12.

Zahteva tudi opredelitev obsega beleženja:

[Oboje] Lastnik sistema / lastnik aplikacije MORA opredeliti obseg beleženja PII za dogodke avtentikacije, dogodke dostopa, privilegirana dejanja, dejavnosti izvoza PII in bistvene spremembe konfiguracije v REG12 pred produkcijsko uporabo ali bistveno spremembo.

Ko spremljanje kaže na nepooblaščen dostop do PII, nastane obveznost zapisa incidenta:

[Pogojno] Ko spremljanje kaže na sum nepooblaščenega dostopa do PII, sum razkritja PII, sum spremembe PII ali sum izgube razpoložljivosti PII, MORA koordinator odzivanja na incidente v enem delovnem dnevu odpreti ali povezati zapis REG10.

Eskalacijo zasebnosti zaključi Politika incidentov in kršitev varnosti PII:

[Pogojno] Vodja zasebnosti / vodja PIMS MORA za vsak incident v zvezi z osebno določljivimi podatki z velikim vplivom oceniti veljavne pravne, sektorske, finančno-sektorske, kibernetskovarnostne, pogodbene, naročniške in storitveno-prejemniške sprožitvene pogoje za poročanje ter rezultat uporabljivosti evidentirati v REG01, REG08 in REG10.

Tako se opozorilo MFA pretvori v dokazila, pripravljena za revizijo, na področjih varnosti, zasebnosti in skladnosti.

NIS2, DORA in GDPR: en incident, različna vprašanja

Utrujenost zaradi MFA je uporaben stresni test skladnosti med okviri, ker se dotika upravljanja, kibernetske higiene, nadzora dostopa, zaznavanja incidentov, dostopa dobaviteljev in poročanja o kršitvah.

NIS2: odgovornost vodstva in kibernetska higiena

NIS2 se uporablja za številne bistvene in pomembne subjekte, odvisno od sektorja, velikosti in določitve v državi članici. Article 20 nalaga odgovornost upravljalnim organom, da odobrijo ukrepe za obvladovanje kibernetskih tveganj, nadzirajo njihovo izvajanje in se usposabljajo. Article 21 zahteva ustrezne tehnične, operativne in organizacijske ukrepe, vključno z obravnavanjem incidentov, kibernetsko higieno, varnostjo dobavne verige, nadzorom dostopa, upravljanjem sredstev, usposabljanjem ter večfaktorsko ali neprekinjeno avtentikacijo, kjer je to primerno. Article 23 uvaja postopne obveznosti poročanja o pomembnih incidentih, vključno z zgodnjim opozorilom v 24 urah od seznanitve in obvestilom o incidentu v 72 urah.

Incident zasipanja s potisnimi pozivi zato postane vprašanje za upravni odbor: ali je bila MFA varno zasnovana ali zgolj omogočena?

DORA: avtentikacija kot digitalna operativna odpornost

Za zajete finančne subjekte se DORA uporablja od 17. januarja 2025. Pričakuje upravljanje tveganj IKT, zaznavanje, odziv, obnovitev, poročanje o incidentih, testiranje digitalne operativne odpornosti in upravljanje tveganj tretjih ponudnikov storitev IKT.

DORA Article 9 obravnava zaščito in preprečevanje, vključno z nadzorom dostopa in ukrepi avtentikacije. Article 10 obravnava zaznavanje anomalne dejavnosti. Article 17 zahteva proces upravljanja incidentov, povezanih z IKT. V kontekstu DORA morajo dokazila o utrujenosti zaradi MFA pokazati, da so bila prizadeta sredstva IKT identificirana, da je spremljanje zaznalo anomalno vedenje, da je bil incident razvrščen po merilih vpliva, da je bila zadeva po potrebi eskalirana višjemu vodstvu in da so bile pridobljene izkušnje vključene nazaj v okvir upravljanja IKT-tveganj.

GDPR: varnost obdelave in odgovornost

GDPR Article 5(1)(f) zahteva celovitost in zaupnost. Article 5(2) zahteva odgovornost. Article 32 zahteva varnost, ustrezno tveganju. Article 4 opredeljuje kršitev varnosti osebnih podatkov kot kršitev varnosti, ki povzroči nenamerno ali nezakonito uničenje, izgubo, spremembo, nepooblaščeno razkritje osebnih podatkov ali dostop do njih.

Če incident utrujenosti zaradi MFA zadeva osebne podatke, je vprašanje dokazil preprosto: ali lahko organizacija dokaže ustrezne avtentikacijske kontrole, spremljanje, odziv na incidente in oceno kršitve?

Preslikava za ISO, NIST CSF 2.0, COBIT 2019 in revizijska dokazila

NIST CSF 2.0 je koristen, ker upravljanje MFA prevede v izide GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND in RECOVER.

COBIT 2019 dodaja jasnost upravljanja. Presojevalec, usmerjen v COBIT, lahko preveri DSS05.04 Upravljanje identitete in logičnega dostopa, DSS05 Upravljanje varnostnih storitev, APO13 Upravljana varnost in MEA03 Upravljanje skladnosti z zunanjimi zahtevami. Težišče ni dobavitelj MFA. Težišče je, ali avtentikacija podpira poslovne cilje, ali se pravice dostopa upravljajo, ali je spremljanje učinkovito in ali vodstvo prejema smiselna zagotovila.

Konsolidirana preslikava pomaga ekipam za skladnost preprečiti razdrobljene zahteve po dokazilih:

Kaj bodo zahtevali presojevalci in regulatorji

Močan program za utrujenost zaradi MFA mora prestati različne pristope presoje. Clarysecov vodnik Zenith Controls za skladnost med okviri prikazuje, kako se kontrole ISO/IEC 27002:2022 preverjajo po metodologijah ISO, NIST, COBIT in ISACA.

Šibek program pravi: »Vprašali smo uporabnika in ponastavili geslo.« Upravljan program ustvari opozorilo SIEM, zahtevek za incident, zapis preklica seje, dokazilo o ponastavitvi gesla, pregled faktorjev MFA, analizo dnevnikov dostopa, oceno PII, vrednotenje sprožitvenih pogojev za poročanje, izjavo o temeljnem vzroku, korektivne ukrepe in vhodne informacije za vodstveni pregled.

30-dnevni akcijski načrt za obvladovanje utrujenosti zaradi MFA

Cilj ni popolnost v 30 dneh. Cilj so vidnost, lastništvo in dokazila.

1. teden: identificirajte in določite obseg

• Navedite vse ponudnike identitet, VPN, konzole v oblaku, platforme SaaS in orodja za privilegirani dostop.
• Identificirajte sisteme z osebnimi podatki, finančnimi podatki, dostopom do produkcije ali funkcijami, ki vplivajo na storitve.
• Izvozite trenutne metode MFA in izjeme.
• Identificirajte zunanje račune in račune dobaviteljev.
• Dodajte utrujenost zaradi MFA in zasipanje s potisnimi pozivi v register tveganj.
• Dodelite lastnika tveganja in lastnika obravnave tveganja.

2. teden: utrdite avtentikacijo

• Onemogočite zastarelo avtentikacijo.
• Zahtevajte MFA, odporno proti lažnemu predstavljanju, za administratorje, kjer je izvedljivo.
• Omogočite ujemanje številk in kontekst aplikacije za potisno MFA.
• Uporabite pogojni dostop za lokacijo, skladnost naprave in nemogoče potovanje.
• Omejite ponavljajoče se potisne pozive.
• Zahtevajte ponovno avtentikacijo za visoko tvegana dejanja.
• Storitvene račune naredite neinteraktivne, kjer je mogoče.
• Dokumentirajte izjeme z rokom poteka in kompenzacijskimi kontrolami.

3. teden: spremljajte in vadite

• Zagotovite, da dnevniki avtentikacije zajemajo uspeh, neuspeh, trajanje seje in uporabo MFA.
• Ustvarite pravila opozarjanja za ponavljajoče se pozive, zavrnjene pozive, ki jim sledi odobritev, registracijo nove naprave in neobičajno lokacijo.
• Preizkusite opozorila z nadzorovano simulacijo.
• Preverite ustvarjanje zahtevkov za incidente in eskalacijo.
• Usposobite uporabnike s kratko vajo »nepričakovan poziv MFA«.
• Posodobite skripte službe za pomoč uporabnikom, da preprečite socialni inženiring pri ponastavitvah gesel in ponovni vključitvi v MFA.

4. teden: dokazila in vodstveni pregled

• Shranite izvoze konfiguracije in posnetke zaslona.
• Zabeležite rezultate pregledov pravic dostopa.
• Povežite dokončanje usposabljanja s privilegiranimi uporabniki.
• Preglejte incidente in skorajšnje incidente.
• Posodobite izjavo o uporabnosti in načrt obravnave tveganja.
• Predstavite preostalo tveganje in metrike vodstvu.
• Načrtujte vzorčenje v notranji reviziji.

Poskrbite, da bo utrujenost zaradi MFA preverljiva, preden postane predmet poročanja

Utrujenost zaradi MFA opozarja, da varnostne kontrole odpovedujejo na stikih: med identiteto in spremljanjem, med politiko in usposabljanjem, med dobavitelji in notranjim dostopom, med odzivom na incidente in poročanjem o zasebnosti.

Organizacije, ki to dobro upravljajo, MFA ne zgolj »vklopijo«. Avtentikacijo upravljajo kot življenjski cikel, jo spremljajo kot signal grožnje, uporabnike usposabljajo kot del kontrole in dokazila ohranjajo kot del ISMS.

Clarysec povezuje tri sklope sredstev:

• Zenith Blueprint: 30-koračni načrt za presojevalce, zlasti korak 19 za varno avtentikacijo, korak 22 za informacije za avtentikacijo in korak 16 za poročanje o incidentih, ki ga sproži osebje.
• Predloge politik Clarysec, vključno z P38 Politika varnih komunikacij in večfaktorske avtentikacije (MFA), P22S Politika beleženja in spremljanja – MSP, P11S Politika upravljanja uporabniških računov in privilegijev – MSP, Politika ozaveščanja in usposabljanja za informacijsko varnost – MSP, Politika varnosti PII in nadzora dostopa ter Politika incidentov in kršitev varnosti PII.
• Zenith Controls: vodnik za skladnost med okviri, ki preslika kontrole ISO/IEC 27002:2022 5.17, 8.5, 8.15 in 8.16 na podporne kontrole, pričakovanja presoje ISO, GDPR, NIS2, DORA, NIST in COBIT.

Če ste CISO, vodja skladnosti, presojevalec ali lastnik podjetja, izvedite enotedenski pregled dokazil o utrujenosti zaradi MFA. Pridobite konfiguracijo MFA, dnevnike avtentikacije, seznam privilegiranega dostopa, seznam dostopa dobaviteljev, odzivni priročnik za incidente, gradivo za usposabljanje in register izjem. Če ti artefakti ne povedo ene skladne zgodbe, vam lahko Clarysec pomaga zgraditi paket kontrol, preden ga zahteva napadalec, presojevalec ali regulator.

Raziščite Zenith Blueprint, preglejte Zenith Controls ali se dogovorite za uvodni pogovor s Clarysec, da utrujenost zaradi MFA iz presenečenja za upravni odbor pretvorite v zagovorljiv in preverljiv program avtentikacije.