MFA-fárasztás és push bombing támadások irányítása

A hajnali 2:13-as push értesítés, amely igazgatósági kérdéssé vált

Hajnali 2:13-kor egy vezető pénzügyi rendszergazda mobilértesítést kap: „Jóváhagyja a bejelentkezést?” Félálomban van, azt feltételezi, hogy egy felhőalapú pénzügyi platform időtúllépéséről van szó, és jóváhagyja.

2:19-re a támadó már az identitásszolgáltatón belül van. 2:31-kor megpróbál hozzáférni egy bérszámfejtési exporthoz, egy kiemelt jogosultságú felhőkonzolhoz és a beszállítói kifizetésekhez használt megosztott postaládához. 3:05-kor a SOC ismétlődő MFA-promptokat, szokatlan földrajzi helyet, sikeres jóváhagyást és egy nem felügyelt eszközről indított új munkamenetet észlel.

A reggeli beszélgetés ismerős:

• „De volt MFA-nk.”
• „Miért hagyta jóvá a felhasználó?”
• „Naplóztuk az MFA-kihívás részleteit?”
• „Ez személyesadat-sértés?”
• „Van 24 vagy 72 órás jelentéstételi kötelezettségünk?”
• „Az ISO 27001:2022 auditorunk ezt kontrollhibának fogja tekinteni?”
• „Érinti ez a NIS2, a DORA, a GDPR, az ügyfélszerződések vagy a kiberbiztosítás követelményeit?”

Ez az MFA-fárasztás és a push bombing mögötti irányítási hiányosság. A támadók nem a kriptográfiát törik fel. Kimerítik az emberi döntéshozatalt, kihasználják a gyenge hitelesítési kialakítást, és felügyelet nélkül hagyott kivételeket keresnek. A kontrollhiba ritkán az, hogy „nincs bekapcsolva az MFA”. Többnyire olyan láncolatról van szó, amely gyenge identitásbizonyosságból, kockázatos push-jóváhagyási kialakításból, hiányzó számegyeztetésből, nem egyértelmű kiemelt jogosultságú hozzáférési szabályokból, elégtelen hitelesítési naplózásból, gyenge riasztáskezelésből, alulképzett felhasználókból és annak dokumentált bizonyítékhiányából áll, hogy a szervezet felülvizsgálta és kijavította a gyengeséget.

A CISO-k, megfelelési vezetők, auditorok és üzleti felelősök számára az MFA-fárasztást IBIR-bizonyítékkezelési problémaként kell kezelni, nem pusztán identitásszolgáltatói beállításként. A válasz az ISO 27001:2022 szerinti kockázatkezelést, az ISO/IEC 27002:2022 kontrollokat, szabályzati kötelezettségeket, felhasználói tudatosságot, incidensreagálást, beszállítói irányítást, valamint a NIS2, DORA, GDPR, NIST CSF 2.0 és COBIT 2019 közötti keretrendszer-megfeleltetéseket ötvözi.

Az MFA-fárasztás hitelesítési bizonyossági hiba, nem felhasználói probléma

Az MFA-fárasztás, más néven push bombing vagy prompt bombing, akkor következik be, amikor egy érvényes jelszóval rendelkező támadó ismételten MFA-jóváhagyási kérelmeket indít, amíg a felhasználó egyet el nem fogad. A támadó ezt időnként szociális manipulációval egészíti ki, például hamis helpdesk-hívással, „teszteljük a fiókját” tartalmú üzenettel, vagy azzal a kéréssel, hogy a felhasználó hagyja jóvá a bejelentkezést az értesítések leállítása érdekében.

A működési kockázat abból ered, hogy a szervezetek gyakran minden MFA-t egyenértékűnek tekintenek. Ez nem így van.

Az egyszerű „jóváhagyás vagy elutasítás” típusú push értesítés gyengébb, mint a számegyeztetés, az adathalászatnak ellenálló FIDO2 biztonsági kulcsok, a tanúsítványalapú hitelesítés vagy az olyan feltételes hozzáférés, amely blokkolja a lehetetlen utazást és a nem felügyelt eszközöket. Az MFA akkor is kudarcot vall, ha a megkerülési kivételek nincsenek dokumentálva, a szolgáltatásfiókok interaktívak, az örökölt protokollok nyitva maradnak, vagy a magas kockázatú hozzáférés nem igényel erősebb hitelesítést.

