В последнее время киберпреступники всё чаще угрожают финансовому сектору и его клиентам. Банки и другие финансовые организации становятся их целью. Согласно статистике Центрального банка России, увеличилось количество операций без согласия клиентов (ОБС), при этом число компьютерных инцидентов снизилось. Однако общий уровень угроз остаётся высоким, что требует усиления мер защиты данных и финансовых операций.
Эффективная защита — это не только внутренние меры реагирования, но и активное взаимодействие с регуляторами. В 2015 году в Центральном банке Российской Федерации было создано особое структурное подразделение — ФинЦЕРТ. Его миссия — координация информационного обмена, контроль и содействие при возникновении инцидентов в финансовом секторе. В ФинЦЕРТе функционирует автоматизированная система обработки инцидентов (АСОИ), которая обеспечивает эффективный обмен данными.
Обработка большого объёма инцидентов и ОБС, ежедневно возникающих в банках, вручную — это очень ресурсозатратный процесс, особенно с учётом необходимости соблюдать нормативные сроки уведомления ФинЦЕРТ, установленные в Федеральных законах № 161-ФЗ, № 211-ФЗ и др. Формы и сроки взаимодействия участников с Банком России определены в стандарте Банка России СТО БР БФБО-1.5-2023.
Сроки уведомления об инцидентах ИБ и ОБС (если иное не предусмотрено нормативными актами Банка России) согласно СТО БР БФБО-1.5-2023:
-
в течение 3 часов с момента выявления инцидента защиты информации — для участников информационного взаимодействия, реализующих усиленный или стандартный уровни защиты в соответствии с ГОСТ Р 57580.1-2017;
-
в течение 24 часов с момента выявления инцидента защиты информации — для остальных участников информационного взаимодействия.
В крупных организациях передача инцидентов в АСОИ ФинЦЕРТ вручную становится серьёзной проблемой, требующей автоматизации. Это позволяет снизить нагрузку на сотрудников, уменьшить количество ошибок и ускорить процесс.
Таймлайн проекта
На изображении представлены ключевые этапы проекта: в сентябре 2022 года началась разработка сервиса, а в декабре того же года выпущена первая версия. В 2023 году выявили и устранили недостатки, а в октябре стартовала работа над второй версией. В 2024 году проект прошёл оптимизацию и подготовку к финальной адаптации, что улучшит взаимодействие с регулятором и ускорит процессы.
Анализ проблемы ручного взаимодействия с регулятором
Ручная обработка запросов через пользовательский интерфейс Личного кабинета АСОИ ФинЦЕРТ (ЛК) сопряжена с рядом сложностей:
-
Разрозненность данных — полная информация, необходимая для регистрации запроса в ЛК, может храниться в разных системах, что требует ручного сбора данных из нескольких источников.
-
Риски ошибок — при ручном заполнении электронных форм высока вероятность опечаток или неточностей из-за невнимательности.
-
Большие затраты времени — на заполнение одной формы уходит 5–10 минут, а в крупных организациях таких форм может быть сотни в день.
-
Постоянный мониторинг — требуется регулярно проверять ЛК или почтовые уведомления на наличие новых запросов или уточнений.
Эти факторы стали драйверами для создания интеграции R-Vision SOAR (далее — SOAR) с АСОИ ФинЦЕРТ.
Переход от коробочного решения к расширенной интеграции
В нашем SOAR уже давно реализован функционал, позволяющий передавать информацию об инцидентах в АСОИ ФинЦЕРТ и получать request-id из Личного кабинета АСОИ.
Однажды к нам обратился заказчик, который активно работает с АСОИ ФинЦЕРТ, и попросил расширить функционал взаимодействия с системой, доступный по API. В сентябре 2022 года мы начали работать над первой расширенной версией интеграции, которая должна была решить его проблему. Поскольку запрос был единичный, мы решили выполнить работу силами инженеров, не привлекая команду продуктовой разработки.
Первую версию интеграции мы представили в январе 2023 года. К тому моменту она выполняла следующие функции:
Интеграция успешно использовалась нашим заказчиком, а возникающие проблемы решались оперативно. Проект развивался хорошо, но мы решили не останавливаться на достигнутом. Команда провела анализ рынка, чтобы выявить возможности максимального использования функционала API АСОИ ФинЦЕРТ.
В результате, в октябре 2023 года мы пришли к идее расширить функционал и оптимизировать работу интеграции, превратив её в полноценный сервис, который можно предлагать другим клиентам. Таким образом, первую версию интеграции можно считать MVP.
Эволюция расширенной интеграции
Работа над второй версией расширенной интеграции началась с тщательного анализа пользовательских сценариев и недостатков текущей версии ещё в декабре 2024 года. Мы провели опрос среди наших клиентов, чтобы понять, насколько им интересен новый сервис, какие функции они хотели бы видеть и какие требования могут быть сформулированы со стороны конечного пользователя.
Основные недостатки и проблемы первой версии, которые необходимо было учесть при дальнейшей разработке:
-
В АСОИ ФинЦЕРТ к одному инциденту можно добавлять несколько форм ОБС, поэтому мы реализовали связь «один ко многим» между инцидентами и ОБС.
-
Система не поддерживала работу с влиянием различных типов атак – в электронных формах тип атаки всегда указывался как «иное».
-
Старые версии электронных форм не сохранялись.
-
Не была реализована надёжная доставка данных при возникновении сетевых проблем.
-
Обслуживание сервиса осложнялось: при изменении схем данных на стороне АСОИ ФинЦЕРТ приходилось вручную переписывать маппинг полей в коде.
Наша команда, основываясь на полученной информации и своей экспертизе, разработала техническое задание и описала пользовательские сценарии.
Основные процессы сервиса:
Мы изучили структуру запросов в личном кабинете АСОИ ФинЦЕРТ, а также схемы данных для взаимодействия через API. После этого мы разделили их на отдельные сущности, которые решили использовать в нашей SOAR-системе.
Модель взаимосвязей сущностей
Пример отображения запроса АСОИ ФинЦЕРТ в R-Vision SOAR
Сопоставление по разделам:
Аналогичную разбивку сделали для запроса по ОБС от регулятора
Отображение входящих запросов ОБС
Система SOAR в текущей версии поддерживает связи типа «Входит в» и «Связан с» для карточек. Это позволяет устанавливать связи между сущностями в форматах «один к одному», «один ко многим» и «многие ко многим». Кроме того, добавлена возможность отправлять электронные формы с учетом всех типов атак, указанных в АСОИ ФинЦЕРТ (влияние инцидента).
Создание удобной системы версионирования электронных форм
С конца декабря 2024 года проект перешел из активной фазы в режим «тишины» и только в марте 2024 года команда возобновила работу, сосредоточившись на улучшении удобства использования сервиса и его дальнейшей адаптации.
Мы добавили в SOAR новое поле для номера версии электронной формы (ЭФ). Каждую версию ЭФ можно сохранять как артефакт в разделе «Свидетельства» в формате JSON. Этот файл формируется автоматически, как только ЭФ поступает в АСОИ ФинЦЕРТ.
В фоновом режиме отправляется API-запрос на получение информации по ЭФ, затем система получает ответ в формате JSON, записывает его в файл и добавляет в раздел «Свидетельства».
Пример отображения версий в ЛК АСОИ ФинЦЕРТ:
Пример отображения версии электронной формы в SOAR:
Версионирования инцидентов в R-Vision SOAR
Основные функциональные изменения на этом завершены, теперь перейдем к техническим аспектам.
Техническая часть
Мы учли особенности асинхронного взаимодействия с АСОИ ФинЦЕРТ и перешли на использование очередей задач, что значительно снижает вероятность возникновения ошибок, связанных с сетью.
Сервис можно условно разделить на три основных компонента:
-
Сервис реагирования — отвечает за обработку запросов и отправку ответов в АСОИ ФинЦЕРТ.
-
Сервис, отвечающий за polling данных — периодически отправляет запросы к АСОИ ФинЦЕРТ для обновления информации.
-
Инициализатор — используется только для первичной синхронизации данных из АСОИ ФинЦЕРТ, что особенно важно, если заказчик ранее работал через личный кабинет и хочет продолжить работу с уже существующими запросами в SOAR или получить исторические данные для обеспечения достоверности.
Процесс инициализации выглядит следующим образом:
Схема взаимодействия между компонентами сервиса при первичном получении данных из АСОИ ФинЦЕРТ
-
Пользователь запускает коннектор, в котором указывает количество запросов для синхронизации (Поток 1).
-
Инициализатор обращается к АСОИ ФинЦЕРТ (Поток 2) и получает заданное количество записей (Поток 3).
-
Инициализатор обрабатывает полученные данные и отправляет запросы на создание и заполнение соответствующих карточек инцидентов в R-Vision SOAR (запросы, инциденты, входящие и исходящие формы ОБС, влияние инцидента, переписки и вложения в рамках запросов) (Поток 4).
Отдельно от первичной синхронизации постоянно работают два других компонента:
-
Сервис реагирования.
-
Сервис, отвечающий за polling данных.
Схема взаимодействия между компонентами сервиса
Сервис, отвечающий за polling данных
Сервис, отвечающий за polling данных, работает постоянно. Раз в n-ое количество времени, заданное в настройках, сервис, отвечающий за polling данных, обращается в АСОИ ФинЦЕРТ и запрашивает данные о появлении новых входящих запросов, а также данные по уже созданным открытым запросам (поток 5). Сервис, отвечающий за polling данных, получает ответ от АСОИ ФинЦЕРТ о наличии таких данных (поток 6). В случае наличия таких данных в АСОИ ФинЦЕРТ, сервис, отвечающий за polling данных, инициализирует в SOAR создание/обновление соответствующих карточек инцидентов, добавление комментариев или свидетельств (поток 7).
Настройка ретраев
Длительность периода каждого polling-запроса можно задать отдельно, чтобы приоритизировать получение определенных данных. Для надежной доставки мы добавили настройку повторных запросов (ретраев). Клиент может задать их количество и периодичность в зависимости от ресурсов и потребностей.
Повторная отправка сократила количество ошибок, но в некоторых случаях требуется вмешательство оператора. Например, если исчерпаны все ретраи и доставка данных не гарантирована или если один из компонентов сетевой цепочки не отвечает, инцидент обрабатывается вручную.
Минимизация ошибок
Чтобы минимизировать сетевые ошибки, мы добавили healthcheck-и для проверки работоспособности интеграции и доступа к АСОИ ФинЦЕРТ.
В SOAR отображаются не только сетевые ошибки, но и ошибки бизнес-логики, а также сообщения об ошибках от АСОИ ФинЦЕРТ. Это позволяет своевременно выявлять и устранять проблемы.
Динамический маппинг
Важное изменение — добавление динамического маппинга. Мы отказались от жесткой привязки полей из структуры ответа к тегам в SOAR и внедрили обработку, которая автоматически преобразует их на основе названий тегов. Это упростило поддержку интеграции и исключило необходимость прописывать сопоставление полей в коде. В результате пользователь получает актуальные данные из АСОИ ФинЦЕРТ.
Ниже приведен пример метода сканирования во влиянии инцидента и типа атаки (scanPorts).
Поле «Метод сканирования» в ЛК АСОИ ФинЦЕРТ
Поле «Метод сканирования» в API-схеме АСОИ ФинЦЕРТ
Пример структуры запроса с полем «Метод сканирования»
У нас есть параметры для маппинга:
-
Префикс для всех полей, которые мапятся в RVN из ФинЦЕРТ и обратно: «f» (нужен, чтобы не путать с полями, которые не относятся к интеграции).
-
Разделитель, по которому строится регистр у частей ключа поля: «_».
-
Разделитель, по которому формируются вложенные структуры: «__».
-
Описание поля в SOAR.
Пример тега с параметрами маппинга
Сервис собирает поля по тегам и формирует JSON-структуру, которую отправляет в АСОИ ФинЦЕРТ.
Динамический маппинг исключает статическую запись параметров в коде и упрощает работу с новыми полями в АСОИ ФинЦЕРТ. Чтобы получать и отправлять данные из новых полей, достаточно создать их с соответствующими тегами в веб-интерфейсе SOAR — без изменения кода интеграции.
Адаптация интеграции для пользователя
Параллельно с разработкой мы начали адаптацию интеграции для пользователей. На этом этапе существовал условный конструктор, где все связи приходилось настраивать вручную. Для отправки данных пользователь запускал коннекторы. Статус отправки, форматы системных сообщений и ошибок тогда еще не были определены.
На этом этапе к работе присоединилась я как бизнес-аналитик. Моя задача — адаптировать сервис под нужды пользователей и сделать его удобнее.
Кроме того, мы добавили автоматические связи карточек, устанавливаемые коннекторами. Например, если пользователю нужно добавить ОБС к инциденту, он нажимает кнопку «Добавить форму ОБС». Затем запускается коннектор, который делает API-запрос к SOAR и создает карточку типа «Исходящая ОБС» со связями: «связан с» — инцидентом, «входит в» — обращением или запросом (зависит от сущности).
Процесс добавления ОБС из инцидента
Такие сценарии помогают автоматизировать процесс, когда форма ОБС добавляется не по инициативе пользователя, а в результате интеграции с другой системой.
Также мы с командой добавили возможность отправки сообщения через раздел «Комментарии» без запуска коннектора, а по системному триггеру «Добавление комментария». Здесь работает обработчик, проверяющий, что сообщение удовлетворяет формату сообщений, которые необходимо отправить в АСОИ ФинЦЕРТ, если сообщение уже обрабатывается и пользователь добавляет новое, мы выводим системный комментарий:
Пример коммуникации с регулятором в R-Vision SOAR
Кроме того, мы внедрили статусную модель отправки данных:
-
отправка запущена;
-
отправка успешно завершена;
-
отправка завершена с ошибкой.
Эта модель позволяет легко фильтровать запросы по статусам и находить данные, которые были отправлены с ошибками.
Мы создали модель данных для нашего сервиса и настроили отображение карточек в соответствии с этой моделью. Например, в форме ОБС в зависимости от способа реализации перевода отображается различный набор полей.
Пример карточки с настроенными зависимостями
После проработки бизнес-логики в июне 2024 года мы приступили к созданию пользовательской документации. В ней подробно описаны настройки, компоненты интеграции, связи между сущностями, пользовательские сценарии и другие важные аспекты, необходимые для эксплуатации системы.
На этом этапе интеграция была завершена, и команда перешла к тестированию.
Вместо ручного тестирования силами разработчиков мы привлекли квалифицированного тестировщика. Была создана коллекция сквозных (E2E) тестов для смоук- и регрессионного тестирования, включающая около 150 сценариев. Автотесты, связанные с интеграцией, стали писать рядом с кодом. Нагрузочное тестирование выявило и помогло исправить ряд багов, что повысило качество системы.
Завершаем интеграцию
Интеграция готова к внедрению и эксплуатации. Мы провели все необходимые тесты и подготовили исчерпывающую документацию. Но что же могло пойти не так?
Вернемся к вопросу динамического сопоставления полей. Рассмотрим пример: в форме ОБС может быть представлено восемь различных реализаций, что схематически представлено на рисунке ниже.
Пример полей «Сумма операции» в структуре API-схемы АСОИ ФинЦЕРТ
В связи с этим, для реализации динамического маппинга в соответствии со схемой данных необходимо добавить восемь полей с одинаковым названием «Сумма операции» и разными тегами.
Дублирование тегов полей «Сумма операции»
Однако, переключившись с логики интеграции на множество одинаковых полей в формах ОБС и влияниях инцидентов, мы увидели точку роста. Большое количество полей затрудняло настройку сценариев в SOAR, запутывало пользователей при настройке представлений и мешало фильтровать ОБС по одному полю.
Перед релизом сервиса в сентябре 2024 года мы выявили эту проблему и приступили к финальной доработке. Решение оказалось простым: сервис должен опираться на теги, соответствующие схемам данных АСОИ ФинЦЕРТ, а в UI мы объединили условно одинаковые поля в одно. Это преобразование выполнено как на уровне сервиса, так и в UI.
Результат преобразования тегов полей «Сумма операции»
Обратное преобразование тегов в зависимости от способа реализации перевода
Наша команда в приоритетном порядке разработала и внедрила архитектурные изменения. Мы добавили обработку в интеграцию, скорректировали модель данных и документацию, а также успешно протестировали оптимизированный сервис для заказчика.
После завершения этих задач работа не останавливается. Мы следим за изменениями в API, составе полей и новыми требованиями регулятора на информационном портале АСОИ, чтобы оперативно адаптировать интеграцию и поддерживать пользователей. Эксперты команды помогают встроить сервис в существующий процесс управления инцидентами и адаптировать его под нужды заказчика.
P.S.
Финансовый сектор сталкивается с ростом киберугроз и требует эффективных решений для взаимодействия с регулятором. Опыт разработки интеграции между SOAR и АСОИ ФинЦЕРТ показывает, как автоматизация помогает оптимизировать процессы, снижать риски ошибок и ускорять обработку инцидентов.
Интеграция значительно расширила функциональность системы, охватив ключевые сценарии: обработку сообщений, передачу электронных форм, версионирование. Особое внимание уделено удобству пользователей: адаптирован интерфейс, добавлены автоматизированные связи между элементами системы, упрощена поддержка благодаря динамическому маппингу.
Проделанная работа повысила скорость и точность обработки инцидентов, а также улучшила пользовательский опыт. Это стало возможным благодаря упрощению процессов и устранению недостатков, присущих ручной обработке данных.
