Судя по статистике ФСТЭК - межсетевые экраны являются самыми распространенными сертифицированными средствами защиты информации в России - они составляют четверть от общего числа. Поэтому неслучайно, что ФСТЭК решила обновить давно необновляемые (с 97-го года) требования к МСЭ. Приказом №9 от 9 февраля 2016 года были утверждены новые требования к ним, которые начнут применяться с 1-го декабря 2016-го года. Это, пожалуй, первый пример, когда ФСТЭК обновляет (хотя правильнее было бы сказать “переписывает”) ранее выпущенный РД с требованиями к средствам защиты. Пока такой чести не удостоился ни РД на АС (и врядли удостоится), ни РД на СВТ, ни РД на НДВ (а вот это стоит ожидать).
Что обновилось в новом документе? На самом деле все, но я бы выделил несколько ключевых моментов:
На очевидно возникший вопрос о действии уже выданных сертификатов ФСТЭК здраво отмечает, что закон обратной силы не имеет и уже используемые МСЭ можно продолжать использовать - пересертифицировать ничего не надо. Как минимум, до окончания срока действия сертификата. Да и после, если среда и условия функционирования не менялись, - тоже.
Документ ушел на регистрацию в Минюст, а сами профили и типовые методики тестирования, дополняющие данный документ, находятся в финальной стадии разработки (их согласовывать ни с кем не надо).
Что обновилось в новом документе? На самом деле все, но я бы выделил несколько ключевых моментов:
- Число классов защищенности МСЭ стало 3 для гостайны и 3 для обычных информационных систем (вместо 5-ти по прежнему РД на МСЭ). Мотивация такого изменения проста - на 5-й и 1-й классы мало кто сертифицировался (да и на 2-й было всего несколько решений). Да и классов защищенности ГИС и АСУ ТП три и поэтому соотносить их с классами МСЭ гораздо проще.
- Вместо плоской классификации сетевых МСЭ ФСТЭК ввела еще один критерий классификации - тип МСЭ. Выделяется 5 типов - А (уровень сети), Б (уровня логических границ сети), В (уровень узла), Г (уровень Web-сервера) и Д (промышленные МСЭ). Деление между ними достаточно простое, МСЭ типа А - это периметровая железка (только железка). Б - это аппаратный или виртуальный МСЭ, который может стоять только внутри сети. Если вы хотите поставить виртуальный МСЭ на периметре, то на сертификацию надо будет подавать комплекс - виртуальный МСЭ + аппаратная платформа, на которой он работает. Тип В очевидно размещается на защищаемых узлах и по версии ФСТЭК может иметь только программное исполнение. Что делать с МСЭ в сетевых картах не совсем понятно, но таких решений не так уж и много на рынке. Тип Г - это обычные WAF (Web Application Firewall), которые так популярны у отечественных стартаперов (PT WAF, Wallarm, Tempesta FW). Тут ФСТЭК, на мой взгляд, допустила промашку - совершенно выпал из ввиду такой класс МСЭ, как NGFW. Либо именно его надо было делать типом В, либо не выносить WAF в отдельный класс. В принципе, я понимаю мотивацию ФСТЭК, но со стороны это выглядит не совсем логично. Можно попробовать NGFW сертифицировать как МСЭ типа А или Б, но время покажет, насколько это будет адекватно.
- Помните, я писал про проект документа ФСТЭК, который так и не увидел свет, и в котором говорилось о том, что средства защиты должны оцениваться с трех точек зрения - функционал, среда функционирования и требования к разработке (уровни доверия). В новом РД все эти пункты нашли свое отражение. Во первых были усилены основные, функциональные требования к МСЭ.
- Коренным образом были переработаны и расширены требования к доверию. Учитывая, что львиная доля МСЭ на российском рынке разработаны не в России, а эксалация киберугроз все нарастает и нарастает, регулятору ничего не остается как усиливать контроль за процессом разработки, поставки, обновления межсетевого экрана.
- Обратите внимание, что и в данном документе ФСТЭК не смогла пропустить раздел про анализ уязвимостей. Регулятор требует выстроить процесс обнаружения и устранения уязвимостей в подаваемом на сертификацию изделии. Как представитель разработчика самых популярных в мире и России (что доказывает статистика продаж в мире и в России) межсетевых экранов, могу сказать, что уже сейчас при согласовании документов на сертификацию этой теме уделяется огромное внимание и без данного раздела продукт на сертификацию просто не принимается.
- Также не принимается на оценку соответствия МСЭ, для которого не расписана процедура его обновления - устранения уязвимостей, установки патчей, обновления ядра системы защиты и т.п.
Документ ушел на регистрацию в Минюст, а сами профили и типовые методики тестирования, дополняющие данный документ, находятся в финальной стадии разработки (их согласовывать ни с кем не надо).