Сегодняшняя нормативная, методическая и инструментальная база выявления недекларированных возможностей программ не позволяет эффективно обеспечивать безопасность программных ресурсов. Данной проблемой занимаются испытательные лаборатории Минобороны, ФСБ и ФСТЭК России, однако большинство уязвимостей обнаруживаются не в соответствии с нормативными документами, а порой даже вопреки им. Мало того, имеется тенденция увеличения числа уязвимостей в программном коде.

Проблемой защиты программ занимаются испытательные лаборатории Минобороны, ФСБ и ФСТЭК России, которые в своей работе опираются на Руководящий документ (РД) Гостехкомиссии России по контролю над недекларированными возможностями [1]. Однако опыт выявления авторами более 20 закладок и тысяч некорректностей кода показал, что большинство из них обнаружены не только не в соответствии с указанным документом, но и порой вопреки ему. Существующая нормативная, методическая и инструментальная база [2] выявления недекларированных возможностей в программном обеспечении не позволяет эффективно обеспечивать безопасность программ.

Объективные причины появления уязвимостей в программных продуктах заключаются в чрезвычайно высокой структурной сложности программного кода, динамичности развития версий и легкости модификации кода [3]. К этому можно добавить проблему достоверной идентификации преднамеренно созданных программных закладок, несовершенство нормативно-методической базы и отставание инструментальной базы сертификационных испытаний. Скажем, в отличие от средств антивирусного контроля, отсутствуют средства гарантированного выявления программных закладок в структурно сложном программном обеспечении. Полувековые теоретические изыскания [4] так и не обеспечили разработки математического аппарата для оценки степени безопасности программного обеспечения, основанного на сертификационных испытаниях с целью подтвердить отсутствие программных закладок. Поэтому снижается качество разработки отечественных программных средств в государственных учреждениях, как и уровень доверия к зарубежным продуктам.

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

Сертификационные испытания

Ограничения Руководящего документа

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

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

  • Значительная вычислительная сложность статического и динамического анализа. Фактически, с ростом сложности программного продукта динамический анализ становится неразрешимой задачей и превращается в формальную процедуру, отнимающую много времени и ресурсов у экспертов [3].
  • Отсутствие или недостаточность проверок, непосредственно связанных с безопасностью изделия. Например, не упоминается сигнатурный анализ в требованиях к испытаниям программ ниже второго уровня контроля (т.е. программ, обрабатывающих секретную и конфиденциальную информацию). Не выдвигаются требования к содержимому базы потенциально опасных конструкций, что делает неэффективными методы сигнатурного анализа. Нет механизмов выявления ошибок кодирования, связанных с переполнением буфера, гонками, вызовом функций из чужого адресного пространства. Отсутствует очистка памяти и т.д.
  • Неопределенность действий экспертов и достоверности получаемых результатов. Отсутствуют декларированные способы, нацеленные на построение перечня маршрутов при выполнении функциональных объектов (ветвей). Нет механизмов определения полноты покрытия и его достаточности при динамическом анализе. Отсутствуют рекомендации по выявлению недекларированных возможностей при анализе, например, матрицы связей по информации.

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

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

Чтобы получить аттестат аккредитации ФСТЭК по выявлению недекларированных возможностей, испытательная лаборатория должна иметь сертифицированные инструментальные средства («АИСТ», EMU). Здесь возникают два вопроса.

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

Во-вторых, следует ли в обязательном порядке сертифицировать такие средства? Из-за длительности процесса сертификации средства тестирования уязвимостей никогда не смогут гарантировать результат согласно принципу «снаряд-броня». Совершенно очевидно, что эти средства не позволяют оперативно включать признаки современных уязвимостей кода в меняющейся среде защиты и в новых средах программирования.

Скажем, для анализа кода на языке Си рекомендуется программа «АИСТ-С» (непререкаемый «авторитет» в области анализа кода на наличие недекларированных возможностей). Однако, несмотря на ее очевидные достоинства, установлено, что она некорректно обрабатывает структуры объектно-ориентированных программ, например не анализирует конструктор и деструктор. Не анализируются и исходные тексты, подключаемые директивами #include — лишь проверяется исходный текст программы. Мало того, нормальная работа анализатора возможна, только если объем исходных текстов не превышает нескольких мегабайт: блок-схемы программ строятся некорректно уже для программ объемом более нескольких килобайт. Те же ограничения относятся к построению матрицы связей по информации, да и отчеты не в полной мере соответствуют требованиям РД по недекларированным возможностям. Но главное отставание от реалий дня состоит в том, что это средство вообще не имеет базы сигнатур и умеет анализировать лишь программы на языке Cи/C++.

Организационные проблемы сертификации

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

  • Если в изолированной системе нет программных каналов утечки информации, то так ли необходимо наличие сертификата на отсутствие недекларированных возможностейи и не достаточно ли проверок на доступность (готовность, качество) изделия? Например, почему проверкам на отсутствие недекларированных возможностей не подлежит ряд сетевых экранов?
  • В нормативной документации нет четкого ответа, как организовать сертификацию программных продуктов с постоянно изменяющимся кодом. Если в продукте обнаружены уязвимости, то должно ли быть приостановлено действие сертификата?
  • Как определить уровень глубины выявления недекларированных возможностей: на уровне приложения, базового программного обеспечения, операционной среды, программно-аппаратном? Если имеются исходные коды только для программной оболочки (например, сетевого экрана, функционирующего в операционной среде), то как поступать со средой?
  • Что делать, если нет исходных кодов? А ведь некоторые проверки можно (и даже желательно) проводить и без оного. Например, анализ механизмов парольной защиты целесообразно осуществлять в отладочном режиме на уровне исполняемых модулей: тогда наиболее эффективно выявляются низкоуровневые деструктивные функции.
  • Что делать, если сертификацию нельзя провести по правовым или техническим причинам? Например, неизвестен правообладатель продукта или фрагментов кода, разработчик находится за рубежом и распространяет продукт бесплатно, нет спецификации на продукт, утеряны исходные тексты. Не пора ли ввести систему спецпроверки программ по аналогии с аппаратными средствами [3]?

