Мы используем cookie. Это позволяет нам анализировать взаимодействие посетителей с сайтом и делать его лучше. Продолжая пользоваться сайтом, Вы соглашаетесь с использованием файлов cookie. Тем не менее, Вы всегда можете отключить файлы cookie в настройках Вашего браузера.
Принять

ИБ

Портал для специалистов по информационной безопасности. Новости, нормативная правовая и справочная документация. Шаблоны документов.

  • Главная
  • Новости
  • НПА
    • Стандарты и методики
    • Приказы ФСБ России
    • Приказы ФСТЭК
  • Загрузки
Вы читаете: Требования ЦБ по противодействию мошенническим денежным переводам
Поделиться
Aa

ИБ

Портал для специалистов по информационной безопасности. Новости, нормативная правовая и справочная документация. Шаблоны документов.

Aa
Поиск
  • Главная
  • Новости
  • НПА
    • Стандарты и методики
    • Приказы ФСБ России
    • Приказы ФСТЭК
  • Загрузки
Follow US
ИБ > Информационная безопасность > Требования ЦБ по противодействию мошенническим денежным переводам
Информационная безопасность

Требования ЦБ по противодействию мошенническим денежным переводам

3 года назад Просмотров: 24 3 года назад минут на прочтение: 6
Поделиться

[ad_1]

Внимательно посмотрел положение ЦБ №683-П «Об установлении обязательных для кредитных организаций требований к обеспечению защиты информации при осуществлении банковской деятельности в целях противодействия осуществлению переводов денежных средств без согласия клиента». Больше всего меня интересовали вопросы анализа уязвимостей.

Кредитные организации обязаны выполнять требования ГОСТ Р 57580.1-2017 «Безопасность финансовых (банковских) операций. Защита информации финансовых организаций. Базовый состав организационных и технических мер». При этом значимые кредитные организации должны выполнять требования усиленного (т.е. высшего) уровня, остальные — стандартного (т.е. среднего) уровня. Требования стандарта предъявляются ко всем объектам информационной инфраструктуры, которые участвуют в обработке, передаче и хранении платежной информации. И это, наверное, хорошо. Правда, в стандарте нет требований по защите информации — он содержит просто перечень мер защиты, без детализации требований к ним. Например, стандарт говорит, что кредитная организация должна контролировать отсутствие и обеспечивать оперативное устранение известных уязвимостей (меры защиты ЦЗИ.1 — ЦЗИ.6), для чего нужно применять сканеры уязвимостей к объектам инфраструктуры (меры защиты ЦЗИ.7 — ЦЗИ.10). При этом он ничего не говорит о том, как часто нужно проводить анализ уязвимостей и что понимается под оперативностью их устранения.

OK, добросовестному банку этого достаточно: менеджмент известных уязвимостей уже описан много раз, и как его реализовывать — понятно. Остаются уязвимости нулевого дня — например, те же уязвимости веб-интерфейсов систем ДБО. В соответствии с положением, такие интерфейсы («программное обеспечение, используемое для приема сообщений … в сети Интернет») должно или сертифицироваться в системе сертификации ФСТЭК, или пройти анализ уязвимостей в объеме, соответствующем оценочному уровню доверия ОУД4 ГОСТ 15408-3. Альтернатива «сертифицировать или анализировать уязвимости» появилась еще год назад в положении Банка России 382-П (в редакции указания N 4793-У от 7 мая 2018 г.), и на тот момент логика авторов документа была понятна. Сертификация включает в себя проведение анализа уязвимостей, поэтому в теории подобное требование означало, что банки вынуждены будут так или иначе проводить работу по поиску и анализу уязвимостей нулевого дня в используемом программном обеспечении, при этом ОУД4 задает минимально-приемлемую глубину анализа. К сожалению, только в теории.

