Соответствие требованиям

Куда я попал?

SECURITM это SGRC система, автоматизирующая процессы в службах информационной безопасности. SECURITM помогает построить и управлять ИСПДн, КИИ, ГИС, СМИБ/СУИБ, банковскими системами защиты.
А еще SECURITM это место для обмена опытом и наработками для служб безопасности.

Подробнее

Наш канал

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

Страна: Россия

Методическая документация ФСТЭК

4.3

Для проведения оценки соответствия по документу войдите в систему.

Список требований

4. Проведение исследований по выявлению уязвимостей и недекларированных возможностей
4.3. Динамический анализ объекта оценки (ДАО)
Динамический анализ ОО включает:
а) тестирование модулей ОО (ДАО.1);
б) фаззинг-тестирование ОО (ДАО.2).
4.3.1 Общие требования к проведению всех видов динамического анализа ОО
Для 4-5 уровней контроля тестирование модулей ОО (ДАО.1) и фаззинг-тестирование ОО (ДАО.2) должны выполняться в отношении специальных сборок ОО со встроенными датчиками срабатывания ошибок. Специальные отладочные сборки ОО подготавливаются на этапе ПОД.2 в рамках выполнения требований усиления 1 (с учетом уровня контроля).
Перечень используемых датчиков фиксируется в протоколе исследований.
Испытательной лабораторией фиксируются факты выявления механизмов, встроенных в исходный или исполняемый код ОО и препятствующих проведению динамического анализа. В случае выявления в ходе исследований таковых механизмов, эти механизмы и защищенные ими программные модули (участки кода) должны быть проанализированы при проведении экспертизы кода (ЭКО). Если суммарный объем исходных кодов данных механизмов и защищенных модулей (участков кода) превосходит 10 000 строк, делается вывод о невозможности проведения дальнейших исследований.
Перечень исследований при динамическом анализе ОО представлен в таблице 4.
Шифр
ДАО.1
Наименование исследований
Тестирование модулей ОО
Уровень контроля
6: +
5: 1
4: 1, 2, 3, 4, 5
Шифр
ДАО.2
Наименование исследований
Фаззинг-тестирование ОО
Уровень контроля
6: +
5: 1
4: 1, 2, 3, 4, 5
Примечание:
«+» – исследования подлежат выполнению для соответствующего уровня контроля;
«цифра» – дополнительные требования к исследованиям для соответствующего уровня контроля
4.3.2. Тестирование модулей ОО (ДАО.1)
Задачей исследования является выявление недостатков безопасности ОО, в том числе ошибок реализации функций безопасности ОО, самостоятельно и в результате анализа результатов выполнения процессов разработки ОО в соответствии с ГОСТ Р 56939-2024, методом и инструментами автоматического динамического тестирования модулей ОО со сбором покрытия.
Исходными данными при проведении исследования являются:
- исходные данные в соответствии с требованиями пункта 2.3 настоящей Методики, в первую очередь подпункта «ж» пункта 2.3 настоящей Методики;
- сведения, полученные по результатам выполнения ПОД.1;
- испытательный стенд, полученный по результатам выполнения ПОД.2.
Требования к проведению исследования
При тестировании модулей оцениваются исходные данные согласно пункту 3.1 настоящей Методики, а также проводится оценка реализации разработчиком ОО следующих требований:
а) выполняется автоматическое тестирование<16> всех модулей, реализующих ФБ ОО;
б) выполняется тестирование модулей для каждой процессорной архитектуры, поддержка которой обеспечивается исследовательским стендом;
в) выполняется сбор тестового покрытия по функциям исходного или исполняемого кода для каждого тестируемого модуля ОО;
г) выполняется анализ журналов тестирования для каждого тестируемого модуля на предмет наличия сбоев и нарушений требований, проверяемых тестами, в том числе порождаемых датчиками срабатывания ошибок.

