Кибербезопасность банков: свой SOC или внешний MSSP

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

Разница между контролируемым инцидентом и утечкой определяется не только наличием средств защиты. Критичны скорость обнаружения, качество первичной квалификации события и способность команды немедленно ограничить вектор атаки. Именно здесь банки выбирают между собственным центром мониторинга информационной безопасности — SOC — и внешним провайдером управляемых услуг — MSSP.

Для финансового сектора это уже не вопрос удобства. В первом полугодии 2025 года на организации финансовой отрасли пришлось 17% целенаправленных кибератак в России. Всего за этот период российские компании столкнулись более чем с 63 тысячами кибератак — на 27% больше, чем годом ранее. При такой динамике модель мониторинга становится частью операционной устойчивости банка, а не отдельной закупкой средств ИБ.

Ландшафт угроз: почему финансовый сектор под прицелом

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

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

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

• аномальные входы в учетные записи и резкое изменение поведенческого профиля пользователя;
• попытки повысить привилегии или подключиться к административным ресурсам;
• запуск нестандартных процессов на рабочих станциях и серверах;
• перемещение между сегментами сети;
• выгрузку больших объемов данных;
• отключение или обход средств защиты;
• подозрительную активность подрядчиков и внешних сервисных учетных записей;
• события, связанные с вредоносным программным обеспечением и эксплуатацией уязвимостей.

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

SOC без круглосуточной аналитики — это не центр мониторинга, а склад журналов, в котором инцидент может остаться незамеченным.

Для банков особенно опасна задержка между первым сигналом и подтверждением компрометации. У атакующего может быть достаточно времени, чтобы закрепиться в инфраструктуре, обойти сегментацию и подготовить вывод данных. Поэтому в сравнении собственного SOC и MSSP необходимо смотреть не на перечень продуктов, а на измеримые показатели: MTTD, MTTR, долю ложных срабатываний, полноту покрытия активов и стоимость владения.

Что означают ключевые метрики SOC

MTTD — среднее время обнаружения инцидента. Оно показывает, сколько проходит от появления вредоносной активности до фиксации угрозы системой или аналитиком.

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

TCO — совокупная стоимость владения. В случае SOC это не только лицензии SIEM, EDR и средств сетевого мониторинга. В расчет входят внедрение, интеграция, хранение журналов, резервирование, зарплаты, обучение, замещение сотрудников, дежурства, развитие правил корреляции и расследование инцидентов.

SLA — договорный уровень сервиса. Для MSSP он должен описывать время обнаружения, уведомления, эскалации и реагирования, а также перечень исключений. Формулировка без временных границ не является рабочим SLA: она оставляет спор о качестве услуги на момент, когда ущерб уже возник.

Экономика собственного SOC: инфраструктура против кадрового дефицита

Собственный SOC дает банку максимальный контроль над архитектурой, данными и процессами расследования. Но этот контроль оплачивается не одной закупкой оборудования. В первую очередь банк создает постоянно действующую операционную функцию, которая должна работать независимо от отпусков, текучести кадров и ночных смен.

Для инфраструктуры примерно на 4 тысячи активов капитальные затраты на внедрение SIEM и сопутствующей инфраструктуры оцениваются в 15–25 млн рублей. Это только этап развертывания. Далее начинаются ежегодные расходы на команду и эксплуатацию.

Команда из 12–15 специалистов требует 18–25 млн рублей в год операционных расходов по приведенной оценке. Для режима 24/7 на первой линии необходимо минимум 8–12 человек. Даже фонд оплаты труда команды из 10 сотрудников может составлять 15–24 млн рублей в год. Полноценный минимальный SOC на 25 человек обходится от 35 млн рублей ежегодно.

Эти значения не следует воспринимать как универсальный прайс. На итоговую стоимость влияют число активов, объем журналов, требования к сроку хранения, количество филиалов, сложность интеграций, уровень автоматизации и наличие собственной команды реагирования. Однако порядок затрат показывает главное: SOC — это не лицензия на SIEM, а инфраструктурно-кадровый проект с постоянными расходами.

Из чего складывается стоимость инсорсинга

Внутренний центр мониторинга обычно требует нескольких уровней компетенций:

1. Первая линия мониторинга. Аналитики принимают события, отсеивают очевидные ложные срабатывания, фиксируют инциденты и запускают утвержденные процедуры эскалации. Для режима 24/7 именно численность этой группы становится одним из главных ограничений.

2. Вторая линия расследования. Специалисты анализируют цепочку событий, сопоставляют данные из SIEM, EDR, сетевых средств и систем управления доступом, определяют масштаб компрометации.

3. Третья линия и threat hunting. Эксперты ищут признаки атак, которые не были обнаружены стандартными правилами, анализируют тактики и техники злоумышленников, обновляют модели обнаружения.

4. Инженерная функция. Она отвечает за подключение источников, качество журналирования, правила корреляции, отказоустойчивость, хранение данных и развитие платформы.

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

