Ну и чтобы уж завершить начатую вчера тему с требованиями ЦБ по обязательной сертификации, покажу еще один фрагмент из проекта ГОСТа, который я упомянул во вчерашней заметке:
Тут все предельно понятно - АБС, мобильный банковское ПО, приложения для ведения брокерской деятельности, ПО страховщиков (в том числе на сайте - для выписки ОСАГО) и др. должно быть сертифицировано на отсутствие уязвимостей по ОУД4 по ГОСТ Р ИСО/МЭК 15408-3. Это то, что прописано в дорожной карте Банка России на 2016-2018 годы.
Позиция ЦБ понятна - разработчики АБС не спешат повышать качество своего ПО с точки зрения безопасности, чем и пользуются злоумышленники. Поэтому ЦБ, уже по традиции, устанавливает требования для своих подопечных, которые должны будут заставить разработчиков прикладного ПО выполнить требования ГОСТа. Такой же фокус был проделан и в 552-П, который обязал перенести функцию электронной подписи из АРМ КБР в АБС.
Правда, с текущим требованием есть ряд отличий. Во-первых, 552-П касалось только банков, а новый ГОСТ распространяется на все финансовые организации. И как будет, например, микрофинансовая организация сертифицировать свое прикладное ПО по "Общим критериям" я представляю с трудом. Во-вторых, согласно ГОСТ Р ИСО/МЭК 15408-3 оценка должна быть внешней и независимой, то есть разработчикам придется дополнительно раскошелиться на приглашение компании, которая займется анализом кода (а у нас их в России раз-два и обчелся). В-третьих, оценка соответствия в "Общих критериях" все-таки проводится не на соответствие ГОСТу, а на соответствие разрабатываемому заданию по безопасности, в котором надо учесть и среду функционирования и модель угроз. А кто будет это ЗБ разрабатывать? Заказчик ПО или его разработчик? Боюсь, что большинство разработчиков этого слова вообще не знают. Но в любом случае цена на ПО вырастет.
С предложенным ЦБ уровнем доверия ОУД4 есть тоже нюансы. Согласно ГОСТу "ОУД4 – самый высокий уровень, на который, вероятно, экономически целесообразно ориентироваться при оценке уже существующих продуктов". При это необходимо с помощью выборочного независимого анализа уязвимостей продемонстрировать противодействие попыткам проникновения нарушителей, обладающим усиленным базовым потенциалом нападения. Базовым?! Но ломающие те же банки нарушителя врядли могут быть отнесены к базовому потенциалу нападения (даже усиленному). А значит и проверки тут нужны более глубокие, то есть ОУД6, а то и ОУД7. Но это уже будет за гранью разумного. И возникает вопрос - обеспечивает ли ОУД4 эффективное противодействие действиям злоумышленников или это просто некоторая золотая середина, которая должна отсечь разработчиков, явно неспособных хотя бы задумываться о безопасности своих творений?
Вот такие вопросы возникают и как на них отвечать, лично я пока не знаю. Писать свои собственные требования, по аналогии с PA DSS, ЦБ, видимо, не готов (много ресурсов нужно). Поэтому он пошел по вот такому пути - отсылкой на существующие требования. И смогут ли их выполнить отечественные разработчики платежных приложений - вопрос открытый.
Тут все предельно понятно - АБС, мобильный банковское ПО, приложения для ведения брокерской деятельности, ПО страховщиков (в том числе на сайте - для выписки ОСАГО) и др. должно быть сертифицировано на отсутствие уязвимостей по ОУД4 по ГОСТ Р ИСО/МЭК 15408-3. Это то, что прописано в дорожной карте Банка России на 2016-2018 годы.
Позиция ЦБ понятна - разработчики АБС не спешат повышать качество своего ПО с точки зрения безопасности, чем и пользуются злоумышленники. Поэтому ЦБ, уже по традиции, устанавливает требования для своих подопечных, которые должны будут заставить разработчиков прикладного ПО выполнить требования ГОСТа. Такой же фокус был проделан и в 552-П, который обязал перенести функцию электронной подписи из АРМ КБР в АБС.
Правда, с текущим требованием есть ряд отличий. Во-первых, 552-П касалось только банков, а новый ГОСТ распространяется на все финансовые организации. И как будет, например, микрофинансовая организация сертифицировать свое прикладное ПО по "Общим критериям" я представляю с трудом. Во-вторых, согласно ГОСТ Р ИСО/МЭК 15408-3 оценка должна быть внешней и независимой, то есть разработчикам придется дополнительно раскошелиться на приглашение компании, которая займется анализом кода (а у нас их в России раз-два и обчелся). В-третьих, оценка соответствия в "Общих критериях" все-таки проводится не на соответствие ГОСТу, а на соответствие разрабатываемому заданию по безопасности, в котором надо учесть и среду функционирования и модель угроз. А кто будет это ЗБ разрабатывать? Заказчик ПО или его разработчик? Боюсь, что большинство разработчиков этого слова вообще не знают. Но в любом случае цена на ПО вырастет.
Требования ОУД4 |
Вот такие вопросы возникают и как на них отвечать, лично я пока не знаю. Писать свои собственные требования, по аналогии с PA DSS, ЦБ, видимо, не готов (много ресурсов нужно). Поэтому он пошел по вот такому пути - отсылкой на существующие требования. И смогут ли их выполнить отечественные разработчики платежных приложений - вопрос открытый.
14 коммент.:
А есть понимание о взглядах ЦБ, которыми должны будут руководствоваться финансовые организации при определении уровня защиты в соответствии с новым ГОСТом?
И еще вопрос, т.к. СТО БР ИББС-1.0-2014 отдельными местами противоречит разрабатываемому ГОСТу, есть ли информация о дальнейшей судьбе СТО БР и соответствующей самооценке?
Алексей, платежные системы не банковского сектора (например, транспорта или оператора связи) так же подпадают под действие нового ГОСТ ЦБ России по ИБ?
Saches: уровень защищенности (я про это писал) за вас определит ЦБ в своих нормативных актах. А вам надо будет только из ГОСТа взять нужные меры защиты.
Saches: Могу предположить, что по мере выхода ГОСТов СТО будет отмирать, а уж оценка соответствия по нему тем более. Сейчас уже готов проект ГОСТа по оценке требованиям ГОСТа с базовыми мерами защиты.
Target: попадают только те, под ЦБ - финансовые организации (страховые, банки, операторы услуг платежной инфраструктуры, микрофинансы, пенсфонды и т.п.)
Алексей, но явно же указан что требуется только оценка уязвимостей по ОУД4, то есть AVA_VLA.3.
Да, сама по себе активность оценщика по AVA_VLA опирается на данные из раздела ADV.
Но всё равно, я бы не называл это полной сертификацией.
Алексей,
Вопрос был о том, есть ли информация какие банки должны будут соответствовать 3-му уровню защиты?
Helgin: AVA_VLA.3 не вижу, вижу AVA_VAN.3 (в версии от 2013-го года). Также вижу ADV_IMP.1, а это означает предоставление исходных кодов.
Saches: а это зависит не от банка, я же писал раньше. От кучи параметров. Внутри одного банка разные системы могут быть разного уровня - от 1-го до 3-го.
Алексей,
Прошу прощение за занудство, но тогда должны быть доступны критерии классификации (например, как в ПП-1119) по которым банк мог бы классифицировать свои системы.
Т.е. мы их ждем от ЦБ и, возможно, из других источников...))
Алексей, как с Вами связаться? Не нахожу ни адреса эл почты, ни Скайпа, ничего.
Подскажите, пожалуйста.
Роман: на главно странице блога куча вариантов для связи
Saches: не будет критериев - это же не самостоятельное решение, как в ПП-1119. ЦБ в своих документах будет устанавливать сам критерии, а вам останется только взять под козырек
Алексей, в ФБ нужно быть в друзьях, чтобы сообщение не попало в папку Другие. В ЛинкедИн то же самое. Твитером не пользуюсь. Может не замечаю чего-то
Я в ФБ мониторю все папки
Я написал вам в ФБ вопрос видите ли Вы моё сообщение, но пока не увидел ответ
Отправить комментарий