Your SlideShare is downloading. ×
как настроить безопасную разработку
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Saving this for later?

Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime - even offline.

Text the download link to your phone

Standard text messaging rates apply

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

3,226
views

Published on


0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
3,226
On Slideshare
0
From Embeds
0
Number of Embeds
11
Actions
Shares
0
Downloads
14
Comments
0
Likes
3
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Как настроить безопасную разработку Практики в классических vs гибкие методологии разработки
  • 2. Цели и disclaimer  Рассказать о том, как удалось на примере отдельно взятых методологий разработки  Рассказать о том, как еще это можно сделать  Презентация не претендует на универсальное описание и энциклопедическую точность формулировок  В презентации использованы открытые материалы OWASP, а также материалы книги Бориса Вольфсона «Гибкие методологии разработки»
  • 3. Определения  Secure Development LifeCycle (SDLC) – цикл разработки ПО, включающий практики управления безопасностью как часть процесса разработки  MS SDLC – универсальная методология управления безопасностью, предложенная Microsoft  Waterfalls (каскадная методология разработки) – классическая методология с жестко разграниченными последовательными этапами и фиксированным ожидаемым результатом  Agile (итеративные методологии) – методологии разработки, построенные на возможности гибкого изменения требований в процессе создания продукта и частой демонстрации промежуточных результатов
  • 4. Подходы  Последовательные: waterfalls требования фиксируются и не меняются  Итеративные: agile (без ограничения общности) требования меняются постоянно, итерациями
  • 5. Подход Waterfalls Оформляем требования Составляем ТЗ Разрабатываем Тестируем Эксплуатируем и поддерживаем
  • 6. Подход Waterfalls
  • 7. Waterfalls: требования  Требования создаются, согласуются друг с другом, затем итог согласуется со всеми участниками  Требования подаются в виде заявок, формализуются в виде документов технического задания  Если что-то поменялось в концепции – требования повторно согласуются друг с другом, затем снова со всеми участниками
  • 8. Waterfalls: проектирование  Включает проработку аналитики и архитектуры  Результат должен согласовываться безопасниками  Должны быть составлены карты рисков информационной безопасности  В результате требования могут поменяться и уйти на повторное согласование  Эта ситуация может повторяться многократно
  • 9. Waterfalls: оценка рисков ИБ  Методология: STRIDE (MS SDLC)  Инструменты: SDL Threat Modeling Tool  Результат: стандартизованный отчет о рисках и запланированных мерах по снижению рисков + базовый gap-анализ  Плюсы: можно проанализировать риски ИБ по всей архитектуре решения в комплексе  Минусы: может потребоваться полная переделка архитектуры решения для учета требований ИБ
  • 10. Waterfalls: оценка рисков ИБ по MS SDL
  • 11. Waterfalls: результаты анализа ИБ  Сложность управления: изменения и результаты согласования отражаются в финальном ТЗ текстом  Недостаточное документирование: ценность других артефактов (документов) существенно снижается, они вторичны и потому часто игнорируются  Индульгенция разработчику: если все будет сделано точно по ТЗ, значит, будет сделано правильно, если что-то не учтено в ТЗ, значит, это не важно
  • 12. Waterfalls: результаты анализа
  • 13. Waterfalls: тестирование  Функциональное тестирование мер безопасности будет минималистским  Главное – пройти UAT (User Acceptance Testing)  Пентест = высокая вероятность внесения (а стало быть и очередного цикла согласований для) изменений в архитектуре решения  Проверка уязвимостей исходного кода – редкий случай и обычно воспринимается как знак недоверия разработчикам
  • 14. Безопасность в waterfalls + Видна картинка в целом, риски «насквозь» как в архитектуре приложений, так и в инфраструктуре + Можно обойтись частными (одноразовыми) решениями для каждого отдельно взятого риска + Одноразовая конечная задача для безопасника + Безопасника можно проаутсорсить - Негибкий процесс согласования любых изменений в исходные требования - ТЗ превалирует над другими артефактами, они часто не сохраняются, либо оказываются неактуальными - Значительная продолжительность цикла: к моменту тестирования модель угроз, как правило, уже забыта, работа начинается с чистого листа - Функциональное тестирование ИБ чаще всего формальное vs ТЗ - Качеству кода, как правило, уделяется недостаточно внимания, т.к. в UAT оно не видно
  • 15. Подходы Agile (на примере Scrum):
  • 16. Требования (истории Agile)  Требования фиксируются на итерацию и не изменяются в процессе разработки  Требования могут изменяться от итерации к итерации, поэтому одного финального ТЗ, чаще всего, не появляется  Возможны пересмотры глобальных решений ИБ при существенном изменении концепций продукта  Новые требования и вводные, как правило, ориентированы на утвержденное глобальное решение ИБ
  • 17. Работа с бэклогом (на примере Scrum)  Модель «позвоночника» (backbone model)  Идеологическое деление на ИБ как отдельная активность (часть продукта) и подзадачи ИБ в рамках других активностей
  • 18. Проектирование Agile  Задачи в активности ИБ, или истории продукта «безопасность», как правило, носят концептуальный характер пример: концепция аутентификации и авторизации в приложении  Подзадачи – риск-приоритезируемые ИБ-истории (технические истории) пример: обработка пользовательского ввода из веб-формы  Дополнительные, часто общие для многих продуктовых историй (supplementary requirements) пример: централизованный метод обработки пользовательского ввода  Продуктовые истории могут требовать анализа рисков ИБ даже если напрямую не относятся к концепции обеспечения безопасности пример: по всем без исключения открытым полям текстового ввода должны быть проанализированы риски внедрения исполняемого кода
  • 19. Проектирование Agile (продолжение)  Важность документирования карты рисков в формате «угроза – уязвимость – ущерб – контрольная процедура»  Новые вводные и требования согласуются с построенной картой рисков, при необходимости карта рисков актуализируется  Перечень рисков и контрольных процедур стандартизуется, возникают «типовые меры безопасности»  Задача обеспечения ИБ становится постоянной составляющей цикла проектирования  ИБ-специалист становится обязательным членом команды постановки требований (продуктовой команды)
  • 20. Анализ рисков ИБ Agile
  • 21. Анализ рисков ИБ Agile  С легкостью решается обратная задача: понять, в каких историях был найден риск X, или применено решение Y  Приоритетны переиспользуемые решения  Визуальный business trade-off – снижать, или не снижать риск предложенным решением при указанных затратах  Удобно прогнозировать изменение объемов и сроков работ по историям для реализации конкретного решения ИБ
  • 22. Разработка Agile  Повышение «видимости» процесса разработки – возможность контролировать процесс создания кода и его качество  Обязательные ревью + рефакторинг = более высокая эффективность обучения принципам безопасного написания кода  Эффективное использование простых баз знаний и библиотек типа OWASP ESAPI  «Безболезненное» внедрение процедур регулярной проверки кода на низкоуровневые уязвимости – совместное ревью и статический анализ кода
  • 23. Чек-листы правил OWASP для разработчиков
  • 24. Обучающие семинары (OWASP) для разработчиков
  • 25. Тестирование Agile  Участие тестировщика в процессе формирования карт рисков – формирование планов и приоритетов функционального тестирования ИБ-функционала на основании рисков, уязвимостей и методов эксплуатации  Оперативная коммуникация результатов тестирования по относительно небольшим объемам разработанного функционала  Стандартизация планов тестирования для типовых мер безопасности  Возможность автоматизации процесса тестирования типовых мер безопасности  Использование стандартных (привычных) инструментов для статического анализа кода, а также возможность оперативной оценки значительности найденных уязвимостей
  • 26. Тестирование Agile  Должен появиться выделенный (dedicated) тестировщик, ответственный за безопасность  Тестировщики должны участвовать в анализе рисков и выборе мер безопасности  Составляются стандартизованные отчеты с результатами тестирования  По результатам можно запретить выпуск релиза  Нужен специалист с достаточной экспертизой по безопасности  Функциональную составляющую процесса можно делегировать в команду, и проверять ее результаты
  • 27. Постановка тест-планов сценариев безопасности Agile
  • 28. Проверка уязвимостей исходного кода Agile
  • 29. Трэкинг найденных уязвимостей
  • 30. Безопасность в agile + Как правило не требуется отдельного процесса формальных согласований с требованиями + Существенно выше ценность разработанных карт рисков ИБ, а также описаний использованных мер по снижению этих рисков + Формируется общая концепция безопасности, понятная всей команде разработки + Ориентированность на переиспользование типовых, хорошо протестированных мер по снижению рисков + Качество кода выше, т.к. его контроль заложен методологией; меньше дефектов, ведущих к уязвимостям ПО - Риски проанализированы только для известной части продукта - Карта рисков может радикально измениться при значительном изменении продукта - Задача специалиста ИБ становится регулярной, требования к его экспертизе и объему участия существенно возрастают
  • 31. Спасибо!  Дмитрий Баранов,  dbaranov@round.ru,  dimitry.a.baranov@gmail.com