Управление на умората от MFA и атаките чрез бомбардиране с push известия

Push известието в 2:13 ч., което се превърна във въпрос към ръководния орган

В 2:13 ч. старши финансов администратор получава мобилно известие: „Одобряване на вход?“ Тя е полузаспала, приема, че става дума за изтекла сесия в облачна финансова платформа, и натиска „Одобри“.

До 2:19 ч. нападателят вече е в доставчика на идентичност. До 2:31 ч. прави опити за достъп до експорт на данни за заплати, привилегирована облачна конзола и споделена пощенска кутия, използвана за плащания към доставчици. В 3:05 ч. SOC вижда повтарящи се MFA заявки, необичайна геолокация, успешно одобрение и нова сесия от неуправлявано устройство.

Сутрешният разговор е познат:

• „Но ние имахме MFA.“
• „Защо потребителят го одобри?“
• „Регистрирахме ли детайлите за MFA предизвикателството?“
• „Това нарушение на сигурността на личните данни ли е?“
• „Имаме ли задължения за докладване в срок от 24 часа или 72 часа?“
• „Ще третира ли нашият одитор по ISO 27001:2022 това като отказ на контрол?“
• „Засяга ли това NIS2, DORA, GDPR, клиентски договори или киберзастраховка?“

Това е управленският пропуск зад умората от MFA и бомбардирането с push известия. Нападателите не разбиват криптографията. Те изчерпват човешкия капацитет за вземане на решения, експлоатират слаб дизайн на автентикацията и търсят ненаблюдавани изключения. Отказът на контрол рядко е „MFA не е активирана“. Обикновено това е верига от слаба увереност в идентичността, рисков дизайн на push одобренията, липсващо съпоставяне на номер, неясни правила за привилегирован достъп, недостатъчно регистриране на събитията по автентикация, слаб триаж на предупрежденията, недостатъчно обучени потребители и липса на документирани доказателства, че организацията е прегледала и отстранила слабостта.

За директорите по информационна сигурност (CISO), мениджърите по съответствие, одиторите и собствениците на процеси умората от MFA трябва да се третира като въпрос на доказателства в СУИС, а не само като настройка в доставчика на идентичност. Отговорът съчетава третиране на риска по ISO 27001:2022, контроли по ISO/IEC 27002:2022, задължения по политики, осведоменост на потребителите, реагиране при инциденти, управление на доставчици и съпоставяне между рамки за NIS2, DORA, GDPR, NIST CSF 2.0 и COBIT 2019.

Умората от MFA е отказ на увереността, а не потребителски проблем

Умората от MFA, наричана още бомбардиране с push известия или бомбардиране със заявки за потвърждение, възниква, когато нападател с валидна парола многократно задейства заявки за одобрение чрез MFA, докато потребителят приеме една от тях. Понякога нападателят добавя социално инженерство, например фалшиво обаждане от службата за поддръжка, съобщение от типа „тестваме вашия акаунт“ или искане потребителят да одобри вход, за да спрат известията.

Оперативният риск е, че организациите често третират всички MFA методи като равностойни. Те не са.

Просто push известие „одобри или откажи“ е по-слабо от съпоставяне на номер, устойчиви на фишинг FIDO2 ключове за сигурност, автентикация на базата на сертификати или условен достъп, който блокира невъзможно пътуване и неуправлявани устройства. MFA се проваля и когато изключенията за заобикаляне не са документирани, служебните акаунти са интерактивни, наследени протоколи остават отворени или високорисковият достъп не изисква по-силна автентикация.

В Zenith Blueprint: 30-стъпкова пътна карта за одитори Clarysec поставя сигурната автентикация във фазата „Контроли в действие“, стъпка 19: Технологични контроли I. Насоката е пряка:

Автентикацията е първата и най-критична линия на защита между нападателя и вашите системи, данни и услуги. Ако автентикацията е слаба, всичко останало — криптиране, мониторинг, сегментиране — може да бъде заобиколено.

Същият Zenith Blueprint разглежда и контрол 5.17 от ISO/IEC 27002:2022 в стъпка 22:

Ако идентичността задава въпроса „Кой сте вие?“, автентикацията е доказателството. Контрол 5.17 е мястото, където теорията среща доверието. Той изисква информацията за автентикация да се управлява сигурно през целия ѝ жизнен цикъл, така че методите и удостоверителните данни, използвани за проверка на идентичността, сами да не се превърнат в най-слабото звено.

Тези две твърдения обясняват защо бомбардирането с push известия принадлежи в регистъра на риска. Криптирането не помага, ако нападателят се превърне в одобрен потребител. Мрежовото сегментиране помага по-малко, ако привилегирован облачен достъп бъде одобрен чрез заявка, потвърдена от уморен потребител. Мониторингът работи само ако събитията по автентикация се регистрират с достатъчна детайлност и се преглеждат своевременно.

Зрелият запис на риск трябва да бъде ясен:

Тук ISO 27001:2022 има значение. Стандартът изисква контекст, заинтересовани страни, лидерство, оценка на риска, планиране на третирането, оперативен контрол, мониторинг, вътрешен одит, преглед от ръководството и непрекъснато подобрение. Умората от MFA засяга всички тях.

Клъстерът от контроли по ISO 27001:2022, който одиторите ще тестват

ISO 27001:2022 предоставя структурата на системата за управление. ISO/IEC 27002:2022 предоставя насоки за внедряване на контролите. При умора от MFA и бомбардиране с push известия одиторите обикновено се фокусират върху клъстер от контроли, а не върху един-единствен контрол.

Zenith Controls: ръководство за съответствие между рамки на Clarysec съпоставя контрол 8.5 Сигурна автентикация от ISO/IEC 27002:2022 с поддържащи контроли като 5.17 Информация за автентикация, 8.2 Права за привилегирован достъп, 8.16 Дейности по мониторинг, 5.24 Планиране и подготовка за управление на инциденти по информационна сигурност и 5.34 Неприкосновеност и защита на PII. Тази връзка между контролите е важна, защото екранна снимка с „MFA enabled“ не е достатъчна. Одиторите искат доказателство, че автентикацията е проектирана, наблюдавана, преглеждана и подобрявана на база риск.

Защитимият пакет с доказателства трябва да включва:

1. Оценка на риска, която идентифицира бомбардиране с push известия и социално инженерство при MFA заявки.
2. Стандарт за автентикация, който определя допустимите MFA методи според критичността на системата.
3. Политика за привилегирован достъп, която изисква по-силна автентикация за администраторски и отдалечен достъп.
4. Експорт на конфигурацията на доставчика на идентичност, показващ съпоставяне на номер, ограничения на заявките, условен достъп и блокирана наследена автентикация.
5. Журнали, показващи успешни и неуспешни MFA събития, отказани заявки, невъзможно пътуване и контекст за устройство.
6. Правила за предупреждения при повтарящи се MFA заявки, повтарящи се неуспехи и необичайно успешно одобрение.
7. Записи от реагиране при инциденти за предупреждения, свързани с автентикацията.
8. Съдържание за обучение по осведоменост, което указва на потребителите да не одобряват неочаквани заявки.
9. Записи от преглед на достъпа за привилегировани системи и системи с високо въздействие.
10. Регистър на изключенията със срокове на валидност, одобрения от собственика на риска и компенсиращи контроли.

Политиката превръща „не одобрявайте неочаквани заявки“ в доказателства

Много организации казват на потребителите да не одобряват подозрителни заявки. Този съвет е полезен, но не е достатъчен за сертификация по ISO 27001:2022, надзор по NIS2, устойчивост по DORA, отчетност по GDPR, клиентска надлежна проверка или киберзастраховане.

Първата опора в политиките е P38 Политика за сигурни комуникации и многофакторна автентикация (MFA). Тя разглежда пряко човешкия фактор:

Осведоменост на потребителите: Потребителите трябва да получават обучение за разграничаване на сигурни от несигурни комуникационни канали. Обучението трябва да обхваща правилното използване на многофакторна автентикация (MFA) (напр. неодобряване на неочаквани заявки за вход) и практики за сигурни комуникации (напр. проверка на връзки за видеоконференции и недопускане на обсъждане на поверителни теми през незащитени линии).

Това превръща умората от MFA в задължение за обучение, а не в упражнение по търсене на вина. То позволява на CISO да покаже, че бомбардирането със заявки за потвърждение е обхванато при въвеждане в длъжност, опреснително обучение, ролево базирано обучение и инструктажи за привилегировани потребители.

Същата P38 Политика за сигурни комуникации и многофакторна автентикация (MFA) създава и задължение за мониторинг:

Екипът по информационна сигурност трябва непрекъснато да наблюдава журналите за автентикация за опити за вход само с един фактор или аномални неуспехи при многофакторна автентикация (MFA). Журналите от системи за сигурна комуникация, когато е приложимо, трябва да се наблюдават за опити за неоторизиран достъп или промени в конфигурацията.

За малки и средни предприятия P11S Политика за управление на потребителски акаунти и привилегии - SME задава практичен базов набор:

Многофакторна автентикация (MFA) трябва да бъде активирана, когато е технически възможно, за администраторски акаунти или чувствителни системи.

Фразата „когато е технически възможно“ никога не трябва да се превръща във вратичка. Ако дадена система не поддържа силна автентикация, изключението трябва да бъде записано със собственик, срок на валидност, компенсиращи контроли, мониторинг и план за миграция. По-големите организации могат да съгласуват същото очакване с P11 Политика за управление на потребителски акаунти и привилегии, след което да проверят дали политиката и оперативната реалност съвпадат.

Доказателствата за откриване идват от P22S Политика за регистриране и мониторинг - SME, която изисква регистриране на събития при автентикация:

Журнали за автентикация: успешни и неуспешни опити за вход, продължителност на сесията, използване на MFA

Тя също изисква спешен преглед на високорискови сигнали при автентикация:

Незабавен преглед при откриване на предупреждения с висока степен на сериозност (напр. зловреден софтуер, неуспешна многофакторна автентикация (MFA), повтарящи се неуспешни входове)

Осведомеността трябва да се развива заедно със заплахите. Политика за осведоменост и обучение по информационна сигурност - SME поддържа този цикъл:

Темите трябва да включват нововъзникващи заплахи (напр. фишинг), релевантни промени в политиките и вътрешни тенденции при инцидентите.

Когато SOC открие опити за умора от MFA, тази информация за заплахите трябва да захрани предупреждения към потребителите, скриптове за службата за поддръжка, настолни упражнения и актуализации на обучението.

Управляван пакет от контроли за умора от MFA

Да приемем, че организацията използва облачен доставчик на идентичност, SaaS CRM, финансова платформа, VPN и доставчик на управлявани услуги за сигурност. Целта е умората от MFA да се управлява чрез Zenith Blueprint на Clarysec, библиотеката с политики и ръководството за съответствие между рамки Zenith Controls.

Започнете със стъпка 19 в Zenith Blueprint, която указва на екипите да дефинират изискванията за автентикация за всяка система и предупреждава, че автентикация само с парола трябва да се избягва за административни акаунти, облачни конзоли, инструменти за отдалечен достъп и системи, изложени към интернет. След това приложете практическата дейност за преглед:

Прегледайте вашето внедряване на MFA: идентифицирайте пропуските и планирайте тяхното отстраняване. Валидирайте, че служебните акаунти са неинтерактивни, когато е възможно, имат силни удостоверителни данни и са документирани. Потвърдете, че в нито една система или приложение не са останали удостоверителни данни по подразбиране.

Преобразувайте тази насока в оперативен пакет от контроли.

Стъпка 1: класифицирайте системите според риска при автентикация

Стъпка 2: премахнете високорисковото push поведение