<16> Тесты могут быть реализованы на различных уровнях – системном, интеграционном, модульном.
При проведении исследований оценивается число модулей из состава подлежащих тестированию модулей ОО, в отношении которого не выполнены требования пункта 4.3.2 настоящей Методики. В исследовании ДАО.1 не учитываются тесты, в ходе выполнения которых не вызываются функции подлежащих тестированию модулей ОО.
Если разработчиком ОО выполняется исследование модулей ОО в рамках деятельности Центра исследований безопасности системного ПО и в ходе исследования ОО выполнено тестирование подлежащих тестированию модулей ОО в объеме программы исследований безопасности, то требования пункта 4.3.2 настоящей Методики в отношении данных модулей считаются выполненными.
В противном случае:
- если число таких модулей не превосходит 5, испытательной лабораторией проводится тестирование модулей самостоятельно в соответствии с требованиями настоящей Методики либо принимается решение о невозможности проведения дальнейших исследований ОО;
- если число таких модулей превосходит 5, испытательной лабораторией принимается решение о невозможности проведения дальнейших исследований ОО.
Если предоставленные разработчиком ОО исходные данные отвечают требованиям пункта 4.3.2 настоящей Методики, испытательной лабораторией проводится выборочная проверка результатов анализа тестов, выявивших сбои и нарушение требований. Выборочная проверка выполняется в отношении контрольной выборки тестов, составленной по следующему принципу:
- в состав выборки включается не менее 50 тестов, выявивших сбои и нарушение требований;
- в состав выборки включаются тесты, относящиеся не менее чем к 5 различным модулям;
- в состав выборки включаются все тесты, выявившие сбои и нарушение требований, явно связанные с безопасностью регрессий<17>, не исправленных в текущей версии модуля ОО.
Если доля неверно размеченных разработчиком результатов тестов в составе контрольной выборки не превосходит 10 %, исследования ОО продолжаются после устранения разработчиком выявленных недостатков безопасности ОО.
Если доля неверно размеченных разработчиком ОО результатов тестов в составе контрольной выборки превосходит 10 %, испытательная лаборатория принимает решение о невозможности проведения дальнейших исследований ОО.