A Zenith Blueprint: 30 lépéses auditori ütemterv keretében a Clarysec a biztonságos hitelesítést a Controls in Action szakasz 19. lépésében, a Technological Controls I témakörben helyezi el. Az útmutatás egyértelmű:

A hitelesítés az első és legkritikusabb védelmi vonal a fenyegető szereplő és a rendszerek, adatok és szolgáltatások között. Ha a hitelesítés gyenge, minden más — a titkosítás, a felügyelet, a szegmentálás — megkerülhető.

Ugyanez a Zenith Blueprint a 22. lépésben az ISO/IEC 27002:2022 5.17 kontrollját is tárgyalja:

Ha az identitás kérdése az, hogy „Ki Ön?”, akkor a hitelesítés a bizonyíték. Az 5.17 kontroll az a pont, ahol az elmélet bizalommá válik. Megköveteli, hogy a hitelesítési információkat teljes életciklusuk alatt biztonságosan kezeljék, biztosítva, hogy az identitás ellenőrzésére használt módszerek és hitelesítő adatok maguk ne váljanak a leggyengébb láncszemmé.

Ez a két állítás magyarázza, miért kell a push bombingot szerepeltetni a kockázati nyilvántartásban. A titkosítás nem segít, ha a támadó jóváhagyott felhasználóvá válik. A hálózati szegmentálás kevésbé hatékony, ha a kiemelt jogosultságú felhőhozzáférést egy kifárasztott prompton keresztül jóváhagyják. A felügyelet csak akkor működik, ha a hitelesítési eseményeket kellő részletességgel naplózzák és gyorsan felülvizsgálják.

Egy érett kockázati állításnak egyértelműnek kell lennie:

Itt válik fontossá az ISO 27001:2022. A szabvány megköveteli a kontextus és az érdekelt felek meghatározását, a vezetői szerepvállalást, a kockázatértékelést, a kockázatkezelési tervezést, az operatív kontrollt, a nyomon követést, a belső auditot, a vezetőségi átvizsgálást és a folyamatos fejlesztést. Az MFA-fárasztás mindegyiket érinti.

Az ISO 27001:2022 kontrollcsoport, amelyet az auditorok tesztelni fognak

Az ISO 27001:2022 az irányítási rendszer szerkezetét adja meg. Az ISO/IEC 27002:2022 a kontrollok végrehajtásához ad útmutatást. MFA-fárasztás és push bombing esetén az auditorok jellemzően nem egyetlen kontrollra, hanem egy kontrollcsoportra fókuszálnak.

A Clarysec Zenith Controls: megfelelési keretrendszerek közötti útmutatója az ISO/IEC 27002:2022 8.5 Biztonságos hitelesítés kontrollját olyan támogató kontrollokhoz rendeli, mint az 5.17 Hitelesítési információk, a 8.2 Kiemelt jogosultságok, a 8.16 Felügyeleti tevékenységek, az 5.24 Információbiztonsági incidenskezelés tervezése és előkészítése, valamint az 5.34 Magánszféra és PII védelme. Ez az összekapcsolás azért fontos, mert az „MFA bekapcsolva” állapotot mutató képernyőkép nem elegendő. Az auditorok bizonyítékot várnak arra, hogy a hitelesítés kockázatalapon megtervezett, felügyelt, felülvizsgált és fejlesztett.

Egy igazolható bizonyítékcsomagnak tartalmaznia kell:

1. Kockázatértékelést, amely azonosítja a push bombingot és az MFA-promptok szociális manipulációját.
2. Hitelesítési szabványt, amely a rendszerkritikusság alapján meghatározza az elfogadható MFA-módszereket.
3. Kiemelt jogosultságú hozzáférési szabályzatot, amely erősebb hitelesítést ír elő az adminisztrátori és távoli hozzáféréshez.
4. Identitásszolgáltatói konfigurációexportot, amely igazolja a számegyeztetést, promptkorlátokat, feltételes hozzáférést és a blokkolt örökölt hitelesítést.
5. Naplókat a sikeres és sikertelen MFA-eseményekről, elutasított promptokról, lehetetlen utazásról és eszközkörnyezetről.
6. Riasztási szabályokat az ismétlődő MFA-promptokra, ismétlődő hibákra és szokatlan sikeres jóváhagyásra.
7. Incidensreagálási feljegyzéseket a hitelesítéssel kapcsolatos riasztásokról.
8. Tudatossági képzési tartalmat, amely előírja, hogy a felhasználók ne hagyjanak jóvá váratlan promptokat.
9. Hozzáférési felülvizsgálati feljegyzéseket a kiemelt jogosultságú és nagy hatású rendszerekről.
10. Kivételnyilvántartást lejárati dátumokkal, kockázatgazdai jóváhagyásokkal és kompenzáló kontrollokkal.

