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

Куда я попал?

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

Подробнее

Наш канал

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

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

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

3.1.2

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

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

3. Подготовка к проведению исследований по выявлению уязвимостей и недекларированных возможностей (ПОД)
3.1. Анализ документации и иных исходных данных (ПОД.1)
Требования к проведению исследования:
В ходе анализа документации и иных исходных данных проверяются исходные данные на соответствие требованиям настоящей Методики в части достоверности, полноты, актуальности, согласованности (отсутствие противоречий).
При проведении исследований оцениваются представленные разработчиком ОО результаты анализа ОО, проводимого в соответствии с ГОСТ Р 56939-2024, иными национальными стандартами в области защиты информации, с целью использования в качестве материалов исследований на предмет:
а) правильности выбора и настройки разработчиком средств выявления уязвимостей и НДВ;
б) соответствия полноты проводимых исследований требованиям уровня контроля, включая полноту набора анализируемых функциональных возможностей, интерфейсов, модулей и подпрограмм (функций);
в) правильности интерпретации результатов, полученных от средств выявления уязвимостей и НДВ, полноты и однозначности разметки предупреждений.
Испытательной лабораторией оценивается полнота поверхности атаки<2> ОО, представленной разработчиком в исходных данных. Для этого выполняется анализ поверхности атаки ОО с учетом методик анализа поверхности атаки заимствованных компонентов с открытым исходным кодом, указанных в пункте 2.3 настоящей Методики, и проводится сопоставление полученных результатов.

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

<3> В качестве потенциальных нарушителей рассматриваются в том числе все штатные пользователи ОО, обладающие произвольными ролями, за исключением оговоренных в пункте 3.1 настоящей Методики частных случаев.
К интерфейсам ОО, непосредственно доступным для атаки потенциальным нарушителям, рекомендуется относить служебные интерфейсы ОО, в том числе функционирующие ограниченно по времени, доступные периодически, отладочные интерфейсы, интерфейсы удаленного управления, интерфейсы обновления ОО или используемых баз данных<4>.

<4> Например, интерфейс ОО в виде TCP-сокета, однократно создаваемый ОО раз в сутки с целью сетевого доступа к централизованному репозиторию решающих правил и их загрузки, интерфейс периодического доступа к службе точного времени, интерфейс доступа к DHCP-серверу, интерфейс доступа к LDAP-каталогу и другие интерфейсы.
К числу интерфейсов, доступных для атаки потенциальным нарушителям в ходе штатного функционирования, не относят интерфейсы, доступные только пользователям, успешно прошедшие идентификацию и аутентификацию и обладающим максимальными привилегиями<5> из административных ролей ОО. Данное правило не применяется, если набор привилегий административной роли (в том числе наиболее привилегированной) является настраиваемым.

<5> Например, «главный администратор», «суперпользователь», «root» и аналогичные роли, в том числе – отвечающие за развертывание и приведение ОО в сертифицированное состояние в соответствии с эксплуатационной документацией ОО.
Интерфейсы, доступные пользователям, обладающим административной ролью, допускающей настройку набора привилегий, относятся к интерфейсам ОО, доступным для атаки потенциальным нарушителем из числа наименее привилегированных администраторов<6>.

<6> Например, к сетевому веб-интерфейсу администрирования ОО имеют доступ все пользователи, обладающие ролью «Администратор». При этом имеется возможность доступа пользователя к конкретным разделам административного портала: анализ записей в хранилище инцидентов, прямое взаимодействие с базой решающих правил, возможность создания новых ролей/пользователей и другие возможности, определяемые набором привилегий, доступных конкретному пользователю.
Интерфейсы, реализующие шифрование в соответствии с требованиями ФСБ России, не относятся к интерфейсам ОО, доступным для атаки потенциальным нарушителям. При этом интерфейсы, которые становятся доступными посредством использования интерфейсов, реализующих шифрование, относятся к интерфейсам ОО, доступным для атаки потенциальным нарушителям<7>.

<7> Например, сетевой веб-интерфейс администрирования ОО, доступный пользователям сети, доступ к которому защищается с использованием СКЗИ, тем не менее, является поверхностью атаки для потенциального внутреннего нарушителя из числа пользователей и наименее привилегированных администраторов ОО за исключением модулей, непосредственно входящих в состав средства криптографической защиты информации.
По результатам анализа документации и иных исходных данных оценивается состав и полнота полученных для испытуемого ОО результатов выполнения процессов разработки в соответствии с ГОСТ Р 56939-2024 в целях учета этих результатов при составлении методики проведения исследований.
При проведении дальнейших исследований ОО испытательная лаборатория контролирует перечень анализируемых интерфейсов и модулей ОО с целью выявления недекларированных интерфейсов, модулей и реализуемого ими функционала, в том числе неиспользуемого кода и неиспользуемых функциональных возможностей ОО.

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