Научные публикации

Особенности контроля НДВ при проведении сертификационных испытаний

В 1999 году Гостехкомиссией России был введен в действие Руководящий документ (РД), который регламентирует контроль программного обеспечения (ПО) средств защиты информации (СЗИ) на предмет отсутствия недекларированных возможностей (НДВ). Документ разработан в дополнение к РД и ориентирован на специалистов испытательных лабораторий, разработчиков и заказчиков. На данный момент работа испытательных лабораторий основывается на требованиях изложенных в РД НДВ Часть 1, хотя вторая часть этого документа так и не появилась.

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

К таким особенностям относятся следующие:

  • 1) недостаточность документации, необходимой для проведения исследований на НДВ;
  • 2) отсутствие в существующих автоматизированных системах анализа (анализаторах) эффективных методик поиска программных закладок в рамках статического и динамического анализов;
  • 3) отсутствие в РД критериев оценки необходимости применения ручного анализа.

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

Отсутствие полноты документации является неприятным фактом, который уже принято воспринимать как данность. Среди предписанных РД документов не найти ни одного, который бы мог ответить на закономерный вопрос эксперта: «является ли найденная в исходных текстах возможность кода заложенной в архитектуру ПО в рамках проекта?». Все документы, подготавливаемые разработчиками, по своему содержанию, могут предоставить информацию о логике программы и о конкретных алгоритмах, которые имеют более высокий уровень абстракции, чем требуется при поиске недокументированной возможности. Например, если она (недокументированная возможность), реализована в виде какой-нибудь вспомогательной функции, (осуществляющей, к примеру, удаление следующего за текущим байта памяти, или увеличение счетчика на единицу), то скорее всего ни в логическом описании, ни в алгоритме она не будет отражена. И с точки зрения описания логики работы программы – это корректно, так как излишняя детализация описания затрудняет восприятие архитектуры проекта. Для сертификационных же исследований такая детализация является не столько желательной, сколько необходимой. Разрешение этой сложности возможно осуществить следующим образом: во-первых, автоматизировать процесс разработки документации, отражающей более высокий уровень детализации, чем используемые в данный момент документы, во-вторых включить в РД требование к детализации документации до уровня функциональных объектов. Такое решение позволит снизить сложность работы эксперта и повысить общий уровень качества программного обеспечения.

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

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

Условно разделим закладки на два типа:

  • 1) закладки, которые активизируются сразу после запуска программы;
  • 2) закладки, которые активизируются в случае выполнения определенных условий (пассивные).

Закладки, активизирующиеся сразу же после запуска, или в результате выполнения стандартных функций программы, выявляются в результате сопоставления фактических маршрутов выполнения функциональных объектов и маршрутов, построенных в процессе проведения статического анализа. Закладки, которые активизируются специальными вызовами, могут быть обнаружены следующим способом. В ходе статического анализа исходных текстов выявляются места ветвления программы (условные операторы if, операторы цикла for, while, и др.) и записываются, допустим, в БД. После того, как в каждый оператор ветвления будет вставлен датчик срабатывания и будет проведен динамический анализ, сформируется трасса вызовов. При сравнении статических данных, содержащихся в БД с результатами, зарегистрированными в журнале трассы, возможно, определить места ветвления, по которым трасса проходит только по одной ветви, по 2-м ветвям, либо вообще не проходит. Те места ветвления, в которых были пройдены все ветки, по определению не содержат не вызванных программных закладок. Те места ветвления, которые не были пройдены ни по одной из ветвей целесообразно считать нерабочими (контроль таких ветвей, возможно, производить по информации об избыточных функциональных объектах). Даже, если в них и находится закладка, то она никогда не сработает. Те места ветвления, которые имеют в своем составе часть ветвей пройденных, а часть не пройденных, как раз и должны быть подвергнуты ручному анализу на предмет наличия, либо отсутствия программной закладки в не пройденной части. Таким образом, повышение эффективности контроля программных продуктов на отсутствие недекларированных возможностей, достижимо обеспечением следующих условий:

  • 1) применение автоматизированных средств, в процессе формирования документации, обеспечивающей детализацию на уровне функциональных объектов;
  • 2) предоставление заказчиком документов, содержащих описание ПО на уровне функциональных объектов;
  • 3) использование новых критериев оценки функциональных объектов на предмет содержания программных закладок;
  • 4) внесение в РД требований по использованию критериев оценки необходимости выполнения экспертом ручного анализа.