Как стать автором
Обновить

Комментарии 18

Квадратно-гнездовой пост тащемта ниачом…

Как я понял из поста, сертификация проводится путём испытаний сертификационных :)

Проводящихся в сертификарии при помощи сертификатов. См. Сепульки.

Нет, ну почему же. Хотя бы понятно, что в ходе испытаний действительно что-то находилось. Уже радует.)

Опечатка в заголовке, в слове сертификационных

Два вопроса:


  1. Что происходит, если в ходе испытаний выявляется уязвимость? Не выдаётся сертификат соответствия? Что, если обнаружилась только незначительная уязвимость?
  2. Планируется ли пост (ну или хотя бы комментарий) про КРОВЬ КИШКИ МЯСО на сертификационных испытаниях? Ну там всякие байки из разряда "приносят нам как-то раз межсетевой экран, мы Nmap запустили и нашли скрытую админку, которую разработчики забыли из кода убрать".
    Интересно всё-таки, как вы всё это выявляете. Сколько мегабайт исходного кода аналитик разбирает в день, используется ли какая-то автоматизация, что было особенно запоминающегося и так далее.
Скорее всего есть поправки на критичность уязвимости, от которых зависит итог сертификации. А вообще очень интересная тема. А что если найдутся уязвимости после сертификации? Сертифицируется ли отдельный билд, ветка или просто — вот сертификат «Виндоус!»
А если сертифицированный продукт вдруг явил свету критичный баг — обновление лишает сертификата или нет?

Сертифицируется конкретный билд, что делает сертификацию профанацией в масштабе государства. Как разработчик сертифицированного ПО, могу вам сказать, что дальнейшая судьба этого билда — лежать записанным на диске на полке у клиента.
Сертификация конкретной версии ПО с фиксацией в документах конкретного номера сборки и хешей исполняемых файлов достаточно распространённая практика не только в отечественной, но и зарубежных системах сертификации. Выдавать сертификат на что-то абстрактное нельзя – у пользователей должна быть возможность убедиться (например, путем сверки номера сборки или сравнения хешей исполняемых файлов), что они получили от разработчика или поставщика именно сертифицированную версию продукта. При реализации разработчиком ПО процедуры выпуска обновлений и их «легализации» с использованием процедуры инспекционного контроля (а эта процедура налажена у всех крупных российских разработчиков) пользователи сертифицированных продуктов имеют возможность оперативно получать обновления, использование которых не нарушает сертифицированных свойств продукта.
Для подобных случаев (уязвимость обнаружена после получения сертификата) предусмотрена процедура инспекционного контроля (более простая и менее затратная, по сравнению с сертификацией, процедура). Эта процедура предусматривает передачу в испытательную лабораторию доработанного ПО и всех необходимых для поведения испытания материалов. Задача лаборатории – подтвердить, что уязвимость «закрыта», а внесенные исправления не оказали влияния на сертифицированные функции по безопасности. После проверок со стороны испытательной лаборатории и подтверждения со стороны Системы сертификации обновления можно поставлять пользователю (сертификат в этом случае продолжает действовать на обновленную версию продукта). В отдельных случаях (уязвимость «закрывает» критичную уязвимость) разрешается поставлять обновления ПО, не дожидаясь завершения процедуры инспекционного контроля. Случаи отзыва сертификата были (по официальным данным от представителей ФСТЭК России), но это происходило только из-за того, что разработчик не мог исправить уязвимость в течение долгого времени.
1. Техническая информация о найденной уязвимости (тестовый сценарий, подтверждающие материалы) передаются разработчику ПО. Разработчик устраняет уязвимость в исходном коде сертифицируемой программы или, если это возможно, «закрывает» уязвимость компонентами среды функционирования (это бывает достаточно редко). Доработанная программа передается в испытательную лабораторию для верификации исправления и продолжения испытаний. Если доработанная программа успешно проходит оставшиеся проверки, лаборатория делает заключение о соответствии продукта предъявляемым требованиям (это является одним из оснований для оформления сертификата соответствия). Отказ в выдаче сертификата возможен, например, если разработчик сознательно не исправляет уязвимость – на нашей практике такого не случалось. По критичности уязвимостей: все найденные при сертификации уязвимости должны исправляться. Каких-либо официальных уточнений от Системы сертификации в части возможности неустранения некритичных уязвимостей пока нет.

2. Пока нет. Все «КРОВЬ КИШКИ МЯСО», к сожалению, подпадают под действие NDA между лабораторией и разработчиками ПО. Согласовать с разработчиками возможность публичного раскрытия уязвимостей (в совместных пресс-релизах или выступлениях на конференциях) нам пока не удалось, но мы работаем в этом направлении.
А где можно посмотреть сами описания уязвимостей? Проценты это конечно хорошо, но хотелось бы почитать подробнее

разработчиками ПО были приняты меры по устранению выявленных уязвимостей

Вот чисто для интереса. Как организована процедура на случай выявления уязвимости? «Приняты меры» — это как-то обтекаемо
К сожалению, все технические подробности попадают под действие NDA между разработчиками и лабораторией. Процедуру в случае выявления – описал в комментарии выше. Принятые меры во всех случаях были связаны с внесением изменений в исходный код программы.
Ну с предоставлением информации вендору все только начинается в процедуре
— вносятся ли изменения в пакет документов, подаваемый на сертификацию?
— по процедуре сборка версии, подаваемой на сертификацию, производится в присутствии или заказчика или сертифицирующей организации. В случае нахождения уязвимости естественно необходима пересборка. Выезжают ли ваши представители на нее?
1. Да, изменения вносятся. Как минимум, вносятся новые сведения о контрольных суммах (хэшах) файлов исправленного дистрибутива и исполняемых файлов сертифицируемого ПО.

2. Да, сборка, в том числе сборка исправленных файлов, выполняется либо на территории испытательной лаборатории, либо на территории разработчика в присутствии экспертов. Для уменьшения количества таких выездов наша лаборатория практикует проведения анализа уязвимостей на ранних стадиях испытаний.
Спасибо, понял

Удачи вам с выявлением уязвимостей!
Тема, вообще, интересная, но получилось до конца осмысленно. Да, статистика по числу уязвимостей в разных типах испытуемых средств — это хорошо, но интересно было бы еще и следующее:

  1. Разбивка типов уязвимостей по типам объектов испытаний
  2. Разбивка критичности уязвимостей по типам ОИ
  3. Порядок взаимодействия с производителем
  4. Среднее время реакции производелей
1, 2. Статистику построили, обновили статью.
3. Поскольку разработчик всегда вовлечен в процесс сертификации (если испытания требуют предоставления доступа к исходным текстам), то взаимодействие выполняется с их ответственным представителем (как правило, менеджер по сертификации), который обеспечивает оперативную передачу сведений об уязвимостях разработчикам (QA, security team и пр.) для их оперативного устранение или получения уточнений.
4. Поскольку разработчик полностью вовлечен в процесс сертификации, более того, заинтересован в быстром ее прохождении, то среднее время реакции разработчика, по нашему опыту, составляет около 5 рабочих дней.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.