Анализ уязвимостей платежного программного обеспечения по уровню ОУД4

Требование о проведении анализа уязвимостей распространяется на прикладное программное обеспечение автоматизированных систем и приложений, которое используется банками для переводов денежных средств (п. 2.5.5.1 Положения № 382-П). При буквальной трактовке требование распространяется не только на системы ДБО, но и на автоматизированные банковские системы и даже на АРМ КБР-Н.

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

Аналогичные требования для небанковских финансовых организаций содержатся в Положении № 684-П. Анализ уязвимостей по ОУД4 или сертификацию по требованиям ФСТЭК необходимо проводить для ПО, используемого небанковскими финансовыми организациями для взаимодействия с клиентами через интернет: личных кабинетов и веб-сервисов пенсионных и инвестиционных фондов, организаторов торговли, участников рынка ценных бумаг, микрофинансовых организаций, — а также серверной части такого ПО.

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

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

Некоторую ясность вносят ответы Банка России на вопросы банков, НФО, ассоциаций и экспертов по информационной безопасности, но полной ясности пока нет. Большая ясность наступит только с обширной практикой проверок выполнения банками требований к платежному ПО.

Большинство разработчиков систем ДБО в том или ином виде проводили анализ уязвимостей выпускаемых версий своего ПО в рамках цикла безопасной разработки и до вступления в силу новых требований Банка России. Обычно проводился статический и динамический анализ кода новых версий программы без оформления публичных отчетов.

Крупные банки, разрабатывающие системы ДБО самостоятельно, также в основном проводят анализ уязвимостей новых версий ПО, так как имеют необходимые ресурсы.

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

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

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

Для обеспечения анализа уязвимостей по уровню доверия ОУД4 также требуется провести анализ исходного кода программного обеспечения. Если банк разрабатывает систему ДБО самостоятельно, то проблем с предоставлением лаборатории исходных кодов не возникнет. Если же банк использует приобретенную систему ДБО, то обеспечить выполнение новых требований Банка России без участия компании — разработчика системы ДБО не получится.

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

Требования к уровням доверия установлены в ГОСТ Р ИСО/МЭК 15408-3-2013; анализ уязвимостей программного обеспечения — это один из компонентов доверия. Для уровня доверия ОУД4 используется компонент доверия AVA_VAN.3 «Сосредоточенный анализ уязвимостей».

В соответствии с требованиями ГОСТ Р ИСО/МЭК 15408-3-2013 сосредоточенный анализ уязвимостей проводится с зависимостями от других компонентов доверия, в том числе от ADV_ARC.1 «Описание архитектуры безопасности», ADV_IMP.1 «Представление реализации ФБО» и др.

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

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

Необходимый для выполнения требований Положений № 382-П и № 683-П профиль защиты прикладного ПО автоматизированных систем и приложений кредитных организаций и некредитных финансовых организаций во второй половине 2019 г. активно разрабатывался Банком России с привлечением экспертного сообщества из подкомитета № 1 «Безопасность финансовых (банковских) операций» ТК № 122 «Стандарты финансовых операций». Компания «БИФИТ» активно участвовала в разработке профиля защиты в составе рабочей группы при ПК 1 ТК 122.

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

Однако, в ответах банкам и НФО на их запросы Банк России явно указывает на необходимость использования разработанного профиля защиты для проведения анализа уязвимостей по уровню ОУД4 в соответствии с требованиями.

Утвержденная версия профиля защиты содержит 44 функциональных требования безопасности и 30 компонентов доверия.

Причем Банк России усилил требования непосредственно к анализу уязвимостей по сравнению с требованиями компонента доверия AVA_VAN.3 из ГОСТ Р ИСО/МЭК 15408-3-2013.

Согласно профилю защиты, в отношении платежного ПО должен проводиться усиленный методический анализ (AVA_VAN.5), в рамках которого осуществляются:

• статический анализ — выявление типовых уязвимостей, содержащихся в базах данных уязвимостей, и поиск типовых уязвимостей веб-приложений;
• динамический анализ кода;
• тестирование на проникновение.

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

В соответствии с профилем защиты по итогам анализа уязвимостей оформляется отчет, содержащий:

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

В связи с такими изменениями получается, что ранее проводимый разработчиками систем ДБО и некоторыми банками анализ уязвимостей не соответствует тем требованиям, которые Банк России установил в профиле защиты.

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

Банкам, использующим приобретенную систему ДБО, нужно узнать у разработчика системы, приступил ли он к проведению анализа уязвимостей по уровню доверия ОУД4, каковы сроки завершения проекта и финансовые условия предоставления результатов. Если в банке проходит или в ближайшее время намечается внешняя оценка выполнения требований Положения № 382-П или № 683-П (ГОСТ 57580), рекомендуется получить от компании — разработчика системы ДБО гарантийное письмо, подтверждающее, что анализ уязвимостей проводится. Практика проведения внешних оценок банков показывает, что гарантийного письма от разработчика системы ДБО или от испытательной лаборатории достаточно для признания требования частично выполняющимся.

Если банк использует индивидуальную версию покупной системы ДБО или существенно изменил настройки системы, нужно самостоятельно договариваться с испытательной лабораторией о проведении анализа банковского экземпляра системы ДБО. Но при этом у разработчика системы ДБО необходимо получить согласие на предоставление доступа испытательной лаборатории к исходному коду.

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

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