Часть 3 ГОСТ 15408 описывает требования к свидетельствам, с помощью которых заявитель доказывает, что его продукт действительно соответствует заявленным требованиям, и действия сертификатора при оценке таких свидетельств. Состав свидетельств и действий по оценке определяется оценочным уровнем доверия, а анализ уязвимостей является одним из действий сертификатора. Когда регулятор говорит, что должен быть проведен анализ уязвимостей в объеме, соответствующем ОУД4, он говорит следующее (за подробностями отсылаю к описанию компонента доверия AVA_VAN.3 ГОСТ 15408-3-2013):

  1. Заявитель должен предоставить на оценку следующие свидетельства:
  • проектную документацию оцениваемого программного компонента (описание архитектуры безопасности и детальное описание реализации функций безопасности);
  • руководства (администратора/пользователя, по инсталляции);
  • исходные коды.
  • Оценщик должен все это посмотреть и каким-то способом поискать уязвимости.
  • ГОСТ ничего не говорит о том, как же именно оценщик должен обнаруживать уязвимости. Несколько лет назад профильный комитет ISO уже пытался стандартизировать хотя бы поиск известных уязвимостей и фаззинг, но на проект документа без слез смотреть было нельзя, и он был благополучно похоронен. Т.е. в альтернативе «анализ уязвимостей» регулятор требует провести его хоть как-то, фактически ставя только два условия: анализ должен проводить лицензиат ФСТЭК и ему должны быть предоставлены исходные коды.

    С альтернативой «сертифицировать» тоже не все просто. Во-первых, в системе сертификации ФСТЭК больше нет сертификации «на отсутствие уязвимостей или недекларированных возможностей». Теперь сертификация — это только оценка соответствия требованиям безопасности (например, техническим условиям, которые разрабатывает сам заявитель), а анализ уязвимостей — просто составная часть работ по сертификации. Во-вторых, ФСТЭК вместо ГОСТ 15408-3 руководствуется своим собственным документом, в котором оценочные уровни доверия определены совсем по-другому. Их шесть, на ОУД6, низшем уровне доверия, проводится лишь анализ архитектурных уязвимостей и фаззинг в режиме черного ящика, в то время как ОУД4 требует проведения полноценных статического и динамического анализа исходных кодов. При этом ни положение 382-П, ни положение 683-П ничего не говорят о том, какой уровень доверия должен быть выбран при сертификации. Ну и в-третьих, сертификация — это длительный процесс, который включает в себя «тройной контроль» (испытательная лаборатория, орган по сертификации и ФСТЭК) и может длиться от года и дольше.

    В итоге требование об анализе уязвимостей нулевого дня получается очень странным. С одной стороны, ЦБ признает крайнюю необходимость поиска и устранения уязвимостей нулевого дня, особенно в самописных фронтэндах систем ДБО. С другой стороны, регулятор тщательно прячется «в домик», точнее, за требования ГОСТ, который на самом деле ничего не требует, и за практику деятельности системы сертификации ФСТЭК.

    Как в этой ситуации поступать банкам? Ну, во-первых, стоит вспомнить о том, что есть рекомендации в области стандартизации РС БР ИББС-2.6-2014 «Обеспечение информационной безопасности организаций банковской системы Российской Федерации. Обеспечение информационной безопасности на стадиях жизненного цикла автоматизированных банковских систем»», где в приложении подробно расписано, что подразумевается под анализом уязвимостей компонентов информационных систем. Во-вторых, можно провести анализ уязвимостей в объеме все того же ОУД4, но только определенного не в ГОСТ 15408, а в «Методике выявления уязвимостей и недекларированных возможностей в программном обеспечении» ФСТЭК. Так как ГОСТ 15408 в действительности не содержит никаких требований к объему и методам анализа уязвимостей, любой из этих двух вариантов будет автоматически соответствовать требованиям этого ГОСТ.

    [ad_2]

    Источник

    Вас может заинтересовать

    Вводятся в действие рекомендации по стандартизации Р 1323565.1.043–2022

    Вступает в действие ГОСТ Р 70262.1-2022

    ИБ для чайника. Часть 1.

    Лабиринт малотавра: Как мы моделируем угрозы. Часть 3: техники и тактики

    Лабиринт малотавра: Как мы моделируем угрозы. Часть 2: негативные последствия, угрозы, техники

    Александр Демидов 11.08.2019
    Предыдущая статья Лабиринт малотавра: Требования к средствам ГосСОПКА
    Следующая статья Повторяемость инцидента при оценке ущерба объектам КИИ
    Комментировать

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

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

    Вас может заинтересовать:

    Вводятся в действие рекомендации по стандартизации Р 1323565.1.043–2022

    4 недели назад

    Вступает в действие ГОСТ Р 70262.1-2022

    4 недели назад

    ИБ для чайника. Часть 1.

    2 года назад

    Лабиринт малотавра: Как мы моделируем угрозы. Часть 3: техники и тактики

    3 года назад

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

    Все данные на сайте представлены для ознакомления и носят исключительно информационный характер. Администрация сайта не несёт ответственность за использование размещённой на сайте информации.

    Сайт не является СМИ.

    Top.Mail.Ru

    © Ассоциация специалистов по информационной безопасности в сфере здравоохранения

    Removed from reading list

    Undo
    Go to mobile version
    С возвращением!

    Авторизуйтесь для продолжения

    Забыли пароль?