sdl/ssdl для руководителей

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

Руководитель отдела решений по построению процесса безопасной

разработки

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 для руководителей. Демо, дискуссия

SSDL Митап, Москва, Белые Сады 2

Программа PDUG Meetup

25 ноября 2016


Валерий БоронинВ разработке и R&D более 20 летВ безопасности с прошлого тысячелетия ;-)

Работал CTO небольшой компании (30+ человек)Директором по исследованиям большой (Лаборатория Касперского, 2500+ человек, 2009-2014)

Сейчас отвечаю за направление безопасной разработки (SDL / SSDL) в Позитиве. Мы с командой создаем новый продукт по автоматизации безопасной разработки.

О докладчике

SSDL-митап, Москва 325 ноября 2016

http://www.linkedin.com/in/boronin

mailto:[email protected]?subject=%D0%A1%D1%82%D0%B0%D1%87%D0%BA%D0%B0%202016%20SSDL


Мы НЕ обсуждаем важна ли безопасностьМы НЕ доказываем приоритет безопасности над расписанием и остальными вещамиМы НЕ обсуждаем нужна ли безопасная разработка, SDL \ SSDL

Мы обсуждаем что нужно знать и что делать руководителямМы обсуждаем что конкретно и почему предлагается делать на каждой стадииМы обсуждаем выгоды и затраты \ риски от изменений

Мы делимся опытом т.к. успешных управленческих решений может быть больше, чем одно

Presuppositions

SSDL Митап, Москва, Белые Сады 425 ноября 2016

03.05.2023 SSDL Митап, Москва, Белые Сады 5

1.Что надо знать руководителям?

2.Подготовить к последствиям перехода на SDL

3.Что должны делать первые лица / руководители

I. SDL для руководителей.


ПланированиеОрганизацияМотивацияКонтрольКоординация

Связаны процессами

принятия решения коммуникации

Разогрев – базовый управленческий цикл



Планирование - Где мы, Куда идем, Как; Общая цель и критерии\метрики

Организация – Что, Кто, Когда• Формализация структуры• Обеспечение всем необходимым• Создание условий для перестройки

МотивацияКонтроль - процесс обеспечения достижения результата

• Установление стандартов – точная цель в опр время (см планирование)• Измерение и план \ факт – знаем проблему и источник• Коррекция серьезных отклонений

Координация• Достиж. соглас. работы всех звеньев путем установления рац. связей• Отчеты, собрания, интервью, skype, …, документы• Дает взаимное маневрирование ресурсами, единство и согласованность всех

ф-й процесса управления и руководителей

Разогрев – базовый управленческий цикл


Инфа откуда ? Отсюда


https://ru.wikipedia.org/wiki/%D0%A4%D1%83%D0%BD%D0%BA%D1%86%D0%B8%D0%B8_%D0%BC%D0%B5%D0%BD%D0%B5%D0%B4%D0%B6%D0%BC%D0%B5%D0%BD%D1%82%D0%B0


Что надо знать про SDL руководителям?

Подготовить к последствиям в SDLC при переходе на SDLРесурсыВлияние на расписание, бюджетКак убедиться что мы соответствуем требованиям SDL

Что должны делать первые лица / руководители, чтобы обеспечить, что их люди делают более защищённое ПО.

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


SDL не бесплатен – нужны время, бюджет, твердое обязательство руководства гарантировать приоритет безопасности (strong execs commitment to prioritize security over everything else)



Заказчики жалуются на частоту и стоимость залатывания дыр в безопасности

Современные атаки оказывают влияние на IT заказчиков до такой степени, что становятся заметны и внутренним и внешним пользователям, SLA

СМИ настолько фокусируются на проблемах безопасности, что те затмевают все продуктовые улучшения

Необходимость частых исправлений и выпуска патчей, фиксов и прочая работа «по хвостам» - мешает создавать новые фичи и код

