Повышение уровня кибербезопасности — это необязательно дополнительные периметры защиты и зоопарк новых СЗИ. Иногда достаточно по-другому организовать рабочие процессы и пересмотреть приоритеты.

Так служба ИБ-архитектуры МТС превратилась из обычного сервисного подразделения в полноценных Security Business Partners. Параллельно изменилось распределение зон ответственности между безопасниками. В итоге выиграли и ИБ-специалисты, и продуктовые команды, и в целом компания.   

О том, как внедрялись такие изменения и каких результатов удалось достичь с их помощью, нам рассказал первопроходец этого процесса — руководитель направления архитектуры ИБ в МТС и автор телеграм-канала Пакет безопасности Роман Панин. А «на сладкое» эксперт припас несколько полезных лайфхаков для всех, кто тоже задумывается над реорганизацией управления кибербезом. Передаём ему слово. 

С чего все начиналось 

Ценность кибербеза в МТС понимали и до переформатирования ИБ-архитектуры. Всё-таки защита информации в телекоммуникациях напрямую влияет на жизнеспособность бизнеса. Поэтому модель угроз и рисков давно стала «библией» для нашего подразделения. Если выделить самые актуальные проблемы, то среди них DDoS, а также атаки на уровне приложений. Не дают забыть о себе и риски supply chain. Однако настоящим вызовом для нас стала организация рабочих процессов.

Как была организована работа сервиса ИБ-архитектуры изначально

Проблема заключалась в том, что наш сервис работал как конвейер. Коллеги постоянно регистрировали в service desk заявки, которые назначались сразу на весь отдел. Каждый архитектор ИБ забирал с этого конвейера первую попавшуюся задачу и только затем начинал разбираться, что там за продукт и какова его архитектура. Безопасник накладывал на разработанную схему дополнительные средства защиты или говорил коллегам, что переделать. Потом ловил новую заявку — и так до бесконечности.

В отличие от производственного конвейера, наш постоянно менял темп. Запросы поступали неравномерно, и предугадать, например, следующий аврал было невозможно. Соответственно, не удавалось спрогнозировать загрузку ИБ-архитекторов, чтобы рационально распределить ресурсы. 

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

Как переформатировали ИБ-архитектуру

Мы быстро поняли, к какой организации ИБ-архитектуры стремиться: best practices подсказали подходящее решение. Обошлось без длительной подготовки и предварительных исследований — мы сразу же начали экспериментировать в пилотном кластере. Поэтому логичнее сначала обрисовать нашу «реформу», а уже потом перейти к проблемам и «граблям» на пути её внедрения.

Кластерный подход

Архитекторы ИБ больше не распыляются между продуктовыми тематиками и не хватаются за все заявки подряд. Мы решили распределить сферы ответственности и закрепить за каждым определённый кластер, объединяющий связанные между собой продукты. Например:

• внутренние сервисы: офисное ПО и софт, доступные только сотрудникам компании;

• IoT: продукты для умного дома (сим-карты, умные лампочки, розетки, хабы и прочее);

• медиа: продукты интертеймента, такие как МТС-лайф, KION, МТС-музыка (не включает сферу телеком);

• телеком: решения сотовой связи и телефонии.  

Кластеры не всегда напрямую соотносятся с подразделениями компании. Это скорее бизнес-группировка по продуктовому контексту. Теперь команды продуктов взаимодействуют лишь с теми безопасниками, которые ответственны за их кластер. ИБ-архитекторы решают возникающие проблемы самостоятельно либо привлекают коллег из смежных структур. 

ИБ-архитекторы как «единое окно»

Мы замкнули на себя все вопросы кибербеза и подключаемся к работе над продуктом начиная с обсуждения гипотез. Таким образом можно сразу оценить архитектуру с точки зрения кибербезопасности и при необходимости заложить туда СЗИ и бюджет на реализацию дополнительных мер защиты.

Но это еще не всё: работа ИБ-архитекторов не завершается даже на этапе выкатки продукта в продакшн. Если вдруг грянула DDoS-атака, WAF-сервис начал резать заголовки, применяемый алгоритм шифрования вызывает опасения или возникли другие сложности, продуктовые команды также обращаются к нам за помощью. Наш отдел теперь встроен в весь цикл создания и поддержки ПО.

Какие задачи решали в ходе переформатирования ИБ-архитектуры

