Zarządzanie ryzykiem zmęczenia MFA i ataków typu push bombing

Powiadomienie push o 2:13, które stało się pytaniem dla zarządu

O 2:13 starsza administratorka finansowa otrzymuje powiadomienie mobilne: „Zatwierdzić logowanie?”. Jest na wpół śpiąca, zakłada, że to wygaśnięcie sesji w chmurowej platformie finansowej, i naciska zatwierdzenie.

O 2:19 atakujący jest już u dostawcy tożsamości. O 2:31 próbuje uzyskać dostęp do eksportu danych płacowych, uprzywilejowanej konsoli chmurowej oraz współdzielonej skrzynki pocztowej używanej do płatności na rzecz dostawców. O 3:05 SOC widzi powtarzające się monity MFA, nietypową lokalizację geograficzną, skuteczne zatwierdzenie i nową sesję z niezarządzanego urządzenia.

Poranna rozmowa brzmi znajomo:

• „Przecież mieliśmy MFA.”
• „Dlaczego użytkownik to zatwierdził?”
• „Czy zarejestrowaliśmy szczegóły wyzwania MFA?”
• „Czy to jest naruszenie ochrony danych osobowych?”
• „Czy mamy obowiązki zgłoszeniowe w terminie 24 albo 72 godzin?”
• „Czy nasz audytor ISO 27001:2022 potraktuje to jako nieskuteczność zabezpieczenia?”
• „Czy wpływa to na NIS2, DORA, GDPR, umowy z klientami albo ubezpieczenie cybernetyczne?”

To właśnie luka w nadzorze stojąca za zmęczeniem MFA i push bombing. Atakujący nie łamią kryptografii. Wyczerpują ludzką zdolność podejmowania decyzji, wykorzystują słaby projekt uwierzytelniania i szukają niemonitorowanych wyjątków. Nieskuteczność zabezpieczenia rzadko polega na tym, że „MFA nie było włączone”. Zwykle jest to łańcuch słabego zapewnienia tożsamości, ryzykownego mechanizmu zatwierdzania push, braku dopasowania numerów, niejasnych reguł dostępu uprzywilejowanego, niewystarczającego rejestrowania zdarzeń uwierzytelniania, słabej wstępnej kwalifikacji alertów, niedostatecznie przeszkolonych użytkowników oraz braku udokumentowanych dowodów, że organizacja przeanalizowała i usunęła tę słabość.

Dla CISO, menedżerów zgodności, audytorów i właścicieli biznesowych zmęczenie MFA musi być traktowane jako problem dowodowy SZBI, a nie wyłącznie jako ustawienie dostawcy tożsamości. Odpowiedź obejmuje postępowanie z ryzykiem ISO 27001:2022, zabezpieczenia ISO/IEC 27002:2022, obowiązki wynikające z polityk, świadomość użytkowników, reagowanie na incydenty, nadzór nad dostawcami oraz mapowania między ramami dla NIS2, DORA, GDPR, NIST CSF 2.0 i COBIT 2019.

Zmęczenie MFA to nieskuteczność zapewnienia, a nie problem użytkownika

Zmęczenie MFA, określane także jako push bombing albo bombardowanie monitami, występuje wtedy, gdy atakujący dysponujący prawidłowym hasłem wielokrotnie wyzwala żądania zatwierdzenia MFA, aż użytkownik zaakceptuje jedno z nich. Czasem atakujący dokłada inżynierię społeczną, na przykład fałszywy telefon z helpdesku, wiadomość typu „testujemy Twoje konto” albo prośbę o zatwierdzenie logowania w celu zatrzymania powiadomień.

Ryzyko operacyjne polega na tym, że organizacje często traktują wszystkie formy MFA jako równoważne. Tak nie jest.

Proste powiadomienie push „zatwierdź albo odrzuć” jest słabsze niż dopasowanie numerów, odporne na phishing klucze bezpieczeństwa FIDO2, uwierzytelnianie oparte na certyfikatach albo dostęp warunkowy blokujący niemożliwą podróż i niezarządzane urządzenia. MFA zawodzi również wtedy, gdy wyjątki umożliwiające obejście mechanizmu nie są udokumentowane, konta serwisowe pozostają interaktywne, przestarzałe protokoły są nadal dostępne albo dostęp wysokiego ryzyka nie wymaga silniejszego uwierzytelniania.