Хотя цена патчей и невысока в абсолютных цифрах, частое отвлечение разработчиков на заплатки делает расписание менее предсказуемым

Почему нужно подойти системно?



Выступайте с заявлениемEmail первого лицаKickoffs by VPs (for SDL, security push, FSR, etc)Непоколебимая вера – изменения важны. И почему.

Effective Commitment - Make a statement


Полезно: используйте в сообщениях 3 составляющие – индивидуальный, групповой, глобальный уровни.



3R - Reminders, Recognition & RewardsПериодические встречи для напоминания того, что вышеПоиск и награждение передовиков, подтягивание отстающихВсе это внедрять в культуру организации

Задача руководителя: организовать и поддерживать – проста, используйте этапы SDL, на каждом будет масса возможностей

Что делать: убедиться \ донести что ожидаете, на что смотрите, поощрять поведение на благо SDLЦель: сделать процесс самодостаточным, самовоспроизводящимся

Effective Commitment - Be Visible


Безопасность – дело каждого!



Предоставляйте ресурсыUpfront costs – development budgets & tools budgets (если правильно применяете)Выбор платить или нет – за Вами. Но в безопасности вы получаете то, за что платите.Windows Server 2003: 2 дня –> в 8 недель

Effective Commitment - Provide Resources


В SDL важно все, что не нужно – убрать.



Почему может быть нужно тормознуть выпуск?

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

Effective Commitment - Stop Products



Rules of thumbMassive legacy дает плюс 20%C нуля или 2+ итерация SDL получаем экономию от 20%

Воздействие ЗаказчикиРепутацияПотерянные продажи

Главное: понимание \ осознанная вера, что

цена “не имения SDL” сильно больше затрат на SDL

Managing the SDL - Resources


Формулы нет.25 ноября 2016


Новые проекты выгодноБольшие 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


Изучай в offline



Отслеживать посещение тренингов для своих команд• Использовать оценки тестов и очки, если собираются Отслеживать создание моделей угроз и качества со старта• Есть смысл в создании спецбригады для TM review – актуальность + опыт \

сноровка \ закалка \ тренировка + отлов проблем как можно раньшеМониторить темп появления и типы уязвимостей по стадиям• Уменьшается ли к концу проекта число реальных\потенц. уязвимостей?• Есть ли классы (по типу, по компонентам), где не снижается?Отслеживать воздействие найденных снаружи уязвимостей• Старые версии• Конкуренты

Watch the Numbers & Trends• Постоянно узнавать \ учить что все это значит с позиций SDL

Managing the SDL – Control



Без поддержки сверху – не взлетитОценки точные по стоимости\выгодам никто не даетНесмотря на отсутствие исчерпывающего рук-ва, которое бы гарантировало успешность перехода на SSDL, работают следующие простые вещи:• Отслеживание deliverables и активностей SDL постадийно – и

тут уже все можно четко посчитать, причем под себя• Отслеживание external measures, таких как

удовлетворенность заказчика в плане безопасности • Отслеживание темпов появления \ отработки инцидентов

безопасности

Managing the SDL – Summary


Software security скорее про страховку, чем про фичи \ функциональность.



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

(организационными, в частности) – у нас максимум сложности: люди, процессы, технологии

«Стандартные» затыки – на заметку


Обучение, ответственность и ясные цели – ключевые компоненты успеха любой программы по безопасности.



Стандартные отговорки: Сроки горят (время)Нет ресурсов (бюджета, экспертизы, инструментов, …) на обеспечение безопасных практикМы стартап – нам нужно быстрее стать популярными и заработать много денег…

Разработчики и Безопасность


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 одним взглядом – 20 и 10 лет назад


SDLC

Training Reqs Design Impl Verification Release Response



Постоянное обучениеСпособы доставки тренинговУпражнения и Лабы (30 мин)Измерение Знаний

Обследовать подготовленность организации по темам безопасности и защиты данных (privacy)

При необходимости создать стандартные курсы обучения

