Методика выявления уязвимостей и недекларированных возможностей в программном обеспечении (Выписка)

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

2.2. Исследования ОО проводятся в соответствии с уровнями контроля, которые определяют состав и содержание проводимых исследований, методы исследований и требования к применяемым при проведении исследований инструментальным средствам анализа и контроля.

Устанавливается 6 уровней контроля. Самый низкий уровень – шестой, самый высокий – первый.

Требования к уровню контроля ОО предъявляются в соответствии с Требованиями доверия.

2.3. При проведении исследований ОО используются:

а) документация на ОО, предусмотренная Требованиями доверия;

б) исходный код ОО;

в) сборочная среда и система сборки ОО, включая их документацию;

г) дистрибутив ОО;

2.5. При проведении исследований применяются инструментальные средства анализа и выявления ошибок, уязвимостей и НДВ, функциональные возможности которых обеспечивают реализацию положений настоящей Методики, не имеющие каких-либо ограничений по применению и адаптации (доработке) на территории Российской Федерации.

2.6. Исследования ОО по выявлению уязвимостей и НДВ в соответствии с положениями настоящей Методики проводятся специалистами испытательной лаборатории (далее – испытательная лаборатория)<1>, а также специалистами организации-разработчика, ответственными за обеспечение разработки безопасного программного обеспечения, с привлечением специалистов, непосредственно участвующих в разработке ОО (далее – разработчик ОО).

2.7. Выявленные уязвимости архитектуры, кода и конфигурации ОО, НДВ, а также потенциально опасные декларированные возможности допускается устранять в ходе проведения исследования ОО.

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

В ходе подготовки к проведению исследований по выявлению уязвимостей и НДВ объекта оценки должны выполняться:

В ходе анализа документации и иных исходных данных проверяются исходные данные на соответствие требованиям настоящей Методики в части достоверности, полноты, актуальности, согласованности (отсутствие противоречий).

Входными данными для анализа поверхности атаки являются декларируемые перечни аппаратных, программных и пользовательских интерфейсов, доступных для атаки потенциальным нарушителям.

Анализ поверхности атаки представляет собой следующие действия:

В качестве минимальных требований к полноте поверхности атаки ОО выступают включенные в ее состав подпрограммы (функции):

а) непосредственно доступные для вызова потенциальным нарушителям<3>;

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

Разработчик ОО предоставляет описание вносимых модификаций и обосновывает, что они не приводят к возникновению недостатков безопасности ОО. Испытательная лаборатория оценивает представленное описание, в том числе его достоверность, полноту, актуальность, согласованность, и по результатам принимает решение о возможности проведения дальнейших исследований ОО.

2. В ходе исследований проверяется, что при наличии в составе поверхности атаки ОО функций, написанных на интерпретируемых языках программирования или на языках программирования, компилируемых в промежуточное представление, разработчик ОО включил в перечень анализируемых модулей соответствующие модули среды исполнения применяемых языков программирования<8>. При отсутствии в поверхности атаки требуемых модулей среды исполнения испытательная лаборатория самостоятельно добавляет их в перечень анализируемых модулей.

<8> Модули среды исполнения интерпретируемых языков или языков, компилируемых в промежуточное представление, включают в себя интерпретатор или виртуальную машину выполнения промежуточного языка, библиотеки поддержки времени выполнения и стандартные библиотеки в составе виртуальной машины.

3. При проведении исследований проверяется, что разработчик ОО включил в перечень анализируемых модулей модули, реализующие интерфейсы ОО, доступные периодически, в том числе служебные интерфейсы ОО, отвечающие за периодические обновления ОО с удаленных источников. При отсутствии этих модулей испытательная лаборатория самостоятельно добавляет их в перечень анализируемых модулей.

4. Испытательной лабораторией проводится проверка того, что разработчик ОО выделил в подлежащих анализу модулях перечень критичных для безопасности участков кода, в который включил участки кода, взаимодействующие с данными, поступающими от потенциального нарушителя (парсеры, анализаторы, в том числе в составе кода веб-приложений), и имеющие высокую сложность<9>. Разработчик ОО предоставляет обоснование выбора выделенных участков кода с описанием методики оценки сложности кода.

При отсутствии или недостаточной обоснованности выбора испытательная лаборатория самостоятельно корректирует перечень критичных участков кода.

