На прошлой неделе прошла конференция, организатором которой стал Банк России, и которая стала выездной сессией Уральского форума, проведенной в Москве. На ней регулятор попробовал ответить на животрепещущие вопросы, касающиеся как ЕБС, так и недавно выпущенных, но уже вызвавших немало вопросов нормативных актов (683-П, 684-П и т.п.). Параллельно с этим, как член ПК1 ТК122 я собрал с отрасли около 50 вопросов, которые были направлены в Департамент ИБ Банка России с целью получения ответов на них. И вот часть таких ответов прозвучала на конференции. Позволю себе тезисно озвучить то, что было озвучено.
Перспективы и планы
Конференция не была ориентирована на озвучивание планов по новым нормативным актам, но на одном из слайдов были приведены направления деятельности ДИБ, из которых становится понятно, в каком направлении ждать и новых нормативных актов. Как минимум, сейчас пишется нормативка под финансовый маркетплейс, блокчейн, цифровой профиль и Open. API.
Единая биометрическая система
- Банк России опросил 38 банков, 7 из которых планируют делать свои собственные решения для подключения к ЕБС. Остальные хотят использовать типовое решение, самых распространенных сейчас четыре - от Ростелекома, Инфотекса, ЦФТ и IDSystems.
- Стоимость облачного решения Ростелекома - около 3 миллионов рублей в год. Стоимость типового решения - 5 миллионов (включая инфраструктуру построения, HSM, антивирусы и т.п.).
- Типовое решение уже включает тематические исследования и финансовым организациям проводить их не требуется.
- Покупка типового решения не отменяет выполнения методички Банка России МР-4.
- По словам ЦБ, ряд разработчиков типовых решений делают только сбор биометрии, без предоставления функции верификации, что неправильно по мнению регулятора.
- Стоимость собственной разработки (в качестве примера был приглашен Тинькофф) обходится примерно в те же 5 миллионов. Но это все без резервирования тех HSM. С резервированием - стоимость увеличивается еще примерно на 3-4 миллиона. Длительность создания собственного решения у Тинькофф составила 4-5 месяцев без тематических исследований.
- Обсуждалась тема мобильного сбора биометрии, для которой максимальный возможный класс сертификации СКЗИ озвучивался как КС2. Готовых решений пока нет, но Ростелеком работает над ним. При этом вопрос качества собранной биометрии с помощью планшета или смартфона не обсуждался совсем.
- Для удаленного сбора должны применяться только СКЗИ КС3 или КС2 но с соблюдением. требований к СВТ 4-го класса. Пока обойти эти требования или снизить нельзя.
683-П / 684-П / 672-П
- Планируется кардинальное изменение 382-П, из которого уберут упоминание кредитных организаций (операторов по переводу денежных средств). 382-П будет распространяться на участников НПС - некредитные организации, а также на новые сущности, введенные последними правками в 161-ФЗ - платежные агрегаторы, разработчики платежных приложений, операторы информационного обмена (SWIFT, привет!). Защита информации при осуществлении переводов денежных средств уйдут целиком под 683-П, который покрывает все банковские операции.
- ЦБ считает, что анализ уязвимостей можно проводить своими силами, если есть для этого возможности, навыки и квалификация. Но пока непонятно, как отсекать некачественно проведенную оценку. ЦБ думает над этим.
- На вопрос о том, что является доказательством проведения анализа уязвимостей, если это делает производитель платежного ПО или привлекаемый лицензиат, ЦБ подготовит разъяснение. Надо внимательно посмотреть ГОСТ 15408 в части представления результатов оценки.
- В августе ЦБ разослал письмо по кредитным организациям, в котором говорится, что с учетом принятия ГОСТ 57580.1/57580.2 и 683-П, направлять оценку по СТО БР ИББС 1.2-2014 больше не требуется. Ее проведение остается на усмотрение кредитной организации. Когда кредитные организации выведут и из под 382-П, то у них останется единственная оценка соответствия - по ГОСТу. Надзор ЦБ больше не будет руководствоваться СТО БР при проведении своих мероприятий.
- 202-я форма будет пересмотрена.
- Документ по операционным рискам (с резервирование капитала и прочим блэкджеком) будет очень плотно завязан на новый ГОСТ по управлению киберрисками, который сейчас активно пишется и в октябре будет представлен членам ПК1 ТК122. Так что можно ожидать, что до конца года положение по операционным рискам будет все-таки принято.
- На вопрос о том, почему 683-П и 684-П местами так отличаются друг от друга, прозвучало, что хоть они и писались ДИБом, но затем сильно перерабатывались соответствующими - департаментами банковским и НФО.
- Несмотря на то, что в 684-П прямо не упомянуты (при установлении уровней защиты) микрофинансовые организации, ломбарды и ряд иных, на них распространяются общие требования, прописанные в 684-П (защита от вредоносного кода, уведомление клиентов о рисках и т.п.).
- Если кредитная организация ведет депозитарную и репозитарную деятельность, то применять необходимо и 684-П, даже несмотря на то, что у него сфера деятельности - некредитные финансовые организации. Но, учитывая, что кредитные организации обязаны также выполнять и 683-П, то при пересечении требований выполняться должны те, которые жестче, то есть, по сути, 683-П.
- По поводу SMS и Push ЦБ считает, что не обязательно применять УКЭП. Можно использовать и другие меры подтверждения целостности без УКЭП. Сейчас завершается подготовка информационного письма для этого.
- Было озвучено, что есть правовые проблемы с использованием облачным провайдером ЭП банка (ключи нельзя передавать третьим лицам). ЦБ вроде как нашел с ФСБ некое решение, но у них есть сомнение в его правомерности. Если в новую редакцию 63-ФЗ внесут "третью доверенную сторону", то проблема разрешится. Пока этот вопрос в серой зоне и каждая кредитная организация решает его для себя самостоятельно.
- ГОСТ допускает применение несертифицированных средств защиты при отсутствии их на рынке (техническая невозможность) или высокой цены (экономическая нецелесообразность). Это и так было понятно, но тут это прозвучало еще раз на прямо заданный вопрос.
- Вновь прозвучала мысль, которая звучит последние лет 10, что ЦБ не интересует КАК будут реализовываться защитные меры и какие конкретные технические решения будут применяться. Финансовые организации сами выбирают способ реализации. Для ЦБ важна оценка уровня риска, для чего ЦБ сейчас внедряет новый риск-ориентированный подход, который будет оценивать каждую организацию по набору показателей.
Перспективы и планы
Конференция не была ориентирована на озвучивание планов по новым нормативным актам, но на одном из слайдов были приведены направления деятельности ДИБ, из которых становится понятно, в каком направлении ждать и новых нормативных актов. Как минимум, сейчас пишется нормативка под финансовый маркетплейс, блокчейн, цифровой профиль и Open. API.
26 коммент.:
Алексей, а вопрос о анализе уязвимостей инфраструктуры тестировании на проникновение не задавали? Кто должен ее делать для банка? Обязательно ли лицензиат?
А какое это имеет значение, если 382-П уже всё. )))
Очевидно, что анализ уязвимостей и ежегодное тестирование на проникновение для объектов информационной инфраструктуры по 382-П можно делать самостоятельно, это явно следует из положений 382-П.
382-П требует лицензиата ФСТЭК только для проведения анализа уязвимостей в прикладном программном обеспечении автоматизированных систем и приложений, это требование можно трактовать или как подмножество объектов информационной инфраструктуры, или как относящееся только к пункту сертификации и анализу уязвимостей на НДВ. Я склонен к последнему варианту, т.к. явно используется тот же термин: прикладное программное обеспечение автоматизированных систем и приложений.
Dnebyshe: тут подход пока не финализирован. Думаю ЦБ в ближайшее время формализует подход к тому, что если у банка есть потенция для самостоятельного пентеста / анализа уязвимостей (например, у Сбера, ВТБ и т.п.), то они и сами могут. А если банк не может, то только лицензиат.
Zuz: 382-П совсем не все. Во-первых, он еще действует. А во-вторых, его не отменят, а просто внесут коррективы и распространят на других участников
Алексей Лукацкий: Конечно, он будет действовать для иных субъектов, но ведь для операторов по переводу денежных средств он будет фактически отменён (в части установленных сейчас обязанностей как операторов по переводу денежных средств). Разве нет? А Dnebyshe - банкир, поэтому в его контексте вопрос не очень актуален (т.е. это требование, про которое он спрашивает скорее всего в текущем виде не нужно будет выполнять).
Кстати, сейчас это всего один из многих показателей 382-П, его всё равно на 100% не реализовать, слишком дорого. Как можно провести оценку уязвимостей и пен-тесты для всех объектов информационной инфраструктуры? Можно только выборочно или применяя обобщения, упрощая (к примеру, анализ уязвимостей заменить сканированием на уязвимости, а пен-тест проводить "общий", но направленный на проникновение на объектов информационной инфраструктуры, не требовать каждый объект тестировать).
Алексей, был ещё важный блок про реюз инфраструктурных затрат, понесённых на построение взаимодействия с ЕБС.
В основном тексте это не отражено явно.
А я уже не помню про что там
ZUZ, как же не актуален? Есть же 683-П, и там так же есть пентесты и анализ уязвимости ИИ.
Сами мы не потянем провести пентест, в полном его понимании, но хочется найти слабые стороны в IT инфраструктуре. А объяснить собственнику зачем тратить миллион на поиск дырок, если это не требует закон не получается, ответ один "Да кому мы нужны, сливать наш корсчет".
Пурга там была, абсолютно бессмысленная. Типа, всё, что банки тратят на биометрию, они смогут использовать и для других задач. Не верю...(с).
Ответил нижн
Dnebyshe: А разве в 683-П у кого-то есть разночтения? п. 3.2 про пен-тесты и анализ уязвимостей в 3-м разделе, касающимся объектов информационной инфраструктуры, которые используются для осуществления переводов денежных средств.
Пункт про требования к лицензиату 4.2. в 4-м разделе про отдельные требования к программному обеспечению, используемое также для осуществления переводов денежных средств.
В 382-П было также, но через абзац, что вызывало разночтения. Тут такого нет. Очевидно, что лицензиат требуется только для анализа уязвимостей в ПО. Причём в конкретном ПО (множество уже чем в 382-П).
Zuz, На семинаре Алексея Лукацкого в Москве по 672-П и 683-П, куда я специально летал из Ростова и платил за это денюшку, Алексей четко сказал, что только лицензиаты, что вызвало у меня замешательство. Вот я его и пытаюсь повторно при людно спросить, не поменял ли он свое мнение.
Dnemyshe: смотрите, какая ситуация. 683-П и 382-П не требуют привлечения лицензиата для проведения тестов на проникновение. Но этого требует п.6.13 ГОСТа, который по 683-П должен быть соблюден наряду с требованиями 683-П. Поэтому мой вывод опирался на совокупность документов, а не только на один из них. Кроме того, само по себе проведение деятельности по тестированию на проникновению - лицензируемый вид деятельности.
Алексей Лукацкий, Dnebyshe:
Алексей, вы более чем многие компетентны в разъяснении в законодательства в области ИБ, участвуете в работе над документами, задаёте тренды, действительно помогаете в работе. Мы с удовольствием посещаем ваши курсы, учимся у вас. Сотни слайдов, на курсах по ПДн и другим направлениям (не говоря о ваших статьях о по СЗИ, к примру на хабре, вычитанных и интересных) говорят о серьёзном аналитическом складе ума, вашей компетенции и удивительной продуктивности и не постесняюсь гениальности.
Но иногда, я вас не понимаю: п 6.13 ГОСТ, действительно требует лицензии на ТЗКИ, но это не означает, что для проведения анализа уязвимостей и пен-тестов объектов информационной инфраструктуры по 683-П требуется привлекать лицензиата ФСТЭК.
Интересно почему вы даёте такой комментарий?! :) Далее вы говорите в этом же комментарии: «683-П и 382-П не требуют привлечения лицензиата для проведения тестов на проникновение» и тут же «кроме того, само по себе проведение деятельности по тестированию на проникновению - лицензируемый вид деятельности». Т.е. по-вашему «регулятор настолько глуп», что не может определить, что тестирование на проникновение является лицензируемым видом деятельности? И не может для этого случая предъявить требования?
Моё мнение было выше. Есть чёткое разделение по объектам требований. Не вижу причин, почему я не могу инициировать тестирование на проникновение для нужд организации без лицензии ФСТЭК. Что сложного в этом процессе, кроме ка наличие компетентных специалистов? На основании чего сделан ваш вывод? Я внимательно прочитал Постановление Правительства и не нашёл там основывай для вашего вывода но понимаю, что я далеко не так опытен и жду пояснений.
Ну скажем так, у меня есть основания так считать, видя общее направление регулирования и планы подготовки нормативных актов. Давайте дождемся ответа ЦБ - тогда будет ясна позиция регулятора.
Если я ошибусь, то признаю свою ошибку
Мне в пятницу пришел официальный ответ из главного ЦБ.
Лицензиат на пентесты и анализ на уязвимость инфраструктуры не нужен.
Только для анализа ПО на ОУД4.
А вообще жать что не нужен, теперь денег на настоящие пентесты не дадут. а сами мы не сделаем.
Опять все закончиться рулоном туалетной бумаги с никому ненужными актами анализа и тестирования.
Предполагает ли нынешнее законодательство сбор данных для ЕБС не банками/кредитными организациями/Ростелекомом, а некими 3-ими организациями, которым тот же Ростелеком это поручит либо без изменения НМД это невозможно?
МФЦ хотят наделить правом это делать еще. Но без изменения НМД это невозможно
Опечатка в заголовке.
А на основании каких НПА запрещается передавать ЭП третьим лицам?
Отправить комментарий