На первый взгляд описанные меры и получившиеся процессы выглядят просто. Такими и должны быть хорошие процессы, но вот их внедрение на практике стало настоящим челенджем со множеством нюансов. Для начала обозначу наиболее масштабные и сложные задачи, с которыми пришлось столкнуться. 

Задача 1: обкатать архитектуру на практике и выстроить коммуникацию

Сперва предстояло выработать и опробовать механизмы взаимодействия безопасников с продуктовыми командами в пилотном кластере, чтобы потом масштабировать эти практики на остальную инфраструктуру. В компании давно привыкли, что архитекторы ИБ выступают в другом амплуа, далёком от Security Business Partners. Так что мы налаживали контакты, устраивали бесконечные митапы, доказывали коллегам ценность и необходимость перемен. Впрочем, о возникшем у них когнитивном диссонансе в восприятии нашей роли подробнее скажу чуть позже.  

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

Кроме того, нам больше не нужно отвлекать и звать на встречи сразу по 10-15 коллег из-за незнания, к кому обратиться с возникшим вопросом. Большинство тем можно обсудить тет-а-тет с Security Champion. Или же он уже по необходимости соберёт рабочую группу из коллег.

В перспективе миссия чемпионов безопасности может расшириться. Сейчас прорабатывается схема, при которой они будут объединяться в гильдии (да, совсем как средневековые купцы или ремесленники), перенимать лучшие практики у нас в формате обучений и менторства и распространять их по всей компании.

Задача 2: автоматизировать процессы

Поскольку ИБ-служба — всё же сервисное подразделение, без поступающих через service desk заявок не обойтись. Нам нужно принимать запросы в единой цифровой среде, рассчитывать KPI, анализировать объёмы выполненной работы. Другое дело, что следовало упорядочить процесс и отказаться от упомянутого «конвейера».

Первым делом мы настроили автоматическое назначение заявок на конкретных ИБ-архитекторов в зависимости от продукта. Если запрос касается, скажем, сферы IoT, то он по умолчанию «улетает» ответственному за этот кластер безопаснику. 

Затем добавили несколько новых типов заявок. В нашем сервисном каталоге помимо проектирования безопасной архитектуры появились такие услуги, как проведение пентеста, интеграции с СЗИ, категоризация информации. Это не усложнило жизнь продуктовым командам или архитекторам ИБ. Напротив, повысилась прозрачность процессов, поскольку всем сразу понятна суть задачи. Безопасникам стало проще проводить аналитику и отчитываться перед топ-менеджментом о проделанной работе.    

Задача 3: внедрить лидеров практик по ИБ

В МТС действуют верхнеуровневые органы со звучной аббревиатурой ЦК партии, что означает центры компетенций. Подобные структуры уже давно работают в сферах DevOps, аналитики, тестирования, SRE. ЦК формируют общие стратегические рекомендации и практики, которые потом транслируют лидерам своих направлений в кластерах. Те же каскадируют всё это на продуктовые команды (чаще всего, на их CTO). 

Мы создали аналогичный координирующий орган и в кибербезе. А курирующие кластеры архитекторы ИБ также стали лидерами практик. В итоге вся экосистема МТС с её филиалами, подразделениями и продуктами движется в едином направлении в части цифровой безопасности. 

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

Какие сложности преодолели

Трудности начались ещё до выполнения перечисленных задач, на этапе согласования и защиты пилотного проекта.

Сложность 1. Недоверие со стороны бизнеса

Это как раз то, что было нетрудно предвидеть и без хрустального шара мудрёной прогнозной аналитики. Прежде чем вложить в переформатирование ИБ-архитектуры немалые средства, топ-менеджмент обоснованно желал убедиться, что это сработает. Также предстояло уверить в пользе нововведений CTO и лидеров практик каждого кластера. 

Чтобы отстоять свою позицию и согласовать бюджет, пришлось оперировать красноречием и примерами из best practices. Началась нескончаемая череда встреч и напряжённых дискуссий. Наконец бизнес поверил в ценность наших предложений. Мы сразу же обкатали новые процессы в пилотном кластере, и старое доброе сарафанное радио разнесло итоги эксперимента по всей компании. 

Сложность 2. Сопротивление продуктовых команд

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