• Basics minimum baseline• Raise User Awareness

Кто: Все задействованные сотрудники в технических ролях (Devs, QA, PMs)Как часто: 1+ раз в годЧто: Знания для выполнения остальных фаз + как работаем по новому процессу

0. Education


Безопасность – дело каждого!



Как организации сделать новый класс самостоятельноОпределить цели и ЦА для класса.Эксперт по безопасности делает новый класс – рабочую программу.Другие технические эксперты смотрят материалы на предмет технической точности и применимости.Эксперты по тренингам (не безопасники) и редакторы вычитывают и улучшают как согласованность, так и типографические ошибки.Проводим первый класс. Главная цель – понять тайминг и получчить обратную связь по поводу содержимого \ контента.Обновляем материалы с учетом поступившей новой информации.Повторяем класс ежемесячно минимум 6 мес .Через 6 мес класс записывается и выкладывается в интранет.

0. Education – создаем свой курс обучения


Хозяйке на заметку: для максимально бюджетных вариантов всегда есть PowerPoint Record Narration.



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



The Basics of Secure Software Design, Development, and Testing Fuzz Testing in DepthThreat Modeling in DepthImplementing Threat MitigationsSecurity Design and Architecture: Time-Tested Design PrinciplesIntroduction to the SDL and Final Security Review (FSR) ProcessSecurity Tools OverviewPerforming Security Code ReviewsSecure Coding PracticesSecurity Bugs in DetailAttack Surface Analysis (ASA) and Attack Surface Reduction (ASR)Exploit DevelopmentBuild RequirementsSecurity ResponseCryptography by ExampleCustomer Privacy

Basic software security training should cover foundational concepts such as: Secure design, including the following topics:

Attack surface reductionDefense in depthPrinciple of least privilegeSecure defaults

Threat modeling, including the following topics:Overview of threat modelingDesign implications of a threat modelCoding 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 testingRisk assessmentSecurity testing methods

Privacy, including the following topics:Types of privacy-sensitive dataPrivacy design best practicesRisk assessmentPrivacy development best practicesPrivacy testing best practices

As time and resources permit, training in advanced concepts may be necessary. Examples:

Advanced security design and architectureTrusted user interface designSecurity vulnerabilities in detailImplementing custom threat mitigations

0. Education – Чему учить - 2016 vs 2006


Изучай в offline25 ноября 2016


Проверить применимость• Продукт или 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


Назначайте снаружи25 ноября 2016


Analyzing & Triaging• Security & Privacy BugsSecurity Sounding BoardsPreparing for FSRWorking with Reactive Sec TeamsBuilding the Security Leadership TeamBug Tracking process• Security & Privacy fieldsBug Bar

1. Project Inception – Adviser at Work



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


The Security/Privacy Bug Cause field:Not a Security BugBuffer Overflow or UnderflowArithmetic Error (for example, integer overflow)SQL/Script InjectionDirectory TraversalRace ConditionCross-Site ScriptingCryptographic WeaknessWeak AuthenticationWeak Authorization/Inappropriate ACLIneffective Secret HidingResource Consumption (DoS)Incorrect/No Error MessagesIncorrect/No Pathname CanonicalizationOther



Common Secure-Design PrinciplesAttack Surface AnalysisAttack Surface Reduction

2. Define & Follow Best Practices


Economy of mechanism Keep the code and design simple and small. Fail-safe defaultsComplete 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: 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


Проще говоря, делаем так:

Ограничиваем количество кода, доступного по умолчаниюОграничиваем в плане откуда можно добраться до кодаОграничиваем в плане кто может добраться до кодаУменьшаем привилегии кода



Уточнить уровень поддержки SDL активностей (effort)• Что требуется покрыть моделями• Что требует design review• Что требует penetration tests• Что требует динамического анализа \ фаззингаSecurity Risk Assessment QuizPrivacy Impact Rating• Анонимные данные• PII• Sensitive данныеНайти компоненты с наибольшим рискомПоработать с каждым