<9> Для оценки сложности кода должна использоваться одна из известных метрик, например, цикломатическая сложность программы (цикломатическое число Мак-Кейба), мера Холстеда, мера Овиедо и другие метрики.

5. В ходе исследований проверяется полнота перечня анализируемых модулей с использованием инструментальных средств определения поверхности атаки. При выявлении неполноты испытательная лаборатория самостоятельно расширяет состав анализируемых модулей.

На основе собранных и проанализированных сведений испытательной лабораторией разрабатывается методика проведения исследований в соответствии с Положением о системе сертификации средств защиты информации, утвержденным приказом ФСТЭК России от 3 апреля 2018 г. № 55. В методике по каждому виду исследований определяются состав и содержание исследований, средства анализа и их настройки, указывается конкретный порядок действий, выполняемых в ходе реализации соответствующих исследований, учитывающий особенности ОО, в том числе особенности, связанные с языками программирования, на которых написан ОО, составом реализуемых ОО ФБ, составом механизмов защиты от исследований, реализованных в ОО, типами внешних интерфейсов ОО, иные архитектурные особенности ОО, влияющие на порядок проведения исследований.

В методике проведения исследований (или протоколе исследований) приводится описание поверхности атаки в графической нотации в объеме сущностей не меньшем, чем:

Также указываются как минимум следующие характеристики модулей:

Каждая операционная система, составляющая среду функционирования, формирует собственное семейство сред функционирования. Отнесение к семейству среды функционирования для сред, реализованных в формате средства контейнеризации, определяется парой «базовая технология средства контейнеризации — операционная система», в которой функционирует средство контейнеризации. Отнесение к семейству среды функционирования для сред, реализованных в формате средства виртуализации, определяется базовой технологией средства виртуализации.

Испытательной лабораторией выполняется контролируемая сборка дистрибутивов ОО с целью выявления:

В случае выявления указанных фактов испытательная лаборатория расценивает их в качестве недостатков безопасности ОО и принимает решение о невозможности проведения дальнейших исследований ОО.

При подготовке исследовательского стенда проводятся проверки в отношении того, что:

В ходе установки ОО в среду функционирования и его настройки проводится контроль отсутствия недекларированных взаимодействий ОО с сетевыми ресурсами и ресурсами среды функционирования.

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

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

В случае реализации ОО с использованием технологий контейнеризации и (или) виртуализации, контрольные суммы исполняемых файлов ОО рассчитываются относительно снимков состояния (снапшотов) файловых систем выполняющихся контейнеров и (или) виртуальных машин.

2. Исследовательский стенд должен обеспечивать проведение динамического анализа ОО для каждой процессорной архитектуры среды функционирования ОО.

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

В ходе проведения исследований по выявлению уязвимостей и недекларированных возможностей объекта оценки должны выполняться:

а) анализ архитектуры ОО;

б) статический анализ ОО;

в) динамический анализ ОО;

г) экспертиза кода ОО.

Анализ архитектуры ОО включает:

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

В ходе анализа архитектуры контролируется назначение ОО и его составным частям полномочий, минимально необходимых для функционирования ОО. Выявленные избыточные полномочия ОО и его составных частей рассматриваются в качестве недостатков безопасности ОО.

Испытательной лабораторией самостоятельно собираются и анализируются материалы из общедоступных источников (публикации разработчика, пользователей и исследователей об ОО и его заимствованных компонентах, базы данных уязвимостей, сведения о типовых уязвимостях и ошибках, тематические информационные ресурсы) о недостатках (слабостях) и уязвимостях как самого ОО, так и аналогичного по архитектуре программного обеспечения в дополнение к исходным данным, предоставленным разработчиком ОО. В качестве источников информации о типовых недостатках (слабостях) и уязвимостях следует использовать в том числе:

Если предоставленные разработчиком ОО исходные данные отвечают требованиям, то испытательная лаборатория должна:

Если предоставленные разработчиком результаты анализа архитектуры ОО статическими методами не отвечают требованиям, испытательная лаборатория проводит анализ архитектуры статическими методамисамостоятельно, в соответствии с требованиями настоящей Методики либо принимает решение о невозможности проведения дальнейших исследований ОО.

В целях выявления НДВ, компрометирующих конструкций, недостатков архитектуры и кода должен проводится анализ комментариев в исходном коде ОО.

Испытательной лабораторией самостоятельно анализируются:

