SDL/SSDL для руководителей

SDL/SSDL для руководителей

• 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 для руководителей. Демо, дискуссия SSDL Митап, Москва, Белые Сады 2 Программа PDUG Meetup 25 ноября 2016
• 3.
  SSDL для руководителейPDUG Валерий Боронин В разработке и R&D более 20 лет В безопасности с прошлого тысячелетия ;-) Работал CTO небольшой компании (30+ человек) Директором по исследованиям большой (Лаборатория Касперского, 2500+ человек, 2009-2014) Сейчас отвечаю за направление безопасной разработки (SDL / SSDL) в Позитиве. Мы с командой создаем новый продукт по автоматизации безопасной разработки. О докладчике SSDL-митап, Москва 325 ноября 2016
• 4.
  SSDL для руководителейPDUG Мы НЕ обсуждаем важна ли безопасность Мы НЕ доказываем приоритет безопасности над расписанием и остальными вещами Мы НЕ обсуждаем нужна ли безопасная разработка, SDL SSDL Мы обсуждаем что нужно знать и что делать руководителям Мы обсуждаем что конкретно и почему предлагается делать на каждой стадии Мы обсуждаем выгоды и затраты риски от изменений Мы делимся опытом т.к. успешных управленческих решений может быть больше, чем одно Presuppositions SSDL Митап, Москва, Белые Сады 425 ноября 2016
• 5.
  30.11.2016 SSDL Митап,Москва, Белые Сады 5 1.Что надо знать руководителям? 2.Подготовить к последствиям перехода на SDL 3.Что должны делать первые лица / руководители I. SDL для руководителей.
• 6.
  SSDL для руководителейPDUG Планирование Организация Мотивация Контроль Координация Связаны процессами принятия решения коммуникации Разогрев – базовый управленческий цикл SSDL Митап, Москва, Белые Сады 625 ноября 2016
• 7.
  SSDL для руководителейPDUG Планирование - Где мы, Куда идем, Как; Общая цель и критерииметрики Организация – Что, Кто, Когда • Формализация структуры • Обеспечение всем необходимым • Создание условий для перестройки Мотивация Контроль - процесс обеспечения достижения результата • Установление стандартов – точная цель в опр время (см планирование) • Измерение и план факт – знаем проблему и источник • Коррекция серьезных отклонений Координация • Достиж. соглас. работы всех звеньев путем установления рац. связей • Отчеты, собрания, интервью, skype, …, документы • Дает взаимное маневрирование ресурсами, единство и согласованность всех ф-й процесса управления и руководителей Разогрев – базовый управленческий цикл SSDL Митап, Москва, Белые Сады 7 Инфа откуда ? Отсюда 25 ноября 2016
• 8.
  SSDL для руководителейPDUG Что надо знать про SDL руководителям? Подготовить к последствиям в SDLC при переходе на SDL Ресурсы Влияние на расписание, бюджет Как убедиться что мы соответствуем требованиям SDL Что должны делать первые лица / руководители, чтобы обеспечить, что их люди делают более защищённое ПО. SDL для руководителей SSDL Митап, Москва, Белые Сады 8 SDL не бесплатен – нужны время, бюджет, твердое обязательство руководства гарантировать приоритет безопасности (strong execs commitment to prioritize security over everything else) 25 ноября 2016
• 9.
  SSDL для руководителейPDUG Заказчики жалуются на частоту и стоимость залатывания дыр в безопасности Современные атаки оказывают влияние на IT заказчиков до такой степени, что становятся заметны и внутренним и внешним пользователям, SLA СМИ настолько фокусируются на проблемах безопасности, что те затмевают все продуктовые улучшения Необходимость частых исправлений и выпуска патчей, фиксов и прочая работа «по хвостам» - мешает создавать новые фичи и код Хотя цена патчей и невысока в абсолютных цифрах, частое отвлечение разработчиков на заплатки делает расписание менее предсказуемым Почему нужно подойти системно? SSDL Митап, Москва, Белые Сады 925 ноября 2016
• 10.
  SSDL для руководителейPDUG Выступайте с заявлением Email первого лица Kickoffs by VPs (for SDL, security push, FSR, etc) Непоколебимая вера – изменения важны. И почему. Effective Commitment - Make a statement SSDL Митап, Москва, Белые Сады 10 Полезно: используйте в сообщениях 3 составляющие – индивидуальный, групповой, глобальный уровни. 25 ноября 2016
