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

Безопасная
разработка
для руководителей
Валерий Боронин
Руководитель отдела решений
по построению процесса
безопасной разработки
Positive Technologies
Москва, 25 ноября 2016

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

 Валерий Боронин
 В разработке и R&D более 20 лет
 В безопасности с прошлого тысячелетия ;-)
 Работал CTO небольшой компании
(30+ человек)
 А также директором по исследованиям
(Лаборатория Касперского,
2500+ человек, 2009-2014)
 Сейчас отвечаю за направление безопасной
разработки (SDL / SSDL) в Позитиве
 Мы с командой создаем новый продукт
для автоматизации безопасной разработки
О докладчике
SSDL-митап, Москва 325 ноября 2016

Мы не обсуждаем:
 Важна ли безопасность
 Каков приоритет безопасности над расписанием
и остальными вещами
 Нужна ли безопасная разработка (SDL / SSDL)
Мы обсуждаем:
 Что нужно знать и что делать руководителям
 Что конкретно и почему предлагается делать на каждой стадии
 Каковы выгоды и затраты / риски от изменений
Мы делимся опытом, так как успешных управленческих
решений может быть больше, чем одно
Предпосылки
SSDL Митап, Москва 425 ноября 2016

01.12.2016 SSDL Митап, Москва, Белые Сады 5
1. Что надо знать руководителям?
2. Подготовка к последствиям перехода на SDL
3. Что должны делать первые лица / руководители?
I. SDL для руководителей

 Планирование
 Организация
 Мотивация
 Контроль
 Координация
Этапы связаны процессами
 Принятия решений
 Коммуникации
Разогрев. Базовый управленческий цикл

 Планирование: где мы, куда идем, как.
Общая цель и критерии / метрики
 Организация: что, кто, когда
 Формализация структуры
 Обеспечение всем необходимым
 Создание условий для перестройки
 Мотивация
 Контроль: процесс обеспечения достижения результата
 Установление стандартов – точная цель в определенное время
 Измерение и план / факт – знаем проблему и источник
 Коррекция серьезных отклонений
 Координация
 Достижение согласованной работы всех звеньев
путем установления рациональных связей
 Отчеты, собрания, интервью, Skype, документы
 Дает взаимное маневрирование ресурсами, единство
и согласованность всех функций процесса управления и руководителей
Разогрев. Базовый управленческий цикл
SSDL Митап, Москва 7
Информация отсюда
25 ноября 2016

Что надо знать про SDL руководителям?
Подготовка к последствиям в SDLC при переходе на SDL
Ресурсы
Влияние на расписание, бюджет
Как убедиться, что мы соответствуем требованиям SDL?
Что должны делать первые лица / руководители,
чтобы обеспечить разработку более защищенного ПО?
SDL для руководителей
SDL не бесплатен: нужны время, бюджет,
твердое обязательство руководства гарантировать
приоритет безопасности

Заказчики жалуются на частоту и стоимость «залатывания
дыр» в безопасности
Современные атаки оказывают влияние на IT заказчиков
до такой степени, что становятся заметны и внутренним,
и внешним пользователям, SLA
СМИ настолько фокусируются на проблемах безопасности,
что те затмевают все продуктовые улучшения
Необходимость частых исправлений и выпуска патчей,
фиксов и прочая работа «по хвостам» мешают создавать
новые фичи и код
Хотя цена патчей и невысока в абсолютных цифрах, частое
отвлечение разработчиков на заплатки делает расписание
менее предсказуемым
Почему нужно подойти системно?

E-mail первого лица
Обсуждение среди
руководителей
Непоколебимая вера
в то, что изменения важны
Выступайте с заявлением
Полезно: используйте в своих сообщениях три составляющих –
индивидуальный, групповой, глобальный уровни

3R: Reminders, Recognition & Rewards
 Периодические встречи для напоминания того, что выше
 Поиск и награждение передовиков, подтягивание отстающих
 Внедрение всего этого в культуру организации
Задача руководителя заключается в организации и поддержке.
Эта задача решается просто: используйте этапы SDL, на каждом
из них будет масса возможностей
 Что делать: убедиться / донести, чего вы ожидаете,
