Безопасная разработка приложений на практике
- 1. Разработка безопасных приложений на практике Второй Евразийский CIO Конгресс
- 2. О чем будем говорить • Кому нужна разработка безопасных приложений • Выгоды от разработки безопасных приложений • Основные этапы разработки безопасных приложений • Разработка безопасных приложений на основе Microsoft SDL • Как быстро начать внедрять Security Development Lifecycle • Демонстрация инструментов разработки безопасных приложений www.pointlane.ru 2
- 3. Почему именно разработка безопасного ПО? • Облака, виртуализация • Статистика из практики тестов на проникновение • 4 из 10 web приложений с доступом из Internet содержат уязвимости уровня high priority • 7 из 10 приложений в корпоративных сетях содержат уязвимости уровня high priority и critical Вывод: надо бороться с причиной, а не со следствием www.pointlane.ru 3
- 4. Кому нужна безопасная разработка • Компании профессионально занимающиеся разработкой программного обеспечения • Руководители ИТ в крупных компаниях, поддерживающих и развивающих собственные приложения • Спросите российских вендоров: разрабатывают ли они безопасное ПО и как они это делают? • Проектным командам, разрабатывающим продукт или решения в рамках проекта www.pointlane.ru 4
- 5. Стратегии разработки • «Найти и обезвредить» • Сканирование приложений на уязвимости • Тестирование на проникновение • «Защитить и отложить» • Использование WAF, application-level proxy • Изначально безопасная разработка • Интеграция инструментов и практик в жизненный цикл разработки ПО www.pointlane.ru 5
- 6. Стратегии разработки Источник: Aberdeen Group www.pointlane.ru 6
- 7. Выгоды от разработки безопасного ПО Относительная стоимость устранения • Расходы на команду 30 ошибок (разработчики, Выпуск 25 администраторы, тестировщики) в ходе 20 устранения ошибок 15 (уязвимостей) 10 • Потеря производительности 5 бизнес-подразделений 0 Требования/ Интеграция/ Финальное После Кодирование Архитектура Тестирование тестирование выпуска компонент Источник: National Institute of Standards and Technology www.pointlane.ru 7
- 8. Что говорят аналитики • Исследование Aberdeen: • Предотвращение одной уязвимости почти полностью покрывает годовые затраты на повышение безопасности разработки • Предотвратить проблему с безопасностью в 4 раза дешевле чем разбираться с ее последствиями • Исследование Forrester: • Разработка безопасного ПО еще не стала широко распространенной практикой • Компании применяющие методы SDL демонстрируют гораздо более быстрый возврат инвестиций www.pointlane.ru 8
- 9. Выход в облака: OWASP Top 10 threats • Injections • Cross-site scripting • Authentication and session management • Direct object references • Cross-site request forgery • Security misconfiguration • Insecure cryptographic storage • Failure to restrict URL access • Insufficient transport layer protection • Invalidated redirects and forwards www.pointlane.ru 9
- 10. История Microsoft SDL Процесс безопасной разработки прошел многолетнее тестирование и шлифовку в рамках Microsoft и других компаний. www.pointlane.ru 10
- 11. Этапы применения SDL SDL – обязательная политика в Майкрософт с 2004 г. Обуче Требо Проекти Реали Провер Реагиро Выпуск ние вания рование зация ка вание Начальное Определение Моделирован Выбор Динамическое План Выполнение владельца от ие угроз инструментов тестирование реагирования плана обучение бизнеса и fuzzing Анализ Блокирование Заключитель- реагирования по основам Анализ рисков опасных запрещенных Проверка ный анализ на инциденты безопасност безопасности областей функций моделей угроз безопасности и и конфиден- Статический и опасных Архив циальности анализ областей выпусков Определение требований к качеству Обучение Технология и процесс Ответственность Постоянные улучшения процессов www.pointlane.ru 11
- 12. Фаза: обучение Проекти Реали Реагирова Обучение Training Requirements Требования Design Implementation Verification Проверка Release Выпуск Response рование зация ние Обследовать подготовленность организации по темам безопасности и защиты данных. При необходимости (то есть в любом случае!) создать стандартные курсы обучения. • Разработать критерии качества программы обучения • Содержимое должно покрывать темы безопасного дизайна, разработки, тестирования и защиты данных • Определить частоту тренингов • Разработчик должен пройти не менее n тренингов в год • Определить минимальный приемлемый порог тренингов в группе разработки • 80% процентов технического персонала должны пройти минимальные обязательные тренинги до выпуска RTM версии продукта www.pointlane.ru 12
- 13. Источники для обучения Как написать безопасный код на С++, Java, Perl, PHP, ASP. NET Защищенный код для Windows Vista Игра «Spot the vuln» 10 уязвимостей веб проектов - OWASP Top Ten Курсы SANS Книга по SDL Упрощенный SDL www.pointlane.ru 13
- 14. Фаза: Требования Проекти Реали Реагирова Обучение Training Requirements Требования Design Implementation Verification Проверка Release Выпуск Response рование зация ние Возможность заложить безопасный фундамент для проекта • Команда разработки определяет лидеров и консультантов по темам безопасности • Назначается ответственный за безопасность • Ответственный проверяет план разработки продукта, рекомендует изменения или устанавливает дополнительные требования к безопасности продукта • Определить приоритет, процедуру отслеживания и исправления ошибок (bug tracking/job assignment system) • Определить и задокументировать порог отбраковки продукта по ошибкам связанным с безопасностью и защитой данных www.pointlane.ru 14
- 15. Фаза: Проектирование Проекти Реали Реагирова Обучение Training Requirements Требования Design Implementation Verification Проверка Release Выпуск Response рование зация ние Определить и задокументировать архитектуру безопасности и идентифицировать критические компоненты безопасности • Минимизировать поверхность атаки. • Ограничить ее установками по умолчанию (отключить ненужные сервисы, использовать принцип минимальных привилегий • Определить критерии выпуска обновления продукта в связи с изменением в безопасности продукта • Результаты автоматизированного тестирования атак • Устаревание криптографических алгоритмов или замена слабых алгоритмов • Моделирование угроз • Систематический анализ свойств продукта и его архитектуры с точки зрения безопасности • Определить угрозы и меры снижения угроз www.pointlane.ru 15
- 16. Моделирование угроз • Продумать требования к безопасности продукта, сценарии Spoofing использования. Tampering • Идентифицировать Repudiation классы пользователей. Denial of Service • Ожидаемое поведение.of privilege Elevation www.pointlane.ru 16
- 17. SDL Threat Modeling Tool • Обучает созданию диаграмм угроз • Анализ угроз и мер защиты • Интеграция с багтреккером • Отчеты по угрозам и уязвимостям Формализует и упрощает моделирование угроз так чтобы им мог заниматься архитектор www.pointlane.ru 17
- 18. Фаза: Реализация Проекти Реали Реагирова Обучение Training Requirements Требования Design Implementation Verification Проверка Release Выпуск Response рование зация ние Разработка кода и ревью процессов, документации и инструментов необходимых для безопасного развертывания и эксплуатации разрабатываемого продукта Спецификация утвержденных инструментов и их аналогов Статический анализ (/analyze (PREfast), FXCop, CAT.NET) Поиск случаев использования запрещенных API Применение механизмов защиты предоставляемых ОС (NX, ASLR и HeapTermination) Соблюдение специфических требований безопасности для сетевых сервисов (крос сайт скриптинг , SQL иньекции и.т.д) Использование безопасных версий библиотек и фреймворков Прочие рекомендации ( Standard Annotation Language (SAL)) www.pointlane.ru 18
- 19. Фаза: Проверка - Инструменты BinScope Binary Analyzer • Убедиться что SDL соблюден при компиляции и сборке MiniFuzz File Fuzzer • !exploitable RegexFuzer Attack Surface Analyzer • Анализ снимков системы AppVerifier • Динамический анализ системы www.pointlane.ru 19
- 20. Фаза: Проверка Проекти Реали Реагирова Обучение Training Requirements Требования Design Implementation Verification Проверка Release Выпуск Response рование зация ние Начните проверки как можно раньше. В идеале сразу же после стадии “code complete”. Начните планирование процесса реагирования на обнаружение уязвимостей в выпущенном продукте Повторно проверьте поверхность атаки. Все ли вы учли? MiniFuzz тестирование – файлами, вводом данных в интерфейсные элементы и код сетевой подсистемы При необходимости выполнить “security push” (с каждым разом все реже) Не является заменой работе над безопасностью в процессе разработки продукта Ревью кода Тестирование на проникновение Ревью дизайна и архитектуры в свете вновь обнаруженных угроз www.pointlane.ru 20
- 21. Фаза: Выпуск и план реагирования Проекти Реали Реагирова Обучение Training Requirements Требования Design Implementation Verification Проверка Release Выпуск Response рование зация ние Создать политики поддержки продукта Создать план реагирования на инциденты безопасности - Software Security Incident Response Plan (SSIRP) Контакты и ресурсы внутри организации для адекватной реакции на обнаружение уязвимостей и защиту от атак 24x7x365 контакт с 3-5 инженерами, 3-5 специалистами маркетинга, и 1-2 менеджеров верхнего уровня Обратите внимание на необходимость выпуска экстренных обновлений вашего продукта из за уязвимостей в коде сторонних производителей включенном в ваш продукт. Так же может быть необходимость обновлять продукт после обновления ОС. www.pointlane.ru 21
- 22. Фаза: Выпуск – Final Security Review (FSR) Проекти Реали Реагирова Обучение Training Requirements Требования Design Implementation Verification Проверка Release Выпуск Response рование зация ние Проверить продукт на соответствие требованиям SDL и отсутствие известных уязвимостей Получаем независимое заключение готовности продукта к выпуску FSR не является: Тестом на проникновение. Запрещено ломать и обновлять продукт. Первой проверкой безопасности продукта Процессом финальной подписи продукта и отправки его в тираж Ключевая концепция: Эта фаза не используется как точка для завершения всех задач пропущенных на предыдущих стадиях www.pointlane.ru 22
- 23. Фаза: Выпуск – Архив Проекти Реали Реагирова Обучение Training Requirements Требования Design Implementation Verification Проверка Release Выпуск Response рование зация ние План реагирования на инциденты безопасности создан Документация для клиентов обновлена Создан централизованный архив исходного кода, символов, моделей атак RTM версии продукта www.pointlane.ru 23
- 24. Фаза: Реагирование Проекти Реали Реагирова Обучение Training Requirements Требования Design Implementation Verification Проверка Release Выпуск Response рование зация ние Инцидент случился? Идем по заранее созданному плану. Выполняем активности по плану реагирования на инциденты безопасности и выпускаем обновления в соответствии с графиком релизов www.pointlane.ru 24
- 25. Что можно сделать уже сейчас • Создать каталог приложений • Не забываем про EUC • Произвести оценку рисков • Критичность для бизнеса • Обрабатываемая информация • Закрепить ответственность • В целом за безопасную разработку • Собственники и потребители приложений • Определиться и четко следовать стратегии www.pointlane.ru 25
- 26. Что можно сделать уже сейчас • Провести хотя бы минимальное обучение для разработчиков • Code review • Static/dynamic analysis • Banned functions repository • Manual/automated pentest • Fuzzing • Создать и поддерживать прозрачный и открытый диалог между IT и ИБ • Комитет по безопасной разработке в рамках комитета по ИТ/ИБ • Постоянный мониторинг и контроль KPI по приложениям www.pointlane.ru 26
- 27. Где найти больше информации www.microsoft.com/sdl www.Secunia.org The Simplified Implementation of the SDL Блог об SDL www.pointlane.ru 27
- 28. Спасибо за внимание! Компания «Pointlane» Москва, ул. Ильинка, д 4 Тел +7 (495) 233-65-08 consult@pointlane.ru www.pointlane.ru www.pointlane.ru 28