• 11.
  SSDL для руководителейPDUG 3R - Reminders, Recognition & Rewards Периодические встречи для напоминания того, что выше Поиск и награждение передовиков, подтягивание отстающих Все это внедрять в культуру организации Задача руководителя: организовать и поддерживать – проста, используйте этапы SDL, на каждом будет масса возможностей Что делать: убедиться донести что ожидаете, на что смотрите, поощрять поведение на благо SDL Цель: сделать процесс самодостаточным, самовоспроизводящимся Effective Commitment - Be Visible SSDL Митап, Москва, Белые Сады 11 Безопасность – дело каждого! 25 ноября 2016
• 12.
  SSDL для руководителейPDUG Предоставляйте ресурсы Upfront costs – development budgets & tools budgets (если правильно применяете) Выбор платить или нет – за Вами. Но в безопасности вы получаете то, за что платите. Windows Server 2003: 2 дня –> в 8 недель Effective Commitment - Provide Resources SSDL Митап, Москва, Белые Сады 12 В SDL важно все, что не нужно – убрать. 25 ноября 2016
• 13.
  SSDL для руководителейPDUG Почему может быть нужно тормознуть выпуск? Находим слишком много – темп важен Feature не просто небезопасна, а не может стать таковой Новые угрозы Final Security Review (FSR) провален для продукта или компонента Effective Commitment - Stop Products SSDL Митап, Москва, Белые Сады 1325 ноября 2016
• 14.
  SSDL для руководителейPDUG Rules of thumb Massive legacy дает плюс 20% C нуля или 2+ итерация SDL получаем экономию от 20% Воздействие Заказчики Репутация Потерянные продажи Главное: понимание осознанная вера, что цена “не имения SDL” сильно больше затрат на SDL Managing the SDL - Resources SSDL Митап, Москва, Белые Сады 14 Формулы нет. 25 ноября 2016
• 15.
  SSDL для руководителейPDUG Новые проекты выгодно Большие legacy проекты дорого Первая итерация собирает все и вклад идет по $, времени, schedule Вторая и более итерации - хорошо. Не даем «бардак разводить» Managed > Unmanaged Удалить нельзя лечить (Remove, Disable by default, etc) Tools most effective & efficient только вместе с людьми Products / Components «с историей», где все время косяки, т.к. by design не правят – ибо дорого, некогда и т.п. Но терпеть – дороже! Тренинги! Снижают общую стоимость безопасности. Эффективная программа мотивирует на создание более качественного и защищенного кода, меньше багов, меньше… работы по хвостам Secure designs снижают очень сильно последствия в виде багов и severity оставшихся уязвимостей, а также TCO Ваш опыт вариант? Managing the SDL – Impacts on Costs SSDL Митап, Москва, Белые Сады 15 Изучай в offline 25 ноября 2016
• 16.
  SSDL для руководителейPDUG Отслеживать посещение тренингов для своих команд • Использовать оценки тестов и очки, если собираются Отслеживать создание моделей угроз и качества со старта • Есть смысл в создании спецбригады для TM review – актуальность + опыт сноровка закалка тренировка + отлов проблем как можно раньше Мониторить темп появления и типы уязвимостей по стадиям • Уменьшается ли к концу проекта число реальныхпотенц. уязвимостей? • Есть ли классы (по типу, по компонентам), где не снижается? Отслеживать воздействие найденных снаружи уязвимостей • Старые версии • Конкуренты Watch the Numbers & Trends • Постоянно узнавать учить что все это значит с позиций SDL Managing the SDL – Control SSDL Митап, Москва, Белые Сады 1625 ноября 2016
• 17.
  SSDL для руководителейPDUG Без поддержки сверху – не взлетит Оценки точные по стоимостивыгодам никто не дает Несмотря на отсутствие исчерпывающего рук-ва, которое бы гарантировало успешность перехода на SSDL, работают следующие простые вещи: • Отслеживание deliverables и активностей SDL постадийно – и тут уже все можно четко посчитать, причем под себя • Отслеживание external measures, таких как удовлетворенность заказчика в плане безопасности • Отслеживание темпов появления отработки инцидентов безопасности Managing the SDL – Summary SSDL Митап, Москва, Белые Сады 17 Software security скорее про страховку, чем про фичи функциональность. 25 ноября 2016