на что смотрите, поощрять инициативу во благо SDL
 Цель: сделать процесс самодостаточным, самовоспроизводящимся
Действуйте открыто
Безопасность – дело каждого!

Управляйте бюджетами
на разработку и превращайте
издержки в инвестиции
Платить или нет – выбор
за вами. В сфере безопасности
вы получаете то, за что платите
Windows Server 2003: 2 дня → в 8 недель
Выделяйте ресурсы
В SDL важно убрать все ненужное

Почему может быть нужно
приостановить выпуск?
Находим слишком много –
темп важен
Функция не просто
небезопасна, а не может
стать таковой
Возникли новые угрозы
Final Security Review (FSR)
провален для продукта
или компонента
Вовремя остановитесь

“Rules of thumb”
 Большие legacy проекты дают
плюс 20% к затратам
 C нуля или на 2+ итерации с SDL
получаем экономию от 20%
Воздействие
 Заказчики
 Репутация
 Потерянные продажи
Главное
 Необходимо понимать, что без
SDL дороже, чем с ним
Управление SDL. Ресурсы
Формулы нет

 Новые проекты становятся выгодными
 Поддерживать большие legacy проекты становится дорого
 Первая итерация собирает все и вклад идет по $, времени, плану
 Вторая и более итерации – хорошо. Не даем «бардак разводить»
 Managed > Unmanaged
 Удалить нельзя лечить
 Процессы и средства эффективны только вместе с людьми
 Продукты «с историей» и постоянными косяками обычно не правят:
дорого, некогда и т. п. Но терпеть – дороже
 Проводите тренинги. Они снижают общую стоимость безопасности.
Эффективная программа мотивирует на создание качественного и
защищенного кода. Меньше багов, меньше работы «по хвостам»
 Secure designs сильно снижают последствия в виде багов
и существенность оставшихся уязвимостей, а также TCO
 А каков ваш опыт / вариант?
Управление SDL. Влияние на издержки

 Отслеживайте посещение тренингов для своих команд
Используйте оценки тестов и очки, если они собираются
 Отслеживайте создание моделей угроз и качества со старта
Есть смысл в создании спецбригады для TM review.
Это актуальность + опыт / сноровка / закалка / тренировка + отлов
проблем на самых ранних стадиях
 Отслеживайте темп появления и типы уязвимостей по стадиям
Уменьшается ли к концу проекта число реальных / потенциальных
уязвимостей?
Есть ли классы (по типу, по компонентам), где уровень не снижается?
 Отслеживайте воздействие найденных снаружи уязвимостей
Старые версии
Конкуренты
 Следите за динамикой
Постоянно узнавайте / учите, что все это значит с точки зрения SDL
Управление SDL. Контроль

Без поддержки сверху проект не взлетит
Никто не даст точные оценки по стоимости и выгодам
Несмотря на отсутствие исчерпывающего руководства,
которое бы гарантировало успешность перехода на SDL,
работают следующие простые вещи:
Отслеживание deliverables и активностей SDL постадийно.
Так все можно четко посчитать, причем под себя
Отслеживание внешних метрик, таких как удовлетворенность
заказчика в плане безопасности
Отслеживание темпов появления и отработки инцидентов
безопасности
Управление SDL. Выводы
Безопасная разработка скорее про страховку,
чем про функциональность

Не надо:
 Слишком полагаться на тестирование на поздних этапах цикла
 Управлять без измерений
 Обучать, не оценив
 Начинать без достаточной поддержки руководства
 Политические риски
 Бюджетные риски
 Стандартные сложности управления изменениями
(организационными, в частности) – люди, процессы,
технологии – становятся максимально серьезными
Стандартные «затыки». На заметку
Обучение, ответственность и ясные цели – ключевые
компоненты успеха любой программы по безопасности

Стандартные отговорки:
Сроки горят (время)
Нет ресурсов (бюджета,
экспертизы, инструментов)
на обеспечение безопасных
практик
Мы стартап. Нам нужно
быстрее стать популярными
и заработать много денег
…
Разработчики и безопасность
Shortage of skill or shortage
of discipline?
Знать мало – надо
применять!

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

SDL одним взглядом
SDLC
Training Reqs Design Impl Verification Release Response