W Zenith Blueprint: 30-etapowa mapa drogowa audytora Clarysec ujmuje bezpieczne uwierzytelnianie w fazie „Zabezpieczenia w działaniu”, krok 19: zabezpieczenia techniczne I. Wytyczne są jednoznaczne:

Uwierzytelnianie jest pierwszą i najbardziej krytyczną linią obrony między sprawcą zagrożenia a Twoimi systemami, danymi i usługami. Jeżeli uwierzytelnianie jest słabe, wszystko inne — szyfrowanie, monitorowanie, segmentacja — może zostać ominięte.

Ten sam Zenith Blueprint odnosi się również do zabezpieczenia ISO/IEC 27002:2022 5.17 w kroku 22:

Jeżeli tożsamość odpowiada na pytanie „Kim jesteś?”, to uwierzytelnianie jest dowodem. Zabezpieczenie 5.17 jest miejscem, w którym teoria spotyka się z zaufaniem. Wymaga ono, aby informacje uwierzytelniające były bezpiecznie zarządzane przez cały cykl życia, zapewniając, że metody i dane uwierzytelniające używane do weryfikacji tożsamości same nie staną się najsłabszym ogniwem.

Te dwa stwierdzenia wyjaśniają, dlaczego push bombing powinien znaleźć się w rejestrze ryzyk. Szyfrowanie nie pomaga, jeżeli atakujący staje się zatwierdzonym użytkownikiem. Segmentacja sieci pomaga mniej, jeżeli uprzywilejowany dostęp do chmury jest zatwierdzany wskutek zmęczenia monitami. Monitorowanie działa tylko wtedy, gdy zdarzenia uwierzytelniania są rejestrowane z wystarczającą szczegółowością i szybko przeglądane.

Dojrzałe sformułowanie ryzyka powinno być jednoznaczne:

W tym miejscu znaczenie ma ISO 27001:2022. Norma wymaga określenia kontekstu, stron zainteresowanych, przywództwa, oceny ryzyka, planowania postępowania z ryzykiem, nadzoru operacyjnego, monitorowania, audytu wewnętrznego, przeglądu zarządzania i ciągłego doskonalenia. Zmęczenie MFA dotyka wszystkich tych obszarów.

Klaster zabezpieczeń ISO 27001:2022, który sprawdzą audytorzy

ISO 27001:2022 zapewnia strukturę systemu zarządzania. ISO/IEC 27002:2022 zapewnia wytyczne wdrożeniowe dla zabezpieczeń. W przypadku zmęczenia MFA i push bombing audytorzy zwykle skupiają się na klastrze zabezpieczeń, a nie na jednym zabezpieczeniu.

Zenith Controls: przewodnik po zgodności między ramami Clarysec mapuje zabezpieczenie ISO/IEC 27002:2022 8.5 Bezpieczne uwierzytelnianie na wspierające zabezpieczenia, takie jak 5.17 Informacje uwierzytelniające, 8.2 Prawa dostępu uprzywilejowanego, 8.16 Monitorowanie działań, 5.24 Planowanie i przygotowanie zarządzania incydentami bezpieczeństwa informacji oraz 5.34 Prywatność i ochrona PII. To powiązanie jest ważne, ponieważ zrzut ekranu pokazujący „MFA enabled” nie wystarcza. Audytorzy oczekują dowodu, że uwierzytelnianie jest projektowane, monitorowane, przeglądane i doskonalone na podstawie ryzyka.

Możliwy do obrony pakiet dowodów powinien obejmować:

1. Ocenę ryzyka identyfikującą push bombing oraz inżynierię społeczną dotyczącą monitów MFA.
2. Standard uwierzytelniania definiujący dopuszczalne metody MFA według krytyczności systemu.
3. Politykę dostępu uprzywilejowanego wymagającą silniejszego uwierzytelniania dla dostępu administracyjnego i zdalnego.
4. Eksport konfiguracji dostawcy tożsamości pokazujący dopasowanie numerów, limity monitów, dostęp warunkowy i zablokowane przestarzałe mechanizmy uwierzytelniania.
5. Logi pokazujące udane i nieudane zdarzenia MFA, odrzucone monity, niemożliwą podróż oraz kontekst urządzenia.
6. Reguły alertów dla powtarzających się monitów MFA, powtarzających się niepowodzeń i nietypowego skutecznego zatwierdzenia.
7. Zapisy reagowania na incydenty dotyczące alertów związanych z uwierzytelnianiem.
8. Treści szkoleń uświadamiających informujące użytkowników, aby nie zatwierdzali nieoczekiwanych monitów.
9. Zapisy przeglądów dostępu dla systemów uprzywilejowanych i o istotnym wpływie.
10. Rejestr wyjątków z datami wygaśnięcia, zatwierdzeniami właścicieli ryzyka i zabezpieczeniami kompensującymi.

Polityka zamienia „nie zatwierdzaj nieoczekiwanych monitów” w dowód

Wiele organizacji mówi użytkownikom, aby nie zatwierdzali podejrzanych monitów. Taka wskazówka jest użyteczna, ale nie wystarcza do certyfikacji ISO 27001:2022, nadzoru NIS2, odporności DORA, rozliczalności GDPR, due diligence klienta ani ubezpieczenia cybernetycznego.

Pierwszą kotwicą polityki jest P38 Secure Communications and Multi-Factor Authentication (MFA) Policy. Odnosi się ona bezpośrednio do czynnika ludzkiego:

Świadomość użytkowników: użytkownicy muszą otrzymać szkolenie pozwalające odróżniać bezpieczne kanały komunikacji od niebezpiecznych. Szkolenie musi obejmować prawidłowe korzystanie z uwierzytelniania wieloskładnikowego (MFA) (np. niezatwierdzanie nieoczekiwanych monitów logowania) oraz bezpieczne praktyki komunikacji (np. weryfikowanie linków do wideokonferencji i nieomawianie tematów poufnych przez niezabezpieczone linie).

To zmienia zmęczenie MFA w obowiązek szkoleniowy, a nie w mechanizm obwiniania. Pozwala CISO wykazać, że bombardowanie monitami jest uwzględnione we wdrożeniu pracowników, szkoleniu przypominającym, szkoleniu opartym na rolach oraz briefingach dla użytkowników uprzywilejowanych.

Ta sama P38 Secure Communications and Multi-Factor Authentication (MFA) Policy tworzy również obowiązek monitorowania:

Bezpieczeństwo informacji musi w sposób ciągły monitorować logi uwierzytelniania pod kątem wszelkich prób logowania jednoskładnikowego lub anomalnych niepowodzeń uwierzytelniania wieloskładnikowego (MFA). Logi z bezpiecznych systemów komunikacji, jeżeli mają zastosowanie, muszą być monitorowane pod kątem prób nieuprawnionego dostępu lub zmian konfiguracji.

Dla MŚP P11S User Account and Privilege Management Policy - SME ustanawia praktyczny poziom bazowy:

Uwierzytelnianie wieloskładnikowe (MFA) musi być włączone, tam gdzie jest to technicznie wykonalne, dla kont administratorów lub systemów wrażliwych.

Sformułowanie „tam gdzie jest to technicznie wykonalne” nigdy nie powinno stać się luką. Jeżeli system nie obsługuje silnego MFA, wyjątek musi zostać zarejestrowany z właścicielem, datą wygaśnięcia, zabezpieczeniami kompensującymi, monitorowaniem i planem migracji. Większe organizacje mogą dostosować to samo oczekiwanie do P11 User Account and Privilege Management Policy, a następnie sprawdzić, czy polityka i rzeczywistość operacyjna są zgodne.

Dowody detekcji pochodzą z P22S Logging and Monitoring Policy - SME, która wymaga rejestrowania zdarzeń uwierzytelniania:

Logi uwierzytelniania: udane i nieudane próby logowania, czas trwania sesji, użycie MFA

Wymaga ona również pilnego przeglądu sygnałów uwierzytelniania wysokiego ryzyka:

Natychmiastowy przegląd po wykryciu alertów o wysokiej wadze (np. złośliwe oprogramowanie, nieudane uwierzytelnianie wieloskładnikowe (MFA), powtarzające się nieudane logowania)