Проводится оценка соответствия конфигураций запуска отдельных контейнеров и групп (сетей) контейнеров, составляющих ОО в контейнерном исполнении, публично доступным рекомендациям по безопасности и минимизации полномочий (например, рекомендации ФСТЭК России, CIS, Kubernetes Security Best Practices и другие рекомендации), в том числе:

а) для ОО в контейнерном исполнении обеспечивается запуск контейнеров с полномочиями, минимально необходимыми для функционирования ОО, на уровне процессов хостовой операционной системы;

1. Испытательной лабораторией анализируется перечень программных компонентов и иные результаты композиционного анализа в части поиска известных уязвимостей привлекаемых компонентов среды функционирования ОО за исключением компонентов системы сборки и сборочной среды ОО.

2. В ходе исследований контролируются наличие в составе ОО кода (либо генераторов такового кода), выполняющегося в контексте браузера (например, JavaScript, ActiveX, WebAssembly и других), а также учет кода в перечне программных компонентов и выполнение разработчиком в отношении него композиционного анализа.

Выявление динамической загрузки кода в контекст браузера не из состава (либо результатов генерации) ОО требуется расценивать в качестве основания для прекращения исследований ОО.

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

3. Испытательной лабораторией анализируются конфигурации систем сборки и сборочных сред ОО и его компонентов на предмет использования применимых опций конфигурирования, компиляции и компоновки ОО, повышающих безопасность исполняемого кода ОО<11> в том числе за счет минимизации объема исполняемого кода ОО.

Испытательная лаборатория учитывает отсутствие выбора и использования указанных опций в качестве недостатка безопасности ОО.

Испытательной лабораторией выполняется не менее трех различных сценариев функционирования ОО с контролем сетевой активности ОО с целью выявления утечек чувствительных данных (например, учетные записи и пароли, приватные ключи и другие данные) и НДВ. Примерами сценариев являются: создание учетной записи пользователя и ее редактирование, изменение набора правил фильтрации сетевого трафика, выполнение антивирусного анализа файла и другие сценарии. При выборе сценариев следует отдавать предпочтение сценариям, затрагивающим порождение (модификацию) чувствительных данных, выполнение административных функций, а также предполагающих взаимодействие с подсистемами, расположенными на различных узлах сети.

При проведении исследований выполняется анализ сетевых интерфейсов ОО, составляющих поверхность атаки, с использованием анализаторов безопасности, предполагающих запуск сценариев, реализующих логику автоматизированного определения недостатков безопасности ОО.

1. В ходе исследований анализируются рекомендованные ФСТЭК России либо применяемые разработчиком ОО методы автоматизированного динамического анализа, направленные на подтверждение устойчивости ОО к специфическим для данного типа ОО угрозам<12>.

Испытательной лабораторией выполняется автоматизированный динамический анализ ОО, направленный на подтверждение устойчивости СЗИ к специфическим угрозам, выбранным подмножеством методов. Испытательная лаборатория предоставляет инструменты анализа и может привлекать разработчика ОО для организации и проведения анализа.

Если предоставленные разработчиком ОО исходные данные отвечают требованиям настоящего пункта Методики, испытательная лаборатория проводит выборочную проверку разметки результатов статического анализа из состава исходных данных. Выборочная проверка выполняется в отношении контрольной выборки предупреждений, составленной по следующему принципу:

При составлении контрольной выборки предупреждений следует руководствоваться следующими приоритетами:

Если доля неверно размеченных разработчиком предупреждений в составе контрольной выборки не превосходит 10 %, исследования ОО продолжаются после устранения разработчиком выявленных недостатков безопасности ОО.

Если доля неверно размеченных разработчиком ОО предупреждений превосходит 10 %, испытательной лабораторией выполняется статический анализ кода самостоятельно в соответствии с требованиями настоящей Методики либо принимается решение о невозможности проведения дальнейших исследований ОО.

1. В ходе исследований испытательной лабораторией проверяется, что состав анализируемых модулей дополнен модулями, реализующими ФБ ОО.

2. Испытательной лабораторией проверяется, что используемый статический анализатор отвечает требованиям национального стандарта Российской Федерации ГОСТ Р 71207-2024 «Защита информации. Разработка безопасного программного обеспечения. Статический анализ программного обеспечения. Общие требования».

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

1. В ходе исследований испытательной лабораторией проверяется, что состав тестируемых модулей дополнен модулями, составляющими непосредственную поверхность атаки ОО.

