2015 02 пм качалин sdl
Download as PPTX, PDF1 like686 views
Документ описывает внедрение цикла безопасной разработки программного обеспечения и его важность для организаций. Обсуждаются шаги к безопасной разработке, включая осознание проблем, проверку и выпуск продукта, а также внедрение и мониторинг. Автор подчеркивает значимость соблюдения требований регуляторов и интеграции безопасной разработки в существующие процессы.
2015 02 пм качалин sdl
- 1. «Опасная разработка. Дорожная карта движения к катастрофе» Практика внедрения в организациях цикла безопасной разработки программного обеспечения Качалин Алексей Зам. Генерального директора ЗАО «Перспективный мониторинг»
- 2. О наших работах по теме • Инструментальный анализ ПО и ИС • С 2012 года – работаем по направлению повышения безопасности разработки • Принимаем участие в работе ГК с регуляторами – ФСТЭК: требования к СЗИ и ИБ платформ, база угроз, безопасная разработка – ФСБ: СОПКА
- 3. Безопасная разработка: этапы осознания проблем Мониторинг и реагирование Проверка и выпуск продукта Разработка Проектирование Требования Подготовка команды Внедрение цикла безопасной разработки
- 4. Шаг 1. Такая безопасность не нужна 2010 год. Эксперт по ИБ/соответствию требованиям: «… работы по инструментальному анализу не будут востребованы, нет таких требований у регуляторов» • ФСТЭК: о безопасной разработке • «Банки будут стремиться оптимизировать расходы, а самый оптимальный способ – вывести операции в Интернет» • «Анализ безопасности ПО - одно из немного за что в кризис банки будут готовы платить» Февраль 2015. Конференция ИБ Банков
- 5. Безопасность разработки - требование рынка • Уязвимости и инциденты ИБ – Репутация невозможно контролировать раскрытие информации – Раскрытие информации об уязвимостях используемых компонентов – Обращения к регулятору с вопросами от пользователей • Необходимость реакции – Взаимодействие с «атакующим» сообществом • Требования НПА и регуляторов • Требования 3-их лиц по гарантиям ИБ
- 6. Шаг 2. Соответствие как самоцель «При выполнении работ должны применяться практики безопасной разработки программного обеспечения» Из ТЗ
- 7. Разработка Подтверждение соответствия ПО Как устроена разработка • Водопад – не модно? • Итеративные и гибкие методики В худшем случае – после разработки • Внутренние требования организации • Требования регуляторов отрасли (БР, PCI DSS) • Требования гос.регуляторов • …Разработка Проект Проект Безопасная разработка Проект Проект Безопасная разработка
- 8. Шаг 3. ИБ будет протестировано «… в случае возникновения проблем у внедряемого сервиса мы обратимся за анализом уязвимостей» Руководитель службы эксплуатации сервиса в первом проекте «…мы хотим сделать новый сервис, представляющий следующие возможности:…, насколько это безопасно?» Он же, несколько проектов спустя
- 9. Эволюция требует повторений Мониторинг и реагирование Проверка и выпуск продукта Разработка Проектирование Требования Подготовка команды Внедрение цикла безопасной разработки 1
- 10. Эффект от внедрения безопасной разработки • Осязаемые результаты: отдача от инвестиций – Возврат инвестиций • ПО финансовых, подверженных фроду систем – возможно – Снижение количества инцидентов – Оперативность реагирования на инциденты • Встраивание в существующий процесс разработки (заказа и эксплуатации ПО) • Часто применение к имеющимся продуктам или компонентам – Вам продают «задел по теме», свой или чужой • Вовлечение команды (мотивация исполнителя и легитимизация затрат) на дополнительные практики ИБ 10
- 11. Шаг 4. Какая-то безопасность разработки «Мы себя проверили – у нас многое есть. Программисты что-то такое делают. Не надо ничего менять» В ответ на предложение развивать практики Отказ от изменений Самообман Непонимание
- 12. Не так уж и сложно соответствовать SDL Basic Standardized (Activities are expert led) Advanced (Activities are led by central security team) Dynamic (Activities are co- led by product teams and central security team) Training, Policy Organizational Capabilities + Setting baseline and goals for SDL + Executive support: Tacit + Enterprise coverage: Few SDL pilot project +/- Training: Basic concepts +/- Basic security bug tracking - Executive support: Explicit - Enterprise coverage: New, high risk project - Training: Common baseline - Central security team exists - Executive support: SDL mandated and enforced - Enterprise coverage: All project with meaningful risk +/- Training: Custom training - SDL is adopted to the development methodology Requirements Design Undefined or inconsistent - Risk assessment +/- Threat models: Piloted to high-risk modules - Functional requirements for security and privacy - Standard security solutions +/- Threat models: Created with expert assistance - Threat models: Independently created by product group Implementation Undefined or inconsistent + Compiler defense - Banned functions - Cross-site scripting and SQL injection defenses +/- Static analysis tools - In-house, product-specific security tools development and customization Verification Undefined or inconsistent - File fuzzing - Basic Web application scanning + Penetration testing by third party as appropriate +/- Comprehensive fuzzing and Web application scanning - Threat model validated - In-house development and customization tools to: + Detect vulnerabilities - Audit compliance with SDL Release Response Undefined or inconsistent - Final Security Review: Verify internal and external compliance + Project archiving + Response: Basic + Response plan in place, incident tracking - Basic root-cause analysis - Real-time incident tracking - Advanced root-cause analysis and formal feedback into policy
- 13. Ловушки инструментов и практик “as is” • Выбор инструментов и компонентов – Удобство среды разработки – Использование знакомых компонентов – Борьба с унаследованным кодом • «Безопасное программирование» == ИБ? – Утечки памяти, переполнение буфера, падения/повисания – Безопасные опции компилятора • Инструменты безопасности при разработке – Анализаторы кода – Генераторы нагрузки без тонкой настройки – Системы автоматизированного тестирования • Практики управления – Менеджер форсирует: бюджет, сроки, функционал – Унаследованный долг: было 500 предупреждений, будет 507 – ок?
- 14. Кстати о говоря – о границах понимания • «Уязвимость» – все говорят, скоро зафиксируют в НПА • Различные этапы проявления уязвимостей – Уязвимости эксплуатации – Уязвимости, вносимые на этапе формирования требований • CVE vs CWE - Уязвимость vs Слабость – Необходимость логичной замкнутой системы определений и понятий • Корректность «атакующей» терминологии – «Василий провёл с своего компьютера DDoS» – Пользователи устроили DDoS сервиса – В вашем ПО – эксплоит
- 15. Шаг 5. Строим безопасную разработку по учебнику «Я не читаю курсы по SDL» Алексей Лукацкий, кладезь по ИБ
- 16. Что можно почерпнуть из практик MSDL, CSDL, … • Модель зрелости должна быть – Подходящая этапность внедрения? • Домены – Можно суммировать и расширить • Готовые методы, инструменты, классификации – Моделирование угроз, трассировка уязвимостей для оценки ущерба
- 19. Пример одного анализа • Продуктовый менеджмент – Интенсивность разработки • Бизнес: база внедрений, перспективы продаж • Разработка: технологические тренды, тех.долг и архитектура • Установка и сопровождение – «Агрессивность среды» – Инциденты
- 20. Шаг 6. Если решать - то все проблемы «Если нельзя полностью гарантировать доверие начиная от аппаратной базы, … - то нет смысла вообще заниматься вопросами безопасности» Анализ
- 21. Решить проблему нельзя принять риски • «Крупноузловая» сборка – Фреймворки и библиотеки • Инструменты разработчика – Инструменты проектирования – Инструменты разработки – Инструменты хранения и сборки • Инфраструктура ПО – Магазины мобильных приложений и хранения данных
- 22. Внедрение безопасной разработки даёт ценную информацию к размышлению Мониторинг и реагирование Проверка и выпуск продукта Разработка Проектирование Требования Подготовка команды Внедрение цикла безопасной разработки
- 23. Развитие мониторинга и реагирования • Обнаружить публикацию информации об уязвимости – Публикация уязвимости в используемом компоненте – Публикация информации об уязвимости в Интернет – Сети обмена информацией об уязвимостях – Технический анализ (состояние узлов, трафик, журналы) • Интерпретировать обращения пользователей – Сообщения о «странном поведении программы» (нет явного подозрения на проблемы ИБ) – Попытки шантажа и ультиматумы, оскорбления и троллинг – Готовый метод компрометации ИБ (пошаговый, в виде PoCE) … • Внутренние сообщение от разработчика – обратить внимание – Указания на строчку кода – Развёрнутый анализ с обоснованием неизбежности уязвимости
- 24. Итого • Разрозненные практики ИБ часто расходы на иллюзию безопасности – должна быть поставлена цель – Синергия безопасной разработки и соответствия требованиям – Стратегический план реалистичный по ресурсам и времени • Очень многое зависит от автоматизации и инструментов – но они не панацея – Инструменты определяют отдельные сценарии – целостность? – Риск автоматизации хаоса • Реагирование дороже предотвращения 24 • «Бесплатно» получится плохо – Корректировка бюджетов и границ проектов – Безопасность – в «системе ценностей» менеджмента – Внутренняя команда внедрения
- 25. худшая из угроз - Неведение Инструментальный анализ ПО и ИС Внедрение практик безопасной разработки Мониторинг ИБ Качалин Алексей kachalin@advancedmonitoring.ru
Editor's Notes
- #2: «Опасная разработка. Дорожная карта движения к катастрофе» Начнём с цитаты: «… при реализации первой версии нашего продукта мы не занимались вопросами информационной безопасности, мы планируем заняться ими после запуска пилотной версии сервиса.» Общение с разработчиком программного обеспечения об уязвимостях продукта начинается, как правило, на этапе эксплуатации. На этом этапе все активности, связанные с реагированием и устранением проблем максимально дороги как для разработчика, так и для всех участников «цепочки поставки». Сложившаяся практика делегирования ответственности приводит к тому, что ответственным назначается компания-разработчик, который в свою очередь, в полном соответствии с лицензионным соглашением, имеет право поставлять изделие «как есть» и по факту не несёт обязательств (кроме моральных) по устранению выявленных проблем. Может ли быть изменена установившаяся тупиковая практика, приводящая к отсутствию у участников процесса позитивных стимулов обратить внимание на безопасность итогового решения? Если абсолютная безопасность не может быть достигнута, то какие приёмы на этапах формирования требований и проектирования могут принести пользу и какова допустимая цена этих мер? Как могут повлиять на разработчика заказчики, поставщики, исследователи и пользователи решений? Готового ответа на эти вопросы, пригодного на все случаи жизни очевидно нет, но даже внесение этих вопросов в обсуждение может стать существенным шагом вперёд. Ключевые слова: вопросы безопасной разработки, практика проверки продуктов на уязвимости, разработка программного обеспечения, сопровождение разработки заказчиком, регулирование разработки программного обеспечения
- #8: 1. Данный документ является одним из первых нормативных документов по данной тематике, в котором установлены конкретные требования к процессу разработки, а не к продукту. 2. При разработке данного ГОСТа были учтены лучшие мировые практики по безопасной разработке. 3. В ГОСТе предусмотрен контроль (мониторинг) системы управления безопасной разработкой программного обеспечения, который проводится через внутренние аудиты системы управления безопасностью разработки ПО, что позволяет контролировать качество выполнения требований на всех этапах разработки. 4. Определена необходимость периодического обучения сотрудников организации-разработчика ПО с целью повышения их осведомленности в области безопасной разработки ПО. 5. В госте определены какие документированные свидетельства необходимы для реализации мер по обеспечению безопасности разработки ПО.
- #18: Проекты по развитию существующих продуктов Критичность Распространение на рынке Критичность сценариев Пилотные и исследовательские проекты Новые продукты «Агрессивность» среды Модель угроз/нарушителя Статистика инцидентов Подверженность атакам на распространённые заимствованные компоненты
- #19: Проекты по развитию существующих продуктов Критичность Распространение на рынке Критичность сценариев Пилотные и исследовательские проекты Новые продукты «Агрессивность» среды Модель угроз/нарушителя Статистика инцидентов Подверженность атакам на распространённые заимствованные компоненты