• 18.
  SSDL для руководителейPDUG Не надо Слишком полагаться на тестирование на поздних этапах цикла Управлять без измерений Обучать, не оценив Начинать без достаточной поддержки руководства Политические риски Бюджетные риски Стандартные для дисциплины Управление Изменениями (организационными, в частности) – у нас максимум сложности: люди, процессы, технологии «Стандартные» затыки – на заметку SSDL Митап, Москва, Белые Сады 18 Обучение, ответственность и ясные цели – ключевые компоненты успеха любой программы по безопасности. 25 ноября 2016
• 19.
  SSDL для руководителейPDUG Стандартные отговорки: Сроки горят (время) Нет ресурсов (бюджета, экспертизы, инструментов, …) на обеспечение безопасных практик Мы стартап – нам нужно быстрее стать популярными и заработать много денег … Разработчики и Безопасность SSDL Митап, Москва, Белые Сады 19 Shortage of skill or shortage of discipline? Знать мало – надо применять! 25 ноября 2016
• 20.
  30.11.2016 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 одним взглядом – 20 и 10 лет назад SSDL Митап, Москва, Белые Сады 21 SDLC Training Reqs Design Impl Verification Release Response 25 ноября 2016
• 22.
  SSDL для руководителейPDUG Постоянное обучение Способы доставки тренингов Упражнения и Лабы (30 мин) Измерение Знаний Обследовать подготовленность организации по темам безопасности и защиты данных (privacy) При необходимости создать стандартные курсы обучения • Basics minimum baseline • Raise User Awareness Кто: Все задействованные сотрудники в технических ролях (Devs, QA, PMs) Как часто: 1+ раз в год Что: Знания для выполнения остальных фаз + как работаем по новому процессу 0. Education SSDL Митап, Москва, Белые Сады 22 Безопасность – дело каждого! 25 ноября 2016
• 23.
  SSDL для руководителейPDUG Как организации сделать новый класс самостоятельно Определить цели и ЦА для класса. Эксперт по безопасности делает новый класс – рабочую программу. Другие технические эксперты смотрят материалы на предмет технической точности и применимости. Эксперты по тренингам (не безопасники) и редакторы вычитывают и улучшают как согласованность, так и типографические ошибки. Проводим первый класс. Главная цель – понять тайминг и получчить обратную связь по поводу содержимого контента. Обновляем материалы с учетом поступившей новой информации. Повторяем класс ежемесячно минимум 6 мес . Через 6 мес класс записывается и выкладывается в интранет. 0. Education – создаем свой курс обучения SSDL Митап, Москва, Белые Сады 23 Хозяйке на заметку: для максимально бюджетных вариантов всегда есть PowerPoint Record Narration. 25 ноября 2016
• 24.
  SSDL для руководителейPDUG Key Success Factors & Metrics • Поддержка первых лиц • Опытные спикеры • Постоянное обучение Измерение – чревато • Как использовать будем? Приобретение – легко, удержание – не очень ;-) SDL-compliant – 100% посещаемость • Все должны посетить • База с отметками • Идеи про CPE Сertification Points Earned: Был на конференции по ИБ (1 CPE за час посещения) Был на презентации ИБ вендора (1 CPE за час посещения) Провел тренинг по ИБ (4 CPEs за каждый час проведения) Залудил статью по ИБ (10 CPEs) Выпустил книгу по ИБ (40 CPEs) Прочел книгу по ИБ (5 CPEs) 0. Education – KPI & Metrics SSDL Митап, Москва, Белые Сады 2425 ноября 2016
• 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 0. Education – Чему учить - 2016 vs 2006 SSDL Митап, Москва, Белые Сады 25 Изучай в offline 25 ноября 2016
• 26.
  SSDL для руководителейPDUG Проверить применимость • Продукт или SP Назначить Security Advisor • Project & Process Mgmt Skills • Share for line of products Задачи: • Точка контакта Dev<->Sec Team • Reply Cc on security Q • Kickoffs for Dev team • Goals of SDL • Key Process Points – design & TM review • Встроить в расписание SDL активности 1. 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 1. Project Inception – Adviser at Work SSDL Митап, Москва, Белые Сады 2725 ноября 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 1. 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 2. 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: Is This Feature Really That Important? Шаг 2: Кому нужен какой доступ к чему и откуда? Шаг 3: Режем привилегии • Services and Low Privilege • UDP vs. TCP • Weak Permissions vs. Strong Permissions • .NET Code vs. ActiveX Code • … 2. Define & Follow Best Practices – ASR SSDL Митап, Москва, Белые Сады 30 Проще говоря, делаем так: Ограничиваем количество кода, доступного по умолчанию Ограничиваем в плане откуда можно добраться до кода Ограничиваем в плане кто может добраться до кода Уменьшаем привилегии кода 25 ноября 2016