Сокращение состава почти всегда отражается на качестве. Если банк оставляет только первую линию, сложные инциденты накапливаются в очереди или передаются внешним экспертам. Если нет инженерной функции, новые активы подключаются с задержкой, а правила обнаружения устаревают. Если нет выделенного threat hunting, SOC реагирует преимущественно на уже известные паттерны.

Где собственный SOC действительно оправдан

Инсорсинг имеет рациональные основания, если банк располагает достаточным масштабом и зрелостью:

• инфраструктура содержит большое количество критических активов и сложных внутренних контуров;
• есть стабильная команда ИБ, способная работать посменно и закрывать узкие компетенции;
• банк предъявляет повышенные требования к контролю над телеметрией и расследованиями;
• архитектура включает закрытые или специализированные системы, которые сложно передавать внешнему провайдеру;
• организация готова инвестировать не только во внедрение, но и в многолетнее развитие SOC;
• регуляторные, договорные или внутренние требования ограничивают передачу отдельных функций внешней стороне.

Крупнейшие системно значимые банки могут сохранять собственный SOC именно по этой причине. Для них критичны банковская тайна, локализация данных, контроль над процессами реагирования и способность самостоятельно проводить расследования. Это не означает, что внешний провайдер для них исключен: отдельные функции, технологии или экспертные работы могут закупаться у MSSP. Но полная передача мониторинга требует отдельного анализа ограничений.

Модель MSSP: как аутсорсинг меняет метрики эффективности

MSSP берет на себя часть функций SOC: сбор и анализ событий, круглосуточный мониторинг, первичную квалификацию, уведомление, эскалацию и в некоторых моделях — реагирование. Конкретный объем определяется договором. Один провайдер может ограничиваться передачей подтвержденных инцидентов, другой — изолировать учетную запись, блокировать хост или запускать сценарий автоматического реагирования при заранее заданных условиях.

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

По приведенным оценкам, коммерческий SOC или MSSP снижает стоимость мониторинга одного актива на 40–60% по сравнению с собственным SOC. Дополнительное преимущество — отсутствие крупных начальных капитальных затрат на самостоятельное развертывание SIEM и инфраструктуры. Но снижение TCO не равно автоматическому повышению безопасности. Плохая интеграция, неполное покрытие активов или неясная зона ответственности способны обнулить экономию.

Стандартные параметры SLA коммерческих SOC предусматривают обнаружение угроз менее чем за 15 минут и реагирование менее чем за 30 минут. Для банка эти показатели имеют смысл только при соблюдении трех условий:

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

Если MSSP обнаружил подозрительную активность, но не может заблокировать учетную запись без отдельного подтверждения клиента, фактическое время локализации будет зависеть уже от внутренней процедуры банка. Формальное SLA при этом может быть выполнено, а риск — сохраниться.

Сравнение моделей

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

Регуляторные рамки и ответственность за данные

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

В Республике Беларусь Указ Президента №40 «О кибербезопасности» и Приказ ОАЦ №130 установили для владельцев критической информационной инфраструктуры обязанность создать собственные центры кибербезопасности либо подключиться к услугам сервисных провайдеров — MSSP/SOC. Крайним сроком было 17 августа 2024 года. Этот пример показывает направление регулирования: государственные требования могут допускать не только инсорсинг, но и использование сертифицированной или соответствующей установленным условиям внешней инфраструктуры.

Однако сам факт подключения к MSSP не закрывает регуляторные вопросы. Перед заключением договора банк должен зафиксировать:

• какие данные передаются провайдеру и в каком виде;
• где хранятся журналы и резервные копии;
• кто имеет доступ к телеметрии и результатам расследований;
• как оформляется доступ подрядчиков к критическим системам;
• какие сроки хранения событий применяются;
• как проводится аудит провайдера;
• что происходит с данными после завершения договора;
• кто уведомляет банк о нарушении SLA и компрометации инфраструктуры;
• как организуется взаимодействие с регулятором и правоохранительными органами.

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

Ответственность должна быть разделена по действиям

Формула ответственности в договоре должна быть операционной. Недостаточно написать, что MSSP отвечает за мониторинг, а банк — за инфраструктуру. Необходимо определить, кто:

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

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

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

Как оценивать MSSP по фактическим метрикам

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

1. Покрытие активов

Провайдер должен показать, какие источники он принимает и как контролирует их доступность. В перечне обычно находятся:

• серверы и рабочие станции;
• сетевое оборудование;
• средства удаленного доступа;
• системы управления учетными записями;
• облачные сервисы;
• базы данных;
• приложения дистанционного банковского обслуживания;
• межсетевые экраны и системы предотвращения вторжений;
• средства защиты конечных точек;
• критические API и интеграционные шлюзы.

Подключение SIEM без контроля полноты телеметрии создает ложное ощущение наблюдаемости. Если часть критических активов не передает события, показатель MTTD рассчитывается только для видимой зоны, а не для всей инфраструктуры банка.

2. Качество триажа

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

Для зрелого SOC целевым ориентиром называют уровень false positives менее 5%. Но этот показатель необходимо раскрывать методологически: что считается ложным срабатыванием, как учитываются повторные события, кто подтверждает классификацию и не скрывается ли проблема за агрессивной фильтрацией.

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

