Внимательно посмотрел положение ЦБ №683-П "Об установлении обязательных для кредитных организаций требований к обеспечению защиты информации при осуществлении банковской деятельности в целях противодействия осуществлению переводов денежных средств без согласия клиента". Больше всего меня интересовали вопросы анализа уязвимостей.
Кредитные организации обязаны выполнять требования ГОСТ Р 57580.1-2017 "Безопасность финансовых (банковских) операций. Защита информации финансовых организаций. Базовый состав организационных и технических мер". При этом значимые кредитные организации должны выполнять требования усиленного (т.е. высшего) уровня, остальные - стандартного (т.е. среднего) уровня. Требования стандарта предъявляются ко всем объектам информационной инфраструктуры, которые участвуют в обработке, передаче и хранении платежной информации. И это, наверное, хорошо. Правда, в стандарте нет требований по защите информации - он содержит просто перечень мер защиты, без детализации требований к ним. Например, стандарт говорит, что кредитная организация должна контролировать отсутствие и обеспечивать оперативное устранение известных уязвимостей (меры защиты ЦЗИ.1 - ЦЗИ.6), для чего нужно применять сканеры уязвимостей к объектам инфраструктуры (меры защиты ЦЗИ.7 - ЦЗИ.10). При этом он ничего не говорит о том, как часто нужно проводить анализ уязвимостей и что понимается под оперативностью их устранения.
OK, добросовестному банку этого достаточно: менеджмент известных уязвимостей уже описан много раз, и как его реализовывать - понятно. Остаются уязвимости нулевого дня - например, те же уязвимости веб-интерфейсов систем ДБО. В соответствии с положением, такие интерфейсы ("программное обеспечение, используемое для приема сообщений ... в сети Интернет") должно или сертифицироваться в системе сертификации ФСТЭК, или пройти анализ уязвимостей в объеме, соответствующем оценочному уровню доверия ОУД4 ГОСТ 15408-3. Альтернатива "сертифицировать или анализировать уязвимости" появилась еще год назад в положении Банка России 382-П (в редакции указания N 4793-У от 7 мая 2018 г.), и на тот момент логика авторов документа была понятна. Сертификация включает в себя проведение анализа уязвимостей, поэтому в теории подобное требование означало, что банки вынуждены будут так или иначе проводить работу по поиску и анализу уязвимостей нулевого дня в используемом программном обеспечении, при этом ОУД4 задает минимально-приемлемую глубину анализа. К сожалению, только в теории.
Часть 3 ГОСТ 15408 описывает требования к свидетельствам, с помощью которых заявитель доказывает, что его продукт действительно соответствует заявленным требованиям, и действия сертификатора при оценке таких свидетельств. Состав свидетельств и действий по оценке определяется оценочным уровнем доверия, а анализ уязвимостей является одним из действий сертификатора. Когда регулятор говорит, что должен быть проведен анализ уязвимостей в объеме, соответствующем ОУД4, он говорит следующее (за подробностями отсылаю к описанию компонента доверия AVA_VAN.3 ГОСТ 15408-3-2013):
- Заявитель должен предоставить на оценку следующие свидетельства:
- проектную документацию оцениваемого программного компонента (описание архитектуры безопасности и детальное описание реализации функций безопасности);
- руководства (администратора/пользователя, по инсталляции);
- исходные коды.
- Оценщик должен все это посмотреть и каким-то способом поискать уязвимости.
ГОСТ ничего не говорит о том, как же именно оценщик должен обнаруживать уязвимости. Несколько лет назад профильный комитет ISO уже пытался стандартизировать хотя бы поиск известных уязвимостей и фаззинг, но на проект документа без слез смотреть было нельзя, и он был благополучно похоронен. Т.е. в альтернативе "анализ уязвимостей" регулятор требует провести его хоть как-то, фактически ставя только два условия: анализ должен проводить лицензиат ФСТЭК и ему должны быть предоставлены исходные коды.
С альтернативой "сертифицировать" тоже не все просто. Во-первых, в системе сертификации ФСТЭК больше нет сертификации "на отсутствие уязвимостей или недекларированных возможностей". Теперь сертификация - это только оценка соответствия требованиям безопасности (например, техническим условиям, которые разрабатывает сам заявитель), а анализ уязвимостей - просто составная часть работ по сертификации. Во-вторых, ФСТЭК вместо ГОСТ 15408-3 руководствуется своим собственным документом, в котором оценочные уровни доверия определены совсем по-другому. Их шесть, на ОУД6, низшем уровне доверия, проводится лишь анализ архитектурных уязвимостей и фаззинг в режиме черного ящика, в то время как ОУД4 требует проведения полноценных статического и динамического анализа исходных кодов. При этом ни положение 382-П, ни положение 683-П ничего не говорят о том, какой уровень доверия должен быть выбран при сертификации. Ну и в-третьих, сертификация - это длительный процесс, который включает в себя "тройной контроль" (испытательная лаборатория, орган по сертификации и ФСТЭК) и может длиться от года и дольше.
В итоге требование об анализе уязвимостей нулевого дня получается очень странным. С одной стороны, ЦБ признает крайнюю необходимость поиска и устранения уязвимостей нулевого дня, особенно в самописных фронтэндах систем ДБО. С другой стороны, регулятор тщательно прячется "в домик", точнее, за требования ГОСТ, который на самом деле ничего не требует, и за практику деятельности системы сертификации ФСТЭК.
Как в этой ситуации поступать банкам? Ну, во-первых, стоит вспомнить о том, что есть рекомендации в области стандартизации РС БР ИББС-2.6-2014 "Обеспечение информационной безопасности организаций банковской системы Российской Федерации. Обеспечение информационной безопасности на стадиях жизненного цикла автоматизированных банковских систем»", где в приложении подробно расписано, что подразумевается под анализом уязвимостей компонентов информационных систем. Во-вторых, можно провести анализ уязвимостей в объеме все того же ОУД4, но только определенного не в ГОСТ 15408, а в "Методике выявления уязвимостей и недекларированных возможностей в программном обеспечении" ФСТЭК. Так как ГОСТ 15408 в действительности не содержит никаких требований к объему и методам анализа уязвимостей, любой из этих двух вариантов будет автоматически соответствовать требованиям этого ГОСТ.