• 31.
  SSDL для руководителейPDUG Уточнить уровень поддержки SDL активностей (effort) • Что требуется покрыть моделями • Что требует design review • Что требует penetration tests • Что требует динамического анализа фаззинга Security Risk Assessment Quiz Privacy Impact Rating • Анонимные данные • PII • Sensitive данные Найти компоненты с наибольшим риском Поработать с каждым Поможет с оценками! 3. Product Risk Assessment SSDL Митап, Москва, Белые Сады 31 Нет выгод от обладания PII & Sensitive данных – удали 25 ноября 2016
• 32.
  SSDL для руководителейPDUG Преимущества от моделей угроз Модели угроз (Артефакты) Что моделировать? Строим модель (Подготовить -> Проанализировать -> Меры) Процесс Поможет code review & testing Ключевые факторы успеха и метрики 4. Risk Analysis SSDL Митап, Москва, Белые Сады 3225 ноября 2016
• 33.
  SSDL для руководителейPDUG Преимущества от моделей угроз по мнению Microsoft Дает вклад в процесс управления рисками потому что угрозы ПО и инфраструктуре есть риски для пользователей и окружения, в котором развертывается ПО. Вскрывает угрозы системе до того как система реализуется в коде . Перепроверка архитектуры и дизайна потому что команда разработки проходит через редизайн снова и снова. Заставляет разработчиков смотреть на дизайн с разных точек зрения – а именно безопасности и защиты данных. Понимая наиболее подвергающиеся риску компоненты, разработчики фокусируются на компонентах с наибольшими шансами быть атакованными. Помогает уточнить выбор целесообразных мер для ПО и окружения. Дает вклад в процесс уменьшения поверхности атаки. Помогает с code review. Направляет penetration testing. 4. Risk Analysis – TM - Преимущества SSDL Митап, Москва, Белые Сады 33 Изучай в offline 25 ноября 2016
• 34.
  SSDL для руководителейPDUG Высокоуровневая модель приложения Диаграммы типа DFD Список добра (assets), требующего защиты Угрозы системе отранжированные по рискам Список компенсирующих мер (опционально) Плюс вспомогательная информация: Use scenarios Конфигурации развертывания, как обычно пользуются External dependencies Продукты, компоненты, сервисы, от которых зависим Security assumptions На что можем рассчитывать в плане безопасности в сторонних компонентах External security notes Полезная информация админам или пользователями, чтобы работать более защищенно 4. Risk Analysis – TM - Artifacts SSDL Митап, Москва, Белые Сады 3425 ноября 2016
• 35.
  SSDL для руководителейPDUG 1. Определи сценарии использования 2. Собери внешние зависимости – системные требования 3. Определи предположения касательно безопасности 4. Сделай external security notes – какие порты открыты зачем 5. Сделай одну или больше DFDку моделируемого приложения 6. Определи типы угроз – STRIDE и т.п. 7. Идентифицируй угрозы системе – процессы, хранилища данных, потоки данных, внешние сущности 8. Определи риски – полезны деревья ранжирования рисков для каждой угрозы из STRIDE 9. Спланируй компенсирующие меры – Ничего не делать, Удалить, Отключить, Предупредить пользователя, компенсировать с помощью техники (широко) или технологии (конкретно) 4. Risk Analysis – the TM process SSDL Митап, Москва, Белые Сады 35 Изучай в offline 25 ноября 2016
• 36.
  SSDL для руководителейPDUG Порнография и Модели Угроз – Что общего? 4. Risk Analysis – TM – KPIs & Metrics SSDL Митап, Москва, Белые Сады 3625 ноября 2016
• 37.
  SSDL для руководителейPDUG Ключевые факторы успеха и метрики Порнография и Модели Угроз 4. 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) - Модель явно неактуальна, если: • Текущий дизайн существенно отличается от описанного в модели угроз. • Дата в документе показывает, что он старше 12 месяцев. 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 • Модель актуальна. 4. Risk Analysis – TM – Quality Guidelines-12 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) которые объясняют, как использовать эту технологию безопасно и какие компромиссы. 4. Risk Analysis – TM – Quality Guidelines-22 SSDL Митап, Москва, Белые Сады 39 Изучай в offline 25 ноября 2016
