Безопасность начиная с ранних этапов разработки: реализация анализа исходного кода в цикле разработки IBM Rational Software Development Lifecycle

Важность раннего тестирования безопасности

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

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

Согласно последнему отчету Gartner:

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

Решение от Ounce Labs' анализирует исходный код приложения, обеспечивая наиболее полный и точный анализ уязвимых мест приложения и их относительных приоритетов, предоставляя разработчикам рекомендации по исправлению и позволяя команде разработчиков эффективно избегать слабых мест в исходном коде. Решение Ounce 5 имеет сертификат Ready for Rational и может интегрироваться с решениями по управлению изменениями IBM Rational ClearQuest и IBM Rational ClearCase, а также с решением IBM Rational Application Developer.

Ounce 5 и RUP

Решение от Ounce Labs' анализирует исходный код приложения, обеспечивая наиболее полный и точный анализ уязвимых мест приложения и их относительных приоритетов, предоставляя разработчикам рекомендации по исправлению и позволяя команде разработчиков эффективно избегать слабых мест в исходном коде. Решение Ounce 5 имеет сертификат Ready for Rational и может интегрироваться с решениями по управлению изменениями IBM Rational ClearQuest и IBM Rational ClearCase, а также с решением IBM Rational Application Developer.

Rational Software Development Lifecycle - это инфраструктура процессов и средств автоматизации в соответствии с методологией RUP. RUP - это гибкая типовая инфраструктура процессов, включающая четыре фазы: разработка концепции (Inception), проектирование (Elaboration), реализация (Construction) и передача в эксплуатацию (Transition). Решение Ounce для анализа исходного кода главным образом применимо на этапах кодирования, сборки и передачи в эксплуатацию. На рис. 1 показано место, занимаемое решением Ounce 5 в рамках методологии RUP.

Рис. 1: Решение Ounce 5 в свете методологии RUP

Фаза принятия основных решений

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

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

Рис. 2: Основные проблемы, нарушения политик, конструктивные недостатки

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

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

Этап детальной проработки и совершенствования

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

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

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

Вот несколько примеров:

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

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

• Завершить разработку вариантов использования средств безопасности и требований
• Определить план проекта и итерации для этапа построения решения
• Включить планы тестирования на безопасность с помощью Ounce 5 в общую стратегию тестирования, как в качестве будущих целевых показателей итераций, так и в виде текущих целей
• Если требуется, настроить Ounce 5 под конкретные политики
• Обеспечить создание lдействующего прототипа системы на максимально раннем этапе.

Этап построения решения

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

Помимо проверки вариантов использования, у разработчиков также может возникнуть желание не допустить появления программных ошибок. Это достигается путем непрерывного тестирования исходного кода и внедрения наилучших методик написания кода. С помощью Ounce 5 разработчики могут постоянно проверять безопасность разрабатываемого ПО с использованием подключаемого модуля Ounce 5. Код должен быть как можно более безопасным до того, как он будет подвергнут проверке для последующей сборки. Одна из целей на этапе построения решения - на возможно более раннем этапе создать действующую систему. Чем раньше станет возможна сборка системы, тем скорее удастся исключить риски для интеграции и обеспечить глобальную проверку системы на регулярной основе. С точки зрения безопасности это важно, поскольку взаимодействие между различными компонентами может создать новые слабости в системе безопасности, отличные от тех, которые имели место для каждого из компонентов в отдельности. Анализа исходного кода средствами Ounce 5 должен стать неотъемлемой частью процесса построения решения и создания тестовых сборок, а проверки на безопасность должны проводиться при внесении любых изменений в исходный код. Производительность Ounce 5 оптимизирована для достижения максимальной эффективности, поэтому задержек времени при построении решения возникать не будет. Если рабочие группы создают несколько сборок в течение дня, инструментарий Ounce может стать составной частью этого процесса.

Ниже представлена процедура ежедневной сборки и показано, как Ounce 5 интегрируется с решением IBM Rational:

1. Исходный код сканируется на регулярной основе (см. рис.3): Using IBM Rational Build Forge®, позволяет планировать и контролировать процессы сборки. Build Forge дает возможность специалисту, отвечающему за выпуск, определять и автоматизировать конкретные процессы сборки решения. Ounce 5 предоставляет интерфейс командной строки, который позволяет автоматически анализировать исходный код на безопасность в процессе сборки системы. По завершении анализа результаты становятся доступными для специалиста по безопасности, который оценивает их значимость.

Рис. 3: Сканирование исходного кода как часть регулярного процесса сборки.

2. Специалист по безопасности оценивает результаты и дает указания по разработке (см. рис. 4): В крупных организациях специалист по безопасности обычно сосредоточен исключительно на вопросах обеспечения безопасности при разработке ПО. В небольших группах разработчиков участники часто занимаются несколькими сферами деятельности, и функции специалиста по безопасности может брать на себя ведущий разработчик, глубоко понимающий проблемы безопасности. В любом случае специалист по безопасности использует продукт Ounce 5 Security Analyst для оценки результатов анализа. Ounce 5 предоставляет базовые возможности, позволяющие оптимизировать процесс оценки. К примеру, таблица уязвимых мест позволяет быстро выявлять слабости и немедленно предпринимать соответствующие действия. Специалист по безопасности с помощью средств интеграции Ounce 5 и ClearQuest доводит проблемы до разработчиков. С целью повышения эффективности проблемы могут быть сгруппированы в пакет и переданы в ClearQuest все вместе. Отдельные записи ClearQuest при этом генерируются автоматически.

Рис. 4: Предоставление результатов с помощью Security Analyst

3. Руководитель проекта и члены команды определяют приоритеты (см. рис. 5): Чтобы команда разработчиков предпринимала надлежащие действия в отношении влияющих на безопасность ошибок программирования, и архитектурных недостатков, они должны установить приоритеты и действовать, как для любых других требований, дефектов или улучшений. Интеграция Ounce 5 с ClearQuest позволяет решать проблемы, связанные с безопасностью, в понятной разработчикам среде. Результаты, выдаваемые Ounce 5, могут непосредственно передаваться разработчикам для немедленного реагирования или же направляться руководителю проекта, который будет сам передавать их соответствующим членам группы разработчиков.
   
   Инструмент интеграции Ounce 5 ClearQuest автоматически заполняет поля ClearQuest данными с учетом степени серьезности ошибок и устанавливает их приоритеты на базе принятой по умолчанию схемы. К примеру, выявленным Ounce 5 серьезным слабостям будет соответствовать высокая степень серьезности и высокий приоритет в ClearQuest. Если эти схемы соответствия для вашей рабочей группы не годятся, можно настроить их в ClearQuest, сделав привязку к соответствующим полям.

Рис. 5: Интеграция Ounce 5 и ClearQuest

Конкретный номер записи в ClearQuest также фиксируется Ounce 5 Security Analyst. После того, как ClearQuest указал разработчику на проблему, она разрешается в контексте всего проекта и учитывается как показатель при оценке процесса разработки и общей работоспособности ПО.

4. Разработчик устраняет проблемы с безопасностью (см. рис. 6): При использовании среды разработки (IDE) IBM Rational Application Developer в сочетании с плагином Ounce 5 Developer Plug-in разработчику не нужно выходить из IDE для выполнения действий по устранению слабостей. Разработчик имеет всю информацию о приоритете проблемы в списке, предоставленном ClearQuest. Выбрав проблему, которую следует устранить, разработчик открывает в Ounce 5 окно, в котором выделена строка кода, являющаяся слабым местом с точки зрения безопасности. Кроме того, он получает указания по сути слабости, а также рекомендации по оптимальной методике действий с примерами "плохого" и "хорошего" кода. Устранив проблему, разработчик может выполнить локальное сканирование, чтобы проверить исправленную версию и выяснить, не возникло ли новых проблем. Когда разработчик завершит процесс исправления, код проверяется ClearCase и подготавливается к тестовой сборке, после чего цикл начинается сначала.

