Привет! Меня зовут Екатерина Пухарева, работаю в Авито руководителем продуктовой безопасности. В компанию я пришла в начале 2024 года и одной из первых задач стало внедрение пилотного проекта инициативы бизнес-партнёров по информационной безопасности — Security BP. В этой статьей рассказываю, как это было.
Эта статья будет полезна тем, кто размышляет, стоит ли внедрять роль бизнес-партнёра по безопасности. В ней мы разберём, какую ценность эта роль приносит компании и чем она отличается от security champions.
Что внутри статьи:
Проблематика
Перед запуском пилота мы столкнулись с рядом сложностей, которые требовали оперативного решения. Командам разработки явно не хватало экспертизы в области информационной безопасности для качественной оценки рисков и проведения анализа защищенности продуктов. При этом core-команда продуктовой безопасности (AppSec)* была перегружена, что увеличивало риск пропуска критических уязвимостей.
*Core-команда продуктовой безопасности (AppSec) — команда, которая занимается процессом безопасной разработки, включающим в себя статический и динамический анализ приложений, поиск секретов и персональных данных, анализ зависимостей и множество других решений для быстрого обнаружения проблем.
Хотя в Авито уже были Security Champions*, их усилий не хватало для масштабирования деятельности core-команды. Тем более ребята — прежде всего разработчики и не могут давать комитменты по задачам безопасности.
*Security Champions — разработчики, которые заинтересованы в тематике безопасности. Наши security champions помогают командам в моделировании угроз, прохождению регулярных оценок рисков.
Основной целью пилота было снижение рисков и повышение уровня безопасности продуктов Авито за счёт более тесного и эффективного взаимодействия между продуктовыми командами и командой безопасности, чтобы обе стороны выиграли от сотрудничества.
Когда стоит идти в Sec BP?
Когда у вас несколько разных бизнесов в одной компании. Например, у нас это Работа, Услуги, Недвижимость, Товары и Авто. Также если у вас есть бизнес-направления, которые требуют большего внимания со стороны безопасности, такие как монетизация, сервисы с персональными данными, логистика, мед. услуги и др.
Когда не стоит идти?
Скромные размеры компании и масштабы бизнеса. С минимальным количеством сотрудников (100-250 человек) и простыми IT-системами (например, имеет минимальное количество интеграций с внешними сервисами, небольшую нагрузку и прочее) Sec BP вам не понадобятся.
Отсутствие сложных угроз. Когда компания не является привлекательной целью для киберпреступников (например, не работает с большими объёмами данных или деньгами).
Аутсорсинг ИБ. Если компания передала ИБ на обслуживание внешнему партнеру и вопросы информационной безопасности решаются специалистами на аутсорсе.
Кто же такой Security BP?
Security Business Partner (Sec BP) — это сотрудник департамента ИБ, который глубоко погружается в процессы разработки, помогает развивать практики безопасности и служит входной точкой для взаимодействия между продуктовой командой и командой безопасности. Sec BP одинаково погружён как в продуктовый, так и в security-контекст, что позволяет ему эффективно фасилитировать ключевые процессы (оценка рисков, моделирование угроз, ad-hoc консультации, обработка приходящих уязвимостей).
Более детально почитать про моделирование угроз можно в этой статье.
Основная задача Sec BP — это распространение культуры безопасности в продуктовых и инженерных командах. Для этого они поддерживают команды: предоставляют консультации, обучают основам безопасности и дают рекомендации по улучшению процессов.
Кого мы искали для пилота?
Для участия в пилоте мы открыли две новые позиции и искали специалистов с определёнными навыками. Важно было, чтобы они разбирались в коде, понимали аспекты его безопасности и могли общаться с разработчиками на одном языке. Большую часть технических дирекций составляют разработчики, поэтому требовалось именно такое сочетание навыков. Однако, в отличие от классических специалистов по безопасности приложений, мы делали акцент на коммуникацию, управление проектами и умение обучать.
В итоге оба наших Sec BP оказались бывшими разработчиками с опытом преподавания, что оказалось особенно полезным в рамках пилота.
Подготовка к пилоту
Как я уже писала выше, в Авито большое количество разных бизнесов. В нашей терминологии мы их называем вертикалями. Также есть горизонтальные команды (такие как PaaS, IaaS, безопасность и другие), которые предоставляют технологическую платформу как для горизонтальных, так и для вертикальных команд. Бизнесы могут перекликаться, пользоваться общей платформой для развертывания сервисов (IT-платформа) и взаимодействовать в самых разных ситуациях. У каждой вертикали и горизонтали есть dev-директор.
Перед запуском инициативы я провела встречи с dev-директорами, чтобы собрать их ожидания, и понять, с какими сложностями они сталкивались при взаимодействии с ИБ. Например, это были:
сложности в определении приоритетов по задачам безопасности. В команды могут влететь разные задачи: пройти аудит по защите персональных данных, запатчить баги, пройти обучение и т.д.;
сложности в разграничении зон ответственности. К кому идти? В безопасности много специалистов, а еще есть выделенные технические инженеры по безопасности персональных данных;
риски безопасности выявляются несистемно: не во всех командах есть чемпионы, которые помогут провести оценку рисков и/или моделирование угроз.
Если говорить о проблемах, которые были на стороне AppSec, то очень большое количество времени уходило на понимание продуктового контекста (так как направлений очень много, а AppSec специалистов — нет), чтобы давать качественные консультации по вопросам ИБ.
Чтобы пилот прошёл успешно, от команд разработки требовалось выделить время для онбординга Sec BP на регулярные встречи, предоставление документации и погружение в контекст проектов: 4 часа в неделю. Также команды — особенно старшие инженеры и те, кто отвечает за ревью кода — должны были принять участие в обучении по безопасному программированию: этот курс уже существовал, но не пользовался популярностью (14 часов в квартал). Важно было выделить время на оценку рисков — 2 часа от команды, проведение пентестов ключевых фич — 1 час на одну фичу — и на устранение найденных уязвимостей.
Мы выбрали два направления: вертикаль + горизонталь (22 и 31 команды в каждой). В команде примерно по семь человек. Продолжительность пилота – полгода.
Критерии успешности пилота
Мы заранее определили, что пилот будет считаться успешным, если:
мы получим положительную обратную связь от команд разработки и dev-директоров, включая прозрачность задач и приоритетов по безопасности;
будет зафиксирована положительная обратная связь от core-команды продуктовой безопасности;
удастся снизить нагрузку на core-команду продуктовой безопасности;
метрики Team Maturity Model (TMM)* покажут положительную динамику в части безопасности.
*Team Maturity Model (TMM) — модель соответствия технических и продуктовых практик команды ожиданиям в Авито и процесс быстрого аудита (аналог smoke test в qa), чтобы определить зоны роста команды.
Мы хотим, чтобы команды Авито были в «зеленой зоне» по ключевым инженерным и продуктовым практикам. Это инструмент поддержки и развития команд, а не наказания или попытки сравнить разные команды. И если команда не в «зеленой зоне», это вовсе не значит, что всё плохо. Это лишь сигнал к тому, чтобы сделать более глубокую диагностику, разобраться, действительно ли есть проблема, что с ней делать и когда. Одна из секций — «информационная безопасность» — включает регулярное обновление уязвимостей, проведение оценок рисков, отсутствие просроченных action item по ним и моделирования угроз.
Подробнее можно почитать тут.
Внедрение
Итак, мы приступили к пилоту. Ниже — подробно про основные шаги пилота (все этапы выполняли Sec BP-специалисты).
1. Оценка рисков (проводим раз в полгода и выявляем высокоуровневые риски ИБ).
Как устроен процесс оценки рисков ИБ в Авито можно прочитать тут.
Определили критические сервисы, требующие оценки рисков в приоритетном порядке. Для оценки использовали такие критерии как:
уровень публичности сервиса;
работа с ПДн и конфиденциальными данными;
предоставление выделенных интерфейсов (API/CLI/UI) для администрирования и конфигурирования настроек;
доступ внешних сотрудников (контракторов, подрядчиков) к сервису;
бизнес-критичность (рассчитывается из критерия сколько компания потеряет денег при недоступности данного сервиса).
После провели оценку рисков для всех команд, которым это необходимо (т.е. проводилась более полугода назад или вообще не проводилась).
Разработали планы и рекомендации по снижению рисков, организовали контроль исполнения.
2. Адаптация процесса анализа защищенности
Выявили критические сервисы для анализа защищенности.
Научили тимлидов и security champions использовать разработанные критерии, когда необходимо провести анализ защищенности/моделирование угроз. К этим критериям мы отнесли создание нового продукта или изменений в существующем такие как:
изменения в авторизации, аутентификации;
изменения в сторонних интеграциях;
изменения в финансовых операциях;
изменения в технической части приложения;
изменения модели хранения;
важные технические изменения в мобильных приложениях.
Провели анализ защищенности и выдали рекомендации по устранению недостатков (эту часть работ проводили AppSec-инженеры).
3. Контроль метрик успешности и общей динамики (экватор пилота)
Выявили чувствительные метрики такие как: процент покрытия различными инструментами безопасности, устранение уязвимостей, наличие межсервисной авторизации и др.
Провели презентацию с динамикой пилота заинтересованным сторонам.
Выяснили причины проседания TMM, их оказалось две:
Нерегулярная оценка рисков. Одной из косвенных причин послужило неудобство системы для управления рисками в её коробочной поставке: как только с этим поборолись и настроили интеграцию между ней и багтрекером, команды стали выполнять action items (AI) гораздо охотнее.
Нерегулярное моделирование угроз. По данной практике мы провели опрос среди тимлидов и секчемпов и выяснили, что кто-то не до конца понимал, как его проводить, а кто-то не понимал, в каких случаях это надо делать. Приняли меры, о них подробнее ниже.
4. Сбор обратной связи
Собрали обратную связь со стейкхолдерами и внесли корректировки в процессы. После первого сбора обратной связи поняли, что наши действия и метрики для dev-директоров оказались недостаточно прозрачными. Пошли в сторону регулярных апдейтов и автоматического расчета метрик ИБ, ведь до этого метрики были в разных хранилищах и их приходилось поначалу агрегировать вручную.
5. Адаптация процесса обучения
Определили критерии для обязательного обучения безопасному программированию новых сотрудников: для нас это мидл инженер+.
Чтобы отследить динамику по обучению, разработали/доработали тесты для воркшопов по безопасной разработке.
В компании есть тренд на фичалидство среди мидл-инженеров и мы решили поддержать его, помогая разработчикам проходить секцию ИБ. Обучение стало долгосрочной инвестицией в безопасность: обученный инженер с меньшей вероятностью допустит критическую ошибку в дизайне или коде.
6. Подведение итогов
После завершения пилота мы собрали метрики и обратную связь. Подавляющее большинство участников отметили, что инициатива была полезной и структурированной, а также помогла лучше понять задачи безопасности.
С некоторыми участниками побеседовали отдельно, чтобы лучше понять их обратную связь: например, кому-то не понравилась нестабильность платформы обучения — мы это оперативно исправили. Попадались также случаи, когда у одного участника был достаточно сложный кейс по поиску ответственных за список контроля доступа, а другой просто не был готов к столь пристальному вниманию от ИБ, считая функциональность, разрабатываемую командой, не очень критичной для бизнеса, и т.п.
Core-команда продуктовой безопасности также дала исключительно положительную обратную связь, особенно отметив снижение нагрузки на оценку рисков, обучение и количество запросов от команд. AppSec-специалисты могут решать задачи на лету — без необходимости тратить время на погружение в контекст — и больше времени уделять профильным активностям.
Команды разработки гораздо качественнее стали готовиться к защите технических кейсов и сразу стали привлекать ИБ, когда это действительно нужно.
Team Maturity Model показал значительный прогресс в 24 командах из 53, хотя в нескольких случаях наблюдался регресс из-за организационных факторов (слияние старых/выделение новых).
Появление бизнес-партнёра по безопасности никак не повлияло на работу security champions. Мы продолжаем активно развивать их сообщество, так как важно подходить к вопросам безопасности комплексно и закрывать риски с разных сторон.
Важные выводы
В процессе пилота мы сделали несколько ключевых выводов:
автоматизируйте сбор метрик, чтобы избежать ошибок и сократить временные затраты;
заранее согласовывайте объём необходимых ресурсов и времени;
собирайте обратную связь не только в конце, но и во время пилота, чтобы свериться по ожиданиям и результатам;
нанимайте людей с релевантной экспертизой, необходимой для выполнения функциональных задач;
продвигайте инициативу внутри компании, чтобы о ней знали.
Какие риски стоит учесть?
Будьте готовы к тому, что ваш SecBP может уйти в любой момент — даже посреди пилотного проекта. У нас такое случилось, и это могло сильно повлиять на результаты всей работы. Поэтому с самого начала продумайте, как быстро найти нового специалиста: составьте четкий портрет кандидата и настройте процесс найма так, чтобы не затягивать его. Тогда даже при неожиданном уходе сотрудника вы сможете быстро найти замену и продолжить работу без долгих пауз.
Когда один SecBP сменяет другого, важно правильно передать все дела. В такой момент легко упустить что-то важное — например, обучение команды. У нас так и вышло: в одной команде обучение прошли всего 4% инженеров вместо запланированных 40%.
Чтобы такого не случилось, сделайте два простых шага:
составьте подробный список всех проектов и задач, над которыми работает SecBP. Отметьте, что уже сделано, а что еще в работе;
дайте старому и новому специалисту время поработать вместе. Так они смогут обсудить все детали и нюансы работы, которые не опишешь в документах.
Общие итоги
В целом инициатива оказалась крайне полезной. Мы достигли повышения прозрачности ситуации с безопасностью, улучшили процессы и повысили зрелость команд в вопросах ИБ.
Многие команды сильно поменяли свой mindset и стали относиться к ИБ не как к «необходимому злу», а как к надёжным помощникам, стали активнее давать обратную связь и делиться идеями по улучшению процессов ИБ.
По результатам пилота было принято решение масштабировать инициативу на другие дирекции. Сейчас мы ищем в команду новых SecBP на другие направления. Если все прочитанное кажется тебе интересным и ты готов в этом поучаствовать, то мы тебя ждем!
SecBP все еще довольно неизученный зверь, поэтому каждая компания может применять и адаптировать эти концепции по-разному. Встречались ли вы с такой практикой, насколько считаете полезной? Делитесь своим опытом в комментариях.
Больше о наших мероприятиях, выступлениях и том, какие задачи решают инженеры Авито, — на нашем сайте и в телеграм-канале AvitoTech. А вот здесь — всегда свежие вакансии в нашу команду.