3. Фактический MTTD и MTTR

SLA следует проверять на исторических данных или результатах контрольных сценариев. Банк должен запросить распределение времени обнаружения и реагирования, а не только среднее значение. Среднее может скрывать редкие, но критичные задержки.

Вопросы к провайдеру должны быть конкретными:

• с какого момента начинается отсчет MTTD;
• считается ли обнаружением автоматическое срабатывание правила или подтверждение аналитика;
• что входит в MTTR;
• кто выполняет техническое действие по изоляции;
• какие задержки зависят от банка;
• как учитываются ночные часы и выходные;
• предусмотрена ли компенсация за нарушение SLA;
• как проводится постинцидентный разбор.

Если на эти вопросы нет однозначных ответов, заявленные показатели нельзя использовать для сравнения предложений.

4. Сценарии реагирования

У MSSP должны быть не только правила обнаружения, но и playbook для типовых событий: компрометация учетной записи, вредоносное вложение, попытка эксплуатации уязвимости, подозрительная выгрузка данных, активность привилегированного пользователя, заражение рабочего места.

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

5. Возможность расследования

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

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

Хороший MSSP продает не поток уведомлений, а сокращение времени между событием, подтверждением и контролируемым действием.

Когда смешанная модель рациональнее бинарного выбора

Противопоставление «собственный SOC или MSSP» не всегда отражает реальную архитектуру банка. На практике возможна гибридная схема.

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

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

Гибридный подход требует более сложной координации. Если зона ответственности не разделена, у банка появляются два SOC, но не появляется единый процесс реагирования. Поэтому заранее определяются единые классификаторы инцидентов, формат уведомлений, порядок эскалации и владелец каждого playbook.

Рациональная архитектура может выглядеть так:

• MSSP обеспечивает сбор телеметрии и круглосуточную первую линию;
• внутренние аналитики банка принимают решения по критичным событиям;
• провайдер выполняет согласованные технические действия;
• банк контролирует доступ к данным, регуляторную отчетность и коммуникации;
• независимая команда периодически проверяет полноту мониторинга и качество SLA.

Такой вариант особенно полезен для коммерческого банка, который еще не накопил штат для полноценной работы 24/7, но не готов полностью передавать функции реагирования внешнему оператору.

Критерии выбора: где инсорсинг проигрывает внешнему сервису

Собственный SOC начинает проигрывать MSSP не тогда, когда у него меньше продуктов, а когда он не выдерживает операционный режим. Признаки обычно фиксируются в процессе эксплуатации:

1. Круглосуточная смена закрывается формально. Дежурный специалист есть по графику, но у него нет доступа, полномочий или компетенций для действий по критическим системам.

2. Инженерная команда постоянно тушит эксплуатационные сбои. Правила корреляции не развиваются, источники подключаются с задержкой, а качество журналов не контролируется.

3. Расследование зависит от нескольких сотрудников. Их отсутствие создает очередь инцидентов и увеличивает MTTR.

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

5. SOC не масштабируется вслед за инфраструктурой. Каждый новый филиал, сервис или облачный контур требует отдельной закупки и ручной настройки.

6. Нет независимой проверки результата. Банк видит отчеты о количестве событий, но не знает, насколько полно покрыты критические активы и как быстро выполняются действия.

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

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

Практический алгоритм принятия решения

Сравнение моделей следует проводить в несколько этапов.

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

Затем фиксируется минимально приемлемый уровень защиты: режим работы, время обнаружения, срок эскалации, действия при подтвержденной компрометации, требования к хранению журналов и допустимый уровень автоматизации.

После этого строится финансовая модель на несколько лет. В ней отдельно учитываются:

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

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

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

Вывод

Для большинства коммерческих банков вопрос стоит не в том, чтобы любой ценой построить собственный SOC. При ограниченном штате, большом количестве активов и необходимости круглосуточного мониторинга внешний MSSP может снизить стоимость мониторинга одного актива на 40–60% и быстрее вывести службу на договорные показатели: обнаружение угроз менее чем за 15 минут и реагирование менее чем за 30 минут.

Но эти цифры работают только при полном покрытии инфраструктуры, корректной интеграции, понятном SLA и наличии у провайдера реальных полномочий на реагирование. Аутсорсинг не устраняет ответственность банка за защиту данных и не заменяет внутреннюю функцию управления инцидентами.

Собственный SOC оправдан там, где критичны максимальный контроль, глубокая специализация и способность самостоятельно расследовать атаки. MSSP рациональнее, когда банку требуется быстро получить режим 24/7 без многомиллионного запуска инфраструктуры и постоянного расширения штата. Гибридная модель позволяет совместить эти требования, если границы ответственности закреплены не в общей декларации, а в технических регламентах, playbook и измеримых метриках.

В конечном счете зрелость кибербезопасности банка определяется не тем, где находится SOC — внутри организации или у провайдера. Определяющим остается другое: видит ли банк критические события, понимает ли их контекст и способен ли выполнить необходимое действие до того, как компрометация перейдет в финансовый инцидент.