Аудит программного кода по требованиям безопасности

Проблема безопасности программного кода

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

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

Косвенные экономические потери из-за уязвимости ПО очень высоки. Согласно статистике Computer Economics, годовые потери из-за вирусных эпидемий, использующих уязвимости систем, превышают 16 млрд. долларов, а в результате компьютерных атак мировая экономика потеряла в 2007 г. более 50 млрд. долларов. Надо понимать, что это только вершина айсберга!

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

Указанная проблема явилась толчком к широкому развитию во многих странах аудита безопасности программного кода, получившего название security code reviews. Процедуры security code reviews могут быть реализованы в системе менеджмента качества крупных корпораций (например, в SDL-системе компании Microsoft), либо отдаются на откуп независимым лабораториям, специализирующимся на тестировании безопасности прикладных программных продуктов и их обновлений. Как правило, аудит безопасности кода проводят в рамках комплексного тестирования программных продуктов, реже при аудите безопасности информационной системы.

Активное внедрение технологий аудита безопасности кода поддерживается рядом международных объединений и правительственных проектов в области ИБ. К наиболее известным следует отнести деятельность OWASP в области создания методологии анализа безопасности кода и деятельность MITRE в области стандартизации уязвимостей программ (проект CWE).

Понятие аудита безопасности программного кода

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

Важной особенностью технологий security code reviews является то, что основной задачей аудита является выявление не всевозможных уязвимостей, а только уязвимостей кода, которые могут быть использованы злоумышленником, то есть представлять угрозу ИБ системы.

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

Некорректности кодирования как основой класс уязвимостей

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

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

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

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

Методы аудита безопасности кода

Выделяют несколько методов аудита безопасности кода:

1. Просмотр (инспекция) кода вручную;
2. Статический анализ кода по шаблону;
3. Динамический анализ выполнения кода.

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

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

Статический анализ кода по шаблону заключается в использовании средств автоматизации поиска и анализа потенциально опасных  конструкций кода (сигнатур) в исходном коде программ. Данный метод эффективен при поиске несложных уязвимостей  и немаскируемых закладок, таких как переполнение буфера, парольные константы или «логические бомбы». К автоматизированным средствам проведения статического метода по шаблону относят сканеры уязвимостей кода PREfix, PREfast, АК-ВС, UCA, FlawFinder, ITS4, RATS, FxCop.

Современные сканеры кода позволяют в той или иной степени автоматизировать:

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

Исследования авторов показало, что выявление уязвимостей с использованием средств автоматизации позволяет сократить время проверок в десять-двадцать раз. Пример результатов аудита кода с помощью сканера уязвимостей кода АК-ВС представлен на рис.2.

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

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

• мониторинг работы программы и анализ трассы;
• ручной просмотр в отладочном режиме работы подсистем безопасности.

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

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

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

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

Планирование аудита безопасности программного кода

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

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

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

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

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

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

Сертификация или аудит кода?

В заключении рассмотрения технологии аудита безопасности кода следует сказать о возможности ее развития в нашей стране. Дело в том, что России повышение доверия к ПО регулируется, главным образом, путем его сертификации на отсутствие недекларированных возможностей в соответствии с руководящим документом Гостехкомиссии России. Требования руководящего документа и процедуры аудита безопасности кода в ряде случаев совпадают (табл.1). В частности, оба подхода предполагают наличие исходных текстов, спецификаций и соответствующей компиляционной среды. Из таблицы видно, что российская нормативная база ориентирована на контроль целостности и полномаршрутное тестирование всего программного продукта (что на практике нереально) с целью выявления ошибок вообще, в то время как процедуры security code reviews направлены на скорейшее выявление реализуемых уязвимостей программного кода. Здесь приходится констатировать факт, что продукты, сертифицированные по 3 и 4 уровню контроля отсутствия недекларированных возможностей, не обладают достаточным уровнем доверия, так как неочевидно, подвергались ли они проверкам по безопасности кода или нет.

Табл.1

1 — 4-ый уровень контроля выполняется при сертификации средств защиты конфиденциальной информации, остальные – для случая защиты государственной тайны;

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

3 — проводится только в потенциально опасном фрагменте кода с целью выяснения возможности реализации уязвимости;

красным цветом выделены проверки, выполняемые в ходе динамического анализа.

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

Выводы

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

Следует напомнить, что вопросы обеспечения безопасности ПО регламентируются введенными в нашей стране в 2007 году национальными стандартами в области информационной безопасности: ГОСТ ИСО 17799-05 и ГОСТ ИСО 27001-06.

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

Статья опубликована в журнале Information Security, 2008,  №2 и №3.

Авторы: Алексей Марков и Валентин Цирлов