Сломать этот барьер и по-новому выстроить общение со всеми ИТ-специалистами помогли уже упомянутые митапы, разъяснительная работа и, главное, Security Champions.

Сложность 3. Эскалирование проблем смежным подразделениям

А вот и первые «грабли» на нашем пути. Мы так поспешили взять на себя роль Security Business Partners, что предварительно не разобрались, к кому обращаться самим по смежным вопросам. Допустим, кто поможет, если вдруг «упал» WAF или Firewall? Или же возникли сложности с сегментированием сети. В силу прежнего конвейерного подхода к работе у ИБ-архитекторов не было исчерпывающего понимания, кто за что отвечает в компании.

Иногда мы приходили за помощью не к тем специалистам. Бывало, что локальные проблемы эскалировались на высшее руководство или переходили из рук в руки и возвращались по кругу к нам же.

Стало очевидно, что так взаимодействовать с коллегами нельзя. Мы провели глобальную инвентаризацию зон ответственности по компании, переговорили с руководителями и сотрудниками подразделений и команд. В итоге составили таблицу, в которой расписаны ответственные по направлениям и те коллеги, кто их замещает в случае отпуска или болезни. Такой внутренний справочник стал серьёзным подспорьем даже для опытных ИБ-архитекторов, не говоря уже о джунах.    

Сложность 4. Неравномерное распределение нагрузки между архитекторами ИБ 

Переходим к ещё одним «граблям». Сперва мы наивно полагали, что, если в пилотном кластере один архитектор ИБ справился с 20 продуктами, также будет и в остальных. На деле всё оказалось иначе.

В определённый момент безопасник, отвечающий всего за 15 продуктов третьего кластера, начал «буксовать». На первый взгляд казалось, будто он работает недостаточно эффективно. Однако вскоре выяснилось, что один из вверенных ему продуктов по своему масштабу тянет на целый монокластер. Это было крупное highload-решение с массой сторонних интеграций. Теперь за него отвечает отдельный архитектор ИБ, несколько продуктовых команд и свой CTO. 

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

Как развивается ИБ-архитектура

Архитектура — не муха в янтаре. Меняются реалии бизнеса, тенденции и стратегии кибербеза, на всё это приходится гибко реагировать.

Метрики и оценка текущего состояния

Перефразируя народную мудрость, семь раз измерь, один раз усовершенствуй. Без понимания объективной ситуации, наиболее проблемных зон и продуктов, неясно, в каком направлении развивать ИБ-архитектуру. Вот почему мы разработали собственные метрики информационной безопасности, которые постоянно «допиливаем» в зависимости от текущих реалий. 

Сюда относится показатель уровня зрелости ИБ как продуктов, так и целых кластеров. Параллельно мы измеряем такой параметр в среднем по больнице по компании. Основными критериями при расчёте метрики служат уровень или наличие интеграции с тем или иным СЗИ, наличие инструментов безопасности в пайплайнах CI/CD, давность проведения последнего секьюрити ревью. 

Статистика для вычисления показателя берётся из специальных опросников, которые заполняют члены продуктовых команд. Причём недостаточно ответить на словах: нужно приложить к анкете какой-то документ или артефакт в подтверждение предоставленной информации. Это могут быть отчёты о сканировании, внутренние документы с требованиями ИБ, выгрузки из СЗИ. Все ответы тщательно проверяются и валидируются лидерами практик по кибербезу. Потом уровень ИБ-зрелости оценивается по пятибалльной шкале. Согласно нашим нормативам, по продуктам уровня mission critical или business critical показатель не должен опускаться ниже 3,5 баллов. 

Цель измерений — выявить системные проблемы и, если нужно, помочь коллегам справиться с ними. Например, стоит периодически анализировать динамику метрики по продукту за несколько месяцев. Если показатель ИБ-зрелости заметно снизился или постоянно скачет, самое время углубиться в процессы продуктовой команды с точки зрения кибербеза, чтобы устранить камни преткновения.    

Другой ценный источник информации при оценке текущей ситуации — это обратная связь от CTO кластеров. Подобных руководителей в компании всего несколько десятков, так что регулярно узнавать их мнение о работе архитекторов ИБ и уровне безопасности продуктов не так и сложно.   

Совершенствование и масштабирование