A szabályzat bizonyítékká alakítja a „ne hagyjon jóvá váratlan promptot” üzenetet

Sok szervezet azt mondja a felhasználóknak, hogy ne hagyjanak jóvá gyanús promptokat. Ez a tanács hasznos, de nem elegendő az ISO 27001:2022 tanúsításhoz, a NIS2 felügyelethez, a DORA szerinti rezilienciához, a GDPR elszámoltathatósághoz, az ügyfél-átvilágításhoz vagy a kiberbiztosításhoz.

Az első szabályzati horgony a P38 Biztonságos kommunikációs és többtényezős hitelesítési szabályzat. Közvetlenül kezeli az emberi oldalt:

Felhasználói tudatosság: A felhasználók képzésben részesülnek a biztonságos és nem biztonságos kommunikációs csatornák megkülönböztetésére. A képzésnek ki kell terjednie a többtényezős hitelesítés (MFA) megfelelő használatára (például a váratlan bejelentkezési promptok jóvá nem hagyására) és a biztonságos kommunikációs gyakorlatokra (például a videókonferencia-hivatkozások ellenőrzésére és arra, hogy bizalmas témákat ne tárgyaljanak nem biztonságos vonalakon).

Ez az MFA-fárasztást képzési kötelezettséggé alakítja, nem hibáztatási gyakorlattá. Lehetővé teszi a CISO számára annak bemutatását, hogy a prompt bombing szerepel a beléptetésben, az ismétlő képzésben, a szerepköralapú képzésben és a kiemelt jogosultságú felhasználói tájékoztatókban.

Ugyanez a P38 Biztonságos kommunikációs és többtényezős hitelesítési szabályzat felügyeleti kötelezettséget is létrehoz:

Az információbiztonsági funkciónak folyamatosan felügyelnie kell a hitelesítési naplókat az egytényezős bejelentkezési kísérletek és a rendellenes többtényezős hitelesítési (MFA) hibák észlelése érdekében. A biztonságos kommunikációs rendszerek naplóit — ahol alkalmazható — felügyelni kell a jogosulatlan hozzáférési kísérletek és konfigurációmódosítások szempontjából.

KKV-k számára a P11S Felhasználói fiók- és jogosultságkezelési szabályzat – KKV gyakorlati alapkövetelményt határoz meg:

A többtényezős hitelesítést (MFA) — ahol műszakilag megvalósítható — engedélyezni kell az adminisztrátori fiókoknál vagy az érzékeny rendszereknél.

Az „ahol műszakilag megvalósítható” kitétel nem válhat kiskapuvá. Ha egy rendszer nem támogatja az erős MFA-t, a kivételt rögzíteni kell felelőssel, lejárati dátummal, kompenzáló kontrollokkal, felügyelettel és migrációs tervvel. A nagyobb szervezetek ugyanezt az elvárást a P11 Felhasználói fiók- és jogosultságkezelési szabályzathoz igazíthatják, majd tesztelhetik, hogy a szabályzat és a működési valóság összhangban van-e.

Az észlelési bizonyíték a P22S Naplózási és felügyeleti szabályzat – KKV alapján keletkezik, amely előírja a hitelesítési események naplózását:

Hitelesítési naplók: sikeres és sikertelen bejelentkezési kísérletek, munkamenet-időtartam, MFA-használat

Előírja továbbá a magas kockázatú hitelesítési jelzések sürgős felülvizsgálatát:

Azonnali felülvizsgálat nagy súlyosságú riasztások észlelésekor (például malware, sikertelen többtényezős hitelesítés (MFA), ismétlődő bejelentkezési hibák)

A tudatosságnak a fenyegetések fejlődésével együtt kell fejlődnie. Az Információbiztonsági tudatossági és képzési szabályzat – KKV támogatja ezt a visszacsatolási kört:

