18 сентября 2013

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

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

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

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

Этап разработки	Действие
Обучение	Обучение основам безопасности
Требования	Задание требований безопасности
	Создание контрольных условий качества и панелей ошибок
	Оценка рисков безопасности и конфиденциальности
Проектирование	Задание требований проектирования
	Анализ возможных направлений для злоумышленных атак
	Моделирование рисков
Реализация	Применение утвержденных инструментов
	Отказ от небезопасных функций
	Статический анализ
Проверка	Динамический анализ
	Нечеткое тестирование (фаззинг)
	Проверка возможных направлений для злоумышленных атак
Выпуск	Планирование реагирования на инциденты
	Окончательная проверка безопасности
	Сертификация и архивация выпуска
Реагирование	Выполнение плана реагирования на инциденты

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

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

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

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

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

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

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

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

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

Архитектура и проектирование:

Оценка рисков при создании архитектуры ПО;
Рекомендации при проектировании;
Принципы проектирования защищенного ПО;
Описание утилит для моделирования.

Разработка требований:

Создание требований к защищенному ПО;
Шаблоны возможных атак на ПО.

Разработка:

Анализ исходных текстов ПО;
Советы и практики по разработке;
Правила разработки.

Управление:

Управление процессом разработки защищенного ПО;
Оценка рисков.

Тестирование:

Тестирование на безопасность;
Тестирование по принципу «белого ящика»;
Тестирование по шаблонам атак.

Рекомендации по системам в целом:

Применение, интеграция и развитие;
Внедрение и обслуживание;
Управление инцидентами;
Тестирование на проникновение в систему;
Тестирование по принципу «черного ящика».

Фундаментальные основы:

Метрики для измерений защищенности ПО;
Обучение и поощрение сотрудников;
Применение процессов защищенной разработки;
Моделирование бизнес-кейсов.

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

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

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

Этап разработки	Действие
Управление	Стратегия и метрики для оценки
	Правила и соответствия требованиям
	Обучение специалистов и разработка руководств
Разработка	Оценка угроз
	Разработка требований по защищенности
	Разработка архитектуры по защищенности
Проверка	Проверка архитектуры
	Проверка исходных текстов ПО
	Проверка на защищенность
Выпуск	Управление уязвимостями и реагирование на их обнаружение
	Усиление защиты с помощью всей инфраструктуры в целом
	Обеспечение обратной связи

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

Building Security In Maturity Model (BSIMM) - формализованное описание процесса защищенной разработки программного обеспечения (ПО).

Этапы и действия аналогичны SAMM за некоторым исключением в описании процессов. BSIMM имеет те же плюсы и минусы, что и SAMM.

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

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

Инициирование;
Разработка;
Внедрение;
Обслуживание;
Вывод из эксплуатации.

Cisco Security Development Lifecycle (CSDL) формализованное описание процесса защищенной разработки программного обеспечения (ПО).

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

Этап разработки	Действие
Концепция	Задание требований по безопасности
	Задание требований по процессам
	Задание требований по функциональности
Планирование	Задание требований по проектированию
Планирование	Моделирование рисков
Разработка	Использование наиболее безопасных библиотек
	Статический анализ
	Реализация требований по безопасности
	Проверка используемого стороннего ПО
Проверка	Тестирование на уязвимости
	Нечеткое тестирование (фаззинг)
	Проверка выполнений требований по безопасности
Выпуск	Проверка соответствия требованиям CSDL
Реагирование	Реагирование на инциденты
Реагирование	Мониторинг уязвимостей в использованном стороннем ПО

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

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