опубликовано: 18.11.2018
Суть: хотим предотвращать появление уязвимостей, а не обнаруживать их. Для этого разработчикам можно дать инструменты сканирования.
Безопасность приложений. Тестируем приложения, интегрируемся с разработкой. Мы хотим предотвратить появление уязвимостей, а не обнаружить их.
Существующие подходы: OWASP, BSIMM, OpenSAMM. Рекомендуемый: BSIMM
Как сейчас: безопасность это контролирующий орган, который всех пинает в конце релиза. Проблемы:
Можно купить кучу инструментов безопасности, вывалить кучу уязвимостей, но это не поможет. Нужен процесс.
ИБ должны использовать те же инструменты, что и разработчики: чаты, документация и т.п. Security Champions.
Чувак в команде, который заинтересован в обеспечении безопасности. Т.е. Это разработчик, который работает с инструментами ИБ, консультирует команду об ИБ, проводить код-ревью и тренинги.
Анализ кода на наличие уязвимостей, анализ паттернов, датафлоу, анализ конфигураций. Такое сканирование занимает кучу времени, высокий уровень False Nagative/False Positive.
Инструменты: PVS-Stidio, Chechmarx, veracode, incode, fortify, coverity, positive technologies
Есть OpenSource решения под конкретные языки, на них можно обкатывать процесс. Интегрировать решение на PR, делать инкрементальные сканы. Запретить мердж, если тест не пройден. Отправлять отчет в SonarQube. Интеграция в CI. Бежит после тестов.
Нельзя после первого скана требовать исправление всего что нашли! Сформируйте технический долг и постепенно его разбирайте.
Все сканы всегда по дельте, чтобы на разработчика не вывались фиксирует по всему проекту.
Анализ используемых библиотек на уязвимости в открытых и закрытых источниках Анализ лицензии Контроль библиотек в периметре организации. По определенным политикам мы можем отсечь использованные библиотеки. Например, отсекать все что с критикал уязвимостью. Мониторинг новых уязвимостей в компонентах
Инструменты: Sonatype Nexus, Source Clear, BlackDuck, Dependency-check, WhiteSource
Интеграция. В CI как этап тестирования, запрет сборки, если там есть критичные баги или запрет деплить в прод. Интеграция в среду разработки, чтобы знать об уязвимостях до коммита. Мониторим что у нас в проде(Nexus IQ).
Анализ уже собранного и развернутого приложения. Имитирует работу пользователя, анализирует ответы приложения. Поиск известных уязвимостей. Fuzzing. Проверка конфигурации сервера.
Риски: высокая нагрузка на сервер, нет интеграций, возможность изменения настроек аналитики, отсутствие поддержки технологий, сложность.
Инструменты: Burpsuite, appscan, acunetix, w3af, owasp, microfocus
Интеграция: в CD после установки на стенд. Идеально иметь отдельный стенд для тестирования. До начала тестирования необх записать послед логина. Наличие уязвимостей — не стоппер.
Тоже самое, что и просто баги. У критичности есть ранжирование по критичности, как и у багов, это позволяет их приоретизировать в одном беклоге, т.к. с точки зрения качества ПО они идентичны.
Надо собирать метрички(производственные, инструментов, дефект-трекеры)
Нужна помощь? Напиши мне в telegram @aladmit или на почту [email protected]