<17> Под регрессиями понимаются тесты, подтверждающих наличие известных недостатков безопасности, выявленных в предыдущих версиях модуля.
Дополнительные требования к исследованиям (усиления)
1. В ходе исследований испытательной лабораторией проверяется, что состав тестируемых модулей дополнен модулями, составляющими непосредственную поверхность атаки ОО.
2. Испытательной лабораторией проверяется, что для тестируемых модулей с открытым исходным кодом, для которых определены методики тестирования, указанные в подпункте «м» пункта 2.3 настоящей Методики, тестирование выполнено в соответствии с требованиями этих методик.
3. В ходе исследований испытательной лабораторией проверяется, что сбор тестового покрытия осуществляется по строкам исходного кода или по базовым блокам исполняемого кода для каждого тестируемого модуля ОО.
4. Испытательной лабораторией проверяется, что совокупный достигнутый процент тестового покрытия для каждого тестируемого модуля составляет не менее 25 %.
5. В ходе исследований испытательной лабораторией проверяется, что состав тестируемых модулей дополнен модулями, обеспечивающими реализацию ФБ ОО.
Требования к результатам исследования
Если предоставленные разработчиком результаты тестирования модулей ОО, проводимого при разработке безопасного ПО, соответствуют требованиям пунктов 3.1 и 2.3 настоящей Методики, испытательной лаборатории разрешается повторно использовать результаты анализа при оформлении материалов исследований.
Результаты исследований фиксируются в материалах исследований в объеме, соответствующем требованиям пункта 5.2 настоящей Методики. Дополнительно требуется зафиксировать в материалах исследований в формате электронных приложений структурное покрытие для каждого тестируемого модуля.
Содержание ДАО.1:
Наименование исследования
ДАО.1
Уровень контроля
6: +
5: +
4: +
Наименование исследования
Дополнительные требования к ДАО.1
Уровень контроля
6:
5: 1
4: 1, 2, 3, 4, 5
4.3.3. Фаззинг-тестирование ОО (ДАО.2)
Задачей исследования является выявление недостатков безопасности ОО самостоятельно и в результате анализа результатов выполнения процессов разработки ОО в соответствии с ГОСТ Р 56939-2024 методом и инструментами фаззинг-тестирования и сбора покрытия ОО.
Исходными данными при проведении исследования являются:
- исходные данные в соответствии с требованиями пункта 2.3 настоящей Методики;
- сведения, полученные по результатам выполнения ПОД.1;
- испытательный стенд, полученный по результатам выполнения ПОД.2;
- сведения о покрытии модулей, достигаемом по результатам выполнения ДАО.1.
Требования к проведению исследования
При проведении фаззинг-тестирования оцениваются исходные данные согласно пункту 3.1 настоящей Методики, а также проводится оценка реализации разработчиком ОО следующих требований:
а) выполняется фаззинг-тестирование интерфейсов, относящихся к поверхности атаки ОО. Не требуется выполнять фаззинг-тестирование в отношении кода, выполняющегося в контексте браузера. Допускается проводить фаззинг-тестирование только в одной в среде функционирования, обеспечивающей наиболее эффективное выполнение тестирования;
б) выполняется фаззинг-тестирование интерфейсов, для которых доступны специализированные фаззеры, адаптированные для тестирования конкретных типов интерфейсов (например, SMI, USB, SQL и другие интерфейсы), в том числе с использованием данных фаззеров. Фаззинг-тестирование интерфейсов веб-приложений выполняется специализированными фаззерами, адаптированными для решения такого класса задач.
Если применяются фаззеры, поддерживающие работу с коллекциями входных данных, для каждого из подлежащих фаззинг-тестированию интерфейсов должны быть сформированы и применены коллекции примеров входных данных. Коллекции должны вызывать использование различных функциональных возможностей тестируемого интерфейса. Формирование коллекций следует выполнять на основе публично доступных коллекций, использования генераторов коллекций, использования инструментов автоматического определения и формирования коллекций данных или экспертным способом.
Если применяются фаззеры, не поддерживающие работу с коллекциями входных данных, то для каждого из подлежащих фаззинг-тестированию интерфейсов должны быть сформированы и применены правила порождения входных данных. Правила должны вызывать использование различных функциональных возможностей тестируемого интерфейса.
Если применяются фаззеры, поддерживающие работу со словарями, то для интерфейсов, где применим такой подход, должны быть сформированы и применены словари лексем;
в) выполняется для каждой тестируемой цели (интерфейс, участок кода) анализ журналов фаззера на предмет фактов зависаний и сбоев работы ОО, в том числе порождаемых датчиками срабатывания ошибок, и на предмет подтверждения воспроизведения данных фактов в штатном режиме функционирования ОО.
Испытательной лабораторией оценивается число целей из состава подлежащих фаззинг-тестированию, в отношении которых не выполнены требования пункта 4.3.3 настоящей Методики.
Если разработчик ОО выполняет исследование модулей ОО в рамках деятельности Центра исследований безопасности системного ПО и в ходе исследования ОО выполнил фаззинг-тестирование подлежащих фаззинг-тестированию модулей ОО в объеме программы исследований безопасности, требования пункта 4.3.3 настоящей Методики в отношении данных модулей считаются выполненными.
Если число таких целей не превосходит 3, испытательной лабораторией выполняется фаззинг-тестирование самостоятельно в соответствии с требованиями настоящей Методики либо принимается решение о невозможности проведения дальнейших исследований ОО.
Если число таких целей превосходит 3, испытательной лабораторией принимается решение о невозможности проведения дальнейших исследований ОО.
Если предоставленные разработчиком ОО исходные данные отвечают требованиям текущего пункта настоящей Методики, испытательной лабораторией проводится проверка результатов фаззинг-тестирования, выявивших воспроизводимые сбои и зависания целей.
Если доля неверно размеченных разработчиком результатов фаззинг-тестирования в составе контрольной выборки не превосходит 10 %, исследования ОО продолжаются после устранения разработчиком выявленных недостатков безопасности ОО.
Если доля неверно размеченных разработчиком ОО результатов фаззинг-тестирования в составе контрольной выборки превосходит 10 %, испытательной лабораторией принимается решение о невозможности проведения дальнейших исследований ОО.
Испытательной лабораторией самостоятельно разрабатывается не менее 2 новых фаззинг-цели и выполняется их фаззинг-тестирование в составе ОО либо значительно дорабатывается не менее 3 существующих комплектов фаззинг-тестов для целей в составе ОО (например, улучшение коллекции, расширение словаря, добавление нового датчика срабатывания ошибок, учет сложных зависимостей мутируемых параметров). При выборе подлежащего тестированию кода следует в приоритетном порядке выполнять фаззинг-тестирование целей, наиболее значимых для безопасности ОО, с приведением обоснования данного выбора.
Дополнительные требования к исследованиям (усиления)
1. В ходе проведения исследований испытательной лабораторией проверяется, что используемый разработчиком ОО фаззер обеспечивает применение генетических алгоритмов фаззинг-тестирования за счет инструментирования кода в случае, если доступны инструменты, позволяющие осуществлять такое фаззинг-тестирование с учетом языков программирования, компиляторов и среды функционирования ОО. При этом допускается выполнять инструментирование:
как по исходным текстам, так и по бинарному (в том числе промежуточному) представлению;
по бинарному представлению, если модуль, написанный на интерпретируемом языке программирования, компилировался в промежуточное представление или подвергался принудительной компиляции в исполняемый код («Ahead of Time» компиляция).
2. Испытательной лабораторией проверяется выполнение в дополнение к условиям, указанным в других дополнительных требованиях, при фаззинг-тестировании ОО как минимум одного из следующих условий:
а) для фаззеров, подсчитывающих число найденных уникальных путей, число уникальных путей, найденных фаззером, должно не менее чем в два раза превышать число образцов входных данных, поданных на вход фаззеру;
б) для фаззеров, подсчитывающих достигнутое покрытие, процент покрытия, достигнутого фаззером, должен не менее чем в два раза превышать процент покрытия, достигаемый в результате подачи на вход фаззеру стартовых образцов входных данных.
При достижении покрытия по строкам исходного кода не менее 90 % (по базовым блокам не менее 80 %) испытательная лаборатория может не учитывать дальнейший прирост покрытия для принятия решения о завершении фаззинг-тестирования.
3. В ходе проведения исследований испытательной лабораторией проверяется, что для тестируемых модулей с открытым исходным кодом, для которых определены методики фаззинг-тестирования, указанные в подпункте «н» пункта 2.3 настоящей Методики, фаззинг-тестирование выполнено в соответствии с требованиями этих методик.
4. Испытательной лабораторией проверяется, что фаззинг-тестирование выполнялось в отношении специально подготовленных синтетических целей, сформированных с целью эффективного тестирования участков кода, выделенных в ходе выполнения требований усиления 4 ПОД.1.
При фаззинг-тестировании интерфейсов ОО допускается ограничиваться фаззинг-тестированием в отношении специально подготовленных синтетических целей. Достаточность состава выделенных целей определяется испытательной лабораторией непосредственно в ходе проведения исследований ДАО.2 и фиксируется с обоснованием в протоколах исследований.
Функции-обертки обеспечивают вызов тестируемых участков кода целей, конвертируя мутируемые фаззером данные во входные параметры тестируемых функций в соответствии со спецификациями интерфейсов (протоколов), типов данных и контекста выполнения тестируемых функций в составе ОО.
5. Испытательной лабораторией проверяется, что тестирование каждой фаззинг-цели продолжается до состояния, когда в течение не менее двух часов фаззер не находит нового пути или отсутствует прирост покрытия при условии, что на вход подаются уникальные мутированные данные.
Требования к результатам исследования
Если предоставленные разработчиком результаты тестирования модулей ОО, проводимого при разработке безопасного ПО, соответствуют требованиям пунктов 3.1 и 2.3 настоящей Методики, испытательной лаборатории разрешается повторно использовать результаты анализа при оформлении материалов исследований.
Результаты исследований фиксируются в материалах исследований в объеме, соответствующем требованиям пункта 5.2 настоящей Методики. Дополнительно требуется зафиксировать в материалах исследований в формате электронных приложений структурное покрытие для каждого тестируемого модуля.
Дополнительно требуется зафиксировать в материалах исследований:
- параметры сборки каждой фаззинг-цели;
- принципы формирования коллекции, правил, словарей;
- достигнутое структурное покрытие для каждой фаззинг-цели.
Испытательной лабораторией в протоколах исследований фиксируются результаты, полученные по пункту 4.3.3 настоящей Методики, которые в дальнейшем передаются разработчику ОО с целью развития применяемого разработчиком комплекта тестов.
Содержание ДАО.2:
Наименование исследования
ДАО.2
Уровень контроля
6: +
5: +
4: +
Наименование исследования
Дополнительные требования к ДАО.2
Уровень контроля
6:
5: 1, 2
4: 1, 2, 3, 4, 5

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