A témáknak tartalmazniuk kell a kialakulóban lévő fenyegetéseket (például adathalászat), a releváns szabályzatmódosításokat és a belső incidenstrendeket.

Amikor a SOC MFA-fárasztási kísérleteket észlel, ezeknek az információknak felhasználói riasztásokba, helpdesk-szkriptekbe, asztali gyakorlatokba és képzési frissítésekbe kell beépülniük.

Irányított MFA-fárasztási kontrollcsomag

Tegyük fel, hogy a szervezet felhőalapú identitásszolgáltatót, SaaS CRM-et, pénzügyi platformot, VPN-t és menedzselt biztonsági szolgáltatót használ. A cél az MFA-fárasztás irányítása a Clarysec Zenith Blueprint, szabályzati könyvtár és Zenith Controls megfelelési keretrendszerek közötti útmutató alapján.

Kezdje a Zenith Blueprint 19. lépésével, amely előírja a csapatok számára a hitelesítési követelmények rendszerenkénti meghatározását, és figyelmeztet arra, hogy a kizárólag jelszóalapú hitelesítést kerülni kell az adminisztrátori fiókoknál, felhőkonzoloknál, távoli hozzáférési eszközöknél és internet felől elérhető rendszereknél. Ezt követően alkalmazza a gyakorlati felülvizsgálati tevékenységet:

Vizsgálja felül az MFA-bevezetést: azonosítsa a hiányosságokat, és tervezze meg azok lezárását. Ellenőrizze, hogy a szolgáltatásfiókok lehetőség szerint nem interaktívak, erős hitelesítő adatokkal rendelkeznek és dokumentáltak. Erősítse meg, hogy egyetlen rendszeren vagy alkalmazáson sem maradtak alapértelmezett hitelesítő adatok.

Alakítsa át ezt az útmutatást működési kontrollcsomaggá.

1. lépés: rendszerek besorolása hitelesítési kockázat szerint

2. lépés: magas kockázatú push működés megszüntetése

Az adminisztrátori és nagy hatású fiókoknál ki kell kapcsolni az alap push-jóváhagyást. Ahol lehetséges, adathalászatnak ellenálló hitelesítőket kell használni. Ahol a push megmarad, ki kell kényszeríteni a számegyeztetést, az alkalmazáskörnyezetet, a földrajzi kontextust, az eszközhöz kötést és a promptok gyakorisági korlátozását. Blokkolni kell az örökölt hitelesítést, és kockázatos munkameneteknél ismételt hitelesítést kell előírni.

3. lépés: riasztási szabályok meghatározása MFA-fárasztásra

Egy gyakorlati SIEM-szabálynak akkor kell aktiválódnia, ha rövid időablakon belül az alábbi minták közül egy vagy több megjelenik:

• Három vagy több MFA-push prompt egy felhasználónál.
• Két elutasított promptot egy jóváhagyott prompt követ.
• MFA-jóváhagyás új földrajzi helyről vagy nem felügyelt eszközről.
• MFA-prompt password spraying vagy credential stuffing típusú támadás jele után.
• MFA-jóváhagyás kiemelt jogosultságú hozzáféréshez a szokásos munkaidőn kívül.
• Új hitelesítő regisztrációja röviddel sikertelen bejelentkezési kísérletek után.

A riasztásnak incidensjegyet kell létrehoznia, értesítenie kell a SOC-ot vagy a biztonsági vezetőt, és elszigetelési lépéseket kell előírnia: munkamenet felfüggesztése, refresh tokenek visszavonása, jelszó-visszaállítás előírása, eszköz ellenőrzése, felhasználó megkérdezése, a munkamenet alatti hozzáférések felülvizsgálata, valamint annak besorolása, hogy történt-e személyes adatot vagy kritikus szolgáltatást érintő hatás.

4. lépés: adatvédelmi és incidensnyilvántartások összekapcsolása

Ha a fiók személyes adatokhoz férhet hozzá, alkalmazni kell a PII-biztonsági és hozzáférés-szabályozási szabályzatot. Ez erős hitelesítést ír elő a nagy hatású PII-hozzáférés előtt:

[Mindkét esetben] Az információbiztonsági vezető KÖTELES erős hitelesítést előírni a kiemelt jogosultságú, távoli, adminisztratív vagy nagy hatású PII-hozzáférés engedélyezése előtt, és a követelményt rögzíteni köteles a REG12-ben.

