как настроить безопасную разработку

Как настроить безопасную разработку

Практики в классических vs гибкие методологии разработки

Цели и disclaimer Рассказать о том, как удалось на примере

отдельно взятых методологий разработки Рассказать о том, как еще это можно

сделать

Презентация не претендует на универсальное описание и энциклопедическую точность формулировок

В презентации использованы открытые материалы OWASP, а также материалы книги Бориса Вольфсона «Гибкие методологии разработки»

Определения Secure Development LifeCycle (SDLC) – цикл

разработки ПО, включающий практики управления безопасностью как часть процесса разработки

MS SDLC – универсальная методология управления безопасностью, предложенная Microsoft

Waterfalls (каскадная методология разработки) – классическая методология с жестко разграниченными последовательными этапами и фиксированным ожидаемым результатом

Agile (итеративные методологии) – методологии разработки, построенные на возможности гибкого изменения требований в процессе создания продукта и частой демонстрации промежуточных результатов

Подходы Последовательные: waterfalls

требования фиксируются и не меняются

Итеративные: agile (без ограничения общности)

требования меняются постоянно, итерациями

Подход Waterfalls

Оформляем требования

Составляем ТЗ

Разрабатываем

Тестируем

Эксплуатируем и поддерживаем

Подход Waterfalls

Waterfalls: требования Требования создаются, согласуются друг с

другом, затем итог согласуется со всеми участниками

Требования подаются в виде заявок, формализуются в виде документов технического задания

Если что-то поменялось в концепции – требования повторно согласуются друг с другом, затем снова со всеми участниками

Waterfalls: проектирование Включает проработку аналитики и

архитектуры Результат должен согласовываться

безопасниками Должны быть составлены карты рисков

информационной безопасности В результате требования могут поменяться

и уйти на повторное согласование Эта ситуация может повторяться

многократно

Waterfalls: оценка рисков ИБ Методология: STRIDE (MS SDLC) Инструменты: SDL Threat Modeling Tool Результат: стандартизованный отчет о

рисках и запланированных мерах по снижению рисков + базовый gap-анализ

Плюсы: можно проанализировать риски ИБ по всей архитектуре решения в комплексе

Минусы: может потребоваться полная переделка архитектуры решения для учета требований ИБ

Waterfalls: оценка рисков ИБ по MS SDL

Waterfalls: результаты анализа ИБ Сложность управления: изменения и

результаты согласования отражаются в финальном ТЗ текстом

Недостаточное документирование: ценность других артефактов (документов) существенно снижается, они вторичны и потому часто игнорируются

Индульгенция разработчику: если все будет сделано точно по ТЗ, значит, будет сделано правильно, если что-то не учтено в ТЗ, значит, это не важно

Waterfalls: результаты анализа

Waterfalls: тестирование Функциональное тестирование мер

безопасности будет минималистским Главное – пройти UAT (User Acceptance

Testing) Пентест = высокая вероятность внесения

(а стало быть и очередного цикла согласований для) изменений в архитектуре решения

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

Безопасность в waterfalls+ Видна картинка в целом, риски «насквозь» как в архитектуре

приложений, так и в инфраструктуре+ Можно обойтись частными (одноразовыми) решениями для

каждого отдельно взятого риска+ Одноразовая конечная задача для безопасника+ Безопасника можно проаутсорсить

- Негибкий процесс согласования любых изменений в исходные требования

- ТЗ превалирует над другими артефактами, они часто не сохраняются, либо оказываются неактуальными

- Значительная продолжительность цикла: к моменту тестирования модель угроз, как правило, уже забыта, работа начинается с чистого листа

- Функциональное тестирование ИБ чаще всего формальное vs ТЗ- Качеству кода, как правило, уделяется недостаточно внимания,

т.к. в UAT оно не видно

Подходы Agile (на примере Scrum):

Требования (истории Agile) Требования фиксируются на итерацию и не

изменяются в процессе разработки Требования могут изменяться от итерации

к итерации, поэтому одного финального ТЗ, чаще всего, не появляется

Возможны пересмотры глобальных решений ИБ при существенном изменении концепций продукта

