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

Куда я попал?

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

Подробнее

Наш канал

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

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

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

4.3.2

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

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

4. Проведение исследований по выявлению уязвимостей и недекларированных возможностей
4.3. Динамический анализ объекта оценки (ДАО)
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

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