Способы выявления уязвимостей

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

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

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

  1. Формирование политики безопасности программ, которая может соотноситься с техническими условиями на объект информатизации;
  2. Сигнатурно-эвристический анализ исходного и выполнимого кода по потенциально опасным операциям и некорректностям кодирования;
  3. Анализ подсистем безопасности (трассировка подсистемы парольной защиты) и др.;
  4. Функциональное, стрессовое, нагрузочное тестирование и тестирование производительности;
  5. Структурный анализ избыточности дистрибутива и контроль над целостностью;
  6. Анализ наличия скрытых каналов;
  7. Формирование ограничений на использование продукта в соответствии с политикой безопасности;
  8. Формирование условий обновления и модификации политики безопасности.

Таблица 1.

СРЕДСТВА ДЛЯ ПРОВЕДЕНИЯ ИСПЫТАНИЙ

Среди специализированных средств, которые могут использоваться при сертификационных испытаниях, следует выделить: «АИСТ-С» (ЦБИ), продукты третьего ЦНИИ МО РФ [6], а также отдельные разработки ряда испытательных лабораторий и разработчиков (таблица 2). В таблице 3 указаны используемые в мировой практике средства, которые целесообразно применять при тестировании программного обеспечения в дополнение к средствам, реализующим требования РД по недекларированным возможностям.

Таблица 2.

Таблица 3.

ВОЗМОЖНОСТЬ ПЕРЕХОДА К ГОСТ 15408

Помимо традиционных РД с 2004 года введен в действие ГОСТ Р ИСО/МЭК 15408-2002 [5,7], представляющий собой аутентичный перевод международного стандарта «Общие критерии». Практическому применению данного стандарта при сертификационных испытаниях должны предшествовать разработка и утверждение пакета профилей защиты и заданий по обеспечению безопасности. Профили защиты должны послужить заменой РД, регламентирующих порядок сертификации продуктов конкретного класса в соответствии с требованиями к безопасности информации. В свою очередь, задание по обеспечению безопасности определяет требования к конкретному изделию.

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

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

С другой стороны, более ценным представляется обратный подход: движения не от РД по недекларированным возможностям к «Общим критериям», а от «Общих критериев» к новому нормативно-методическому документу, регламентирующему выявление уязвимостей кода, учитывающему апробированные методы и особенности процесса поиска уязвимостей. Соответствующие методики (например, разработанные в рамках НИР для разных систем сертификации и интегрированные в единый процесс сертификации по ГОСТ Р ИСО/МЭК 15408-2002) могли бы обеспечить внутреннее единство и методическую полноту таких испытаний.

***

Сложившееся противоречие между природой реальных уязвимостей программного кода и нормативно-методической и инструментальной базой испытаний на отсутствие недекларированных возможностей и программных закладок требует решения. Необходимы разработка и внедрение новых методов и средств выявления уязвимостей программного кода, оценки угроз информационной безопасности [8-10].

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

Развитие нормативной базы возможно в рамках использования новых стандартов и руководящих документов по линии «Общих критериев».

Литература

  1. Руководящий документ. Защита от несанкционированного доступа к информации. Часть 1. Программное обеспечение средств защиты информации. Классификация по уровню контроля отсутствия недекларированных возможностей. М.: Гостехкомиссия России, 1998.
  2. Калайда И.А. Недекларированные возможности в программном обеспечении средств защиты информации. Jet Info, 2000, № 8.
  3. Марков А.С., Щербина С.А. Испытания и контроль программных ресурсов. InformationSecurity, 2003, № 6.
  4. Дастин Э., Рэшке Д., Пол Д. Автоматизированное тестирование программного обеспечения: внедрение, управление, эксплуатация. М.: Лори, 2003.
  5. ГОСТ Р ИСО/МЭК 15408-2002. Информационная технология. Методы и средства обеспечения безопасности. Критерии оценки безопасности информационных технологий. Части 1, 2, 3. М.: ИПК «Изд-во стандартов», 2002.
  6. Методическое руководство по оценке качества функционирования информационных систем. М.: Изд-во 3 ЦНИИ МО РФ, 2003.
  7. ГОСТ РВ 51719-2001. Испытания программной продукции. М.: ИПК «Изд-во стандартов», 2001.
  8. Руководящий документ. Безопасность информационных технологий. Критерии оценки безопасности информационных технологий. Части 1, 2, 3. — М.: Гостехкомиссия России, 2002.
  9. Скрытые каналы, // Jet Info, 2002, № 11.
  10. Хогланд Г., Мак-Гроу Г. Взлом программного обеспечения: анализ и использование кода. М.: Вильямс, 2005.

Алексей Марков (amarkov@npp-bit.ru, a.markov@npo-echelon.ru), Сергей Миронов, Валентин Цирлов — сотрудники Испытательного центра НПП «БИТ», (Москва).

Примеры выявленных программных закладок

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