аудит программного кода это
СОДЕРЖАНИЕ
Методические рекомендации
При аудите программного обеспечения каждый критический компонент следует проверять отдельно и вместе со всей программой. Рекомендуется сначала поискать уязвимости с высоким уровнем риска, а затем перейти к уязвимостям с низким уровнем риска. Уязвимости между высокой и низкой степенью риска обычно существуют в зависимости от ситуации и того, как используется исходный код, о котором идет речь. Тестирование на проникновение приложений пытается выявить уязвимости в программном обеспечении, используя как можно больше известных методов атаки на вероятные точки доступа в попытке остановить приложение. Это распространенный метод аудита, который можно использовать, чтобы узнать, существуют ли какие-либо конкретные уязвимости, но не в том месте, где они находятся в исходном коде. Некоторые утверждают, что методы аудита в конце цикла имеют тенденцию перегружать разработчиков, в конечном итоге оставляя команду с длинным списком известных проблем, но с незначительным фактическим улучшением; в этих случаях в качестве альтернативы рекомендуется метод встроенного аудита.
Уязвимости с высоким риском
Некоторые распространенные уязвимости высокого риска могут существовать из-за использования:
Уязвимости с низким уровнем риска
Ниже приводится список уязвимостей с низким уровнем риска, которые следует обнаруживать при аудите кода, но которые не создают ситуации с высоким уровнем риска.
Инструменты
Зависимость от требований
Если установлен низкий порог, большинство инструментов аудита программного обеспечения обнаруживают множество уязвимостей, особенно если код ранее не подвергался аудиту. Однако фактическая важность этих предупреждений также зависит от того, как используется приложение. Библиотека, которая может быть связана с вредоносным кодом (и должна быть защищена от него), имеет очень строгие требования, такие как клонирование всех возвращаемых структур данных, поскольку ожидаются намеренные попытки взломать систему. Программа, которая может подвергаться только злонамеренному вводу (например, бэкэнд веб-сервера), должна сначала позаботиться об этом вводе (переполнение буфера, SQL-инъекция и т. Д.). Такие атаки могут никогда не произойти для программы, которая используется только внутри внутри авторизованными пользователями в защищенной инфраструктуре.
Аудит программного кода это
Алексей Марков, канд. техн. наук, ст. науч. сотр., CISSP
Валентин Цирлов, CISSP.
Проблема безопасности программного кода
Как это ни удивительно, но успешное развитие рынка информационной безопасности (ИБ) обусловлено чрезвычайной структурной сложностью и динамичностью реализаций программного обеспечения (ПО) компьютерных систем, с одной стороны, и недостаточностью внимания к тестированию безопасности программ и их обновлений, с другой. Зачастую внимание при проектировании, внедрении и аудите информационных систем сосредоточено на мерах, средствах и сервисах ИБ, ориентированных на противодействие инцидентам в информационной сфере, но не на устранении их источника – уязвимостей программного ресурса.
Согласно исследованию NIST, американские производители ПО ежегодно теряют около 25 млрд. долларов на выпуске исправлений критических уязвимостей, потери же экономики США в лице потребителей ПО превосходят эту цифру во много раз.
Косвенные экономические потери из-за уязвимости ПО очень высоки. Согласно статистике Computer Economics, годовые потери из-за вирусных эпидемий, использующих уязвимости систем, превышают 16 млрд. долларов, а в результате компьютерных атак мировая экономика потеряла в 2007 г. более 50 млрд. долларов. Надо понимать, что это только вершина айсберга!
Следуем указать, что возможность наличия преднамеренных закладок в ПО систем управления национальных инфраструктур относят к угрозам государственной важности, даже разовый ущерб от реализации которых трудно переоценить.
Указанная проблема явилась толчком к широкому развитию во многих странах аудита безопасности программного кода, получившего название security code reviews. Процедуры security code reviews могут быть реализованы в системе менеджмента качества крупных корпораций (например, в SDL-системе компании Microsoft ), либо отдаются на откуп независимым лабораториям, специализирующимся на тестировании безопасности прикладных программных продуктов и их обновлений. Как правило, аудит безопасности кода проводят в рамках комплексного тестирования программных продуктов, реже при аудите безопасности информационной системы.
Активное внедрение технологий аудита безопасности кода поддерживается рядом международных объединений и правительственных проектов в области ИБ. К наиболее известным следует отнести деятельность QWASP в области создания методологии анализа безопасности кода и деятельность MITRE в области стандартизации уязвимостей программ (проект CWE).
Понятие аудита безопасности программного кода
Аудит программного кода по требованиям безопасности представляет собой структурное тестирование ПО с целью выявления уязвимостей, реализация которых может снизить уровень целостности, доступности и конфиденциальности системы. Условием проведения аудита безопасности кода является наличие исходных текстов программ и их спецификаций.
Важной особенностью технологий security code reviews является то, что основной задачей аудита является выявление не всевозможных уязвимостей, а только уязвимостей кода, которые могут быть использованы злоумышленником, то есть представлять угрозу ИБ системы.
В общем плане аудит безопасности кода является итерационным процессом, включающим мероприятия по планированию, проведению анализа, выработке рекомендаций по доработке программы и документации, а также развитию методик и средств выявления и анализа уязвимостей (см.рис.1).
 |
