ОУД: как не купить услуги, которые не соответствуют требованиям ЦБ?

Финансовая индустрия России активно цифровизуется, и все ее услуги невероятными темпами переходят в электронный вид. В условиях отсутствия внешнего регулирования некоторые участники этого процесса могли пренебрегать вопросами безопасности для поддержания своего экстенсивного роста. Быстрее сделать доступным новый продукт, быстрее завоевать долю рынка – в условиях жесткой конкуренции это логичная стратегия. Однако она предполагает определенную расстановку приоритетов и жертвование чем-либо. Как правило, жертвовали тем, чего не видно. Тем, что должно присутствовать незримо – безопасностью. При этом создание безопасных сервисов – процесс нетривиальный. Если ранее только некоторые участники финансового рынка осознанно и добровольно делали шаги в этом направлении, то теперь ЦБ РФ определил для всех единые правила игры. Дело в том, что с принятием указанных Положений у кредитных и некредитных финансовых организаций появилась обязанность проводить аудит своего программного обеспечения, распространяемого клиентам или доступного из сети Интернет, на соответствие требованиям безопасности информации.

Таким образом, требования безопасности из разряда желательных были переведены в категорию обязательных. Во время очередной проверки представитель ЦБ обязательно попросит вас рассказать, показать и подтвердить документами, как в вашей организации реализуются требования Положений № 683/684/757 или тех, что придут им на смену.

К слову, аудит программного обеспечения – не единственное требование, содержащееся в этих документах, но в данной статье мы сосредоточимся именно на нем.

ЦБ РФ предлагает два пути решения этой задачи: (1) сертификация в системе ФСТЭК или (2) оценка соответствия по требованиям к оценочному уровню доверия (кратко – ОУД). Это очень разные подходы, сильно различающиеся уровнем временны́х и финансовых затрат, а также гибкостью применения программного обеспечения, прошедшего проверку.

(1) У сертифицированных в системе ФСТЭК продуктов есть особенности, делающие их применение крайне затруднительным (если не невозможным) в постоянно развивающемся, адаптирующемся под требования клиентов финансовом секторе.

Дело в том, что сертифицированные версии программ поставляются с соответствующим сертификатом, формуляром и инструкциями, которые должны исполняться неукоснительно. Каждый файл, входящий в сертифицированную сборку, имеет строго определенную контрольную сумму, закрепленную в документах. Кроме того, программа может иметь ограничения, касающиеся настроек и возможностей. Проще говоря, сертифицированную версию невозможно обновить или перенастроить просто так, когда у вас возникнет необходимость. Как только какой-либо файл изменится, и его контрольная сумма будет расходиться с тем, что указано в формуляре, как только будет активирована или изменена какая-либо функция, закрепленная в документах – сертификация будет утеряна.

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

