ПОД.1 — Анализ документации и иных исходных данных

Раздел методики: 3.1
Применимость для уровня доверия 4 (уровень контроля 4): базовое исследование + усиления 1, 2, 3, 4, 5
Кто проводит: испытательная лаборатория совместно с разработчиком ОО

Задачи исследования

1. Сформировать представление об ОО:
2. функциональные возможности и функции безопасности (ФБ) ОО
3. условия безопасной эксплуатации, режимы и параметры функционирования
4. структура ОО: интерфейсы, компоненты, модули, файлы, структурные элементы кода
5. сторонние программные компоненты ОО

6. параметры и особенности сборочной среды и системы сборки ОО

7. Оценить состав и полноту результатов выполнения процессов разработки ОО в соответствии с ГОСТ Р 56939-2024 и иными национальными стандартами в области ИБ.

8. Разработать методику проведения исследований (для новой сертификации) или определить порядок исследований (для изменений в сертифицированном ОО).

Исходные данные

Предоставляются разработчиком ОО в соответствии с п. 2.3 Методики:

• документация на ОО (в соответствии с Требованиями доверия)
• исходный код ОО
• сборочная среда и система сборки ОО, включая документацию
• дистрибутив ОО
• результаты выполнения процессов разработки по ГОСТ Р 56939-2024: анализ архитектуры, поверхности атаки, композиционный анализ, анализ конфигураций, статический анализ, фаззинг, тестирование на проникновение, результаты Bug Bounty (при наличии), функциональные/интеграционные/модульные тесты
• перечень программных компонентов и образов контейнеров ОО (CycloneDX 1.6/1.7 JSON по приложениям 1 и 2 Методики)
• тесты: системные, функциональные, регрессионные, модульные, фаззинг-тесты, конфигурации инструментов анализа
• план поддержки безопасности заимствованных компонентов (при внесении изменений в сертифицированный ОО)
• для контейнерного исполнения: заданные в эксплуатационной документации списки разрешённых действий (правила) взаимодействия компонентов
• методики анализа поверхности атаки, статического анализа, тестирования и фаззинга заимствованных open-source компонентов (с портала portal.linuxtesting.ru)

Требования к проведению исследования

Проверка исходных данных

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

Оценка результатов разработчика

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

1. Правильность выбора и настройки средств выявления уязвимостей и НДВ.
2. Соответствие полноты исследований требованиям уровня контроля — набор анализируемых ФВ, интерфейсов, модулей и подпрограмм.
3. Правильность интерпретации результатов и полнота/однозначность разметки предупреждений.

Оценка полноты поверхности атаки

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

Порядок анализа поверхности атаки:

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

Минимальные требования к полноте поверхности атаки:

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

Что включается в поверхность атаки:

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

Что НЕ включается в поверхность атаки:

• интерфейсы, доступные только пользователям, прошедшим идентификацию/аутентификацию и обладающим максимальными привилегиями из административных ролей ОО (при условии, что набор привилегий административной роли не является настраиваемым)
• интерфейсы, реализующие шифрование в соответствии с требованиями ФСБ России (но интерфейсы, ставшие доступными через эти интерфейсы — входят в поверхность атаки)

Внимание: если набор привилегий административной роли является настраиваемым — соответствующие интерфейсы включаются в поверхность атаки наименее привилегированного администратора.

Контроль перечня анализируемых модулей

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

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

Дополнительные требования (усиления) для уровня контроля 4

Усиление 1 — Анализ сборочной среды

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

Действия:

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

Если результат модификации — код на языке высокого уровня → выполнить статический анализ исходного и модифицированного кода по требованиям раздела САО (п. 4.2 Методики) для всех затронутых модулей.

Если результат модификации — интерпретируемый код (байт-код) или машинный код → выполнить экспертизу кода по требованиям раздела ЭКО (п. 4.4 Методики) для всех затронутых модулей.

Если суммарный объём байт-кода/машинного кода от модификации превышает 10 000 инструкций → дальнейшие исследования невозможны.

Усиление 2 — Модули среды исполнения интерпретируемых языков

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

Если модули среды исполнения отсутствуют в перечне → испытательная лаборатория самостоятельно добавляет их.

Усиление 3 — Периодически доступные интерфейсы

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

• служебные интерфейсы ОО, отвечающие за периодические обновления с удалённых источников

Если такие модули отсутствуют → испытательная лаборатория самостоятельно добавляет их.

Усиление 4 — Критичные участки кода

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

• участки кода, взаимодействующие с данными от потенциального нарушителя (парсеры, анализаторы, в т.ч. в составе кода веб-приложений)
• участки, имеющие высокую сложность (оценивается по цикломатической сложности Мак-Кейба, мере Холстеда, мере Овиедо и т.д.)

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

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