Świadomość musi ewoluować wraz z zagrożeniami. Information Security Awareness and Training Policy - SME wspiera tę pętlę:

Tematy muszą obejmować pojawiające się zagrożenia (np. phishing), odpowiednie zmiany polityk oraz wewnętrzne trendy incydentów.

Gdy SOC wykrywa próby zmęczenia MFA, informacje o zagrożeniach powinny zasilać alerty dla użytkowników, skrypty helpdesku, ćwiczenia tabletop i aktualizacje szkoleń.

Pakiet zabezpieczeń do nadzoru nad zmęczeniem MFA

Załóżmy, że organizacja używa chmurowego dostawcy tożsamości, CRM w modelu SaaS, platformy finansowej, VPN oraz dostawcy usług zarządzanych w zakresie bezpieczeństwa. Celem jest nadzór nad zmęczeniem MFA z wykorzystaniem Zenith Blueprint Clarysec, biblioteki polityk oraz przewodnika po zgodności między ramami Zenith Controls.

Zacznij od kroku 19 w Zenith Blueprint, który nakazuje zespołom zdefiniować wymagania uwierzytelniania dla poszczególnych systemów i ostrzega, że uwierzytelniania wyłącznie hasłem należy unikać dla kont administracyjnych, konsol chmurowych, narzędzi dostępu zdalnego i systemów dostępnych z Internetu. Następnie zastosuj praktyczne działanie przeglądowe:

Przejrzyj wdrożenie MFA: zidentyfikuj luki i zaplanuj ich usunięcie. Zweryfikuj, czy konta serwisowe są nieinteraktywne tam, gdzie to możliwe, mają silne dane uwierzytelniające i są udokumentowane. Potwierdź, że w żadnym systemie ani aplikacji nie pozostały domyślne dane uwierzytelniające.

Przekształć te wytyczne w operacyjny pakiet zabezpieczeń.

Krok 1: sklasyfikuj systemy według ryzyka uwierzytelniania

Krok 2: usuń zachowania push wysokiego ryzyka

Dla kont administratorów i kont o istotnym wpływie wyłącz podstawowe zatwierdzanie push. Tam, gdzie to możliwe, używaj autentykatorów odpornych na phishing. Tam, gdzie push pozostaje w użyciu, egzekwuj dopasowanie numerów, kontekst aplikacji, kontekst geograficzny, powiązanie z urządzeniem oraz limity częstotliwości monitów. Blokuj przestarzałe mechanizmy uwierzytelniania i wymagaj ponownego uwierzytelnienia dla sesji ryzykownych.

Krok 3: zdefiniuj reguły alertów dla zmęczenia MFA

Praktyczna reguła SIEM powinna wyzwalać alert, gdy w krótkim oknie czasowym wystąpi jeden lub więcej z poniższych wzorców:

• Trzy lub więcej monitów push MFA dla jednego użytkownika.
• Dwa odrzucone monity, po których następuje jeden zatwierdzony monit.
• Zatwierdzenie MFA z nowej lokalizacji geograficznej lub niezarządzanego urządzenia.
• Monit MFA po sygnale password spraying albo credential stuffing.
• Zatwierdzenie MFA dla dostępu uprzywilejowanego poza normalnymi godzinami pracy.
• Rejestracja nowego autentykatora krótko po nieudanych próbach logowania.

Alert powinien utworzyć zgłoszenie incydentu, powiadomić SOC albo osobę odpowiedzialną za bezpieczeństwo oraz wymagać działań powstrzymujących: zawieszenia sesji, unieważnienia tokenów odświeżania, wymuszenia resetu hasła, weryfikacji urządzenia, rozmowy z użytkownikiem, przeglądu dostępu w trakcie sesji oraz klasyfikacji, czy wystąpił wpływ na dane osobowe albo usługę krytyczną.

Krok 4: powiąż zapisy prywatności i incydentu

Jeżeli konto może uzyskać dostęp do danych osobowych, zastosuj PII Security and Access Control Policy. Wymaga ona silnego uwierzytelniania przed dostępem do PII o istotnym wpływie:

[Both] Osoba odpowiedzialna za bezpieczeństwo informacji MUSI wymagać silnego uwierzytelniania dla dostępu uprzywilejowanego, zdalnego, administracyjnego lub dostępu do PII o istotnym wpływie przed włączeniem takiego dostępu oraz odnotować wymaganie w REG12.

Wymaga ona również zdefiniowania zakresu rejestrowania:

[Both] Właściciel systemu / właściciel aplikacji MUSI zdefiniować zakres rejestrowania PII dla zdarzeń uwierzytelniania, zdarzeń dostępu, działań uprzywilejowanych, eksportu PII oraz istotnych zmian konfiguracji w REG12 przed użyciem produkcyjnym lub istotną zmianą.

Gdy monitorowanie wskazuje na nieuprawniony dostęp do PII, powstaje obowiązek utworzenia zapisu incydentu:

[Conditional] Koordynator reagowania na incydenty MUSI otworzyć albo powiązać rekord REG10 w ciągu jednego dnia roboczego, gdy monitorowanie wskazuje podejrzenie nieuprawnionego dostępu do PII, podejrzenie ujawnienia PII, podejrzenie zmiany PII albo podejrzenie utraty dostępności PII.

Eskalację prywatności uzupełnia PII Incident and Breach Management Policy:

[Conditional] Osoba odpowiedzialna za prywatność / Menedżer PIMS MUSI ocenić mające zastosowanie przesłanki zgłoszeniowe wynikające z wymagań prawnych, sektorowych, sektora finansowego, cyberbezpieczeństwa, umownych, klienta i odbiorcy usługi dla każdego incydentu PII o istotnym wpływie oraz odnotować wynik oceny stosowalności w REG01, REG08 i REG10.

W ten sposób alert MFA staje się dowodem gotowym do audytu w obszarze bezpieczeństwa, prywatności i zgodności.

NIS2, DORA i GDPR: jeden incydent, różne pytania

Zmęczenie MFA jest użytecznym testem obciążeniowym zgodności między ramami, ponieważ dotyka ładu organizacyjnego, cyberhigieny, kontroli dostępu, wykrywania incydentów, dostępu dostawców i zgłaszania naruszeń.

NIS2: rozliczalność kierownictwa i cyberhigiena

NIS2 ma zastosowanie do wielu podmiotów kluczowych i ważnych, zależnie od sektora, wielkości i wyznaczenia przez państwo członkowskie. Artykuł 20 nakłada rozliczalność na organy zarządzające w zakresie zatwierdzania środków zarządzania ryzykiem cyberbezpieczeństwa, nadzorowania wdrożenia i odbywania szkoleń. Artykuł 21 wymaga odpowiednich środków technicznych, operacyjnych i organizacyjnych, w tym obsługi incydentów, cyberhigieny, bezpieczeństwa łańcucha dostaw, kontroli dostępu, zarządzania aktywami, szkoleń oraz uwierzytelniania wieloskładnikowego lub ciągłego tam, gdzie jest to właściwe. Artykuł 23 wprowadza etapowe obowiązki zgłaszania istotnych incydentów, w tym wczesne ostrzeżenie w ciągu 24 godzin od uzyskania wiedzy oraz zgłoszenie incydentu w ciągu 72 godzin.

Incydent push bombing staje się więc pytaniem na poziomie zarządu: czy MFA zostało zaprojektowane bezpiecznie, czy tylko włączone?

DORA: uwierzytelnianie jako element cyfrowej odporności operacyjnej

Dla objętych zakresem podmiotów finansowych DORA ma zastosowanie od 17 stycznia 2025 r. Oczekuje zarządzania ryzykiem ICT, wykrywania, reagowania, odtwarzania, zgłaszania incydentów, testowania cyfrowej odporności operacyjnej oraz zarządzania ryzykiem ICT stron trzecich.

Artykuł 9 DORA dotyczy ochrony i zapobiegania, w tym kontroli dostępu i środków uwierzytelniania. Artykuł 10 dotyczy wykrywania anomalnej aktywności. Artykuł 17 wymaga procesu zarządzania incydentami związanymi z ICT. W kontekście DORA dowody dotyczące zmęczenia MFA powinny pokazywać, że dotknięte aktywa ICT zostały zidentyfikowane, monitorowanie wykryło anomalne zachowanie, incydent został sklasyfikowany według kryteriów wpływu, eskalowano go do kierownictwa wyższego szczebla tam, gdzie było to wymagane, a wnioski zostały przekazane z powrotem do ram zarządzania ryzykiem ICT.

