Как это работает: банки, металлургия и цифровые двойники на Standoff

Банки

Финансовая отрасль — самая крупная на киберполигоне. Банковская система нашего виртуального государства состоит из трех коммерческих банков и центрального банка, который отвечает за межбанковские платежи и хранит информацию о деятельности остальных банков. При разработке отраслевого сегмента мы ориентировались на реальные бизнес-процессы российских компаний и реализовали типовые B2B-, B2C-, С2С-, C2B- и межбанковские операции. 

К примеру, мы полностью воспроизвели на полигоне процесс обслуживания юридических лиц — от открытия расчетного счета, регистрации сотрудников и выдачи ключей для подписи платежных документов до формирования платежных поручений, отчетности и интеграции с 1С. Кроме того, мы реализовали автоматизированную цепочку проведения межбанковских платежей и даже функционал оплаты товаров по QR-кодам (через СБП).

В Commercial Bank of Standoff установлена АБС одного из ведущих вендоров банковского софта в России. АБС является ядром любого банка, но для ее работы необходима инфраструктурная обвязка в виде полноценного Windows-офиса (с доменом, пользователями и сетевым разграничением сегментов). Все это мы реализовали на киберполигоне.

First Partner Bank предлагает пользователям вендорское решение по эквайрингу через СБП и 2FA для подтверждения платежей. Серверная часть частично работает «из коробки», а клиентскую и middleware мы написали сами. Таким образом, в банке появилось мобильное приложение для телефонов на Android, четыре магазина,  товары из которых можно оплатить по QR-кодам, а также набор микросервисов, которые эмулируют ответы от продуктивных сред и проставляют статусы оплаты в магазинах.

Межбанковские транзакции

В основу нашей модели межбанковских транзакций легла система передачи финансовых сообщений ЦБ РФ. В качестве форматов для обмена информацией о платежах мы использовали УФЭБС (унифицированные форматы электронных банковских сообщений). Процесс проведения платежей выглядит следующим образом:

• Все начинается с формирования платежного поручения в АБС любого из банков виртуального государства. На выходе получаем набор документов в формате ED101. 
• Документы подхватывает эмуляция АРМ КБР, которая отвечает за подпись, шифрование и передачу входящих и исходящих сообщений.
• Подписанное и зашифрованное сообщение передается на сервер, где специальный микросервис его расшифровывает, определяет банк-получатель и перекладывает поручение в папку со входящими документами.
• В банке-получателе тоже работает экземпляр эмулятора АРМ КБР, который проверяет папку со входящими документами на сервере ЦБ.
• Входящие документы расшифровываются, проверяются на целостность и перекладываются в АБС.
• Для эмуляции работы операционистов банка и специалистов отдела корреспондентских счетов в АБС мы использовали инструмент для Unit-тестирования — CodedUI. Скрипт запускает терминал, авторизовывается и производит все необходимые действия для зачисления средств на счета клиентов.

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

Оплата по QR-кодам

Отдельно остановимся на функционале оплаты товаров по QR-кодам через СБП. В общих чертах процесс выглядит следующим образом:

1. Пользователь формирует корзину товаров в магазине и оформляет заказ.
2. Магазин обращается к API вендорской системы и запрашивает регистрацию QR-кода. В ответ получает картинку с кодом, которую отображает пользователю (см. рис. 3), а параллельно сохраняет информацию о содержимом кода в служебных полях заказа.

3. Пользователь открывает мобильное приложение и наводит камеру на QR-код. После считывания кода приложение предлагает выбрать счет для оплаты. Если средств не хватает, операция попадает в список отложенных платежей, которые нужно подтвердить через 2FA.
4. Пользователь выбирает платеж из списка и нажимает «Подтвердить». С помощью технологии deeplink Android перенаправляет пользователя в вендорское приложение для двухфакторной авторизации, где можно подтвердить платеж с помощью кода или биометрии.
5. В случае успешного подтверждения платежа серверная часть 2FA-сервиса отправляет запрос в АБС на проведение платежа.
6. АБС замораживает деньги на счете пользователя и обращается к вендорской части, которая занимается обработкой СБП-платежей.
7. Серверный софт проверяет наличие QR-кода в системе, а также целостность полезной нагрузки. При успешном прохождении всех проверок платеж помечается в эмуляторе как оплаченный. Уведомление об оплате отправляется в специальную Nats-очередь.
8. Nats-очередь «слушает» микросервис на хостинге. При появлении идентификаторов оплаченных QR-кодов он проходит по webhook api, и магазины проставляют соответствующим заказам завершенный статус.
9. После оплаты заказа пользователь может перезагрузить страницу и скачать купленные товары.

Металлургия

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

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

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

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

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

Готовая жидкая сталь доставляется до машины непрерывного литья заготовок (МНЛЗ), где кристаллизуется, отливается в прямоугольную заготовку и нарезается на слябы. 

Прокатный стан

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

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