Рис.1. Процессная модель security code reviews
Некорректности кодирования как основой класс уязвимостей
Данные классы уязвимостей могут быть использованы при проведении атак на отказ в обслуживания или выполнении нелегитимного кода.
Очевидно, что выявление некорректностей кодирования полностью не решает проблему обеспечения безопасности кода. К важному классу уязвимостей относят ошибки проектирования подсистем защиты и преднамеренные (логические) программные закладки. Наиболее известными из них являются: наличие недекларированных отладочных и деструктивных функций, неверные реализации протоколов или алгоритмов шифрования, использование собственных механизмов псевдобезопасности, наличие встроенных мастерпаролей и внедрение «логических бомб».
Методы аудита безопасности кода
Первый подход считается самым эффективным с точки зрения полноты и точности проверок. Понятно, что только эксперт способен обнаружить сложные уязвимости и маскируемые программные закладки, а также дать рекомендации по исправлению уязвимостей или ограничению возможности их реализации.
К недостаткам метода относят высокую трудоемкость и требования к квалификации и опыту экспертов. Для исключения субъективизма в работе экспертов, может быть привлечены независимые группы тестирования, что является еще более затратным.
Статический анализ кода по шаблону заключается в использовании средств автоматизации поиска и анализа потенциально опасных конструкций кода (сигнатур) в исходном коде программ. Данный метод эффективен при поиске несложных уязвимостей и немаскируемых закладок, таких как переполнение буфера, парольные константы или «логические бомбы». К автоматизированным средствам проведения статического метода по шаблону относят сканеры уязвимостей кода PREfix, PREfast, АК-ВС, UCA, FlawFinder, ITS4, RATS, FxCop.
Современные сканеры кода позволяют в той или иной степени автоматизировать:
Исследования авторов показало, что выявление уязвимостей с использованием средств автоматизации позволяет сократить время проверок в десять-двадцать раз. Пример результатов аудита кода с помощью сканера уязвимостей кода АК-ВС представлен на рис.2.
К недостаткам метода относят то, что результаты строго ограничены набором предварительно определенных шаблонов известных классов уязвимостей. Кроме того, может быть получено огромное число ложных срабатываний, что снижает производительность труда. Перспективным направлением развития сканеров уязвимостей кода является внедрение элементов эвристического анализа потенциально опасных операций.
Рис 2. Пример аудита средства защиты персональных данных, выполненного с помощью сканера уязвимостей кода АК-ВС
Динамический анализ заключается в мониторинге действий программы при выполнении различных функций, связанных с безопасностью: инсталляции, изменении прав, пересылке паролей, очистке памяти и др. Наиболее известны следующие процедуры динамического анализа:
Мониторинг работы программы и анализ трассы может быть выполнен путем включения контрольных точек (например, реализующих функции печати) в исходный текст программы и последующей ее перекомпиляции. Кроме того, можно использовать различные программы-мониторы системных вызовов. Например, таким образом может проверяться наличие системного вызова межсетевой фильтрации при различных вариантах межсетевого обмена. Перекомпиляция программы с включенными контрольными точками имеет ряд преимуществ. Во-первых, это позволяет оценить степень полноты тестирования (по статистике вызовов подпрограмм). Во-вторых, сама компиляционная среда может предоставить инструментальные средства и провести первичный разбор кода.
Часто в качестве методики проверки ПО применяется рандомизированное тестирование по методу «серого ящика» (fuzzing, «фаззинг»). Метод заключается в генерации случайных входных данных из заданного диапазона, определенного на этапе структурного анализа безопасности продукта. Фаззинг легко автоматизируется и может выполняться непрерывно. Однако основная проблема фаззинга состоит в ограниченности его использования для проверки критичных (с точки зрения безопасности) маршрутов. Поэтому фаззинг популярен, главным образом, при тестировании качества и надежности ПО.
Отладчики удобны при изучении самых критичных подсистем безопасности программы, например для проверки в динамике возможности обхода парольной или криптографической подсистемы.
На практике, динамические методы часто игнорируются экспертами по причине длительности процесса тестирования при отсутствии гарантий выявления нарушений безопасности.
Планирование аудита безопасности программного кода
Надо понимать, что невозможно провести полномаршрутное тестирование сложных программ с учетом всевозможных входных данных и условий среды в сколь угодно обозримое для человечества время. Технология security code reviews оптимизирует процесс аудита путем выделения фрагментов повышенного риска, которые затем анализируется ручным или полуавтоматизированным способом.
Для идентификации потенциально опасных фрагментов и их ранжирования могут быть использованы различные подходы, например: использование опросных листов ( checklist ), оценка метрической сложности ПО, предварительный анализ потенциально опасных операций (сигнатур). Технологии security code reviews опираются на определение подпрограмм и фрагментов кода, непосредственно связанных с безопасностью системы, например с:
Кроме того, могут быть приняты во внимание экспертные оценки по ранжированию областей повышенного риска. В качестве исходных данных может служить информация о степени модификации кода по сравнению с предыдущими версиями, выполнении кода по умолчанию, наличии ассемблерных вставок, возможности выполнения кода с повышенными привилегиями, частоте повторно используемого кода, возможности межсетевого обмена и др. В простейшем случаем, ранжирование областей повышенного риска можно осуществить на основе статистики о потенциально опасных операциях, полученной на этапе предварительного анализа программного продукта.
Сокращение проверок может идти по пути выделения точек входа и входных данных потенциально опасного фрагмента. Это позволяет исключить ненужный анализ и исправление уязвимостей, которые затруднительно реализовать злоумышленнику.
Конечно, в идеале аудит безопасности программного кода начинается с анализа проекта ПО, формирования моделей угроз ПО и идентификации классов уязвимостей, свойственных конкретному языку программирования.
Сертификация или аудит кода?
В заключении рассмотрения технологии аудита безопасности кода следует сказать о возможности ее развития в нашей стране. Дело в том, что России повышение доверия к ПО регулируется, главным образом, путем его сертификации на отсутствие недекларированных возможностей в соответствии с руководящим документом Гостехкомиссии России. Требования руководящего документа и процедуры аудита безопасности кода в ряде случаев совпадают (табл.1). В частности, оба подхода предполагают наличие исходных текстов, спецификаций и соответствующей компиляционной среды. Из таблицы видно, что российская нормативная база ориентирована на контроль целостности и полномаршрутное тестирование всего программного продукта (что на практике нереально) с целью выявления ошибок вообще, в то время как процедуры security code reviews направлены на скорейшее выявление реализуемых уязвимостей программного кода. Здесь приходится констатировать факт, что продукты, сертифицированные по 3 и 4 уровню контроля отсутствия недекларированных возможностей, не обладают достаточным уровнем доверия, так как неочевидно, подвергались ли они проверкам по безопасности кода или нет.
Аудит программного кода необходим. Безопасность через неясность — зло
25 января информационное агенство Reuters сообщило что такие фирмы как McAfee, SAP и Symantec позволили российским спецслужбам произвести изучение исходного кода своих продуктов, а это «потенциально подвергает опасности компьютерные сети как минимум дюжины федеральных агенств CША ». Данная статья призвана рассказать об аудите исходного кода и какие компании его допускают, а так же рассмотреть тезис о том, что «разрешение России изучать исходный код таких программных решений может привести к выявлению неизвестных уязвимостей, которые могут быть использованы для подрыва сетевой безопасности США».
Главная мысль статьи Reuters в том что запрос исходного кода для аудита плохая и опасная практика. Это попросту неверно. Аудит кода очень широко распространенная регулярная практика, используемая как компаниями, так и профессиональными разработчиками, специалистами в области информационной безопасности, чтобы убедиться в безопасности устанавливаемого программного обеспечения(ПО). Так же в статье информационного агентства отмечается что «Reuters не нашло никаких свидетельств того что аудит исходного кода имел значение для проведения кибератак». Для нас в фонде EFF является обычным делом выполнение аудита исходного кода любого ПО, которое мы выбираем для использования.
Подчеркнем для полной ясности: мы не хотим преуменьшать степень иностранных угроз для кибербезопасности США или подстрекать к использованию уязвимостей ПО, напротив, мы хотим подчеркнуть что открытый код(open source) и аудит кода — одни из сильных мер безопасности. Именно поэтому EFF серьезно поддерживает распространение и использование открытого ПО.
Не только производители ПО запрещают иностранным правительствам производить аудит кода, торговые соглашения используются теперь и для того чтобы запрещать странам запрашивать аудит кода важных для них программных комплексов. Первым торговым соглашением с таким ограничением стало Транстихоокеанское партнерство ( Comprehensive and Progressive Trans-Pacific Partnership — CPTPP так же известное как TPP), которое должно быть подписано в марте этого года.
Аналогичное ограничение предлагается включить в обновленное соглашение о Североамериканской зоне свободной торговли (NAFTA) и в грядущем двустороннем соглашении с ЕС. EFF уже заявлял о своей позиции по данному вопросу: такие запреты на обязательный аудит кода создают препятствия для легализации мер по подтверждению безопасности и качества такого ПО как VPN и средств безопасного общения, а так же таких устройств как роутеров и IP-камер.
Неявное предположение что «сохранение нашего исходного кода закрытым повышает нашу защищенность» очень опасно. Исследователи и эксперты в области информационной безопасности периодически наглядно демонстрируют нам что защищенность, главным образом, полагающаяся на безопасность через неясность просто не работает. Еще хуже то что она дает ит-специалистам ложное чувство безопасности и поддерживает этим соответствующие плохие подходы к информационной безопасности.
Аудит программного кода по требованиям безопасности
Аудит программного кода по требованиям безопасности
Аудит программного кода по требованиям безопасности
Алексей Марков, к. т.н., старший научный сотрудник, CISSP, эксперт по информационной безопасности
Валентин Цирлов, CISSP, эксперт по информационной безопасности
Проблема безопасности программного кода
Данная проблема явилась толчком к широкому развитию во многих странах аудита безопасности программного кода, получившего название security code reviews.
Процедуры security code reviews могут быть либо реализованы в системе менеджмента качества крупных корпораций (например, в SDL-системе компании Microsoft), либо отданы на откуп независимым лабораториям, специализирующимся на тестировании безопасности прикладных программных продуктов и их обновлений. Как правило, аудит безопасности кода проводят в рамках комплексного тестирования программных продуктов, реже при аудите безопасности информационной системы.
Понятие аудита безопасности программного кода
Аудит программного кода по требованиям безопасности представляет собой структурное тестирование ПО с целью выявления уязвимостей, реализация которых может снизить уровень целостности, доступности и конфиденциальности системы. Условием проведения аудита безопасности кода является наличие исходных текстов программ и их спецификаций.
В общем плане аудит безопасности кода является итерационным процессом, включающим мероприятия по планированию, проведению анализа, выработке рекомендаций по доработке программы и документации, а также развитию методик и средств выявления и анализа уязвимостей (см. рис. 1).
Некорректности кодирования как основой класс уязвимостей
Уязвимости программного кода могут являться некорректностями кодирования или ошибками проектирования, а также иметь злоумышленный или непреднамеренный характер. Однако, согласно открытым публикациям, основные приемы security code reviews, используемые при проверках кода, ориентированы на выявление некорректностей кодирования подсистем безопасности. Перечислим основные классы указанных уязвимостей:
Данные классы уязвимостей могут быть использованы при проведении атак на отказ в обслуживании или выполнении нелегитимного кода.
Очевидно, что выявление некорректностей кодирования полностью не решает проблему обеспечения безопасности кода. К важному классу уязвимостей относят ошибки проектирования подсистем защиты и преднамеренные (логические) программные закладки. Наиболее известными из них являются: наличие недеклари-рованных отладочных и деструктивных функций, неверные реализации протоколов или алгоритмов шифрования, использование собственных механизмов псевдобезопасности, наличие встроенных мастер-паролей и внедрение «логических бомб».
Методы аудита безопасности кода
Выделяют несколько методов аудита безопасности кода:
Первый подход считается самым эффективным с точки зрения полноты и точности проверок. Понятно, что только эксперт способен обнаружить сложные уязвимости и маскируемые программные закладки, а также дать рекомендации по исправлению уязвимостей или ограничению возможности их реализации.
К недостаткам метода относят высокую трудоемкость и требования к квалификации и опыту экспертов. Для исключения субъективизма к работе экспертов может быть привлечены независимые группы тестирования, что является еще более затратным.
Статический анализ кода по шаблону заключается в использовании средств автоматизации поиска и анализа потенциально опасных конструкций кода (сигнатур) в исходном коде программ. Данный метод эффективен при поиске несложных уязвимостей и немаскируемых закладок, таких как переполнение буфера, парольные константы или «логические бомбы». К автоматизированным средствам проведения статического метода по шаблону относят сканеры уязвимостей кода PREfix, PREfast, АК-ВС, UCA, FlawFinder, ITS4, RATS, FxCop.
Современные сканеры кода позволяют в той или иной степени автоматизировать:
Исследование авторов показало, что выявление уязвимостей с использованием средств автоматизации позволяет сократить время проверок в десять-двадцать раз.