31
Как настроить безопасную разработку Практики в классических vs гибкие методологии разработки

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

  • Upload
    risspa

  • View
    3.296

  • Download
    5

Embed Size (px)

Citation preview

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

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

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

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

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

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

сделать

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Подход Waterfalls

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

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

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

Тестируем

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

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

Подход Waterfalls

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

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

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

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

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

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

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

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

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

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

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

многократно

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Спасибо! Дмитрий Баранов, [email protected], [email protected]