Антифрод-команда замечает странное поведение: клиент входит с привычного устройства, но сессия выглядит иначе. Движения по экрану не похожи на обычный сценарий, появляются попытки открыть банковское приложение поверх подозрительной активности, а затем меняется профиль риска операции. Если устройство заражено мобильным вредоносом, одного факта успешной аутентификации уже недостаточно.
AI в таком вредоносе важен не как фантастическая автономия, а как усилитель адаптации. Вредонос может лучше распознавать состояние экрана, подстраивать шаги под интерфейс, выбирать момент для перехвата и обходить простые проверки. Защитнику нужно искать не один индикатор, а связку поведения устройства, приложения и пользователя.
Классическая защита часто разделяет зоны ответственности: SOC смотрит сеть и конечные точки, антифрод смотрит операции, мобильная команда смотрит приложение. В банковском мобильном инциденте эти данные нужно соединять. Иначе каждая команда видит только слабый сигнал и не понимает, что перед ней заражённое устройство.
Практическая задача — построить карту телеметрии: какие события собирает приложение, какие сигналы даёт устройство, какие операции попадают в риск-модель и когда сессия должна требовать дополнительную проверку.
Какие признаки искать
Заражённое устройство редко выглядит как отдельная яркая тревога. Чаще это набор небольших отклонений: необычные разрешения, наложение поверх окна, изменение скорости действий, включение служб доступности, подозрительные сетевые обращения и операции в непривычной последовательности.
AI-усиленный вредонос может снижать шум: ждать подходящего экрана, не выполнять действия постоянно, использовать легитимные разрешения. Поэтому правила должны учитывать контекст сессии, а не только наличие известного файла.
- включение службы доступности без бизнес-причины;
- наложение поверх банковского приложения;
- резкая смена скорости ввода;
- необычные переходы между экранами;
- новые сетевые направления с устройства;
- операция сразу после изменения поведения;
- повторные попытки пройти дополнительную проверку.
Связка SOC и антифрода
SOC может увидеть заражение, но не знать, была ли финансовая операция. Антифрод может увидеть риск операции, но не знать, что устройство уже подозрительное. Нужен общий идентификатор сессии или события, который связывает мобильную телеметрию, вход, устройство и платёж.
Хорошая схема не передаёт лишние персональные данные. Достаточно передавать уровень риска, тип события, время, идентификатор устройства, состояние приложения и ссылку на внутреннее расследование.
- device_id и app_session_id;
- уровень доверия устройству;
- сигнал службы доступности;
- факт наложения окна;
- тип операции и сумма;
- результат дополнительной проверки;
- решение антифрод-модели.
Как реагировать безопасно
Блокировка каждой подозрительной сессии может создать много ложных отказов. Лучше использовать ступени реакции: предупреждение, дополнительная проверка, ограничение операций, отзыв сессии, временная заморозка высокорискового платежа.
После подтверждения заражения нужно думать не только о конкретной операции. Нужно отозвать активные сессии, проверить связанные устройства, предупредить клиента, сохранить журналы и передать признаки в правила обнаружения.
- повысить уровень проверки для операции;
- запретить смену реквизитов из рискованной сессии;
- отозвать токены мобильного приложения;
- сохранить журнал поведения устройства;
- передать индикаторы в SOC;
- добавить сценарий в обучение антифрода.
Минимальный контур внедрения
Перед включением такого контроля в рабочую среду команда должна договориться, что именно считается безопасным действием. AI может помогать анализировать контекст, но не должен единолично менять доступы, маршруты, финансовые статусы или правила безопасности без проверяемого основания.
Контур внедрения лучше начинать с режима наблюдения. В этом режиме модель предлагает вывод, а человек подтверждает или отклоняет его. После накопления примеров можно разрешать частичную автоматизацию, но только для низкорисковых действий с понятным откатом.
- назначить владельца процесса и владельца данных;
- описать действия, которые требуют ручного подтверждения;
- сохранить версию политики и шаблона запроса;
- включить журнал причины решения;
- создать набор тестовых событий;
- раз в месяц пересматривать исключения.
Что проверять после запуска
После запуска нужно смотреть не только на количество срабатываний. Важнее понять, уменьшилась ли неопределённость для аналитика, стало ли меньше ручных проверок и не выросло ли число решений, которые никто не может объяснить.
Отдельно нужно учитывать ошибки модели. Если она стабильно пропускает один класс событий или слишком часто повышает риск нормальных действий, правило нельзя просто ужесточить. Нужно вернуться к данным, признакам и границам применения.
- доля событий с полным набором журналов;
- время до первичного вывода;
- число ручных откатов;
- доля ложных тревог;
- число исключений без владельца;
- качество объяснения решения.
Как собрать расследование без лишних данных
Расследование мобильного банковского инцидента не должно превращаться в сбор всего содержимого устройства. Достаточно минимального набора признаков: состояние разрешений, риск сессии, тип операции, результат проверки и временная шкала действий. Такой подход защищает приватность клиента и при этом даёт SOC достаточно контекста.
Для повторяемости полезно завести карточку события. В ней фиксируются сработавшие признаки, решение антифрода, подтверждение клиента и действия по восстановлению. Если похожие карточки начинают повторяться, команда получает основу для нового правила или модели риска.
- не сохранять содержимое экранов без отдельного основания;
- использовать обезличенный идентификатор устройства;
- фиксировать только рискованные разрешения и состояния;
- связывать событие с конкретной операцией;
- добавлять решение оператора и причину;
- передавать обобщённые признаки в обучение правил.
Финальная проверка должна быть простой: владелец процесса открывает карточку контроля и за несколько минут видит цель, данные, журнал, ответственного, последнее тестовое событие и срок следующего пересмотра. Если для ответа нужно собирать сведения вручную из нескольких команд, контроль ещё не стал рабочим.
