Автор: Полаженко Сергей

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

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

Содержание

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

Введение

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

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

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

Основные недостатки и ограничения тестирования по методу «чёрного ящика»:

• сложность, а в некоторых случаях — невозможность полного тестирования всех функций ПП (задача в некоторых случаях эквивалентна достижению 100% покрытия исходного кода ПП в ходе проведения тестирования);
• сложность проверки факта соответствия конкретного ПП его спецификации;
• в основе тестирования по методу «чёрного ящика»зачастую лежит принцип того, что ключевыми моментами для тестирования являются граничные значения возможных входных данных. Т.е. для тестирования функций ПП (в случае слишком большого числа вариантов тестов) достаточно протестировать граничные значения и некоторые (возможно случайные) промежуточные значения входных данных. В случае же тестирования по методу «белого ящика»легче убедиться, путём анализа исходных текстов функций ПП, в том, что действительно код не делает никаких исключений для входных данных и что действительно, те или иные граничные значения достаточно хорошо охватывают то, что нужно протестировать функциональными методами;
• сложность осуществления ряда функциональных тестов, связанная с различного рода техническими трудностями (особенностями используемых операционных систем, временные задержки в работе сети и т.д.);
• особенностью «тестирования безопасности и защищённости ПП» является то, что требования по большой степени являются негативными, т.е., например, «неавторизованные пользователи не должны иметь доступ к защищаемым ресурсам». Подобные требования очень сложно представить в виде конкретных функциональных тестов в форме: «сделать то, сделать то — получить результат». В результате проверка выполнимости таких требований сводится к задаче осуществления полного функционального тестирования, что, как уже отмечалось, достаточно сложно осуществимо или даже невозможно.

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

В статье будет кратко рассмотрена процедура экспертизы исходных текстов ПП, как способа тестирования его безопасности и защищённости методом «белого ящика».

Суть метода экспертизы исходных текстов программных продуктов

Экспертиза исходных текстов ПП в общем случае состоит из нескольких этапов:

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

Экспертиза проходит во время разработки ПП и его тестирования. Завершается одновременно с завершением тестирования самого ПП.

Исследование проблемы информационной безопасности программных продуктов

Исходные тексты ПП являются очень объёмным источником информации, где есть смысл искать не только чисто технические ошибки, такие как неправильная работа с памятью, игнорирование кодов возврата функций и т.д. — ведущих к тем или иным видам нарушения свойств безопасности и защищённости ПП (например, «отказ в обслуживании»), но также и ряда логических ошибок — передача паролей в открытом виде, неверный выбор алгоритмов шифрования, а также ряд ошибок, которые являются архитектурным недосмотром и для исправления требуют внесения значительных изменений в структуру ПП. Поэтому экспертиза исходных текстов ПП (особенно внешняя экспертиза — с привлечением сторонней организации), как правило, начинается с разработки экспертами собственной модели безопасности ПП (подробнее о сути проблемы обеспечения безопасности и защищённости ПП можно узнать из более ранней работы [1]).

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

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

Работы по построению модели ИБ ПП могут быть организованы при помощи ряда различных методологий, таких как Microsoft Threat Modeling Methodology [2], при помощи популярных методик оценки риска [3] или методологии, рекомендуемой стандартами ГОСТ Р ИСО/МЭК 15408-1-3 (общеизвестными, как «Общие критерии»).

Разработка собственной модели ИБ ПП позволяет экспертам локализовать наиболее критичные области ПП, которые должны быть наиболее тщательно проанализированы в ходе инспекции кода, а также выявить потенциальные недочёты модели безопасности ПП, используемой разработчиками ПП.

Цели ревизии исходных текстов ПП:

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

Инспекция кода

Во время инспекции исходных текстов ПП происходит непосредственный поиск уязвимостей ПП путём анализа исходных текстов ПП.

Для облегчения труда экспертов, проводящих экспертизу исходных текстов ПП, разработчику следует дать базовое описание кода: его организация (иерархия) по модулям и проектам, описание классов, функций, оказать помощь в компиляции и запуске отладки. Возможность самостоятельной компиляции исходных текстов ПП позволяет команде инспекторов воспользоваться всеми доступными возможностями среды разработки, которую использует разработчик (функции intellisense, которые имеются практически во всех современных интегрированных средах разработки IDE) — для навигации по коду, контекстной справки о стандартных функциях и классах (назначение входных параметров, возвращаемые значения, генерируемые исключения ( exceptions) и т.д.).

Предусловие для инспекции: обеспечение общего качества кода (например, на основе рекомендаций из [4]). Экспертам, проводящим экспертизу, будет значительно легче разобраться в коде, если весь код подчиняется некоторому единому стандарту оформления, в коде обосновано выбираются названия для классов, методов, констант и переменных, что позволяет быстрее определить назначение того или иного участка кода, в коде имеются достаточные комментарии и т.д., например, в соответствии с рекомендациями [5-6].

Основные задачи на этом этапе:

• поиск проблемных мест в коде (поиск потенциальных уязвимостей и ошибок программирования). Рекомендуется применение автоматизированных средств, способствующих обнаружению типовых ошибок программирования (такие инструменты, как FlawFinder, ITS4, RATS [7-8] для языков С/С++, FxCop [9] для языков платформы . Net и др.);
• исследование проблемного места: определение типа и категории ошибки, локализация её, разработка предложений по устранению. Ранжирование обнаруженных проблемных мест, чтобы помочь тем самым команде разработчиков разработать стратегию по их устранению;
• документирование обнаруженных ошибок.