• 40.
  SSDL для руководителейPDUG Setup Docs User Guide Help Docs Dev Docs Creating Tools (Lockdown Tool) Security implications • В зависимости от действий • От конфигураций • Как заморозить конфигурацию • Как upgrade делать • Как поверх вместо конкурента Install / Maintain / Use 5. Creating Tools Docs Best Practices SSDL Митап, Москва, Белые Сады 4025 ноября 2016
• 41.
  SSDL для руководителейPDUG Latest tools & secure options Помощь компилятора SAST • Tools to find at least • Enforce & disciplined usage • Code check-in • Материал для Review Не используем banned API Уменьшить потенциально эксплуатируемые конструкты уровня кода и дизайна Use a secure code checklist • Check-in policies 6. Secure Coding Policies SSDL Митап, Москва, Белые Сады 41 Знать мало – надо применять! 25 ноября 2016
• 42.
  SSDL для руководителейPDUG DASD / 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 7. 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 Изучай Client code Bug Bar в offline 25 ноября 2016
• 44.
  SSDL для руководителейPDUG Example: Fixing Bugs Found Through Fuzz Testing Server Code Bug Bar 7. Secure Testing Policies SSDL Митап, Москва, Белые Сады 44 Изучай в offline 25 ноября 2016
• 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 8. Security Push SSDL Митап, Москва, Белые Сады 4525 ноября 2016
• 46.
  SSDL для руководителейPDUG Команды, которые выполнили следующие задачи будут иметь более короткий security push: Неукоснительно содержат все модели угроз в актуальном состоянии Активно и полностью протестировали модель угроз посредством тестирования на проникновения Тщательно проконтролировали и задокументировали поверхности атаки и любые изменения, внесенные в них в процессе разработки Выполнили ревью кода на безопасность для всего высокоприоритетного кода Идентифицировали и задокументировали контакты в разработке и тестировании для всего кода продукта Придерживались строгих стандартов кодирования Неукоснительно привели весь ранний код проекта в соответствие текущим стандартам безопасности Утвердили план по документации по безопасности 8. Security Push – Are We Done Yet? SSDL Митап, Москва, Белые Сады 4625 ноября 2016
• 47.
  SSDL для руководителейPDUG Можно ли поставлять? Отдельная команда для выполнения FSR • Product team coordination (Quiz) • TM review • Unfixed security bugs review • Ошибки при заполнении багов • Уложиться в неделю (выделить ресурсы на ревью) • Даже если много багов – делать! • Tools use validation Handling exceptions Чеклисты 9. Final Security Review (FSR) SSDL Митап, Москва, Белые Сады 47 Ключевая концепция: Эта фаза не используется как точка для завершения всех задач пропущенных на предыдущих стадиях 25 ноября 2016
• 48.
  SSDL для руководителейPDUG Примеры вопросов—многие ответы есть давно: Это отдельный продукт или service/mgmt/feature/add-on pack? Есть ли торчащие в Сеть (network-facing) части продукта? Когда был security push с сколько длился? Где задокументирована поверхность атаки? Где лежат модели угроз? Где лежит код? Где задокументирован bug bar (наши критерии оценки багов)? Где список (лучше запрос) непоправленных багов по безопасности? security team уже проверяла модели угроз? Если да, кто проверял и что на выходе? Есть ли какие-либо SDL requirements которые не соблюдаются? Если да, то какие и почему? Отрабатывают ли все инструменты анализа и когда был последний прогон ими? 9. FSR – Product team coordination SSDL Митап, Москва, Белые Сады 48 Изучай в offline 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 значениями выше 9. FSR – Unfixed Security Bugs Review SSDL Митап, Москва, Белые Сады 4925 ноября 2016
• 50.
  SSDL для руководителейPDUG Проверить продукт на соответствие требованиям SDL и отсутствие известных уязвимостей. Получаем независимое заключение готовности продукта к выпуску. FSR не является: Тестом на проникновение. Запрещено ломать и обновлять продукт. Первой проверкой безопасности продукта Процессом финальной подписи продукта и отправки его в тираж FSR должен обязательно включать три возможных результата окончательной проверки безопасности: 1. можно выпускать 2. можно выпускать с ограничениями (и есть план по их душу) 3. FSR с эскалацией (на руководство Компании) 9. Final Security Review (FSR) - takeaways SSDL Митап, Москва, Белые Сады 50 Ключевая концепция: Эта фаза не используется как точка для завершения всех задач пропущенных на предыдущих стадиях 25 ноября 2016