A szabályzat a naplózási hatókör meghatározását is előírja:

[Mindkét esetben] A rendszergazda / alkalmazástulajdonos KÖTELES meghatározni a PII-naplózás hatókörét a hitelesítési eseményekre, hozzáférési eseményekre, kiemelt jogosultságú műveletekre, PII-export tevékenységre és lényeges konfigurációmódosításokra vonatkozóan a REG12-ben, az éles használat vagy lényeges változás előtt.

Ha a felügyelet jogosulatlan PII-hozzáférés gyanúját jelzi, incidensbejegyzési kötelezettség keletkezik:

[Feltételesen] Az incidensreagálási koordinátor KÖTELES egy munkanapon belül REG10 bejegyzést megnyitni vagy meglévőhöz kapcsolni, ha a felügyelet jogosulatlan PII-hozzáférés, feltételezett PII-adatközlés, feltételezett PII-módosítás vagy feltételezett PII-rendelkezésreállás-vesztés gyanúját jelzi.

Az adatvédelmi eszkalációt a PII-incidens- és adatsértés-kezelési szabályzat zárja le:

[Feltételesen] Az adatvédelemért felelős vezető / PIMS-vezető KÖTELES minden nagy hatású PII-incidens esetében értékelni az alkalmazandó jogi, ágazati, pénzügyi szektorbeli, kiberbiztonsági, szerződéses, ügyfél- és szolgáltatás igénybe vevője szerinti jelentéstételi kiváltó eseményeket, és az alkalmazhatósági eredményt rögzíteni a REG01-ben, REG08-ban és REG10-ben.

Ez alakítja az MFA-riasztást auditálható bizonyítékká a biztonság, az adatvédelem és a megfelelés területén.

NIS2, DORA és GDPR: egy incidens, eltérő kérdések

Az MFA-fárasztás hasznos megfelelési keretrendszerek közötti stresszteszt, mert érinti az irányítást, a kiberhigiéniát, a hozzáférés-szabályozást, az incidensészlelést, a beszállítói hozzáférést és az adatsértési jelentéstételt.

NIS2: vezetői elszámoltathatóság és kiberhigiénia

A NIS2 számos alapvető és fontos szervezetre alkalmazandó, ágazattól, mérettől és tagállami kijelöléstől függően. Az Article 20 elszámoltathatóságot ró a vezető testületekre a kiberbiztonsági kockázatkezelési intézkedések jóváhagyása, végrehajtásuk felügyelete és képzésben való részvételük tekintetében. Az Article 21 megfelelő technikai, operatív és szervezeti intézkedéseket követel meg, beleértve az incidenskezelést, a kiberhigiéniát, az ellátási lánc biztonságát, a hozzáférés-szabályozást, az eszközkezelést, a képzést, valamint — ahol indokolt — a többtényezős vagy folyamatos hitelesítést. Az Article 23 szakaszos incidensbejelentési kötelezettségeket vezet be jelentős incidensekre, beleértve a tudomásszerzéstől számított 24 órán belüli korai figyelmeztetést és a 72 órán belüli incidensbejelentést.

Egy push bombing incidens ezért igazgatósági kérdéssé válik: az MFA biztonságosan volt megtervezve, vagy csak be volt kapcsolva?

DORA: a hitelesítés mint digitális működési reziliencia

Az érintett pénzügyi szervezetekre a DORA 2025. január 17-től alkalmazandó. IKT-kockázatkezelést, észlelést, reagálást, helyreállítást, incidensjelentést, digitális működési reziliencia tesztelését és IKT-harmadikfél-kockázatkezelést vár el.

A DORA Article 9 a védelmet és megelőzést tárgyalja, beleértve a hozzáférés-szabályozási és hitelesítési intézkedéseket. Az Article 10 a rendellenes tevékenység észlelésével foglalkozik. Az Article 17 IKT-vonatkozású incidenskezelési folyamatot követel meg. DORA-környezetben az MFA-fárasztási bizonyítéknak azt kell igazolnia, hogy az érintett IKT-vagyonelemeket azonosították, a felügyelet észlelte a rendellenes viselkedést, az incidenst hatáskritériumok alapján besorolták, a felső vezetés felé szükség szerint eszkalálták, és a tanulságokat visszavezették az IKT-kockázati keretrendszerbe.

