Комментарии 7
Спасибо за то, что поделились интересным опытом!
Основной целью пилота было снижение рисков и повышение уровня безопасности продуктов Авито за счёт более тесного и эффективного взаимодействия между продуктовыми командами и командой безопасности, чтобы обе стороны выиграли от сотрудничества.
Не получилось ли так, что продуктовые команды по сути начали аутсорсить все вопросы безопасности в своих SecBP (и теперь надо как минимум иметь количество SecBP >= число команд) вместо того, чтобы осознать собственную ответственность за риски в разрабатываемых сервисах (и, как следствие, уделять больше внимание вопросам ИБ)? Стали ли продуктовые команды выполнять больше задач, относящихся к безопасности, после того как у них появлялся SecBP, но без его участия?
Чтобы пилот прошёл успешно, от команд разработки требовалось выделить время для онбординга Sec BP на регулярные встречи, предоставление документации и погружение в контекст проектов: 4 часа в неделю.
Важно было выделить время на оценку рисков — 2 часа от команды, проведение пентестов ключевых фич — 1 час на одну фичу — и на устранение найденных уязвимостей.
А почему вы решили это измерять, причем формально (в часах)?
В команды могут влететь разные задачи: пройти аудит по защите персональных данных, запатчить баги, пройти обучение и т.д.;
Почему это рассматривается именно как "внешние" задачи, при том, что это по сути часть продукта?Например, если баги не будут исправлены, то может реализоваться риск соответствующей атаки (и инцидента). Этот риск может и быть принят в пользу расхода ресурсов на продуктовые фичи. И это решение продуктовой команды.
привет!
Не получилось ли так, что продуктовые команды по сути начали аутсорсить все вопросы безопасности в своих SecBP (и теперь надо как минимум иметь количество SecBP >= число команд) вместо того, чтобы осознать собственную ответственность за риски в разрабатываемых сервисах (и, как следствие, уделять больше внимание вопросам ИБ)? Стали ли продуктовые команды выполнять больше задач, относящихся к безопасности, после того как у них появлялся SecBP, но без его участия?
SecBP закреплен за бизнес-направлением, в котором может быть 25–40 команд. Он служит точкой входа в основную команду ИБ, но не берет на себя все задачи по безопасности. Продуктовые команды действительно начали активнее работать с инструментами ИБ, улучшать их настройку и процессы. Однако пока рано говорить о полноценном эффекте, так как в ряде направлений (кроме двух пилотных) роль SecBP еще не внедрена, и эти задачи по-прежнему выполняются основной командой ИБ.
А почему вы решили это измерять, причем формально (в часах)?
Приблизительно оценили, сколько времени уходит на выполнение задач. При планировании ресурсов со стороны разработки важно заранее договариваться с тимлидами, так как у команд есть квартальные цели, и наши планы в них изначально не входят. Чем конкретнее будут требования к ресурсам, тем проще их согласовать.
Почему это рассматривается именно как "внешние" задачи, при том, что это по сути часть продукта?Например, если баги не будут исправлены, то может реализоваться риск соответствующей атаки (и инцидента). Этот риск может и быть принят в пользу расхода ресурсов на продуктовые фичи. И это решение продуктовой команды.
Задачи не считаются внешними, но у них может быть предопределенный приоритет, например, на основе шкалы CVSS. При этом такая автоматическая оценка не всегда учитывает параллельно поступающие задачи по безопасности, что может создавать дисбаланс в их приоритизации.
SecBP закреплен за бизнес-направлением, в котором может быть 25–40 команд. Он служит точкой входа в основную команду ИБ, но не берет на себя все задачи по безопасности.
А что происходит, когда SecBP уходит в отпуск?
Продуктовые команды действительно начали активнее работать с инструментами ИБ, улучшать их настройку и процессы. Однако пока рано говорить о полноценном эффекте, так как в ряде направлений (кроме двух пилотных) роль SecBP еще не внедрена, и эти задачи по-прежнему выполняются основной командой ИБ.
Этот результат немного отличается от декларируемого в статье:
"В целом инициатива оказалась крайне полезной. Мы достигли повышения прозрачности ситуации с безопасностью, улучшили процессы и повысили зрелость команд в вопросах ИБ.
Многие команды сильно поменяли свой mindset и стали относиться к ИБ не как к «необходимому злу», а как к надёжным помощникам, стали активнее давать обратную связь и делиться идеями по улучшению процессов ИБ. "
Приблизительно оценили, сколько времени уходит на выполнение задач.
Часто размер задач достаточно сложно оценить, тем более в часах. У вас же получилось упаковать то же тестирование безопасности и исправление найденных уязвимостей в достаточно жесткие временные рамки. Рассматривали ли вы возможность сначала делать быструю сортировку фич с дальнейшим анализом рисков и уже на основе этого тестирование безопасности и т.д.? То есть идти от того, насколько потенциально рискованная фича, а не просто строго выделять время в неделю.
А что происходит, когда SecBP уходит в отпуск?
Работы переходят на основную команду
Этот результат немного отличается от декларируемого в статье
Не вижу противоречий. В статье я пишу про результаты пилота
Рассматривали ли вы возможность сначала делать быструю сортировку фич с дальнейшим анализом рисков и уже на основе этого тестирование безопасности и т.д.? То есть идти от того, насколько потенциально рискованная фича, а не просто строго выделять время в неделю.
Нет, не рассматривали. С таким подходом вижу сложность в оценке, тк не все изменения можно предусмотреть заранее
Работы переходят на основную команду
Допустим, что у вас 5 вертикалей и каждый SecBP уходит отпуск хотя бы раз в год, тогда почти полгода основная команда будет вынуждена переключаться на решение задач соответствующего бизнес-юнита (и следовательно будет необходимость поддерживать знание в соответствующем домене). Как вы планируете решать эту проблему? Планируете ли возможность организовать команду под каждого SecBP?
Нет, не рассматривали. С таким подходом вижу сложность в оценке, тк не все изменения можно предусмотреть заранее
По описании фичи часто можно спрогнозировать, что она в принципе будет рискованна. Следовательно можно и заложить под это полноценный анализ рисков (вместо фиксированного времени, которого просто может не хватить и будет пропущен действительно рискованный релиз).
В целом, любопытно было бы почитать такой же пост, но по прошествии 1-2 лет и, конкретно, про то, насколько много продуктовые команды вертикалей стали делать больше самостоятельно в плане ИБ (либо же SecBP стали для них ответом на все вопросы).
Допустим, что у вас 5 вертикалей и каждый SecBP уходит отпуск хотя бы раз в год, тогда почти полгода основная команда будет вынуждена переключаться на решение задач соответствующего бизнес-юнита (и следовательно будет необходимость поддерживать знание в соответствующем домене). Как вы планируете решать эту проблему? Планируете ли возможность организовать команду под каждого SecBP?
Я согласна, что проблема с взаимозаменяемостью есть. На счет команды пока сложно сказать, скорее это будет младший помощник к партнеру. Сейчас мы заняты тем, чтобы иметь хотя бы одного партнера на направление.
В целом, любопытно было бы почитать такой же пост, но по прошествии 1-2 лет и, конкретно, про то, насколько много продуктовые команды вертикалей стали делать больше самостоятельно в плане ИБ (либо же SecBP стали для них ответом на все вопросы).
Через 1,5-2 года попробую вернуться к статье и рассказать как получилось.
Спасибо за ответы и в любом случае желаю удачи! :)
Кстати, на Хабре были также статьи про SecBP/БПИБ от ребят из Озона (https://habr.com/ru/companies/ozontech/articles/744524/).
Да кто такой этот ваш Security BP?