Презентация Павла Мельникова для второго конгресса директоров по информационным технологиям.

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