04.05.2017

Финальная редакция ГОСТа ЦБ по защите информации

Пришла пора сформулировать свои впечатления от последних инициатив ЦБ по части нормотворчества, а таких инициатив по-крупному было две:
  • утвержденная финальная редакция ГОСТа с базовыми защитными мерами для финансовых организаций
  • проект новой редакции 382-П.
Начну с первого документа (в следующей заметке будет обзор поправок в 382-П), который вызвал достаточно бурные обсуждения в апреле, так как он вводит сертификацию используемых финансовыми организациями средств защиты и платежных приложений (тут и тут детальнее), что, мягко говоря, изменяет сложившуюся годами практику и заставит многие компании если не выбросить имеющиемя решения по ИБ на свалку, то сильно потратиться на приведение себя в соответствие, что в условиях и так непростой ситуации с небольшими банками, теряющими лицензии, может еще больше проредить банковские ряды.

К изменениям, которые вошли в финальную редакцию (по сравнению с предыдущей), можно отнести:
  • Распространение действия стандарта еще и на субъектов НПС, а не только на финансовые кредитные и некредитные организации.
  • Включение пункта о возможности формирования нескольких контуров безопасности, для которых и устанавливаются уровни защищенности, определяемые нормативными актами Банка России. На мой взгляд, именно эта тема сейчас вызывает основные вопросы - никто не знает, какие уровни и для кого/чего будут установлены? Я еще недавно был уверен, что эти уровни будут устанавливаться отдельными нормативными актами Банка России, например, 552-П, 382-П, 437-П, 483-П и т.п. Но на заседании ТК122 представитель ЦБ сказал, что будет один нормативный акт (до конца года), который и определит эти уровни для разных типов организаций и платежных процессов. Первый вариант мне казался более логичным, так как второй врядли сможет учесть все возможные ситуации, что потребует регулярного его пересмотра, что не так быстро. Допускаю вариант, что ЦБ пока вообще не думал о форме установления этих уровней защищенности, так как есть более приоритетные задачи, а до принятия ГОСТа еще не далеко.
  • Помимо контроля отсутстви известных (описанных) уязвимостей добавили требование про их оперативное устранение (срок "оперативности" не определен).
  • Стирание информации может быть обеспечено не только средствами гарантированного стирания информации, но и способами (методами), обеспечивающими невозможность их восстановления. О том, что это за методы, могу посоветовать почитать мою заметку 2012-го года, в которой я делал обзор NISTовского стандарта на эту тему.
Наибольшее обсуждение вызвала тема сертификации. В отличие от предыдущей формулировки, которую я приводил в блоге раньше, удалось ее изменить и вернуться к тому, что было определено еще в прошлом году. Сейчас формулировка звучит следующим образом: "применение средств защиты информации, прошедших в установленном порядке процедуру оценки соответствия (в том числе программных (программно-аппаратных) средств, в которых они реализованы, имеющих необходимые функции безопасности) в случаях, когда применение таких средств необходимо для нейтрализации угроз безопасности, определенных в модели угроз и нарушителей безопасности информации финансовой организации". В таблице же требования РЗИ.11-РЗИ.13 стали звучать как "Применение сертифицированных по требованиям безопасности информации средств защиты информации не ниже Х класса**", где примечание (**) звучит как "В случаях, когда применение таких средств необходимо для нейтрализации угроз безопасности, определенных в модели угроз и нарушителей безопасности информации финансовой организации".

По сути повторяется формулировка из 21-го приказа ФСТЭК по защите персональных данных, а мы помним, что ФСТЭК сейчас не требует обязательной сертификации средств защиты для коммерческих организаций. Об этом я писал ровно год назад, приводя ответ ФСТЭК. Об этом говорилось на последней конференции АЗИ. Об этом же сказал представитель ФСТЭК и на заседании в Банке России во время обсуждения ГОСТа, приведя в пример даже крупную финансовую организацию, где эта схема была официально согласована (и это не ЦБ, и не Сбербанк).

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

