лет • Начинал еще под Windows 3.1 • Достиг определенных высот разработчиком режима ядра под Windows (до 2009) • В безопасности с прошлого тысячелетия ;-) • Работал CTO небольшой компании (30+ человек) • Директором по исследованиям большой («Лаборатория Касперского», 2500+ человек, 2009–2014) • Сейчас отвечаю за направление безопасной разработки (SDL / SSDL) в Позитиве • Мы с командой создаем новый продукт по автоматизации безопасной разработки
• Что такое защищенное приложение? • Почему ПО небезопасно? • Разработчики и безопасность • Что такое SDL/SSDL = безопасная разработка? • Зачем нужна? • Какие проблемы решает?
на восстановление Ущерб по инциденту Заказчики Репутация Безопасность на стыке с надежностью: у вас 5 компонентов в e-commerce приложении с 98% uptime каждый? Ожидайте 150 мин простоя в день! * *Источник: книга Gary McGraw (https://www.garymcgraw.com/)
хорошо описанные. Статистика по распределению уязвимостей веб-приложений за 2015 год Источник: по данным аналитического центра Positive Technologies (серым цветом – 2014 год)
ящик Высокий Средний Низкий Почему мы об этом говорим? Источник: по данным аналитического центра Positive Technologies за 2015 год 56% 69% 88% 100% 100% 100% 44% 38% 75% 0% 20% 40% 60% 80% 100% 120% PHP Java Другие Высокий Средний Низкий
постоянном ожидании сбоя. Работать даже тогда, когда твоего сбоя яростно ожидает оппонент. Защищенное ПО гораздо больше вкладывает в учет проблемных кейсов, чем не имеющих проблем. На шаг впереди – вот девиз проектировщиков и других безопасных разработчиков. Источник: вступительное слово к замечательной книге Gary McGraw (первопроходца в SDL)
• Нет ресурсов (бюджета, экспертизы, инструментов, …) на обеспечение безопасных практик • Мы стартап – нам нужно быстрее стать популярными и заработать много денег • … Shortage of skill or shortage of discipline? Знать мало – надо применять!
Development Life Cycle • SSDLC – Secure Software Development Life Cycle • SDLC – Secure / Security Development Life Cycle • SSDL – Secure Software Development • SDL – Secure Development Lifecycle (MSFT) SDLC
почти полностью покрывает годовые затраты на повышение безопасности разработки • Предотвратить проблему с безопасностью в 4 раза дешевле, чем разбираться с ее последствиями Исследование Forrester: • Разработка безопасного ПО еще не стала широко распространенной практикой • Компании, применяющие методы SDL, демонстрируют гораздо более быстрый возврат инвестиций BSIMM (позже) & McGrow (в книге) еще более категоричны: • Разрыв между теми, кто применяет, и теми, кто ждет, нарастает с ускорением • Пугают тем, что скоро HR начнут массово искать SDL-certified людей ;-) • В результате не перестроившиеся начнут вылетать с рынка
formal testing > 99% efficient Quality excellence has ROI > $15 for each $1 spent Источник: http://namcookanalytics.com/software-quality-survey-state-art/
безопасной? • Роли, ответственность, квалиф. требования • Обязательные активности (16 практик) • Дополнительные активности • О чем еще стоит упомянуть? • Процедура проверки безопасности приложения • Так этих SDL’ей… много и они разные?! Что же такое SDL? Из чего состоит?
уровень зрелости компании и разработать план действий по внедрению соответствующих процессов для реализации полноценного цикла безопасной разработки • Так когда разработка становится безопасной? Зрелость Организации
корпоративном окружении? • Обрабатывает / хранит персональные данные или sensitive информацию? • Взаимодействует по сети / другим каналам передачи информации? • Практика показывает, что сложно найти приложение, которому не показан SDL
/ конфиденциальности (снаружи) • Аудитор (подчиненная роль) • Эксперт (подчиненная роль) • Можно совмещать аудитора с экспертом • Советников тоже можно совмещать •Руководители групп по безопасности / конфиденциальности (изнутри) • Отвечают за координацию и отслеживание вопросов безопасности на проекте + сообщают состояние Советнику и другим ЗЛ • Можно совмещать роли security и privacy champions
в технических ролях (Devs, QA, PMs) 2. Не реже 1 раза в год 3. Знания для выполнения остальных фаз + как работаем по новому процессу • Обследовать подготовленность организации по темам безопасности и защиты данных (privacy) • При необходимости создать стандартные курсы обучения Безопасность – дело каждого! Разработать критерии качества программы обучения Содержимое должно покрывать темы со следующего слайда Определить частоту тренингов Разработчик должен пройти не менее Х тренингов в год Определить минимальный приемлемый порог тренингов в группе разработки 75% техперсонала должны пройти базовые тренинги до выпуска беты
дизайн • Уменьшение поверхности атаки • Наименьшие привилегии • Многослойная защита • Безопасные настройки по умолчанию 2. Моделирование угроз 3. Безопасное кодирование (переполнение буфера, XSS, SQL-инъекции, криптография) 4. Тестирование безопасности • Разница с функциональным тестированием • Оценка рисков • Методы тестирования безопасности Безопасность – дело каждого! • 5. Защита информации / Privacy / Соответствие требованиям • Персональные данные, ФЗ 152 и отраслевые стандарты • Трансграничная передача данных • Обработка, хранение и т. п. чувствительных данных – ФЗ №242 • 6. … • … • Trusted user interface design • …
для проекта • Определение требований по безопасности (разово) SDL Practice #2: Establish Security and Privacy Requirements • Определить и задокументировать порог отбраковки продукта по ошибкам, связанным с безопасностью и защитой данных (разово) SDL Practice #3: Create Quality Gates/Bug Bars • Оценка рисков SDL Practice #4: Perform Security and Privacy Risk Assessments (разово)
• Определить и задокументировать архитектуру безопасности и идентифицировать критические компоненты безопасности 2. Анализ / сокращение поверхности атаки (разово) • Задокументировать поверхность атаки продукта • Ограничить ее установками по умолчанию 3. Моделирование угроз • Определить угрозы и меры снижения угроз • Систематический пересмотр свойств продукта и его архитектуры с точки зрения безопасности • Определить критерии выпуска обновления продукта в связи с изменением в безопасности продукта
и упрощает моделирование угроз так, чтобы им мог заниматься архитектор Обучает созданию диаграмм угроз Анализ угроз и мер защиты Интеграция с багтрекером Отчеты по угрозам и уязвимостям
процессов, документации и инструментов, необходимых для безопасного развертывания и эксплуатации разрабатываемого продукта • Использование утвержденных / доверенных средств и их аналогов • Практики безопасного программирования • Статический анализ кода Конкретно: Поиск случаев использования запрещенных API Применение механизмов защиты предоставляемых ОС Использование безопасных версий библиотек и фреймворков Соблюдение специфических требований безопасности (XSS, SQL-инъекции…)
можно раньше. В идеале – как только появился готовый для этого код • Динамический анализ • Фаззинг – файлами, вводом данных в интерфейсные элементы и код сетевой подсистемы • Повторно проверьте модели угроз, риски, поверхность атаки. Все ли вы учли? • Начните планирование процесса реагирования на обнаружение уязвимостей в выпущенном продукте – см. следующую стадию • При необходимости выполнить security push (с каждым разом все реже) • Не является заменой работе над безопасностью в процессе разработки • Ревью кода • Тестирование на проникновение • Ревью дизайна и архитектуры в свете вновь обнаруженных угроз
Analyzer • Убедиться что SDL соблюден при компиляции и сборке MiniFuzz File Fuzzer • !exploitable в WinDbg • DAST RegexFuzer • DAST Attack Surface Analyzer • Анализ снимков системы • Измеряет потенциальную поверхность атаки на приложение и ОС AppVerifier • Динамический анализ системы MSF Agile + SDL шаблоны для TFS • Автоматически создает процессы соблюдения SDL в момент создания нового спринта или выполнения check in • Контролирует выполнение всех необходимых процессов безопасности CMMI Шаблоны SDL для TFS • SDL требования как задачи • SDL-based check-in policies • Создание отчета Final Security Review • Интеграция с инструментами сторонних производителей • Библиотека пошаговых указаний SDL how-to
политики поддержки продукта • Создать план реагирования на инциденты безопасности • Группа инженерной поддержки: ресурсы внутри и снаружи организации для адекватной реакции на обнаружение уязвимостей и защиту от атак • Контактные данные лиц, доступных 24x7x365 • 3–5 инженеров • 3–5 специалистов из маркетинга • 1–2 менеджеров верхнего уровня • Обратите внимание на: • Необходимость выпуска экстренных обновлений вашего продукта из-за уязвимостей в унаследованном коде • От других групп в той же организации • Сторонних производителей • Включенном в ваш продукт • Лицензионные условия, возможность вносить изменения, имена файлов, версии, контактные данные и т. п. • Может быть необходимость обновлять продукт после обновления ОС и т. п. http://www.microsoft.com/security/msrc/whatwedo/responding.aspx Watch Alert and Mobilize Resources Assess and Stabilize Resolve Reporting Analysis and Mitigation Create Fix Update Models Test Fix Выпуск Lessons Learned Provide Guidance
Проверить продукт на соответствие требованиям SDL и отсутствие известных уязвимостей. Получаем независимое заключение готовности продукта к выпуску. FSR не является: • Тестом на проникновение. Запрещено ломать и обновлять продукт • Первой проверкой безопасности продукта • Процессом финальной подписи продукта и отправки его в тираж FSR должен обязательно включать три возможных результата окончательной проверки безопасности: 1. Можно выпускать 2. Можно выпускать с ограничениями (и есть план по их душу) 3. FSR с эскалацией (на руководство Компании) Ключевая концепция: эта фаза не используется как точка для завершения всех задач, пропущенных на предыдущих стадиях
в Архив • План реагирования на инциденты безопасности создан • Документация для клиентов обновлена • Создан централизованный архив всего, что поможет • С сервисным обслуживанием релиза • Снизить стоимость поддержки в долгосрочной перспективе • Обязательно включить в архив • Исходники • Приватные отладочные символы • Модели угроз • Документацию – техническую и пользовательскую • Планы реагирования • Лицензионные и прочие Servicing Terms для используемого стороннего ПО
случился? Идем по заранее созданному плану • Выполняем активности по плану реагирования на инциденты безопасности • Выпускаем обновления в соответствии с графиком релизов • Пересчитываем риски • Информируем клиентов • Публикуем информацию • Выгоды планового реагирования • Понятно, что происходит • Есть ответственные • Удовлетворенность клиента растет • Собираем данные для будущих разработок • Проводим тренинги Не если, а когда!
Сode review глазом • Важные компоненты • Где храним, обрабатываем, передаем sensitive данные • Криптография 2. Анализ уязвимостей схожих приложений (конкурентов) 3. Тесты на проникновение (но сделать до FSR!) Улучшаем процесс дальше: 1. Анализ первопричин Исследование причин появления найденных уязвимостей (из-за чего она возникла – человеческая ошибка? Несовершенство процесса? Ошибка автоматизации?) 2. Регулярное обновление процесса
хранению артефактов через приложение со строгим контролем доступа (RBAC) • Руководители групп безопасности и конфиденциальности обеспечивают ввод данных и их корректность • Их используют Советники, обеспечивая среду для FSR и для анализа, а также подтверждения выполнения всех требований Обязательно хранить: • Требования безопасности и конфиденциальности для организации • Функц. и тех. требования для разрабатываемого приложения • Рабочий контекст приложения (Ex: процедура отслеживания)
SDL РС БР ИББС-2.6-2014) Обучение разработчиков Secure Design, Secure Coding Training Обучение - Отслеживание уязвимостей 3rd Party Security Implementation (частично) Выявление уязвимостей Эксплуатация Определение требований к ИБ Product Security Requirements Requirements Проектирование Проектирование Создание модели угроз Secure Design Design Оценка рисков Разработка технического задания (рекомендательно) Практики безопасной разработки Secure Coding Implementation Создание - Анализ кода Secure Analysis Implementation Анализ кода Создание и тестирование (рекомендательно) Тестирование безопасности Vulnerability Testing Verification, Release Тестирование безопасности Создание и тестирование Выпуск релиза - Release Выпуск Прием и ввод в действие Поддержка - Response Поддержка Сопровождение и модернизация Вывод из эксплуатации - Снятие с эксплуатации Источник: http://www.slideshare.net/arekusux/sdl-38135128
Model (SAMM) и Building Security In Maturity Model (BSIMM) для оценки текущего уровня зрелости, а также в качестве методологической основы для построения процессов обеспечения безопасности разработки. В рамках предлагаемых методик выделяются четыре основных направления развития процессов управления безопасностью разработки или бизнес-функций: корпоративное управление (Governance), разработка (Construction), контроль (Verification), развертывание и эксплуатация (Deployment).
• C чего начинать, в каком порядке? • Disclaimer – о чем обязан предупредить • C чем будут трудности у руководителя • Предостережения разработчику • Как преодолевать (тезисно и справочно) • Знание – Сила! И другие полезности Что важно, что забрать с собой
платформы и языка разработки • SDL подходит для разных сценариев разработки включая бизнес-приложения и онлайн-сервисы • SDL применим к разным методологиям разработки, таким как водопад и agile • Успешная реализация SDL предполагает автоматизацию с помощью инструментов. Вы можете использовать инструменты от других компаний • SDL подходит организациям любого размера. От разработчика-одиночки до огромных корпораций
каждом этапе / фазе, очень важны. The SDL process does benefit from investments in effective tools & automation but the real value lies in comprehensive & accurate results.
безопасного программирования 3. Тестирование безопасности и анализ кода 4. Процедуры выпуска и поддержки 5. Отслеживание уязвимостей, реестр ПО 6. Формальное определение требований к ИБ 7. Планы реагирования на инциденты 8. Моделирование угроз, анализ поверхности атак 9. Внешний анализ
Предупреждение от Securosis Adopting MS-SDL wholesale is a little like a child putting on adult clothes because they want to be ‘big’. You cannot drop that particular process into your development organization and have it fit. More likely you will break everything. Your team will need to change their skills and priorities, and though it sounds cliche, people are resistant to change. Existing processes need to be adjusted to accommodate secure development processes and techniques. You will need new tools, or to augment existing ones. You will need a whole new class of metrics and tracking. And everything you pick the first time will need several iterations of alteration and adjustment before you get it right – this isn’t Microsoft’s first attempt either.
Слишком полагаться на тестирование на поздних этапах цикла • Управлять без измерений • Обучать, не оценив • Начинать без достаточной поддержки руководства • Политические риски • Бюджетные риски • Стандартные для дисциплины Управление Изменениями (организационными, в частности) – у нас максимум сложности: люди, процессы, технологии Обучение, ответственность и ясные цели – ключевые компоненты успеха любой программы по безопасности
безопасности ПО как о проблемах кодирования. McGraw метко называет это явление «парад багов» • Неверно убеждение, что software security про то, как грамотно адаптировать или использовать различные фичи или соглашения по безопасности. Software security скорее про страховку, чем про фичи / функциональность • Последнее предупреждение – не полагайтесь чересчур на чеклисты. Тот же STRIDE в моделировании угроз. Чеклисты устаревают без обновления по результатам открытий и не всегда полны Основанный на фичах подход к безопасности зовут иногда ‘cookbook’ approach. Конечно, поможет с рецептом, но просто чтение книги без включения плиты и пробы блюда вряд ли сделает из вас хорошего повара. Опыт – самый могущественный учитель.
себя: выявляй зависимости и планируй. Пошаговые изменения – см. дальше. Знай, как у тебя все работает, и ищи грамотный путь улучшить с использованием лучших практик • Выкатывай отдельные инициативы аккуратно: найди чемпиона для каждой и надели ответственностью. Не оставляй без помощи – коучинг и наставничество. Пилоты и прототипы – не надо на всех сразу накатывать сырое • Обучай людей: разработчики и архитекторы могут не подозревать, как много тут от них зависит. Обучение и воспитание • Заложи основу метрикам: измеряй и оценивай прогресс. Метрики (в т. ч. относительно себя прошлого и по бизнес-показателям) и измерения – без них никуда в любой большой организации. В идеале надо накрыть четыре зоны: project, process, product and organization. Первые три вокруг artifact or activity в разработке, четвертая, чтобы определять тренды вокруг первых трех • Установи и поддерживай способность к постоянным изменениям: создавай условия путем постоянных измерений и оценки результатов, периодически переводя внимание на отстающие аспекты своей программы повышения уровня безопасной разработки
the bleeding • SAST или переход на процесс анализа рисков • Собери все, что назрело / Harvest the low-hanging fruit • Хороший барометр, готова ли организация меняться реально • Заложи основание / Establish a foundation • Создай контроль изменений / Creating change control programs • Построй анализ первопричин / Building root-cause analysis function • Создай контур обратной связи / Setting up critical feedback loop • Усиляй сильные качества / Craft core competencies • Развивай то, что дает различия / Develop differentiators • Строй все, что осталось / Build out nice-to-haves
(первая фаза) проведение инвентаризации, оценки и анализа текущего уровня зрелости разработки с точки зрения безопасности. Внедрение или повышение уровня базовых практик безопасности. Создание рабочей группы безопасности приложений. Целевое обучение участников группы. Подготовка плана повышения уровня зрелости разработки с точки зрения ИБ. Вторая волна (вторая и третья фазы) – реализация плана повышения уровня зрелости разработки с точки зрения ИБ. В рамках второй фазы проводятся основные активности, осуществляется внедрение основных технических и организационных механизмов, разработка необходимой документации. Проводится массовое обучение сотрудников практикам безопасной разработки и приемам использования внедряемых инструментов, разработчикатываются метрики оценки практик безопасности. Третья фаза позволяет оценить успешность мероприятий второй фазы, исправить явные недочеты и подготовить план повышения уровня зрелости для третей волны. Третья волна (четвертая и пятая фазы) – в рамках третьей волны реализуется план повышения уровня зрелости с учетом опыта третьей фазы. Также внедряются дополнительные организационные и технические механизмы, необходимость которых была выявлена в ходе реализации второй и третьей фазы. В рамках пятой фазы проводится сопровождение внедренных практик безопасности и оценка эффективности текущего уровня зрелости. Оценочная продолжительность каждой из фаз – 6 месяцев. PDCA = Plan – Do – Check - Act
Knowledge Architecture Seven knowledge catalogs (principles, guidelines, rules, vulnerabilities, exploits, attack patterns, and historical risks) are grouped into three knowledge categories (prescriptive knowledge, diagnostic knowledge, and historical knowledge). Experience, Expertise, and Security Software developers place a high premium on knowledge. Experience is king, and expertise is very valuable.
на переделывание и отладку 2. Меньше времени на тестирование 3. Меньше времени на поддержку и проще развитие 4. Отлов проблем как можно раньше 5. Избегаем повторяющихся security issues 6. Избегаем несогласованных уровней безопасности 7. Повышаем экспертизу и опыт в безопасности 8. Выше продуктивность + чаще укладываемся в сроки 1. Качественный код 2. Больше времени на работу и развитие 3. Проактивность
и надежная разработка, которая: • Увеличивает ROI и качество ВАШЕГО продукта / сервиса • Снижает риски (в т. ч. «завалить» проект, получить качество продукта ниже ожиданий, превысить бюджет или сроки, а также связанные с интеллектуальной собственностью) • Минимизирует возможный ущерб и стоимость инцидентов • Снижает стоимость разработки, поддержки и общую стоимость владения • Помогает соответствовать требованиям (compliance) • Повышает уровень удовлетворенности у Заказчика и Команды • Повышает продуктивность • Уменьшает сроки / график / расписание
Предотвращение одной уязвимости почти полностью покрывает годовые затраты на повышение безопасности разработки Исследование Forrester Компании, применяющие методы SDL, демонстрируют гораздо более быстрый возврат инвестиций Предотвратить проблему с безопасностью в 4 раза дешевле, чем разбираться с ее последствиями!
your product Popular? Next Target! • Разработка защищенного кода с помощью процесса безопасной разработки – экономия денег Компании, снижение рисков и повышение качества продукта •Пора попробовать SDL!
– обязательно к прочтению • Дао безопасности от Геннадия Махметова • 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)
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
OWASP 2. Статья с описанием подхода на Хабре от Владимира Кочеткова, PT 3. Обнаружение недостатков безопасности при помощи STRIDE (MSDN Magazine) 4. The STRIDE Threat Model на сайте Microsoft 5. Microsoft Threat Modeling Tool 2016
интересна «жизнь по SSDL» • Тех, кто готов делиться опытом, уже живет или находится в процессе перехода на SDL • Разработчиков на С#, QA, фронтендеров, аналитиков в Новосибирск bit.ly/PT_Novosibirsk_job • …и другие города тоже www.ptsecurity.com/about/vacancy
pdugslides
fukubaka0825
taro28
kakao
maruto
zsmb
cer
tutinoko
oheyadam
kno3a87
petamoriken
ivargrimstad
addyosmani
paigeccino
sstephenson
eileencodes
garrettdimon
jacobian
lemiorhan
honnibal
shlominoach
sachag
bryan
aarron
![Заголовок Цикл [безопасной] разработки • SDLC – Systems / Software](https://files.speakerdeck.com/presentations/f1eed327801d4b9e85c7c5388768bc11/slide_12.jpg){kind=link}