Поможет с оценками!

3. Product Risk Assessment


Нет выгод от обладания PII & Sensitive данных –

удали



Преимущества от моделей угрозМодели угроз (Артефакты)Что моделировать?Строим модель (Подготовить -> Проанализировать -> Меры)ПроцессПоможет code review & testingКлючевые факторы успеха и метрики

4. Risk Analysis



Преимущества от моделей угроз по мнению MicrosoftДает вклад в процесс управления рисками потому что угрозы ПО и инфраструктуре есть риски для пользователей и окружения, в котором развертывается ПО.Вскрывает угрозы системе до того как система реализуется в коде .Перепроверка архитектуры и дизайна потому что команда разработки проходит через редизайн снова и снова.Заставляет разработчиков смотреть на дизайн с разных точек зрения – а именно безопасности и защиты данных. Понимая наиболее подвергающиеся риску компоненты, разработчики фокусируются на компонентах с наибольшими шансами быть атакованными. Помогает уточнить выбор целесообразных мер для ПО и окружения.Дает вклад в процесс уменьшения поверхности атаки.Помогает с code review.Направляет penetration testing.

4. Risk Analysis – TM - Преимущества





Высокоуровневая модель приложения

Диаграммы типа DFD

Список добра (assets), требующего защиты

Угрозы системе отранжированные по рискам

Список компенсирующих мер (опционально)

Плюс вспомогательная информация:Use scenarios Конфигурации развертывания, как обычно пользуются

External dependencies Продукты, компоненты, сервисы, от которых зависим

Security assumptions На что можем рассчитывать в плане безопасности в сторонних компонентах

External security notes Полезная информация админам или пользователями, чтобы работать более защищенно

4. Risk Analysis – TM - Artifacts



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

данных, потоки данных, внешние сущности8. Определи риски – полезны деревья ранжирования рисков для

каждой угрозы из STRIDE9. Спланируй компенсирующие меры – Ничего не делать,

Удалить, Отключить, Предупредить пользователя, компенсировать с помощью техники(широко) или технологии (конкретно)

4. Risk Analysis – the TM process


Изучай в offline25 ноября 2016


Порнография и Модели Угроз – Что общего?

4. Risk Analysis – TM – KPIs & Metrics



Ключевые факторы успеха и метрики Порнография и

Модели Угроз

4. 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)


https://en.wikipedia.org/wiki/I_know_it_when_I_see_it

https://en.wikipedia.org/wiki/Potter_Stewart


Как минимум, модели угроз должны быть помечены “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-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) которые объясняют, как использовать эту технологию безопасно и какие компромиссы.

4. Risk Analysis – TM – Quality Guidelines-2\2





Setup DocsUser GuideHelp DocsDev DocsCreating Tools (Lockdown Tool)

Security implications• В зависимости от действий• От конфигураций• Как заморозить конфигурацию• Как upgrade делать• Как поверх \ вместо конкурента

Install / Maintain / Use

5. Creating Tools Docs Best Practices



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


Знать мало – надо применять!



DASD / Fuzz testing• File format / protocol parsers, API• 100000 cyclesPenetration testingRun-time verification• AppVerif & Driver VerifierRe-review threat models• Largest attack surface• Threats with highest risks• Focus code review & testing effortsReevaluate 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


Изучай Client code Bug Bar в

offline



Example: Fixing Bugs Found Through Fuzz TestingServer 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

8. Security Push



Команды, которые выполнили следующие задачи будут иметь более короткий security push:

Неукоснительно содержат все модели угроз в актуальном состоянии Активно и полностью протестировали модель угроз посредством тестирования на проникновенияТщательно проконтролировали и задокументировали поверхности атаки и любые изменения, внесенные в них в процессе разработкиВыполнили ревью кода на безопасность для всего высокоприоритетного кодаИдентифицировали и задокументировали контакты в разработке и тестировании для всего кода продуктаПридерживались строгих стандартов кодированияНеукоснительно привели весь ранний код проекта в соответствие текущим стандартам безопасностиУтвердили план по документации по безопасности

