Защита обратной связи при вводе аутентификационной информации что это
Перейти к содержимому

Защита обратной связи при вводе аутентификационной информации что это

  • автор:

ИАФ.5

В информационной системе должна осуществляться защита аутентификационной информации в процессе ее ввода для аутентификации от возможного использования лицами, не имеющими на это полномочий.

Защита обратной связи «система — субъект доступа» в процессе аутентификации обеспечивается исключением отображения для пользователя действительного значения аутентификационной информации и (или) количества вводимых пользователем символов аутентификационной информации. Вводимые символы пароля могут отображаться условными знаками«*», «•» или иными знаками.

Требования к усилению ИАФ.5:

Мера защиты информации Класс защищенности информационной системы
4 3 2 1
ИАФ.5 + + + +
Усиление ИАФ.5

Приказ ФСТЭК России № 21 от 18.02.2013

Состав и содержание мер по обеспечению безопасности персональных данных, необходимых для обеспечения каждого из уровней защищенности персональных данных

ИАФ.5

× Для проведения оценки соответствия по документу войдите в систему.

Список требований

Показывать только требования
Обязательно для уровня защищенности УЗ1 УЗ2 УЗ3 УЗ4

Похожие требования

Framework № PCI DSS 4.0 от 01.03.2022 «Payment Card Industry Data Security Standard»:

8.3.2
Defined Approach Requirements:
Strong cryptography is used to render all authentication factors unreadable during transmission and storage on all system components.

Customized Approach Objective:
Cleartext authentication factors cannot be obtained, derived, or reused from the interception of communications or from stored data.

Defined Approach Testing Procedures:

  • 8.3.2.a Examine vendor documentation and system configuration settings to verify that authentication factors are rendered unreadable with strong cryptography during transmission and storage.
  • 8.3.2.b Examine repositories of authentication factors to verify that they are unreadable during storage. 8.3.2.c Examine data transmissions to verify that authentication factors are unreadable during transmission

Purpose:
Network devices and applications have been known to transmit unencrypted, readable authentication factors (such as passwords and passphrases) across the network and/or store these values without encryption. As a result, a malicious individual can easily intercept this information during transmission using a “sniffer,” or directly access unencrypted authentication factors in files where they are stored, and then use this data to gain unauthorized access.

CIS Critical Security Controls v7.1 (SANS Top 20):

CSC 16.5 CSC 16.5 Encrypt Transmittal of Username and Authentication Credentials
Ensure that all account usernames and authentication credentials are transmitted across networks using encrypted channels.

Framework № PCI DSS 4.0 от 01.03.2022 «Payment Card Industry Data Security Standard (RU)»:

8.3.2
Определенные Требования к Подходу:
Надежная криптография используется для того, чтобы сделать все факторы аутентификации нечитаемыми во время передачи и хранения во всех компонентах системы.

Цель Индивидуального подхода:
Факторы аутентификации открытого текста не могут быть получены, выведены или повторно использованы в результате перехвата сообщений или из сохраненных данных.

Определенные Процедуры Тестирования Подхода:

  • 8.3.2.a Изучите документацию поставщика и параметры конфигурации системы, чтобы убедиться, что факторы аутентификации становятся нечитаемыми с помощью надежной криптографии во время передачи и хранения.
  • 8.3.2.b Проверьте хранилища факторов аутентификации, чтобы убедиться, что они нечитаемы во время хранения. 8.3.2.c Проверяйте передачи данных, чтобы убедиться, что факторы аутентификации нечитаемы во время передачи

Цель:
Известно, что сетевые устройства и приложения передают незашифрованные, читаемые факторы аутентификации (такие как пароли и кодовые фразы) по сети и/или сохраняют эти значения без шифрования. В результате злоумышленник может легко перехватить эту информацию во время передачи с помощью “сниффера” или напрямую получить доступ к незашифрованным факторам аутентификации в файлах, где они хранятся, а затем использовать эти данные для получения несанкционированного доступа.

Приказ ФСТЭК России № 17 от 11.02.2013 «Требования о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах»:

Информационная безопасность

При составлении таблицы выполнения продуктами Код Безопасности мер по обеспечению безопасности персональных данных, у нас с коллегами то и дело разгорались споры по трактовке этих самых мер.