Постоянное обучение
Способы доставки тренингов
Практические упражнения
Измерение знаний
Нужно обследовать
подготовленность
организации в сфере
безопасности и защиты
данных (privacy)
При необходимости создать
стандартные курсы обучения
Базовый уровень
Повышение осведомленности
Кто: все задействованные
сотрудники с техническими
ролями (Devs, QA, PMs)
Как часто: 1+ раз в год
Что: знания для выполнения
остальных фаз + подход
к работе по новому процессу
1. Education
Безопасность – дело
каждого!

Как организации сделать новый курс самостоятельно?
 Нужно определить цели и целевую аудиторию для курса
 Эксперт по безопасности делает новый курс – рабочую программу
 Другие технические эксперты смотрят материалы на предмет
технической точности и применимости
 Эксперты по тренингам (не безопасники) и редакторы вычитывают
и улучшают структуру и содержание
 Проводится первый курс. Главная цель – понять тайминг и получить
обратную связь по поводу содержания
 Материалы обновляются с учетом поступившей информации
 Курс повторяется ежемесячно минимум полгода
 Через полгода курс записывается и выкладывается в интранет
1. Education. Создаем свой курс обучения
Для максимально бюджетных вариантов всегда есть
PowerPoint Record Narration

Ключевые показатели
эффективности
Поддержка первых лиц
Опытные спикеры
Постоянное обучение
Измерение – чревато
Как будем использовать?
Приобретение – легко
Удержание – не очень ;-)
SDL-compliant –
100% посещаемость
Все должны посещать
Нужно вести базу с отметками
Идеи про CPE
1. Education. KPI & Metrics
Сertification Points Earned
• Был на конференции по ИБ
(1 CPE за час посещения)
• Был на презентации ИБ-вендора
(1 CPE за час посещения)
• Провел тренинг по ИБ
(4 CPEs за каждый час проведения)
• Написал статью по ИБ (10 CPEs)
• Выпустил книгу по ИБ (40 CPEs)
• Прочел книгу по ИБ (5 CPEs)

 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
Изучай в offline

 Проверить применимость
Продукт или 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
активности
Назначайте снаружи

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

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
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

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?”
Сложность
и безопасность:
простота – залог
здоровья

Анализируем и снижаем
поверхность атаки
 Шаг 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
Проще говоря, делаем так:
 Ограничиваем количество кода,
доступного по умолчанию
 Ограничиваем в плане, откуда
можно добраться до кода
 Ограничиваем в плане, кто
может добраться до кода
 Уменьшаем привилегии кода

 Уточнить уровень поддержки SDL активностей
 Что требуется покрыть моделями
 Что требует дизайн ревью
 Что требует тестирования на проникновение
 Что требует динамического анализа / фаззинга
 Security Risk Assessment Quiz
 Privacy Impact Rating
 Анонимные данные
 PII
 Чувствительные данные
 Найти компоненты с наибольшим риском
 Поработать с каждым
Это поможет с оценками!
4. Product Risk Assessment
Если от обладания PII
и чувствительных данных нет
выгоды, нужно удалять

Преимущества от моделей угроз
Модели угроз (артефакты)
Что моделировать?
Строим модель
(подготовить → проанализировать → принять меры)
Процесс
Поможет code review & testing
Ключевые показатели эффективности и метрики
5. Risk Analysis

Преимущества от моделей угроз по мнению Microsoft
 Вносят вклад в процесс управления рисками, потому что угрозы ПО
и инфраструктуре – это риски для пользователей и окружения,
в котором развертывается ПО
 Вскрывают угрозы системе до того, как система реализуется в коде
 Позволяют перепроверить архитектуру и дизайн, потому что команда
разработки проходит через редизайн снова и снова
 Заставляют разработчиков смотреть на дизайн с разных точек зрения,
а именно: безопасности и защиты данных. Понимая, какие компоненты
больше всего подвергаются риску, разработчики фокусируются
на компонентах, которые наиболее вероятно подвергнутся атаке
 Помогают уточнить выбор целесообразных мер для ПО и окружения
 Вносят вклад в процесс уменьшения поверхности атаки
 Помогают с ревью кода
 Направляют тестирование на проникновение