За администраторски акаунти и акаунти с високо въздействие деактивирайте базовото push одобрение. Използвайте устойчиви на фишинг автентификатори, когато е възможно. Когато push известията остават, прилагайте съпоставяне на номер, контекст на приложението, географски контекст, обвързване с устройство и ограничения на честотата на заявките. Блокирайте наследената автентикация и изисквайте повторна автентикация за рискови сесии.

Стъпка 3: дефинирайте правила за предупреждения при умора от MFA

Практично SIEM правило трябва да се задейства, когато един или повече от тези модели възникнат в кратък времеви прозорец:

• Три или повече MFA push заявки за един потребител.
• Две отказани заявки, последвани от една одобрена заявка.
• MFA одобрение от нова геолокация или неуправлявано устройство.
• MFA заявка след сигнал за password spraying или credential stuffing.
• MFA одобрение за привилегирован достъп извън нормалното работно време.
• Регистрация на нов автентификатор малко след неуспешни опити за вход.

Предупреждението трябва да създаде билет за инцидент, да уведоми SOC или ръководителя по сигурността и да изисква стъпки за ограничаване: прекратяване на сесията, отнемане на refresh токени, изискване за нулиране на парола, проверка на устройството, интервю с потребителя, преглед на достъпа по време на сесията и класификация дали е настъпило въздействие върху лични данни или критична услуга.

Стъпка 4: свържете записите за защита на личните данни и инциденти

Ако акаунтът може да достъпва лични данни, приложете Политика за сигурност и контрол на достъпа до лични данни (PII). Тя изисква силна автентикация преди достъп до лични данни с високо въздействие:

[И в двата случая] Ръководителят по информационна сигурност ТРЯБВА да изисква силна автентикация за привилегирован, отдалечен, административен достъп или достъп до лични данни с високо въздействие, преди такъв достъп да бъде активиран, и да запише изискването в REG12.

Тя също изисква да бъде дефиниран обхватът на регистриране:

[И в двата случая] Собственикът на система / собственикът на приложение ТРЯБВА да дефинира обхвата на регистриране на лични данни за събития при автентикация, събития при достъп, привилегировани действия, дейности по експорт на лични данни и съществени промени в конфигурацията в REG12 преди продукционна употреба или съществена промяна.

Когато мониторингът сочи неоторизиран достъп до лични данни (PII), това създава задължение за запис на инцидент:

[Условно] Координаторът по реагиране при инциденти ТРЯБВА да открие или свърже запис в REG10 в рамките на един работен ден, когато мониторингът показва предполагаем неоторизиран достъп до лични данни, предполагаемо разкриване на лични данни, предполагаема промяна на лични данни или предполагаема загуба на наличност на лични данни.

Ескалацията по защита на личните данни се завършва чрез Политика за управление на инциденти и нарушения на сигурността на личните данни:

[Условно] Ръководителят по защита на личните данни / мениджърът на PIMS ТРЯБВА да оцени приложимите правни, секторни, финансово-секторни, киберсигурностни, договорни, клиентски и свързани с получатели на услуги критерии за задействане на докладване за всеки инцидент с лични данни с високо въздействие и да запише резултата за приложимостта в REG01, REG08 и REG10.

Това превръща MFA предупреждението в доказателства, готови за одит, в областите сигурност, защита на личните данни и съответствие.

NIS2, DORA и GDPR: един инцидент, различни въпроси

Умората от MFA е полезен стрес тест за съответствие между рамки, защото засяга управление, киберхигиена, контрол на достъпа, откриване на инциденти, достъп на доставчици и докладване на нарушения.

NIS2: отчетност на ръководството и киберхигиена

NIS2 се прилага за много съществени и важни субекти в зависимост от сектора, размера и определянето от държавата членка. Article 20 възлага отчетност на ръководните органи да одобряват мерките за управление на риска за киберсигурността, да упражняват надзор върху прилагането им и да получават обучение. Article 21 изисква подходящи технически, оперативни и организационни мерки, включително обработване на инциденти, киберхигиена, сигурност на веригата на доставки, контрол на достъпа, управление на активите, обучение и многофакторна или непрекъсната автентикация, когато е подходящо. Article 23 въвежда задължения за поетапно докладване на инциденти за значителни инциденти, включително ранно предупреждение в рамките на 24 часа от узнаването и уведомление за инцидент в рамките на 72 часа.