• 51.
  SSDL для руководителейPDUG В следующий раз! Next PDUG Appearance? 10. Security Response Planning SSDL Митап, Москва, Белые Сады 5125 ноября 2016
• 52.
  SSDL для руководителейPDUG План реагирования на инциденты безопасности создан Документация для клиентов обновлена Создан централизованный архив всего, что поможет с сервисным обслуживанием релиза снизить стоимость поддержки в долгосрочной перспективе Обязательно включить в архив Исходники Приватные отладочные символы Модели угроз Документацию – техническую и пользовательскую Планы реагирования Лицензионные и прочие servicing terms для используемого стороннего ПО 11. Release –sign off & поместить в Архив SSDL Митап, Москва, Белые Сады 5225 ноября 2016 Информация
• 53.
  SSDL для руководителейPDUG 11. Release – Ключ на старт! Поехали! SSDL Митап, Москва, Белые Сады 5325 ноября 2016
• 54.
  SSDL для руководителейPDUG Инцидент случился? Идем по заранее созданному плану. Выполняем активности по плану реагирования на инциденты безопасности выпускаем обновления в соответствии с графиком релизов Пересчитываем риски Информируем клиентов Публикуем информацию Выгоды планового реагирования Понятно что происходит Есть ответственные Удовлетворенность клиента растет Собираем данные для будущих разработок Проводим тренинги 12. Security Response Execute SSDL Митап, Москва, Белые Сады 54 Не если, а когда! 25 ноября 2016
• 55.
  30.11.2016 SSDL Митап,Москва, Белые Сады 55 III. Напосошок 1.Подведем итог. Выводы. 2. Что почитать и полезные ссылки 3. Вопросы и ответы. Дискуссия.
• 56.
  SSDL для руководителейPDUG Более защищенная, безопасная и надежная разработка, которая 1. Увеличивает ROI и качество ВАШЕГО продуктасервиса 2. Снижает риски (в т.ч. «завалить» проект, получить качество продукта ниже ожиданий, превысить бюджет, сроки, а также связанные с Интеллектуальной Собственностью) 3. Минимизирует возможный ущерб и стоимость инцидентов 4. Снижает стоимость разработки, поддержки и общую стоимость владения 5. Помогает соответствовать требованиям (compliance) 6. Повышает уровень удовлетворенности у Заказчика и Команды 7. Повышает продуктивность 8. Уменьшает сроки график расписание Выгоды SDL / SSDL для руководителей SSDL Митап, Москва, Белые Сады 5625 ноября 2016
• 57.
  SSDL для руководителейPDUG 1. Меньше времени на переделывание и отладку 2. Меньше времени на тестирование 3. Меньше времени на поддержку и проще развитие 4. Отлов проблем как можно раньше 5. Избегаем повторяющихся security issues 6. Избегаем несогласованных уровней безопасности 7. Повышаем экспертизу и опыт в безопасности 8. Выше продуктивность + чаще укладываемся в сроки Выгоды SDL / SSDL для разработчиков SSDL Митап, Москва, Белые Сады 57 1. Качественный код 2. Больше времени на работу и развитие 3. Проактивность 25 ноября 2016
• 58.
  SSDL для руководителейPDUG Ликбезы по SSDL со Стачки Valery on SSDL, video, PDUG, Aug’16 Building Security In – must read Дао безопасности от Геннадия Махметова SDL by Microsoft все про SDL от MSFT Книга по SDL от Ховарда и Липнера (главный за SDL в Microsoft) Упрощенный SDL на русском (и оригинал) SDL Best Practices for Developers, BUILD 2014 (45 min video) 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 Митап, Москва, Белые Сады 5825 ноября 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 Митап, Москва, Белые Сады 5925 ноября 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 Моделирование угроз – Ссылки 30.11.2016 SSDL Митап, Москва, Белые Сады 60
• 61.
  Спасибо! - Вопросы, Идеи,Уточнения - А давайте попробуем <> ?! - Поработаем вместе?
• 62.
  SSDL для руководителейPDUG Ищем SDL/SSDL сообщество – тех, кому интересна “жизнь по SSDL” Кто готов делиться опытом – уже живет или в процессе перехода на SDL разработчиков на С#, QA, фронтендеров, аналитиков в Новосибирск bit.ly/PT_Novosibirsk_job …и другие города тоже http://www.ptsecurity.com/ru- ru/about/vacancy Минутка Рекламы SSDL Митап, Москва, Белые Сады 6225 ноября 2016