О сертификации средств защиты, уязвимостях и отзыве сертификатов

Можно спорить, насколько это правильно или нет, но ФСТЭК работает именно так. А если подумать, то такой подход вполне логичен, так как обнаружить все уязвимости при сертификации невозможно и защищенность продукта характеризуется не числом дыр в нем, а умением производителя устранять их, наличием выстроенного процесса. К сожалению, процесс устранения уязвимостей в продуктах ФСТЭК не оценивает. Да и непонятно вообще как это делать, по каким критериям? Ответом мог бы послужить метод V-RATE, разработанный в институте Карнеги-Меллона еще в конце 90-х годов (я про него писал уже ровно 4 года назад), но за пределами США он как-то не очень распространился; да и не об этом сейчас.

Отсюда, кстати, вытекает и банальная мысль, что если функционал NetScreen соответствует РД на межсетевые экраны, то сертификат продолжает действовать и отозвать его не так просто, как заявляют не очень компетентные в этом вопросе люди. В 199-м приказе Гостехкомиссии всего 5 оснований для отзыва сертификата и наличие уязвимости в сертифицированном продукте к ним не относится. Поэтому в России почти и нет случаев отзыва сертификатов на средства защиты.

Но функциональность — это только одна сторона медали. Помимо функциональности продукта, необходимо учитывать и еще два аспекта — доверие к процессу разработки и среду функционирования, в которой будет эксплуатироваться средство защиты. Про среду функционирования мы сейчас опустим, а вот про доверие поговорим чуть глубже. Мы, как специалисты, прекрасно понимаем, что продукт может обладать заявленными функциями, но при этом содержать еще и недекларированные возможности, нарушающие его защищенность. И пример с Juniper как раз это и иллюстрирует. И вот как раз для таких случаев в 1999-м году ФСТЭК выпустила РД по недокументированным (недекларированным) возможностям. Интересная деталь — он называется «Часть 1». Значит подразумевалась и часть 2, но, увы, за 16 лет никакой второй части так и не появилось. И вот то, что произошло с Juniper могло бы быть обнаружено в рамках сертификации на отсутствие НДВ (с оговорками на происхождение Juniper), но… NetScreen на эту сертификацию не подавался, так как она не является обязательной для МСЭ (исключая тему гостайны). А раз таких требований не предъявлялось, то и проблема в сертифицированном изделии не была выявлена (вопрос, а смогли бы эксперты испытательной лаборатории ФСТЭК это выявить, я оставлю за кадром). Опять к ФСТЭК никаких претензий. В действующем правовом поле, конечно. Потому что вопрос оценки продукции на отсутствие НДВ, на мой взгляд, все-таки должен быть включен в основную для средства защиты сертификацию, но подходить к этому надо дифференцированно, а не только с точки зрения предоставления исходных кодов.

Но очевидно, что проблема-то существует. И в динамично изменяющемся мире вопрос доверия к недоверенным элементам и их производителям становится все более острым. ФСТЭК в 2004-м году к этой теме подступилась, но увы… так и не довела ее до ума. Сейчас она вновь вернулась к этому вопросу, меняя подходы к сертификации, к обновлению сертифицированных решений, к управлению уязвимостями в них, к процессу безопасной разработки. Но процесс этот небыстр и требует ломки не только в самой ФСТЭК, но и во всей отечественной ИБ-отрасли.

Если же вновь вернуться к ситуации с недокументированными возможностями в Juniper, то стоит обратить внимание, что речь идет о VPN-функциональности, которая по российскому законодательству к ФСТЭК никакого отношения не имеет вовсе. Когда-то ФСТЭК пыталась войти в эту реку и даже проекты РД на VPN разработала, но смежники из 8-го Центра ФСБ замкнули все вопросы с VPN все-таки на себя. Поэтому ФСТЭК при сертификации средств защиты с криптографическими подсистемами в них не лезет… а в ФСБ NetScreen не подавался и подаваться не мог в принципе, так как согласно 608-му Постановлению Правительства по обязательной сертификации средств защиты информации, шифровальные средства должны использовать только рекомендованные в ФСБ криптоалгоритмы, а это ГОСТ. Поэтому закладка в Juniper могла и дальше оставаться незамеченной, находясь вне зоны ответственности ФСТЭК и ФСБ.

Это, кстати, демонстрирует еще одну проблему с сертификацией средств защиты в России, — несогласованность действий между регуляторами, имеющими собственные системы оценки соответствия средств защиты. Живут они как кошка с собакой и несмотря на явную необходимость договориться, сделать этого не могут. И это приводит к «забавным» коллизиям. Например, МСЭ с функциями СКЗИ производитель заявляет как имеющий сертификат ФСБ и ФСТЭК одновременно (иногда еще и МинОбороны фигурирует), а на деле оказывается, что в органы по сертификации подавались разные версии продуктов. Одна версия имеет сертификат ФСТЭК, вторая, отличная от первой, — имеет только сертификат ФСБ. И синхронизации между ними при несовпадении сроков сертификации в разных системах сертификации нет.

Вот как-то так…