Берем, к примеру, одну из первых мер — ИАФ.2, которая звучит как «Идентификация и аутентификация устройств, в том числе стационарных, мобильных и портативных». Первый же вопрос — что такое мобильные и портативные устройства. Чем мобильные отличаются от портативных? Можем ли мы говорить, что ноутбук — это портативное устройство, а нетбук — мобильное? Никаких критериев и пояснений нет, значит — можем. Ставим уверенный плюс, даже если продукт работает только под Windows.

Идем дальше, ИАФ.5 — «Защита обратной связи при вводе аутентификационной информации», менеджеры продуктов предлагают варианты на перебой — подписывание авторизационного трафика при удаленном доступе, слежение за перехватом Windows API и детектирование кейлогеров при локальном вводе данных, использование токенов с PIN-кодами и так далее. А тут в твиттере выдвигают простое предположение:

И такие примеры можно привести практически по каждому пункту. Что делать интеграторам и разработчикам средств защиты? Моё мнение — трактовать меры по защите по своему усмотрению, по крайней мере, до выхода методических документов ФСТЭК, обещанных нам в конце этого года. Впрочем, правовой статус методических документов еще нужно будет выяснять, вполне возможно, что документы будут носить рекомендательный характер, если их обязательное применение не пропишут в очередном приказе ФСТЭК.

Приказ ФСТЭК России № 17 от 11.02.2013

Требования о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах

ИАФ.5

× Для проведения оценки соответствия по документу войдите в систему.

Список требований

Показывать только требования
Обязательно для класса защищенности К1 К2 К3

Похожие требования

Приказ ФСТЭК России № 21 от 18.02.2013 «Состав и содержание мер по обеспечению безопасности персональных данных, необходимых для обеспечения каждого из уровней защищенности персональных данных»:

ИАФ.5 ИАФ.5 Защита обратной связи при вводе аутентификационной информации
Framework № PCI DSS 4.0 от 01.03.2022 «Payment Card Industry Data Security Standard»:

8.3.2
Defined Approach Requirements:
Strong cryptography is used to render all authentication factors unreadable during transmission and storage on all system components.

Customized Approach Objective:
Cleartext authentication factors cannot be obtained, derived, or reused from the interception of communications or from stored data.

Defined Approach Testing Procedures:

  • 8.3.2.a Examine vendor documentation and system configuration settings to verify that authentication factors are rendered unreadable with strong cryptography during transmission and storage.
  • 8.3.2.b Examine repositories of authentication factors to verify that they are unreadable during storage. 8.3.2.c Examine data transmissions to verify that authentication factors are unreadable during transmission

Purpose:
Network devices and applications have been known to transmit unencrypted, readable authentication factors (such as passwords and passphrases) across the network and/or store these values without encryption. As a result, a malicious individual can easily intercept this information during transmission using a “sniffer,” or directly access unencrypted authentication factors in files where they are stored, and then use this data to gain unauthorized access.

CIS Critical Security Controls v7.1 (SANS Top 20):

CSC 16.5 CSC 16.5 Encrypt Transmittal of Username and Authentication Credentials
Ensure that all account usernames and authentication credentials are transmitted across networks using encrypted channels.

Framework № PCI DSS 4.0 от 01.03.2022 «Payment Card Industry Data Security Standard (RU)»:

8.3.2
Определенные Требования к Подходу:
Надежная криптография используется для того, чтобы сделать все факторы аутентификации нечитаемыми во время передачи и хранения во всех компонентах системы.

Цель Индивидуального подхода:
Факторы аутентификации открытого текста не могут быть получены, выведены или повторно использованы в результате перехвата сообщений или из сохраненных данных.

Определенные Процедуры Тестирования Подхода:

  • 8.3.2.a Изучите документацию поставщика и параметры конфигурации системы, чтобы убедиться, что факторы аутентификации становятся нечитаемыми с помощью надежной криптографии во время передачи и хранения.
  • 8.3.2.b Проверьте хранилища факторов аутентификации, чтобы убедиться, что они нечитаемы во время хранения. 8.3.2.c Проверяйте передачи данных, чтобы убедиться, что факторы аутентификации нечитаемы во время передачи

Цель:
Известно, что сетевые устройства и приложения передают незашифрованные, читаемые факторы аутентификации (такие как пароли и кодовые фразы) по сети и/или сохраняют эти значения без шифрования. В результате злоумышленник может легко перехватить эту информацию во время передачи с помощью “сниффера” или напрямую получить доступ к незашифрованным факторам аутентификации в файлах, где они хранятся, а затем использовать эти данные для получения несанкционированного доступа.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *