Всем привет! Меня зовут Артём Пузанков, я DevSecOps-инженер в департаменте защиты приложений VK. Хочу рассказать о том, зачем команде разработчиков нужны Security Champions и чем они отличаются от AppSec-аналитиков.

Немного истории, или Что такое «безопасный SDLC»

Впервые о роли Security Champions заговорили в контексте безопасной разработки ПО, а точнее, в процессе формирования концепции «безопасного SDLC». Но обо всём по порядку.

Безопасность приложений (Application Security) охватывает широкий спектр инструментов и методологий, но все они преследуют одну и ту же цель: выявить слабые места (уязвимости) и исправить их до того, как они будут использованы злоумышленником. Причём на протяжении всего жизненного цикла (SDL/SDLC, или Software Development Lifecycle), — а это последовательность этапов от анализа требований, планирования, проектирования и дизайна до непосредственной разработки ПО, тестирования и развёртывания. 

Первоначально концепция SDLC рассматривала обеспечение безопасности как задачу, выполняемую в рамках этапа тестирования. Но недостаток такого подхода — это позднее, «постфактумное» обнаружение уязвимостей и ошибок.

Сегодня очевидно, что интеграция требований безопасности на каждом этапе SDLC помогает  обнаруживать и устранять уязвимости раньше, сводя к минимуму длительность процесса и уменьшая количество дорогостоящих исправлений на более поздних этапах разработки (привет концепции Shift Left). Поэтому идея об оценке безопасности на всех этапах разработки ПО (тестирование на проникновение, моделирование угроз, проверка кода, анализ архитектуры и т.д.) быстро завоевала популярность и признание в индустрии и получила название Secure SDLC/SSDLC, или «безопасный SDLC». 

Основные преимущества применения SSDLC-подхода:

• Безопасность приложения контролируется на всех этапах его жизненного цикла.

• Заинтересованные стороны осведомлены о функциях безопасности.

• Раннее обнаружение дефектов.

• Снижение затрат и рисков благодаря раннему выявлению и решению проблем.

Глубоко детализированный SDLC, хоть и не в своём первозданном виде, рассматривается в методологиях таких мастодонтов, как OWASP SAMM, BSIMM, OpenSAMM. 

Итак, важность оценки безопасности на всех этапах осознали, подход к процессу определили, но возникает вопрос: кто это будет делать? И именно в этот момент врывается идея, практика, программа, концепция Security Champions.

Кто такие Security Champions? 

Специалистов по информационной безопасности, как правило, не хватает в команде, поэтому хороший способ для продвижения культуры ИБ — это задействовать Security Champions.

Обычно так называют сотрудников команды разработки, выступающих в интересах группы ИБ. Они участвуют в повседневной разработке, понимают цели, процессы и особенности команды. Чемпионами могут быть QA, проект-менеджеры, разработчики — кто угодно, лишь бы сотрудник «радел» за безопасность. Чемпионы выступают в качестве «точки входа», «мостика» к безопасности приложений для своей команды.

В методологиях различных компаний говорится, что Security Champions — это ключевой элемент повышения зрелости безопасной разработки ПО в компании. Они помогают внедрять лучшие практики ИБ на ранних этапах SDLC, улучшая дальнейшее взаимодействие между командами разработчиков и ИБ-подразделениями. А поскольку «чемпионы» являются частью команд разработки, они лучше знают свой продукт, и им легче понять, как удовлетворить требованиям безопасности без ущерба бизнесу и технологиям.

Примерная ролевая модель может выглядеть так:

Экспертная группа команды ИБ обменивается с Security Champion информацией для выполнения поставленных задач, а он транслирует все рекомендации команде разработки.

 Какие функции выполняет Security Champion?

• Отвечает за запуск и ежедневное сопровождение практик разработки защищённого ПО в своей команде.

• Инициирует анализ защищённости ПО при помощи инструментов SAST, DAST, mDAST, IAST, SCA, CA.

• По результатам анализа фиксирует идентифицированные уязвимости и дефекты программного обеспечения. Даёт рекомендации по их исправлению, консультирует свою проектную команду.

• Регулярно анализирует дефекты технического долга ИБ.

• Проверяет код и документацию на предмет следования руководствам по разработке защищённого ПО.

• Отвечает за формирование единого информационного пространства между командой разработки и отделом безопасности разработки.

