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

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

а) анализ архитектуры ОО;

б) статический анализ ОО;

в) динамический анализ ОО;

г) экспертиза кода ОО.

Анализ архитектуры ОО включает:

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

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

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

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

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

В целях выявления НДВ, компрометирующих конструкций, недостатков архитектуры и кода должен проводится анализ комментариев в исходном коде ОО.

Испытательной лабораторией самостоятельно анализируются:

Проводится оценка соответствия конфигураций запуска отдельных контейнеров и групп (сетей) контейнеров, составляющих ОО в контейнерном исполнении, публично доступным рекомендациям по безопасности и минимизации полномочий (например, рекомендации ФСТЭК России, CIS, Kubernetes Security Best Practices и другие рекомендации), в том числе:

а) для ОО в контейнерном исполнении обеспечивается запуск контейнеров с полномочиями, минимально необходимыми для функционирования ОО, на уровне процессов хостовой операционной системы;

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

2. В ходе исследований контролируются наличие в составе ОО кода (либо генераторов такового кода), выполняющегося в контексте браузера (например, JavaScript, ActiveX, WebAssembly и других), а также учет кода в перечне программных компонентов и выполнение разработчиком в отношении него композиционного анализа.

Выявление динамической загрузки кода в контекст браузера не из состава (либо результатов генерации) ОО требуется расценивать в качестве основания для прекращения исследований ОО.

Выявление возможностей взаимодействия кода со стандартными интерфейсами доступа к камере, микрофону, экрану, уведомлениям, геопозиции, буферу обмена, методам оплаты и прочим требуется расценивать в качестве недостатка безопасности ОО.

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

Испытательная лаборатория учитывает отсутствие выбора и использования указанных опций в качестве недостатка безопасности ОО.

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

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

1. В ходе исследований анализируются рекомендованные ФСТЭК России либо применяемые разработчиком ОО методы автоматизированного динамического анализа, направленные на подтверждение устойчивости ОО к специфическим для данного типа ОО угрозам<12>.

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

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

При составлении контрольной выборки предупреждений следует руководствоваться следующими приоритетами:

Если доля неверно размеченных разработчиком предупреждений в составе контрольной выборки не превосходит 10 %, исследования ОО продолжаются после устранения разработчиком выявленных недостатков безопасности ОО.

Если доля неверно размеченных разработчиком ОО предупреждений превосходит 10 %, испытательной лабораторией выполняется статический анализ кода самостоятельно в соответствии с требованиями настоящей Методики либо принимается решение о невозможности проведения дальнейших исследований ОО.

1. В ходе исследований испытательной лабораторией проверяется, что состав анализируемых модулей дополнен модулями, реализующими ФБ ОО.

2. Испытательной лабораторией проверяется, что используемый статический анализатор отвечает требованиям национального стандарта Российской Федерации ГОСТ Р 71207-2024 «Защита информации. Разработка безопасного программного обеспечения. Статический анализ программного обеспечения. Общие требования».

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

1. В ходе исследований испытательной лабораторией проверяется, что состав тестируемых модулей дополнен модулями, составляющими непосредственную поверхность атаки ОО.

3. В ходе исследований испытательной лабораторией проверяется, что сбор тестового покрытия осуществляется по строкам исходного кода или по базовым блокам исполняемого кода для каждого тестируемого модуля ОО.

4. Испытательной лабораторией проверяется, что совокупный достигнутый процент тестового покрытия для каждого тестируемого модуля составляет не менее 25 %.

5. В ходе исследований испытательной лабораторией проверяется, что состав тестируемых модулей дополнен модулями, обеспечивающими реализацию ФБ ОО.

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

б) выполняется фаззинг-тестирование интерфейсов, для которых доступны специализированные фаззеры, адаптированные для тестирования конкретных типов интерфейсов (например, SMI, USB, SQL и другие интерфейсы), в том числе с использованием данных фаззеров. Фаззинг-тестирование интерфейсов веб-приложений выполняется специализированными фаззерами, адаптированными для решения такого класса задач.