Усиление 5 — Инструментальная проверка полноты перечня модулей

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

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

Требования к результатам исследования

Для новой сертификации: разработка методики проведения исследований

Методика разрабатывается в соответствии с Положением о системе сертификации СЗИ (приказ ФСТЭК России от 03.04.2018 № 55) и должна содержать:

• для каждого вида исследований: состав и содержание исследований, средства анализа и их настройки, конкретный порядок действий
• учёт особенностей ОО: языки программирования, состав ФБ, механизмы защиты от исследований, типы внешних интерфейсов, архитектурные особенности

Описание поверхности атаки в методике (в графической нотации, не менее):

• интерфейсы непосредственной поверхности атаки
• модули, реализующие интерфейсы поверхности атаки
• подсистемы, включающие эти модули (микросервисы, логические группы функций, инфраструктурные компоненты)

Характеристики модулей (обязательно указывать):

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

Для исследований при внесении изменений в сертифицированный ОО

Методика не разрабатывается. Результаты ПОД.1 определяют порядок проведения исследований и включаются в протокол исследований.

Проверка артефактов результата

Формат для агента: артефакт считается принятым только при выполнении всех критериев; неприменимые пункты фиксируются с причиной.

Чек-лист проверки результатов перед отправкой

Формат: каждый пункт проверяется как выполнено / не выполнено / неприменимо.
Все пункты без статуса "неприменимо" должны иметь статус "выполнено".

Блок 1: Полнота исходных данных

• Предоставлена эксплуатационная документация на ОО (руководство пользователя, руководство администратора, формуляр).
• Предоставлен исходный код ОО в полном объёме.
• Предоставлена документация на сборочную среду и систему сборки.
• Предоставлен дистрибутив ОО.
• Предоставлены результаты выполнения процессов разработки по ГОСТ Р 56939-2024 (анализ архитектуры, поверхности атаки, композиционный анализ, анализ конфигураций, статический анализ, фаззинг, тестирование).
• Предоставлен перечень программных компонентов в формате CycloneDX 1.6 или 1.7 (JSON).
• Предоставлены тесты: системные, функциональные, регрессионные, модульные, фаззинг-тесты с описанием конфигураций.
• Тестовая документация содержит прослеживаемость ФБ и функциональных тестов, описание целей, процедур и ожидаемых результатов тестирования, а также фактические результаты (журналы, скриншоты).
• Для контейнерного ОО: предоставлены списки разрешённых действий (правил) взаимодействия компонентов.
• Для open-source компонентов: методики анализа поверхности атаки, статического анализа, тестирования и фаззинга с портала portal.linuxtesting.ru получены и учтены.

Блок 2: Оценка результатов разработчика

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

Блок 3: Поверхность атаки

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

Блок 4: Перечень анализируемых модулей

• Перечень анализируемых модулей включает модули среды исполнения для интерпретируемых языков/языков с промежуточным представлением (усиление 2).
• Перечень включает модули, реализующие периодически доступные интерфейсы и интерфейсы обновления (усиление 3).
• Перечень включает критичные участки кода с обоснованием выбора по сложности (усиление 4).
• При неполноте перечня — испытательная лаборатория самостоятельно добавила недостающие модули (задокументировано).

Блок 5: Сборочная среда (усиление 1)

• Проверена сборочная среда на наличие нестандартных инструментов модификации кода.
• Если нестандартная модификация есть: разработчик предоставил описание и обоснование безопасности.
• Описание модификации оценено на достоверность, полноту, актуальность, согласованность.
• Если результат модификации — высокоуровневый код: запланирован статический анализ по разделу САО.
• Если результат модификации — байт-код/машинный код: запланирована экспертиза по разделу ЭКО.
• Объём байт-кода/машинного кода от модификаций не превышает 10 000 инструкций (иначе — фиксируется невозможность продолжения).

Блок 6: Методика проведения исследований

• Разработана методика проведения исследований (или — при внесении изменений — оформлены результаты в протокол).
• Методика содержит для каждого вида исследований: состав, средства анализа и их настройки, порядок действий.
• Методика учитывает особенности ОО: языки программирования, типы интерфейсов, архитектуру.
• Методика содержит описание поверхности атаки в графической нотации (интерфейсы, модули, подсистемы).
• Для каждого модуля в нотации указаны: языки программирования, признак веб-сервиса, признак среды исполнения.

Задачи СИ по данному разделу

Рабочий перечень задач для Redmine: Перечень_задач_СИ_М3.md