Перейти на Sec.Ru
Рейтинг@Mail.ru

18 сентября 2013

Защищенная разработка программного обеспечения

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

  1. Microsoft Security Development Lifecycle (SDL) – формализованное описание процесса защищенной разработки программного обеспечения (ПО) и набор программных инструментов для реализации отдельных элементов процесса.

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

Этап разработки

Действие

Обучение

Обучение основам безопасности

Требования

Задание требований безопасности

Создание контрольных условий качества и панелей ошибок

Оценка рисков безопасности и конфиденциальности

Проектирование

Задание требований проектирования

Анализ возможных направлений для злоумышленных атак

Моделирование рисков

Реализация

Применение утвержденных инструментов

Отказ от небезопасных функций

Статический анализ

Проверка

Динамический анализ

Нечеткое тестирование (фаззинг)

Проверка возможных направлений для злоумышленных атак

Выпуск

Планирование реагирования на инциденты

Окончательная проверка безопасности

Сертификация и архивация выпуска

Реагирование

Выполнение плана реагирования на инциденты

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

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

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

Этап реализации контролируется с помощью различных инструментов и методик – запрещается использование не проверенных инструментов и сред разработки, не вызывающих доверия утилит и прочих нестандартных решений. Рекомендуется отказ от небезопасных функций, этому посвящен целый раздел MSDN - Security Enhancements in the CRT. И регламентируется применение специальных инструментов для статического анализа исходных текстов программ.

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

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

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

  1. Build Security In Департамента национальной безопасности США (BSI) – набор несистематизированных процессов и рекомендаций по безопасной разработке ПО.

Описание процессов и рекомендаций делится по категориям:

  • Архитектура и проектирование:
    • Оценка рисков при создании архитектуры ПО;
    • Рекомендации при проектировании;
    • Принципы проектирования защищенного ПО;
    • Описание утилит для моделирования.
  • Разработка требований:
    • Создание требований к защищенному ПО;
    • Шаблоны возможных атак на ПО.
  • Разработка:
    • Анализ исходных текстов ПО;
    • Советы и практики по разработке;
    • Правила разработки.
  • Управление:
    • Управление процессом разработки защищенного ПО;
    • Оценка рисков.
  • Тестирование:
    • Тестирование на безопасность;
    • Тестирование по принципу «белого ящика»;
    • Тестирование по шаблонам атак.
  • Рекомендации по системам в целом:
    • Применение, интеграция и развитие;
    • Внедрение и обслуживание;
    • Управление инцидентами;
    • Тестирование на проникновение в систему;
    • Тестирование по принципу «черного ящика».
  • Фундаментальные основы:
    • Метрики для измерений защищенности ПО;
    • Обучение и поощрение сотрудников;
    • Применение процессов защищенной разработки;
    • Моделирование бизнес-кейсов.

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

  1. Software Assurance Maturity  Model (SAMM) - формализованное описание процесса защищенной разработки программного обеспечения (ПО).

Подобно SDL все действия разделены по этапам, набор действий отличается:

Этап разработки

Действие

Управление

Стратегия и метрики для оценки

Правила и соответствия требованиям

Обучение специалистов и разработка руководств

Разработка

Оценка угроз

Разработка требований по защищенности

Разработка архитектуры по защищенности

Проверка

Проверка архитектуры

Проверка исходных текстов ПО

Проверка на защищенность

Выпуск

Управление уязвимостями и реагирование на их обнаружение

Усиление защиты с помощью всей инфраструктуры в целом

Обеспечение обратной связи

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

  1. Building Security In Maturity Model (BSIMM) - формализованное описание процесса защищенной разработки программного обеспечения (ПО).
  2. Этапы и действия аналогичны SAMM за некоторым исключением в описании процессов. BSIMM имеет те же плюсы и минусы, что и SAMM.

  3. Security Considerations in the System Development Life Cycle Национального Института Стандартов и Технологии США (SDLC) - формализованное описание процесса защищенной разработки программного обеспечения (ПО).

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

  • Инициирование;
  • Разработка;
  • Внедрение;
  • Обслуживание;
  • Вывод из эксплуатации.
  1. Cisco Security Development Lifecycle (CSDL) формализованное описание процесса защищенной разработки программного обеспечения (ПО).

Методика CSDL похожа на SDL, но с учетом использования стороннего программного обеспечения и библиотек, а также с меньшим анализом уязвимостей и большим упором на требования по безопасности:

Этап разработки

Действие

Концепция

Задание требований по безопасности

Задание требований по процессам

Задание требований по функциональности

Планирование

Задание требований по проектированию

Моделирование рисков

Разработка

Использование наиболее безопасных библиотек

Статический анализ

Реализация требований по безопасности

Проверка используемого стороннего ПО

Проверка

Тестирование на уязвимости

Нечеткое тестирование (фаззинг)

Проверка выполнений требований по безопасности

Выпуск

Проверка соответствия требованиям CSDL

Реагирование

Реагирование на инциденты

Мониторинг уязвимостей в использованном стороннем ПО

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

Просмотров: 3339

Мнения экспертов

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

  • Крюков А.Н.Крюков А.Н.
    Рязанское высшее воздушно-десантное командное училище им. В.Ф.Маргелова
    преподаватель
Файл, предложенный для рецензирования, относится экспертом к статьям только по объёму. По его мнению, текст представляет собой перевод иностранной рекламы, сделанный программно (например, Google) и отредактированный человеком, далёким от темы и слабо знакомым с орфографией русского языка. По определению, методика есть последовательность действий, которая может быть однозначно описана и воспроизведена, имеющая практическую ценность для производящего действия. Здесь же методики изложены настолько поверхностно, что их сущность и различия теряются. Последовательность изложения элементов для разных методик разная. В тексте отсутствуют сравнительный анализ перечисленных методик, оценка их трудоёмкости и практической реализуемости, описание занимаемой доли рынка, рисунки, таблицы и перечень использованных источников. Эксперт не рекомендует материал к публикации до его глубокой переработки.

Ваши комментарии:

Для того, чтобы оставлять коментарии, Вам нужно авторизоваться на Sec.Ru. Если У Вас еще нет аккаунта, пройдите процедуру регистрации.


Автор

  • Бойцов И.А.Бойцов И.А.
    ООО "Код Безопасности" (ГК "Информзащита")
    Аналитик

Информация

  • Снимай крутую видеорекламу - выкладывай на Sec.Ru!

    Рекламный ролик - один из самых эффективных способов донесения информации. И он отлично подходит для рекламирования любой продукции, в т.ч. и продукции рынка систем безопасности.
    Поэтому редакция Портала решила составить свой рейтинг лучших рекламных видеороликов. Все они разные и все чем-то покоряют: красотой, задумкой, стилем съемки, посылом, необычным финалом.
    Некоторые из них язык не повернется назвать иначе как шедевром короткого метра. Смотрим, наслаждаемся, делаем заметки, учимся творить рекламу правильно.
    Если Вы хотите выложить видеоролик о своей продукции на Sec.Ru, пишите о своем желании на adv@sec.ru!

    Картинка: Jpg, 100x150, 16,47 Кбайт

    Мотор!

Отраслевые СМИ

Все права защищены 2002 – 2019
Rambler's Top100 �������@Mail.ru