Следователно инцидент с бомбардиране с push известия се превръща във въпрос към ръководния орган: MFA проектирана ли е сигурно, или просто е активирана?

DORA: автентикацията като цифрова оперативна устойчивост

За обхванатите финансови субекти DORA се прилага от 17 януари 2025 г. Тя очаква управление на ИКТ риска, откриване, реагиране, възстановяване, докладване на инциденти, тестване на цифровата оперативна устойчивост и управление на риска от трети страни в областта на ИКТ.

DORA Article 9 разглежда защитата и превенцията, включително контрол на достъпа и мерки за автентикация. Article 10 разглежда откриването на аномална дейност. Article 17 изисква процес за управление на инциденти, свързани с ИКТ. В контекст на DORA доказателствата за умора от MFA трябва да показват, че засегнатите ИКТ активи са идентифицирани, мониторингът е открил аномално поведение, инцидентът е класифициран чрез критерии за въздействие, висшето ръководство е било уведомено по реда за ескалация, когато се изисква, и извлечените поуки са върнати в рамката за управление на ИКТ риска.

GDPR: сигурност на обработването и отчетност

GDPR Article 5(1)(f) изисква цялостност и поверителност. Article 5(2) изисква отчетност. Article 32 изисква сигурност, съответстваща на риска. Article 4 дефинира нарушение на сигурността на личните данни като нарушение на сигурността, което води до случайно или незаконосъобразно унищожаване, загуба, промяна, неоторизирано разкриване или достъп до лични данни.

Ако инцидент с умора от MFA засяга лични данни, въпросът за доказателствата е прост: може ли организацията да демонстрира подходящи контроли за автентикация, мониторинг, реагиране при инциденти и оценка на нарушението?

Съпоставяне за ISO, NIST CSF 2.0, COBIT 2019 и одитни доказателства

NIST CSF 2.0 е полезна рамка, защото превежда управлението на MFA в резултати по GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND и RECOVER.

COBIT 2019 добавя яснота в управлението. Одитор, ориентиран към COBIT, може да разгледа DSS05.04 Manage identity and logical access, DSS05 Manage security services, APO13 Managed security и MEA03 Managed compliance with external requirements. Фокусът не е доставчикът на MFA. Фокусът е дали автентикацията подкрепя бизнес целите, дали правата за достъп се управляват, дали мониторингът е ефективен и дали ръководството получава смислено уверение.

Консолидираното съпоставяне помага на екипите по съответствието да избегнат фрагментирани искания за доказателства:

Какво ще поискат одиторите и регулаторите

Силната програма за управление на умората от MFA трябва да издържи на различни одитни подходи. Ръководството за съответствие между рамки Zenith Controls на Clarysec показва как контролите по ISO/IEC 27002:2022 се тестват чрез методологии на ISO, NIST, COBIT и ISACA.

Слаба програма казва: „Попитахме потребителя и нулирахме паролата.“ Управлявана програма предоставя SIEM предупреждение, билет за инцидент, запис за отнемане на сесия, доказателства за нулиране на парола, преглед на MFA фактора, анализ на журналите за достъп, оценка на PII, оценка на критериите за задействане на докладване, становище за първопричината, коригиращи действия и входна информация за прегледа от ръководството.

30-дневен план за действие за управление на умората от MFA

Целта не е съвършенство за 30 дни. Целта е видимост, собственост и доказателства.

Седмица 1: идентифициране и определяне на обхвата

• Избройте всички доставчици на идентичност, VPN, облачни конзоли, SaaS платформи и инструменти за привилегирован достъп.
• Идентифицирайте системите с лични данни, финансови данни, достъп до продукционна среда или функции, които могат да засегнат услугите.
• Експортирайте текущите MFA методи и изключения.
• Идентифицирайте външните акаунти и акаунтите на доставчици.
• Добавете умората от MFA и бомбардирането с push известия в регистъра на риска.
• Определете собственик на риска и собственик на третирането.