Все бы ничего, но на заседании одним из участников был задан вопрос, можно ли отказаться от сертификации средств защиты, если, согласно п.6.4 ГОСТа будет признано, что применение сертифицированных решение экономически нецелесообразно? И вот тут началось :-) Представитель ФСБ высказался категорически против такой трактовки, а вот представители ЦБ после долгой дискуссии нехотя согласились с тем, что такая трактовка имеет право на существование и они разделяют ее правомерность. Я тоже считаю, что это вполне логично, так как наличие сертификата ничего не добавляет к защищенности, а только удорожает и так возросшую в требованиях систему защиты информации. Теперь стоит дождаться финального принятия ГОСТа (потребуется ли согласование со стороны ФСБ?) и правоприменительной практики.

Против нового ГОСТа голосовало три человека - я, ФСТЭК и одна крупная финансовая организация. Мотивация у всех, насколько я понял, была разная. Мне не понравилась спешка, в которой принимался стандарт. После жесткой дискуссии на тему сертификации стоило бы зафиксировать текст и разослать его еще раз членам ТК122 на финальное согласование. Я предпочитаю видеть текст, прежде чем соглашаться с ним. В данном же случае текст поправок даже не был озвучен и все соглашались с ними "на веру". Против самого стандарта я ничего против не имею (хотя надо признать - его будет сложно выполнить небольшим банкам). Представитель финансовой организации (не буду называть имя) считал, что требование по сертификации и средств защиты (пусть и в такой дипломатической формулировке) и особенно прикладного ПО на данном этапе избыточно. Его стоило бы включать во второй версии, после апробации самого стандарта на практике. Против самого стандарта он не возражал. А вот ФСТЭК возражала против самого стандарта, считая, что он ничего нового не несет с точки зрения требований по ИБ и по сути повторяет уже существующие приказы ФСТЭК. 6 членов ТК воздержалось, большинство же в едином порыве голосовало "ЗА".

По срокам принятия данного ГОСТа пока сказать нечего. Сроком его введения в действие предполагается сделать 1-е января 2018-го года, но это не значит, что к этой дате надо бежать его и выполнять. Срок введения и срок вступления в силу - это, обычно, разные даты и могут быть разнесены на длительные временные периоды. Например, ГОСТ Р 56939-2016 по SDLC был принят 1-го июня 2016-го года, а введен в действие (вступает в силу) - 1-го июня 2017-го года. Что же касается 1-го января 2018-го года, то я пока скептически отношусь к этой дате - не помню случаев, чтобы ГОСТ так быстро проходил через все согласования в Ростехрегулировании. Более реальной я бы назвал дату 1 июня 2018 года. Иными словами сам ГОСТ может стать обязательным с 2019-го года (но это мои предположения).

9 коммент.:

Айдар Замалиев комментирует...

Видимо, предполагается, что к моменту вступления в силу ГОСТа "небольших" банков не должно остаться

timur.aitov комментирует...

Ждём про 382п - про Антифрод и про тестирование :)
Тимур АИТОВ

Алексей Лукацкий комментирует...

Тимур, а что с антифродом не так? Он был еще в прежней версии - в новой ничего не добавилось серьезного. Или речь идет об ограничениях по операциям в случае отсутствия разделения контуров? Так эти ограничения также были в прежней версии для ДБО

Likler Stroyer комментирует...

А в сертфицированных ФСТЭК ciscoвских свичах тоже была CVE-2017-3881 ?

Алексей Лукацкий комментирует...

При наличии договора на получение сертифицированных обновлений с испытательной лабораторией ПО должно было быть обновлено

OksanaVB комментирует...

А на основании чего планируется сделать новый ГОСТ обязательным?

Алексей Лукацкий комментирует...

На основании закона "О стандартизации"

Дмитрий комментирует...

Интересно, а получить проект стандарта до принятия можно?
И где?

Алексей Лукацкий комментирует...

Вступить в члены ТК122