8. Security Push – Are We Done Yet?



Можно ли поставлять?Отдельная команда для выполнения FSR• Product team coordination (Quiz)• TM review• Unfixed security bugs review• Ошибки при заполнении багов• Уложиться в неделю (выделить

ресурсы на ревью)• Даже если много багов – делать!• Tools use validation

Handling exceptionsЧеклисты

9. Final Security Review (FSR)


Ключевая концепция: Эта фаза не используется как точка для завершения всех задач пропущенных на предыдущих стадиях



Примеры вопросов—многие ответы есть давно:Это отдельный продукт или service/mgmt/feature/add-on pack?Есть ли торчащие в Сеть (network-facing) части продукта?Когда был security push с сколько длился?Где задокументирована поверхность атаки?Где лежат модели угроз?Где лежит код?Где задокументирован bug bar (наши критерии оценки багов)?Где список (лучше запрос) непоправленных багов по безопасности?security team уже проверяла модели угроз? Если да, кто проверял и что на выходе?Есть ли какие-либо SDL requirements которые не соблюдаются? Если да, то какие и почему?Отрабатывают ли все инструменты анализа и когда был последний прогон ими?

9. 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 значениями выше

9. FSR – Unfixed Security Bugs Review



Проверить продукт на соответствие требованиям SDL и отсутствие известных уязвимостей.

Получаем независимое заключение готовности продукта к выпуску.

FSR не является:

Тестом на проникновение. Запрещено ломать и обновлять продукт.

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

Процессом финальной подписи продукта и отправки его в тираж

FSR должен обязательно включать три возможных результата окончательной проверки безопасности:

1. можно выпускать

2. можно выпускать с ограничениями (и есть план по их душу)

3. FSR с эскалацией (на руководство Компании)

9. Final Security Review (FSR) - takeaways


Ключевая концепция: Эта фаза не используется как точка для завершения всех задач пропущенных на предыдущих стадиях



В следующий раз! Next PDUG Appearance?

10. Security Response Planning



План реагирования на инциденты безопасности созданДокументация для клиентов обновленаСоздан централизованный архив всего, что поможет

с сервисным обслуживанием релизаснизить стоимость поддержки в долгосрочной перспективе

Обязательно включить в архивИсходникиПриватные отладочные символыМодели угрозДокументацию – техническую и пользовательскуюПланы реагированияЛицензионные и прочие servicing terms для используемого стороннего ПО

11. Release –sign off & поместить в Архив


Информация


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



Инцидент случился? Идем по заранее созданному плану.Выполняем активности по плану реагирования на инциденты безопасностивыпускаем обновления в соответствии с графиком релизовПересчитываем рискиИнформируем клиентовПубликуем информацию

Выгоды планового реагированияПонятно что происходитЕсть ответственныеУдовлетворенность клиента растетСобираем данные для будущих разработокПроводим тренинги

12. Security Response Execute


Не если, а когда!



III. Напосошок

1.Подведем итог. Выводы.

2. Что почитать и полезные ссылки

3. Вопросы и ответы. Дискуссия.


Более защищенная, безопасная и надежная разработка, которая1. Увеличивает ROI и качество ВАШЕГО продукта\сервиса2. Снижает риски (в т.ч. «завалить» проект, получить качество

продукта ниже ожиданий, превысить бюджет, сроки, а также связанные с Интеллектуальной Собственностью)

3. Минимизирует возможный ущерб и стоимость инцидентов4. Снижает стоимость разработки, поддержки и общую

стоимость владения 5. Помогает соответствовать требованиям (compliance)6. Повышает уровень удовлетворенности у Заказчика и Команды7. Повышает продуктивность8. Уменьшает сроки \ график \ расписание

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



