Статический анализ кода: что могут инструментальные средства?

Соответственно, анализ кода по требованиям ИБ позволяет значительно повысить качество разработки. Ни у кого не возникает вопроса, зачем выполнять регрессионное тестирование перед вводом новой функциональности системы в эксплуатацию. Анализ кода по требованиям безопасности – не менее важный этап разработки, чем комплексное тестирование ПО. По оценке исследователей Гарвардского университета, исправление ошибки, выявленной на этапе тестирования, в среднем стоит $960, а ошибки, обнаруженной на этапе эксплуатации, – $7600. Не говоря уже о том, какой ущерб может нанести злоумышленник эксплуатацией уязвимости.

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

Инструментальные средства анализа кода

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

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

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

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

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

Рис. 1. Магический квадрант Гартнера – производители решений для тестирования ПО на соответствие требованиям ИБ

В целом для инструментальных средств статического анализа кода характерны:

• Ложные срабатывания (false positive) – выделение фрагмента кода как уязвимого, хотя на самом деле он уязвимости не содержит. С одной стороны, чем больше ложных срабатываний, тем более тщательный анализ выполняется, с другой – ложные срабатывания отбирают у программистов много времени на то, чтобы разобраться и понять, что выделенный фрагмент безопасен.
• Пропущенные ошибки (false negative) – уязвимости в программном коде, которые не были найдены при анализе.

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

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

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

1. Качественные технологии и алгоритмы для глубокого анализа кода и выявления всех уязвимостей
2. Регулярно обновляемая база правил с возможностями гибкой настройки и расширения
3. Предоставление исчерпывающих обоснований наличия уязвимости и подробных рекомендаций по её устранению
4. Сопоставление результатов анализа при повторном сканировании отредактированного кода (выделение исправленных, неисправленных, вновь появившихся уязвимостей)
5. Поддержка большого числа языков программирования
6. Интеграция со средами разработки, системами контроля версий и системами отслеживания ошибок
7. Функционал, обеспечивающий связь между командами разработчиков и экспертов, отвечающих за безопасность
8. Минимальное количество ложных срабатываний
9. Представление результатов анализа в удобном для восприятия (в том числе непрофессионалами) виде
10. Наличие средств автоматического составления отчётов
11. Возможность проводить анализ кода удалённо

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

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

HP Fortify

Компания HP предлагает несколько продуктов для тестирования ПО на соответствие требованиям ИБ:

• HP Fortify Static Code Analyzer (SCA) – инструмент для статического анализа кода. Определяет причины уязвимостей, приоритизирует результаты и даёт подробные рекомендации по исправлению кода. Статический анализ предоставляется для 21 языка программирования.
• HP Web Inspect – инструмент для динамического анализа кода. Он проводит тестирование приложений, имитирующее реальные атаки. Обладает средствами управления историей тестирования.
• HP WebInspect Real-Time – имитирует атаку средствами HP WebInspect, предоставляя пользователю возможность наблюдать за работой приложения на уровне кода. Полученные сведения используются в качестве основы для динамического анализа.
• HP WebInspect Enterprise – платформа по управлению веб-приложениями, позволяющая проводить распределённое оценивание безопасности приложений и руководить процессом тестирования.
• HP Fortify Runtime Analyzer – инструмент для централизованного управления угрозами безопасности на уровне компании. Защищает уже выпущенные приложения от попыток несанкционированного доступа. Регистрирует записи о событиях в Fortify Software Security Center (SSC).
• HP Fortify SSC – веб-инструмент для централизованного управления безопасностью приложения. Поддерживает единую базу данных об уязвимостях. Позволяет эффективно организовать совместную работу разработчиков и специалистов по безопасности.

HP Fortify SCA дает хорошее качество сканирования. На наш взгляд, это лучшее сканирование по сочетанию «время работы/количество ложных срабатываний и пропущенных ошибок». В общей сложности это инструментальное средство было протестировано более чем на 15 тыс. CLOC (Count Lines of Code) различного кода, реализованного на разных языках. Количество пропущенных ошибок приближается к нулю, те же, которые есть, в настоящее время просто нельзя идентифицировать автоматически. Для повышения точности сканирования, то есть уменьшения количества ложных срабатываний, можно модифицировать набор предоставляемых правил. Сделать это просто, так как интерфейс ИС удобен, а язык правил доступен.

