Чем грозит формальный подход к ОУД 4

Каждый год несколько российских банков лишается лицензии, при этом в среднем с рынка уходит около 10% существующих игроков. Одной из причин, по которой ЦБ РФ может отозвать лицензию у финансовой организации, является отсутствие положительного заключения по оценочному уровню доверия, ОУД 4, показывающего, насколько ПО соответствует требованиям безопасности, описанным в ГОСТ Р ИСО/МЭК 15408-3-2013.

В этой статье мы поговорим о проведении оценки соответствия по ОУД 4 и о рисках формального подхода. Материал будет полезен операторам по переводу денежных средств, банковским платежным агентам, операторам услуг информационного обмена и платежной инфраструктуры, некредитным финансовым организациям, ответственным за безопасность специалистам.

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

Требование по оценке по ОУД 4изложено в нескольких положениях Центрального Банка: № 683-П, № 719-П, № 757-П. В зависимости от области деятельности организации ОУД 4проводится для ПО, обрабатывающего защищаемую информацию, которая также изложена в положениях ЦБ: информация о действиях с денежными средствами, информация об осуществленных финансовых операциях и т.п. Оценка является необходимой составляющей процесса обеспечения защиты, т.к. в рамках нее анализируются архитектура ПО, реализация функций безопасности, уязвимости, что в общем случае позволяет заблаговременно определить проблемы безопасности инфраструктуры в целом. Благодаря этому возможно более качественно реализовать защиту данных в процессе их обработки и, соответственно, минимизировать риски информационной безопасности, связанные с эксплуатацией уязвимостей кода.

Требования законодательства игнорировать не стоит, поскольку ЦБ периодически проверяет финансовые организации. И если обнаружит несоответствие, то примет меры в соответствии со статьями ФЗ:

• Статья 74 № 86-ФЗ гласит, что ЦБ имеет право взыскать штраф с кредитной организации, запретить осуществление определенных банковских операций, потребовать реорганизации активов или руководства или лишить лицензии вовсе;
• Статья 34 № 161-ФЗ: если после того, как нарушитель получил уведомление от ЦБ, он не внес исправления или повторно нарушил, регулятор может исключить его из реестра платежных операторов, наложить административную ответственность и штрафы на кредитную организацию и ее руководителей. Продолжать деятельность после отзыва лицензии является нарушением статьи 171 УК РФ.
  

Кроме того, что проблемы безопасности информационной инфраструктуры или ее недостаточная надежность могут привести к:

• Краже или разглашению конфиденциальной информации клиентов банка;
• Нарушению правил использования компьютерной информации;
  
• Нарушению правил управления техническими средствами, связанными с защитой от угроз, связанных с использованием сети «Интернет».
  

Такие инциденты могут повлечь уголовную ответственность согласно статьям 138, 159, 183, 272-274 УК РФ.

Наконец, если физическим или юридическим лицам причинен ущерб из-за недостатка услуги, это влечет гражданскую ответственность по статье 1095 ГК РФ.

Для прохождения ОУД 4 заявитель должен предоставить оценщику набор следующих исходных данных:

• дистрибутивы программного продукта (включая дистрибутивы ПО, дистрибутивы БД, корневые сертификаты, макросы и т. п.);
• исходные и исполняемые коды программного обеспечения;
  
• тестовый полнофункциональный стенд работы всех сервисов программного обеспечения, наполненный тестовыми данными;
  
• полную эксплуатационную документацию на программный продукт.
  

Соответственно, оценщик проделывает все шаги, обозначенные в ГОСТ 18045, фиксирует их в документации, включающей в себя:

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

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

Порядок проведения Банком России проверок поднадзорных лиц представлен в инструкции «О порядке проведения Банком России проверок надзорных лиц» доступной здесь.

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

В чем здесь подвох? В том, что в дальнейшем при возникновении инцидентов вся тяжесть ответственности ляжет на плечи заказчика. Но ведь нельзя просто так взять и снизить стоимость услуги – нужно чем-то жертвовать. А именно тестирование на проникновение и анализ кода очень затратны по ресурсам, а потому некоторые исполнители просто «выкидывают» их из списка. Следует отметить, что у таких исполнителей вообще могут отсутствовать необходимые для этого вида работ инструменты, стоимость которых начинается от двух миллионов рублей, что влияет на финальный ценник по проектам. Да и одними сканерами не обойтись для проведения тестирования – обязательно нужен квалифицированный специалист. Его зарплата по состоянию на декабрь 2023 года в Москве и Санкт-Петербурге составляла от 180 до 250 тыс. рублей.

Документация оценщика при формальном подходе как правило тоже будет отличаться. В ней не будут отражена выборка функций безопасности из исходных кодов. В основном компании, осуществляющие формальный подход, работают по шаблону (отсюда и высокая скорость). Их технические отчеты как правило не содержат найденных уязвимостей, ведь их никто и не искал. Безопасность ПО в таком случае под большим вопросом.

Не все компании напрямую говорят заказчику о формальном подходе к ОУД 4. Однако, по некоторым признакам можно определить, что ОУД 4 был проведен формально. Вот они:

• Исходные коды объекта оценки не запросили.
• Документ «ADV_IMP Представление реализации функций безопасности объекта оценки» не содержит описание реализации функций безопасности в исходных кодах, и компания, проводящая оценку, просит заполнить этот раздел самостоятельно.
• Название модулей в документе «Базовый модульный проект» не совпадает с названиями модулей в исходных кодах объекта оценки.
• Исполнитель не запрашивает доступ к тестовой среде для проведения пентеста.
• Отчет не содержит информацию о найденных уязвимостях.
• Стоимость работ ниже рынка, сроки проведения работ меньше одного месяца.

При формальном подходе проведения ОУД 4 возможны следующие риски:

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

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

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

1. ИБ_ST Задание по безопасности
2. ADV_ARC Описание архитектуры безопасности
3. ADV_FSP Функциональная спецификация
4. ADV_IMP Представление реализации функций безопасности объекта оценки
5. ADV_TDS Базовый модульный проект
6. AGD_OPE Руководство пользователя по эксплуатации
7. AGD_PRE Руководство по подготовительным процедурам
8. ALC_CMC.4 ALC_CMS.4 Документация по управлению конфигурацией
9. ALC_DEL.1 Процедуры поставки
10. ALC_DVS Документация по безопасности мер разработки
11. ALC_LCD.1 Определенная разработчиком модель жизненного цикла
12. ALC_TAT Инструментальные средства и методы
13. ATE_COV Свидетельство о покрытии тестами
14. ATE_DPT Свидетельство о глубине тестирования
15. ATE_FUN Функциональное тестирование

Нередко оказывается, что у разработчиков нет всех перечисленных в пакете документов. В таких случаях они часто обращаются в сторонние компании для устранения «пробелов». Однако, не все учитывают, что для создания всех входящих в перечень документов необходимо наличие тестовой среды и исходных кодов.

Исходные коды, в частности, нужны для следующих документов:

• ADV_IMP Представление реализации функций безопасности объекта оценки;
• ADV_TDS Базовый модульный проект.

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

Полученные данные можно представить в виде такой таблицы:

• Расположение
• Наименование
• Описание
• Путь к файлу
• Имя_файла.расширение файла
• Описание модуля

В столбце «Расположение» необходимо указать путь к файлу в исходных кодах, реализующий функции безопасности объекта оценки. В «Наименовании» будет имя файла и его расширение. В «Описании» – функции безопасности, которые реализует файл или группа файлов, объединенная в модули. Например, это может быть описание класса, отвечающего за смену пароля или валидатора, выполняющего проверку корректности введенного логина и пароля. Заполнение представленной таблицы без исходных кодов невозможно.

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

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

Когда функции безопасности сформированы по модулям, исходные данные из документа «Представление реализации функций безопасности объекта оценки» используются в документе «Базовый модульный проект». Соответственно, названия этих модулей берутся из исходных кодов. Если же впоследствии выясняется, что есть расхождения в названиях, это может свидетельствовать о формальном подходе к ОУД 4.

Использование сформированных модулей, реализующих функции безопасности объекта оценки, поможет повторно не проходить ОУД 4, если функции объекта оценки не поменялись. Как правило, в техническом отчете оценщик проводит фиксацию контрольных сумм предъявленных ему исходных кодов и дистрибутива.

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

Если исполнитель не запрашивает у вас доступ к тестовой среде, это может также свидетельствовать о формальном подходе к ОУД 4. Конечно, исполнитель может сам развернуть ее, однако, это трудоёмкий процесс, который сложно выполнить без соответствующих навыков.

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

В одном из таких случаев в нашей практике мы обнаружили несоответствия в выборке представления реализации функций безопасности объекта оценки в исходных кодах. В документе «Задание по безопасности» были найдены избыточные функции безопасности объекта оценки, так как оно было шаблонного типа и основывалось на профиле безопасности ЦБ РФ. Он носит рекомендательный характер, но многие заказчики хотят ему соответствовать. Сделать это не так просто – необходимо, чтобы все функциональные требования безопасности были реализованы в ПО (объекте оценки).

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

Прежде, чем приобретать такие документы, необходимо иметь в виду, что они могут быть легко вычислены оценщиком, поскольку похожи друг на друга и имеют одинаковые ошибки. Кроме того, никто не может гарантировать их качества. В процессе также выясняется, что заполнять их не так просто, платить за помощь все равно придется. Так зачем платить несколько раз, если можно сделать это один раз, обратившись к профессионалам?

При выборе исполнителя на разработку документации разработчика и оценки следует обращать внимание на следующие моменты:

• наличие действующей лицензии ФСТЭК России на деятельность по технической защите конфиденциальной информации, предусмотренной подпунктами «б», «д» или «е» пункта 4 Положения о лицензировании деятельности по технической защите конфиденциальной информации, утвержденного постановлением Правительства Российской Федерации №79;
• исполнитель должен иметь опыт в предоставлении аудиторских услуг в отношении ИБ, в проведении тестов на проникновение в отношении системно значимых банков (согласно ЦБ РФ);
• наличие сканеров безопасности.

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

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