Как выглядит процесс взаимодействия между командами AppSec (ИБ) и Dev (разработка) при наличии Security Champion:

Но что делать, если в команде разработки нет желающих стать Security Champion или никто не разбирается в ИБ? На помощь может прийти AppSec-аналитик из команды ИБ.

А зачем нужен AppSec-аналитик?

Это сотрудник команды ИБ с более глубокими знаниями, формирующий требования к безопасности продукта. Основные функции AppSec-аналитика:

1. Внедрение практик безопасной разработки ПО совместно с командами разработки. Руководствуется регламентами и условиями, соответствующими критичности приложений, систем и сервисов.

2. Экспертная поддержка. Разрабатывает практики, стандарты безопасного проектирования и разработки для дальнейшего внедрения. Обучает разработчиков практикам обеспечения безопасности приложений. Разрабатывает ролевые тренинги и программы осведомлённости для различных профилей сотрудников.

3. Анализ соответствия требований ИБ. Анализ регуляторных требований, тестирование и анализ продукта на соответствие требованиям ИБ. 

4. Анализ защищённости ПО:

• Анализирует отчётность по выявленным уязвимостям, готовит рекомендации для разработчиков по доработке и оптимизации ПО. Принимает решения по статусу дефектов.

• Контролирует архитектуру разрабатываемых систем, приложений и сервисов с точки зрения угроз информационной безопасности и их минимизации.

• Анализирует, соответствуют ли бизнес-требования, системные требования, архитектура систем и технические решения практикам построения защищённых приложений. Разрабатывает модель угроз (при необходимости), отвечает за приоритеты при анализе защищённости.

Итак, резюмируя, AppSec-аналитик совместно с командой внедряет практики безопасной разработки, оказывает экспертную поддержку, контролирует соблюдение требований регулятора, коммуницирует с командой разработки, а если у неё остались вопросы, то AppSec-аналитик даст рекомендации. Прямо человек-оркестр от команды ИБ!

Осталось только выбрать сотрудника из команды разработки, который будет:

• контролировать внедрение и сопровождение практик разработки защищённого ПО в команде;

• регулярно анализировать дефекты в back-log’e;

• отвечать за эффективную коммуникацию между командой разработки и командой ИБ.

Тогда процесс взаимодействия между командами AppSec (ИБ) и Dev (разработка) при наличии AppSec-аналитика будет выглядеть так:

Заключение

Практика Security Champion непроста во внедрении и не гарантирует моментального выхода безопасной разработки на новый уровень, но в долгосрочной перспективе она приносит только пользу. Такая «плавная» интеграция команды разработки со специалистами ИБ позволит ускорить производство, повысить качество разрабатываемого ПО, а также развить культуру безопасности среди сотрудников. Начинайте с малого и попробуйте внедрить практику в одной-двух лояльных командах разработчиков, оцените эффективность, и при положительном эффекте тиражируйте на бОльшее количество команд. 

Привлекая AppSec-аналитика к процессам команды разработки, можно добиться повышения безопасности на каждом этапе жизненного цикла разработки ПО, но такой подход требует привлечения в компанию большого количества экспертов. 

К тому же, Security Champion лучше понимает особенности продукта, а потому вызывает больше доверия у разработчиков, чем профильный ИБ-специалист. Указание на уязвимость и рекомендации воспринимаются понятнее и легче от «своих». Сотрудник команды ИБ даже при большом желании не сможет моментально погрузиться в проект и понять все особенности продукта так, как это сделает разработчик. 

Но у внедрения практики Security Champion есть и обратная сторона: необходимо отвлекаться на срочные задачи в рамках основного профиля работы, возникают конфликты интересов. Так как Security Champion является частью команды разработки, на него в первую очередь будут влиять продуктовые метрики и сроки внедрения новых функций и продуктов. Устранение же дефектов в информационной безопасности может противоречить им.

Подводя итог, скажу так: идея Security Champions — это про дополнительные бонусы, которые получит организация, развивая культуру безопасности изнутри. Это про отношение сотрудников к вопросам безопасности как к важным задачам, а не ограничениям и требованиям команды ИБ. Но внедрение этой практики напрямую связано со зрелостью команды продукта и их вниманием к безопасности. Конечно, концепция Security Champions гораздо шире того, что я описал, поэтому планирую через некоторое время вернуться с продолжением и расскажу о подходах к мотивации и обучению, а также о реализации базы знаний ИБ.