Новые требования и вводные, как правило, ориентированы на утвержденное глобальное решение ИБ

Работа с бэклогом (на примере Scrum) Модель «позвоночника» (backbone model)

Идеологическое деление на ИБ как отдельная активность (часть продукта) и подзадачи ИБ в рамках других активностей

Проектирование Agile Задачи в активности ИБ, или истории продукта

«безопасность», как правило, носят концептуальный характер

пример: концепция аутентификации и авторизации в приложении Подзадачи – риск-приоритезируемые ИБ-истории

(технические истории)пример: обработка пользовательского ввода из веб-формы

Дополнительные, часто общие для многих продуктовых историй (supplementary requirements)

пример: централизованный метод обработки пользовательского ввода Продуктовые истории могут требовать анализа рисков ИБ

даже если напрямую не относятся к концепции обеспечения безопасности

пример: по всем без исключения открытым полям текстового ввода должны быть проанализированы риски внедрения исполняемого кода

Проектирование Agile (продолжение) Важность документирования карты рисков в

формате «угроза – уязвимость – ущерб – контрольная процедура»

Новые вводные и требования согласуются с построенной картой рисков, при необходимости карта рисков актуализируется

Перечень рисков и контрольных процедур стандартизуется, возникают «типовые меры безопасности»

Задача обеспечения ИБ становится постоянной составляющей цикла проектирования

ИБ-специалист становится обязательным членом команды постановки требований (продуктовой команды)

Анализ рисков ИБ Agile

Анализ рисков ИБ Agile С легкостью решается обратная задача:

понять, в каких историях был найден риск X, или применено решение Y

Приоритетны переиспользуемые решения Визуальный business trade-off – снижать,

или не снижать риск предложенным решением при указанных затратах

Удобно прогнозировать изменение объемов и сроков работ по историям для реализации конкретного решения ИБ

Разработка Agile Повышение «видимости» процесса

разработки – возможность контролировать процесс создания кода и его качество

Обязательные ревью + рефакторинг = более высокая эффективность обучения принципам безопасного написания кода

Эффективное использование простых баз знаний и библиотек типа OWASP ESAPI

«Безболезненное» внедрение процедур регулярной проверки кода на низкоуровневые уязвимости – совместное ревью и статический анализ кода

Чек-листы правил OWASP для разработчиков

Обучающие семинары (OWASP) для разработчиков

Тестирование Agile Участие тестировщика в процессе формирования карт

рисков – формирование планов и приоритетов функционального тестирования ИБ-функционала на основании рисков, уязвимостей и методов эксплуатации

Оперативная коммуникация результатов тестирования по относительно небольшим объемам разработанного функционала

Стандартизация планов тестирования для типовых мер безопасности

Возможность автоматизации процесса тестирования типовых мер безопасности

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

Тестирование Agile Должен появиться выделенный

(dedicated) тестировщик, ответственный за безопасность

Тестировщики должны участвовать в анализе рисков и выборе мер безопасности

Составляются стандартизованные отчеты с результатами тестирования

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

Нужен специалист с достаточной экспертизой по безопасности

Функциональную составляющую процесса можно делегировать в команду, и проверять ее результаты

Постановка тест-планов сценариев безопасности Agile

Проверка уязвимостей исходного кода Agile

Трэкинг найденных уязвимостей

Безопасность в agile+ Как правило не требуется отдельного процесса формальных

согласований с требованиями+ Существенно выше ценность разработанных карт рисков ИБ, а

также описаний использованных мер по снижению этих рисков+ Формируется общая концепция безопасности, понятная всей

команде разработки+ Ориентированность на переиспользование типовых, хорошо

протестированных мер по снижению рисков+ Качество кода выше, т.к. его контроль заложен методологией;

меньше дефектов, ведущих к уязвимостям ПО

- Риски проанализированы только для известной части продукта- Карта рисков может радикально измениться при значительном

изменении продукта- Задача специалиста ИБ становится регулярной, требования к

его экспертизе и объему участия существенно возрастают

Спасибо! Дмитрий Баранов, dbaranov@round.ru, dimitry.a.baranov@gmail.com