Безопасная разработка для руководителей

Доклад Валерия Боронина (Positive Technologies) о внедрении процесса безопасной разработки с точки зрения руководителя на PDUG Meetup: SSDL for Management.

Transcript

1. Безопасная разработка для руководителей Валерий Боронин Руководитель отдела решений по построению процесса безопасной разработки Positive Technologies Москва, 25 ноября 2016
2. SSDL для руководителей PDUG 15:30-16:00 Регистрация 16:00-16:10 Вступительное слово 16:10-16:45 История SDL и ее использование в Microsoft 16:45-17:00 Перерыв 17:00-17:45 SSDL для руководителей. Теория 17:45-18:00 Перерыв 18:00-18:45 SSDL для руководителей. Практика 18:45-19:00 Перерыв 19:00-20:00 SSDL для руководителей. Демо, дискуссия Программа PDUG Meetup
3. SSDL для руководителей PDUG  Валерий Боронин  В разработке и R&D более 20 лет  В безопасности с прошлого тысячелетия ;-)  Работал CTO небольшой компании (30+ человек)  А также директором по исследованиям (Лаборатория Касперского, 2500+ человек, 2009-2014)  Сейчас отвечаю за направление безопасной разработки (SDL / SSDL) в Позитиве  Мы с командой создаем новый продукт для автоматизации безопасной разработки О докладчике SSDL-митап, Москва 3 25 ноября 2016
4. SSDL для руководителей PDUG Мы не обсуждаем:  Важна ли безопасность  Каков приоритет безопасности над расписанием и остальными вещами  Нужна ли безопасная разработка (SDL / SSDL) Мы обсуждаем:  Что нужно знать и что делать руководителям  Что конкретно и почему предлагается делать на каждой стадии  Каковы выгоды и затраты / риски от изменений Мы делимся опытом, так как успешных управленческих решений может быть больше, чем одно Предпосылки SSDL Митап, Москва 4 25 ноября 2016
5. 25.09.2017 SSDL Митап, Москва, Белые Сады 5 1. Что надо знать руководителям? 2. Подготовка к последствиям перехода на SDL 3. Что должны делать первые лица / руководители? I. SDL для руководителей
6. SSDL для руководителей PDUG  Планирование  Организация  Мотивация  Контроль  Координация Этапы связаны процессами  Принятия решений  Коммуникации Разогрев. Базовый управленческий цикл SSDL Митап, Москва 6 25 ноября 2016
7. SSDL для руководителей PDUG  Планирование: где мы, куда идем, как. Общая цель и критерии / метрики  Организация: что, кто, когда  Формализация структуры  Обеспечение всем необходимым  Создание условий для перестройки  Мотивация  Контроль: процесс обеспечения достижения результата  Установление стандартов – точная цель в определенное время  Измерение и план / факт – знаем проблему и источник  Коррекция серьезных отклонений  Координация  Достижение согласованной работы всех звеньев путем установления рациональных связей  Отчеты, собрания, интервью, Skype, документы  Дает взаимное маневрирование ресурсами, единство и согласованность всех функций процесса управления и руководителей Разогрев. Базовый управленческий цикл SSDL Митап, Москва 7 Информация отсюда 25 ноября 2016
8. SSDL для руководителей PDUG Что надо знать про SDL руководителям? Подготовка к последствиям в SDLC при переходе на SDL Ресурсы Влияние на расписание, бюджет Как убедиться, что мы соответствуем требованиям SDL? Что должны делать первые лица / руководители, чтобы обеспечить разработку более защищенного ПО? SDL для руководителей SSDL Митап, Москва 8 SDL не бесплатен: нужны время, бюджет, твердое обязательство руководства гарантировать приоритет безопасности 25 ноября 2016
9. SSDL для руководителей PDUG Заказчики жалуются на частоту и стоимость «залатывания дыр» в безопасности Современные атаки оказывают влияние на IT заказчиков до такой степени, что становятся заметны и внутренним, и внешним пользователям, SLA СМИ настолько фокусируются на проблемах безопасности, что те затмевают все продуктовые улучшения Необходимость частых исправлений и выпуска патчей, фиксов и прочая работа «по хвостам» мешают создавать новые фичи и код Хотя цена патчей и невысока в абсолютных цифрах, частое отвлечение разработчиков на заплатки делает расписание менее предсказуемым Почему нужно подойти системно? SSDL Митап, Москва 9 25 ноября 2016
10. SSDL для руководителей PDUG E-mail первого лица Обсуждение среди руководителей Непоколебимая вера в то, что изменения важны Выступайте с заявлением SSDL Митап, Москва 10 Полезно: используйте в своих сообщениях три составляющих – индивидуальный, групповой, глобальный уровни 25 ноября 2016
11. SSDL для руководителей PDUG 3R: Reminders, Recognition & Rewards  Периодические встречи для напоминания того, что выше  Поиск и награждение передовиков, подтягивание отстающих  Внедрение всего этого в культуру организации Задача руководителя заключается в организации и поддержке. Эта задача решается просто: используйте этапы SDL, на каждом из них будет масса возможностей  Что делать: убедиться / донести, чего вы ожидаете, на что смотрите, поощрять инициативу во благо SDL  Цель: сделать процесс самодостаточным, самовоспроизводящимся Действуйте открыто SSDL Митап, Москва 11 Безопасность – дело каждого! 25 ноября 2016
12. SSDL для руководителей PDUG Управляйте бюджетами на разработку и превращайте издержки в инвестиции Платить или нет – выбор за вами. В сфере безопасности вы получаете то, за что платите Windows Server 2003: 2 дня → в 8 недель Выделяйте ресурсы SSDL Митап, Москва 12 В SDL важно убрать все ненужное 25 ноября 2016
13. SSDL для руководителей PDUG Почему может быть нужно приостановить выпуск? Находим слишком много – темп важен Функция не просто небезопасна, а не может стать таковой Возникли новые угрозы Final Security Review (FSR) провален для продукта или компонента Вовремя остановитесь SSDL Митап, Москва 13 25 ноября 2016
14. SSDL для руководителей PDUG “Rules of thumb”  Большие legacy проекты дают плюс 20% к затратам  C нуля или на 2+ итерации с SDL получаем экономию от 20% Воздействие  Заказчики  Репутация  Потерянные продажи Главное  Необходимо понимать, что без SDL дороже, чем с ним Управление SDL. Ресурсы SSDL Митап, Москва 14 Формулы нет 25 ноября 2016
15. SSDL для руководителей PDUG  Новые проекты становятся выгодными  Поддерживать большие legacy проекты становится дорого  Первая итерация собирает все и вклад идет по $, времени, плану  Вторая и более итерации – хорошо. Не даем «бардак разводить»  Managed > Unmanaged  Удалить нельзя лечить  Процессы и средства эффективны только вместе с людьми  Продукты «с историей» и постоянными косяками обычно не правят: дорого, некогда и т. п. Но терпеть – дороже  Проводите тренинги. Они снижают общую стоимость безопасности. Эффективная программа мотивирует на создание качественного и защищенного кода. Меньше багов, меньше работы «по хвостам»  Secure designs сильно снижают последствия в виде багов и существенность оставшихся уязвимостей, а также TCO  А каков ваш опыт / вариант? Управление SDL. Влияние на издержки SSDL Митап, Москва 15 25 ноября 2016
16. SSDL для руководителей PDUG  Отслеживайте посещение тренингов для своих команд Используйте оценки тестов и очки, если они собираются  Отслеживайте создание моделей угроз и качества со старта Есть смысл в создании спецбригады для TM review. Это актуальность + опыт / сноровка / закалка / тренировка + отлов проблем на самых ранних стадиях  Отслеживайте темп появления и типы уязвимостей по стадиям Уменьшается ли к концу проекта число реальных / потенциальных уязвимостей? Есть ли классы (по типу, по компонентам), где уровень не снижается?  Отслеживайте воздействие найденных снаружи уязвимостей Старые версии Конкуренты  Следите за динамикой Постоянно узнавайте / учите, что все это значит с точки зрения SDL Управление SDL. Контроль SSDL Митап, Москва 16 25 ноября 2016
17. SSDL для руководителей PDUG Без поддержки сверху проект не взлетит Никто не даст точные оценки по стоимости и выгодам Несмотря на отсутствие исчерпывающего руководства, которое бы гарантировало успешность перехода на SDL, работают следующие простые вещи: Отслеживание deliverables и активностей SDL постадийно. Так все можно четко посчитать, причем под себя Отслеживание внешних метрик, таких как удовлетворенность заказчика в плане безопасности Отслеживание темпов появления и отработки инцидентов безопасности Управление SDL. Выводы SSDL Митап, Москва 17 Безопасная разработка скорее про страховку, чем про функциональность 25 ноября 2016
18. SSDL для руководителей PDUG Не надо:  Слишком полагаться на тестирование на поздних этапах цикла  Управлять без измерений  Обучать, не оценив  Начинать без достаточной поддержки руководства  Политические риски  Бюджетные риски  Стандартные сложности управления изменениями (организационными, в частности) – люди, процессы, технологии – становятся максимально серьезными Стандартные «затыки». На заметку SSDL Митап, Москва 18 Обучение, ответственность и ясные цели – ключевые компоненты успеха любой программы по безопасности 25 ноября 2016
19. SSDL для руководителей PDUG Стандартные отговорки: Сроки горят (время) Нет ресурсов (бюджета, экспертизы, инструментов) на обеспечение безопасных практик Мы стартап. Нам нужно быстрее стать популярными и заработать много денег … Разработчики и безопасность SSDL Митап, Москва 19 Shortage of skill or shortage of discipline? Знать мало – надо применять! 25 ноября 2016
20. 25.09.2017 SSDL Митап, Москва, Белые Сады 20 1. Education 2. Project Inception 3. Define & Follow Best Practices 4. Product Risk Assessment 5. Risk Analysis 6. Creating Tools, Docs, Best Practices for Customers 7. Secure Coding Policies 8. Secure Testing Policies 9. Security Push 10. FSR 11. Security Response Planning 12. Release 13. Security Response Execute II. SDL на практике. Стадии SDLC
21. SSDL для руководителей PDUG SDL одним взглядом SSDL Митап, Москва 21 SDLC Training Reqs Design Impl Verification Release Response 25 ноября 2016
22. SSDL для руководителей PDUG Постоянное обучение Способы доставки тренингов Практические упражнения Измерение знаний Нужно обследовать подготовленность организации в сфере безопасности и защиты данных (privacy) При необходимости создать стандартные курсы обучения Базовый уровень Повышение осведомленности Кто: все задействованные сотрудники с техническими ролями (Devs, QA, PMs) Как часто: 1+ раз в год Что: знания для выполнения остальных фаз + подход к работе по новому процессу 1. Education SSDL Митап, Москва 22 Безопасность – дело каждого! 25 ноября 2016
23. SSDL для руководителей PDUG Как организации сделать новый курс самостоятельно?  Нужно определить цели и целевую аудиторию для курса  Эксперт по безопасности делает новый курс – рабочую программу  Другие технические эксперты смотрят материалы на предмет технической точности и применимости  Эксперты по тренингам (не безопасники) и редакторы вычитывают и улучшают структуру и содержание  Проводится первый курс. Главная цель – понять тайминг и получить обратную связь по поводу содержания  Материалы обновляются с учетом поступившей информации  Курс повторяется ежемесячно минимум полгода  Через полгода курс записывается и выкладывается в интранет 1. Education. Создаем свой курс обучения SSDL Митап, Москва 23 Для максимально бюджетных вариантов всегда есть PowerPoint Record Narration 25 ноября 2016
24. SSDL для руководителей PDUG Ключевые показатели эффективности Поддержка первых лиц Опытные спикеры Постоянное обучение Измерение – чревато Как будем использовать? Приобретение – легко Удержание – не очень ;-) SDL-compliant – 100% посещаемость Все должны посещать Нужно вести базу с отметками Идеи про CPE 1. Education. KPI & Metrics SSDL Митап, Москва 24 25 ноября 2016 Сertification Points Earned • Был на конференции по ИБ (1 CPE за час посещения) • Был на презентации ИБ-вендора (1 CPE за час посещения) • Провел тренинг по ИБ (4 CPEs за каждый час проведения) • Написал статью по ИБ (10 CPEs) • Выпустил книгу по ИБ (40 CPEs) • Прочел книгу по ИБ (5 CPEs)
25. SSDL для руководителей PDUG  The Basics of Secure Software Design, Development, and Testing  Fuzz Testing in Depth  Threat Modeling in Depth  Implementing Threat Mitigations  Security Design and Architecture: Time- Tested Design Principles  Introduction to the SDL and Final Security Review (FSR) Process  Security Tools Overview  Performing Security Code Reviews  Secure Coding Practices  Security Bugs in Detail  Attack Surface Analysis (ASA) and Attack Surface Reduction (ASR)  Exploit Development  Build Requirements  Security Response  Cryptography by Example  Customer Privacy Basic software security training should cover foundational concepts such as: Secure design, including the following topics:  Attack surface reduction  Defense in depth  Principle of least privilege  Secure defaults Threat modeling, including the following topics:  Overview of threat modeling  Design implications of a threat model  Coding constraints based on a threat model Secure coding, including the following topics:  Buffer overruns (for applications using C and C++)  Integer arithmetic errors (for applications using C and C++)  Cross-site scripting (for managed code and Web applications)  SQL injection (for managed code and Web applications)  Weak cryptography Security testing, including the following topics:  Differences between security testing and functional testing  Risk assessment  Security testing methods Privacy, including the following topics:  Types of privacy-sensitive data  Privacy design best practices  Risk assessment  Privacy development best practices  Privacy testing best practices As time and resources permit, training in advanced concepts may be necessary. Examples:  Advanced security design and architecture  Trusted user interface design  Security vulnerabilities in detail  Implementing custom threat mitigations 1. Education. Чему учить? 2016 vs 2006 SSDL Митап, Москва 25 Изучай в offline 25 ноября 2016
26. SSDL для руководителей PDUG  Проверить применимость Продукт или SP  Назначить Security Advisor Навыки управления проектами и построения процессов Внедрение практик для всей линейки продуктов  Задачи Точка контакта Dev<->Sec Team Reply Cc on security Q Kickoffs for Dev team Goals of SDL Key Process Points – design & TM review Встроить в расписание SDL активности 2. Project Inception SSDL Митап, Москва 26 Назначайте снаружи 25 ноября 2016
27. SSDL для руководителей PDUG Analyzing & Triaging Security & Privacy Bugs Security Sounding Boards Preparing for FSR Working with Reactive Sec Teams Building the Security Leadership Team Bug Tracking process Security & Privacy fields Bug Bar 2. Project Inception SSDL Митап, Москва 27 25 ноября 2016
28. SSDL для руководителей PDUG The Security/Privacy Bug Effect field:  Not a Security Bug  Spoofing  Tampering  Repudiation  Information Disclosure  Information Disclosure (Privacy)  Denial of Service  Elevation of Privilege  Attack Surface Reduction – это уже не STRIDE, а скорее про defense-in- depth 2. Project Inception. Bug Tracking Process SSDL Митап, Москва 28 The Security/Privacy Bug Cause field:  Not a Security Bug  Buffer Overflow or Underflow  Arithmetic Error (for example, integer overflow)  SQL/Script Injection  Directory Traversal  Race Condition  Cross-Site Scripting  Cryptographic Weakness  Weak Authentication  Weak Authorization/Inappropriate ACL  Ineffective Secret Hiding  Resource Consumption (DoS)  Incorrect/No Error Messages  Incorrect/No Pathname Canonicalization  Other 25 ноября 2016
29. SSDL для руководителей PDUG Common Secure-Design Principles Attack Surface Analysis Attack Surface Reduction 3. Define & Follow Best Practices SSDL Митап, Москва, Белые Сады 29  Economy of mechanism Keep the code and design simple and small  Fail-safe defaults  Complete mediation Every access to every protected object should be validated. Follow the best practice of performing the check as close to the protected object as possible  Open design Open design, as opposed to “security through obscurity,” suggests that designs should not be secret.  Separation of privilege Do not permit an operation based on one condition. Ex: two-factor authentication & separation of duties  Least privilege Operate with the lowest level of privilege necessary to perform the required tasks  Least common mechanism Minimize shared resources such as files and variables  Psychological acceptability Is your secured product easy to use? If not, it won’t be used. You should always ask yourself, “Can I implement this system in a way that makes the product easier to use?” Сложность и безопасность: простота – залог здоровья Изучай в offline 25 ноября 2016
30. SSDL для руководителей PDUG Анализируем и снижаем поверхность атаки  Шаг 1. Настолько ли важна конкретная функциональность?  Шаг 2. Кому нужен какой доступ к чему и откуда?  Шаг 3. Режем привилегии Services and Low Privilege UDP vs TCP Weak Permissions vs Strong Permissions .NET Code vs ActiveX Code 3. Define & Follow Best Practices. ASR SSDL Митап, Москва 30 Проще говоря, делаем так:  Ограничиваем количество кода, доступного по умолчанию  Ограничиваем в плане, откуда можно добраться до кода  Ограничиваем в плане, кто может добраться до кода  Уменьшаем привилегии кода 25 ноября 2016
31. SSDL для руководителей PDUG  Уточнить уровень поддержки SDL активностей  Что требуется покрыть моделями  Что требует дизайн ревью  Что требует тестирования на проникновение  Что требует динамического анализа / фаззинга  Security Risk Assessment Quiz  Privacy Impact Rating  Анонимные данные  PII  Чувствительные данные  Найти компоненты с наибольшим риском  Поработать с каждым Это поможет с оценками! 4. Product Risk Assessment SSDL Митап, Москва 31 Если от обладания PII и чувствительных данных нет выгоды, нужно удалять 25 ноября 2016
32. SSDL для руководителей PDUG Преимущества от моделей угроз Модели угроз (артефакты) Что моделировать? Строим модель (подготовить → проанализировать → принять меры) Процесс Поможет code review & testing Ключевые показатели эффективности и метрики 5. Risk Analysis SSDL Митап, Москва 32 25 ноября 2016
33. SSDL для руководителей PDUG Преимущества от моделей угроз по мнению Microsoft  Вносят вклад в процесс управления рисками, потому что угрозы ПО и инфраструктуре – это риски для пользователей и окружения, в котором развертывается ПО  Вскрывают угрозы системе до того, как система реализуется в коде  Позволяют перепроверить архитектуру и дизайн, потому что команда разработки проходит через редизайн снова и снова  Заставляют разработчиков смотреть на дизайн с разных точек зрения, а именно: безопасности и защиты данных. Понимая, какие компоненты больше всего подвергаются риску, разработчики фокусируются на компонентах, которые наиболее вероятно подвергнутся атаке  Помогают уточнить выбор целесообразных мер для ПО и окружения  Вносят вклад в процесс уменьшения поверхности атаки  Помогают с ревью кода  Направляют тестирование на проникновение 5. Risk Analysis. TM. Преимущества SSDL Митап, Москва 33 Изучай в offline 25 ноября 2016
34. SSDL для руководителей PDUG  Высокоуровневая модель приложения  Диаграммы типа DFD  Список того, что требует защиты  Угрозы системе, ранжированные по рискам  Список компенсирующих мер (опционально) Плюс вспомогательная информация:  Use scenarios (обычные конфигурации развертывания)  External dependencies (продукты, компоненты, сервисы, от которых есть зависимость)  Security assumptions (на что можно рассчитывать в плане безопасности сторонних компонентов)  External security notes (полезная информация для администраторов или пользователей, позволяющая работать более защищенно) 5. Risk Analysis. TM. Artifacts SSDL Митап, Москва 34 25 ноября 2016
35. SSDL для руководителей PDUG 1. Определите сценарии использования 2. Соберите внешние зависимости (системные требования) 3. Определите предположения касательно безопасности 4. Сделайте external security notes (какие порты открыты и зачем) 5. Сделайте одну или больше DFD моделируемого приложения 6. Определите типы угроз (STRIDE и т. п.) 7. Идентифицируйте угрозы системе (процессы, хранилища данных, потоки данных, внешние сущности) 8. Определите риски (полезны деревья ранжирования рисков для каждой угрозы из STRIDE) 9. Спланируйте компенсирующие меры (ничего не делать, удалить, отключить, предупредить пользователя, компенсировать с помощью техники (широко) или технологии (конкретно) 5. Risk Analysis. The TM process SSDL Митап, Москва 35 Изучай в offline 25 ноября 2016
36. SSDL для руководителей PDUG Порнография и модели угроз – что общего? 5. Risk Analysis. TM. KPIs & Metrics SSDL Митап, Москва 36 25 ноября 2016
37. SSDL для руководителей PDUG Ключевые факторы успеха и метрики Порнография и модели угроз 5. Risk Analysis. TM. KPIs & Metrics SSDL Митап, Москва 37 “I shall not today attempt further to define the kinds of material [pornography]… but I know it when I see it” Potter Stewart 25 ноября 2016
38. SSDL для руководителей PDUG Как минимум, модели угроз должны быть помечены “OK”, а те компоненты, по которым выполнялись пентесты, – “Good” или лучше  No threat model (0). Отсутствие модели недопустимо, потому что это означает, что никакие угрозы не рассматривались  Not acceptable (1). Модель явно не актуальна, если: Текущий дизайн существенно отличается от описанного в модели угроз Дата в документе показывает, что он старше года  OK (2) Есть DFD или следующий список: Assets (processes, data stores, data flows, external entities), Users, Trust boundaries (machine to machine, user to kernel, high to low privilege и наоборот) Как минимум одна угроза детализирована для каждого актива (asset) Компенсирующие меры есть для всех угроз с риском уровня 1, 2, 3 Модель актуальна 5. Risk Analysis. TM. Quality Guidelines. 1/2 SSDL Митап, Москва 38 Изучай в offline 25 ноября 2016
39. SSDL для руководителей PDUG Good (3) Модели угроз соответствуют критерию “OK” Anonymous, authenticated, local and remote users все показаны на DFD Все S, T, I и E угрозы идентифицированы и классифицированы либо как скомпенсированные, либо как принятые Excellent (4) Модели угроз соответствуют критерию “Good” Все STRIDE угрозы идентифицированы и имеют снижения рисков, есть примечания безопасности (external security notes) либо dependencies acknowledged Смягчения риска есть для каждой угрозы Примечания безопасности включают план создания customer-facing документов (from the external security notes), которые объясняют, как использовать эту технологию безопасно и какие могут быть компромиссы 5. Risk Analysis. TM. Quality Guidelines. 2/2 SSDL Митап, Москва 39 25 ноября 2016 Изучай в offline
40. SSDL для руководителей PDUG Setup Docs User Guide Help Docs Dev Docs Creating Tools (Lockdown Tool) Security implications В зависимости от действий От конфигураций Как заморозить конфигурацию Как делать upgrade Как делать поверх / вместо конкурента Install / Maintain / Use 6. Creating Tools Docs Best Practices SSDL Митап, Москва 40 25 ноября 2016
41. SSDL для руководителей PDUG Latest tools & secure options Помощь компилятора SAST Tools to find at least Enforce & disciplined usage Code check-in Материал для ревью Не используем banned API Уменьшаем потенциально эксплуатируемые конструкты уровня кода и дизайна Use a secure code checklist Check-in policies 7. Secure Coding Policies SSDL Митап, Москва 41 Знать мало – надо применять! 25 ноября 2016
42. SSDL для руководителей PDUG DAST / Fuzz testing File format / protocol parsers, API 100000 cycles Penetration testing Run-time verification AppVerif & Driver Verifier Re-review threat models Largest attack surface Threats with highest risks Focus code review & testing efforts Reevaluate attack surface Corrective actions (not to ship, disable by default, modify dev practices) Documenting! – update 8. Secure Testing Policies SSDL Митап, Москва 42 Best Practices Every time you find a security vulnerability in your application, build a small test plan to verify the existence of the bug, and then later reuse the test to verify that the code is fixed. Build on this series of tests as new vulnerabilities are found, and rerun all the tests on an ongoing basis. 25 ноября 2016
43. SSDL для руководителей PDUG 7. Secure Testing Policies. Triage Bars for Fuzz SSDL Митап, Москва 43 Изучай в offline 25 ноября 2016
44. SSDL для руководителей PDUG Example: Fixing Bugs Found Through Fuzz Testing Server Code Bug Bar 8. Secure Testing Policies SSDL Митап, Москва 44 25 ноября 2016 Изучай в offline
45. SSDL для руководителей PDUG  Когда делать? Code & feature complete, beta. Потом еще один тестовый цикл  Цель: найти баги, не править  Длительность: сколько потребуется  Task-driven, not time-driven  Критерии завершения: Training Code reviews Exec files owners Threat models updates Security testing, attack surface scrub Document scrub  Подготовка: ресурс со статистикой (Web, DB, competitions)  Security focused 9. Security Push SSDL Митап, Москва 45 25 ноября 2016
46. SSDL для руководителей PDUG Команды, которые выполнили следующие задачи, будут иметь более короткий Security Push. Эти команды:  Неукоснительно содержат все модели угроз в актуальном состоянии  Активно и полностью протестировали модель угроз посредством тестирования на проникновение  Тщательно проконтролировали и задокументировали поверхности атаки и любые изменения, внесенные в них в процессе разработки  Выполнили ревью кода на безопасность для всего высокоприоритетного кода  Идентифицировали и задокументировали контакты в разработке и тестировании для всего кода продукта  Придерживались строгих стандартов кодирования  Неукоснительно привели весь ранний код проекта в соответствие с текущим стандартом безопасности  Утвердили план по документации по безопасности 9. Security Push. Are We Done Yet? SSDL Митап, Москва 46 25 ноября 2016
47. SSDL для руководителей PDUG Отвечаем на вопрос: можно ли поставлять? Отдельная команда для выполнения FSR Product team coordination (Quiz) TM review Unfixed security bugs review Ошибки при заполнении багов Уложиться в неделю (выделить ресурсы на ревью) Делать, даже если много багов Tools use validation Handling exceptions Чеклисты 10. Final Security Review (FSR) SSDL Митап, Москва 47 Важно: эта фаза не используется как точка для завершения всех задач, пропущенных на предыдущих стадиях 25 ноября 2016
48. SSDL для руководителей PDUG Примеры вопросов (многие ответы есть давно):  Это отдельный продукт или service / management / feature / add-on pack?  Есть ли торчащие в Сеть (network-facing) части продукта?  Когда был Security Push и сколько он длился?  Где задокументирована поверхность атаки?  Где лежат модели угроз?  Где лежит код?  Где задокументирован bug bar (наши критерии оценки багов)?  Где список (лучше запрос) не исправленных багов по безопасности?  Security team уже проверяла модели угроз? Если да, кто проверял и что получилось на выходе?  Есть ли какие-либо SDL-требования, которые не соблюдаются? Если да, то какие и почему?  Отрабатывают ли все инструменты анализа и когда был последний прогон с их использованием? 10. FSR. Product team coordination SSDL Митап, Москва 48 25 ноября 2016
49. SSDL для руководителей PDUG Как выполнить эффективно? В дополнение к полям в трекере из Prj Inception надо добавить еще одно SecAudit такими значениями: Untriaged Not a security concern Defense in depth Low severity Medium severity Important severity Critical severity Затем все unfixed security bugs (где Security/Privacy Bug Effect < > Not a Security Bug) проставить SecAudit = Untriaged По мере обработки заполнять SecAudit значениями выше 10. FSR. Unfixed Security Bugs Review SSDL Митап, Москва 49 25 ноября 2016
50. SSDL для руководителей PDUG Нужно проверить продукт на соответствие требованиям SDL и отсутствие известных уязвимостей. В итоге получаем независимое заключение о готовности продукта к выпуску FSR не является:  Тестом на проникновение. Запрещено ломать и обновлять продукт  Первой проверкой безопасности продукта  Процессом финальной подписи продукта и отправки его в тираж FSR должен обязательно включать три возможных результата окончательной проверки безопасности:  Можно выпускать  Можно выпускать с ограничениями (и есть план)  FSR с эскалацией (на руководство компании) 10. Final Security Review (FSR). Takeaways SSDL Митап, Москва, Белые Сады 50 Важно: эта фаза не используется как точка для завершения всех задач, пропущенных на предыдущих стадиях 25 ноября 2016
51. SSDL для руководителей PDUG В следующий раз 11. Security Response Planning SSDL Митап, Москва 51 25 ноября 2016
52. SSDL для руководителей PDUG  План реагирования на инциденты безопасности создан  Документация для клиентов обновлена Создан централизованный архив всего, что поможет:  С сервисным обслуживанием релиза  Со снижением стоимости поддержки в долгосрочной перспективе Обязательно включить в архив:  Исходники  Приватные отладочные символы  Модели угроз  Документацию (техническую и пользовательскую)  Планы реагирования  Лицензионные и прочие servicing terms для используемого стороннего ПО 12. Release. Sign off & помещение в архив SSDL Митап, Москва 52 25 ноября 2016
53. SSDL для руководителей PDUG 12. Release. Ключ на старт. Поехали! SSDL Митап, Москва 53 25 ноября 2016
54. SSDL для руководителей PDUG Инцидент случился? Идем по заранее созданному плану:  Выполняем активности по плану реагирования на инциденты безопасности  Выпускаем обновления в соответствии с графиком релизов  Пересчитываем риски  Информируем клиентов  Публикуем информацию Выгоды планового реагирования  Понятно, что происходит  Есть ответственные  Удовлетворенность клиента растет  Собираем данные для будущих разработок  Проводим тренинги 13. Security Response Execute SSDL Митап, Москва 54 Не если, а когда! 25 ноября 2016
55. 25.09.2017 SSDL Митап, Москва, Белые Сады 55 III. «На посошок» 1.Подведем итог. Выводы 2. Что почитать? Полезные ссылки 3. Вопросы и ответы
56. SSDL для руководителей PDUG Более защищенная и надежная разработка, которая:  Увеличивает ROI и качество вашего продукта / сервиса  Снижает риски (в т. ч. «завалить» проект, получить качество продукта ниже ожиданий, превысить бюджет, сроки, а также иные риски, связанные с интеллектуальной собственностью)  Минимизирует возможный ущерб и стоимость инцидентов  Снижает стоимость разработки, поддержки и общую стоимость владения  Помогает соответствовать требованиям (compliance)  Повышает уровень удовлетворенности у заказчика и команды  Повышает продуктивность  Уменьшает сроки Выгоды SDL / SSDL для руководителей SSDL Митап, Москва 56 25 ноября 2016
57. SSDL для руководителей PDUG 1. Меньше времени на переделку и отладку 2. Меньше времени на тестирование 3. Меньше времени на поддержку и проще развитие 4. Отлов проблем на самых ранних стадиях 5. Избегаем повторяющихся инцидентов безопасности 6. Избегаем несогласованных уровней безопасности 7. Расширяем экспертизу и опыт в безопасности 8. Выше продуктивность, чаще укладываемся в сроки Выгоды SDL / SSDL для разработчиков SSDL Митап, Москва 57  Качественный код  Больше времени на работу и развитие  Проактивность 25 ноября 2016
58. SSDL для руководителей PDUG  Ликбезы по SSDL со Стачки  Building Security In (обязательно к прочтению)  Дао безопасности от Геннадия Махметова  SDL by Microsoft все про SDL от MSFT  Книга по SDL от Ховарда и Липнера Упрощенный SDL на русском (и оригинал)  SDL Best Practices for Developers, BUILD 2014 (видео)  Alexey Sintsov. SDLC: Implement me or Die (SDL + DevOps)  Алексей Бабенко. Цикл безопасной разработки SDL  Andrey Beshkov on SDL & ALM (1, 2)  Nazar Tymoshyk on SDL & Agile (1, 2, 3) Что почитать 1 / 2 SSDL Митап, Москва, Белые Сады 58 25 ноября 2016
59. SSDL для руководителей PDUG Безопасное программирование http://cwe.mitre.org http://owasp.org Общие базы данных уязвимостей http://www.securityfocus.com http://nvd.nist.gov http://secunia.com Информация по внешнему обучению http://www.sans.org/security-training.php Материалы для организации внутреннего обучения OWASP Code Review Project OWASP Top 10 Project http://www.sans.org/top25-software-errors http://www.cert.org/secure-coding Что почитать 2 / 2 SSDL Митап, Москва 59 25 ноября 2016
60. SSDL для руководителей PDUG 1. Application Threat Modeling на сайте OWASP 2. Статья с описанием подхода на Хабре (Владимир Кочетков, PT) 3. Обнаружение недостатков безопасности при помощи STRIDE (MSDN Magazine) 4. The STRIDE Threat Model на сайте Microsoft 5. Microsoft Threat Modeling Tool 2016 Моделирование угроз. Ссылки 25.09.2017 SSDL Митап, Москва 60
61. Спасибо!