GDPR: bezpieczeństwo przetwarzania i rozliczalność

Artykuł 5(1)(f) GDPR wymaga integralności i poufności. Artykuł 5(2) wymaga rozliczalności. Artykuł 32 wymaga bezpieczeństwa odpowiedniego do ryzyka. Artykuł 4 definiuje naruszenie ochrony danych osobowych jako naruszenie bezpieczeństwa prowadzące do przypadkowego lub niezgodnego z prawem zniszczenia, utraty, zmiany, nieuprawnionego ujawnienia danych osobowych lub nieuprawnionego dostępu do nich.

Jeżeli incydent zmęczenia MFA dotyka danych osobowych, pytanie dowodowe jest proste: czy organizacja może wykazać odpowiednie środki uwierzytelniania, monitorowania, reagowania na incydenty i oceny naruszenia?

Tabela korelacji dla ISO, NIST CSF 2.0, COBIT 2019 i dowodów audytowych

NIST CSF 2.0 jest użyteczny, ponieważ przekłada nadzór nad MFA na wyniki w funkcjach GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND i RECOVER.

COBIT 2019 dodaje przejrzystość ładu organizacyjnego. Audytor zorientowany na COBIT może odnieść się do DSS05.04 Manage identity and logical access, DSS05 Manage security services, APO13 Managed security oraz MEA03 Managed compliance with external requirements. Przedmiotem zainteresowania nie jest dostawca MFA. Chodzi o to, czy uwierzytelnianie wspiera cele biznesowe, czy prawa dostępu są objęte nadzorem, czy monitorowanie jest skuteczne oraz czy kierownictwo otrzymuje znaczące zapewnienie.

Skonsolidowane mapowanie pomaga zespołom ds. zgodności uniknąć rozproszonych żądań dowodowych:

O co poproszą audytorzy i regulatorzy

Silny program zarządzania ryzykiem zmęczenia MFA powinien wytrzymać różne style audytu. Przewodnik po zgodności między ramami Zenith Controls Clarysec pokazuje, jak zabezpieczenia ISO/IEC 27002:2022 są testowane w metodykach ISO, NIST, COBIT i ISACA.

Słaby program mówi: „Zapytaliśmy użytkownika i zresetowaliśmy hasło”. Program objęty nadzorem tworzy alert SIEM, zgłoszenie incydentu, zapis unieważnienia sesji, dowód resetu hasła, przegląd czynnika MFA, analizę logów dostępu, ocenę PII, ocenę przesłanek zgłoszeniowych, opis przyczyny źródłowej, działania korygujące i wkład do przeglądu zarządzania.

30-dniowy plan działań dla nadzoru nad zmęczeniem MFA

Celem nie jest doskonałość w 30 dni. Celem jest widoczność, własność i dowody.

Tydzień 1: identyfikacja i zakres

• Sporządź listę wszystkich dostawców tożsamości, VPN, konsol chmurowych, platform SaaS i narzędzi dostępu uprzywilejowanego.
• Zidentyfikuj systemy zawierające dane osobowe, dane finansowe, dostęp do środowiska produkcyjnego albo funkcje wpływające na usługi.
• Wyeksportuj aktualne metody MFA i wyjątki.
• Zidentyfikuj konta zewnętrzne i konta dostawców.
• Dodaj zmęczenie MFA i push bombing do rejestru ryzyk.
• Przypisz właściciela ryzyka i właściciela postępowania z ryzykiem.

Tydzień 2: utwardzenie uwierzytelniania

• Wyłącz przestarzałe mechanizmy uwierzytelniania.
• Wymagaj MFA odpornego na phishing dla administratorów tam, gdzie jest to wykonalne.
• Włącz dopasowanie numerów i kontekst aplikacji dla MFA push.
• Zastosuj dostęp warunkowy dla lokalizacji, zgodności urządzeń i niemożliwej podróży.
• Ogranicz powtarzające się monity push.
• Wymagaj ponownego uwierzytelnienia dla działań wysokiego ryzyka.
• Uczyń konta serwisowe nieinteraktywnymi tam, gdzie to możliwe.
• Udokumentuj wyjątki wraz z datą wygaśnięcia i zabezpieczeniami kompensującymi.