IBM AppScan

Линейка решений от компании IBM для аудита ПО на соответствие требованиям информационной безопасности состоит из следующих продуктов:

• IBM AppScan Standard – инструмент для динамического анализа кода («чёрный ящик»). Предназначен для поиска уязвимостей в работающем ПО, применяется на последних этапах разработки и после выпуска приложения. Относительно несложен в установке и настройке. Позволяет отправлять сообщения о найденных уязвимостях в систему отслеживания ошибок. При помощи расширения JavaScript Security Analyzer может проводить гибридный анализ JavaScript-кода.
• IBM AppScan Source – инструмент для статического анализа кода («белый ящик»). Он предназначен для специалистов по информационной безопасности, требует высокой квалификации, зато формирует более полную картину уязвимостей с привязкой к исходному коду. Обеспечивает взаимодействие между сотрудниками, ответственными за безопасность приложений, и разработчиками. Обладает средствами интеграции с распространёнными средами разработки, что позволяет отслеживать уязвимости на ранних стадиях. Работает только в качестве дополнения к IBM AppScan Enterprise. Статический анализ поддерживает 21 язык программирования.
• IBM AppScan Enterprise – веб-инструмент для централизованного динамического тестирования приложений, учёта и наглядного представления степени риска, которому они подвергаются. Позволяет вычислять метрики и осуществлять быстрое сканирование. Предназначен, в том числе, для неспециалистов, позволяет составлять наглядные отчёты по результатам сканирования. При наличии AppScan Source может проводить тестирование по методу «прозрачного ящика» (Glass Box), сопоставляя результаты динамического и статического анализов. Обладает средствами интеграции с системой мониторинга безопасности QRadar.

В состав AppScan Source входят инструменты для поиска и анализа уязвимостей в исходном коде (Source for Analysis), автоматизации процесса разработки (Source for Automation) и интеграции со средами разработки, такими как Visual Studio и Eclipse (Source for Development). Также в решение входит база знаний об уязвимостях и способах их устранения (Source Security Knowledgebase) и средство для централизованного обмена информацией об уязвимостях (Source Enterprise Server). Подробно рассмотрим AppScan Source for Analysis, а также перечислим основные понятия, используемые при анализе кода в рамках AppScan.

Данные, которые использует AppScan, организованы следующим образом:

1. Приложение (application) содержит один или несколько проектов и соответствующие им атрибуты.
2. Проект состоит из множества файлов (в том числе с исходным кодом), а также содержит сопутствующую информацию (например, параметры конфигурации).
3. Атрибуты – характеристики приложения, позволяющие наглядно представить результаты сканирования. Пользователь может самостоятельно определять атрибуты.

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

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

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

• Уязвимость – участок исходного кода, содержащий ошибки, позволяющие злоумышленнику заставить приложение осуществлять незапланированные действия, что приводит к несанкционированному доступу к данным, повреждению системы и т.д.
• Исключение типа I – подозрительный участок исходного кода, скорее всего, являющийся уязвимостью, при этом для отнесения его к этому классу не хватает информации. Например, степень подверженности атаке может зависеть от параметров использования динамических элементов или вызова библиотечных функций, о которых у AppScan недостаточно сведений.
• Исключение типа II – подозрительный участок исходного кода, для которого невозможно оценить вероятность подверженности атаке.

С целью обеспечения полной безопасности приложения нужно проводить дополнительные исследования для отнесения исключений либо к уязвимостям, либо к ложным срабатываниям, причём для обработки исключений типа II, как правило, требуется больше усилий. В дальнейшем для краткости мы будем называть результаты сканирования AppScan «уязвимостями», понимая под этим собственно уязвимости и исключения I и II типов.

Статический анализ IBM AppScan дает нормальное качество, однако складывается впечатление, что база правил здесь несколько более скудная, нежели у HP Fortify. Некоторые уязвимости ищутся по «старым» шаблонам. По соотношению «скорость сканирования/количество ложных срабатываний и пропущенных ошибок» ИС сильно уступает HP Fortify: количество ложных срабатываний меньше, но больше пропущенных уязвимостей. Как мы уже отмечали выше, ложные срабатывания при отсутствии пропусков ошибок лучше, нежели пропущенные ошибки с минимальным количеством ложных срабатываний.

Positive Technologies Application Inspector

Инструментальное средство использует методы динамического и статического анализа для поиска уязвимостей. За счет этого, как говорят разработчики продукта, минимизируется количество ложных срабатываний. Application Inspector может анализировать приложения, созданные на разных языках программирования и платформах (Java, .NET, PHP, JavaScript, мобильные платформы и т.п.).

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

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

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

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

Veracode

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

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

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

Checkmarx

Еще одно инструментальное средство анализа кода, которое пытается завоевать рынок. Продукт показывает достойные результаты сканирования, однако складывается впечатление, что его база уязвимостей менее полная, чем у конкурентов, в частности, у HP Fortify. Мы проводили сравнение Checkmarx с HP Fortify SCA в 5 независимых проектах. Время работы средств было сопоставимым, однако количество выявленных действительных уязвимостей у HP Fortify оказалось значительно больше. Это свидетельствует о том, что Checkmarx пропускает уязвимости, которые можно идентифицировать автоматически.

Также следует отметить, что даже представители производителя при демонстрации системы тратят некоторое время на ее развертывание, тогда как HP Fortify не требует никакой специальной подготовки для инсталляции.

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

InfoWatch APPERCUT

Отдельно стоит отметить еще одно ИС, которое позиционируется как инструментальное средство в помощь разработчикам и специалистам в области ИБ, – InfoWatch APPERCUT. Мы намеренно не называем его инструментальным средством статического анализа кода. Обычно под этим подразумевают ИС, которые анализируют особенности выполнения программы, моделируют преобразование данных в процессе ее работы. Именно на основании информации о преобразовании данных в процессе выполнения программы строятся заключения о наличии или отсутствии альтернативных сценариев эксплуатации ПО, которые могут использовать злоумышленники.

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

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

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

Эксперименты показали, что все уязвимости, которые находит инструмент APPERCUT для программ C/C++, обнаруживаются MVS (Microsoft Visual Studio) 2012 при включении опции полной проверки. Все уязвимости, которые находит APPERCUT для Java-программ, выявляет среда разработки Eclipse c плагином Find Bugs. Eclipse и Find Bugs – это свободно распространяемое программное обеспечение.

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

Экспертная проверка кода по требованиям ИБ

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

• действительные уязвимости (true positive), которые ранжированы по степени риска;
• для каждой уязвимости необходимо:

1. 1. описать ущерб, который может быть нанесен в результате ее успешной эксплуатации злоумышленником;
   2. представить возможный сценарий/сценарии ее эксплуатации, описать уровень квалификации злоумышленника, позволяющий ему проэксплуатировать уязвимость;
   3. представить рекомендации по устранению уязвимостей с оценкой трудоемкости.

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

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

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

1. Хорошее ИС, позволяющее разрабатывать собственные правила для анализа кода. Язык для составления правил должен быть удобным, а интерфейс их загрузки в систему – интуитивно понятным.
2. Наличие грамотного специалиста, который владеет большим набором шаблонных ситуаций внедрения недекларированных возможностей в код. Помимо этого, эксперт должен уметь формализовывать такие шаблоны и описывать их на языке правил инструментального средства, которое будет использоваться для поиска НДВ по всему коду программного приложения.
3. Наличие специалиста по анализу кода, умеющего быстро и качественно работать с ним в полуавтоматическом режиме, так как в противном случае стоимость анализа будет сопоставима со стоимостью разработки кода (значит, стоимость разработки возрастет в два раза).

Понимание компанией итогов выполнения экспертного аудита кода зависит от представления этого результата в виде отчетов. Требования к отчетам разные:

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

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