Рис. 6: Устранение проблем с безопасностью с помощью Ounce 5

Мы получаем двойное преимущество от интеграции средств анализа исходного кода Ounce 5 в Rational Application Developer и регулярного выполнения сканирования. Прежде всего, естественно, снижается риск появления брешей в системе безопасности. Во-вторых, что важно на перспективу, растут навыки разработчиков, которые с меньшей вероятностью будут создавать уязвимости в коде, поскольку им известны наилучшие методики написания кода благодаря указаниям, выдаваемым Ounce 5. Рабочие группы неизбежно будут делать меньше ошибок при будущих разработках ПО. Чтобы способствовать внедрению более безопасных методик программирования, в плагине Ounce 5 Developer Plug-In предусмотрено бесплатное и многократное использование рекомендаций по устранению слабостей. Итак, после завершения этапа построения должны быть решены следующие задачи в области обеспечения безопасности:

• Полностью реализована безопасная архитектура
• Все требования к безопасности проверены в процессе итерационного построения решения
• Автоматизированы проверки исходного кода в целях исключения слабостей, обусловленных применением "плохих" методик программирования
• Разработчики должны быть лучше осведомлены о методиках безопасного написания кода

Передача в эксплуатацию

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

Ключевым моментом этого приемосдаточного тестирования является, разумеется, тестирование на безопасность. В этот момент должно быть проведено тестирование на преодоление защиты (с помощью, например, IBM Watchfire® AppScan) чтобы выявить возможные слабости в системе защиты при функционировании в рабочей среде. Анализа исходного кода с помощью Ounce 5 является хорошим дополнением к тестированию на преодоление защиты, поскольку Ounce 5 способен выявлять уязвимые места и указывать на них в коде, тогда как тест на преодоление защит просто указывает слабости, обнаруженные при выполнении атак. Степень строгости аудита системы безопасности и приемосдаточных испытаний, проводимых для конкретного приложения, зависят от применимых норм (например, PCI) и стандартов. Ounce 5 предоставляет отчеты SmartAudit (см. рис. 7) для обеспечения соблюдения нормативных требований. Отчет SmartAudit предоставляет "табель успеваемости" приложения и в полной мере раскрывает конструктивные недостатки и ошибки программирования.

Рис. 7: Ounce 5 SmartAudit обеспечивает соблюдение нормативных требований и стандартов.

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

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

Рис. 8: Портфель средств управления Ounce 5

Итак, на этапе передачи должны быть решены следующие задачи:

• Полное проведение приемосдаточных испытаний перед развертыванием
• Подготовка к непрерывным усовершенствованиям и организация сопровождения
• Управление рисками для приложения в контексте всего портфеля развернутых приложений

Заключение

Повышенное внимание к безопасности программного обеспечения перед лицом все более массированных атак и необходимостью соблюдения нормативных требований накладывает на группу разработчиков дополнительные обязанности по защите ПО. Реализация решения анализа исходного кода Ounce 5 на платформе Rational Software Delivery Platform (в соответствии с методологией RUP) обеспечивает как рамочную инфраструктуру процессов, так и средства автоматизации, упрощающие работу и проясняющие роль каждого участника команды в задаче обеспечения безопасности ПО. На всех этапах, от принятия основных решений до передачи готового продукта в эксплуатацию, имеются основные цели, которых нужно добиваться. Итоговый результат двоякий - разработанное ПО отвечает стандартам безопасности, и одновременно сокращаются расходы на исправление ошибок, выявленных в ходе эксплуатации ПО.

Фазы RUP, ключевые цели по обеспечению безопасности ПО и основные инструменты, необходимые для автоматизации на каждом из этапов, представлены в табл. 1.

ТАБЛИЦА 1: Этапы RUP, ключевые цели и инструменты автоматизации

Примечания

¹ B. Boehm and V. Basili, "Software Defect Reduction Top 10 List." IEEE Computer, January 2001.

² "Implement Source Code Security Scanning Tools to Improve Application Security," Amrit Williams, Gartner, April 4, 2006.