По большей части мы продолжаем применять привычные практики, которые опробовали в начале нашего пилота. Это и проведение регулярных митапов с членами продуктовых команд, и взаимодействие с Security Champions. Всего за год работы в новом формате ситуация в бизнесе и кибербезе не изменилась настолько, чтобы снова ломать и без того не до конца устоявшиеся процессы. 

Тем не менее кое-какие подходы корректируем уже сейчас. В определённые моменты мы осознали, что не можем поручить кластер IoT никому из наших ИБ-архитекторов. Эта сфера требует специфических знаний и компетенций, поэтому нам пришлось найти под неё специалиста с соответствующим опытом. 

Попутно у нас родилась полезная идея: сконцентрировать уникальные и узкоспециализированные компетенции в отдельных кластерах. Допустим, в IoT и телеком-безопасникам критически важно разбираться в хардвере, в то время как по другим направлениям такие скилы требуются крайне редко. Если ИБ-архитекторам, ответственным за внутренние сервисы или, скажем, медиа, нужно разобраться с железом, они знают, к кому обращаться.

К тому же мы гибко перераспределяем продукты и специалистов между кластерами по мере масштабирования и изменения бизнеса. Если продуктовое направление сильно разрослось и текущая команда не справляется, нанимаются дополнительные безопасники. Кластер МТС-клауд вовсе оказался настолько масштабным и специфическим, что для него пришлось создать особую структуру управления. Там действует отдельный CISO, который курирует работу безопасников. Возможны и противоположные варианты, когда два небольших направления закрепляются за одним ИБ-архитектором, чтобы не раздувать штат и обеспечить достаточную загрузку сотрудникам.    

Полезные лайфхаки

Пройдя весь описанный путь, мы сделали кое-какие полезные выводы. Если вы тоже задумываетесь о переформатировании своей ИБ-архитектуры, ловите несколько простых, но жизненных лайфхаков. 

Лайфхак 1. Не спешите ломать то, что работает 

Всегда следует помнить, что лучшее — враг хорошего. Да, мы в МТС сломали процессы управления кибербезом и выстроили их заново, тем самым улучшив показатели по ИБ. Но это далось нам немалой кровью. Мы допустили массу ошибок, на исправление которых пришлось потратить ресурсы, столкнулись с недоверием топ-менеджмента и неприятием коллег из продуктовых команд на старте проекта. Словом, так рубить с плеча стоит лишь тогда, когда в компании действительно есть критические проблемы с кибербезом или от этого направления зависит жизнеспособность бизнеса. 

Лайфхак 2. Отказывайтесь от «конвейеров»

Желательно, чтобы заявки не лились единым потоком на всю ИБ-службу, а сразу назначались на ответственных безопасников. В нашем случае это кластерный подход, в других компаниях может быть своё распределение. Так или иначе, ИБ-специалистам необходим свой чётко очерченный фронт работ, чтобы глубже погружаться в контекст и специфику продуктов, понимать, из чего они состоят и какое влияние оказывают на бизнес.

Лайфхак 3. Вводите метрики

Даже если на первый взгляд никаких проблем с кибербезом не возникает, метрики всё равно нужны. Ведь их ретроспективный анализ помогает выявить негативные паттерны и исправить системные проблемы до того, как ситуация станет критической. Чтобы облегчить себе задачу при разработке метрик, можно взять за основу один из общепринятых фреймворков, таких как OWASP SAMM или BSIMM. 

Лайфхак. 4. Не загоняйте себя в слишком жёсткие рамки и гибко подходите к срокам выполнения задач

Во многом сами безопасники способны влиять на то, насколько удобным и эффективным будет взаимодействие с коллегами по рабочим задачам. Например, важно рассчитать и обосновать перед руководством оптимальные SLA (соглашения об уровне сервиса, где в том числе прописываются сроки предоставления различных услуг). Работа ИБ-специалистов не должна превращаться в постоянный бег в колесе, но и слишком затягивать выполнение запросов не стоит. 

Необходимо учитывать критичность и трудоёмкость разных задач. Если на проведение планового пентеста вполне допустимо заложить и целый месяц, то ревью интеграции продукта, который выкатывается в продакшн, лучше выполнить за несколько дней.    

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

Не менее важный результат — повышение удовлетворённости продуктовых команд взаимодействием с ИБ-архитекторами. Теперь все коллеги знают безопасников в лицо и работают вместе с ними на достижение общего результата.