АНАЛИЗ ПРОГРАММНОГО КОДА ПО ТРЕБОВАНИЯМ БЕЗОПАСНОСТИ

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

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

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

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

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

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

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

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

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

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

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

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

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

Rational Unified Process (RUP) – методология разработки программного обеспечения, созданная компанией Rational Software [2].

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

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

• Формируются видение и границы проекта.
• Создается экономическое обоснование (business case).
• Определяются основные требования, ограничения и ключевая функциональность продукта.
• Создается базовая версия модели прецедентов.
• Оцениваются риски.

При завершении начальной фазы оценивается достижение этапа жизненного цикла цели (англ. Lifecycle Objective Milestone), которое предполагает соглашение заинтересованных сторон о продолжении проекта.

Рисунок 1. Фазы разработки программного продукта

В фазе «Построение» происходит реализация большей части функциональности продукта. Данная фаза завершается выпуском системы и вехой начальной функциональной готовности (Initial Operational Capability).

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

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

Список литературы:

1. Марков А.С., Цирлов В.Л. Аудит программного кода по требованиям безопасности.//Information security. – 2008. – №2. – С.56-57.
2. Philippe Kruchten. Rational Unified Process – An Introduction, Addison-Wesley. – 1999.