Материалы вебинара по реализации требований Центробанка к ИБ в некредитных финансовых организациях.

Согласно п.9 Положения №684 анализу уязвимостей по требованию ОУД (либо сертификации по требованиям ФСТЭК) подлежит следующее программное обеспечение:

• ПО автоматизированных систем и приложений, распространяемых некредитной организацией своим Клиентам для совершения транзакций.
• ПО, обрабатывающего защищаемую информацию (перечень ЗИ в п.1) при приеме электронных сообщений к исполнению в АС и приложениях с использованием Интернет.

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

Но, если Вы распространяете своим Клиентам программное обеспечение для проведения транзакций, разработанное сторонней организацией, то для такого ПО нужно провести либо анализ уязвимостей, либо сертификацию в системе ФСТЭК.

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

• передать исходные коды программного продукта;
• реализовать у себя и задокументировать процесс безопасной разработки;
• разработать документацию на программное обеспечение;
• исправлять выявленные уязвимости в документации и исходном коде;

то успешно пройти анализ уязвимости программного обеспечения у НФО не получится, а Центробанк будет спрашивать именно с НФО, как с финансовой организации, использующей ПО, которая должна выполнять требования законодательства.

В такой ситуации возможны 2 пути:

1. Договориться с разработчиком о предоставлении необходимой документации и информации.
2. Предложить разработчику ПО от своего лица провести анализ уязвимостей к оценочному уровню доверия.

В противном случае использование ПО, не прошедшего анализ уязвимостей к оценочному уровню доверия (ОУД) является прямым нарушение требований Банка России со всеми вытекающими последствиями. Обратите внимание и на то, что даже если разработчик ПО самостоятельно проведет анализ уязвимостей по требованиям ОУД, то Вам в конечном итоге все равно придется провести ОУД повторно (такое требование указано в ГОСТ 15408). Но в данном случае объем работ по ОУД будет существенно меньше. Вам (с привлечением лицензиата) нужно лишь подтвердить отсутствие отличий в ПО и инфраструктуре от той версии, для которой разработчик провел ОУД.

Сроки проведения самого анализа уязвимостей по требованию к оценочному уровню доверия (ОУД) могут достигать – 120-160 рабочих дней в зависимости от объема поверки. Также финансовой организации перед проведением проверки уязвимостей по требованиям ОУД необходимо провести подготовительные работы значительного объема – к примеру, корректировка существующей и разработка недостающей документации.

Подробнее о подготовке к проведению анализа уязвимости по требованиям к ОУД4 можно ознакомиться в нашем материале (ссылка). Там же приведен перечень документов и стандарты, которые нужно учесть при разработке документации. Помимо этого не стоит забывать и о возможной корректировке ПО и документации по результатам проверки. В итоге суммарно длительность работ от начала до получения положительного заключения может составить календарный год. Наиболее логичным выходом из сложившейся ситуации мы видим в оперативном заключением договора с лицензиатом о проведении подобных работ.

Самостоятельно без привлечения разработчика (без разницы – собственный или внешний) провести анализ уязвимостей по требованиям ОУД Вам не получится. Разработчик ПО должен:

• передать исходные коды программного продукта;
• реализовать у себя и задокументировать процесс безопасной разработки;
• разработать документацию на программное обеспечение;
• исправлять выявленные уязвимости в документации и исходном коде.

Также обращаю Ваше внимание на то, что Требование Центробанка о необходимости проведения анализа уязвимостей по требованиям к уровням доверия либо сертификации данного ПО предъявляется непосредственно к финансовым организациям. И вопрос о проведении подобного анализа по требованиям ОУД силами разработчика лежит в плоскости Ваших с ним договоренностей. Обратите внимание и на то, что даже если разработчик ПО самостоятельно проведет анализ уязвимостей по требованиям ОУД, то Вам в конечном итоге все равно формально придется провести ОУД повторно (такое требование указано в ГОСТ 15408). Но в данном случае объем работ по ОУД будет существенно меньше. Вам (с привлечением лицензиата) нужно лишь подтвердить отсутствие отличий в ПО и инфраструктуре от той версии, для которой разработчик провел ОУД.

Исполнения АПКШ «Континента» были нужны для оптимизации процесса сертификации. Сейчас все заказчики получают шестое, наиболее полное исполнение. Класс защиты СКЗИ для обработки ПДн определяется постановлением правительства №1119 и приказом ФСБ №278. В целом, если речь не идет о обработке биометрических персональных данных, рекомендуется использовать СКЗИ класса не ниже КС2.

Сертификация Континент 4 ожидается в первом полугодии 2021 года.

Методика описана в ГОСТ Р 57580.2-2018. По сути, надо взять требования из ГОСТ Р 57580.1, расставить им значения соответствия/не соответствия/частичного соответствия (раздел 8 и 9, далее полученные результаты считаются по формулам из ГОСТ О 57580.2. Но имейте ввиду то, что оценку соответствия может проводить только лицензиат ФСТЭК (п.6.1 Положения 684-П).

Да. В рабочей беседе с представителями ДИБ ЦБ РФ было сказано, что Web-приложения попадают под требования ОУД, если распространяются клиентам и используются для проведения финансовой операции.