О чем статья
Чем ProdSec отличается от AppSec и DevSecOps? Возможны ли они в отрыве друг от друга и что нужно именно вам?
После выхода статьи про безопасную разработку мне задали справедливый вопрос: «Может ли AppSec существовать отдельно от DevSecOps и наоборот?» Уже тогда я поняла: новой статье быть! Но с тех пор, кажется, случился новый виток эволюции — теперь все говорят о Product Security и пытаются понять, чем это понятие отличается от уже привычных AppSec и DevSecOps. Давайте разбираться, как все-таки правильно «по понятиям» :)
Помню, как в 2019 г. впервые столкнулась с безопасной разработкой. Начала гуглить, наткнулась на SAST, а потом и на BSIMM. Тогда я использовала его исключительно для прохождения PCI DSS, но визуальная составляющая фреймворка меня сразу поразила.
Я не суперфанат BSIMM, но часто вспоминаю его (как некоторые Римскую империю), поэтому не могу не упомянуть :) Кроме того, мы использовали его в качестве одного из референсов при построении собственной методологии — вместе с OWASP SAMM, BSA SSF и еще кипой того, что называется best practices. Да, российские стандарты (ГОСТ 56939, Профиль защиты от Центробанка и др.) мы, конечно, тоже смотрели — мы вообще compliance first :) Но пошли другим путем: мы ориентированы на процесс разработки и отталкиваемся от этапов жизненного цикла
DevSecOps
Уже из названия становится понятно, что DevSecOps — это «продвинутый» брат DevOps, и родился он путем добавления безопасности (Security) к блокам Development и Operations.
Главное не забывать, что DevSecOps — это не только безопасность, но и автоматизация, которая позволяет оптимизировать трудозатраты и экономить деньги. Да-да, вспоминаем экономическую теорию третьего курса: «расчет и сокращение затрат на избыточные процессы».
Мои коллеги по цеху говорят: все, что можем, — автоматизируем, а что не можем — нам не надо :)
В качестве примера представим компанию, которая решила внедрить DevSecOps:
- закупила инструменты;
- взяла OWASP SAMM и BSIMM;
- реализовала общий пайплайн разработки для всей компании;
- наладила релизный цикл;
- интегрировала сканеры в пайплайн (они автоматически сканируют код при новых PR).
Живут не тужат, разбирают себе уязвимости. После каждого скана эксперты смотрят результаты и принимают решение по PR.
Это уже DevSecOps? Пока нет, но это движение в правильном направлении!
Автосканирование с настроенными триггерами и общий пайплайн это хорошо, но для полного счастья не хватает автоматической верификации. Станет намного лучше, когда компания реализует quality gates (для блокировки движения подозрительных артефактов по пайплайну) и автоматизирует разметку обнаружений.
Application Security
AppSec — великий, но вовсе не ужасный. То, что принято называть безопасностью приложений или безопасной разработкой.
Безопасная разработка включает больше активностей, чем DevSecOps: инструменты анализа, обучение, управление разработкой и т. д. Однако AppSec не требует обязательной автоматизации: ИБ-практики можно внедрить даже в классическую водопадную модель. Сами методы тестирования в этом случае не так важны, главное — правильная последовательность и полнота проверки (код, библиотеки и все компоненты).
Большая часть AppSec-фреймворков и стандартов описывают, как и куда нужно добавлять безопасность, кто должен отвечать за отдельные задачи и т. д. Хороший пример — Профиль защиты ЦБ РФ от 10.02.2022. Кстати, все схемы в нем описаны именно в логике жизненного цикла разработки.
Product Security
Невиданный доселе зверь :) ProdSec — понятие более широкое, чем DevSecOps и AppSec. В него входят:
- Физическая защита. Нет, драться ни с кем не придется, а вот продумать безопасность среды функционирования — да.
- Защита виртуализации или Cloud Security.
- Безопасность эндпоинтов («Нужно ли нам защищать машину разработчика?»).
Плюсуем к списку Hardware Security, управление изменениями, патчинг, настройку и эксплуатацию WAF, моделирование угроз, харденинг инфраструктуры и т. д. В итоге получаем следующую схему (см. рис. 3).
В DevSecOps мы ждем помощи от DevOps-специалистов. В Application Security делаем акцент (по привычке) на безопасном коде, за который отвечают разработчики. А в ProdSec нас ждет к-к-к-комбо из этих и новых ролей. Например, сетевой инженер поможет нам с безопасностью инфраструктуры, а DataOps — с шифрованием и безопасностью данных
Собираем пазл
Теперь посмотрим, как ProdSec, AppSec и DevSecOps соотносятся друг с другом (см. рис. 4).
Проще говоря, в идеальном мире безопасность продукта должна расти из безопасности приложения, а она, в свою очередь, — из безопасности и автоматизации разработки. Почти сказка про Кощея, утку, зайца и яйцо :)
А теперь самый интересный вопрос: что из этого нужно именно вам?
Нужна ли всем компаниям Product Security? Определенно да, пусть и не все ее аспекты. А DevSecOps? Не сказала бы... Если у вас мало девелоперов (да и разработки в целом), а релизы выходят редко, зачем вам автоматизация? Разве что «потому что это прикольно» :) А о потенциальной выгоде от внедрения AppSec мы даже выпустили отдельную статью.
В общем, звучит как очередная дилемма... Возможно, мы и нашу методологию скоро доработаем до полноценного ProdSec подхода ;-)
Как так получилось, что понятия ProdSec, AppSec и DevSecOps на рынке есть, а единого мнения о них нет? Думаю, дело в том, что они возникли в разное время:
- DevOps появился в нулевых, а DevSecOps обрел популярность в 2010-х.
- Application Security в нынешней ипостаси существует с 2005 г. (с момента, когда Microsoft представила SSDLC).
- О Product Security начали говорить еще в 2018 г., но в текущем понимании термин сформировался только в 2023-м
А что дальше?
На одном из мероприятий Positive Technologies в Минске мы обсуждали, куда дальше может развиваться безопасная разработка. Ведь совершенству нет предела, как и мастерству злоумышленников — даже при наличии всех возможных проверок и каноничных стандартов слепые зоны будут всегда.
Простой пример: медленное реагирование на проблемы в поведении приложения. Предположим, у вас просто нет мониторинга, с помощью которого можно было бы отслеживать корреляцию превышения нагрузки и уменьшения числа пользователей. А может, логи пишутся не слишком исчерпывающе. Или, наоборот, они настолько объемные, что поймать что-то ценное практически невозможно. Уже понимаете, к чему я клоню?
Безопасную разработку можно подружить с SOC, тем более все привыкли работать с WAF и runtime container security. Это ведь и есть мониторинг (и почти реагирование), так почему бы не попробовать? Можно даже настроить в SOC оповещения о неисправленных уязвимостях, чтобы у сотрудников центра было больше информации в кризисных ситуациях. Даже схема есть подходящая (см. рис. 5): вроде бы все очевидно, а реализуется редко.
Другой важный момент: нужно активнее привлекать разработчиков к безопасной разработке. Звучит как масло масляное, но пока ваш код похож на решето, нет смысла рассуждать о ProdSec, AppSec или DevSecOps. Мы в качестве эксперимента ставим разработчикам в IDE плагины, которые помогают исправлять код на ранних этапах без привлечения AppSec. Такие инструменты подходят даже компаниям, которые не хотят или не могут внедрить полноценный DevSecOps. Более того, их можно использовать хоть для пет-проектов — культура разработки в любом случае будет повышаться.
Насчет плагинов: вы же помните, что они у нас есть, и они бесплатные? Как-нибудь обязательно расскажем в цифрах, сколько ресурсов можно сберечь с их помощью ;)
В общем, развивать безопасность приложений нужно сразу в двух направлениях — главное, как говорится, не порвать :) С одной стороны, важно идти к безопасности и SOC, с другой — минимизировать количество уязвимостей уже во время написания кода. Звучит немного утопично, но мы же хотим делать качественные продукты, правда?
И помните: безопасность — это всегда про качество!
