Привет! Меня зовут Екатерина Пухарева, работаю в Авито руководителем продуктовой безопасности. В компанию я пришла в начале 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 все еще довольно неизученный зверь, поэтому каждая компания может применять и адаптировать эти концепции по-разному. Встречались ли вы с такой практикой, насколько считаете полезной? Делитесь своим опытом в комментариях.
Вот так видит SecBP нейросеть :)
Больше о наших мероприятиях, выступлениях и том, какие задачи решают инженеры Авито, — на нашем сайте и в телеграм-канале AvitoTech. А вот здесь — всегда свежие вакансии в нашу команду.
