Привет, Хабр! Когда заходит речь о SOC, в голове обычно всплывает техническая картина: вредонос на рабочей станции, фишинговое письмо, подозрительные PowerShell-команды, сканирование портов, эксплуатация уязвимости, скомпрометированный аккаунт, аномалия в инфраструктуре. Для крупного ритейла этой картины давно мало. О том, как киберугрозам противодействуют в М.Видео расскажет Евгений Прошин, руководитель отдела мониторинга и реагирования на инциденты.
Атака на торговую сеть всё чаще стартует не с вредоносного файла и не с попытки пробить периметр. Она выглядит как вал регистраций личных кабинетов, credential stuffing, SMS-бомбинг, перебор промокодов, выкачивание бонусов, серия странных оплат чужими картами, фишинговая страница под бренд со ссылкой, которую клиент получает в мессенджере.
В оргструктуре за всё это отвечают разные люди: информационная безопасность, антифрод, e-commerce, платёжная команда, контакт-центр, PR, юристы, владельцы клиентских сервисов. Для клиента и для бизнеса последствия при этом выглядят одинаково: деньги утекли, клиентский опыт испорчен, поддержка завалена обращениями, репутация под ударом, а решение нужно принимать быстро.
Дальше разберём, почему SOC в ритейле приходится смотреть шире классической инфраструктурной безопасности, как сшить поток технических алертов с бизнес-контекстом и почему общий взгляд на ИБ- и антифрод-сигналы помогает быстрее закрывать риски для клиента и ключевых процессов.
Почему ритейл меняет требования к SOC
Крупный ритейл не сводится к магазинам, складам, кассам и корпоративной сети. За ними стоит большая цифровая экосистема, и почти каждый её узел кому-то интересен как точка входа: сайт и мобильное приложение, личные кабинеты, платёжный контур, бонусная программа, промо и персональные предложения, доставка и самовывоз, контакт-центр, маркетинговые платформы, партнёрские интеграции, внешнее присутствие бренда в сети.
За массовыми попытками входа в личные кабинеты стоит сразу две вещи: нагрузка на сервис авторизации и подготовка к хищению бонусов. Фишинговый домен формально относится к внешним угрозам бренду, но в финале превращается в компрометацию клиентских аккаунтов. Аномальные оплаты выглядят как ошибка пользователя, а оказываются card testing или звеном более длинной схемы.
Поэтому к SOC в ритейле приходит расширенный список вопросов помимо привычного «что произошло в инфраструктуре»:
какой клиентский или бизнес-процесс задет;
есть ли риск денежных потерь;
под угрозой ли персональные данные и клиентский аккаунт;
может ли атака быстро вырасти в масштабе;
кого подключать к реагированию;
какое действие снизит ущерб прямо сейчас.
Очередь алертов без бизнес-контекста
Ответить на эти вопросы мешает знакомая любому SOC болезнь: событий много, рук мало. SIEM, EDR, WAF, сетевые средства, мониторинг, антифрод-правила, обращения пользователей и внешние источники гонят сплошной поток сигналов. Часть из них критична, часть требует проверки, часть оказывается шумом.
Если ориентироваться только на техническую критичность, события начинают конкурировать за внимание аналитика в общей очереди. Фишинговое письмо, ложное срабатывание EDR, всплеск ошибок авторизации, странная активность на веб-ресурсе и фродовый паттерн в оплатах могут лежать рядом, хотя вес у них для бизнеса разный.
Самый громкий технический алерт далеко не всегда самый важный для бизнеса, и наоборот: то, что выглядит обычной пользовательской активностью, иногда оказывается ранним признаком массовой атаки.
К примеру: несколько неуспешных авторизаций сами по себе не пугают, но стоит добавить контекст, и картина меняется. Когда за одним fingerprint стоят десятки аккаунтов, действия повторяются по одному сценарию, сеть подозрительная, а следом идут попытки потратить бонусы или промокоды, это уже автоматизированная атака на клиентский контур, а не случайная опечатка в коде из СМС.
Отсюда сдвиг, к которому приходит зрелый SOC: он обрабатывает не алерты, а риски.
Что значит сшить ИБ и антифрод
Связка ИБ и антифрода не означает, что одна команда поглощает другую: у них разные компетенции, разные процессы и разная экспертиза.
ИБ сильнее в технической стороне: инфраструктура, события безопасности, хосты, сети, учётные записи, уязвимости, вредоносная активность, подозрительные команды, внешние индикаторы компрометации. Антифрод сильнее в поведении и деньгах: клиентские сценарии, платежи, заказы, отмены, бонусы, промокоды, нетипичное поведение аккаунта, финансовые паттерны, признаки злоупотреблений.
Польза появляется там, где эти данные начинают работать в паре. Событие «клиент сделал несколько неудачных попыток оплаты» в одиночку почти ничего не значит. Стоит появиться рядом новому устройству, подозрительному IP, серии похожих аккаунтов, повторяющемуся платёжному инструменту и странному поведению сразу после создания заказа, и картина собирается в возможный фродовый сценарий.
Другой разворот: SOC видит всплеск запросов к сервису авторизации. Без бизнес-контекста это похоже на техническую нагрузку или перебор. Если же антифрод подсказывает, что после удачных входов идут операции с бонусами или промокодами, приоритет инцидента обязан подняться.
На практике связка держится на общих сущностях, вокруг которых и крутится анализ:
клиентский аккаунт;
устройство;
IP-адрес и сетевые признаки;
сессия;
заказ;
платёж;
карта или токен платёжного инструмента;
бонусный счёт;
промокод;
адрес доставки или пункт выдачи;
внешний домен или мошенническая ссылка.
Как только SOC умеет дополнять технический алерт этими признаками, он быстрее понимает, с чем имеет дело: технический шум, одиночный инцидент, фрод или массовая атака на процесс.
Источники, которые нужны SOC
Чтобы видеть полную картину, классических ИБ-логов не хватает. Нужна телеметрия из нескольких контуров.
Базовый набор знаком любому SOC: SIEM, EDR/XDR, WAF, события AD/IAM, сетевые события, почтовая безопасность, события веб-приложений и API, threat intelligence, результаты внешнего мониторинга бренда и фишинга.
Для ритейла к нему добавляются бизнес-события: регистрации и авторизации в личном кабинете, изменения профиля, привязка и использование платёжных инструментов, попытки оплаты, успешные и неуспешные транзакции, отмены заказов, возвраты, траты бонусов, применение промокодов, частота заказов, обращения в контакт-центр, события мобильного приложения, device fingerprint и технические признаки устройства.
Цель не в том, чтобы без разбора залить в SOC все доступные данные. Так быстро растут расходы на хранение, а аналитики тонут в шуме. Разумнее очертить минимальный набор событий, который помогает ответить на четыре вопроса: что произошло, кого или что задело, какой процесс под риском, какое действие выполнить. Если событие не помогает с этими ответами, его место в SOC стоит обосновать отдельно.
Приоритет вместо severity
Классическая шкала high/medium/low хорошо подходит для первичной технической сортировки, но ритейлу её мало. Один и тот же технический уровень критичности оборачивается разным влиянием на бизнес. Medium на тестовом стенде и medium в платёжном контуре живут в разных вселенных. Неудачный вход в один аккаунт и атака на тысячи аккаунтов тоже различаются, хотя тип события похож.
Значит, к severity добавляется бизнес-контекст. Грубую модель можно записать так:
Приоритет = техническая критичность × бизнес-влияние × масштаб × вероятность развития × клиентский ущерб
На разборе конкретного события это превращается в набор оценок: какой сервис затронут и клиентский ли он, связан ли с платежами, бонусами, заказами или персональными данными, сколько аккаунтов задето, есть ли следы автоматизации, повторяется ли сценарий, способна ли атака масштабироваться, тянет ли за собой внешний репутационный риск, нужно ли звать другие команды. Так перед аналитиком оказывается вероятное влияние события на клиента и бизнес, а не только его технический тип.
Кейс: массовая активность в личных кабинетах
Аккаунты клиентов в ритейле ломают постоянно: credential stuffing, массовые регистрации, перебор паролей, накрутка реферальной программы, охота за промокодами и бонусами.
Поначалу это не отличить от обычного дня сервиса: регистрации, входы, ошибки при логине, сбросы пароля, смена контактов. Разницу выдают детали: десятки аккаунтов с одного устройства, одинаковые параметры браузера или мобильного клиента, неестественная частота действий, подозрительные сети, прокси и хостинги, один и тот же сценарий у разных аккаунтов, операции с бонусами, промокодами или заказами сразу после входа.
Одним алертом «много авторизаций» тут не отделаешься: за неделю он превратится в фон, на который никто не смотрит. Толк появляется, когда технические признаки сходятся с тем, что аккаунт делает после входа, и сразу видно, задевает это клиента и деньги или нет. Всплеск входов сам по себе тянет на один приоритет. Тот же всплеск, за которым тут же идут траты бонусов или смена данных, на совсем другой, а добавьте автоматизацию и повторяемость, и событие уезжает в начало очереди.
Кейс: платежи и card testing
Платёжный контур ближе всего к деньгам, и следят за ним пристальнее всего. Причём смотреть надо не на сам факт оплаты, прошла она или нет, а на то, что происходит вокруг неё.
Подозрительно выглядят несколько попыток оплаты подряд, перебор разных карт, пачка отказов, отмены сразу после онлайн-оплаты, нетипичная сумма, частая смена аккаунтов с одного устройства, одинаковые платёжные признаки у разных клиентов, странности по IP, геолокации и устройству, повтор того же сценария на разных заказах.
Если списать всё на платёжные ошибки, схема пройдёт незамеченной. Если свести к чистой технике, исчезнет денежная подоплёка. Поэтому SOC, антифрод и те, кто отвечает за платежи, разбираются с этим вместе.
На практике цепочка такая: платёжный шлюз или антифрод выдаёт событие, SOC подтягивает к нему контекст (IP, устройство, сессию, аккаунт, историю похожих случаев), правило или аналитик ставит уровень риска, и дальше по этому риску решают, что делать: проверить ещё раз, придержать сценарий, отдать в антифрод, позвать владельца процесса или поднять полноценный инцидент.
При этом SOC не принимает бизнес-решение за владельца процесса. Его дело найти риск раньше, собрать контекст и поднять нужный процесс, а решать дальше тем, кто отвечает за платежи.
Кейс: угрозы за периметром
Часть угроз вообще не внутри периметра. Атаки на клиентов часто живут снаружи: фишинговые сайты, поддельные страницы оплаты, домены-двойники под бренд, фейковые акции и розыгрыши, поддельные аккаунты в соцсетях, короткие ссылки на мошеннические ресурсы, объявления о продаже аккаунтов, бонусов и промокодов, утечки логинов и паролей клиентов и сотрудников.
Формально этим занимаются Brand Protection, Digital Risk Protection, PR, юристы или клиентский сервис. SOC всё равно в деле, потому что внешняя угроза цепляется за внутренние события. Фишинговая страница собирает логины и пароли клиентов, а через какое-то время в логах авторизации всплывают попытки зайти в настоящие кабинеты. Не свяжешь эти два потока, и компания видит два отдельных эпизода: где-то фишинг снаружи, где-то ошибки входа внутри. Свяжешь, и вся цепочка атаки видна целиком.
Дальше всё идёт по шагам: нашли подозрительный домен или страницу, сверили с брендом, прикинули, что именно там собирают (логины, платёжные данные, телефоны, коды подтверждения), и отправили на блокировку. Тем временем SOC смотрит, нет ли связанных событий внутри: всплеска входов, жалоб клиентов, попыток зайти, изменений в аккаунтах. Если надо, подключаются PR, контакт-центр, юристы и владельцы клиентских сервисов.
Так клиента прикрывают и внутри приложения, и снаружи, там, где компания формально уже не хозяин.
Кейс: SMS-бомбинг и нагрузка на поддержку
Технически SMS-бомбинг выглядит как лавина запросов на одноразовые коды, для клиента это назойливый поток сообщений, а для бизнеса счёт за SMS, заваленный контакт-центр и просевшее доверие.
Если смотреть только на нагрузку на API, всё упрётся в rate limit по IP. А его обходят на раз: меняют адреса, раскидывают источники, гоняют разные номера, и всё та же автоматизация по одному сценарию.
Подход посерьёзнее смотрит на несколько слоёв сразу: сколько запросов с одного IP, сколько разных номеров с одного источника, сколько источников бьют в один номер, связка IP, устройства, сессии и сценария, дошло ли дело до удачного входа после кода, репутация сети, следы автоматизации, что при этом прилетает клиентам и контакт-центру.
SOC тут нужен не чтобы «заблокировать IP», а чтобы выстроить осмысленный ответ: где-то хватит притормозить частоту, где-то поставить challenge, где-то закрыть сценарий целиком, а где-то позвать тех, кто отвечает за клиентский сервис.
Что меняется в роли SOC
В этой модели SOC перестаёт быть просто приёмником технических алертов. Он садится между ИБ, антифродом и бизнесом и сшивает их сигналы: собирает события с обеих сторон, расставляет приоритеты по реальному влиянию, ловит массовые и повторяющиеся сценарии, обвешивает инцидент контекстом — клиент, устройство, заказ, платёж, внешний след — и отдаёт подтверждённые паттерны дальше, в антифрод-правила, в требования к мониторингу, в SOAR.
Границу ответственности при этом лучше не размывать. SOC не решает в одиночку, кому отключить оплату, чей заказ отменить и кого записать в мошенники, — это остаётся за владельцами процессов и опирается на правила, юридическую оценку и согласованную модель риска. У SOC своя задача — найти раньше, квалифицировать, дать контекст и доказательства, поднять нужный процесс.
Как это запускать и что считать успехом
Начинать стоит не с покупки системы и не с попытки автоматизировать всё разом, а с разговора о модели риска: какие процессы для компании критичнее всего, какие сценарии фрода уже видны, что нужно для раннего обнаружения, кто реагирует, где можно отдать решение автоматике, а где только руками, что разрешает закон.
Дальше — техника: нормализация событий, корреляция, риск-скоринг, интеграции с антифродом, платёжным контуром, WAF, EDR, Brand Protection и SOAR. И двигаться итерациями: взять два-три понятных сценария (массовые авторизации, атаки на бонусы, фишинговые домены), для каждого прописать признаки, источники, приоритет, владельца и ожидаемый результат.
Тяжелее всего тут не техника, а организация. Данные разбросаны по системам и владельцам, поэтому SOC видит алерт, но не дотягивается до контекста по заказу или оплате. Команды говорят на разных языках: для ИБ — IOC, хосты и учётки, для антифрода — клиент, заказ и сумма ущерба, и общий формат инцидента приходится проговаривать отдельно.
Автоматику легко перетянуть: блокировку клиента или платёжного метода нужно согласовывать аккуратно, иначе автоматизируется не снижение ущерба, а хаос. И «закрыть всё подозрительное» в ритейле не выйдет — где-то хватит мониторинга, где-то нужен challenge, где-то ручная проверка.
Мерить такую работу числом закрытых алертов бессмысленно. Полезнее смотреть, что меняется в процессе: насколько быстро инцидент получает квалификацию, какая доля событий обросла бизнес-контекстом, сколько массовых сценариев поймали и увели в правила, насколько просела ручная рутина и нагрузка на контакт-центр по типовым атакам.
Что забрать из этого
Опыт крупного ритейла сводится к нескольким тезисам.
Техническая критичность события не равна бизнес-критичности. Для нормальной приоритизации нужен контекст: клиент, платёж, заказ, бонусы, устройство, внешний ресурс, масштаб и вероятность развития.
ИБ и антифрод видят разные половины одной картины. SOC ловит технические признаки, антифрод читает поведение, и вместе они описывают риск точнее, чем поодиночке.
Защита клиента не заканчивается на сайте и в приложении. Фишинговые домены, поддельные акции, мошеннические ссылки и утечки учёток попадают в тот же процесс обнаружения и реагирования.
Автоматизация окупается там, где ясны правила решения, владельцы действий и допустимый уровень риска. В остальных местах она автоматизирует не снижение ущерба, а беспорядок.
Зрелость SOC видна не в объёме, а в скорости — насколько быстро команда понимает, какой процесс под угрозой, кого звать и какое действие снизит риск.
В ритейле инцидент не всегда означает вирус, эксплойт или взломанный сервер. Иногда это атака на клиентский сценарий — и чем раньше SOC научится её замечать, тем раньше безопасность превращается из чисто технической функции в способ защитить клиента, бренд и выручку.