Tydzień 3: monitorowanie i przećwiczenie

• Upewnij się, że logi uwierzytelniania obejmują sukces, niepowodzenie, czas trwania sesji i użycie MFA.
• Utwórz reguły alertów dla powtarzających się monitów, odrzuconych monitów zakończonych zatwierdzeniem, rejestracji nowego urządzenia i nietypowej lokalizacji.
• Przetestuj alerty za pomocą kontrolowanej symulacji.
• Zweryfikuj utworzenie zgłoszenia incydentu i eskalację.
• Przeszkol użytkowników krótkim ćwiczeniem dotyczącym „nieoczekiwanego monitu MFA”.
• Zaktualizuj skrypty helpdesku, aby ograniczyć inżynierię społeczną podczas resetowania haseł i ponownej rejestracji MFA.

Tydzień 4: dowody i przegląd zarządzania

• Zapisz eksporty konfiguracji i zrzuty ekranu.
• Odnotuj wyniki przeglądów dostępu.
• Powiąż ukończenie szkoleń z użytkownikami uprzywilejowanymi.
• Przejrzyj incydenty i sytuacje bliskie incydentowi.
• Zaktualizuj Deklarację stosowania i plan postępowania z ryzykiem.
• Przedstaw kierownictwu ryzyko szczątkowe i metryki.
• Zaplanuj próbkowanie w audycie wewnętrznym.

Uczyń zmęczenie MFA audytowalnym, zanim stanie się zgłaszalne

Zmęczenie MFA przypomina, że zabezpieczenia zawodzą na styku obszarów: między tożsamością a monitorowaniem, między polityką a szkoleniem, między dostawcami a dostępem wewnętrznym, między reagowaniem na incydenty a zgłaszaniem naruszeń prywatności.

Organizacje, które dobrze tym zarządzają, nie tylko „włączają MFA”. Obejmują uwierzytelnianie nadzorem jako cykl życia, monitorują je jako sygnał zagrożenia, szkolą użytkowników jako część zabezpieczenia i zachowują dowody jako element SZBI.

Clarysec łączy trzy zasoby:

• Zenith Blueprint: 30-etapowa mapa drogowa audytora, w szczególności krok 19 dotyczący bezpiecznego uwierzytelniania, krok 22 dotyczący informacji uwierzytelniających oraz krok 16 dotyczący zgłaszania incydentów przez personel.
• Szablony polityk Clarysec, w tym P38 Secure Communications and Multi-Factor Authentication (MFA) Policy, P22S Logging and Monitoring Policy - SME, P11S User Account and Privilege Management Policy - SME, Information Security Awareness and Training Policy - SME, PII Security and Access Control Policy oraz PII Incident and Breach Management Policy.
• Zenith Controls: przewodnik po zgodności między ramami, który mapuje zabezpieczenia ISO/IEC 27002:2022 5.17, 8.5, 8.15 i 8.16 na wspierające zabezpieczenia, oczekiwania audytowe ISO, GDPR, NIS2, DORA, NIST i COBIT.

Jeżeli jesteś CISO, menedżerem zgodności, audytorem albo właścicielem biznesowym, przeprowadź jednotygodniowy przegląd dowodów dotyczących zmęczenia MFA. Pobierz konfigurację MFA, logi uwierzytelniania, listę dostępów uprzywilejowanych, listę dostępów dostawców, podręcznik postępowania z incydentami, materiały szkoleniowe i rejestr wyjątków. Jeżeli te artefakty nie opowiadają jednej spójnej historii, Clarysec może pomóc zbudować pakiet zabezpieczeń, zanim poprosi o niego atakujący, audytor albo regulator.

Poznaj Zenith Blueprint, przejrzyj Zenith Controls albo umów rozmowę wprowadzającą z Clarysec, aby zmienić zmęczenie MFA z niespodzianki na poziomie zarządu w możliwy do obrony, audytowalny program uwierzytelniania.