Современный SOC перестал быть просто системой, которая собирает и сортирует многочисленные события информационной безопасности. Для банка это уже полноценный элемент инфраструктуры, от которого зависит скорость обнаружения и расследования атак, взаимодействие подразделений и способность организации быстро реагировать на инциденты. Но чем сложнее становится банковская ИТ-среда, тем труднее провести границу между автоматизацией и работой человека. Особенно остро эта проблема проявляется там, где рядом существуют многолетние legacy-системы, микросервисы, Kubernetes, собственный SOC и внешний сервис-провайдер. Участники видеоподкаста «Банковский SOC» Национального банковского журнала (NBJ) и Ассоциации ФинТех, который прошёл 22 сентября, обсудили, каким должен быть современный SOC в финансово-кредитной организации, и почему автоматизация без выстроенных процессов способна не ускорить, а затормозить реагирование.

Участники подкаста:

Ведущий: Александр ТОВСТОЛИП, руководитель Управления информационной безопасности, Ассоциация ФинТех;

Константин МУШОВЕЦ, директор УЦСБ SOC;

Евгений ГУЛЯЕВ, руководитель отдела поддержки продаж, R-Vision;

Евгений КАНТЫШЕВ, руководитель группы аналитики и операционного развития, Solar;

Виталий ГЛИНСКИЙ, руководитель Центра противодействия кибератакам, ДOМ.РФ Банк.

От legacy до Kubernetes: современному SOC приходится работать сразу в нескольких мирах

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

По мнению директора УЦСБ SOC Константина Мушовца, ключевое требование к современному SOC – способность гибко перестраиваться при появлении новых типов активов, сервисов и угроз.

«Современный SOC должен уметь быстро адаптироваться под изменяющиеся технологии», – отмечает эксперт. Даже если сегодня банк построен преимущественно на тяжёлой legacy-инфраструктуре, завтра после объединения или поглощения в его ИТ-контуре могут появиться микросервисные системы, которые потребуют совершенно иных инструментов мониторинга.

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

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

И здесь возникает важное ограничение: повышение уровня защиты не должно нарушать бизнес-процесс.

Главная проблема legacy: защищать систему, которую нельзя просто заменить

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

Руководитель Центра противодействия кибератакам ДОМ.РФ Банка Виталий Глинский обращает внимание на принцип, который в отношении подобных систем должен быть определяющим: «не навреди». В некоторых организациях за старую систему отвечает один специалист, который обладает уникальной экспертизой, а сама система может не поддерживать даже полноценное журналирование действий. В таких условиях стандартный подход к мониторингу оказывается неприменимым.

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

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

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

Внешний и внутренний SOC: кто отвечает за инцидент

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

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

«Ответственность всегда лежит на банке», – подчеркивает эксперт. Внешние сервисы становятся инструментами службы информационной безопасности, но не заменяют саму ответственность организации.

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

Здесь важны не только договорные документы, но и playbook – заранее подготовленные сценарии реагирования. Однако даже хорошо прописанная схема на бумаге не гарантирует, что в реальном инциденте всё сработает.

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

Почему внешний SOC не может заменить внутреннюю команду

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

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

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

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

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

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

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

Российский SOC после ухода западных решений: что изменилось на рынке

Отдельная тема – развитие российского рынка SOC-решений после ухода крупных зарубежных поставщиков. По словам руководителя отдела поддержки продаж R-Vision Евгения Гуляева, одним из главных результатов этого процесса стал рост технологического суверенитета.

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

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

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

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

Виталий Глинский считает этот разрыв скорее этапом развития, чем нерешаемой проблемой. Крупные зарубежные поставщики десятилетиями накапливали аналитику, создавали экосистемы и сообщества пользователей, формировали маркетплейсы дополнительных решений. Российскому рынку предстоит пройти этот путь быстрее, но часть компетенций уже формируется. При этом близость отечественных разработчиков к заказчикам даёт российским банкам важное преимущество – более оперативную коммуникацию и возможность быстро влиять на развитие продукта.

Где заканчивается автоматизация и начинается аналитик

Ещё один вопрос, который становится особенно важным для банковского SOC, – насколько далеко можно зайти в автоматизации расследования и реагирования.

Современные SOAR-решения позволяют собирать информацию об инциденте, обогащать её, формировать карточку события и готовить данные для передачи регулятору. Это существенно сокращает объём ручной работы.

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

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

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

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

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

Но автоматизация сама по себе не является гарантией эффективности.

«Автоматизировать хаос» нельзя: сначала процессы, потом технологии

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

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

Именно поэтому фраза ведущего подкаста Александра Товстолипа – «если автоматизировать хаос, то получишь автоматизированный хаос» – фактически стала одним из ключевых выводов обсуждения.

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

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

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

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

Полная версия видео подкаста доступна на VK видео и Rutube

Текст: Оксана Дяченко

Материал также опубликован в печатной версии Национального банковского журнала (октябрь 2026)