Поиск проблемных мест

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

• на каждом подходе должны быть чёткие цели. Так у первого просмотра цель: оценить важность того или иного участка кода, т.е. определить насколько глубоко необходимо его изучение. Не следует смешивать одновременно анализ потенциальных логических (архитектурных недостатков) с поиском ошибок, допущенных при кодировании (чисто технические ошибки). Т.е. не стоит отвлекаться на особенности выделения и освобождения памяти под массивы в исходном тексте ПП, пока не проанализированы сами методы обработки информации в массиве, которая возможно, является конфиденциальной. Другой пример, цель: «проверить наличие доступа у авторизованных лиц и отсутствие доступа у неавторизованных» — выглядит правильной, однако является слишком абстрактной и требует в каждом конкретном случае уточнения;
• следует ограничивать время, выделяемое для каждого участка кода, так чтобы не задерживаться на некоторых участках слишком долго, что в итоге может сказаться на качестве анализа других участков;
• рекомендуется применять проверочные листы (check lists) для того, чтобы не упустить в ходе проведения экспертизы никаких существенных моментов. Примерами таких листов для управляемых языков платформы . Net, а также для ряда технологий сопряжённых с самой платформой, можно найти в [10].

Оценка важности участка кода для безопасности и защищённости программных продуктов

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

• Выполняется ли код по умолчанию?
• Выполняется ли код с повышенными привилегиями?
• Принимает ли он данные от сетевого интерфейса?
• Аутентифицируется ли сетевой интерфейс?
• Написан ли код на неуправляемом языке (таком как, например, C/ C++)?
• Были ли уже связаны с этим кодом проблемы с безопасностью?
• Настороженно ли относится к этому компоненту специалисты по безопасности?
• Имеет ли дело код с конфиденциальными данными?
• Пригоден ли код для повторного использования (например, в виде динамически подключаемой библиотеки, заголовочного файла, статической библиотеки, сборки или ActiveX компоненты и т.д.)?
• Если исходить из модели безопасности ПП, то находится ли компонент в уязвимой среде или подвержен опасным угрозам?

Следует оказать повышенное внимание коду, который получил более трёх-четырёх положительных ответов.

Поиск логических ошибок в реализации модели безопасности программных продуктов

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

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

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

Поиск технических ошибок, критичных для безопасности и защищённости программных продуктов

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

Таблица 2. Краткий обзор функций, в которых наиболее часто встречаются уязвимости, ведущие к нарушению свойств безопасности и защищённости ПП.

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

Также для каждого языка программирования существует ряд технических особенностей, специфических именно для данного языка, которые в каждом отдельном случае необходимо изучать на основании специализированных справочников и статей. Так, например, для языка программирования Java ряд рекомендаций можно найти в [13], для PHP в [14].

Составление отчёта, выработка рекомендаций

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

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

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

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

Выводы

Экспертиза исходных текстов ПП позволяет:

• для разработчиков ПП — осуществлять контроль за менее опытными разработчиками, которые могут допускать ошибки, ведущие к нарушению свойств безопасности и защищённости ПП. Работая в жестких временных рамках разработчик может умышленно или неумышленно допустить достаточно серьёзные нарушения или оставить не до конца проверенный код в окончательной версии ПП, как следствие — необходим контроль за теми изменениями, которые вносят разработчики в исходный код ПП;
• для компании-разработчика — поиск ошибок, которые не выявляются другими видами тестирования. Тот факт, что продукт работает функционально правильно не значит, что он защищён и безопасен. В случае передачи паролей открытым текстом — ПП работает функционально правильно как со стороны сервера так и клиента, однако такая уязвимость может отрицательно сказаться на свойствах безопасности и защищённости ПП, что в итоге может выразиться в потере рыночной стоимости такого ПП;
• для компании-заказчика — независимое подтверждение безопасности и защищённости разрабатываемого ПП с возможностью практически полного анализа (покрытия) кода (что зачастую невозможно при функциональном тестировании).

Недостатки метода:

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

Список использованных источников

• Сергей Полаженко, Актуальность вопросов тестирования безопасности и защищённости программных продуктов
  
• J.D. Meier, Alex Mackman, Michael Dunner, Srinath Vasireddy, Ray Escamilla and Anandha Murukan, Threat Modeling
  
• Сергей Симонов. Анализ рисков, управление рисками .
• Макконелл С. Совершенный код. Мастер класс / Пер. с англ. — М. Издательско-торговый дом «Русская редакция»; СПб.: Питер. 2005. — 896 стр.: ил.
• Соглашения по оформлению кода команды RSDN
  
• C++ Programming Style Guidelines
  
• Криспин Конован, Безопасность систем с открытым кодом
  
• Scott Meyers, A First Look at C++ Program Analyzers
  
• FxCop Team Page
  
• Code Security Checklists by Microsoft
  
• Michael Howard , Expert Tips for Finding Security Defects in Your Code
  
• Стэн Мястковски. Ищем в ПО «пасхальные яйца».
• Java Security Code Guidelines
  
• Илья Басалаев, Безопасность в PHP. Часть 1, часть 2, часть 3.