Мифы и легенды безопасной разработки

Доклад Юрия Шабалина (Swordfish Security) для PDUG-секции на PHDays 8.

Transcript

1. Заголовок ptsecurity.com Мифы и легенды безопасной разработки Ведущий архитектор по информационной безопасности Swordfish Security Шабалин Юрий
2. Заголовок Who Am I Yury Shabalin Chief Security Architect at Swordfish Security Ex - Positive Technologies, Alfa-Bank, Sberbank - Developing - SSDL integration - Source code analysis - Mobile application security analysis - Security Researcher - Android Bughunter Speaker at conferences Zer0Nights, PhDays, RISSPA, OWASP
3. Заголовок Поговорим о безопасной разработке • Что вообще такое безопасная разработка? • Общемировые практики по построению процесса безопасной разработки • Ключевые мифы и легенды безопасной разработки • А кто знает как правильно? • Секция вопросов и ответов * Мнение автора не соответствует действительности * Все персонажи вымышлены, а совпадения случайны
4. Заголовок Процесс SSDL (SDLC) SDLC, где S – это Security
5. Заголовок Итак, начинаем строить безопасную разработку А зачем? • Нужно улучшить качество ПО с точки зрения безопасности • Требования регуляторов • Руководство сказало – «Надо» • У всех есть, мы тоже хотим
6. Заголовок Инструменты решают все проблемы Миф #1 Выбор инструментов (SAST\OSA\DAST\IAST\BAST\RASP\WAF) • Пилоты • Сравнение решений • Бюджетирование • Закупка • Поставка • Эксплуатация (?)
7. Заголовок Проверка перед релизом поможет выявить уязвимости • Увеличение сроков выпуска релиза • Большое количество новых уязвимостей • Вероятность пропустить что-то сильно увеличивается • Вызывает ненависть программистов Миф #2 • Нужно просканировать как можно больше систем • Особенности процесса разработки не учитываются • Инструменты стоят отдельно от разработки
8. Заголовок Отчёты - удобная форма описания уязвимостей Миф #3
9. Заголовок Экспертиза должна быть сосредоточена в одном месте Вредные советы: • Держите экспертизу внутри команды • Никогда не выпускайте её наружу • Старайтесь как можно меньше общаться с разработкой • Если приходится общаться, пишите письма • Не ходите на встречи и собрания Миф #4
10. Заголовок Требования ИБ понятны всем Миф #5 Требования ИБ: • Представлены в нечитаемом виде \ неудобном формате • Неактуальны • Непроверяемы • Написаны ужасным языком • Противоречат друг другу • Неприменимы для конкретного приложения
11. Заголовок Всё должны делать только разработчики или только ИБ Миф #6 Разработка • Мы ничего не понимаем в ИБ, ничего не будем делать • У меня в KPI такого не написано • Вы заварили процесс, вы и управляйте • Мы отвечаем за продукт, а не за безопасность ИБ • Мы в вашем коде не разбираемся, сами анализируйте всё • Мы вам уязвимости нашли, устраняйте • Мы процесс запустили, а вы должны ему соответствовать • Мы за безопасность отвечаем, что вы там напрограммировали, нас не касается
12. Заголовок Внешняя компания сама построит процесс Миф #7 Причины: • Экспертизы нет и не будет • Людей нет и не будет • Мы людей научим, а они уйдут • Внешняя компания построит нам весь процесс, а мы потом им пользоваться будем Следствие: • Внешний подрядчик не вечен • Если не развивать внутреннюю экспертизу, перенимать процесс будет некому • Кто будет контролировать? Возможное решение: • Комплексный подход, разделение полномочий • Необходим внутренний «драйвер» инициативы, отвечающий за успех начинания в целом • Внешняя экспертиза может хорошо помочь на старте • Перенимать опыт и растить экспертизу • Оставить рутинные \ затратные операции на подрядчика
13. Заголовок Запустив процесс его не нужно контролировать - Процесс запущен, он работает! - А как работает? - Хорошо работает! Ура, процесс безопасной разработки идёт полным ходом: • Код сканируется • Приложения тестируются • Отчёты отправляются • Что ещё нужно? Миф #8
14. Заголовок А как всё-таки правильно подойти к построению процесса? Нет решения, которое подошло бы всем, каждая компания уникальна. Есть несколько советов, как избежать ключевых ошибок и построить работающий процесс Reliable software does what it is supposed to do. Secure software does what it is supposed to do, and nothing else.
15. Заголовок Подходы к построению бывают разные OWASP OpenSAMM СТО БР ИББС BSIMM Что же выбрать?
16. Заголовок BSIMM ДОМЕН >>> НАПРАВЛЕНИЕ >>> АКТИВНОСТЬ 4 12 112 УРОВНИ ЗРЕЛОСТИ 3
17. Заголовок BSIMM • Governance Группа практик, которые отвечают за организацию, управление и оценку эффективности инициативы Application Security; • Intelligence Группа практик, которые отвечают за сбор и консолидацию знаний в области ИБ внутри организации для реализации всех задач внедрения и тиражирования практик разработки защищенного ПО в полном объеме; • SSDL Touchpoints Группа практик, отвечающих за анализ и оценку конкретных артефактов и процессов в рамках производства ПО; • Deployment Группа практик, которые отвечают за взаимодействие с подразделениями сетевой и инфраструктурной безопасности и службами технической поддержки.
18. Заголовок Но ведь это процесс безопасной разработки * Найди 10 отличий (или Уолли) VS
19. Заголовок Agile manifest == Security Manifest ?
20. Заголовок Agile manifest == Security Manifest ?
21. Заголовок Agile manifest == Security Manifest ?
22. Заголовок Agile manifest == Security Manifest ?
23. Заголовок Agile manifest == Security Manifest ?
24. Заголовок Разговаривайте с разработкой на их языке Стоп фразы, которые должен знать забыть каждый: • «Я вам отправил PDF-отчёт» • «Я письмо с уязвимостями отправлял, вы всё исправили?» • «Пока всё не исправите, в релиз не пустим!» • «Наши дефекты имеют наивысший приоритет!» • «А мы Вам требования выставляли ещё год назад, они на общем диске лежат» Полезные советы: • Для отображения информации используйте удобные для всех сервисы. • Актуализируйте требования и выставляйте только применимые для конкретного приложения • Используйте те же системы дефект-трекинга, что и разработка, так будет удобнее всем. • Не нужно сразу отправлять разработчикам все найденные баги без разбора • Сформируйте технический долг, который будете разбирать постепенно, сообщайте только о новых уязвимостях
25. Заголовок Разговаривайте с разработкой на их языке Not all Software Quality issues are AppSec issues. But all AppSec issues are Software Quality issues. Sherif Mansour, Expedia Дефекты безопасности ничем не отличаются от функциональных дефектов. Исправляться они должны согласно выставленным приоритетам наравне с остальными дефектами.
26. Заголовок А почему бы не делать процесс вместе? • Включайтесь в процесс разработки вместе с разработчиками • Инкрементальное сканирование • Повышение скорости сканирования • Возможность встраивания в процесс не замедляя разработку (например на пулл реквесты) • Используйте инструментарий и наработки разработчиков • Максимально автоматизируйте всё, что можно автоматизировать
27. Заголовок Application Security – это совместная работа Разработка + ИБ = 1 love • Качество продукта – общая цель • Одна сторона без помощи другой хороших результатов не получит • У сотрудников ИБ свои знания, у разработчиков – свои, помогайте друг-другу • Проводите семинары, обучение, совместные тренинги • Делайте новостные рассылки с интересными материалами • Вооружите разработчиков гайдлайнами • Не держите в себе экспертизу, делитесь Любой процесс – это совместная работа
28. Заголовок Каждый процесс нуждается в контроле Для понимания, как работает процесс и где его нужно улучшить: • Производственные метрики • Метрики с инструментов • Метрики из дефект-трекеров • обеспечение полной прозрачности процесса для всех участников в полностью автоматическом режиме. • Статистика по практикам и их применению • Любые данные могут быть полезны • Но не просто данные ради данных, а метрики - ради метрик Чем больше данных, тем больше разрезов можно построить. От верхнеуровневых, до деталей каждого процесса
29. Заголовок Краткие итоги • Важнее люди, а не инструменты  Не нужно сразу покупать дорогие инструменты и потом под них пытаться сделать процесс • Перед началом, опишите цели и продумайте стратегию развития • Опишите процесс, как он будет устроен, обсудите с потенциальными участниками • Начните с того, что уже есть:  Приведите в порядок требования  Создайте портал, где будет вся необходима информация в доступном и понятном виде  Проведите обучение разработчиков, вовлеките их в процесс  Вооружите разработчиков знаниями (гайдлайны по безопасной разработке, семинары) • Не обязательно делать всё сразу для всех систем, выберите несколько команд • После того, как разработчики будут лучше понимать, что такое AppSec, можно идти дальше
30. Заголовок Краткие итоги • Используйте инструменты, которые уже используют разработчики • Витрина данных • Дефект-трекеры • Системы сборки • Автотесты • Интегрируйтесь в процесс разработки, используйте подходы разработки • Максимально автоматизируйте проверки • Добавьте проверки безопасности в обычные тест-кейсы тестировщиков • Дефекты безопасности = функциональные дефекты • Контроллируйте и управляйте процессом безопасной разработки
31. Заголовок ptsecurity.com Спасибо! Спасибо!