Значительная вычислительная сложность статического и динамического анализа при проведении контроля отсутствия недекларированных возможностей программного обеспечения привели к необходимости их автоматизации. Одним из таких средств автоматизации является комплекс «Project Viewer», разработанный ООО «Агентство информационной безопасности «Максимальный стандарт». Результатами комплекса являются законченные представления каждого возможного пути выполнения программного обеспечения.
В настоящем материале процедуры контроля описываются применительно к 3 уровню руководящего документа «Защита от несанкционированного доступа к информации. Часть 1. Программное обеспечение средств защиты информации. Классификация по уровню контроля отсутствия недекларированных возможностей» (Гостехкомиссия России, 1999 г.) и ориентированы на применение комплекса «Project Viewer».
Первым этапом работы комплекса «Project Viewer» является формирование исходных данных для проведения последующих статического и динамического анализов исследуемого программного обеспечения (так называемый технологический этап). На данном этапе комплекс (подобно соответствующему компилятору, использованному при компиляции исследуемого программного обеспечения) осуществляет лексический и синтаксический анализ файлов исходных текстов, результатами которых является набор следующих таблиц:
На втором этапе работы комплекса производится вычислительный процесс, который на основании определенных критериев осуществляет:
Причиной, почему мы используем понятие «классифицируемый как подозреваемый на избыточность», является следующая. Мы понимаем, что анализируем «чужой программный код» (общепризнано, что разобраться в чужом программном коде гораздо сложнее, чем написать собственный), и предоставляем разработчику возможность перепроверить его результаты работы. Поэтому, результаты второго этапа работы комплекса (таблицы «Файлы, подозреваемые на избыточность», «Функциональные объекты, подозреваемые на избыточность», «Типы, подозреваемые на избыточность», «Информационные объекты, подозреваемые на избыточность») мы передаем для анализа разработчику исследуемого программного обеспечения. Как правило, по результатам такого анализа, разработчиком значительная часть классифицированного «как подозреваемое на избыточность» удаляется из исходных текстов. Но бывают и случаи, когда разработчик указывает нам на ошибки в работе комплекса. В этом случае факт ошибочного срабатывания комплекса нами анализируется, и в комплекс вносятся соответствующие исправления. Цель второго этапа – обеспечить максимальную «чистоту» исходных текстов перед проведением следующего этапа вычислительного процесса – формирования представления каждого возможного пути выполнения программного обеспечения и его анализа. В данном материале не рассматриваются вопросы проведения контроля состава и содержания документации (комплекс предоставляет шаблонную форму для заполнения экспертом), а также контроля соответствия исходных текстов программного обеспечения его объектному (загрузочному) коду (поскольку для выполнения данного вида контроля используется штатная среда разработки программного обеспечения и официальная инструкция по сборке). При положительном результате выполнения контроля соответствия исходных текстов программного обеспечения его объектному (загрузочному) коду проводятся иные виды контроля, предусмотренные руководящим документом «Защита от несанкционированного доступа к информации. Часть 1. Программное обеспечение средств защиты информации. Классификация по уровню контроля отсутствия недекларированных возможностей» (Гостехкомиссия России, 1999 г.).
Контроль исходного состояния программного обеспечения подразумевает, что при идентификации объекта сертификации (тематических исследований), заключающейся в расчете указанным разработчиком способом (технологическим средством) контрольных сумм модулей исполняемого кода и исходных текстов исследуемого программного обеспечения, полученные данные расчетов при последующем сравнении совпадут с данными, приведенными в документации на исследуемое программное обеспечение. Цель контроля – убедиться, что для проведения исследований передано официальное программное обеспечение, задокументированное разработчиком установленным образом.
В связи с отсутствием требований о применении того или иного алгоритма (средства) расчета значений контрольных сумм файлов, а также о необходимости указания в программной документации значений контрольных сумм и размеров файлов, явно предъявляемых к разработчику программного обеспечения, эксперт данный вид контроля проводит с применением средств, рекомендованных системой сертификации.
Комплекс «Project Viewer» предоставляет эксперту возможность автоматизированного контроля исходного состояния программного обеспечения с применением отдельной утилиты (как интегрируемой в состав комплекса, так и имеющей самостоятельную поставку), осуществляющей расчет контрольных сумм по алгоритму md5 и выводящей результаты фиксации в следующем виде:
Рис.1. Вид отчетной формы «Контроль исходного состояния»
Результаты работы комплекса «Project Viewer» (отчетные таблицы) при желании экспертом могут быть переведены в формат MS Excel.
Контроль полноты и отсутствия избыточности исходных текстов исследуемого программного обеспечения на уровне файлов подразумевает, что в представленном для исследований наборе файлов исходных текстов отсутствуют файлы, не участвующие в сборке программного обеспечения и не использующиеся в процессе его функционирования.
При построении исходных таблиц для последующего статического анализа в зависимости от месторасположения файла в каталоге проекта, комплекс «Project Viewer» присваивает файлу уникальный порядковый номер, в последствии используемый как уникальный идентификатор файла (например, в таблице «Подключения файлов»).
В первоначальном процессе вычислений, осуществляемых комплексом «Project Viewer» в рамках контроля полноты и отсутствия избыточности исходных текстов программного обеспечения на уровне файлов, используются таблицы «Исходные файлы», «Библиотечные файлы» и «Подключения файлов».
Таблица «Исходные файлы» отражает характеристики текста программы и содержит для каждого файла следующие сведения:
Таблица «Библиотечные файлы» содержит сведения о применении динамических библиотек в процессе сборки программного обеспечения и отражает полный путь к местонахождению файла анализируемой динамической библиотеки.
Таблица «Подключения файлов» отражает подключения файлов исходных текстов в файле проекта.
Процесс вычислений при контроле полноты и отсутствия избыточности исходных текстов исследуемого программного обеспечения на уровне файлов заключается в сопоставлении сведений о файлах, представленных в таблицах «Исходные файлы» и «Библиотечные файлы», со сведениями, содержащимися в таблице «Подключения файлов». При отсутствии о файле, указанном в таблицах «Исходные файлы» и «Библиотечные файлы», сведений в таблице «Подключения файлов», полный путь к его местонахождению указывается в таблице «Файлы, подозреваемые на избыточность». Таким образом, осуществляется классификация файлов в качестве «файлов, подозреваемых как избыточные». Таблица «Файлы, подозреваемые на избыточность» передается разработчику программного обеспечения с целью прокомментировать полученные результаты исследований. При удалении файла из набора файлов исходных текстов разработчик в графе «Комментарий» отражает данный факт (например, пишет «Удалено»). Если разработчиком доказывается ошибочная классификация файла как «подозреваемого как избыточного», в графе «Комментарий» разработчиком программного обеспечения приводятся сведения об использовании файла (цель, место обращения). По результатам анализа ошибочной классификации файлов в комплекс «Project Viewer» вносятся исправления.
С целью визуализации результатов контроля на основании таблицы «Подключения файлов» средствами комплекса «Project Viewer» может быть отображено Дерево «Подключения файлов».
Контроль полноты и отсутствия избыточности исходных текстов программного обеспечения на уровне функциональных объектов (процедур, функций) подразумевает выявление в составе исходных текстов контролируемого программного обеспечения функциональных объектов (процедур, функций), явно не используемых в процессе компиляции и работы изделия.
В процессе вычислений, осуществляемых комплексом «Project Viewer» в рамках контроля полноты и отсутствия избыточности исходных текстов программного обеспечения на уровне функциональных объектов, используются таблицы «Объявления функций», «Определения функций», «Вызовы функций». Если функция определена, но нигде не вызывается, она классифицируется как «подозреваемая на избыточность», и сведения о ней заносятся в таблицу «Функциональные объекты, подозреваемые на избыточность». Таблица «Функциональные объекты, подозреваемые на избыточность» передается для анализа и корректировки исходных текстов разработчику исследуемого программного обеспечения.
С целью визуализации результатов контроля на основании таблицы «Вызовы функций» средствами комплекса «Project Viewer» может быть отображено Дерево «Вызовы функций».
Вычислительный процесс, осуществляемый комплексом «Project Viewer», заключается в формировании таблицы «Связи функциональных объектов по управлению», характеризующей отношения вызова и достижимости между произвольными парами функциональных объектов, определенных в таблице «Определения функций». Если между функциональными объектами отсутствуют отношения непосредственного вызова, сведения о данной паре не заносятся в таблицу «Связи функциональных объектов по управлению». Отношения вызова характеризуются так называемыми точками вызова, фиксирующими точные местоположения вызовов в исходном тексте исследуемого программного обеспечения. Точные местоположения вызовов определяются номером строки и столбца расположения оператора вызова в файле исходного текста исследуемого программного обеспечения. Это обуславливается тем, что любая функция может вызвать другую функцию много раз, т.е. оператор вызова может располагаться во многих строках исходного текст.
При анализе экспертом должно учитываться, что элементы в иерархии вызовов могут находиться в одной из следующих взаимосвязей:
Таблица «Связи функциональных объектов по управлению» позволяет эксперту ответить на следующие вопросы:
Результаты, полученные на данном этапе тематических исследований, должны подлежать сравнению с описанием, приведенным в программной документации на исследуемое программное обеспечение.
Таблица "Связи функциональных объектов по управлению" не содержит информации о последовательности вызовов других функций из текущей (точках ветвления выполняемого потока), а отображает только информацию о том, какие функции могут быть вызваны из данной функции. Информация о последовательности вызовов приведена в таблице «Маршруты выполнения функциональных объектов на уровне функций».
Вычислительный процесс, осуществляемый комплексом «Project Viewer», заключается в формировании таблицы «Связи функциональных объектов по информации», характеризующей процесс совместного использования одних информационных объектов в различных функциях исследуемого программного обеспечения.
Таблица «Связи функциональных объектов по информации» отображает факты совместного использования информационных объектов различными функциональными объектами.
Таблица «Связи функциональных объектов по информации» позволяет эксперту ответить на следующие вопрос: в каких ещё функциях, кроме текущей может быть модифицирован данный информационных объект.
На подготовительном этапе к проведению тематических исследований нами проверяется работоспособность исследуемого программного обеспечения. Цель работы – убедиться, что динамический анализ в принципе может быть выполнен.
В процессе подготовки исходных данных (при формировании таблиц «Определения информационных объектов» и «Использования информационных объектов»), а также в процессе проведения статического анализа на этапе контроля связей функциональных объектов по информации осуществляется не только идентификация переменных, но и фиксация фактов передачи данных между функциональными объектами.
Применение отладчика позволяет протестировать поведение исследуемого программного обеспечения при граничных значениях переменных, выявить потенциально возможные уязвимости защиты, выявить существующие логические ошибки, дефекты выполнения, наличие конкуренции за ресурсы, редкие граничные состояния исследуемого программного обеспечения.
Формирование перечня маршрутов выполнения функциональных объектов осуществляется на этапе подготовки комплексом «Project Viewer» исходных данных для проведения последующих статического и динамического анализов исследуемого программного обеспечения. Формирование содержимого таблицы «Маршруты выполнения функциональных объектов на уровне функций» происходит на основе таблиц «Определение функций», «Объявление функций» и «Использование функций». Строится граф в памяти программы по каждой функции. Граф содержит очередность вызова функций, ветвление вызовов. В таблицу «Маршруты выполнения функциональных объектов на уровне функций» записываются пары: какая функция вслед за какой может быть вызвана. С помощью этой таблицы можно восстановить граф вызовов функций.
С целью визуализации результатов формирования перечня выполнения функциональных объектов на основании таблицы могут быть отображены Графы «Маршруты выполнения функциональных объектов на уровне функций» для каждой функции.
Контроль выполнения функциональных объектов (процедур, функций) подразумевает внесение по определенному алгоритму в исходный код исследуемого программного обеспечения так называемых элементов отладочной печати («мониторов»), сборку «лабораторной» версии программного обеспечения, выполнение программного обеспечения в соответствии с официальной эксплуатационной документацией, фиксацию поведения исследуемого программного обеспечения в заявленных разработчиком режимах функционирования.
Контроль выполнения функциональных объектов (процедур, функций) запускается отдельно для каждого исполняемого бинарного файла из состава анализируемого программного обеспечения, соответственно таблице «Точки входа» (см. ниже).
«Мониторы» обеспечивают выдачу во внешний файл (dinamicf) информации о проходе контрольных точек. Совокупность информации о прохождении контрольных точек образует сведения о реальных маршрутах выполнения исследуемого программного обеспечения. Контрольными точками считаются входы во все функциональные объекты исследуемого программного обеспечения. «Мониторы» устанавливаются средствами комплекса «Project Viewer» перед первым оператором каждого функционального объекта исследуемого программного обеспечения.
Структура файла dinamicf следующая: первая цифра в строке – номер функции из таблицы определения функций (соответствующего «монитора»), вторая цифра – идентификатор потока, из которого выводится монитор. Если поток не указан, значит, он не поменялся и соответствует потоку предыдущей функции. Поток (поток выполнения, Thread) – это последовательность выполняемых команд процессора. Процесс, в котором выполняется приложение, может делиться на несколько потоков.
На основе файла dinamicf, строятся файлы potok-*, символ * определяет идентификатор потока. В каждом таком файле описана динамика выполнения одного потока приложения. Файл potok-* содержит в каждой строке только одну цифру – номер функции («монитора») из таблицы «Определения функций».
На этапе статического анализа мы получаем вероятностную картину поведения исследуемого программного обеспечения и проверяем, как это соответствует утверждениям разработчика. На этапе динамического анализа фиксируется реальное поведение исследуемого программного обеспечения в заявленных разработчиком режимах функционирования и производится сравнение реального и вероятностного поведения исследуемого программного обеспечения.
Вычислительный процесс, осуществляемый комплексом «Project Viewer», заключается в сопоставлении сведений, содержащихся в файлах potok-*, с данными таблицы «Маршруты выполнения функциональных объектов на уровне функций» как одного из результатов выполнения статического анализа. Для каждого файла potok-* формируется таблица «Результаты динамического анализа на уровне функций» (Приложение 20), содержащая номер функции (из файла potok-*), координату определения функции в исходном тексте и столбец «Статический маршрут», в который заносится результат сопоставления фактического маршрута статическому.
Результатом анализа являются таблицы «Результаты динамического анализа на уровне функций» (Приложение 20) и «Перечень фактических маршрутов выполнения функциональных объектов на уровне функций» (Приложение 21).
Таблица «Перечень фактических маршрутов выполнения функциональных объектов на уровне функций» (Приложение 21) формируется в единственном экземпляре одновременно c таблицами «Результаты динамического анализа на уровне функций» и содержит уникальные пары фактических переходов между функциональными объектами, выявленные при последовательном разборе содержимого файлов potok-*.