1. Меньше времени на переделывание и отладку2. Меньше времени на тестирование3. Меньше времени на поддержку и проще развитие4. Отлов проблем как можно раньше5. Избегаем повторяющихся security issues6. Избегаем несогласованных уровней безопасности7. Повышаем экспертизу и опыт в безопасности8. Выше продуктивность + чаще укладываемся в сроки

Выгоды SDL / SSDL для разработчиков


1. Качественный код 2. Больше времени на работу и развитие3. Проактивность25 ноября 2016


Ликбезы по SSDL со СтачкиValery on SSDL, video, PDUG, Aug’16Building 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)Алексей Бабенко Цикл безопасной разработки SDLAndrey Beshkov on SDL & ALM (1, 2)Nazar Tymoshyk on SDL & Agile (1, 2, 3)

Что почитать 1 \ 2


http://www.slideshare.net/ValeryBoronin/2016-61855208

https://www.facebook.com/valery.boronin/posts/10207732651169370

http://www.swsec.com/

http://makhmetov.ru/articles/dao-of-software-security.html

https://www.microsoft.com/en-us/sdl/

http://www.amazon.com/Security-Development-Lifecycle-Michael-Howard/dp/0735622140


https://www.microsoft.com/ru-RU/download/confirmation.aspx?id=12379



http://go.microsoft.com/?linkid=9708425

https://channel9.msdn.com/Events/Build/2014/2-546



http://www.slideshare.net/DefconRussia/sdlc-38863452



http://www.slideshare.net/arekusux/sdl-38135128

http://www.slideshare.net/arekusux/sdl-38135128

http://www.slideshare.net/abeshkov/

http://www.slideshare.net/abeshkov/

http://www.slideshare.net/abeshkov/microsoft-sdl

https://www.techdays.ru/videos/7396.html

http://www.slideshare.net/NazarTymoshyk



http://www.slideshare.net/NazarTymoshyk/security-as-a-new-metric-for-business-product-and-development-lifecycle

http://www.slideshare.net/NazarTymoshyk/agile-and-secure-sdlc

http://www.slideshare.net/NazarTymoshyk/agile-and-secure-development



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


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

https://www.owasp.org/index.php/Category:OWASP_Code_Review_Project

https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project

http://www.sans.org/top25-software-errors

http://www.cert.org/secure-coding


1. Application Threat Modeling на сайте OWASP2. Статья с описанием подхода на Хабре от Владимира Кочеткова, PT3. Обнаружение недостатков безопасности при помощи STRIDE

(MSDN Magazine)4. The STRIDE Threat Model на сайте Microsoft5. Microsoft Threat Modeling Tool 2016

Моделирование угроз – Ссылки


https://www.owasp.org/index.php/Application_Threat_Modeling

http://habrahabr.ru/post/129386/

http://msdn.microsoft.com/ru-ru/magazine/cc163519.aspx#S10




http://msdn.microsoft.com/en-US/library/ee823878(v=cs.20).aspx

http://blogs.microsoft.com/cybertrust/2015/10/07/whats-new-with-microsoft-threat-modeling-tool-2016/

Спасибо!- Вопросы, Идеи, Уточнения- А давайте попробуем <> ?!- Поработаем вместе?

mailto:[email protected]?subject=%D0%A1%D1%82%D0%B0%D1%87%D0%BA%D0%B0%202016%20SSDL


ИщемSDL/SSDL сообщество – тех, кому интересна “жизнь по SSDL”Кто готов делиться опытом – уже живет или в процессе перехода на SDLразработчиков на С#, QA, фронтендеров, аналитиков в Новосибирск bit.ly/PT_Novosibirsk_job…и другие города тоже http://www.ptsecurity.com/ru-ru/about/vacancy

Минутка Рекламы


http://bit.ly/PT_Novosibirsk_job

http://bit.ly/PT_Novosibirsk_job

http://www.ptsecurity.com/ru-ru/about/vacancy

http://www.ptsecurity.com/ru-ru/about/vacancy