О чем материал
Рассказываем о ландшафте и трендах киберугроз в современном финтехе
Какие тренды киберугроз вы выделяете в современном финтехе?
Они все те же и продолжают набирать обороты: DDoS, утечки и шифрование. Причем с DDoS в прошлом году было попроще, чем в 2024-м. Сейчас мы видим явный тренд: атаки стали более таргетированными и длительными (атака может длиться больше месяца). В 2024 г. мы изучили подходы хакеров, приспособились и успешно им противостояли (у злоумышленников в принципе не получалось повлиять на доступность наших систем), а в 2025-м они пришли с новыми техниками и тактиками. Раньше меняли типы атак каждый час, а сейчас — раз в несколько минут.
Атаки на подрядчиков усилились: многих зашифровали через разработчиков (например, «1С») или взломали через open source библиотеки, утилиты или npm. Вы наверняка слышали про злоумышленника, который взломал аккаунт разработчика npm-пакета, заразил миллионы компьютеров по всему миру и пытался украсть из криптокошельков деньги, летающие через фронты. Однако что-то пошло не так: видимо, программировать зловредный код ему помогал ИИ. Когда стали анализировать, сколько денег наскреб хакер, оказалось, что около 505 долл. То есть заразил миллионы, а наскреб всего 505 долл. — огонь :)
Участилось применение дропов — инструментов, которые проникают на компьютер жертвы и подтягивают за собой другие вредоносные компоненты. Небезызвестные «Киберпартизаны», к примеру, шифруют полезные нагрузки под конкретные машины. Ни в каких других условиях зловред себя не выдает и выполняет только легальные операции, поэтому свободно проходит песочницы и компьютеры форензеров. Но как только оказывается на месте назначения, расшифровывается и показывает себя в полный рост.
Социнженерия тоже не стоит на месте. В августе 2024 г. начались атаки формата «фейк-босс»: злоумышленник представлялся председателем или руководителем компании и просил сотрудника что-то сделать. Теперь схема расширилась: к примеру, появились фейк-менеджеры премиального обслуживания. Они связываются с VIP-клиентом, записывают дипфейк-кружочки и предлагают «пообщаться по поводу финансовых услуг». Другой новый паттерн — фейковые партнеры. Атакующие представляются контрагентами компании и пытаются попасть в инфраструктуру: просят открыть вредоносный файлик или что-то в этом духе. При этом сама техника не новая, она применялась еще в начале 2020-х, но с развитием ИИ и удаленных коммуникаций проводить такие атаки стало проще.
Помню, как в начале 2020-х злоумышленники пришли в офис одной компании и под видом демонстрации продукта попросили генерального директора запустить вредоносный файл, потому что у них были «неполадки с компьютером». К счастью, SOC и СЗИ (EDR, песочница и т. д.) сразу выявили, что это троян. Но прецедент был интересный: офлайн-атаки встречаются не так уж часто.
Еще из интересного — атаки на СМС-провайдеров. Они начались летом 2024 г., а сейчас продолжаются с новой силой. Дело в том, что между операторами сотовой связи, их клиентами, банками и сервисами есть прослойка СМС-провайдеров, которые чаще всего не слишком хорошо защищены. Сообщения летают в открытом виде, злоумышленники их перехватывают и пытаются использовать в своих целях. Так, набор «СМС + номер телефона + номер паспорта (который можно найти в даркнете)» открывает большие возможности. Например, можно зарегистрироваться в микрофинансовой организации и взять кредит... Хорошо, если банк имеет прямой стык с сотовым оператором для оправки СМС.
Когда безопасность становится узким горлышком, а когда — драйвером инноваций?
Кибербез становится узким горлышком, если занимает излишне запретительную позицию. Здесь многое зависит от стиля управления в компании, роли CISO, его лояльности и влияния, но в целом такая ситуация, к сожалению, встречается довольно часто. Еще один сценарий — нехватка ресурсов. Допустим, бизнес быстро бежит вперед и внедряет новые технологии: микросервисную архитектуру, гринпламы, тот же GraphQL (в безопасности которого, к слову, разбираются далеко не все). При этом у ИБ-службы нет ресурсов вникать в защиту новых инструментов, поэтому они вынуждены либо запрещать, либо прятаться со словами «этого не существует, это вне нашего скоупа» :) Наконец, еще одним узким горлышком могут стать SLA, а точнее их несоблюдение. Например, когда ИБ-согласование фичи длится дольше, чем ее разработка.
С другой стороны, применение подхода Shift Left Security, наоборот, помогает драйвить бизнес. Чем «левее» безопасность интегрирована в процесс разработки, тем больше шансов, что вам не придется в последний момент тормозить релиз и срочно закрывать уязвимости. Или вообще разбираться с последствиями успешной атаки...
Наконец, топ-менеджмент должен быть заинтересован в ИБ, понимать современные угрозы, уделять достаточно внимания и финансирования — без этого никак. Некоторые вообще делают ИБ одной из фич компании (а заодно маркетинговым преимуществом) и идут на рынок со словами «Мы — самый безопасный банк!» или «Мы реализовали самый безопасный платеж!».
Внутренняя популяризация ИБ крайне важна. Вовлечение сотрудников включает целый комплекс практик: ИБ-туры, киберучения, security-чемпионов, рассылки, новости и т. д. Важно донести до людей проблематику, объяснить, что инфобез — не просто череда запретительных мер, а реальная необходимость (особенно в условиях международных кибервойн). А там, глядишь, и финансисты сами предложат сделать passwordless-аутентификацию: «Это же круто и удобно, мы готовы профинансировать, а то уже замучились с вашими 15-символьными паролями» :) Или CPO начнет больше заботиться о безопасности, потому что поймет: лучше подумать об этом заранее, чем каждый раз разгребать косяки перед выходом в продакшн.
Как вам удается держать баланс между скоростью выпуска и безопасностью релизов?
Важно правильно выстроить процесс проверки и, опять же, как можно «левее» интегрировать ИБ в пайплайн. Наименее чувствительные изменения (например, во фронте или дизайне) можно оперативно выпускать без предварительного согласования и проверять в рамках регулярных пентестов. Но для критичных зон (аутентификация, платежи, персональные данные, банковская тайна) мы всегда проводим полноценный security review.
Отдельная практика — рейтинговая модель разработчиков. Команды с высоким security-рейтингом могут проводить изменения в зонах средней и высокой критичности без ревью, потому что уже доказали свою компетентность. То есть мы в какой-то степени отпускаем их в самостоятельное плавание, но эпизодически (например, раз в месяц) приходим и все перепроверяем.
При этом в каждой команде есть security-чемпион. Многие считают эту практику неэффективной, но, на мой взгляд, достаточно правильно выстраивать мотивацию. Основной стимул должен быть не в деньгах, потому что люди склонны врать для получения финансовой выгоды. Мы даем другие плюшки: прокачиваем специалистов и активно вкладываемся в их развитие. Если сотрудник горит работой, он будет делать все хорошо и быстро. Конечно, его скорость напрямую зависит и от установленных SLA, но без четкой внутренней мотивации это не сработает.
Приведу пример быстрого релиза в «МТС Банке». Запуск продукта занял совсем мало времени, и это включая отдельную инфраструктуру, мобильные приложения, АБС и все-все-все. Причем мы проверяли его со всех сторон. Естественно, выпустить суперидеал за полгода сложно и что-то мы дотачивали уже в проде, но в целом это хорошая иллюстрация того, как ИБ, бизнес и ИТ слаженно отработали в одной упряжке.
Угрозы и технологии
В чем особенность ландшафта угроз mobile-first-банка?
В целом он сопоставим с традиционными банками, но в копилку добавляется ряд специфичных атак. Допустим, злоумышленники могут раздебажить вшитые в приложения сертификаты/секреты и пойти ковырять апишку. Такие угрозы характерны для всей мобилки, не только банковской.
При этом практика показывает, что mobile-first-банки зачастую защищены лучше, чем традиционные. Для веба придумано много эмуляторов (тот же Selenium), которые затрудняют определение мошенников. Мобильное приложение позволяет собирать больше телеметрии и контекста: серийный номер и IMEI устройства, номер телефона, информацию о сим-карте и т. д. Благодаря этому вы сразу видите любые манипуляции — рутованные устройства, запуск из-под Android- или IOS-эмулятора с фермы (например, Genymotion) и др.
Однажды мы накрыли ферму: выявили, что нас щупают в попытках найти уязвимости, начали расследование, привлекли доблестные спецслужбы. В итоге вышли на человека, который, оказывается, «просто продавал у себя в квартире стойкоместо». Чего только не придумают в оправдание :)
Облака, микросервисная архитектура, API и другие современные технологии ускоряют разработку, но размывают традиционный ИБ-периметр. Как вы решаете задачи по их защите?
С API все просто: защита лицензируется, покупается и работает. В хороших WAF-решениях для этого есть специальные механизмы. В дополнение можно использовать AST, багбаунти и классические пентесты.
Что касается микросервисов, в России есть крутые решения, которые можно применять и на этапе деплоя, и в рантайме. Мы используем платные решения для сложной защиты рантайма и open source для проверки контейнеров (тот же Trivy) и поиска секретов (gitleaks, trufflehog): зачем платить, если и так хорошо работает.
С облаками ситуация сложнее. Если в облако выносятся клиентские данные, к провайдеру возникают жесткие требования в части безопасности. Допустим, злоумышленник стал клиентом того же cloud-сервиса, заказал себе личное облако и горизонтально проник в банковское пространство. Такие атаки возможны, например, через взлом облачного кликхауса — как сервиса, который предоставляет возможность делать XML-инъекции. Кто в этом случае будет нести ответственность? Конечно же, финансовая организация. Чтобы минимизировать риски, необходимо тщательно подходить к выбору провайдера и коллабиться с ним в вопросах защищенности. Мы, к примеру, договаривались с некоторыми сервисами, чтобы они реализовали наши дополнительные хотелки и передавали все логи по нашим устройствам — многие легко на это соглашались.
Какие еще технологии и ИБ-продукты вы используете для защиты от киберугроз?
Уже упомянутые тулы для проверки безопасности контейнеров, а также SCA, SAST, WAF и другие стандартные AppSec-инструменты. Еще ASOC — очень полезная вещь: позволяет собирать в одном месте все уязвимости, связанные именно с разработкой, и управлять ими в рамках отдельных команд. Можно формировать белые списки, принимать риски по упрощенной процедуре и т. д. Также мы внедряем подпись образов, чтобы выявлять различия между исходным кодом образа на проде и тем, что лежит в централизованном репозитории.
В этом году планируем реализовать механизм превентивного обнаружения шеллкода в инфраструктуре микросервисов — по сути, что-то вроде песочницы для кубера. Предположим, у вас возникнет RCE-уязвимость. Как в этом случае быстро обнаружить спящий шеллкод, который могут залить и не использовать до нужного времени? Есть идея применить для этого ИИ. Мы уже исследуем этот подход: собираем все файлики, PHP-, Python- и другие скрипты в одну корзину для анализа. Таким образом, мы обнаруживаем проникновение раньше, чем сработает рантайм-защита.
Концепция периметра безопасности еще работает или нам всем пора переходить к Zero Trust?
Если мы говорим про инфраструктурную защиту, целиком уйти в Zero Trust пока не получится, потому что в России нет подходящих решений. За рубежом, например, можно поставить Cisco ACI, а у нас с подобными продуктами сложно. Поэтому полноценный Zero Trust — это молодежно, но в наших просторах реализуется иным путем. Мы действуем по принципу «хочешь сделать хорошо — сделай сам»: тот же Zero Trust можно реализовать с помощью собственной разработки, которая в одном месте управляет host-based firewall (HBF) и network policies в кубернетесе.
Проблемы сближают
Расскажите о взаимодействии между ИБ- и бизнес-подразделениями «МТС Банка».
Чтобы выстроить конструктивный диалог с бизнесом, нужно активно работать с руководителями подразделений. Вовлекать их в проблематику, рассказывать, чем вообще занимаются «эти ваши инфобезники», проводить регулярные one-to-one и помогать решать их задачи.
Кроме того, сейчас мы стараемся чаще соглашаться на инициативы от коллег: по сути, меняем политику «нет» на более доверительную «да, если». Грубо говоря, не нужно сразу отказывать, когда к тебе приходят с просьбой: «Нам нужен искусственный интеллект!» (читай: хотим все сливать ChatGPT). Можно ответить: «Ребят, конечно! Если сделаете локальную копию, поставите туда AI’шный security gateway или организуете прокси и будете обезличивать данные — пожалуйста». Решение можно найти всегда, главное — желание :)
А вообще, проблемы сближают: в момент их решения как раз и выстраивается диалог, возникает доверие.
Какие ИБ-вызовы вы видите на горизонте 2–3 лет?
В первую очередь это применение ИИ для реализации атак. Вполне допустима ситуация, когда злоумышленники проникли в инфраструктуру и запускают туда ИИ-агенты, которые молниеносно размножаются, ищут уязвимости, заражают, шифруют и выносят данные. Раньше от момента взлома до реального импакта могли пройти месяцы и годы, но уже в ближайшее время этот цикл сократится. Возможно, до считанных часов или даже десятков минут. Вопрос в том, готовы ли мы будем реагировать с такой же скоростью…
Отдельно выделю риски, связанные с автоматизацией процесса поиска логических уязвимостей. Пока я знаю лишь об экспериментах в этом направлении у Palo Alto, но вполне допускаю, что уже через год эта история станет трендом. Речь, к примеру, о поиске IDOR — когда ты проникаешь со своим сессионным токеном в одного клиента и дергаешь API-ручки от имени другого. Думаю, в будущем злоумышленники смогут быстро находить ошибки в бизнес-логике приложений или логике интеграции между системами и сразу переходить к эксплуатации. Да, от этого можно защититься: есть багбаунти, AppSec-ревью перед продом, WAF, API-защита, антиботы и т. д. А вот от быстрого горизонтального перемещения хакеров в инфраструктуре защититься будет довольно сложно… Спасут только заранее построенная комплексная защита с подходом Zero Trust и автоматическое реагирование. Чем мы занимаемся и вам советуем :)
