Спустя месяц после назначения в Juniper нового главного безопасника (Security CTO), этот производитель объявил об обнаружении в коде своей операционной системы ScreenOS неавторизованного фрагмента, который позволял злоумышленнику получать административный доступ к средствам сетевой безопасности NetScreen, а также расшифровывать VPN-трафик. В российском Twitter разгорелся некоторый флейм на эту тему, который можно кратко описать несколькими тезисами:
- Это проделки АНБ (сразу становится понятно, кто это заявил - у человека это, видимо, идея-фикс).
- На эту версию выдан сертификат ФСТЭК.
- Система сертификации ФСТЭК - полное гуано, если пропускает такие вещи.
- Надо срочно отзывать сертификат ФСТЭК.
- ФСТЭК активно отзывает сертификаты на средства защиты с уязвимостями (этот бред заявил тот же некомпетентный человек, что и про АНБ все время пишет).
Я вообще небольшой сторонник пока еще действующей концепции сертификации ФСТЭК, но хотелось бы прокомментировать высказанные тезисы, так как они базируются на полном непонимании того, что и как делает ФСТЭК в части оценки соответствия средств защиты.
Во-первых, если посмотреть, что понимается под сертификацией средств защиты информации по требованиям безопасности информации, то согласно 199-му приказу ФСТЭК (тогда еще Гостехкомиссии, как предшественницы ФСТЭК) от 1995-го года (а свежее ничего до сих пор нет), под ней "понимается деятельность по подтверждению характеристик средств защиты информации требованиям государственных стандартов или иных нормативных документов по защите информации, утвержденных Государственной технической комиссией при Президенте Российской Федерации (Гостехкомиссией России)". Иными словами, при сертификации не ищутся уязвимости - она всего лишь подтверждает функционал продукта и его соответствие требованиям регулятора. Все! Ничего больше при сертификации не делается.
Можно спорить, насколько это правильно или нет, но ФСТЭК работает именно так. А если подумать, то такой подход вполне логичен, так как обнаружить все уязвимости при сертификации невозможно и защищенность продукта характеризуется не числом дыр в нем, а умением производителя устранять их, наличием выстроенного процесса. К сожалению, процесс устранения уязвимостей в продуктах ФСТЭК не оценивает. Да и непонятно вообще как это делать, по каким критериям? Ответом мог бы послужить метод V-RATE, разработанный в институте Карнеги-Меллона еще в конце 90-х годов (я про него писал уже ровно 4 года назад), но за пределами США он как-то не очень распространился; да и не об этом сейчас.
Отсюда, кстати, вытекает и банальная мысль, что если функционал NetScreen соответствует РД на межсетевые экраны, то сертификат продолжает действовать и отозвать его не так просто, как заявляют не очень компетентные в этом вопросе люди. В 199-м приказе Гостехкомиссии всего 5 оснований для отзыва сертификата и наличие уязвимости в сертифицированном продукте к ним не относится. Поэтому в России почти и нет случаев отзыва сертификатов на средства защиты.
Но функциональность - это только одна сторона медали. Помимо функциональности продукта, необходимо учитывать и еще два аспекта - доверие к процессу разработки и среду функционирования, в которой будет эксплуатироваться средство защиты. Про среду функционирования мы сейчас опустим, а вот про доверие поговорим чуть глубже. Мы, как специалисты, прекрасно понимаем, что продукт может обладать заявленными функциями, но при этом содержать еще и недекларированные возможности, нарушающие его защищенность. И пример с Juniper как раз это и иллюстрирует. И вот как раз для таких случаев в 1999-м году ФСТЭК выпустила РД по недокументированным (недекларированным) возможностям. Интересная деталь - он называется "Часть 1". Значит подразумевалась и часть 2, но, увы, за 16 лет никакой второй части так и не появилось. И вот то, что произошло с Juniper могло бы быть обнаружено в рамках сертификации на отсутствие НДВ (с оговорками на происхождение Juniper), но... NetScreen на эту сертификацию не подавался, так как она не является обязательной для МСЭ (исключая тему гостайны). А раз таких требований не предъявлялось, то и проблема в сертифицированном изделии не была выявлена (вопрос, а смогли бы эксперты испытательной лаборатории ФСТЭК это выявить, я оставлю за кадром). Опять к ФСТЭК никаких претензий. В действующем правовом поле, конечно. Потому что вопрос оценки продукции на отсутствие НДВ, на мой взгляд, все-таки должен быть включен в основную для средства защиты сертификацию, но подходить к этому надо дифференцированно, а не только с точки зрения предоставления исходных кодов.
Но очевидно, что проблема-то существует. И в динамично изменяющемся мире вопрос доверия к недоверенным элементам и их производителям становится все более острым. ФСТЭК в 2004-м году к этой теме подступилась, но увы... так и не довела ее до ума. Сейчас она вновь вернулась к этому вопросу, меняя подходы к сертификации, к обновлению сертифицированных решений, к управлению уязвимостями в них, к процессу безопасной разработки. Но процесс этот небыстр и требует ломки не только в самой ФСТЭК, но и во всей отечественной ИБ-отрасли.
Если же вновь вернуться к ситуации с недокументированными возможностями в Juniper, то стоит обратить внимание, что речь идет о VPN-функциональности, которая по российскому законодательству к ФСТЭК никакого отношения не имеет вовсе. Когда-то ФСТЭК пыталась войти в эту реку и даже проекты РД на VPN разработала, но смежники из 8-го Центра ФСБ замкнули все вопросы с VPN все-таки на себя. Поэтому ФСТЭК при сертификации средств защиты с криптографическими подсистемами в них не лезет... а в ФСБ NetScreen не подавался и подаваться не мог в принципе, так как согласно 608-му Постановлению Правительства по обязательной сертификации средств защиты информации, шифровальные средства должны использовать только рекомендованные в ФСБ криптоалгоритмы, а это ГОСТ. Поэтому закладка в Juniper могла и дальше оставаться незамеченной, находясь вне зоны ответственности ФСТЭК и ФСБ.
Это, кстати, демонстрирует еще одну проблему с сертификацией средств защиты в России, - несогласованность действий между регуляторами, имеющими собственные системы оценки соответствия средств защиты. Живут они как кошка с собакой и несмотря на явную необходимость договориться, сделать этого не могут. И это приводит к "забавным" коллизиям. Например, МСЭ с функциями СКЗИ производитель заявляет как имеющий сертификат ФСБ и ФСТЭК одновременно (иногда еще и МинОбороны фигурирует), а на деле оказывается, что в органы по сертификации подавались разные версии продуктов. Одна версия имеет сертификат ФСТЭК, вторая, отличная от первой, - имеет только сертификат ФСБ. И синхронизации между ними при несовпадении сроков сертификации в разных системах сертификации нет.
Вот как-то так...
Можно спорить, насколько это правильно или нет, но ФСТЭК работает именно так. А если подумать, то такой подход вполне логичен, так как обнаружить все уязвимости при сертификации невозможно и защищенность продукта характеризуется не числом дыр в нем, а умением производителя устранять их, наличием выстроенного процесса. К сожалению, процесс устранения уязвимостей в продуктах ФСТЭК не оценивает. Да и непонятно вообще как это делать, по каким критериям? Ответом мог бы послужить метод V-RATE, разработанный в институте Карнеги-Меллона еще в конце 90-х годов (я про него писал уже ровно 4 года назад), но за пределами США он как-то не очень распространился; да и не об этом сейчас.
Отсюда, кстати, вытекает и банальная мысль, что если функционал NetScreen соответствует РД на межсетевые экраны, то сертификат продолжает действовать и отозвать его не так просто, как заявляют не очень компетентные в этом вопросе люди. В 199-м приказе Гостехкомиссии всего 5 оснований для отзыва сертификата и наличие уязвимости в сертифицированном продукте к ним не относится. Поэтому в России почти и нет случаев отзыва сертификатов на средства защиты.
Но функциональность - это только одна сторона медали. Помимо функциональности продукта, необходимо учитывать и еще два аспекта - доверие к процессу разработки и среду функционирования, в которой будет эксплуатироваться средство защиты. Про среду функционирования мы сейчас опустим, а вот про доверие поговорим чуть глубже. Мы, как специалисты, прекрасно понимаем, что продукт может обладать заявленными функциями, но при этом содержать еще и недекларированные возможности, нарушающие его защищенность. И пример с Juniper как раз это и иллюстрирует. И вот как раз для таких случаев в 1999-м году ФСТЭК выпустила РД по недокументированным (недекларированным) возможностям. Интересная деталь - он называется "Часть 1". Значит подразумевалась и часть 2, но, увы, за 16 лет никакой второй части так и не появилось. И вот то, что произошло с Juniper могло бы быть обнаружено в рамках сертификации на отсутствие НДВ (с оговорками на происхождение Juniper), но... NetScreen на эту сертификацию не подавался, так как она не является обязательной для МСЭ (исключая тему гостайны). А раз таких требований не предъявлялось, то и проблема в сертифицированном изделии не была выявлена (вопрос, а смогли бы эксперты испытательной лаборатории ФСТЭК это выявить, я оставлю за кадром). Опять к ФСТЭК никаких претензий. В действующем правовом поле, конечно. Потому что вопрос оценки продукции на отсутствие НДВ, на мой взгляд, все-таки должен быть включен в основную для средства защиты сертификацию, но подходить к этому надо дифференцированно, а не только с точки зрения предоставления исходных кодов.
Но очевидно, что проблема-то существует. И в динамично изменяющемся мире вопрос доверия к недоверенным элементам и их производителям становится все более острым. ФСТЭК в 2004-м году к этой теме подступилась, но увы... так и не довела ее до ума. Сейчас она вновь вернулась к этому вопросу, меняя подходы к сертификации, к обновлению сертифицированных решений, к управлению уязвимостями в них, к процессу безопасной разработки. Но процесс этот небыстр и требует ломки не только в самой ФСТЭК, но и во всей отечественной ИБ-отрасли.
Если же вновь вернуться к ситуации с недокументированными возможностями в Juniper, то стоит обратить внимание, что речь идет о VPN-функциональности, которая по российскому законодательству к ФСТЭК никакого отношения не имеет вовсе. Когда-то ФСТЭК пыталась войти в эту реку и даже проекты РД на VPN разработала, но смежники из 8-го Центра ФСБ замкнули все вопросы с VPN все-таки на себя. Поэтому ФСТЭК при сертификации средств защиты с криптографическими подсистемами в них не лезет... а в ФСБ NetScreen не подавался и подаваться не мог в принципе, так как согласно 608-му Постановлению Правительства по обязательной сертификации средств защиты информации, шифровальные средства должны использовать только рекомендованные в ФСБ криптоалгоритмы, а это ГОСТ. Поэтому закладка в Juniper могла и дальше оставаться незамеченной, находясь вне зоны ответственности ФСТЭК и ФСБ.
Это, кстати, демонстрирует еще одну проблему с сертификацией средств защиты в России, - несогласованность действий между регуляторами, имеющими собственные системы оценки соответствия средств защиты. Живут они как кошка с собакой и несмотря на явную необходимость договориться, сделать этого не могут. И это приводит к "забавным" коллизиям. Например, МСЭ с функциями СКЗИ производитель заявляет как имеющий сертификат ФСБ и ФСТЭК одновременно (иногда еще и МинОбороны фигурирует), а на деле оказывается, что в органы по сертификации подавались разные версии продуктов. Одна версия имеет сертификат ФСТЭК, вторая, отличная от первой, - имеет только сертификат ФСБ. И синхронизации между ними при несовпадении сроков сертификации в разных системах сертификации нет.
Вот как-то так...
Комментариев нет:
Отправить комментарий
Примечание. Отправлять комментарии могут только участники этого блога.