Помимо этого, для сертификации программы в системе ФСТЭК необходимо обратиться в специализированную аккредитованную организацию – испытательную лабораторию. На момент написания этой статьи таких лабораторий на территории РФ всего 39 штук (https://fstec.ru/normotvorcheskaya/sertifikatsiya/153-sistema-sertifikatsii/588-perechen-ispytatelnykh-laboratorij-n-ross-ru-0001-01bi00). Всего 39 лабораторий на всю огромную страну. Не нам объяснять вам, как ограниченность предложения и слабая конкуренция могут сказываться на ценообразовании и сроках оказания услуг.

И заключительная проблема: ФСТЭК может не принять программное обеспечение на сертификационные испытания, т.к. сертификация в системе ФСТЭК подразумевает сертификацию средств защиты информации. Т.е. финансовое приложение должно являться средством защиты информации, а не прикладным программным продуктом.

(2) А теперь взглянем на второй путь – оценку по требованиям к ОУД. И выглядит он намного проще.

Во-первых, текущая позиция ЦБ РФ такова, что проведенная оценка не налагает непреодолимых запретов на последующее обновление продукта. Вот каким был официальный ответ регулятора на наш запрос о необходимости повторной оценки в случае внесения изменений в код продукта:

Это значит, что при использовании гибких методологий разработки, распространенных в финтехе, и регулярном выпуске небольших последовательных обновлений, объем изменений, который можно назвать существенным, будет накапливаться длительное время. Другими словами, промежуток между оценками по требованиям к ОУД может быть значительным, и все это время результаты оценки будут оставаться действительными. Сравните это с сертификацией во ФСТЭК, когда любое, даже незначительное, изменение автоматически аннулирует сертификат соответствия.

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

Но как обычно у всего есть обратная сторона. Такое обилие поставщиков услуг создает ожидаемые риски: возможность обратиться к недобросовестному исполнителю и получить результат, не соответствующий требованиям регулятора. В чем эта недобросовестность может проявляться?

Оценка – услуга новая, а правоприменительной практики в отношении нее немного. Это плодородная почва для спекуляций на теме трактовки требований нормативных актов.

В Положениях № 683 и № 684 присутствует неудачная формулировка. Согласно п. 4.1 и п. 9 соответственно финансовым организациям предписывается провести «анализ уязвимостей». Дело в том, что анализ уязвимостей – это лишь часть работы, входящей в оценку. Стандарт ГОСТ Р ИСО/МЭК 15408, регламентирующий оценку, определяет множество самых разных видов деятельности, и анализ уязвимостей – лишь один из них. Мало того, это еще и завершающий, финальный вид деятельности, выполнение которого основывается на результатах множества предшествующих шагов. В число этих шагов входят и анализ различной проектной и специализированной документации (вроде «задания по безопасности»), и исследование способов доставки продукта потребителям, и изучение эксплуатационных инструкций, и т.д. Все это необходимо для того, чтобы обеспечить обоснованное доверие к тому, что продукт корректно спроектирован, точно реализован и эксплуатируется безопасным образом. Стандарт весьма однозначен и строг: все виды деятельности взаимосвязаны и обязательны, а финальный анализ уязвимостей систематизирует их результаты и подтверждает или опровергает возможность использования нарушителем выявленных проблем. Сам по себе, в отрыве от других шагов, он попросту невозможен.

Формулировки Положений явно противоречат стандарту, и написано в них не то, что регулятор подразумевал. О чем сам ЦБ РФ и сообщает в своем ответе на наш запрос:

Более того, в свежем Положении № 757 требование было скорректировано, и от финансовых организаций в явном виде требуют проводить полноценную оценку. Такая же корректировка ожидается и в документе, идущем на смену Положению № 683.

Так вот, когда Положения только появились, некоторые подрядчики уцепились за противоречивое требование и самостоятельно без консультаций с регулятором интерпретировали его как разрешение на некорректное, выборочное исполнение стандарта. Таким образом, всеобъемлющую оценку превратили в рядовой пентест, включающий в себя лишь небольшую часть необходимых работ. Зачастую такой пентест покрывает лишь компонент доверия «AVA_VAN.3», однако сам ОУД должен быть намного шире.

Класс доверия	Компоненты доверия AVA_VAN.3 и его зависимости	Компоненты доверия ОУД 4	Компоненты доверия ОУД 4 с учетом профиля защиты Банка России (Таблица 7.3 Профиля)
ADV: Разработка	ADV_ARC.1 Описание архитектуры безопасности	ADV_ARC.1 Описание архитектуры безопасности	ADV_ARC.1 Описание архитектуры безопасности
	ADV_FSP.2 Детализация вопросов безопасности в функциональной спецификации* * с повышением до ADV_FSP.4 Полная функциональная спецификация.	ADV_FSP.4 Полная функциональная спецификация	ADV_FSP.4 Полная функциональная спецификация
	ADV_IMP.1 Представление реализации ФБО	ADV_IMP.1 Представление реализации ФБО	ADV_IMP.2* «Полное отображение представления реализации ФБО
	–	–	ADV_IMP_EXT.3* «Реализация ОО»
	ADV_TDS.3 Базовый модульный проект	ADV_TDS.3 Базовый модульный проект	ADV_TDS.3 Базовый модульный проект
AGD: Руководства	AGD_OPE.1 Руководство пользователя по эксплуатации	AGD_OPE.1 Руководство пользователя по эксплуатации	AGD_OPE.1 Руководство пользователя по эксплуатации
	AGD_PRE.1 Подготовительные процедуры	AGD_PRE.1 Подготовительные процедуры	AGD_PRE.1 Подготовительные процедуры
ALC: Поддержка жизненного цикла	–	ALC_CMC.4 Поддержка производства, процедуры приемки и автоматизации	ALC_CMC.4** Расширенная поддержка
	–	ALC_CMS.4 Охват УК отслеживания проблем	ALC_CMS.4 Охват УК отслеживания проблем
	–	ALC_DEL.1 Процедуры поставки	ALC_DEL.1 Процедуры поставки
	–	ALC_DVS.1 Идентификация мер безопасности	ALC_DVS.1 Идентификация мер безопасности
	–	–	ALC_FLR.2 «Процедуры сообщений о недостатках»
	–	–	ALC_FPU_EXT.1 «Процедуры обновления программного обеспечения»,
	–	ALC_LCD.1 Определенная разработчиком модель жизненного цикла	ALC_LCD.1 Определенная разработчиком модель жизненного цикла
	–	–	ALC_LCD_EXT.3 «Определенные разработчиком сроки поддержки»,
	ALC_ТАТ.1 Полностью определенные инструментальные средства разработки	ALC_TAT.1 Полностью определенные инструментальные средства разработки	АLС_ТАТ.1 Полностью определенные инструментальные средства разработки
ASE: Оценка задания по безопасности	–	ASE_CCL.1 Утверждения о соответствии	ASE_CCL.1 Утверждения о соответствии
	–	ASE_ECD.1 Определение расширенных компонентов	ASE_ECD.1 Определение расширенных компонентов
	–	ASE_INT.1 Введение ЗБ	ASE_INT.1 Введение ЗБ
	–	ASE_OBJ.2 Цели безопасности	ASE_OBJ.2 Цели безопасности
	–	ASE_REQ.2 Производные требования безопасности	ASE_REQ.2 Производные требования безопасности
	–	ASE_SPD.1 Определение проблемы безопасности	ASE_SPD.1 Определение проблемы безопасности
	–	ASE_TSS.1 Краткая спецификация ОО	ASE_TSS.1 Краткая спецификация ОО
ATE: Тестирование	–	ATE_COV.2 Анализ покрытия	ATE_COV.2 Анализ покрытия
	–	ATE_DPT.2 Тестирование: модули обеспечения безопасности	ATE_DPT.2 Тестирование: модули обеспечения безопасности
	–	ATE_FUN.1 Функциональное тестирование	ATE_FUN.1 Функциональное тестирование
	–	ATE_IND.2 Выборочное независимое тестирование	ATE_IND.2 Выборочное независимое тестирование
AVA: Оценка уязвимостей	AVA_VAN.3 Сосредоточенный анализ уязвимостей	AVA_VAN.3 Сосредоточенный анализ уязвимостей	AVA_VAN.5 «Усиленный методический анализ»
	–	–	AVA_CCA_EXT.1 «Анализ скрытых каналов».
Обновление ОО	–	–	AMA_SIA_EXT.3 «Анализ влияния обновлений на безопасность»

Такая махинация позволяет сильно экономить на сроках и стоимости услуги. Но что в итоге получает ее приобретатель? Головную боль и проблемы во время очередной проверки ЦБ. А еще потерю денег из-за необходимости проведения работ повторно и добросовестно.

Положение № 684 уже утратило силу, а 683 – вот-вот утратит. В новых Положениях все формулировки скорректированы и соответствуют изначальному духу оценочного стандарта, и апеллировать к ним не получится. Результаты работы подрядчиков-махинаторов без вариантов будут отвергнуты регулятором.

С таким итогом на руках не получится воспользоваться разрешенным ЦБ РФ длительным промежутком между оценками, потому что оценки по требованиям к ОУД и не было. Это означает новый поиск грамотного исполнителя, новые траты на повторную оценку, ожидание результатов и, возможно, нарушение сроков предписаний регулятора.

Здесь мы скромно отметим, что наши специалисты имеют большой опыт работы со стандартами ГОСТ Р ИСО/МЭК 15408 и ГОСТ Р ИСО/МЭК 18045. Наша работа изначально была выстроена в строгом соответствии с ними, и результаты нашей оценки соответствуют как старым Положениям ЦБ РФ, так и тем, что пришли или придут им на смену.

Мы работаем в тесном контакте с регулятором и все выводы и решения, касающиеся предоставляемых услуг, согласовываем с ЦБ РФ. Кроме того, мы состоим в Техническом комитете по стандартизации № 122 «Стандарты финансовых операций» (https://tk122.ru/) и принимаем непосредственное участие в процессах разработки национальных стандартов финансовых операций, а также адаптации действующих международных стандартов.

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

В следующей статье мы расскажем, как правильно выбрать исполнителя, который выполнит корректную оценку. Приведем примеры технико-коммерческих предложений и покажем, какие параметры следует искать в верном предложении.

Будьте бдительны и обращайтесь только к квалифицированным специалистам, действующим в интересах своих клиентов.

ООО «ИЦ РЕГИОНАЛЬНЫЕ СИСТЕМЫ» - Ваш партнер в индустрии безопасных финансовых технологий.

Авторы: Евдокименко А.А., Умницын М.Ю.