GDPR: az adatkezelés biztonsága és elszámoltathatóság

A GDPR Article 5(1)(f) sértetlenséget és bizalmasságot követel meg. Az Article 5(2) elszámoltathatóságot ír elő. Az Article 32 a kockázatnak megfelelő biztonságot követel meg. Az Article 4 a személyesadat-sértést olyan biztonsági sérülésként határozza meg, amely a személyes adatok véletlen vagy jogellenes megsemmisítéséhez, elvesztéséhez, megváltoztatásához, jogosulatlan közléséhez vagy az azokhoz való jogosulatlan hozzáféréshez vezet.

Ha egy MFA-fárasztási incidens személyes adatokat érint, a bizonyítékkérdés egyszerű: képes-e a szervezet igazolni a megfelelő hitelesítési kontrollokat, felügyeletet, incidensreagálást és személyesadat-sértési értékelést?

ISO, NIST CSF 2.0, COBIT 2019 és auditbizonyítékok megfeleltetése

A NIST CSF 2.0 azért hasznos, mert az MFA-irányítást GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND és RECOVER eredményekre fordítja le.

A COBIT 2019 irányítási egyértelműséget ad. Egy COBIT-orientált auditor a DSS05.04 Manage identity and logical access, a DSS05 Manage security services, az APO13 Managed security és a MEA03 Managed compliance with external requirements területeket vizsgálhatja. A fókusz nem az MFA-szállító. A kérdés az, hogy a hitelesítés támogatja-e az üzleti célkitűzéseket, a hozzáférési jogosultságok irányítottak-e, a felügyelet hatékony-e, és a vezetés kap-e érdemi bizonyosságot.

Az egységes megfeleltetés segít a megfelelési csapatoknak elkerülni a széttöredezett bizonyítékkéréseket:

Mit fognak kérni az auditorok és a szabályozók?

Egy erős MFA-fárasztási programnak többféle auditmegközelítést is ki kell állnia. A Clarysec Zenith Controls megfelelési keretrendszerek közötti útmutatója bemutatja, hogyan tesztelik az ISO/IEC 27002:2022 kontrollokat ISO, NIST, COBIT és ISACA módszertanok szerint.

Egy gyenge program azt mondja: „Megkérdeztük a felhasználót és visszaállítottuk a jelszót.” Egy irányított program SIEM-riasztást, incidensjegyet, munkamenet-visszavonási feljegyzést, jelszó-visszaállítási bizonyítékot, MFA-faktor felülvizsgálatot, hozzáférési naplóelemzést, PII-értékelést, jelentéstételi kiváltó esemény értékelését, gyökérok-megállapítást, helyesbítő intézkedéseket és vezetőségi átvizsgálási bemenetet állít elő.

30 napos cselekvési terv az MFA-fárasztás irányításához

A cél nem a tökéletesség 30 nap alatt. A cél a láthatóság, a felelősség és a bizonyíték.

1. hét: azonosítás és hatókör-meghatározás

• Sorolja fel az összes identitásszolgáltatót, VPN-t, felhőkonzolt, SaaS-platformot és kiemelt jogosultságú hozzáférési eszközt.
• Azonosítsa a személyes adatokat, pénzügyi adatokat, éles rendszerhez való hozzáférést vagy szolgáltatáshatással járó funkciókat tartalmazó rendszereket.
• Exportálja az aktuális MFA-módszereket és kivételeket.
• Azonosítsa a külső és beszállítói fiókokat.
• Vegye fel az MFA-fárasztást és a push bombingot a kockázati nyilvántartásba.
• Jelöljön ki kockázatgazdát és kockázatkezelési felelőst.

2. hét: a hitelesítés megerősítése

• Tiltsa le az örökölt hitelesítést.
• Írjon elő adathalászatnak ellenálló MFA-t az adminisztrátoroknak, ahol ez megvalósítható.
• Kapcsolja be a számegyeztetést és az alkalmazáskörnyezet megjelenítését push MFA esetén.
• Alkalmazzon feltételes hozzáférést hely, eszközmegfelelőség és lehetetlen utazás alapján.
• Korlátozza az ismétlődő push promptokat.
• Írjon elő ismételt hitelesítést magas kockázatú műveletekhez.
• Tegye a szolgáltatásfiókokat lehetőség szerint nem interaktívvá.
• Dokumentálja a kivételeket lejárattal és kompenzáló kontrollokkal.

3. hét: felügyelet és gyakorlás

• Biztosítsa, hogy a hitelesítési naplók rögzítsék a sikert, a hibát, a munkamenet-időtartamot és az MFA-használatot.
• Hozzon létre riasztási szabályokat az ismétlődő promptokra, az elutasított promptokat követő jóváhagyásra, az új eszközregisztrációra és a szokatlan helyre.
• Tesztelje a riasztásokat kontrollált szimulációval.
• Ellenőrizze az incidensjegy létrehozását és az eszkalációt.
• Képezze a felhasználókat rövid „váratlan MFA-prompt” gyakorlattal.
• Frissítse a helpdesk-szkripteket, hogy megelőzzék a szociális manipulációt a jelszó-visszaállítások és az MFA-újraregisztráció során.

4. hét: bizonyítékok és vezetőségi átvizsgálás

• Tárolja a konfigurációexportokat és képernyőképeket.
• Rögzítse a hozzáférési felülvizsgálatok eredményeit.
• Kapcsolja össze a képzési teljesítést a kiemelt jogosultságú felhasználókkal.
• Vizsgálja felül az incidenseket és a majdnem bekövetkezett eseményeket.
• Frissítse az alkalmazhatósági nyilatkozatot és a kockázatkezelési tervet.
• Mutassa be a maradványkockázatot és a mutatókat a vezetésnek.
• Ütemezzen belső auditos mintavételt.

Tegye auditálhatóvá az MFA-fárasztást, mielőtt bejelentéskötelessé válik

Az MFA-fárasztás emlékeztet arra, hogy a biztonsági kontrollok az illesztési pontokon hibásodnak meg: az identitás és a felügyelet, a szabályzat és a képzés, a beszállítók és a belső hozzáférés, valamint az incidensreagálás és az adatvédelmi jelentéstétel között.

Azok a szervezetek, amelyek ezt jól kezelik, nem egyszerűen „bekapcsolják az MFA-t”. A hitelesítést életciklusként irányítják, fenyegetettségi jelként felügyelik, a felhasználókat a kontroll részeként képzik, és a bizonyítékokat az IBIR részeként őrzik meg.

A Clarysec három elemet kapcsol össze:

• A Zenith Blueprint: 30 lépéses auditori ütemterv, különösen a 19. lépés a biztonságos hitelesítéshez, a 22. lépés a hitelesítési információkhoz és a 16. lépés a személyzet által indított incidensbejelentéshez.
• Clarysec szabályzatsablonok, többek között a P38 Biztonságos kommunikációs és többtényezős hitelesítési szabályzat, a P22S Naplózási és felügyeleti szabályzat – KKV, a P11S Felhasználói fiók- és jogosultságkezelési szabályzat – KKV, az Információbiztonsági tudatossági és képzési szabályzat – KKV, a PII-biztonsági és hozzáférés-szabályozási szabályzat, valamint a PII-incidens- és adatsértés-kezelési szabályzat.
• A Zenith Controls: megfelelési keretrendszerek közötti útmutató, amely az ISO/IEC 27002:2022 5.17, 8.5, 8.15 és 8.16 kontrolljait támogató kontrollokhoz, ISO audit elvárásokhoz, valamint GDPR, NIS2, DORA, NIST és COBIT követelményekhez rendeli.

Ha Ön CISO, megfelelési vezető, auditor vagy üzleti felelős, végezzen egyhetes MFA-fárasztási bizonyítékfelülvizsgálatot. Gyűjtse össze az MFA-konfigurációt, a hitelesítési naplókat, a kiemelt jogosultságú hozzáférési listát, a beszállítói hozzáférési listát, az incidens-forgatókönyvet, a képzési anyagot és a kivételnyilvántartást. Ha ezek a bizonyítékok nem alkotnak egységes történetet, a Clarysec segíthet felépíteni a kontrollcsomagot, mielőtt egy támadó, auditor vagy szabályozó kéri azt.

Ismerje meg a Zenith Blueprint megközelítést, tekintse át a Zenith Controls útmutatót, vagy egyeztessen Clarysec feltáró hívást, hogy az MFA-fárasztás igazgatósági meglepetés helyett igazolható, auditálható hitelesítési programmá váljon.