Продолжение. С первой частью можно ознакомиться здесь.
5.
РекомендацииВ этом разделе каждая из предыдущих рекомендаций будет рассмотрена более подробно.
5.1.
Ключевые рекомендацииЭти рекомендации следует считать обязательными для всех систем, если они технически выполнимы.
5.1.1. Длина пароля или парольной фразы
Разрешите использование длинных парольных фраз, но не применяйте их принудительно.
В соответствии с общей целью заставить пользователей создавать не слишком слабые пароли, рекомендуемая минимальная длина пароля составляет 8 символов для учетной записи с МФА, и 14 символов — для учетной записи, использующей только пароль. При выборе максимальной длины пароля стоит отталкиваться от наибольшего значения, позволяемого возможностями системы/программного обеспечения, а не ограничиваться политикой.
В целом верно, что длинные пароли лучше коротких (их труднее взломать). Но также верно и то, что категоричные требования к длине используемых паролей предсказуемо вызывают нежелательное поведение пользователей. Например, требование иметь минимум 16-символьный пароль может заставить их выбирать повторяющиеся шаблоны типа «PasswordPassword» или «1234123412341234», которые соответствуют правилу, но легко угадываются злоумышленниками. К тому же, предписание иметь длинные пароли увеличивает вероятность того, что пользователи будут применять и другие небезопасные методы для упрощения работы с ними. Например, записывать их, использовать повторно или хранить в незашифрованном виде в своих документах.
Установление разумной минимальной длины без ограничения максимального количества символов увеличивает среднюю длину используемого пароля (и, следовательно, его надежность).
5.1.1.1. Парольные фразы
Обучите пользователей применению парольных фраз. Это приведет к созданию более длинных и надежных паролей.
В парольной фразе используется ряд слов, которые могут включать или не включать пробелы: correcthorsebatterystaple – пример парольной фразы из известного комикса XKCD на эту тему. Несмотря на то, что парольные фразы часто содержат больше символов, чем пароли, они всегда содержат меньше «компонентов» (четыре слова вместо, скажем, 12 случайных символов).
В конечном счете, все дело — в соотношении длины и легкости запоминания. Именно поэтому обучение пользователей таким приемам, как применение парольных фраз, позволяющих создавать более длинные и легко запоминающиеся пароли — весьма эффективная практика.
Примечание. Для получения более подробной информации об использовании парольных фраз, см. Приложение: что делает пароль хорошим?
Итоговая рекомендация:
5.1.2. Состав/сложность пароля
Разрешите использование символов любого типа, но не принуждайте использовать символы определенных типов.
Требования к составу или сложности пароля часто используются для повышения надежности создаваемого пользователем пароля заданной длины. Например, сложный пароль должен содержать некоторое количество символов из всех трех следующих категорий:
✧ заглавные символы;
✧ строчные символы;
✧ неалфавитные символы, такие как цифры или специальные символы, например <*&(^%$>!):.
В настоящее время не существует стандарта для состава пароля, поэтому очень часто эти требования варьируются от системы к системе (например, одна система разрешает специальные символы, а другая – нет).
Требования к составу пароля являются слабой защитой от атаки Password Guessing. Принуждение пользователей к выбору некоторой комбинации символов верхнего и нижнего регистра, цифр и специальных символов нередко влечет негативные последствия. Это создает дополнительную нагрузку на пользователей, и многие из них будут обращаться к предсказуемым шаблонам (например, заглавная буква в первой позиции, затем строчные буквы, затем одна или две цифры и «специальный символ» в конце). Злоумышленники знают об этом, и в ходе словарных атак часто используют эти популярные шаблоны, а также наиболее распространенные замены, например, $ на s, @ на a, 1 на l, 0 на o.
Слишком сложные по своей природе пароли затрудняют запоминание пользователям, что приводит к негативным последствиям. Кроме того, требования к составу не обеспечивают защиту от распространенных типов атак, таких как социальная инженерия, или ненадежного хранения паролей.
Итоговая рекомендация:
5.1.3. Срок действия пароля
Меняйте пароли в зависимости от событий, с ежегодной «подстраховкой».
Чрезмерные требования к сроку действия паролей приносят больше вреда, чем пользы, поскольку заставляют пользователей выбирать предсказуемые пароли, состоящие из последовательных слов и цифр, тесно связанных друг с другом. В таких случаях следующий пароль можно предсказать на основе предыдущего (например, увеличивая используемое в пароле число).
Требование обязательной смены пароля по истечении определенного срока действия не дает никаких преимуществ в плане сопротивления злоумышленникам, поскольку те часто используют учетные данные сразу после их получения. Вместо расписания, немедленная смена пароля должна основываться на ключевых событиях, таких, как (перечень не является исчерпывающим):
✧ появление признаков компрометации;
✧ смена ролей пользователя;
✧ увольнение пользователя.
Смена паролей каждые несколько недель или месяцев не только усложняет жизнь пользователя, но и для системы приносит больше вреда, чем пользы, поскольку может привести к неправильным действиям пользователя вроде добавления символа в конец существующего пароля.
Дополнительно мы рекомендуем проводить ежегодную смену паролей. Это связано в первую очередь с тем, что, при всех своих благих намерениях, пользователи будут использовать одни и те же учетные данные в разных системах. Впоследствии, даже если утечка данных из какой-либо системы получит публичную огласку, человек может просто не увидеть сообщение об этом факте, или вообще забыть, что у него был аккаунт, например, на скомпрометированном сайте. Подобная ситуация может сделать общие учетные данные уязвимыми на неопределенный срок. Парольная политика организации, предусматривающая ежегодную смену однолетних паролей, является разумным компромиссом для смягчения описанной проблемы при минимальной нагрузке на пользователя.
Примечание. Существуют организации, использующие автоматически генерируемые одноразовые пароли для каждого доступа к учетной записи (такой тип парольной политики выходит за рамки данного документа). В этих случаях пароль для каждой учетной записи может меняться по многу раз в день. Системы подобного типа отличают беспрецедентный уровень безопасности и почти такая же редкость.
Итоговая рекомендация:
5.1.4. Запрет использования словарных паролей
Проверяйте пароли по списку плохих паролей.
Организациям следует запретить использование распространенных словарных паролей. Это снижает восприимчивость к атакам Brute Force и Password Spraying. Несколько примеров часто используемых паролей: abdcefg, password, qwerty, iloveyou и 12345678 (более полный список распространенных паролей можно найти здесь).
При обработке запросов на создание или изменение пароля, новый пароль должен быть проверен по списку, который содержит часто используемые, словарные или скомпрометированные пароли. Например, список должен включать (но не ограничиваться):
✧ пароли, скомпрометированные в результате предыдущих взломов;
✧ словарные слова;
✧ повторяющиеся или последовательные символы (например, aaaaaa, 1234abcd);
✧ контекстно-специфические слова, такие как название службы, имя пользователя и производные от них;
✧ ранее использовавшиеся пароли для этой учетной записи с задержкой их изменения;
✧ личные идентификационные данные пользователя, если это возможно (дата рождения, фамилия и т.д.).
Проверка должна происходить непосредственно при создании пароля. Если пароль пользователя не прошел проверку по списку запрещенных слов, пользователь должен быть уведомлен о том, что пароль не может быть применен с кратким объяснением причины. Затем пользователю должно быть предложено ввести новый пароль.
Списки запрета паролей — относительно новый инструмент, но он становится все более распространенным, так как утечки учетных данных пользователей становятся все более частыми. Дополнительная информация по использованию списков запретов и примеры плохих паролей доступны по URL-адресам:
Azure Active Directory Password ProtectionHave I Been Pwned?
Примечание. Необходимо подходить к созданию списка запретов с осторожностью и соблюдать меру. В противном случае существует вероятность сделать перечень настолько всеобъемлющим, что пользователю будет очень сложно подобрать правильный пароль.
Итоговая рекомендация:
5.1.5. Блокировка сеанса при бездействии
Блокировка сеанса при бездействии является разумной мерой предосторожности.
Нет никакой пользы в том, чтобы система или сеанс оставались активными, когда пользователь не работает. Узнать, когда пользователь активен, можно с помощью обнаружения пользовательского ввода (ввод с клавиатуры, движение мыши и т.д.).
Примечание. Вход в систему после такой блокировки должен соответствовать всем рекомендациям, применяемым для обычной аутентификации. Неудачные попытки входа должны также отслеживаться и ограничиваться (см. раздел 5.1.6 Ограничение неудачных попыток входа (блокировка)). Способ авторизации для учетной записи, заблокированной во время бездействия пользователя, должен быть того же типа, что и при обычной процедуре входа, без какого-либо упрощения. То есть учетная запись, для которой настроена МФА, в случае блокировки также должная быть авторизована с МФА, а не с применением сокращенного метода аутентификации, вроде пароля.
Итоговая рекомендация:
5.1.6. Ограничение неудачных попыток входа (блокировка)
Чтобы ограничить возможность угадывания пароля, временно блокируйте учетную запись после заранее определенного количества неудачных попыток входа.
Условимся не рассматривать ситуации, когда злоумышленник получает пароль пользователя в открытом виде с помощью социальной инженерии, ненадежного хранения паролей и т.д., (здесь надежность пароля, по сути, не имеет значения). В таком случае цель создания надежных паролей — не дать злоумышленнику получить доступ к целевой учетной записи или системе в результате недолгого подбора легко угадываемого пароля. «Подбор» означает, что атакующий, прежде чем обнаружить настоящий пароль, должен сделать несколько неудачных попыток авторизации в целевой системе. Именно поэтому принудительное ограничение количества попыток входа для атакующего — наиболее важная из всех мер, принимаемых для повышения надежности пароля. Временная (15-минутная) блокировка учетной записи после 5 последовательных неудачных попыток входа в систему доказала свою эффективность в борьбе с попытками перебора и угадывания пароля.
Необходимо помнить, что временная блокировка предназначена для предотвращения несанкционированного доступа, а не для создания дополнительных проблем честным пользователям и администраторам систем каждый раз, когда первые неправильно вводят пароли. Например, длительная блокировка рабочих аккаунтов (снятие которой возможно только при участии администратора) в крупной компании, действующей в нескольких часовых поясах, скорее всего, создаст больше лишних сложностей, чем принесёт пользы. В отдельных случаях разумной альтернативой может стать установка определенного количества временных блокировок, при превышении которого будет производиться уже постоянная блокировка аккаунта, требующая участия администратора для отмены (рекомендуемое значение — 10 неудачных попыток подряд).
Другая техника, набирающая популярность, – это замедление входа (login throttling), при котором каждая неудача постепенно увеличивает задержку перед следующей попыткой входа в систему.
Схемы замедления могут быть разными, но обычно они выглядят так:
✧ первая неудача, немедленная повторная попытка разрешена;
✧ вторая последовательная неудача, одна минута ожидания;
✧ двукратное увеличение времени ожидания при каждой следующей неудачной попытке;
✧ при достижении предельного значения попыток — постоянная блокировка учетной записи (требуется участие ИТ-специалистов).
Замедление входа ограничивает количество попыток угадывания, которые может предпринять злоумышленник, одновременно предоставляя пользователям несколько возможностей вспомнить свой пароль. Этот метод не так распространен в современных системах, как блокировка учетной записи по количеству неудачных попыток, но он набирает популярность в системах, работающих через Интернет. Оба метода обеспечивают хороший баланс между безопасностью, удобством использования и снижением нагрузки на работников ИТ-служб.
Примечание. Независимо от метода, используемого для ограничения неудачных попыток входа в систему, параллельно в целях безопасности должны быть настроены функции мониторинга и оповещения (см п 5.1.7 «Мониторинг неудачных попыток входа в систему»).
Примечание. Ограничение неудачных попыток входа не предотвращает компрометацию пароля с помощью методов Password Spraying (т.е. использование одного и того же пароля для многих различных учетных записей пользователей). Напротив, оно стимулирует злоумышленников использовать эту технику, чтобы избежать блокировки, что является очевидной аномалией и может быть обнаружено с помощью систем мониторинга.
Итоговая рекомендация:
5.1.7. Мониторинг неудачных попыток входа в систему
Контроль входа в систему – обязательное условие (ключевая рекомендация).
Цель создания надежных паролей – предотвратить получение неавторизованными пользователями (в частности, злоумышленниками) доступа к системам или учетным записям. В свою очередь, ведение журнала авторизации является ключевым компонентом анализа попыток получения доступа к учетной записи, будь то аккаунт обычного пользователя или администратора. Необходимо как минимум отслеживать в журнале неудачные попытки входа в систему и оповещать о них ответственный персонал.
Для обеспечения контроля неудачных попыток входа в систему предлагается следующее:
✧ регистрировать все неудачные попытки входа в систему;
✧ оповещать ответственный персонал о фактах временной или постоянной блокировки учетных записей;
✧ регистрировать попытки входа в систему из неожиданных географических зон и оповещать о них ответственный персонал;
✧ регистрировать попытки входа в систему в необычное время и оповещать о них ответственный персонал;
✧ регистрировать попытки авторизации от имени специальных сигнальных учетных записей (записи-приманки для злоумышленников, “Honeypot”) и оповещать о них ответственный
персонал.
Примечание. Мониторинг может принимать различные формы в зависимости от типа системы. Системы, подключенные к одному домену/корпоративной сети, могут контролироваться централизованно с помощью системы управления событиями безопасности (SIEM), которая объединяет и контролирует журналы событий из различных систем. Автономные системы (например, устройства Интернета вещей) могут использовать что-то элементарное, например, электронное письмо или SMS-сообщение, чтобы сообщить пользователю о превышении лимита попыток авторизации. Конечная цель состоит в том, чтобы при неудачных попытках входа в систему связаться с нужным человеком.
Итоговая рекомендация:
5.1.8. Блокирование учетной записи при неиспользовании
Неиспользуемые учетные записи должны автоматически отключаться.
Было бы идеально, если бы администраторы немедленно отключали неактивные учетные записи людей, потерявших право доступа в систему (ушедших из компании, сменивших отдел и т.д.). К сожалению, так бывает не всегда, поэтому разумно иметь техническое решение на случай, если ручной блокировки не произойдет: резервным планом может стать автоматическая приостановка учетной записи после X дней неиспользования (мы рекомендуем 45 дней).
Если пользователь не авторизовался в учетной записи в течение 45 дней с последнего успешного входа, система автоматически отключит ее. Пользователь может ее разблокировать, но для этого ему необходимо связаться с ИТ-отделом для восстановления учетной записи и обосновать, почему она по-прежнему необходима.
Итоговая рекомендация:
5.1.9. Парольные подсказки
Не разрешайте парольные подсказки.
В случае, если пользователь забыл свой пароль, подсказка позволяет вспомнить его, решив проблему самостоятельно, без привлечения ИТ-отдела. Но создаваемые риски в данном решении перевешивают всю пользу. Не существует надежного способа убедиться, что подсказка, предоставленная пользователем, не является слишком очевидной и не позволит злоумышленнику легко получить доступ к системе. Более эффективный подход – позволить пользователям создавать легко запоминающиеся пароли (парольные фразы).
Итоговая рекомендация:
5.2. Опциональные рекомендации
Эти рекомендации необязательны, и их можно применять после выполнения основных, приведенных в разделе 5.1. Опциональные рекомендации являются более специфичными и подходят не для всех случаев.
Например, если пользователь использует только один пароль, то необходимость в менеджере паролей отсутствует.
5.2.1. Индикатор надежности пароля при созданииПоказатели надежности полезны, поскольку большинство людей действительно хотят создать надежный пароль.
При создании нового пароля система должна помочь пользователю и предложить ему руководство, например, индикатор надежности пароля. Особенно полезно включать в индикатор «черные» списки – тогда пользователь сможет создать надежный пароль, не попадающий в список запретных слов.
Итоговая рекомендация:
5.2.2. Отображение пароля
Существует два основных случая отображения паролей.
5.2.2.1. При создании пароляВозможность отображения пароля при его создании предпочтительнее, чем требование повторного слепого ввода
Чтобы помочь пользователю в создании пароля, система должна предложить возможность его полного отображения (без скрытия с использованием точек или звездочек). Это позволит пользователю проверить свой ввод, если обстановка позволяет безопасно отобразить его на экране. Данная возможность работает гораздо лучше, чем дублирование ввода пароля вслепую для исключения ошибок.
5.2.2.2. При введении пароляПредоставление пользователю возможности на краткое время увидеть то, что он вводит в поле пароля, снижает количество ошибок при вводе.
Система должна опционально позволять устройству пользователя отображать отдельные введенные символы в течение короткого времени после ввода каждого символа для проверки правильности ввода (затем заменяя их звездочкой или точкой). Это может быть особенно полезно на мобильных устройствах, где текстовые поля небольшого размера, а текст в них трудноразличим.
Итоговая рекомендация:
5.2.3. Менеджеры паролей
Поощрение использования утвержденного менеджера паролей позволяет пользователям создавать надежные и уникальные для разных систем пароли.
Менеджер паролей похож на записную книжку для паролей пользователя, запертую главным ключом, о котором не знает никто, кроме владельца. На первый взгляд это может показаться неудачной идеей. Что, если кто-то узнает главный пароль пользователя? Это обоснованное опасение. Однако, при условии, что пользователь выбрал надежный, уникальный и запоминающийся основной пароль, который он больше нигде не использует, или, что еще лучше, МФА, менеджеры паролей достаточно эффективны. Как и все остальные инструменты в сфере информационной безопасности, менеджеры паролей не обеспечивают 100% безопасности, но они представляют собой отличную альтернативу для пользователей, которым необходимо управлять несколькими надежными паролями для разных учетных записей. Они позволяют избежать повторного использования одного и того же пароля для нескольких учетных записей, хранения паролей открытым текстом в системе или их записи и хранения в незащищенном месте.
Каждый раз, когда пользователь заходит на сайт или в приложение, он может вызвать менеджер паролей, скопировать свой пароль и вставить его в поле для авторизации. Часто менеджеры паролей предлагают также расширение для браузера, которое может автоматически безопасно заполнить поле сохраненным паролем пользователя.
В организациях желательно использовать один менеджер паролей, так как это облегчит его обслуживание (обновление), отслеживание любых опубликованных уязвимостей и их устранение.
Примечание. Пароли, генерируемые системой и создаваемые менеджером паролей, намного надежнее, чем пароли, создаваемые человеком, поскольку в них используется последовательность символов с большими требованиями к минимальной длине и составу (сложности). Пользователю не нужно запоминать пароль. Вместо этого менеджер паролей хранит их для пользователя.
Примечание. Вход в менеджер паролей должен соответствовать всем рекомендациям обычного входа в систему и правилам, принятым для неудачных попыток входа и мониторинга (см. раздел 5.1.6 Ограничение неудачных попыток входа (блокировка)).
Примечание. Менеджеры паролей предназначены для запоминания всех учетных данных пользователя: и имени пользователя и пароля. Следовательно, помимо сложного пароля пользователь может также создать и сложное уникальное имя пользователя для любой учетной записи. Это делает любые утекшие учетные данные еще менее полезными для злоумышленника, поскольку кроме модификации самого пароля к другой учетной записи ему нужно подобрать еще и имя пользователя. Конечно, это предполагает, что целевая система допускает определенную гибкость в выборе имени пользователя.
Итоговая рекомендация:
5.2.4. Разрешение вставки пароляРазрешите вставку в поле пароля при использовании менеджера паролей.
Системам рекомендуется разрешать пользователям функцию вставки при вводе пароля, поскольку это облегчает применение менеджеров паролей (см. раздел 5.2.3 Менеджеры паролей).
Основное опасение компаний по поводу разрешения данной функции заключается в том, что пароли хранятся в буфере обмена. Действительно, когда пользователь обращается к функции копирования/вставки, скопированное содержимое сохраняется в буфере обмена, откуда его можно вставлять сколько угодно раз. Любое программное обеспечение, установленное на компьютере (или человек, управляющий им), имеет доступ к буферу обмена и может видеть, что было скопировано. Однако большинство менеджеров паролей стирают буфер обмена сразу после вставки пароля, а некоторые вообще обходятся без буфера обмена, вводя пароль с помощью виртуальной клавиатуры. Эти возможности могут быть частью критериев выбора менеджера паролей.
Итоговая рекомендация:
Примечание. Основной смысл заключается в том, что использование менеджера паролей гораздо более безопасно, даже учитывая временное незащищенное хранение копируемых паролей в буфере обмена компьютера.
продолжение - в заключительной, третьей части
Перевод: Аделина Любимова, Origin Security
ссылка на первоисточник