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

Куда я попал?

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

Подробнее

Наш канал

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

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

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

3.2

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

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

3. Подготовка к проведению исследований по выявлению уязвимостей и недекларированных возможностей (ПОД)
3.2. Подготовка исследовательского стенда (ПОД.2)
Задачами исследования являются:
а) подготовка исследовательского стенда, обеспечивающего проведение исследований в соответствии с представлением об ОО и разработанной методикой проведения исследований (ПОД.1);
б) подготовка специальных отладочных сборок ОО.
Исходными данными при проведении исследования являются:
- исходные данные в соответствии с требованиями пункта 2.3 настоящей Методики;
- сведения, полученные по результатам анализа документации и иных исходных данных (ПОД.1).
Требования к проведению исследования
Испытательной лабораторией формируется перечень сред выполнения исследований ОО, определенных в рамках КАО.2, ДАО.1 настоящей Методики и методикой функционального тестирования ОО, включающий не менее одной среды для каждого семейства сред функционирования.
Каждая операционная система, составляющая среду функционирования, формирует собственное семейство сред функционирования. Отнесение к семейству среды функционирования для сред, реализованных в формате средства контейнеризации, определяется парой «базовая технология средства контейнеризации — операционная система», в которой функционирует средство контейнеризации. Отнесение к семейству среды функционирования для сред, реализованных в формате средства виртуализации, определяется базовой технологией средства виртуализации.
При выборе среды проведения исследований из семейства следует экспертным методом определить среду, обладающую наименьшим защитным потенциалом.
Испытательной лабораторией выполняется контролируемая сборка дистрибутивов ОО с целью выявления:
взаимодействий сборочных сред и систем сборки с артефактами сборки, размещенными за пределами контролируемого разработчиком репозитория;
использования в сборочном процессе программного кода, в отношении которого анализ не был выполнен в требуемом виде и объеме;
включения в состав дистрибутива исполняемых файлов, не собираемых разработчиком из исходных кодов.
В случае выявления указанных фактов испытательная лаборатория расценивает их в качестве недостатков безопасности ОО и принимает решение о невозможности проведения дальнейших исследований ОО.
При подготовке исследовательского стенда проводятся проверки в отношении того, что:
в исследовательском стенде реализованы меры защиты, направленные на обеспечение целостности ОО и среды функционирования, а также на исключение возможности несанкционированного доступа к результатам проведения исследований;
все выбранные среды функционирования, а также инструментальные средства анализа и контроля, обеспечивающие проведение исследований ОО, развернуты и настроены в соответствии со своей эксплуатационной документацией. Испытательная лаборатория должна убедиться, что в ходе исследований не нарушаются условия эксплуатации сертифицированных сред функционирования ОО, в том числе операционных систем;
в подготовленных средах функционирования установлен и настроен дистрибутив ОО в соответствии с руководством по безопасной установке и настройке средства, приведенном в эксплуатационной документации.
В ходе установки ОО в среду функционирования и его настройки проводится контроль отсутствия недекларированных взаимодействий ОО с сетевыми ресурсами и ресурсами среды функционирования.
По результатам установки ОО проверяется, что был выполнен антивирусный контроль ОО. Антивирусный контроль ОО предусматривает анализ дистрибутива ОО, всех файлов установленного ОО, а также среды функционирования с использованием не менее двух сертифицированных средств антивирусной защиты от различных разработчиков с актуальными на момент проведения контроля базами данных признаков вредоносных компьютерных программ (вирусов). В случае отсутствия для среды функционирования ОО сертифицированных средств антивирусной защиты, могут применяться иные средства антивирусной защиты.
Затем проводится сравнение контрольных сумм дистрибутива ОО и исполняемых файлов установленного ОО с контрольными суммами, зафиксированными в документации ОО. Контрольные суммы должны быть рассчитаны в соответствии с национальным стандартом Российской Федерации ГОСТ 34.11-2012 «Информационная технология. Криптографическая защита информации. Функции хэширования» (алгоритм «Стрибог»). Контрольное суммирование выполняется средствами сертифицированной операционной системы либо сертифицированным средством контрольного суммирования.
В случае реализации ОО с использованием технологий контейнеризации и (или) виртуализации, контрольные суммы исполняемых файлов ОО рассчитываются относительно снимков состояния (снапшотов) файловых систем выполняющихся контейнеров и (или) виртуальных машин.
Дополнительные требования к исследованиям (усиления)
1. В ходе исследований проверяется, что разработчиком ОО подготовлены специальные сборки ОО со встраиванием инструментальных датчиков срабатывания ошибок при компиляции модулей, подвергаемых динамическому анализу, для каждой среды функционирования, включенной в исследования в соответствии с пунктом 3.2 настоящей Методики.
Испытательной лабораторией совместно с разработчиком ОО определяется перечень требуемых датчиков ошибок (ошибки работы с памятью, неопределенное поведение, нарушения потока управления и т.п.), исходя из технических возможностей, обусловленных используемыми в ОО языками программирования и средой функционирования.
Если система (системы) сборки для выбранной среды (сред) функционирования не позволяет штатным образом встраивать такие датчики, допускается не подготавливать специальную отладочную сборку ОО, а использовать в динамическом анализе любые другие средства встраивания датчиков срабатывания ошибок, такие как динамическое двоичное инструментирование и динамическая компоновка либо запуск интерпретатора с дополнительными опциями.
Если для языка исходных кодов ОО и среды его функционирования ряд типов датчиков срабатывания ошибок не применимы или отсутствуют, их использование не требуется.
2. Исследовательский стенд должен обеспечивать проведение динамического анализа ОО для каждой процессорной архитектуры среды функционирования ОО.
Требования к результатам исследования
По результатам подготовки исследовательского стенда в документации и акте отбора образцов ОО после завершения исследований ОО фиксируются значения контрольных сумм дистрибутива, исполняемых файлов и файлов исходных текстов (в соответствии с уровнем контроля) ОО.
Содержание ПОД.2:
Наименование исследования
ПОД.2
Уровень контроля
6: +
5: +
4: +

Наименование исследования
Дополнительные требования к ПОД.2
Уровень контроля
6:
5: 1
4: 1,2

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