РД 17-29
Базовый состав мер по организации управления и организации защиты идентификационных и аутентификационных данных применительно к уровням защиты информации
РД.17 (Т-Т-Т)
Данная мера направлена на защиту управляемости ресурсами доступа в случае конфликтных или непредвиденных обстоятельств с администраторами ресурсов доступа, когда из-за недоступности администратора теряется возможность управления ресурсом доступа, либо доступ к такому упрелению нужен в экстренном режиме, не дожидаясь пристутствия администратора.
При доступе к содержимому эксплуатационный персонал (все, к чьим паролям был осуществлен доступ) должен быть уведомлен о факте доступа.
Для соблюдения конфиденциальности рекомендуется формировать защищенный бумажный носитель аутентификационных данных отдельно для каждого работника из числа эксплуатационного персонала.
В рамках данной меры также рекомендуется обеспечить хранение аутентификационных данных технических учетных записей, учетных записей суперадминистратора (универсального привилегированого субъекта).
Банк России при реализации данной меры не допускает использование сетевых приложений хранения паролейРД.17 (Т-Т-Т)
Запрет на использование технологии аутентификации с сохранением аутентификационных данных в открытом виде в СВТ
Уровень защиты информации 3-Т, 2-Т, 1-Т
Реализация - Т
Аутентификационные данные ресурса доступа при их хранении в базах и файлах ресурса доступа должны быть преобразованы в хэш-значения без возможности восстановления исходного значения. В конфигурационных файлах, база данных или системе управления доступа ресурса доступа не должны сохраняться исходные аутентификационные данные (пароли, пин-коды)
Проверочные процедуры (свидетельства)
Фрагменты конфигурационный файлов ресурсов доступа, где указываются учетные записи, используемые для идентификации и аутентификации. Проверяется, что файлы не содержат паролей в открытом виде.
Анализ методов аутентификации ресурса доступа (например, проверка, что ресурс доступа использует доменную аутентификацию на основе протокола Kerberos).
Выгрузки из баз данных АС фрагментов таблиц, содержащих данные для проверки идентификации и аутентификации субъекта доступа, проверка что в таблице содержатся хэш-значения паролей
Типичные недостатки
Для недостатков
Компенсационные меры
Для мер
Выявленные коллизии
Для коллизий
РД.18 (Т-Т-Т)
Запрет на передачу аутентификационных данных в открытом виде по каналам и линиям связи и их передачу куда-либо, кроме средств или систем аутентификации
Уровень защиты информации 3-Т, 2-Т, 1-Т
Пояснение
Для пояснения
Реализация - Т
Мера реализовывается путём запрета на использования протоколов, передающих учётные данные в открытом виде.
Пример таких протоколов: Telnet, LDAP, HTTP, FTP
Мера реализовывается запретом на техническую реализации передачи учетных данных данных куда-либо, например в системы логирования или в тех случаях, когда используется некое передаточное звено, не относящееся к системе аутентификации
Рекомендации по использованию протоколов:
- Telnet – запретить к использованию или использовать альтернативу в виде SSH
- LDAP – перейти на использование LDAPS
- HTTP – перейти к использованию HTTPS
- FTP – перейти к использованию FTPS
- POP3 - перейти на POP3S
- SMTP - перейти на SMTPS
- IMAP - перейти на IMAPS
Проверочные процедуры (свидетельства)
Проверяется, что в инфраструктуре не используются протоколы с ооткрытой передачей аутентификационных данных.
Проверяется, не используются ли в процессе обработки информации какие-либо разработки или системы с передачей аутентификационных данных в открытом виде (командных файлов, bat-файлов, промежуточных сервисов, систем управления задачами)
Типичные недостатки
Регистрация в системе управления задачами первичного задания при первичной регистрации учетной записи и выдачи пароля в открытом виде для первичной аутентификации формально является процессом передачи аутентификационных данных в открытом виде и процессом передачи аутентификации данных в систему, не предназначенную для аутентификации, что нарушает меру РД.18
Компенсационные меры
Для мер
Выявленные коллизии
Для коллизий
РД.19 (Т-Т-Т)
Смена паролей пользователей не реже одного раза в год.
Уровень защиты информации 3-Т, 2-Т, 1-Т.
Пояснение
Для пояснения
Реализация - Т
Для контроллера домена ОС семейства Windows
Указание параметра Максимальный срок действия пароля (Maximum password age) = 365 для профиля пользователей.
Указание параметра PASSWORD_LIFE_TIME = 365 для профилей пользователей.
Для семейства CentOS.
Контроль срока действия пароля и его длины осуществляется при помощи файла /etc/login.defs.
PASS_MAX_DAYS – максимальное количество дней действия пароля;
PASS_MIN_DAYS – минимальное количество дней между изменениями пароля;
PASS_MIN_LEN – минимальное количество символов пароля;
PASS_WARN_AGE – количество дней, в течение которых пользователь предупреждается об истечении срока действия пароля.
SQL Server поддерживается использование механизмов политики паролей Windows.
В связи с этим в отношении MS SQL Server для систем, использующих СУБД MS SQL, и включающихся в оценку ГОСТ Р 57580.1-2017, рекомендуется использовать windows-authentication.
Для АС:
Реализация функций парольной политики АС, позволяющая затребовать от пользователя обязательной смены пароля по истечению года и блокирующая учетную запись при невыполнении процедуры смены пароля в заданный период времени не более одного года.
Мера должна быть реализована также для клиентов - пользователей систем дистанционного банковского обслуживания.
Проверочные процедуры (свидетельства)
Скриншот парольных политик домена, где для профиля пользователя установлена опция ежегодной смены пароля.
Файл конфигурации парольных политик субъектов доступа для ОС семейства Linux в составе PAM модуля управления парольными политиками, где для пользователей установлена обязанность смены пароля не реже одного раза в год
Выгрузка настроек парольной политики профилей пользователей СУБД Oracle.
Фрагмент файла конфигурации АС, где указаны настройки обязательной смены пароля пользователем до истечения одного года.
Фрагменты из журналов АС, содержащие записи о ежегодной смене пароля пользователем.
Типичные недостатки
Не выявлены.
Компенсационные меры
Не выявлены.
Выявленные коллизии
Не выявлены.
РД.20 (Т-Т-Т)
Смена паролей эксплуатационного персонала не реже одного раза в квартал.
Уровень защиты информации 3-Т, 2-Т, 1-Т.
Пояснение
Для пояснения
Реализация - Т
Для контроллера домена ОС семейства Windows
Указание параметра Максимальный срок действия пароля (Maximum password age) = 90 в настройках парольных политик профиля, выделенного для эксплуатационного персонала.
Указание параметра PASSWORD_LIFE_TIME = 90 для профиля эксплуатационного персонала.
Для семейства CentOS.
Контроль срока действия пароля и его длины осуществляется при помощи файла /etc/login.defs.
PASS_MAX_DAYS – максимальное количество дней действия пароля;
PASS_MIN_DAYS – минимальное количество дней между изменениями пароля;
PASS_MIN_LEN – минимальное количество символов пароля;
PASS_WARN_AGE – количество дней, в течение которых пользователь предупреждается об истечении срока действия пароля.
SQL Server поддерживается использование механизмов политики паролей Windows.
В связи с этим в отношении MS SQL Server для систем, использующих СУБД MS SQL, и включающихся в оценку ГОСТ Р 57580.1-2017, рекомендуется использовать windows-authentication
Для АС:
Реализация функций парольной политики АС, позволяющая затребовать от пользователя обязательной смены пароля по истечению 90 дней и блокирующая учетную запись при невыполнении процедуры смены пароля в заданный период времени не более трех месяцев.
Проверочные процедуры (свидетельства)
Скриншот парольных политик домена, где для профиля эксплуатационного персонала установлена опция ежегодной смены пароля.
Файл конфигурации парольных политик субъектов доступа для ОС семейства Linux в составе PAM модуля управления парольными политиками, где для эксплуатационного персонала установлена обязанность смены пароля не реже одного раза в год.
Выгрузка настроек парольной политики профилей эксплуатационного персонала СУБД Oracle.
Фрагмент файла конфигурации АС, где указаны настройки обязательной смены пароля эксплуатационного персонала до истечения трех месяцев.
Фрагменты из журналов АС, содержащие записи о смене пароля эксплуатационным персоналом каждые три месяца.
Типичные недостатки
В финансовой организации может быть значительное число ресурсов доступа, имеющих учетные записи эксплуатационного персонала, при таких условиях такая частая смена паролей эксплуатационным персоналом может создать проблемы при работе систем.
Компенсационные меры
Не выявлены.
Выявленные коллизии
Не выявлены.
РД.21 (Т-Т-Т)
Использование пользователями паролей длиной не менее восьми символов.
Уровень защиты информации 3-Т, 2-Т, 1-Т.
Пояснение
Для пояснения
Реализация - Т
Для контроллера домена ОС семейства Windows
Указание параметра Минимальная длина пароля (Minimum password length) = 8 в настройках парольных политик профиля, выделенного для пользователей.
Использовать для проверки стойкости пароля функции:
ora12c_verify_function;
ora12c_strong_verify_function.
и две вспомогательные функции complexity_check и string_distance.
Для семейства CentOS.
Контроль срока действия пароля и его длины осуществляется при помощи файла /etc/login.defs.
PASS_MIN_LEN – минимальное количество символов пароля.
SQL Server поддерживается использование механизмов политики паролей Windows.
В связи с этим в отношении MS SQL Server для систем, использующих СУБД MS SQL, и включающихся в оценку ГОСТ Р 57580.1-2017, рекомендуется использовать windows-authentication.
Для АС:
Реализация функций парольной политики АС, позволяющая затребовать от пользователя ввода пароля длиной не менее 8 символов.
Проверочные процедуры (свидетельства)
Скриншот парольных политик домена, где для профиля пользователя установлена опция минимальной длины пароля.
Файл конфигурации парольных политик субъектов доступа для ОС семейства Linux в составе PAM модуля управления парольными политиками, где для учетных записей пользователей установлены параметры минимальной длины пароля.
Фрагмент модуля проверки аутентификации (вызов функций проверки стойкости пароля) в АС, использующих СУБД Oracle.
Фрагмент файла конфигурации АС, где указаны настройки минимальной длины пароля.
Наблюдение за процедурой установки пароля пользователем, попытка установки пароля пользователя менее 8 символов.
Типичные недостатки
Для СУБД Oracle в явном виде нет параметра профиля субъекта доступа, указывающего длину пароля, а вызов функции проверки стойкости пароля может быть не заложен в архитектуру, в том числе о причине использования старой версии СУБД, где не были реализованы функции проверки стойкости пароля, требующие минимальное значение длины пароля в 8 символов.
Компенсационные меры
Не выявлены.
Выявленные коллизии
Не выявлены.
РД.22 (Т-Т-Т)
Использование эксплуатационным персоналом паролей длиной не менее шестнадцати символов.
Уровень защиты информации 3-Т, 2-Т, 1-Т.
Пояснение
Для пояснения
Реализация - Т
Для контроллера домена ОС семейства Windows
Указание параметра Минимальная длина пароля (Minimum password length) = 16 в настройках парольных политик профиля, выделенного для эксплуатационного персонала.
Внимание! Имеется коллизия в реализации. Пояснения даны ниже по тексту
Не реализовано средствами СУБД.
Для семейства CentOS.
Контроль срока действия пароля и его длины осуществляется при помощи файла /etc/login.defs.
PASS_MIN_LEN – минимальное количество символов пароля.
SQL Server поддерживается использование механизмов политики паролей Windows.
В связи с этим в отношении MS SQL Server для систем, использующих СУБД MS SQL, и включающихся в оценку ГОСТ Р 57580.1-2017, рекомендуется использовать windows-authentication.
Проверочные процедуры (свидетельства)
Реализация функций парольной политики АС, позволяющая затребовать от эксплуатационного персонала ввода пароля длиной не менее 16 символов.
Проверочные процедуры (свидетельства)
Скриншот парольных политик домена, где для профиля эксплуатационного персонала установлена опция минимальной длины пароля.
Файл конфигурации парольных политик субъектов доступа для ОС семейства Linux в составе PAM модуля управления парольными политиками, где для учетных записей пользователей установлены параметры минимальной длины пароля.
Фрагмент модуля проверки аутентификации, разработанный специально для проверки минимальной длины пароля эксплуатационного персонала в АС, использующих СУБД Oracle.
Фрагмент файла конфигурации АС, где указаны настройки минимальной длины пароля.
Наблюдение за процедурой установки пароля пользователем, попытка установки пароля пользователя менее 16 символов.
Типичные недостатки
Для большинства ресурсов доступа требование не поддержано на уровне базовых функций парольных политик ресурсов доступа.
Компенсационные меры
Не выявлены.
Выявленные коллизии
Имеется коллизия для ОС семейства Windows. Допущение увеличенного значения минимальной длины пароля (для значения более 11 символов) появилось с момента реализации ОС Windows 7. Опция минимальной длины пароля свыше 11 символов для домена, содержащего WIndows XP, может приводить к нарушению работы системы аутентификации домена.
Для ОС Windows 10 (в отношении локальных учетных записей) компанией-разработчиком указывается гарантированная работа только до значения минимальной длины пароля в 14 символов. Для компенсации этого недостатка рекомендуется дополнительно к указанию минимального значения в 16 символов в параметре минимальной длины пароля включить опцию информирования, если длина установленного пароля менее желаемого в 16 символов. Такие уведомления следует отслеживать через систему мониторинга событиями безопасности.
РД.23 (Т-Т-Т)
Использование при формировании паролей субъектов логического доступа символов, включающих буквы (в верхнем и нижнем регистрах) и цифры
Уровень защиты информации 3-Т, 2-Т, 1-Т
Пояснение
Для пояснения
Реализация - Т
Реализацией требования является настройка соответствующих парольный политик ОС, СУБД, АС, а также включения функционала проверки используемых паролей при их формировании пользователем.
Проверочные процедуры (свидетельства)
Скриншоты парольных политик ресурсов доступа (или систем настройки централизованной аутентификации, конфигурации объектов информатизации), отражающие выполнение требования.
Примерами скриншотов систем могут являться:
1. Настройки парольной политики Active Direcotry;
2. Настройки парольных политик проприетарных АС, используемых в контуре безопасности и имеющих собственную систему аутентификации.
3. Настройки парольных политик для доступа к СЗИ, активного сетевого оборудования, используемого в контуре безопасности.
4. Настройки парольных политик СУБД.
Типичные недостатки
Для недостатков
Компенсационные меры
Для мер
Выявленные коллизии
Для коллизий
РД.24 (Н-О-О)
Запрет использования в качестве паролей субъектов логического доступа легко вычисляемых сочетаний букв и цифр (например, имена, фамилии, наименования, общепринятые сокращения)
Уровень защиты информации 3-Н, 2-О, 1-О
Пояснение
Мера организационная для всех уровней защиты (второго и первого). Однако мера качественно может быть реализована только технически (активацией настроек парольной защиты ресурса доступа при наличии настройки, запрещающей использование простых, легко вычисляемых паролей).
Реализация - О
Данная мера должна быть регламентирована в Положении о парольной защите, Политике парольной защиты, разделе иного документа, посвященного требованиям парольной политики. Должен быть указан запрет использования в качестве паролей легко вычисляемых сочетаний букв и цифр
Проверочные процедуры (свидетельства)
Акты проверки настроек парольной политики.
Заключения по результатам тестирования на проникновение (результатов попытки вычисления пароля по словарям).
Наблюдение за субъектом в процессе его набора пароля (при отсутствии технической возможности установки тербования к паролю для ресурса доступа). Однако такое свидетельство недосотаточно достоверно, так как не гарантирует выполнение меры всеми субъектами и требует смены пароля после наблюдения, так как в результате наблюдения пароль будет скомпрометирован
Типичные недостатки
Для недостатков
Компенсационные меры
Для мер
Выявленные коллизии
Для коллизий
РД.25 (Т-Т-Т)
Обеспечение возможности самостоятельной смены субъектами логического доступа своих паролей
Уровень защиты информации 3-Т, 2-Т, 1-Т
Пояснение
Для пояснения
Реализация - Т
Настройка в ОС, АС, обеспечивающая возможность смены субъектами доступа своих паролей самостоятельно, без привлечения эксплуатационного персонала.
Под субъектами логического доступа стоит понимать следующие:
- пользователи;
- эксплуатационный персонал;
- программные сервисы.
Проверочные процедуры (свидетельства)
1) Скриншоты парольных политик ресурсов доступа (или систем настройки централизованной аутентификации, конфигурации объектов информатизации), отражающие, что субъекты доступа имею право самостоятельно сменить пароль к УЗ и/или протоколы описания процесса смены субъектами логического доступа своих паролей.
2) Скриншоты пунктов меню смены пароля из-под учетной записи пользователя.
3) Наблюдение за фактическим выполнением пользователями действия под протокол аудитора и роспись со стороны участников процесса.
Типичные недостатки
Для недостатков
Компенсационные меры
Для мер
Выявленные коллизии
Для коллизий
РД.26 (О-О-О)
Хранение копий аутентификационных данных эксплуатационного персонала на выделенных МНИ или на бумажных носителях
Уровень защиты информации 3-О, 2-О, 1-О
Пояснение
Данная мера направлена на защиту управляемости ресурсами доступа в случае конфликтных или непредвиденных обстоятельств с администраторами ресурсов доступа, когда из-за недоступности администратора теряется возможность управления ресурсом доступа, либо доступ к такому упрелению нужен в экстренном режиме, не дожидаясь пристутствия администратора.
При доступе к содержимому эксплуатационный персонал (все, к чьим паролям был осуществлен доступ) должен быть уведомлен о факте доступа.
Для соблюдения конфиденциальности рекомендуется формировать защищенный бумажный носитель аутентификационных данных отдельно для каждого работника из числа эксплуатационного персонала.
В рамках данной меры также рекомендуется обеспечить хранение аутентификационных данных технических учетных записей, учетных записей суперадминистратора (универсального привилегированого субъекта).
Банк России при реализации данной меры не допускает использование сетевых приложений хранения паролей
Реализация - О
Данная мера должна быть регламентирована в Положении о парольной защите, Политике парольной защиты, разделе иного документа, посвященного требованиям парольной политики. Должен быть указан порядок записи копий аутентификационных данных на маркированные МНИ или бумажные носители, порядяк защиты от несанкционированного ознакомления, порядок защищенного хранения, порядок актуализации, порядок вскрытия с фиксацией факта вскрытия (кем, в присутствии кого, для каких целей, какой состав аутентификационных данных и кем будет использован). Рекомендуется приказом определить состав лиц, уполномоченных выполнить вскрытие (доступ) носителя с аутентификационными данными
Проверочные процедуры (свидетельства)
Фото выделенного и маркированного для хранения МНИ или конверта с паролями (без демонстрации самих паролей)
Типичные недостатки
Для недостатков
Компенсационные меры
Для мер
Выявленные коллизии
1. Исходный вопрос Ассоциации Банков России звучал как:
"7. Как следует организовать хранение копий аутентификационных данных эксплуатационного персонала (пункт 7.2.2.3 ГОСТ Р 57580.1): на выделенных МНИ или на бумажных носителях? Необходимо хранить связку логин-пароль в таблице (или только логин), ФИО, должность и т.п.? Можно ли хранить данную информацию в зашифрованном виде в сети (например, с помощью ПО «KeePass Password Safe») или это уже будет считаться нарушением?"
2. Ответ Банка России звучал как:
"1.1 Мера по хранению копий аутентификационных данных эксплуатационнного персонала на выделенных машинных носителях информации (МНИ) и на бумажных носителях (РД,26) включена в базовый состав мер по организации управления и организации защиты идентификационных и аутентификационных данных (пункт 7.2.2.3 ГОСТ Р 57580.1-2017).
При реализации меры РД.26 финансовой организации необходимо обеспечить выполнение меры РД.27 по реализации защиты копий аутентификационных данных эксплуатационного персонала от НСД при их хранении на МНИ или бумажных носителях. Набор параметров, формат и способ защиты от НСД хранимых данных финансовая организация определяет самостоятельно, при этом учитывая, что выбранный набор и формат должны обеспечивать возможность восстановления учетных записей эксплуатационного персонала.
1.2 Исходя из содержания меры РД.26, полагаем, что копии аутентификационных данных эксплуатационного персонала подлежат хранению исключительно на выделенных МНИ или на бумажных носителях. Это, в свою очередь, не предполагает размещение таких данных в сети даже в зашифрованном виде."
3. То есть уже на уровне ответа Банк России "полагает", не "требует", не "приказывает", не даже "рекомендует", а "полагает".
4. На уровне п. 7.2.2.1 ГОСТ Р 57580.1-2017 (определяющего в том числе требования к 7.2.2.3) дается ссылка на ГОСТ 50739 1995 года, который в принципе не дает никакой конкретики по поводу такого аспекта защиты "идентификационного и аутентификационного механизма" как хранение паролей, более того, упор стандарта сделан на вопросы мандатного и дискреционного управления доступом, чистку оперативной памяти и прочие штуки аля старый ФСТЭК (Гостехкомиссия) - уже одно это должно вызвать здоровый скепсис по поводу раздела, т.к. многие меры там описанные "подвешены в воздухе" и мало связаны со ссылочным ГОСТ 50739, что не дает возможности нормально арбитража и дает возможность за счет грамотной ведомости применимости обосновать собственную трактовку требования, тем более верную, если она опирается на лучшие практики и мировой опыт.
5. На уровне самих требований РД.17 - РД.29 четко прослеживается стандартная логика, такая же как в PCI DSS или NIST CSF, суть которой проста - "не раскрывай" credentials, а конкретное содержание мер в принципе не похоже на то, как их трактует ЦБ:
"РД.26 Хранение копий аутентификационных данных эксплуатационного персонала
на выделенных МНИ или на бумажных носителях"
РД.27 (О-О-О)
Реализация защиты копий аутентификационных данных эксплуатационного персонала от НСД при их хранении на МНИ или бумажных носителях
Уровень защиты информации 3-О, 2-О, 1-О
Реализация - О
Данная мера должна быть регламентирована в Положении о парольной защите, Политике парольной защиты, разделе иного документа, посвященного требованиям парольной политики. Должен быть указан порядок защищенного хранения, при котором можно однозначно установить факт несанкционированного доступа к аутентификационным данным, а также порядок действий в случае обнаружения несанкционированного доступа
Проверочные процедуры (свидетельства)
Фото свидетельства, как защищается выделенный для хранения аутентификационных данных бумажный носитель с аутентификационными данными (опечатываемый сейф, запечатанный непрозрачный конверт, сейф-пакет). В случае использования МНИ должно быть продемонстировано, как обеспечивается защищенное хранение МНИ с контролем доступа к нему (например, в опечатываемом сейфе, либо МНИ помещен в сейф-пакет)
Типичные недостатки
Для недостатков
Компенсационные меры
Для мер
Выявленные коллизии
Для коллизий
РД.28 (О-О-О)
Регистрация персонификации, выдачи (передачи) и уничтожения персональных технических устройств аутентификации, реализующих многофакторную аутентификацию
Уровень защиты информации 3-О, 2-О, 1-О
Реализация - О
Данная мера должна быть регламентирована в "Политике управления доступом", должен быть определен состав устройств многофакторной аутентификации, порядок их регистрации, присвоения им уникального номера (не всегда такие устройства снабжаются заводским уникальным номером), кому выдаются такие устройства, порядок их периодического контроля, порядок возврата и утилизации устройств. В документе должен быть, в том числе, описан порядок использования таких устройств
Проверочные процедуры (свидетельства)
Реестр (в бумажном или электронном виде), где фиксируется имеющийся состав таких устройств, уникальные номера устройств, состояние устройства, кто получил устройство
Типичные недостатки
Мера не регулирует использование программных решений многофакторной аутентификации, связываемых с мобильным устройством работников организации (например, применение Google Authentifcator и аналого). Между тем такие решения набирают популярность, вытесняя изолированные технические устройства
Компенсационные меры
Для мер
Выявленные коллизии
Для коллизий
РД.29 (О-О-О)
Смена аутентификационных данных в случае их компрометации
Уровень защиты информации 3-О, 2-О, 1-О
Реализация - О
В отношении работников организации и технических учетных записей данная мера должна быть регламентирована в "Политике управления доступом", должен быть определен порядок немедленного уведомления ответственного работника о факте компрометации, срок и порядок первоочередных действий по прекращению возможности использования скомпрометированных аутентификационных данных, порядок выдачи субъекту новых аутентификационных данных (он может предусматривать возобновление доступа только после расследования причин компрометации, или до такого расследования)
В отношении клиентов организации порядок смены аутентификационных данных клиента в случае их компрометации должен быть определен в соглашениях, договорах с клиентами.
В отношении контрагентов организации порядок смены аутентификационных данных сотрудника подрядной организации в случае их компрометации должен быть определен в Соглашении об уровне сервиса (SLA)
Проверочные процедуры (свидетельства)
Набор свидетельств о фактах обращения субъектов (задачи, письма, заявления, записи звонков, скриншоты из социальных сетей и пр) и свидетельства результатов отработки (цепочка процедур в задаче по смене аутентификационных данных, карточка инцидента, журналы регистрации систем)
Типичные недостатки
В настоящее время в отношении систем дистанционного обслуживания применяется практика, при которой смена аутентификационных данных при компрометации должна быть выполнена самим клиентом без обращения в службу поддержки. При этом для смены исползуется мобильное устройство, на котором размещена система, аутентификационные данные передаются в формате push-уведомлений на то же устройство. При перехвате устройства у клиента может не быть возможности запретить смену атунтификационных данных на устройстве. Организация при таком процессе должна определить возможность клиенту заявить по иным каналам устройство как скомпрометированное, после чего технически должна быть заблокирована возможность использования скомпрометированного устройства для смены аутентификационных данных
Компенсационные меры
Для мер
Выявленные коллизии
Для коллизий
Last updated