Производство губчатого титана

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

Здесь хакеры могут устроить утечку хлорсодержащего газа (открыть задвижку дегазации в процессе подачи газа в реторту) или подменить данные на экране оператора производства.

Кейс: реализация недопустимого события

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

1. Хакеры нашли уязвимость CVE-2022-24706 в СУБД и получили доступ во внутреннюю сеть предприятия.
2. На лендинге атакующие обнаружили email’ы сотрудников. Подобрали пароли (они были простыми и короткими), зашли в почту и от имени пользователей разослали по компании фишинговые письма. Один из сотрудников открыл письмо, и атакующие получили доступ к его компьютеру.
3. Двигаясь по корпоративной сети, хакеры заметили, что версия Confluence (корпоративная база знаний) подвержена уязвимости CVE-2023-22527. Проэксплуатировав ее, атакующие повысили себе права и добрались до учетных записей пользователей SCADA-систем.
4. Далее атакующие методично двигались от узла к узлу и строили сетевые тоннели, пока не добрались до системы управления кислородным конвертером. Хакеры выставили значение подачи кислорода, превышающее допустимый лимит, и тем самым реализовали недопустимое событие. 

Цифровые двойники

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

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

Мы детально погрузились в теоретические исследования по этой теме, а также стали изучать опыт компаний, которые анонсировали успешные проекты по созданию цифровых двойников для решения ИБ-задач. К сожалению, оказалось, что единой методологии создания цифровых двойников в данной области не существует. Более того, практически все примеры, которые мы проанализировали, по сути, не являлись цифровыми двойниками. Можно выделить лишь единичные успешные кейсы — например, интересный проект ENIGMA (sEcuriNg dIgitaltwins through GaMification Approach).

Подобные решения должны соответствовать двум критериям:

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

Если второй пункт не выполняется, речь идет о цифровой тени (digital shadow). Если не выполняется и первый, это просто цифровая модель (digital model). В большинстве примеров, которые мы изучили, компании ошибочно называли цифровыми двойниками именно модели и тени.

Стало понятно, что нам требуется собственная методика разработки цифровых двойников. Решение нашлось в методологии результативной кибербезопасности. Если кратко, мы решили сосредоточиться на недопустимых событиях и воссоздавать инфраструктуру целевых и ключевых систем, помещенную в обвязку игровых сервисов. Чтобы убедиться в правильности выбранного подхода, мы разработали цифрового двойника Positive Technologies. 

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

Затем мы выделили целевые системы — серверы GUS и FLUS (компоненты системы SupplyLab, которую разрабатывают наши эксперты). В раздел ключевых систем попали оставшиеся ИС, которые мы используем при разработке: компьютеры разработчиков, CI/CD и артефакторий. Для воссоздания целевых систем обратились за помощью к коллегам, которые занимаются SupplyLab. Ключевые воссоздавали самостоятельно, с помощью свободно распространяемых версий ПО (gitlab, gitlab-runners, jfrog artifactory). Также мы добавили в модель пользовательские компьютеры и серверы, которые характерны для большинства офисных инфраструктур, построенных на базе продуктов Microsoft.

Поскольку на офлайн-мероприятиях команды красных предпочитают атаковать уже знакомую им инфраструктуру, мы решили предоставить хакерам возможность изучить нашего двойника. Офис posi с двойником процесса разработки и поставки продуктов был доступен на платформе Standoff 365 с апреля по май 2024 г. Все установленные в виртуальном офисе СЗИ работали исключительно в режиме мониторинга, а заложенные нами векторы проникновения позволяли получить доступ к инфраструктуре и исследовать ее. В результате мы получили несколько отчетов о реализации НС. И тут следует отметить, что даже в отклоненных отчетах можно было найти весьма нетривиальные подходы. В качестве примера можно привести хищение ключей для доступа к артефакторию и размещение в нем «вредоносного» ПО собственной разработки (то есть исходный код продукта не модифицировался вообще).

В качестве второго НС мы выбрали «Хищение денежных средств в большом объеме». Для создания двойника бизнес-процесса мы обратились за помощью в финансовый департамент Positive Technologies и к коллегам, которые отвечают за 1С. Результатом стало описание процессов, связанных с движением денежных средств в компании, и соответствующих информационных систем. Как и в предыдущем примере, мы немного упростили бизнес-процесс и использовали нашего цифрового двойника на Standoff 13 в мае 2024 г. 

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

К ключевым системам мы отнесли сервисы сотрудников бухгалтерии и серверы баз данных, с которыми работает 1С.

Все указанные системы были интегрированы в ранее созданный офис. В дальнейшем нам оставалось просто донастроить игровые «тачки». Мы изменили учетные записи, политики безопасности, заложили новые векторы проникновения, а также перевели СЗИ офиса в режим реагирования. В таком виде мы выставили офис на Standoff 13 — в качестве финального испытания для самых сильных команд атакующих.

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

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

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