Статистика выявления уязвимостей в программном обеспечении в рамках сертификационных испытаний

Анализ уязвимостей программного обеспечения в настоящее время является обязательным видом деятельности, выполняемым экспертами испытательных лабораторий отечественных систем сертификации средств защиты информации (СЗИ). Данный вид работ выполняется как при сертификации на соответствие требованиям профилей защиты, в которых в явном виде включены требования семейства доверия AVA_VAN «Анализ уязвимостей» (стандарты по линии «Общих критериев»), так и при испытаниях на соответствие требованиям технических условий или классических руководящих документов Гостехкомиссии России.

В настоящем исследовании представлена статистика выявления уязвимостей в программном обеспечении, которое было объектом сертификационных испытаний в Испытательной лаборатории НПО «Эшелон» в период 2016 — 2017 гг.

Методика исследования


Методика анализа уязвимостей, используемая испытательными лабораториями (ИЛ) в рамках сертификационных испытаний, базируется на «Общей методологии оценки» (международный стандарт ISO/IEC 18045) и в общем случае состоит из следующих этапов.

Этап 1. Выявление известных (подтвержденных) уязвимостей объекта сертификации. На данном этапе экспертами ИЛ осуществляется поиск известных (подтвержденных) уязвимостей в общедоступных источниках информации, например: в Банке данных угроз безопасности информации ФСТЭК России, ресурсах CVE, NVD, ресурсе разработчика программного обеспечения (ПО). Если информация об уязвимостях обнаруживается, то испытания приостанавливаются до момента передачи в ИЛ обновлений ПО, «закрывающих» известные уязвимости.

Этап 2. Выявление ранее не опубликованных уязвимостей объекта сертификации. На данном этапе эксперты ИЛ выполняют в общем случае следующие шаги:

  • шаг 1: формирование перечня потенциальных уязвимостей объекта сертификации на основе изучения различных типов источников данных (проектная документация на объект сертификации, исходный текст, информация из открытых источников);
  • шаг 2: создание тестовых сценариев (атак) для каждой идентифицированной потенциальной уязвимости;
  • шаг 3: выполнение тестов с целью определения верности сделанного предположения.

В рамках данного исследования при выполнении шага 1 специалисты ИЛ НПО «Эшелон» использовали следующие методы формировании перечня потенциальных уязвимостей:

  • экспертно-документальный метод, предусматривающий формирование перечня потенциальных уязвимостей на основе информации об известных уязвимостях в схожих по функциональным возможностям продуктах, в других версиях (например, более старых) объекта сертификации, в заимствованных компонентах, типовых уязвимостях, характерных для технологий, используемых при разработке объекта сертификации;
  • статический анализ исходных текстов ПО (в случае предоставления доступа к исходным текстам в рамках сертификационных испытаний);
  • фаззинг-тестирование.

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

Объекты исследования


Исследования проводились в период 2016 — 2017 гг. в рамках испытаний 76 продуктов по линии системы сертификации во всех системах сертификации (сертификационные испытания, инспекционные контроли) в ИЛ НПО «Эшелон».

Распределение исследованных продуктов по типам представлено на рис.1.


Рис.1. Распределение исследованных продуктов по типам
(СЗИ от НСД – средство защиты от несанкционированного доступа; ППО с СЗИ – прикладное программное обеспечение со встроенными средствами защиты информации; МЭ – межсетевой экран; САВЗ – средство антивирусной защиты; СУБД – системы управления базами данных; ОС – операционная система; СОВ – система обнаружения вторжений)

Разработчиками продуктов являлись как отечественные, так и зарубежные организации.

В зависимости от критериев сертификации, определяемых потенциальной областью применения сертифицируемого продукта, экспертам ИЛ предоставлялся или не предоставлялся доступ к исходным текстам объекта сертификации (рис. 2).


Рис.2. Распределение исследованных продуктов в зависимости от доступа к исходным текстам

Результаты исследований
В результаты исследований специалистами ИЛ НПО «Эшелон» была выявлена 81 уязвимость (уязвимости были выявлены в 26 продуктах из 76 исследованных). Для всех выявленных уязвимостей ПО было получено подтверждение об их актуальности со стороны разработчика ПО, разработчиками ПО были приняты меры по устранению выявленных уязвимостей.
На рис. 3 показано распределение выявленных уязвимостей по степени критичности (оценка выполнялась по методике CVSS версия 3.0).

Рис.3. Распределение выявленных уязвимостей в зависимости от степени критичности


Наиболее популярным типом уязвимого ПО стало прикладное ПО со встроенными средствами защиты информации (рис. 4).