3. В ходе исследований испытательной лабораторией проверяется, что сбор тестового покрытия осуществляется по строкам исходного кода или по базовым блокам исполняемого кода для каждого тестируемого модуля ОО.

4. Испытательной лабораторией проверяется, что совокупный достигнутый процент тестового покрытия для каждого тестируемого модуля составляет не менее 25 %.

5. В ходе исследований испытательной лабораторией проверяется, что состав тестируемых модулей дополнен модулями, обеспечивающими реализацию ФБ ОО.

а) выполняется фаззинг-тестирование интерфейсов, относящихся к поверхности атаки ОО. Не требуется выполнять фаззинг-тестирование в отношении кода, выполняющегося в контексте браузера. Допускается проводить фаззинг-тестирование только в одной в среде функционирования, обеспечивающей наиболее эффективное выполнение тестирования;

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

Если применяются фаззеры, поддерживающие работу с коллекциями входных данных, для каждого из подлежащих фаззинг-тестированию интерфейсов должны быть сформированы и применены коллекции примеров входных данных. Коллекции должны вызывать использование различных функциональных возможностей тестируемого интерфейса. Формирование коллекций следует выполнять на основе публично доступных коллекций, использования генераторов коллекций, использования инструментов автоматического определения и формирования коллекций данных или экспертным способом.

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

Если применяются фаззеры, поддерживающие работу со словарями, то для интерфейсов, где применим такой подход, должны быть сформированы и применены словари лексем;

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

Если предоставленные разработчиком ОО исходные данные отвечают требованиям текущего пункта настоящей Методики, испытательной лабораторией проводится проверка результатов фаззинг-тестирования, выявивших воспроизводимые сбои и зависания целей.

Если доля неверно размеченных разработчиком результатов фаззинг-тестирования в составе контрольной выборки не превосходит 10 %, исследования ОО продолжаются после устранения разработчиком выявленных недостатков безопасности ОО.

Если доля неверно размеченных разработчиком ОО результатов фаззинг-тестирования в составе контрольной выборки превосходит 10 %, испытательной лабораторией принимается решение о невозможности проведения дальнейших исследований ОО.

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

1. В ходе проведения исследований испытательной лабораторией проверяется, что используемый разработчиком ОО фаззер обеспечивает применение генетических алгоритмов фаззинг-тестирования за счет инструментирования кода в случае, если доступны инструменты, позволяющие осуществлять такое фаззинг-тестирование с учетом языков программирования, компиляторов и среды функционирования ОО. При этом допускается выполнять инструментирование:

2. Испытательной лабораторией проверяется выполнение в дополнение к условиям, указанным в других дополнительных требованиях, при фаззинг-тестировании ОО как минимум одного из следующих условий:

а) для фаззеров, подсчитывающих число найденных уникальных путей, число уникальных путей, найденных фаззером, должно не менее чем в два раза превышать число образцов входных данных, поданных на вход фаззеру;

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

При достижении покрытия по строкам исходного кода не менее 90 % (по базовым блокам не менее 80 %) испытательная лаборатория может не учитывать дальнейший прирост покрытия для принятия решения о завершении фаззинг-тестирования.

5. Испытательной лабораторией проверяется, что тестирование каждой фаззинг-цели продолжается до состояния, когда в течение не менее двух часов фаззер не находит нового пути или отсутствует прирост покрытия при условии, что на вход подаются уникальные мутированные данные.

Экспертиза кода ОО представляет собой ручной анализ участков исходного и восстановленного кода ОО сцелью выявления уязвимостей и НДВ (ЭКО).

Испытательной лаборатории требуется выполнить экспертизу участков исходного и восстановленного кода, предусматривающую ручной направленный анализ кода в отношении, как минимум:

Если при проведении динамического анализа были выявлены механизмы, препятствующие проведению исследований, то программы (программные модули), участки кода, содержащие такие механизмы защиты, должны быть проанализированы совместно с разработчиком ОО. В случае отказа разработчика ОО от анализа испытательной лабораторией могут быть самостоятельно разработаны решения по снятию механизмов защиты от исследований. Если разработчик ОО отказался снимать механизмы защиты, препятствующие проведению исследований, или предлагаемые разработчиком решения по снятию механизма защиты не позволяют провести исследования в полном объеме, делается вывод о невозможности дальнейших исследований.

