Почему CISO и antifraud должны видеть одну цепочку атаки

Пользователь получает phishing-сообщение.

Через infostealer злоумышленник получает credentials и session token. Входит в аккаунт с нового устройства. Меняет контактные данные. Через некоторое время оформляет продукт или инициирует перевод. Деньги уходят на новый beneficiary, а затем распределяются через сеть mule accounts.

Внутри компании всё это может превратиться сразу в несколько отдельных историй.

SOC расследует phishing и первоначальную компрометацию.

IAM восстанавливает доступ.

Antifraud анализирует подозрительную транзакцию.

Customer support общается с клиентом.

AML смотрит дальнейшее движение средств.

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

Потому что злоумышленник не знает, где в компании заканчивается SOC и начинается antifraud.

Эти границы существуют только внутри нашей оргструктуры. И слишком часто они помогают атакующему больше, чем защите.

Но если компрометация аккаунта и последующий вывод денег существуют в разных case management systems, имеют разные identifiers и расследуются без общего контекста, защитная модель уже отстаёт от модели атаки.

Для SOC успешный containment иногда выглядит вполне убедительно.

Phishing domain заблокирован.

Malicious process удалён.

Credentials сброшены.

Session отозвана.

Endpoint очищен.

Ticket закрыт.

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

Он просто перешёл в другой бизнес-процесс.

И здесь возникает опасный эффект организационной декомпозиции.

Security отвечает за compromise.

Antifraud — за transaction.

IAM — за identity.

Support — за восстановление клиента.

AML — за движение денег.

У каждой функции есть собственный SLA, dashboards, workflows и KPI.

Но у атакующего KPI один:

получить ценность из компрометации.

Поэтому я бы оценивал зрелость не только по тому, насколько хорошо работают отдельные функции, но и по тому, способны ли они восстановить end-to-end attack narrative.

Представим, что SOC обнаружил:

Для классической cyber-модели это indicators of compromise.

Для antifraud это может быть контекст, радикально меняющий оценку следующей транзакции.

Операция сама по себе может выглядеть почти нормально:

привычная сумма, допустимый регион, корректная аутентификация, никаких очевидных velocity anomalies.

Но если transaction engine знает, что identity десять минут назад была связана с подтверждённым session theft, риск уже другой.

Именно здесь cybersecurity способен дать antifraud то, чего не видно из финансовой операции.

Контекст того, что произошло до денег.

Обмен должен работать в обе стороны.

Предположим, antifraud видит странную последовательность:

новое устройство → изменение телефона → новый beneficiary → unusual transaction → обращение в support.

Endpoint protection ничего не обнаружил.

SOC не имеет подтверждённого alert.

IAM считает authentication успешной.

Если fraud anomaly остаётся внутри antifraud-платформы, security может никогда не получить сигнал о возможной краже session, malware или социальной инженерии.

То есть финансовая аномалия иногда является первым evidence киберкомпрометации, а не её последствием.

Это важный сдвиг в operating model.

Cybersecurity не должна рассматривать antifraud только как получателя security intelligence.

Antifraud — полноценный sensor для cyber detection.

Основная техническая и процессная проблема — отсутствие связующего объекта.

У SOC есть alert ID.

У IAM — request или identity event.

У antifraud — transaction case.

У customer support — обращение клиента.

У AML — собственный case.

Одну атаку организация превращает в пять сущностей.

Я бы строил общий case model вокруг единой цепочки:

identity → device → session → behavior → account changes → transaction → beneficiary → customer impact.

И связывал её через common case ID.

Это не означает, что все команды обязаны работать в одной системе.

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

Тогда расследователь видит не набор alerts, а последовательность:

phishing→ stolen credentials→ session takeover→ trusted device change→ beneficiary creation→ transfer→ cash-out.

Именно такой видит атаку сам злоумышленник.

Я не предлагаю CISO забирать antifraud под своё управление.

Задача CISO в другом.

Нужно выйти за рамки собственной контрольной зоны и спросить:

что происходит после технической компрометации?

Куда движется attacker после stolen session?

Как cyber telemetry меняет fraud score?

Какие antifraud-события должны возвращаться в SOC?

Кто видит всю customer journey во время атаки?

Кто владеет end-to-end coordination?

Где заканчивается наш visibility не потому, что атака закончилась, а потому, что дальше начинается ответственность другой функции?

Для меня именно это один из признаков зрелой security leadership.

Не расширять оргструктуру ради влияния.

А видеть бизнес-риск за пределами собственной функции и строить интерфейсы там, где злоумышленник использует организационные разрывы.

Если у компании есть SOC и развитый antifraud, я бы начал не с интеграции платформ.

Я бы взял три-пять реальных сценариев customer cyber-enabled fraud и вместе прошёл их от первого контакта злоумышленника до конечного ущерба.

Для каждого сценария ответил бы на вопросы:

А затем провёл бы совместный cyber-fraud tabletop.

Не «SOC расследует malware».

А полный сценарий:

phishing → account takeover → transaction → mule → customer impact.

Злоумышленнику не важно, как устроена наша оргструктура.

Он не передаёт incident из cyber в fraud.

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

Поэтому я не считаю организационное объединение SOC и antifraud обязательным.

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

Разные функции — нормально. Разная картина одной атаки — уже проблема.

Сильная защитная модель начинается там, где cybersecurity, antifraud, IAM и customer protection сохраняют собственные компетенции, но способны в реальном времени собрать один attack narrative и совместно разрушить цепочку раньше, чем она закончится реальным ущербом.