Если применяются фаззеры, поддерживающие работу с коллекциями входных данных, для каждого из подлежащих фаззинг-тестированию интерфейсов должны быть сформированы и применены коллекции примеров входных данных. Коллекции должны вызывать использование различных функциональных возможностей тестируемого интерфейса. Формирование коллекций следует выполнять на основе публично доступных коллекций, использования генераторов коллекций, использования инструментов автоматического определения и формирования коллекций данных или экспертным способом.

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

Если применяются фаззеры, поддерживающие работу со словарями, то для интерфейсов, где применим такой подход, должны быть сформированы и применены словари лексем;

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

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

Если доля неверно размеченных разработчиком результатов фаззинг-тестирования в составе контрольной выборки не превосходит 10 %, исследования ОО продолжаются после устранения разработчиком выявленных недостатков безопасности ОО.

Если доля неверно размеченных разработчиком ОО результатов фаззинг-тестирования в составе контрольной выборки превосходит 10 %, испытательной лабораторией принимается решение о невозможности проведения дальнейших исследований ОО.

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

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

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

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

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

При достижении покрытия по строкам исходного кода не менее 90 % (по базовым блокам не менее 80 %) испытательная лаборатория может не учитывать дальнейший прирост покрытия для принятия решения о завершении фаззинг-тестирования.

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

Экспертиза кода ОО представляет собой ручной анализ участков исходного и восстановленного кода ОО сцелью выявления уязвимостей и НДВ (ЭКО).

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

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

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

а) использование потенциально опасных программных интерфейсов;

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

в) небезопасная загрузки библиотек;

г) некорректная обработка ошибок;

д) недостаточное ограничение прав доступа посторонних субъектов к временным файлам;

е) недостаточно полная проверка недопустимости присутствия во входных данных фрагментов программ на интерпретируемых языках (SQL-инъекции, XSS-атаки и другие типы атак);

ж) некорректная обработка длин буферов с данными;

з) некорректная обработка ситуаций, когда вместо обычного файла ОО предоставляется именованный канал, символическая ссылка или иной файловый объект специального вида;

и) ненадлежащее обеспечение корректности совместного доступа к глобальным данным в параллельных вычислениях;

к) ненадлежащее хранение аутентификационных данных в оперативной или внешней памяти;

л) переполнение буферов;

м) предоставление пользователям избыточной функциональности до аутентификации;

н) предоставление пользователям избыточных полномочий;

о) утечки чувствительных данных в журнальные файлы;

п) утечки оперативной памяти, файловых дескрипторов, графических ресурсов и других ошибок;

р) целочисленные переполнения;

с) наличие неиспользуемых программных компонентов: функций, процедур, переменных, классов и других компонентов;

т) наличие бинарных вставок и кодировок, в которых данные вставки представлены.

Определение программных ошибок должно осуществляться на основании сведений, содержащихся в соответствующих базах данных (например, Common Weakness Enumeration или Fortify Taxonomy: Software Security Errors), а также руководствах и стандартах, отражающих лучшие практики разработки безопасных программ (например, SEICERTC++ Coding Standard или The CERT Oracle Secure Coding Standard for Java).

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

В ходе экспертизы участков исходного текста и восстановленного кода должен быть зафиксирован перечень проверяемых программных ошибок и критерии их выявления.

Испытательной лаборатории требуется выполнять ручной анализ исходного кода с использованием инструментов, обеспечивающих навигацию на уровнях модулей (файлов) и структурных элементов языка программирования анализируемой программы. Если код написан на языке программирования, для которого отсутствуют инструменты с такими возможностями, допускается проводить исследование с помощью штатных утилит работы с текстами и файлами, такими как ls, find, grep, cat, sort и других утилит.

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

Инструментальные средства для исследования логической структуры программы должны обеспечивать:

а) определение сущностей программы: процедур, методов, классов, полей, глобальных переменных программы;

б) определение для каждой сущности: места определения в исходном файле, списка вложенных сущностей (методы и поля в классах, вложенные классы в процедурах и методах), объемлющей сущности-родителя;

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

г) определение связей между сущностями в иерархии классов программы: список родителей и наследников заданного класса, список методов, переопределяющих данный метод, список методов, реализующих данный абстрактный метод;

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

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