5. Risk Analysis. TM. Преимущества

 Высокоуровневая модель приложения
 Диаграммы типа DFD
 Список того, что требует защиты
 Угрозы системе, ранжированные по рискам
 Список компенсирующих мер (опционально)
Плюс вспомогательная информация:
 Use scenarios (обычные конфигурации развертывания)
 External dependencies (продукты, компоненты, сервисы,
от которых есть зависимость)
 Security assumptions (на что можно рассчитывать в плане
безопасности сторонних компонентов)
 External security notes (полезная информация для администраторов
или пользователей, позволяющая работать более защищенно)
5. Risk Analysis. TM. Artifacts

1. Определите сценарии использования
2. Соберите внешние зависимости (системные требования)
3. Определите предположения касательно безопасности
4. Сделайте external security notes (какие порты открыты и зачем)
5. Сделайте одну или больше DFD моделируемого приложения
6. Определите типы угроз (STRIDE и т. п.)
7. Идентифицируйте угрозы системе (процессы, хранилища данных,
потоки данных, внешние сущности)
8. Определите риски (полезны деревья ранжирования рисков
для каждой угрозы из STRIDE)
9. Спланируйте компенсирующие меры (ничего не делать,
удалить, отключить, предупредить пользователя, компенсировать
с помощью техники (широко)
или технологии (конкретно)
5. Risk Analysis. The TM process

Порнография
и модели угроз –
что общего?
5. Risk Analysis. TM. KPIs & Metrics

Ключевые факторы
успеха и метрики
Порнография
и модели угроз
5. Risk Analysis. TM. KPIs & Metrics
“I shall not today attempt further
to define the kinds of material
[pornography]… but I know it
when I see it”
Potter Stewart

Как минимум, модели угроз должны быть
помечены “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

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

Setup Docs
User Guide
Help Docs
Dev Docs
Creating Tools
(Lockdown Tool)
Security implications
В зависимости от действий
От конфигураций
Как заморозить конфигурацию
Как делать upgrade
Как делать поверх / вместо конкурента
Install / Maintain / Use
6. Creating Tools Docs Best Practices

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
Знать мало – надо применять!

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
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.

7. Secure Testing Policies. Triage Bars for Fuzz

Example: Fixing Bugs Found Through Fuzz Testing
Server Code Bug Bar

 Когда делать? 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

Команды, которые выполнили следующие задачи, будут иметь более
короткий Security Push. Эти команды:
 Неукоснительно содержат все модели угроз в актуальном состоянии
 Активно и полностью протестировали модель угроз посредством
тестирования на проникновение
 Тщательно проконтролировали и задокументировали поверхности атаки
и любые изменения, внесенные в них в процессе разработки
 Выполнили ревью кода на безопасность для всего
высокоприоритетного кода
 Идентифицировали и задокументировали контакты в разработке
и тестировании для всего кода продукта
 Придерживались строгих стандартов кодирования
 Неукоснительно привели весь ранний код проекта в соответствие
с текущим стандартом безопасности
 Утвердили план по документации по безопасности
9. Security Push. Are We Done Yet?

Отвечаем на вопрос:
можно ли поставлять?
Отдельная команда
для выполнения FSR
Product team coordination (Quiz)
TM review
Unfixed security bugs review
Ошибки при заполнении багов
Уложиться в неделю (выделить
ресурсы на ревью)
Делать, даже если много багов
Tools use validation
Handling exceptions
Чеклисты
10. Final Security Review (FSR)
Важно: эта фаза
не используется как точка
для завершения всех задач,
пропущенных на предыдущих
стадиях

Примеры вопросов (многие ответы есть давно):
 Это отдельный продукт или service / management / feature / add-on pack?
 Есть ли торчащие в Сеть (network-facing) части продукта?
 Когда был Security Push и сколько он длился?
 Где задокументирована поверхность атаки?
 Где лежат модели угроз?
 Где лежит код?
 Где задокументирован bug bar (наши критерии оценки багов)?
 Где список (лучше запрос) не исправленных багов по безопасности?
 Security team уже проверяла модели угроз?
Если да, кто проверял и что получилось на выходе?
 Есть ли какие-либо SDL-требования, которые не соблюдаются?
Если да, то какие и почему?
 Отрабатывают ли все инструменты анализа и когда был последний
прогон с их использованием?
10. FSR. Product team coordination

Как выполнить эффективно?
В дополнение к полям в трекере из 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

Нужно проверить продукт на соответствие требованиям SDL
и отсутствие известных уязвимостей. В итоге получаем независимое
заключение о готовности продукта к выпуску
FSR не является:
 Тестом на проникновение. Запрещено ломать и обновлять продукт
 Первой проверкой безопасности продукта
 Процессом финальной подписи продукта и отправки его в тираж
FSR должен обязательно включать три возможных результата
окончательной проверки безопасности:
 Можно выпускать
 Можно выпускать с ограничениями (и есть план)
 FSR с эскалацией (на руководство компании)
10. Final Security Review (FSR). Takeaways
SSDL Митап, Москва, Белые Сады 50
Важно: эта фаза не используется как точка для завершения всех
задач, пропущенных на предыдущих стадиях

В следующий раз
11. Security Response Planning

 План реагирования на инциденты
безопасности создан
 Документация для клиентов
обновлена
Создан централизованный архив всего,
что поможет:
 С сервисным обслуживанием релиза
 Со снижением стоимости поддержки
в долгосрочной перспективе
Обязательно включить в архив:
 Исходники
 Приватные отладочные символы
 Модели угроз
 Документацию (техническую
и пользовательскую)
 Планы реагирования
 Лицензионные и прочие
servicing terms для используемого
стороннего ПО
12. Release. Sign off & помещение в архив

12. Release. Ключ на старт. Поехали!

Инцидент случился?
Идем по заранее созданному плану:
 Выполняем активности по плану
реагирования на инциденты
безопасности
 Выпускаем обновления
в соответствии с графиком релизов
 Пересчитываем риски
 Информируем клиентов
 Публикуем информацию
Выгоды планового реагирования
 Понятно, что происходит
 Есть ответственные
 Удовлетворенность клиента растет
 Собираем данные
для будущих разработок
 Проводим тренинги
13. Security Response Execute
Не если, а когда!

III. «На посошок»
1.Подведем итог. Выводы
2. Что почитать? Полезные ссылки
3. Вопросы и ответы

Более защищенная и надежная разработка, которая:
 Увеличивает ROI и качество вашего продукта / сервиса
 Снижает риски (в т. ч. «завалить» проект, получить качество
продукта ниже ожиданий, превысить бюджет, сроки, а также иные
риски, связанные с интеллектуальной собственностью)
 Минимизирует возможный ущерб и стоимость инцидентов
 Снижает стоимость разработки, поддержки и общую
стоимость владения
 Помогает соответствовать требованиям (compliance)
 Повышает уровень удовлетворенности у заказчика и команды
 Повышает продуктивность
 Уменьшает сроки
Выгоды SDL / SSDL для руководителей

1. Меньше времени на переделку и отладку
2. Меньше времени на тестирование
3. Меньше времени на поддержку и проще развитие
4. Отлов проблем на самых ранних стадиях
5. Избегаем повторяющихся инцидентов безопасности
6. Избегаем несогласованных уровней безопасности
7. Расширяем экспертизу и опыт в безопасности
8. Выше продуктивность, чаще укладываемся в сроки
Выгоды SDL / SSDL для разработчиков
 Качественный код
 Больше времени на работу и развитие
 Проактивность

 Ликбезы по 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 Митап, Москва, Белые Сады 5825 ноября 2016

Безопасное программирование
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

1. Application Threat Modeling на сайте OWASP
2. Статья с описанием подхода на Хабре (Владимир Кочетков, PT)
3. Обнаружение недостатков безопасности при помощи STRIDE
(MSDN Magazine)
4. The STRIDE Threat Model на сайте Microsoft
5. Microsoft Threat Modeling Tool 2016
Моделирование угроз. Ссылки
01.12.2016 SSDL Митап, Москва 60

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

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Andere mochten auch

Andere mochten auch (13)

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

Ähnlich wie Безопасная разработка для руководителей (20)

Mehr von Positive Development User Group

Mehr von Positive Development User Group (8)

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

Hinweis der Redaktion