Испытательной лаборатории требуется выполнить ручной анализ участков исходного и восстановленного кода ОО на предмет наличия программных и архитектурных ошибок, а также заведомо неудачных программных реализаций, способствующих возникновению ошибок и уязвимостей следующих типов:

а) использование потенциально опасных программных интерфейсов;

б) наличие в ОО заведомо некачественного программного кода (заведомо некорректное оформление исходного кода, невыполнимые или тождественные условия, не удаленные отладочные сообщения и другой код);

в) небезопасная загрузки библиотек;

г) некорректная обработка ошибок;

д) недостаточное ограничение прав доступа посторонних субъектов к временным файлам;

е) недостаточно полная проверка недопустимости присутствия во входных данных фрагментов программ на интерпретируемых языках (SQL-инъекции, XSS-атаки и другие типы атак);

ж) некорректная обработка длин буферов с данными;

з) некорректная обработка ситуаций, когда вместо обычного файла ОО предоставляется именованный канал, символическая ссылка или иной файловый объект специального вида;

и) ненадлежащее обеспечение корректности совместного доступа к глобальным данным в параллельных вычислениях;

к) ненадлежащее хранение аутентификационных данных в оперативной или внешней памяти;

л) переполнение буферов;

м) предоставление пользователям избыточной функциональности до аутентификации;

н) предоставление пользователям избыточных полномочий;

о) утечки чувствительных данных в журнальные файлы;

п) утечки оперативной памяти, файловых дескрипторов, графических ресурсов и других ошибок;

р) целочисленные переполнения;

с) наличие неиспользуемых программных компонентов: функций, процедур, переменных, классов и других компонентов;

т) наличие бинарных вставок и кодировок, в которых данные вставки представлены.

Определение программных ошибок должно осуществляться на основании сведений, содержащихся в соответствующих базах данных (например, Common Weakness Enumeration или Fortify Taxonomy: Software Security Errors), а также руководствах и стандартах, отражающих лучшие практики разработки безопасных программ (например, SEICERTC++ Coding Standard или The CERT Oracle Secure Coding Standard for Java).

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

В ходе экспертизы участков исходного текста и восстановленного кода должен быть зафиксирован перечень проверяемых программных ошибок и критерии их выявления.

Испытательной лаборатории требуется выполнять ручной анализ исходного кода с использованием инструментов, обеспечивающих навигацию на уровнях модулей (файлов) и структурных элементов языка программирования анализируемой программы. Если код написан на языке программирования, для которого отсутствуют инструменты с такими возможностями, допускается проводить исследование с помощью штатных утилит работы с текстами и файлами, такими как ls, find, grep, cat, sort и других утилит.

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

Инструментальные средства для исследования логической структуры программы должны обеспечивать:

а) определение сущностей программы: процедур, методов, классов, полей, глобальных переменных программы;

б) определение для каждой сущности: места определения в исходном файле, списка вложенных сущностей (методы и поля в классах, вложенные классы в процедурах и методах), объемлющей сущности-родителя;

в) определение мест использования сущностей в исходном коде программы с указанием файла, строки: вызов процедур, чтение и запись полей и глобальных переменных;

г) определение связей между сущностями в иерархии классов программы: список родителей и наследников заданного класса, список методов, переопределяющих данный метод, список методов, реализующих данный абстрактный метод;

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

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

5.2. Протокол проведения исследований должен включать:

а) общие положения, объект и цели исследований;

б) средства и условия проведения исследований;

в) технические результаты выполненных исследований;

г) результаты исследований;

д) перечень выявленных недостатков безопасности ОО;

е) выводы.

5.4. Требуется включить в материалы исследований подготовленные разработчиком ОО результаты исследований, выполненных в соответствии с планом поддержки безопасности заимствованных компонентов сертифицированного средства защиты.

5.5. Выявленные в ходе исследований недостатки безопасности, принятые разработчиком ОО меры по устранению недостатков, вердикты и рекомендации испытательной лаборатории по устранению комплексных недостатков подлежат фиксации в протоколах исследований в соответствии с формой, приведенной в таблице 6.

Сведения об уязвимостях ОО и его компонентов направляются разработчиком ОО в банк данных угроз безопасности информации ФСТЭК России.

5.6. Протокол подписывается исследователем или группой исследователей, проводивших исследования по выявлению уязвимостей и НДВ. Исследователи несут ответственность за выводы, сделанные ими по результатам проведенных исследований.

Приложение 3 к Методике выявления уязвимостей и недекларированных возможностей в программном обеспечении