Сертификация программ без исходных текстов

Рост количества уязвимостей в программных системах объективно обусловлен высокой структурной сложностью программных систем, а также динамичностью версий и технологий, не позволяющих получить гарантированные оценки безопасности ПО за приемлемое время. Оценка соответствия требованиям по безопасности ПО решается путем его сертификации на отсутствие недекларированных возможностей либо, при отсутствии таких требований, путем аудита безопасности кода. В первом случае основным ориентиром является руководящий документ Гостехкомиссии России [1], а во втором могут использоваться открытые международные стандарты: PCI DSS/PA-DSS, OWASP Top Ten, CWE.

Документ Гостехкомиссии России содержит требования к программной документации, контролю исходного состояния, статическому и динамическому анализу исходных текстов, которые являются неотъемлемой частью процесса сертификационных испытаний [2]. В других случаях требования к наличию исходных текстов ПО может и не быть, как, например, при сертификационных испытаниях по «Общим критериям» и аудите банковских приложений на соответствие PCI DSS, разумеется если речь не идет о защите государственной тайны.

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

До недавнего времени двумя основными подходами к исследованию безопасности ПО без исходных текстов были метод тестирования черного ящика (например, стресс-тестирование в нештатных режимах работы ПО) и метод обратного инжиниринга (reverse-engineering), включающий дизассемблирование бинарного кода с попыткой воссоздания логики работы исходного программного приложения [3-5]. Оба подхода чрезвычайно трудоемки и не регламентированы нормативными документами, однако имеются и альтернативные подходы.

Повышению доверия к ПО способствуют следующие мероприятия:

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

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

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

Оценка возможности декомпиляции

Широкое распространение сегодня получили платформы, позволяющие выполнить высококачественную декомпиляцию, восстанавливающую исходные тексты программы с полным сохранением иерархии функциональных и информационных объектов, их связей и управляющих структур. Это относится к языкам программирования, имеющим промежуточное представление в виде байт-кода и виртуальную машину для его выполнения, например байт-код виртуальной машины Oracle JVM (Java Virtual Machine), для которой известны реализации языков Java, NetRexx, Ruby (JRuby), JavaScript (Rhino), Python (Jython), Groovy, PHP (Quercus), Clojure, Scala и др.

В ряде случаев высококачественную декомпиляцию можно провести для платформы. Net, где применяется CLR (Common Language Runtime), в которой возможно исполнение кода, написанного на языках программирования ASP.Net, C#, Visual Basic. Net, C++/CLI, F#, J#, JScript. Net, Windows PowerShell и др. Особенностью этой платформы, а также других подобных, например ActionScipt Virtual Machine и Microsoft P-CODE Virtual Machine, является то, что исходные коды компилируются не в команды микропроцессора, а в промежуточное высокоуровневое бинарное представление, которое уже на этапе выполнения будет преобразовано в инструкции процессора.

Для подтверждения возможности использования при сертификации текстов программ, полученных в результате декомпиляции, в НПО «Эшелон" был проведен эксперимент с программными продуктами, проходящими тематические исследования или сертификационные испытания в аккредитованной испытательной лаборатории. В качестве программных платформ были выбраны виртуальная машина Java (Java Virtual Machine, JVM), язык программирования Java, среда CLR и C#. Также были сформированы тестовые программы, содержащие актуальные для 2010 года уязвимости. Испытывались программы с исходными текстами и декомпилированные. В качестве инструментария по выявлению уязвимостей использовался сертифицированный анализатор безопасности программного кода АК-ВС, поддерживающий международную классификацию уязвимостей CWE.

Эксперимент показал (табл. 1) высокую корреляцию результатов проверок исходных текстов и текстов, полученных в результате декомпиляции, для платформ JVM (Java) и. Net (C#). В частности, в рамках эксперимента была доказана возможность выявления уязвимостей кода, а также проведения основных проверок (и формирования отчетов) в рамках статического анализа на отсутствие недекларированных возможностей по второму уровню контроля.

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

Пример потенциально опасного фрагмента программы на C#

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

Дополнительные проверки выполнимого кода

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

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

Основные проверки:

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

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

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

Установка дополнительных средств защиты

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

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

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

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

***

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

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

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

Литература

1. Руководящий документ. Защита от несанкционированного доступа к информации. Часть 1. Программное обеспечение средств защиты информации. Классификация по уровню контроля отсутствия недекларированных возможностей. — Гостехкомиссия России, 1999.
2. Марков А. С., Миронов С. В., Цирлов В. Л. Выявление уязвимостей в программном коде //Открытые системы, № 12, 2005.
3. Eilan E. Reversing: Secrets of Reverse Engineering. — Wiley City: Wiley Publishing, 2005. — 595 p.
4. Kalinovsky A. Covert Java: Techniques for Decompiling, Patching, and Reverse Engineering — Indianapolis: Sams, 2004. – 288 p.
5. Sutton M, Greene A., Amini P. Fuzzing: Brute Force Vulnerability Discovery. -: Addison-Wesley Professional, 2007. – 576 p.

Александр Барабанов, Алексей Марков (a.markov@npo-echelon.ru), Андрей Фадин — сотрудники «НПО «Эшелон» (Москва).