Седмица 2: укрепване на автентикацията

• Деактивирайте наследената автентикация.
• Изисквайте устойчиво на фишинг MFA за администратори, когато е възможно.
• Активирайте съпоставяне на номер и контекст на приложението за push MFA.
• Прилагайте условен достъп за местоположение, съответствие на устройството и невъзможно пътуване.
• Ограничете повтарящите се push заявки.
• Изисквайте повторна автентикация за високорискови действия.
• Направете служебните акаунти неинтерактивни, когато е възможно.
• Документирайте изключенията със срок на валидност и компенсиращи контроли.

Седмица 3: мониторинг и упражнение

• Уверете се, че журналите за автентикация обхващат успех, неуспех, продължителност на сесията и използване на MFA.
• Създайте правила за предупреждения при повтарящи се заявки, отказани заявки, последвани от одобрение, регистрация на ново устройство и необичайно местоположение.
• Тествайте предупрежденията с контролирана симулация.
• Валидирайте създаването и ескалацията на билет за инцидент.
• Обучете потребителите чрез кратко упражнение „неочаквана MFA заявка“.
• Актуализирайте скриптовете за службата за поддръжка, за да се предотврати социално инженерство при нулиране на пароли и повторна регистрация в MFA.

Седмица 4: доказателства и преглед от ръководството

• Съхранете експорти на конфигурации и екранни снимки.
• Запишете резултатите от прегледите на достъпа.
• Свържете завършеното обучение с привилегированите потребители.
• Прегледайте инцидентите и предотвратените инциденти.
• Актуализирайте Декларацията за приложимост и плана за третиране.
• Представете остатъчния риск и показателите на ръководството.
• Планирайте извадково тестване във вътрешния одит.

Направете умората от MFA одитируема, преди да стане подлежаща на докладване

Умората от MFA напомня, че контролите за сигурност се провалят на границите: между идентичността и мониторинга, между политиката и обучението, между доставчиците и вътрешния достъп, между реагирането при инциденти и докладването по защита на личните данни.

Организациите, които я управляват добре, не просто „включват MFA“. Те управляват автентикацията като жизнен цикъл, наблюдават я като сигнал за заплаха, обучават потребителите като част от контрола и запазват доказателства като част от СУИС.

Clarysec обединява три актива:

• Zenith Blueprint: 30-стъпкова пътна карта за одитори, особено стъпка 19 за сигурна автентикация, стъпка 22 за информация за автентикация и стъпка 16 за докладване на инциденти от персонала.
• Шаблони за политики на Clarysec, включително P38 Политика за сигурни комуникации и многофакторна автентикация (MFA), P22S Политика за регистриране и мониторинг - SME, P11S Политика за управление на потребителски акаунти и привилегии - SME, Политика за осведоменост и обучение по информационна сигурност - SME, Политика за сигурност и контрол на достъпа до лични данни (PII) и Политика за управление на инциденти и нарушения на сигурността на личните данни.
• Zenith Controls: ръководство за съответствие между рамки, което съпоставя контроли 5.17, 8.5, 8.15 и 8.16 от ISO/IEC 27002:2022 с поддържащи контроли, очаквания при ISO одит, GDPR, NIS2, DORA, NIST и COBIT.

Ако сте CISO, мениджър по съответствие, одитор или собственик на процес, проведете едноседмичен преглед на доказателствата за умора от MFA. Извлечете конфигурацията на MFA, журналите за автентикация, списъка с привилегирован достъп, списъка с достъп на доставчици, наръчника за инциденти, учебните материали и регистъра на изключенията. Ако тези артефакти не разказват една последователна история, Clarysec може да ви помогне да изградите пакета от контроли, преди нападател, одитор или регулатор да го поиска.

Разгледайте Zenith Blueprint, прегледайте Zenith Controls или насрочете опознавателен разговор с Clarysec, за да превърнете умората от MFA от изненада за ръководния орган в защитима и одитируема програма за автентикация.