Рис.4. Распределение выявленных уязвимостей в зависимости от типа
исследованного ПО


Основными типами векторов успешных атак, которые были разработаны экспертами ИЛ с целью подтверждения актуальности уязвимости, стали (рис. 5):

  • межсайтовое выполнение скриптов (CAPEC-63);
  • межсайтовая подделка запросов (CAPEC-62);
  • повышение привилегий, связанное с обходом функций безопасности (CAPEC-233);
  • атаки, направленные на отказ в обслуживании (CAPEC-2);
  • раскрытие критичной информации ПО в сообщениях об ошибках (CAPEC-54);
  • инъекция SQL-кода (CAPEC-66).


Рис.5. Распределение выявленных уязвимостей в зависимости от типа вектора атаки

В категорию «Иное» попали такие типы векторов атак, как: удалённое выполнение команд операционной системы путем передачи данных в HTTP-запросах (CAPEC-76), XML-инъекция (CAPEC-250), фиксация сессии (CAPEC-61), выход за пределы назначенной директории (CAPEC-126), атаки типа «Reparse-Point», «RegSafe/RegRestore».

Основными типами недостатков ПО, ставших причинами уязвимостей, стали (рис. 6):

  • неверное использование данных, полученных из недоверенного источника, для генерации HTML-страницы (CWE-79);
  • использование аутентификационных данных (данные cookie) для авторизации запроса (CWE-352);
  • неверное использование данных, полученных из недоверенного источника, при выполнении функций безопасности (CWE-807);
  • отсутствие авторизации при выполнении критичных операций (CWE-862);
  • неверное использование данных, полученных из недоверенного источника, для генерации запроса к СУБД (CWE-89);
  • неверная генерация сообщений об ошибках (CWE-209).


Рис.6. Распределение выявленных уязвимостей в зависимости от ошибки (недостатка) ПО

В категорию «Иное» попали такие типы ошибок ПО, как: использование заданных в коде программы аутентификационных данных (CWE-798), переполнение буфера (CWE-120), ошибки, приводящие к фиксации сессии (CWE-384), неверное использование данных, полученных из недоверенного источника, для генерации команд ОС (CWE-22) и пр.

Говоря о методах формирования перечня потенциальных уязвимостей, следует отметить, что большинство уязвимостей было обнаружено благодаря предположениям, сделанным на основе изучения документации на объект сертификации и данных об уязвимостях в схожих с объектом сертификации продуктах (рис.7).


Рис.7. Распределение выявленных уязвимостей в зависимости от метода формирования перечня потенциальных уязвимостей

Распределение выявленных уязвимостей в зависимости от ошибки (недостатка) ПО и типа исследованного ПО показано ниже:











Распределение выявленных уязвимостей в зависимости от от степени критичности и типа исследованного ПО:











Выводы


  1. Надо признать, что доля уязвимостей, обнаруженных в ПО отечественного производства, несколько больше доли уязвимостей, обнаруженных в зарубежном ПО, даже на фоне существенной разницы между объемами исследованных продуктов отечественного и зарубежного производства. Думается, это объясняется существенными различиями в уровнях зрелости процессов жизненного цикла разработки безопасного ПО, внедренных у зарубежных и отечественных разработчиков ПО. Надеемся, с внедрением в стране стандарта по менеджменту безопасной разработке эта ситуация изменится.

    Следует отметить, что при проведении исследований для ПО зарубежного производства в большинстве случаев разработчиками не обеспечивался доступ к исходному коду объектов исследования, что делало принципиально невозможным формирование перечня потенциальных уязвимостей на основе исследования исходных текстов программы.
  2. Большая часть выявленных в рамках исследования уязвимостей могла быть обнаружена разработчиками ПО на ранних стадиях разработки ПО с использованием анализа архитектуры ПО с точки зрения реализации угроз безопасности информации и статического анализа исходных текстов ПО.
  3. С целью уменьшения количества уязвимостей разработчикам ПО рекомендуется внедрять в процессы жизненного цикла основные активности, направленные на разработку безопасного ПО (ГОСТ Р 56939) – анализ архитектуры ПО с точки зрения реализации угроз безопасности информации, статический анализ исходных текстов, тестирование безопасности. Внедрение подобных процедур в практику отечественных разработчиков ПО, на наш взгляд, повысить уровень защищенности создаваемого ПО и, как следствие, значительно уменьшить число инцидентов информационной безопасности.
Эшелон
44.51
Company
Share post

Comments 18

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

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

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

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

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

          Два вопроса:


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

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

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

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

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

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

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

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

                  Only users with full accounts can post comments. Log in, please.